This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Linux: Implement interfaces for memory protection keys

On 12/05/2017 03:06 PM, Adhemerval Zanella wrote:

+@deftypefun int pkey_free (int @var{key})
+@standards{Linux, sys/mman.h}
+Deallocate the protection key, so that it can be reused by
+Calling this function does not change the access rights of the freed
+protection key.  The calling thread and other threads may retain access
+to it, even if it is subsequently allocated again.  For this reason, it
+is not recommended to call the @code{pkey_free} function.

I presume you are referring to your 'MPK: pkey_free and key reuse' discussion,
but should we add a note that 'pkey_free' should be as long as the application
make sure to munmap the pages associated with the key meant to free first?

No, it's also relevant that threads retain access when the key is reused.

My understanding is if we pkey_alloc -> mprotect -> munmap -> pkey_free,
it should not create any other side effects even for key reuse.  Or am
I missing something here?

If there's a pthread_create call between pkey_alloc and pkey_free, and the thread is still running after the pkey_free, then that thread will retain the access rights of the original thread at the time pthread_create was called.

LGTM and we may extend the pkey_free documentation later if it were the case.


As a side note what are you ideas regarding using pkey on glibc (and could you
extend the idea of the GOT protection as well)?

Nick Clifton wrote a binutils patch for me which isolates the GOT on a dedicated page and adds a new DT_* entry with the GOT size. We can then allocate a protection key and apply it to all GOTs in the process. Default access rights for all threads is PKEY_DISABLE_WRITE. _dl_fixup will temporarily disable that to retain write access to the GOT before storing the pointer.

This will need a kernel patch to allow us to specify that we want PKEY_DISABLE_WRITE for the key in signal handlers, not PKEY_DISABLE_ACCESS (as it is the case for some configurations). Without that, lazy binding from signal handlers will be broken. We can implement this with a pkey_alloc flag, so the existing APIs are fine.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]