Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs

[Mike Rapoport <rppt@kernel.org>]

On Wed, Nov 09, 2022 at 05:04:25PM +0000, Edgecombe, Rick P wrote:
> On Wed, 2022-11-09 at 13:17 +0200, Mike Rapoport wrote:
> > On Tue, Nov 08, 2022 at 04:51:12PM +0000, Edgecombe, Rick P wrote:
>
> > How the caching of large pages in vmalloc can be made useful for use
> > cases like secretmem and PKS?
> 
> This part is easy I think. If we had an unmapped page allocator it
> could just feed this. 

The unmapped page allocator could be used by anything that needs
non-default permissions in the direct map and knows how to map the pages
elsewhere. E.g it would have been a oneliner to switch x86::module_alloc()
to use unmapped allocations. But ...

> Do you have any idea when you might pick up that stuff again?

... unfortunately I don't see it happening anytime soon.
 
> To answer my own question, I think a good first step would be to make
> the interface also work for non-text_poke() so it could really be cross
> arch, then use it for everything except modules. The benefit to the
> other arch's at that point is centralized handling of loading text. 

My concern is that the proposed execmem_alloc() cannot be used for
centralized handling of loading text. I'm not familiar enough with
modules/ftrace/kprobes/BPF to clearly identify the potential caveats, but
my gut feeling is that the proposed execmem_alloc() won't be an improvement
but rather a hindrance for moving to centralized handling of loading text.

It feels to me that a lot of ground work is needed to get to the point
where we can use centralized handling of loading text.

-- 
Sincerely yours,
Mike.