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).
busses would end up with "ghost" device instances on the second bus. This
issue was previously masked on ARM systems by the empty-child-devices
array issue fixed recently (that effectively blocked all indirect config
of i2c busses on those systems).
To fix this problem, we require that indirectly-configured devices have
to fully specify their parent spec and address, e.g.:
foo* at iic0 addr 0x55
NOT
foo* at iic? addr ?
or even:
foo* at iic? addr 0x55
This is needed because of how indirect configuration works... attach
directives in the kernel config file are enumerated, calling the bus's
search routine, which in the case of i2c, enumerates all i2c addresses
and calls the match routine for each address. Because we can't always
reliably probe for i2c devices, we ended up with erroneous matches.
Direct configuration of i2c is still allowed to use wildcarded parent specs
and locators.
particular, the parent spec must not be wild-carded, as doing so doesn't
work well on systems where more than one I2C bus is present.
N.B. The x86 platforms are sort of a mess, here... legacy indirect
config and ACPI direct config sort of smashed together with the
same config file directives.
