On 11/23/2017 01:48 PM, Florian Weimer wrote: >>>> Using the malloc() analogy, we >>>> don't expect that free() in one thread actively takes away references to >>>> the memory held by other threads. >>> >>> But malloc/free isn't expected to be a partial antidote to random >>> pointer scribbling. >> >> Nor is protection keys intended to be an antidote for use-after-free. > > I'm comparing this to munmap, which is actually such an antidote > (because it involves an IPI to flush all CPUs which could have seen the > mapping before). > > I'm surprised that pkey_free doesn't perform a similar broadcast. Hmm, I'm not sure this comparison is accurate. IPI flushes in unmap are done because the shared page tables were updated, and TLB's in other cpu's might be stale. The closest pkey equivalent would be allocating a new pkey that only my thread can use, and then using it in pkey_mprotect() to change some memory region. Then other threads will lose access and I believe IPI's will be issued and existing TLB mappings in other cpu's removed. pkey_remove() has AFAICS two potential problems: - the key is still used in some page tables. Scanning them all and resetting to 0 would be rather expensive. Maybe we could maintain per-pkey counters (for pkey != 0) in the mm, which might not be that expensive, and refuse pkey_free() if the counter is not zero? - the key is still "used" by other threads in their PKRU. Here I would think that if kernel doesn't broadcast pkey_alloc() to other threads, it also shouldn't broadcast the freeing? We also can't track per-pkey "threads using pkey" counters, as WRPKRU is pure userspace.
