On Sunday, 16 April 2023 16:50:56 CDT Edward Catmur wrote:
> In fact, accept that you cannot have write-and-execute pages at all,
> anywhere. The best you can do is mmap() a new, writable page, to which you
> write the new code, then you mprotect() it to make it read-only &
> executable. That means you have a minimum allocation of a page size (4096
> on x86). If your thunk is 44 bytes, then you have a 9200% overhead.
>
> libffi has a nice optimization where it maps the same page at two different
> addresses, one mapping writeable and the other executable. This is probably
> even more of an issue for security, though.

Indeed, going through a file appears to allow a few more liberties, but not in
all cases. In particular, it will likely be disallowed for any files (including
memfd ones) that don't have the necessary security containment attributes.

So, again, don't expect JIT to work. The functionality needs to be designed so
it works without JIT and isn't unduly burdensome for that.

> There's another technique that works as long as you're OK with having a
> limit to the number of simultaneous thunks outstanding. Basically, instead
> of a single thread-local data pointer you have a fixed-sized array of them,
> and a same-sized array of function pointers to hand out to the
> callback-based API. Demo: https://godbolt.org/z/cGra4Kjxn

Did I mention that I am working on a system with 896 hardware threads?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering