linux-kernel - Re: [PATCH bpf-next] bpf: Make trampolines W^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] [day] [month] [year] [list]

Date:   Fri, 10 Jan 2020 10:35:59 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc:     "luto@...nel.org" <luto@...nel.org>,
        "songliubraving@...com" <songliubraving@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
        "mjg59@...gle.com" <mjg59@...gle.com>,
        "nadav.amit@...il.com" <nadav.amit@...il.com>,
        "ast@...nel.org" <ast@...nel.org>,
        "thgarnie@...omium.org" <thgarnie@...omium.org>,
        "kpsingh@...omium.org" <kpsingh@...omium.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "revest@...omium.org" <revest@...omium.org>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "namit@...are.com" <namit@...are.com>,
        "jackmanb@...omium.org" <jackmanb@...omium.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "kafai@...com" <kafai@...com>, "yhs@...com" <yhs@...com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "mhalcrow@...gle.com" <mhalcrow@...gle.com>,
        "andriin@...com" <andriin@...com>
Subject: Re: [PATCH bpf-next] bpf: Make trampolines W^X

> On Jan 9, 2020, at 3:01 PM, Edgecombe, Rick P <rick.p.edgecombe@...el.com> wrote:

>> The vmap code immediately removes PTEs when unmaps occur (which it may
>> very well do right now -- I haven't checked) but also tracks the
>> kernel_tlb_gen associated with each record of an
>> unmapped-but-not-zapped area.  Then we split vm_unmap_aliases() into a
>> variant that unmaps all aliases and a variant that merely promises to
>> unmap at least one alias.  The former does what the current code does
>> except that it skips the IPI if all areas in question have tlb_gen <
>> flushed_kernel_tlb_gen.  The latter clears all areas with tlb_gen <
>> flushed_kernel_tlb_gen and, if there weren't any, does
>> flush_tlb_kernel_range() and flushes everything.
>>
>> (Major caveat: this is wrong for the case where
>> flush_tlb_kernel_range() only flushes some but not all of the kernel.
>> So this needs considerable work if it's actually going to me useful.
>> The plain old "take locks and clean up" approach might be a better
>> bet.)
>>
>
> Hmm. In normal usage (!DEBUG_PAGE_ALLOC), are kernel range tlb shootdowns common
> outside of module space users and lazy vmap stuff? A tlb_gen solution might only
> be worth it in cases where something other than vm_unmap_aliases() and helpers
> was doing this frequently.

I suspect that the two bug users aside from vunmap() will be eBPF and,
eventually, XPFO / “exclusive pages” / less crappy SEV-like
implementations / actual high quality MKTME stuff / KVM
side-channel-proof memory.  The latter doesn’t actually exist yet (the
SEV implementation sidesteps this with a horrible hack involving
incoherent mappings that are left active with fingers crossed), but it
really seems like it’s coming.

In general, if we’re going to have a pool of non-RW-direct-mapped
pages, we also want some moderately efficient way to produce such
pages.

Right now, creating and freeing eBPF programs in a loop is probably a
performance disaster on large systems.