On 6/10/19 9:05 AM, Yu-cheng Yu wrote: > On Fri, 2019-06-07 at 14:09 -0700, Dave Hansen wrote: >> On 6/7/19 1:06 PM, Yu-cheng Yu wrote: >>>> 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?
