Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

2018-01-28 Thread Konrad Witaszczyk 
On 01/28/2018 22:28, Warner Losh wrote:
> On Sun, Jan 28, 2018 at 2:22 PM, thomas masper 
> wrote:
> 
>> Hi,
>> similar panic happen to me when extracting a pendrive from laptop USB port
>> (I tried 3 different pendrive).
>> No issue if I reboot or shutdown. I don't know if those two issues are
>> related.
>>
> 
> Do you have a reproducible test case? Ideally, it would be 'insert and
> remove usb thumb drive' but maybe there's more steps between insert and
> removal.
> 
> Warner

I hit the same problem after upgrading to r328500. I booted my laptop from a
pendrive, got a GELI password prompt, removed the pendrive, typed in a GELI
password and then I got the kernel panic. Removing the pendrive at an earlier
stage is a workaround for me at the moment.

>> panic: Releasing 6 with cnt = -559038242
>>
>> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later > html
>>>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-portbld-freebsd12.0".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /boot/kernel/kernel...Reading symbols from
>> /usr/lib/debug//boot/kernel/kernel.debug...done.
>> done.
>>
>> Unread portion of the kernel message buffer:
>> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
>> da0:   s/n 30E47C20 detached
>> (da0:umass-sim0:0:0:0): Periph destroyed
>> panic: Releasing 6 with cnt = -559038242
>> cpuid = 0
>> time = 1517158352
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe00593838c0
>> vpanic() at vpanic+0x18d/frame 0xfe0059383920
>> panic() at panic+0x43/frame 0xfe0059383980
>> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
>> g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe00593839d0
>> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe00593839f0
>> g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
>> g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
>> fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> KDB: enter: panic
>>
>> __curthread () at ./machine/pcpu.h:229
>> 229 __asm("movq %%gs:%1,%0" : "=r" (td)
>> (kgdb) #0  __curthread () at ./machine/pcpu.h:229
>> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
>> #2  0x8040a08b in db_dump (dummy=,
>> dummy2=, dummy3=, dummy4=)
>> at /usr/src/sys/ddb/db_command.c:574
>> #3  0x80409e59 in db_command (last_cmdp=,
>> cmd_table=, dopager=)
>> at /usr/src/sys/ddb/db_command.c:481
>> #4  0x80409bd4 in db_command_loop ()
>> at /usr/src/sys/ddb/db_command.c:534
>> #5  0x8040cdff in db_trap (type=, code=> out>)
>> at /usr/src/sys/ddb/db_main.c:250
>> #6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf=> out>)
>> at /usr/src/sys/kern/subr_kdb.c:697
>> #7  0x80f7b498 in trap (frame=0xfe00593837f0)
>> at /usr/src/sys/amd64/amd64/trap.c:547
>> #8  
>> #9  kdb_enter (why=0x811f101e "panic", msg=)
>> at /usr/src/sys/kern/subr_kdb.c:479
>> #10 0x80ac8d3a in vpanic (fmt=,
>> ap=0xfe0059383960)
>> at /usr/src/sys/kern/kern_shutdown.c:800
>> #11 0x80ac8dc3 in panic (
>> fmt=0x81b1bbd8  "\257\257\033\201\377\377\377\
>> 377")
>> at /usr/src/sys/kern/kern_shutdown.c:738
>> #12 0x80368bb2 in da_periph_release (periph=,
>> token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
>> #13 dadiskgonecb (dp=) at
>> /usr/src/sys/cam/scsi/scsi_da.c:1904
>> #14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_disk.c:783
>> #15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_subr.c:746
>> #16 0x80a15e17 in g_wither_washer ()
>> at /usr/src/sys/geom/geom_subr.c:461
>> #17 0x80a112da in g_run_events ()
>> at /usr/src/sys/geom/geom_event.c:297
>> #18 0x80a89444 in fork_exit (
>> callout=0x80a138c0 , arg=0x0,
>> frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
>> #19 
>> (kgdb)
>>
>>
>> uname -a
>> FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
>> r328509M: Sun Jan 28 15:38:35 CET 2018
>>

[CFT] Encrypted kernel crash dumps.

2016-08-24 Thread Konrad Witaszczyk 
Dear FreeBSD Community,

I would like to ask you for help with testing encrypted kernel crash dumps.
The current patch can be downloaded from Phabricator [1].

You can read more about the feature in the review [2] and in the previous
message posted to freebsd-security [3]. Below you can find a description of four
tests. Please note that the tests will cause a panic and you may lose your data
so do not perform them on a production machine. EKCD should work with mini dumps
and full dumps on all architectures supporting them. Encrypted textdumps are not
supported. I managed to successfully test EKCD on my laptop running amd64 and on
arm64 (only minidump), i386 using QEMU.

First two tests require a kernel compiled with the EKCD kernel option and RSA
keys which will be used to encrypt and decrypt core dump keys. The RSA keys can
be generated in the following way:
# openssl genrsa -out /etc/private.pem 4096
# openssl rsa -in /etc/private.pem -out /etc/public.pem -pubout

1. Encryped minidump:
# dumpon -k /etc/public.pem /dev/dumpdevice
# sysctl debug.minidump=1
# sysctl debug.kdb.panic=1
db> call doadump(0)
db> reset
# savecore /var/crash /dev/dumpdevice
# decryptcore -p /etc/private.pem -n NR
# kgdb -n NR /path/to/kernel

2. Encrypted full dump:
# dumpon -k /etc/public.pem /dev/dumpdevice
# sysctl debug.minidump=0
# sysctl debug.kdb.panic=1
db> call doadump(0)
db> reset
# savecore /var/crash /dev/dumpdevice
# decryptcore -p /etc/private.pem -n NR
# kgdb -n NR /path/to/kernel

The next two tests should be performed using a kernel compiled with the EKCD
kernel option and also using a kernel compiled without the EKCD option:

3. Minidump:
# dumpon /dev/dumpdevice
# sysctl debug.minidump=1
# sysctl debug.kdb.panic=1
db> call doadump(0)
db> reset
# savecore /var/crash /dev/dumpdevice
# kgdb -n NR /path/to/kernel

4. Full dump:
# dumpon /dev/dumpdevice
# sysctl debug.minidump=0
# sysctl debug.kdb.panic=1
db> call doadump(0)
db> reset
# savecore /var/crash /dev/dumpdevice
# kgdb -n NR /path/to/kernel

NR is the number of the core dump saved by savecore(8). The test is successful
if kgdb can read the core dump. You can read more about above steps in
dumpon(8), savecore(8) and decryptcore(8).

Thanks!

[1] https://reviews.freebsd.org/D4712?download=true
[2] https://reviews.freebsd.org/D4712
[3] 
https://lists.freebsd.org/pipermail/freebsd-security/2015-December/008780.html


Best regards,
Konrad Witaszczyk
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"