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]

Date:   Thu, 14 Jul 2022 04:54:40 +0000
From:   Song Liu <songliubraving@...com>
To:     Christoph Hellwig <hch@...radead.org>
CC:     Song Liu <song@...nel.org>, bpf <bpf@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
        "mcgrof@...nel.org" <mcgrof@...nel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "mhiramat@...nel.org" <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>,
        "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 Jul 13, 2022, at 9:23 PM, Christoph Hellwig <hch@...radead.org> wrote:
> 
> On Wed, Jul 13, 2022 at 03:49:45PM +0000, Song Liu wrote:
>> 
>> 
>>> On Jul 13, 2022, at 3:08 AM, Christoph Hellwig <hch@...radead.org> wrote:
>>> 
>>> NAK.  This is not something that should be an exported public API
>>> ever.
>> 
>> Hmm.. I will remove EXPORT_SYMBOL_GPL (if we ever do a v2 of this..)
> 
> Even without that it really is not a vmalloc API anyway.  

This ...

> Executable
> memory needs to be written first, so we should allocate it in that state
> and only mark it executable after that write has completed.

... and this are two separate NAKs.

For the first NAK, I agree that my version is another layer on top of 
vmalloc. But what do you think about Peter's idea? AFAICT, that fits
well in vmalloc logic. 

For the second NAK, I acknowledge the concern. However, I think we 
will need some mechanism to update text without flipping W and X bit in 
the page table. Otherwise, set_memory_* w/ alias will fragment the 
direct map, and cause significant performance drop over time. If this
really doesn't work because of this concern, we will need to look into 
other solutions discussed in LSFMMBPF [1]. 

Thanks,
Song
[1] https://lwn.net/Articles/894557/