linux-kernel - Re: [PATCH bpf-next 1/3] mm/vmalloc: introduce vmalloc

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: <Ys/rnFf/ewPA85Iz@worktop.programming.kicks-ass.net>
Date:   Thu, 14 Jul 2022 12:10:36 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Song Liu <songliubraving@...com>
Cc:     Song Liu <song@...nel.org>, bpf <bpf@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        "linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        "naveen.n.rao@...ux.ibm.com" <naveen.n.rao@...ux.ibm.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "anil.s.keshavamurthy@...el.com" <anil.s.keshavamurthy@...el.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "hch@...radead.org" <hch@...radead.org>,
        "dave@...olabs.net" <dave@...olabs.net>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>,
        "x86@...nel.org" <x86@...nel.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "rick.p.edgecombe@...el.com" <rick.p.edgecombe@...el.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH bpf-next 1/3] mm/vmalloc: introduce vmalloc_exec which
 allocates RO+X memory

On Wed, Jul 13, 2022 at 09:20:55PM +0000, Song Liu wrote:
> 
> 
> > On Jul 13, 2022, at 1:26 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> > 
> > On Wed, Jul 13, 2022 at 03:48:35PM +0000, Song Liu wrote:
> > 
> >>> So how about instead we separate them? Then much of the problem goes
> >>> away, you don't need to track these 2M chunks at all.
> >> 
> >> If we manage the memory in < 2MiB granularity, either 4kB or smaller, 
> >> we still need some way to track which parts are being used, no? I mean
> >> the bitmap.  
> > 
> > I was thinking the vmalloc vmap_area tree could help out there.
> 
> Interesting. vmap_area tree indeed keeps a lot of useful information. 
> 
> Currently, powerpc supports CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC, 

Only PPC32; and it's due to a constraint in their MMU vs page
protections.

> which leaves module_alloc just for module text. If this works, we get
> separation between RO+X and RW memory. What would it take to enable
> CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC for x86_64? 

The VM_TOPDOWN_VMAP flag and ensuring the data and code regions never
overlap. Once you have that you can enable it.

Specifically the problem is that data needs to be in the s32 immediate
range just like code, so we're constrained to the module range. Given
that constraint, the easiest solution is to use the different ends of
that range.