Date: Fri, 4 Feb 2022 01:19:39 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: 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*] Message-ID: <CCD77D18-5DAE-441D-9CC5-229B8E172A79@yahoo.com> In-Reply-To: <9787056B-D173-460A-821C-1386F7F2D5EC@yahoo.com> References: <FA290367-D4B6-463D-AC67-64F224B3C227@yahoo.com> <FBD31544-6D8F-40DB-BC36-F0B2BBA78A14@yahoo.com> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <D93232D9-BCBF-4C65-B984-D95CB12ADFCD@yahoo.com> <20220203230428.GA81336@www.zefox.net> <9787056B-D173-460A-821C-1386F7F2D5EC@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D1 leads to later tries = sometimes/usually failing vs. B) sysctl kern.elf64.aslr.enable=3D0 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 <=3D 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CCD77D18-5DAE-441D-9CC5-229B8E172A79>