On Sun, 9 Apr 2023, Michael Schmitz wrote:
Am 09.04.2023 um 16:42 schrieb Finn Thain:
On Sun, 9 Apr 2023, Michael Schmitz wrote:
The only way I have found to alter dash's inclination to crash is to
reboot. (I said previously I was unable to reproduce this in a
single user mode shell but it turned out to be more subtle.)
I wonder what could change from one boot to another - can you have
dash (and its subshells) dump /proc/self/maps and see whether there's
any variation in that? But what we really need is the physical
mappings. How can we find those?
With the kernel RNG disabled, I would expect neither of these
mappings to change between boots?
It looks like the stack area still changes across invocations:
Yep, but running the same commands in the same order across different
boots, does it still change?
(I'm making a huge assumption here - that timing of the boot process and
hence evolution of the kernel RNG is sufficiently deterministic. And
this might apply only to the shells run from sysvinit, since that does
require no keyboard input ...)
Looks like cat < /proc/self/maps | grep stack would give us enough
information without overwhelming the serial console?
OTOH - if you can show the error is gone without stack address
randomization, that would be a hint maybe?
The results below were produced with 'norandmaps' added to the kernel
parameters to avoid ASLR.
root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
root@debian:~# echo 3 > /proc/sys/vm/drop_caches
[ 913.560000] bash (1024): drop_caches: 3
root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
*** stack smashing detected ***: terminated
Aborted (core dumped)
root@debian:~# sh -c "md5sum < /proc/self/maps"
baacbaf944fb01d3200d924da7f7a815 -
root@debian:~# sh -c "md5sum < /proc/self/maps"
baacbaf944fb01d3200d924da7f7a815 -
root@debian:~# sh -c "md5sum < /proc/self/maps"
baacbaf944fb01d3200d924da7f7a815 -
root@debian:~# sh -c "md5sum < /proc/self/maps"
baacbaf944fb01d3200d924da7f7a815 -
root@debian:~# sh -c "cat < /proc/self/maps"
c0000000-c0021000 r-xp 00000000 08:06 38780 /usr/lib/m68k-linux-gnu/ld.so.1
c0021000-c0023000 rw-p 00000000 00:00 0
c0023000-c0024000 r--p 00021000 08:06 38780 /usr/lib/m68k-linux-gnu/ld.so.1
c0024000-c0026000 rw-p 00022000 08:06 38780 /usr/lib/m68k-linux-gnu/ld.so.1
c002a000-c0199000 r-xp 00000000 08:06 38786 /usr/lib/m68k-linux-gnu/libc.so.6
c0199000-c019a000 ---p 0016f000 08:06 38786 /usr/lib/m68k-linux-gnu/libc.so.6
c019a000-c019c000 r--p 00170000 08:06 38786 /usr/lib/m68k-linux-gnu/libc.so.6
c019c000-c01a0000 rw-p 00172000 08:06 38786 /usr/lib/m68k-linux-gnu/libc.so.6
c01a0000-c01aa000 rw-p 00000000 00:00 0
d0000000-d0019000 r-xp 00000000 08:06 32713 /usr/bin/dash
d001b000-d001c000 r--p 00019000 08:06 32713 /usr/bin/dash
d001c000-d001d000 rw-p 0001a000 08:06 32713 /usr/bin/dash
d001d000-d001f000 rwxp 00000000 00:00 0 [heap]
d001f000-d0040000 rwxp 00000000 00:00 0 [heap]
effdf000-f0000000 rw-p 00000000 00:00 0 [stack]
So I guess this bug has more to do with timing and little to do with
state, contrary to my guesswork above. And no doubt I will have to
contradict myself again if/when it turns out that uninitialized memory is
a factor :-/
