lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 22 Apr 2017 09:49:31 -0400 From: Yichao Yu <yyc1992@...il.com> To: linux-kernel@...r.kernel.org Subject: Memory order of `mprotect` Hi, For the purpose of concurrent/parallel GC (in userspace obviously), I'm interested in what memory order guarantee is provided by the mprotect syscall. My questions are (assuming no compilier reordering or with sufficient compiler barrier) 1. If thread 1 triggers a segfault on an address due to a mprotect on thread 2, can I be sure that everything happens on thread 2 before the syscall can be observed in thread 1 in the signal handler of the segfault? What if a full memory barrier is placed in the signal handler before performing load on thread1? 2. If thread 1 does an volatile load on an address that is set to PROT_NONE by thread 2 and didn't trigger a segfault, is this enough of a happens before relation between the two. Or in another word, if the two threads do (`*ga` starts as `0`, `p` is a page aligned address) // thread 1 *ga = 1; *(volatile int*)p; // no segfault happens // thread 2 mprotect(p, 4096, PROT_NONE); a = *ga; is there a guarantee that `a` on thread 2 will be `1`? (assuming no segfault observed on thread 1 and no other code modifies `*ga`) I'm mainly interested in x86(_64) and arm/aarch64, maybe ppc too. So far my tests on x64 and aarch64 suggests no violations of these though I'm not sure if my test is conclusive or if the behavior can be relied on in the long term. Some searching suggests that `mprotect` may issue a TLB shootdown on all threads with the address mapped when permission is removed which might provide the guarantee stated here though it's unclear to me if future optimization of the kernel code could break this guarentee. Thanks. Yichao Yu
Powered by blists - more mailing lists