countdown with '\b' only after waiting.
Some UEFI implementations have a destructive/erasing backspace,
and will not show the countdown if we move the cursor back before the
wait.
My ThinkPad T430 w/ Lenovo's UEFI exhibited this whiteout-backspace,
while my Gigabyte Brix GB-BXBT-2807 did not.
Should fix PR #53292.
way to determine if we are in kernel mode but with the user context; so we
go the hard way, and scan the IDT.
On i386 the bug is less of a problem, since we don't have GSBASE. All an
attacker can do is panicking the system.
In traceme* tests after validate_status_stopped() include additional check
the verify the received signal with PT_GET_SIGINFO.
All tests passes.
Sponsored by <The NetBSD Foundation>
Set new description to:
- "Verify PT_TRACE_ME followed by raise of " #sig " in a vfork(2)ed "
"child"
The previous one was copy pasted from a different ATF test and not changed.
Sponsored by <The NetBSD Foundation>
Verify software breakpoint in a vfork(2)ed child.
The expected behavior is not to route this signal to the parent, even if
that parent is a tracer. The parent cannot handle it and it would lead to
the deadlock.
This test passes correctly.
Sponsored by <The NetBSD Foundation>
Follow the FreeBSD approach of not routing signals to the parent that is
a became tracer after calling PT_TRACE_ME by the vfork(2)ed child (before
exec(3)/exit(3)).
Now if a child calls raise(3), the signal is processed directly to this
child.
Add new ATF ptrace(2) tests:
- traceme_vfork_raise1 (SIGKILL)
- traceme_vfork_raise2 (SIGSTOP) // temporarily disabled
- traceme_vfork_raise3 (SIGABRT)
- traceme_vfork_raise4 (SIGHUP)
- traceme_vfork_raise5 (SIGCONT)
The FreeBSD implementation introduces P_PPTRACE for this special case.
Right know keep opencoding check of this case in the kernel. It might be
refactored in future.
The Linux kernel does not follow this approach and causes dead locking of
the processes (parent and child).
Defer handling SIGSTOP into future.
This is an intermediate step towards correct handling of fork(2) and
vfork(2) in the context of ptrace(2).
All new tests pass.
There are no regressions in existing ATF ptrace(2) tests.
Sponsored by <The NetBSD Foundation>
to the same IPsec processing. That is to say, that all fragments are ESP,
or AH, or AH+ESP, or none.
The reassembly mechanism can be used both on the wire and inside an IPsec
tunnel, so we need to make sure all fragments of a packet were received
on only one side.
Even though I haven't tried, I believe there are configurations where it
would be possible for an attacker to inject an unencrypted fragment into a
legitimate stream of already-decrypted-and-authenticated fragments.
Typically on IPsec gateways with ESP tunnels, where we can encapsulate
fragments (as opposed to the general case, where we fragment encapsulated
data).
Note, for the record: a funnier thing, under IPv4, would be to send a
zero-sized !MFF fragment at the head of the packet, and manage to trigger
an ICMP error; M_DECRYPTED gets lost by the reassembly, and ICMP will reply
with the packet in clear (not encrypted).
