Re: Troubles building world on stable/13 [Try sysctl kern.elf64.aslr.enable=0 for avoiding SIGSEGV using your stable/13 c++ compiler on RPi3*]

Note: The experiments reported are from a .sh/.cpp
pair produced by system clang++ (a.k.a. c++) that
is used to repeat the problem without doing a
buidlworld .


In my context, using a main [so: 14] kernel and your stable/13 c++
(system clang++), I get:

A) sysctl kern.elf64.aslr.enable=1 leads to later tries sometimes/usually failing
vs.
B) sysctl kern.elf64.aslr.enable=0 has so far lead to later tries working

This is with kern.elf64.aslr.stack_gap being 0 without
my having set it.

WARNING: Doing (B) may have security implications.

stable/13 also has kern.elf64.aslr.enable and the like
from what I can tell. You can let me know if you get
any .sh/.cpp pair(s) failing vs. if all tries work.

I found this by noticing that:

sysctl -a vm.aslr_restarts

was usually incrementing by 2 during the .sh/.cpp runs.

For reference:

# sysctl -ad vm.aslr_restarts
vm.aslr_restarts: Number of aslr failures

Something like:

# ./c++ -v

it got an increment of 1.

Something like:

# date

it got no increment.

I suspect only large processes would get failures,
especially double failures (or more).

It might be that a debug kernel would panic, reporting
a try count that was no longer <= 2 if some of the code
I saw is currently in use in the kernels. I'm running a
non-debug kernel and, so, do not see the KASSERT
related behavior.


I do not have detailed knowledge of how the failure
works. I'd guess some sort of stack-growth related
problem that is leading to corrupted register content
afterwards.

===
Mark Millard
marklmi at yahoo.com