memory used by the kernel at run time, and just like kASan and kCSan, it
is an excellent feature. It has already detected 38 uninitialized variables
in the kernel during my testing, which I have since discreetly fixed.
We use two shadows:
- "shad", to track uninitialized memory with a bit granularity (1:1).
Each bit set to 1 in the shad corresponds to one uninitialized bit of
real kernel memory.
- "orig", to track the origin of the memory with a 4-byte granularity
(1:1). Each uint32_t cell in the orig indicates the origin of the
associated uint32_t of real kernel memory.
The memory consumption of these shadows is consequent, so at least 4GB of
RAM is recommended to run kMSan.
The compiler inserts calls to specific __msan_* functions on each memory
access, to manage both the shad and the orig and detect uninitialized
memory accesses that change the execution flow (like an "if" on an
uninitialized variable).
We mark as uninit several types of memory buffers (stack, pools, kmem,
malloc, uvm_km), and check each buffer passed to copyout, copyoutstr,
bwrite, if_transmit_lock and DMA operations, to detect uninitialized memory
that leaves the system. This allows us to detect kernel info leaks in a way
that is more efficient and also more user-friendly than KLEAK.
Contrary to kASan, kMSan requires comprehensive coverage, ie we cannot
tolerate having one non-instrumented function, because this could cause
false positives. kMSan cannot instrument ASM functions, so I converted
most of them to __asm__ inlines, which kMSan is able to instrument. Those
that remain receive special treatment.
Contrary to kASan again, kMSan uses a TLS, so we must context-switch this
TLS during interrupts. We use different contexts depending on the interrupt
level.
The orig tracks precisely the origin of a buffer. We use a special encoding
for the orig values, and pack together in each uint32_t cell of the orig:
- a code designating the type of memory (Stack, Pool, etc), and
- a compressed pointer, which points either (1) to a string containing
the name of the variable associated with the cell, or (2) to an area
in the kernel .text section which we resolve to a symbol name + offset.
This encoding allows us not to consume extra memory for associating
information with each cell, and produces a precise output, that can tell
for example the name of an uninitialized variable on the stack, the
function in which it was pushed on the stack, and the function where we
accessed this uninitialized variable.
kMSan is available with LLVM, but not with GCC.
The code is organized in a way that is similar to kASan and kCSan, so it
means that other architectures than amd64 can be supported.
- Add XXX comment for strange pause setting code. I suspect this is wrong.
- On my environments, 1000BASE-T half duplex doesn't work, so we might remove
IFM_1000T_HDX from this device in future.
multiplier of 8, just like the 16C1050 controller.
Verified with an ExSys EX-41388.
ryo@ checked back with the hardware his original commit was based on,
and confirmed the change.
XXX Pull-up to netbsd-{7,8,9}
Now COPY_SYMTAB is no longer necessary and it saves ~500kbytes of
GENERIC, so re-enable options DDB (i.e. revert GENERIC rev 1.85).
Also fix zbsdmod.o (a kernel loader for Zaurus Linux) to load symbols
at a proper address as the MI sys/lib/libsa/loadfile_elf32.c does.
No particular comment on port-zaurus@:
https://mail-index.netbsd.org/port-zaurus/2019/11/11/msg000086.html
Note zbsdmod.c (derived from OpenBSD/zaurus) assumed that the loaded
kernels had "esym" variable at the top of its data section and
implicitly overwrote it with the address of loaded symbol tables.
OpenBSD/zaurus kernels used the esym value written by the zbsdmod.o
to initialize ksyms(4) on startup, but we will avoid such implicit
MD interface between the bootloader and kernels (though we don't
bother to add a symbol address value into bootinfo but just assume
symbols are loaded at end[] of a loaded kernel, as per the MI
libsa loadfile() implementation).
Worth to pullup to both netbsd-8 and netbsd-9.
When kernels were configured for both CPU_XSCALE_PXA270 and
CPU_XSCALE_PXA250, the OST freq value was not set until tc_init(9)
then all delay(9) during configure(9) returned immediately.
While here, use proper macro with description for readability.
Should be pulled up to netbsd-8 and netbsd-9.
(though zaudio(4) won't work on netbsd-8)
* hooks: STOPPED is now run on timeout and exit
* BSD: Use IP_REVCIF rather than IN_PKTINFO
* DHCP: When rebinding, ensure we have a DHCP ARP state
* RA: Sort routers when reachability changes
* RA: Apply hoplimit, reachable and retrans timer values to kernel
* RA: Warn if advertised MTU > interface MTU
* dhcpcd: Report SSID connection to when we gain carrier
* DHCP: Fix corruption of address flags when renewing
It is plainly obvious that the init value cannot be used (the
var was never used uninit'd - could not be) but gcc apparently cannot
work that out. Revert this if we ever get a compiler with a brain.
maxv