Re: Troubles building world on stable/13 [How to set just the compiler to avoid ASLR being enabled for it: DOES NOT WORK]

On 2022-Feb-4, at 17:34, Mark Millard <[email protected]> wrote:

> The following shows how to examine and control the compiler's ASLR
> status (notation shown presumes first cd'ing to where the c++ file
> is):
> 
> # elfctl c++
> File 'c++' features:
> noaslr          'Disable ASLR' is unset.
> noprotmax       'Disable implicit PROT_MAX' is unset.
> nostackgap      'Disable stack gap' is unset.
> wxneeded        'Requires W+X mappings' is unset.
> la48            'amd64: Limit user VA to 48bit' is unset.
> noaslrstkgap    'Disable ASLR stack gap' is unset.
> 
> # elfctl -e +noaslr c++
> 
> # elfctl c++
> File 'c++' features:
> noaslr          'Disable ASLR' is set.
> noprotmax       'Disable implicit PROT_MAX' is unset.
> nostackgap      'Disable stack gap' is unset.
> wxneeded        'Requires W+X mappings' is unset.
> la48            'amd64: Limit user VA to 48bit' is unset.
> noaslrstkgap    'Disable ASLR stack gap' is unset.
> 
> (noaslrstkgap may be fairly specific to the vintage of
> main [so: 14] that I'm at and so might not show up.)
> 
> Being tied to the file, this survives reboots.
> 
> This should avoid needing the system wide disable
> that I'd previously listed. In other words: no need
> for:
> 
> # sysctl kern.elf64.aslr.enable=0
> 
> (which would not survive a reboot).
> 

Well, on testing, this did not work in my context:
still can fail and still shows vm.aslr_restarts
increasing the same way as before I updated the
c++ file: success increments by 1 and failure
increments by 2.

So I'm back to indicating to use:

# sysctl kern.elf64.aslr.enable=0

===
Mark Millard
marklmi at yahoo.com