Re: port-amd64/58366: KASLR broken

[Harold Gutch <logix%foobar.franken.de@localhost>]

The following reply was made to PR port-amd64/58366; it has been noted by GNATS.

From: Harold Gutch <logix%foobar.franken.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: port-amd64-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: port-amd64/58366: KASLR broken
Date: Thu, 27 Jun 2024 20:36:34 +0200

 Hi,
 
 On Tue, Jun 25, 2024 at 06:05:01PM +0000, Taylor R Campbell wrote:
 > The following reply was made to PR port-amd64/58366; it has been noted by GNATS.
 > 
 > From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
 > To: Harold Gutch <logix%foobar.franken.de@localhost>
 > Cc: gnats-bugs%NetBSD.org@localhost, port-amd64-maintainer%NetBSD.org@localhost,
 > 	gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
 > Subject: Re: port-amd64/58366: KASLR broken
 > Date: Tue, 25 Jun 2024 18:03:39 +0000
 > 
 >  > Date: Tue, 25 Jun 2024 18:07:44 +0200
 >  > From: Harold Gutch <logix%foobar.franken.de@localhost>
 >  >=20
 >  > On Tue, Jun 25, 2024 at 01:36:07PM +0000, Taylor R Campbell wrote:
 >  > > Can you please try the attached patch?
 >  >=20
 >  > Thanks, that gets past prekern but then panics:
 >  >=20
 >  > [   1.4884345] trap type 4 code 0 rip 0xffffffffacefd336 cs 0x8 rflags 0x=
 >  246 cr2 0 ilevel 0x6 rsp 0xffffffffe9e85a80
 >  > [   1.5005255] curlwp 0xffffffffa0be8480 pid 0.0 lowest kstack 0xffffffff=
 >  e9e812c0
 >  > kernel: protection fault trap, code=3D0
 >  > Stopped in pid 0.0 (system) at  netbsd:aes_sse2_selftest+0xb9:  ???
 >  > aes_sse2_selftest() at netbsd:aes_sse2_selftest+0xb9
 >  
 >  Can you try the patch on top of the first revision you found with
 >  broken prekern?
 >  
 >  If that works, time for another round of bisection, I guess!
 
 I am not 100% sure, but it might be
 https://mail-index.netbsd.org/source-changes/2024/03/25/msg150542.html
 , however I don't see where aes_sse2_selftest() or 
 aes_sse2_xts_update_selftest() might be calling snprintb().
 
 There might also be some undefined behavior involved somewhere as not
 every boot panics - it's hard to say how often it happens, but I'd put
 it at around p=50%.  With a source tree from just before that change I
 have so far not encountered this panic a single time.
 
 So, I'd say your patch has improved things but the snprintb() issue
 also needs to be addressed.
 
 
 thanks,
   Harold