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: Sat, 29 Jun 2024 13:47:05 +0200

 On Thu, Jun 27, 2024 at 11:20:02PM +0000, Taylor R Campbell wrote:
 >  > Date: Thu, 27 Jun 2024 20:36:34 +0200
 >  > From: Harold Gutch <logix%foobar.franken.de@localhost>
 >  > 
 >  > On Tue, Jun 25, 2024 at 06:05:01PM +0000, Taylor R Campbell wrote:
 >  > >  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.
 >  
 >  Bizarre!
 >  
 >  Can you:
 >  
 >  1. update to the snprintb change,
 >  2. apply the pmap directmap patch I attached earlier,
 >  3. put db_stacktrace() (#include <ddb/ddb.h>) at the top of snprintb_m,
 >  and
 >  4. share dmesg when it panics?
 
 I get one stacktrace:
 
 [   1.0216565] wm0 at pci0 dev 3 function 0: Intel i82540EM 1000BASE-T Ethernet (rev. 0x03)
 [   1.0216565] wm0: interrupting at ioapic0 pin 11
 [   1.0216565] wm0: Ethernet address 52:54:00:12:34:56
 [   1.0216565] wm_attach() at netbsd:wm_attach+0x35d7
 [   1.0216565] config_attach_internal() at netbsd:config_attach_internal+0x1a7
 [   1.0216565] config_found_acquire() at netbsd:config_found_acquire+0xd9
 [   1.0216565] config_found() at netbsd:config_found+0x32
 [   1.0216565] pci_probe_device() at netbsd:pci_probe_device+0x661
 [   1.0216565] pci_enumerate_bus() at netbsd:pci_enumerate_bus+0x1a4
 [   1.0216565] pcirescan() at netbsd:pcirescan+0x4e
 [   1.0216565] pciattach() at netbsd:pciattach+0x186
 [   1.0216565] config_attach_internal() at netbsd:config_attach_internal+0x1a7
 [   1.0216565] config_found_acquire() at netbsd:config_found_acquire+0xd9
 [   1.0216565] config_found() at netbsd:config_found+0x32
 [   1.0216565] mp_pci_scan() at netbsd:mp_pci_scan+0xd6
 [   1.0216565] amd64_mainbus_attach() at netbsd:amd64_mainbus_attach+0x361
 [   1.0216565] config_attach_internal() at netbsd:config_attach_internal+0x1a7
 [   1.0216565] config_attach() at netbsd:config_attach+0x53
 [   1.0216565] config_rootfound() at netbsd:config_rootfound+0x45
 [   1.0216565] cpu_configure() at netbsd:cpu_configure+0x38
 [   1.0216565] main() at netbsd:main+0x326
 [   1.0216565] start_prekern() at netbsd:start_prekern+0xf5
 [   1.0216565] ?() at 100641
 [   1.0216565] makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev.  0
 [   1.0216565] makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
 
 After a bit of extra printf() debugging I no longer think it is this
 commit that is responsible.  It seems that when bisecting I ended up
 getting "unlucky" and just so happened to not trigger this.  I am
 sitting right now in a ddb coming from *before* the snprintb() change
 but with your pmap changes.
 
 Back to the bisecting board...
 
 
 thanks,
   Harold