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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 02 2022 at 10:46, Christophe Leroy wrote:
> Le 02/12/2022 à 02:38, Thomas Gleixner a écrit :
>> Even modules can benefit from that. The fact that modules have all
>> sections (text, data, rodata) page aligned and page granular is not due
>> to an requirement of modules, it's so because that's how module_alloc()
>> works and the module layout has been adopted to it.
>
> Sections are page aligned only when STRICT_MODULE_RWX is selected.

Correct, but without strict permission separation we would not debate
this at all. Everything would be RWX and fine.

For separation my point still stands that the problem is that
module_alloc() is just doing an en-bloc allocation, which needs to be
split into RX, RW, RO afterwards and that consequently splits the large
mappings apart. Which in turn means text, data, rodata have to be page
aligned and page granular.

The typed approach and having a mechanism to preserve the underlying
large page mappings is the broadest scope we have to cover.

An RWX only architecture is just the most trivial case of such an
infrastructure. The types become all the same, the underlying page size
does not matter, but it's just a configuration variant.

Architectures which support strict separation, but only small pages are
a configuration variant too.

All of them can use the same infrastructure and the same API to
alloc/free and write/update the allocated memory. The configuration will
take care to pick the appropriate mechanisms.

No?

Thanks,

        tglx

 





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux