linux-hardening - Re: [RFC PATCH v2 17/19] x86/mm/cpa: PKS protect direct map page tables

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: <69aaf7209a560b6414c5ea839bd9a3800495050e.camel@intel.com>
Date:   Tue, 31 Aug 2021 17:58:04 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "rppt@...nel.org" <rppt@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "Weiny, Ira" <ira.weiny@...el.com>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "x86@...nel.org" <x86@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "shakeelb@...gle.com" <shakeelb@...gle.com>
Subject: Re: [RFC PATCH v2 17/19] x86/mm/cpa: PKS protect direct map page
 tables

On Tue, 2021-08-31 at 13:14 +0300, Mike Rapoport wrote:
trim
> > +/*
> > + * If pre boot, reserve large pages from memory that will be
> > mapped. It's ok that this is not
> > + * mapped as PKS, other init code in CPA will handle the
> > conversion.
> > + */
> > +static unsigned int __init reserve_pre_boot(u64 start, u64 end)
> > +{
> > +     u64 cur = memblock_find_in_range(start, end, HPAGE_SIZE,
> > HPAGE_SIZE);
> > +     int i;
> 
> Please use memblock_phys_alloc_range() here.
Oh yea, that's better. Thanks.

> Besides, it seems this reserved pages are not accessed until
> late_initcall
> time, so there is no need to limit the allocation to already mapped
> areas,
> memblock_alloc_raw() would suffice.
The page itself is used for the llist_node. I didn't see an easy way to
get a smaller allocate at this time. I guess it could use less mapped
memory by just using a few mapped pages for some structs to keep the
list outside of the unmapped pages, but it becomes more complex.

> 
> > +
> > +     if (!cur)
> > +             return 0;
> > +     memblock_reserve(cur, HPAGE_SIZE);
> > +     for (i = 0; i < HPAGE_SIZE; i += PAGE_SIZE)
> > +             add_dmap_table((unsigned long)__va(cur + i));
> > +     return HPAGE_SIZE;
> > +}
> > +
> > +/* If post boot, memblock is not available. Just reserve from
> > other memory regions */
> > +static unsigned int __init reserve_post_boot(void)
> > +{
> > +     struct page *page = alloc_table(GFP_KERNEL);
> > +
> > +     if (!page)
> > +             return 0;
> > +
> > +     add_dmap_table((unsigned long)page_address(page));
> 
> add_dmap_table() calls use casting everywhere, maybe make it
> add_dmap_table(void *)?
> 
Yea, I'll give it a try. It was on my todo list, but somehow got
forgotten.

> > +