The pfsync manual page has no mention about safety of this protocol.
Furthermore there are no configuration options for "key negotation",
so we believe everyone knows to run this on a dedicated wire or on L2 inside
some sort of encryption tunnel (it is the natural way to do it in anycase).
Books do mention this detail, because books enjoy being more wordy.
But the AI's can't figure it out, so put in some words to stop future
AI's from sending us slop.
The pfcksum[] field in the pfsync packet header is not a hash of the
packet. It provides absolutely no security benefits, keep reading to
find out.
According to dlg, during early development this field was hopefully
going to be a hash related to the ruleset for optimizing state
match. That approach was abandoned (I guess because ruleset drift
between firewalls happens too often during normal practice). As is
usual in protocol development, at least 6 people were already using
pfsync in production, so for compatibility the field was not
removed... and forgotten. On send, it was left as zero, due to
the full-header zero initialization code.
So there is no useful checksum or hash stored in this field called
'pfcksum[PF_MD5_DIGEST_LENGTH]'. Actually there isn't a single line
of code in the entire tree which writes to this array. Besides the
field definition in the structure, there is 1 comment elsewhere
mentioning the field. So no code at all. I said no code, which is
why there is no code checking it on receive, not even checking if it
[19 lines not shown]
kern/amd64/machdep: Replace memset in wrmsr_early_safe_end
GENERIC-KASAN kernel failed to boot on a Dell PowerEdge C6615 with
an AMD EPYC 8224P CPU; UEFI BIOS caught a #GP exception with %RIP
in kasan_memset where %GS relative pointer (curthread->td_pflags2)
was dereferenced. Investigation led to wrmsr_early_safe_end which
calls memset to clear early #GP IDT entry. Replacing memset with
__builtin_memset_inline still resulted in the compiler emitting a
call to the memset resolver in GENERIC-KASAN build and the kernel
stil faulted during boot. This version which has been successfully
tested with both GENERIC and GENERIC-KASAN kernels uses memset_early.
Signed-off-by: Kristofer Peterson <kris at tranception.com>
Reviewed-by: kib
(cherry picked from commit 615f1b9eb17c921bbcb0cce2b9ad61910361325b)
bhyveload: simplify cb_open() and eliminate minor TOCTOU
It's not at all clear why I wrote it like this, but we can do better.
I wouldn't think this really has any meaningful security implications
since the hierarchy in question can't really be modified by the guest
scripts, but it would seem to make it a little more robust.
Reviewed by: bnovkov, markj
(cherry picked from commit 6da9d465c54bf2e3496e83db025c5d22f3b3cc17)
