and now in PR/53334. Basically non-IKE markers come from a deprecated
draft, and our kernel code for them has never worked.
Setsockopt will now reject UDP_ENCAP_ESPINUDP_NON_IKE.
Perhaps we should also add a check in key_handle_natt_info(), to make
sure we also reject UDP_ENCAP_ESPINUDP_NON_IKE in the SADB.
of /libdata/firmware and /usr/libdata/firmware are not installed
if set to "no". from the bsd.README:
MKFIRMWARE If "no", install the /libdata/firmware directory,
which is necessary for several drivers: athn(4), bwfm(4),
ipw(4), iwi(4), iwm(4), iwn(4), otus(4), rtwn(4), urtwn(4),
wpi(4), ral(4), rum(4), run(4), zyd(4), bcm43xx(4), and
the Tegra 124 SoC.
Default: yes on amd64, cobalt, evbarm evbmips, evbppc, hpcarm,
hppa, i386, mac68k, macppc, sandpoint, and sparc64, no elsewhere.
convert MKRADEONFIRMWARE and MKTEGRAFIRMWARE into FOO.arch lists,
and move their defaults above the general defaults setting.
saves about 12MB in a normal installation for other platforms.
It seems that there remain some paths that don't satisfy the constraint that is
required only if NET_MPSAFE. So don't check it by default.
One known path is nd6_rtrequest => in6_addmulti => if_mcast_op, which is not
easy to address.
a FreeBSD bug report, by Jason Mader.
The RFC specifies that under IPv6 the complete AH header must be 64bit-
aligned, and under IPv4 32bit-aligned. That's a rule we've never respected.
The other BSDs and MacOS never have either.
So respect it now.
This makes it possible to set up IPv6-AH between Linux and NetBSD, and also
probably between Windows and NetBSD.
Until now all the tests I made were between two *BSD hosts, and everything
worked "correctly" since both hosts were speaking the same non-standard
AHv6, so they could understand each other.
Tested with Fedora<->NetBSD, hmac-sha2-384.
If we write a byte character into a pointer, a compiler can emit a
read-modify-write operation, especially when a CPU cannot access directly
a character wide address.
In this scenario calling mmap(2) with PROT_WRITE, without PROT_READ will
emit unexpected trap.
There are two possible workarounds for this issue:
- write register wide memory without rmw sequence,
- mark the region with additional protection PROT_READ
Both work for NetBSD/alpha.
Go for the latter as perhaps more safe for dump compilers emitting rmw
sequences.
Investigated by <martin>
esp_hdrsiz, and clarify.
Until now we were using ah_hdrsiz, and were relying on the fact that the
size of the AH header happens to be equal to that of the ESP trailer.
Now the size of the ESP trailer is added manually. This also fixes one
branch in esp_hdrsiz: we always append an ESP trailer, so it must always
be taken into account, and not just when an ICV is here.
Trailer (two bytes), and we were doing minus two all the time.
Declare 'tlen', which contains padlen+ESP_Trailer+ICV, and use 'struct
esptail' instead of hardcoding the construction of the trailer. 'padlen'
now indicates only the length of the padding, so no need to do -2.
to bytes_transfer() which asserted that the size is < the size of 512 AuxInfo
structs. On a 32 bit system, an AuxInfo is 8 bytes, and 512 AuxInfo
structs is thus 4096 bytes, and 4096 is not < 4096, so the assertion
failed. It would probably work as a <= assert, but I am not confident
enough with this test case to make that call, so instead increase the
array size to be 513 instead, 4096 is < 513*8 so happiness should return
and all should be right with the world. At least for this one test.
(There was no problem on 64 bit systems as AuxInfo is bigger there.)
Don't allow to PT_ATTACH from a vfork(2)ed child (before exec(3)/_exit(3))
to its parent. Return error with EPERM errno.
This scenario does not have a purpose and there is no clear picture how to
route signals.
Sponsored by <The NetBSD Foundation>
The panic_string module accepts input from a device file over the write(2)
system call.
It prints panic(9) message passed from user space, e.g.:
echo "Hello world" > /dev/panic
If a string is empty or contain only whitespaces it's ignored and panic(9)
is not triggered. If a non printable character is passed within the input
buffer, the rest of the string is ignored.
This module performs the sync(8) operation before panic(9) to flush cache.
Submitted by Harry Pantazis.
Simplified and cleaned up by myself.
Add new tests:
- traceme_crash_trap
- traceme_crash_segv
- traceme_crash_ill (temporarily disabled)
- traceme_crash_fpe
- traceme_crash_bus
- unrelated_tracer_sees_crash_trap
- unrelated_tracer_sees_crash_segv
- unrelated_tracer_sees_crash_ill (temporarily disabled)
- unrelated_tracer_sees_crash_fpe
- unrelated_tracer_sees_crash_bus
These tests verify two subtle kernel paths that differ internally:
- for a tracer that is a parent of a traced program (and not vforked)
real parent == tracer
- for a tracer that is an unrelated process of a traced program
real parent != tracer
Regressions in the signal code can cause to break one of the scenarios, and
keep working the other one. It might be propagated to a scenario like:
- attaching to a process with a debugger (over pid)
- starting a process inside a debugger
We can assert on the ATF level that both will be functional.
While there, cover all the crash signals as testing is done practically
for free. While the Machine Independent signal routing code for crash
signals is mostly the same in the kernel, we can verify whether Machine
Dependent parts works as expected emitting the proper signal number and
signal code (si_code).
There have been already caught an unexpected behavior on Alpha, that
instead of SIGBUS we receive SIGSEGV.
Another benefit is that it's easier to catch races, as they pop up more
frequently. (This already helped to catch bugs more quickly)
These tests will help assert correctness of future kernel changes in the
signal routines.
All tests pass.
Sponsored by <The NetBSD Foundation>
when the packet was received on a physical interface, it may not be if
the packet was received over L2TP/EtherIP.
In particular, if the inner ethernet header ends up on two separate IP
fragments. Here the KASSERT is triggered, and on !DIAGNOSTIC we corrupt
memory.
Note that this is a widespread problem: a lot of L2 code was written with
the assumption that "most" headers are present in the first mbuf.
Obviously, that's not true if L2 encapsulation is being used.
start at 0x81; the code used bus_space_map() starting from 0x80 but
used +1 offset for actual I/O, now it maps starting 0x81 and does I/O
without offset
the reads and writes work exactly the same as before, but this frees
0x80 for being mapped independantly
patch provided in PR kern/52468 by Jonathan Chapman; checked against the spec
and also FreeBSD sys/x86/isa/isa_dma.c
