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  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]
Date:   Tue, 31 Aug 2021 18:48:47 +0000
From:   "Edgecombe, Rick P" <>
To:     "" <>
CC:     "" <>,
        "" <>,
        "" <>,
        "Weiny, Ira" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "Williams, Dan J" <>,
        "Lutomirski, Andy" <>,
        "Hansen, Dave" <>,
        "" <>
Subject: Re: [RFC PATCH v2 10/19] x86/mm: Use alloc_table() for fill_pte(),

On Tue, 2021-08-31 at 11:47 +0300, Mike Rapoport wrote:
> On Mon, Aug 30, 2021 at 04:59:18PM -0700, Rick Edgecombe wrote:
> > fill_pte(), set_pte_vaddr(), etc allocate page tables with
> > spp_getpage(). Use alloc_table() for these allocations in order to
> > get
> > tables from the cache of protected pages when needed.
> I can't say I tracked all the users of set_pte_vaddr(), but I don't
> see a
> fundamental reason why spp_getpage() would need GFP_ATOMIC.
Yea, I couldn't find why it was done that way in the first place, and
there were almost too many callers to audit. I guess I could roll up my
sleeves an audit it all, but its not foolproof. Or put a warn for
atomic context and pull all of the GFP_ATOMIC code if it doesn't get
triggered after awhile. Also seems weird that it just panics here if
the allocation fails.

>  Even if there
> is a caller of set_pte_vaddr() that cannot sleep, it seems that page
> tables
> can be prepopulated so that set_pte_vaddr() will not need to allocate
> anything.  
Hmm, could work for the fixmap callers I guess (maybe already happening
in practice). Xen and a few other things seems to use this for non-
fixmap things, but it's during init and easier to audit.

Powered by blists - more mailing lists