netdev - Re: [PATCH bpf-next 2/7] set_memory: introduce set_memory_[ro|x]

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: <B50E9A96-E7AD-4C33-8CDC-AAD058C32401@fb.com>
Date:   Thu, 18 Nov 2021 00:11:49 +0000
From:   Song Liu <songliubraving@...com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     Johannes Weiner <hannes@...xchg.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        bpf <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "andrii@...nel.org" <andrii@...nel.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 2/7] set_memory: introduce
 set_memory_[ro|x]_noalias



> On Nov 17, 2021, at 3:57 PM, Song Liu <songliubraving@...com> wrote:
> 
> 
> 
>> On Nov 17, 2021, at 2:01 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> 
>> On Wed, Nov 17, 2021 at 09:36:27PM +0000, Song Liu wrote:
>>> 
>>> 
>>>> On Nov 16, 2021, at 12:00 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>>>> 
>>>> On Mon, Nov 15, 2021 at 11:13:42PM -0800, Song Liu wrote:
>>>>> These allow setting ro/x for module_alloc() mapping, while leave the
>>>>> linear mapping rw/nx.
>>>> 
>>>> This needs a very strong rationale for *why*. How does this not
>>>> trivially circumvent W^X ?
>>> 
>>> In this case, we want to have multiple BPF programs sharing the 2MB page. 
>>> When the JIT engine is working on one program, we would rather existing
>>> BPF programs on the same page stay on RO+X mapping (the module_alloc() 
>>> address). The solution in this version is to let the JIT engine write to 
>>> the page via linear address. 
>>> 
>>> An alternative is to only use the module_alloc() address, and flip the 
>>> read-only bit (of the whole 2MB page) back and forth. However, this 
>>> requires some serialization among different JIT jobs. 
>> 
>> Neither options seem acceptible to me as they both violate W^X.
>> 
>> Please have a close look at arch/x86/kernel/alternative.c:__text_poke()
>> for how we modify active text. I think that or something very similar is
>> the only option. By having an alias in a special (user) address space
>> that is not accessible by any other CPU, only the poking CPU can expoit
>> this (temporary) hole, which is a much larger ask than any of the
>> proposed options.
> 
> I would agree that __text_poke() is a safer option. But in this case, we 
> will need the temporary hole to be 2MB in size. Also, we will probably 
> hold the temporary mapping for longer time (the whole JITing process). 
> Does this sound reasonable?

Actually, the hole is probably not always 2MB in size. But it could be up 
to 2MB in size. 

Song