Fix possible reace in ipi_drop_fpstate()
ipi_drop_fpstate() needs to check if the current fpu context matches the
expected one sent via IPI. Only after that %fprs should be cleared.
Use the same asm in ipi_drop_fpstate() as in the start of ipi_save_fpstate().
Also simplify ipi_drop_fpstate() and clearfpstate() since there is no need
to enable the FPU before clearing %fprs.
OK miod@ kettenis@ deraadt@
libclock: add POSIX-compatible AlignedTimer for OpenBSD
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6487timerfd_create(2) and timerfd_settime(2) are Linux-specific and not available
on OpenBSD. This alternative implementation uses a single-shot QTimer that
reschedules itself.
The next expiry is computed by rounding the current CLOCK_REALTIME down to the
last interval boundary and stepping forward by one interval.
This was marked BROKEN-sparc64 back when PHP 8.1 was still in the tree.
The issues then no longer apply, it builds fine on sparc64.
Remove BROKEN-sparc64
GCC 15 has the needed bit.h file that was missing when this
was marked BROKEN-sparc64 (like openttd, which was pointed out
by gkoehler).
Remove BROKEN-sparc64 now that it builds again.
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]
Before it is disabled, unveil allows you to override the settings on
any vnode. A block of #if 0 code suggests this might be different.
That can be deleted. This also shows one word "other" in the manual
page is misleading.
question asked by Stuart Thomas
ok beck
A binary without a PT_LOAD exec segment would later read a pinsyscall table
and damage it strangely. Such a binary cannot actually run, but we should
avoid the internal pinsyscall table damage, and fail the execve with EINVAL.
reported by Stuart Thomas
ok guenther