[lkml]   [2020]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH bpf-next] bpf: Make trampolines W^X
> On Jan 9, 2020, at 3:01 PM, Edgecombe, Rick P <> 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

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

 \ /
  Last update: 2020-01-10 19:36    [W:0.041 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site