linux-kernel - Re: [PATCH v2 0/3] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210112214759.GC10434@willie-the-truck>
Date:   Tue, 12 Jan 2021 21:47:59 +0000
From:   Will Deacon <will@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Kirill A. Shutemov" <kirill@...temov.name>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Jan Kara <jack@...e.cz>, Minchan Kim <minchan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Vinayak Menon <vinmenon@...eaurora.org>,
        Hugh Dickins <hughd@...gle.com>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v2 0/3] Create 'old' ptes for faultaround mappings on
 arm64 with hardware access flag

On Mon, Jan 11, 2021 at 11:25:37AM -0800, Linus Torvalds wrote:
> On Mon, Jan 11, 2021 at 6:24 AM Kirill A. Shutemov <kirill@...temov.name> wrote:
> >
> > I wonder if it would be acceptable to pass down to faultaround a copy
> > of vmf, so it mess with it without risking to corrupt the original one?
> 
> I'd almost prefer to split vmf into two parts: the 'this is the fault
> info' part and the 'this is the fault handling state' part.
> 
> So the first one would be filled in by the actual page faulter (or
> GUP) - and then be 'const' during the lookup, while the second one
> would be set up by handle_mm_fault() and would contain that "this is
> the current state of my fault state machine" and contain things like
> that ->pte thing.
> 
> And then if somebody actually needs to pass in "modified fault state"
> (ie that whole "I'm doing fault-around, so I'll use multiple
> addresses") they'd never modify the address in the fault info, they'd
> just pass the address as an explicit argument (like most cases already
> do - the "change addr or flags in vmf" is actually already _fairly_
> rare).

Alright then, I'll take another crack at this for v3 and see how far I
get.

Will