* [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process @ 2018-05-17 20:16 Alexey Izbyshev 2018-05-17 20:46 ` Andy Lutomirski 0 siblings, 1 reply; 7+ messages in thread From: Alexey Izbyshev @ 2018-05-17 20:16 UTC (permalink / raw) To: Dmitry Safonov, Thomas Gleixner Cc: Andy Lutomirski, Cyrill Gorcunov, Borislav Petkov, Kirill A. Shutemov, Alexander Monakov, linux-mm Hello everyone, I've discovered the following strange behavior of a 4.15.13-based kernel (bisected to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b028f784e8c341e762c264f70dc0ca1418c8b7a between 4.11-rc2 and -rc3 thanks to Alexander Monakov). I've reported it as "https://bugzilla.kernel.org/show_bug.cgi?id=199739". $ cat wrap.c #include <unistd.h> int main(int argc, char *argv[]) { execvp(argv[1], &argv[1]); return 127; } $ gcc wrap.c -o wrap $ LD_SHOW_AUXV=1 ./wrap ./wrap true |& grep AT_BASE AT_BASE: 0x7f63b8309000 AT_BASE: 0x7faec143c000 AT_BASE: 0x7fbdb25fa000 $ gcc -m32 wrap.c -o wrap32 $ LD_SHOW_AUXV=1 ./wrap32 ./wrap true |& grep AT_BASE AT_BASE: 0xf7eff000 AT_BASE: 0xf7cee000 AT_BASE: 0x7f8b9774e000 On kernels before the referenced commit the second AT_BASE is at the same range as the third one. The consequences: 1) It breaks ASAN $ gcc -fsanitize=address wrap.c -o wrap-asan $ ./wrap32 ./wrap-asan true ==1217==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==1217==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range. ==1217==Process memory map follows: 0x000000400000-0x000000401000 /home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan 0x000000600000-0x000000601000 /home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan 0x000000601000-0x000000602000 /home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan 0x0000f7dbd000-0x0000f7de2000 /lib64/ld-2.27.so 0x0000f7fe2000-0x0000f7fe3000 /lib64/ld-2.27.so 0x0000f7fe3000-0x0000f7fe4000 /lib64/ld-2.27.so 0x0000f7fe4000-0x0000f7fe5000 0x7fed9abff000-0x7fed9af54000 0x7fed9af54000-0x7fed9af6b000 /lib64/libgcc_s.so.1 [snip] 2) It doesn't seem to be great for security if an attacker always knows that ld.so is going to be mapped into the first 4GB in this case (the same thing happens for PIEs as well). Am I right that this is not the intended behavior? -Alexey ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process 2018-05-17 20:16 [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process Alexey Izbyshev @ 2018-05-17 20:46 ` Andy Lutomirski 2018-05-17 20:50 ` Dmitry Safonov 2018-05-17 20:53 ` Alexander Monakov 0 siblings, 2 replies; 7+ messages in thread From: Andy Lutomirski @ 2018-05-17 20:46 UTC (permalink / raw) To: izbyshev Cc: Dmitry Safonov, Thomas Gleixner, Andrew Lutomirski, Cyrill Gorcunov, Borislav Petkov, Kirill A. Shutemov, Alexander Monakov, Linux-MM On Thu, May 17, 2018 at 1:25 PM Alexey Izbyshev <izbyshev@ispras.ru> wrote: > Hello everyone, > I've discovered the following strange behavior of a 4.15.13-based kernel > (bisected to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b028f784e8c341e762c264f70dc0ca1418c8b7a > between 4.11-rc2 and -rc3 thanks to Alexander Monakov). It's definitely not intended. Can you confirm that the problem still exists in 4.16? I have some vague recollection that this was a known issue that got fixed, and we could plausibly just be missing a backport. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process 2018-05-17 20:46 ` Andy Lutomirski @ 2018-05-17 20:50 ` Dmitry Safonov 2018-05-17 21:07 ` Andy Lutomirski 2018-05-17 20:53 ` Alexander Monakov 1 sibling, 1 reply; 7+ messages in thread From: Dmitry Safonov @ 2018-05-17 20:50 UTC (permalink / raw) To: Andy Lutomirski Cc: izbyshev, Dmitry Safonov, Thomas Gleixner, Cyrill Gorcunov, Borislav Petkov, Kirill A. Shutemov, Alexander Monakov, Linux-MM 2018-05-17 21:46 GMT+01:00 Andy Lutomirski <luto@kernel.org>: > On Thu, May 17, 2018 at 1:25 PM Alexey Izbyshev <izbyshev@ispras.ru> wrote: > >> Hello everyone, > >> I've discovered the following strange behavior of a 4.15.13-based kernel >> (bisected to > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b028f784e8c341e762c264f70dc0ca1418c8b7a >> between 4.11-rc2 and -rc3 thanks to Alexander Monakov). > > > It's definitely not intended. Can you confirm that the problem still > exists in 4.16? I have some vague recollection that this was a known issue > that got fixed, and we could plausibly just be missing a backport. I'm looking into that ATM, the problem like that was fixed with https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ada26481dfe6 Will check what's happening there. Thanks, Dmitry ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process 2018-05-17 20:50 ` Dmitry Safonov @ 2018-05-17 21:07 ` Andy Lutomirski 2018-05-17 21:11 ` Dmitry Safonov 0 siblings, 1 reply; 7+ messages in thread From: Andy Lutomirski @ 2018-05-17 21:07 UTC (permalink / raw) To: Dmitry Safonov Cc: Andrew Lutomirski, izbyshev, Dmitry Safonov, Thomas Gleixner, Cyrill Gorcunov, Borislav Petkov, Kirill A. Shutemov, Alexander Monakov, Linux-MM On Thu, May 17, 2018 at 1:51 PM Dmitry Safonov <0x7f454c46@gmail.com> wrote: > 2018-05-17 21:46 GMT+01:00 Andy Lutomirski <luto@kernel.org>: > > On Thu, May 17, 2018 at 1:25 PM Alexey Izbyshev <izbyshev@ispras.ru> wrote: > > > >> Hello everyone, > > > >> I've discovered the following strange behavior of a 4.15.13-based kernel > >> (bisected to > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b028f784e8c341e762c264f70dc0ca1418c8b7a > >> between 4.11-rc2 and -rc3 thanks to Alexander Monakov). > > > > > > It's definitely not intended. Can you confirm that the problem still > > exists in 4.16? I have some vague recollection that this was a known issue > > that got fixed, and we could plausibly just be missing a backport. > I'm looking into that ATM, the problem like that was fixed with https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ada26481dfe6 > Will check what's happening there. I haven't tried to figure out exactly what code calls which function, but it seems like set_personality_64bit() really ought to clear TS_COMPAT. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process 2018-05-17 21:07 ` Andy Lutomirski @ 2018-05-17 21:11 ` Dmitry Safonov 2018-05-17 21:19 ` Alexey Izbyshev 0 siblings, 1 reply; 7+ messages in thread From: Dmitry Safonov @ 2018-05-17 21:11 UTC (permalink / raw) To: Andy Lutomirski Cc: izbyshev, Dmitry Safonov, Thomas Gleixner, Cyrill Gorcunov, Borislav Petkov, Kirill A. Shutemov, Alexander Monakov, Linux-MM 2018-05-17 22:07 GMT+01:00 Andy Lutomirski <luto@kernel.org>: > On Thu, May 17, 2018 at 1:51 PM Dmitry Safonov <0x7f454c46@gmail.com> wrote: > >> 2018-05-17 21:46 GMT+01:00 Andy Lutomirski <luto@kernel.org>: >> > On Thu, May 17, 2018 at 1:25 PM Alexey Izbyshev <izbyshev@ispras.ru> > wrote: >> > >> >> Hello everyone, >> > >> >> I've discovered the following strange behavior of a 4.15.13-based > kernel >> >> (bisected to >> > >> > >> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b028f784e8c341e762c264f70dc0ca1418c8b7a >> >> between 4.11-rc2 and -rc3 thanks to Alexander Monakov). >> > >> > >> > It's definitely not intended. Can you confirm that the problem still >> > exists in 4.16? I have some vague recollection that this was a known > issue >> > that got fixed, and we could plausibly just be missing a backport. > >> I'm looking into that ATM, the problem like that was fixed with > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ada26481dfe6 > >> Will check what's happening there. > > I haven't tried to figure out exactly what code calls which function, but > it seems like set_personality_64bit() really ought to clear TS_COMPAT. Ugh, yeah, the same way __set_personality_x32(). Will test it and prepare a patch for that Cc'ing stable. Thanks, Alexey, Andy! Sorry about asan breakage, Dmitry ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process 2018-05-17 21:11 ` Dmitry Safonov @ 2018-05-17 21:19 ` Alexey Izbyshev 0 siblings, 0 replies; 7+ messages in thread From: Alexey Izbyshev @ 2018-05-17 21:19 UTC (permalink / raw) To: Dmitry Safonov Cc: Andy Lutomirski, Dmitry Safonov, Thomas Gleixner, Cyrill Gorcunov, Borislav Petkov, Kirill A. Shutemov, Alexander Monakov, Linux-MM On 2018-05-18 00:11, Dmitry Safonov wrote: > 2018-05-17 22:07 GMT+01:00 Andy Lutomirski <luto@kernel.org>: >> On Thu, May 17, 2018 at 1:51 PM Dmitry Safonov <0x7f454c46@gmail.com> >> wrote: >> >>> 2018-05-17 21:46 GMT+01:00 Andy Lutomirski <luto@kernel.org>: >>> > On Thu, May 17, 2018 at 1:25 PM Alexey Izbyshev <izbyshev@ispras.ru> >> wrote: >>> > >>> >> Hello everyone, >>> > >>> >> I've discovered the following strange behavior of a 4.15.13-based >> kernel >>> >> (bisected to >>> > >>> > >>> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b028f784e8c341e762c264f70dc0ca1418c8b7a >>> >> between 4.11-rc2 and -rc3 thanks to Alexander Monakov). >>> > >>> > >>> > It's definitely not intended. Can you confirm that the problem still >>> > exists in 4.16? I have some vague recollection that this was a known >> issue >>> > that got fixed, and we could plausibly just be missing a backport. >> >>> I'm looking into that ATM, the problem like that was fixed with >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ada26481dfe6 >> >>> Will check what's happening there. >> >> I haven't tried to figure out exactly what code calls which function, >> but >> it seems like set_personality_64bit() really ought to clear TS_COMPAT. > > Ugh, yeah, the same way __set_personality_x32(). > Will test it and prepare a patch for that Cc'ing stable. > > Thanks, Alexey, Andy! > Thanks, Dmitry, Andy for the quick investigation, and Alexander for the confirmation! -Alexey ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process 2018-05-17 20:46 ` Andy Lutomirski 2018-05-17 20:50 ` Dmitry Safonov @ 2018-05-17 20:53 ` Alexander Monakov 1 sibling, 0 replies; 7+ messages in thread From: Alexander Monakov @ 2018-05-17 20:53 UTC (permalink / raw) To: Andy Lutomirski Cc: izbyshev, Dmitry Safonov, Thomas Gleixner, Cyrill Gorcunov, Borislav Petkov, Kirill A. Shutemov, Linux-MM On Thu, 17 May 2018, Andy Lutomirski wrote: > It's definitely not intended. Can you confirm that the problem still > exists in 4.16? I have some vague recollection that this was a known issue > that got fixed, and we could plausibly just be missing a backport. I could reproduce it on 4.16.0 on my laptop. Alexander ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-05-17 21:19 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-17 20:16 [4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process Alexey Izbyshev 2018-05-17 20:46 ` Andy Lutomirski 2018-05-17 20:50 ` Dmitry Safonov 2018-05-17 21:07 ` Andy Lutomirski 2018-05-17 21:11 ` Dmitry Safonov 2018-05-17 21:19 ` Alexey Izbyshev 2018-05-17 20:53 ` Alexander Monakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).