On 6/10/19 9:05 AM, Yu-cheng Yu wrote:

On Fri, 2019-06-07 at 14:09 -0700, Dave Hansen wrote:

quoted

On 6/7/19 1:06 PM, Yu-cheng Yu wrote:

quoted

quoted

Huh, how does glibc know about all possible past and future legacy code
in the application?

When dlopen() gets a legacy binary and the policy allows that, it will
manage
the bitmap:

  If a bitmap has not been created, create one.
  Set bits for the legacy code being loaded.

I was thinking about code that doesn't go through GLIBC like JITs.

If JIT manages the bitmap, it knows where it is.
It can always read the bitmap again, right?

Let's just be clear:

The design proposed here is that all code mappers (anybody wanting to
get legacy non-CET code into the address space):

1. Know about CET
2. Know where the bitmap is, and identify the part that needs to be
   changed
3. Be able to mprotect() the bitmap to be writable (undoing glibc's
   PROT_READ)
4. Set the bits in the bitmap for the legacy code
5. mprotect() the bitmap back to PROT_READ

Do the non-glibc code mappers have glibc interfaces for this?
Otherwise, how could a bunch of JITs in a big multi-threaded application
possibly coordinate the mprotect()s?  Won't they race with each other?