Re: build-success/install-fault on i486 with xsrc

[maya%NetBSD.org@localhost]

On Tue, Oct 27, 2020 at 10:57:28PM +0100, Miranda van den Breukelingen wrote:
> as driving to current the dell vostro 14 compiled 22 hours on the userland and 
> 28 hours on the xsrc: no build-failure with the kernel, too. 
> 
> installed it with ./build.sh -u -U install=/ I get a fine install but on 
> postinstall it tells me /usr/src/sbin/postinstall/postinstall is not 
> available. I checked and fixed it manually with the new build postinstall; so 
> no comment. 
> 
> after reboot with the new kernel I have problems with the X-driver; 
> Doing an X -configure brings me:
> 
> libGL.so.3 text relocations
> libGL.so3 cannot write enable text sements: permission deniend
> 
> same with xinit and startx (exec xfce4-session in .xinitrc)
> 
> it's llvm10; I 'chmod 777 /dev/dri/card*' and rebuild xorg-server-libs; no 
> success. do I need compiler FLAGS for the xsrc with the postinstall-problem, 
> too? does compiling with CLANG help?
> 
> miranda
> 
> 

Background story. Skip to last paragraph for actual tips.

Text segment in ELF: the code that is executed (requires execute
permissions)
write-enabling: making it possible to write

This fails because by default, having both write and execute permissions
is not allowed, for security reasons.

Memory that is both writable and executable is an easy exploit target.
Given a memory overflow vulnerability, write your desired malicious
code to this memory, and overwrite where the last return address is
saved so after the function returns, your malicious code runs.

The name of the tunable for this in NetBSD is "PaX mprotect", and the
sysctl for it is security.pax.mprotect.enabled.

It can disabled on a per-binary basis with `paxctl +m /path/to/binary`.
This is a bit tricky for libGL.so as it is used by many binaries.

Some type of code (hand written assembly, or code built without -fPIC)
requires this, usually for a thing called a "text relocation". A
relocation is "offset rewritten at runtime to an external library" and
as we already said, "text" is the code segment.
This relocation lives in the wrong place, because we don't want to ever
write to the section that is already executable.
But if we see this, we try to enable writing first, and when that fails,
we output "cannot write-enable text segment".

The moral of the story, likely rebuild your libGL objects with -fPIC, or
take a hit to your security and save time on rebuilding with
sysctl -w security.pax.mprotect.enabled=0.