Re: port-amd64/58366: KASLR broken

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

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