Re: Does audit work on stable/12? Audit-related panic on latest stable/12

From: Lev Serebryakov <lev_at_FreeBSD.org>
Date: Tue, 19 Oct 2021 08:35:51 UTC
On 19.10.2021 7:36, Alan Somers wrote:

>>    I've upgraded one of my servers from 11.4 to latest stable/12. This server is unique in me fleet because it has audit (and auditd) enabled.
>>
>>    First of all, right after (source-based, buildworld & Ko) upgrade dmesg becomes flooded with:
>>
>> BSM conversion requested for unknown event 43224
>> BSM conversion requested for unknown event 43225
>> BSM conversion requested for unknown event 43234
>> BSM conversion requested for unknown event 43238
>>
>>     And after several minutes of work I've got panic:
>>
>> Sleeping thread (tid 101199, pid 51147) owns a non-sleepable lock
>> BSM conversion requested for unknown event 43224
>> KDB: stack backtrace of thread 101199:
>> #0 0xffffffff804d0f34 at mi_switch+0xd4
>> BSM conversion requested for unknown event 43224
>> BSM conversion requested for unknown event 43224
>> #1 0xffffffff8051ca2c at sleepq_wait+0x2c
>> #2 0xffffffff80467d62 at _cv_wait+0xf2
>> #3 0xffffffff80719573 at audit_commit+0x243
>> #4 0xffffffff80719866 at audit_syscall_exit+0x26
>> #5 0xffffffff804d7f8a at kern_thr_exit+0x14a
>> #6 0xffffffff804d7e37 at sys_thr_exit+0x67
>> #7 0xffffffff807a1557 at amd64_syscall+0x387
>> #8 0xffffffff8077a7ae at fast_syscall_common+0xf8
>> panic: sleeping thread
>> cpuid = 6
>> time = 1634604615
>> KDB: stack backtrace:
>> #0 0xffffffff8050e925 at kdb_backtrace+0x65
>> #1 0xffffffff804c5bcb at vpanic+0x17b
>> #2 0xffffffff804c5a43 at panic+0x43
>> #3 0xffffffff80523702 at propagate_priority+0x282
>> #4 0xffffffff805242cc at turnstile_wait+0x30c
>> #5 0xffffffff804abd29 at __mtx_lock_sleep+0x199
>> #6 0xffffffff804d7ec2 at kern_thr_exit+0x82
>> #7 0xffffffff804d7e37 at sys_thr_exit+0x67
>> #8 0xffffffff807a1557 at amd64_syscall+0x387
>> #9 0xffffffff8077a7ae at fast_syscall_common+0xf8
>>
>>
>>     Now, I've turned off auditd and server looks Ok (at least, it is stable for 30 minutes). But I need audit on this server. Is it known problem? Is it configuration problem?
> 
> audit has at least some coverage in CI, but apparently not enough.
> Would you share your /etc/security configuration?  Event 43224 is
   /etc/security was merged from my old (stable/11 era) config by `mergemaster`. Here result is:

audit_control:
#
# $FreeBSD$
#
host:<ip redacted>
dir:/var/audit
minfree:5
dist:off
flags:lo,aa,fc,-fd,fw,pc,nt,ex
naflags:lo,aa,fc,-fd,fw,pc,nt,ex
policy:cnt,argv
filesz:200M
expire-after:356d OR 50G

audit_user:
#
# $FreeBSD$
#
root:lo:no
daemon::+fw,+fc,+fd
operator::+fw,+fc,+fd
bin::+fw,+fc,+fd
tty::+fw,+fc,+fd
kmem::+fw,+fc,+fd
games::+fw,+fc,+fd
news::+fw,+fc,+fd
man::+fw,+fc,+fd
sshd::+fw,+fc,+fd
smmsp::+fw,+fc,+fd
mailnull::+fw,+fc,+fd
bind::+fw,+fc,+fd
proxy::+fw,+fc,+fd
_pflogd::+fw,+fc,+fd
_dhcp::+fw,+fc,+fd
uucp::+fw,+fc,+fd
pop::+fw,+fc,+fd
www::+fw,+fc,+fd
hast::+fw,+fc,+fd
nobody::+fw,+fc,+fd
mysql::+fw,+fc,+fd
postfix::+fw,+fc,+fd
dovecot::+fw,+fc,+fd
dovenull::+fw,+fc,+fd


  All other audit_* files are identical with source ones.


> thr_new, which certainly should be known everywhere, so I'm wondering
> if you have a bad build somehow.  Are you using GENERIC or do you have
> a custom kernel config?

  It is custom (trimmed) kernel config. Nothing special, only most of devices (which is not actual on this hardware) are stripped.

-- 
// Lev Serebryakov