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: <20211117220132.GC174703@worktop.programming.kicks-ass.net>
Date:   Wed, 17 Nov 2021 23:01:32 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Song Liu <songliubraving@...com>
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 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.