A fresh 5.0 i386 panics with MKPIE

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

Hi,

a fresh i386 5.0_STABLE panics very early on when the userland is built with
MKPIE=yes. More specifically, the problem is with init(8).

Quickly copied by hand:

...
Kernelized RAIDframe activated
pad0: outputs: 44100Hz, 16-bit, stereo
audio1 at pad0: half duplex
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
panic: init died (signal 0, exit 1)
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip 056904c cs 8 eflags 246 cr2 bbbce0d4 ilevel 0
Stopped in pid 1.1 (init) at netbsd:breakpoint+0x4: popl %epb
db{0}> bt
breakpoint(c0a8b6ea,cb3a9c58,c0ab3500,cbc2ef80,ffffffed,1,cbc2ef80,c047606b,0,
cbc2ef80) at netbsd:breakpoint+0x4
panic(c0a4c5cc,0,1,20,cbc28b28,ca9b8ce8,2,0,5,cbc25c00) at netbsd:panic+0x1b0
exit1(ca9b7d00,100,cbc2ef80,ca9b7d00,ca9b7d00,c0aae58c,cb3a9d3c,c05722fd,ca9b7d00,cb3a9d00)
at netbsd: exit1+0x7f1
sys_exit(ca9b7d00,cb3a9d00,cb3a9d28,1,bbbeb000,bbbfee60,bbbfa5fa1,ffffff,0,1)
at netbsd:sys_exit+0c4d
syscall(cb3a9d48,b3,ab,1f,bfbf001f,bbbbeb000,bbbff5c0,bbbff6b8,bbbfee60,ffffff)
at netbsd:syscall+0xbd
db{0}>

Copying init from a backup gave:

Shared object "libgcc_s.so.1" not found
Enter pathname of shell or return for /bin/sh:

Which is quite natural for a position independent executable against the
unfortunate fact that I had /usr on cgd(4). So I went back to the
restore-phase and copied libgcc* to the empty /usr/lib. This gave a normal
boot and a working PIE-system with X11 and non-PIE init.

So any idea what could be wrong with init?

* * *

I take this opportunity to note also what is needed to build a fully
"hardened" i386 system with MKX11=yes, X11_TYPE?=native, MKPIE=yes,
USE_SSP=yes and USE_FORT=yes:

(1) USE_FORT=no to  /usr/src/external/mit/xorg/lib/freetype/Makefile
(2) USE_FORT=no to  /usr/src/external/mit/xorg/lib/fontconfig/src/Makefile
(3) MKPIE=no    to  /usr/src/external/mit/xorg/bin/xman/Makefile
(4) MKPIE=no    to  /usr/src/external/mit/xorg/lib/libOSMesa/Makefile

The (1) was addressed in PR #40503, but no pullup was done for 5.0. The (3)
is needed because xman(1) is stupid enough to "#define PIC" for internal
use. I do not know if (4) is really relevant, but I added it from old habit
coming from experiences with other operating systems.


- Jukka.