when the alarm hits while the process is currently in syslog(), holding
the sl lock, then calling syslog again will deadlock:
/proc/1729193/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: lstk()
sleep()+0x7 /sys/src/libc/9syscall/sleep.s:5
lock(lk=0x394d8)+0xb7 /sys/src/libc/port/lock.c:25
i=0x3e8
syslog(logname=0x41c64,cons=0x0,fmt=0x41c6a)+0x2d /sys/src/libc/9sys/syslog.c:60
err=0x79732f27
d=0x0
ctim=0x0
buf=0x0
p=0x0
arg=0x0
n=0x0
catchalarm(msg=0xdfffc854)+0x7a /sys/src/cmd/upas/smtp/smtpd.c:71
notifier+0x30 /sys/src/libc/port/atnotify.c:15
this implements the mitigation suggested in section "6.5 Countermeasures" of
"Key Reinstallation Attacks: Forcing Nonce Resuse in WPA2" [1].
[1] https://papers.mathyvanhoef.com/ccs2017.pdf
copying files from the uefi shell works, reading plan9.ini works,
loading the kernel by calling Read to read in the DATA section of
the kernel *FAILS*. my guess is that uefi filesystem driver or
nvme driver tries to allocate a temporary buffer and hasnt got
the space. limiting the read size fixes it.
the cachetab just keeps track of recent messages that have not
been called cachefree() on. under some conditions, the fixed
table could overflow (all messages having refs > 0). with a
linked list, overflow becomes non fatal and the algorithm is
simpler to implement.
there isnt much of a point in keep maintaining separate
kernel configurations for terminal and cpu kernels as
the role can be switched with service=cpu boot parameter.
to make stuff cosistent, we will just have one "pc" kernel
and one "pc64" kernel configuration now.
we used to tweak arround in the ICH registers for all intel controllers,
which is wrong, as the 200 series has different magic registes. see
the datasheet:
https://www.intel.com/content/www/us/en/chipsets/200-series-chipset-pch-datasheet-vol-2.html
this caused the clocks to be disabled for the 6th port causing a full
machine lockup touching the 6th port registers.
the next problem was that aiju's bios disabled the unused ports somehow
but didnt clear ther PI bits, so that they would stay in Sbist status even
after a port reset. so the port would get stuck in the Dportreset state
forever. the fix for this was to use a one second timeout for the
port reset procedure.
