separation between the kernel and userland.
On Xen-amd64, the kernel runs in ring3 just like userland, and the
separation is guaranteed by the hypervisor - each syscall/trap is
intercepted by Xen and sent manually to the kernel. Before that, the
hypervisor modifies the page tables so that the kernel becomes accessible.
Later, when returning to userland, the hypervisor removes the kernel pages
and flushes the TLB.
However, TLB flushes are costly, and in order to reduce the number of pages
flushed Xen marks the userland pages as global, while keeping the kernel
ones as local. This way, when returning to userland, only the kernel pages
get flushed - which makes sense since they are the only ones that got
removed from the mapping.
Xen differentiates the userland pages by looking at their PG_u bit in the
PTE; if a page has this bit then Xen tags it as global, otherwise Xen
manually adds the bit but keeps the page as local. The thing is, since we
set PG_u in the kernel pages, Xen believes our kernel pages are in fact
userland pages, so it marks them as global. Therefore, when returning to
userland, the kernel pages indeed get removed from the page tree, but are
not flushed from the TLB. Which means that they are still accessible.
With this - and depending on the DTLB size - userland has a small window
where it can read/write to the last kernel pages accessed, which is enough
to completely escalate privileges: the sysent structure systematically gets
read when performing a syscall, and chances are that it will still be
cached in the TLB. Userland can then use this to patch a chosen syscall,
make it point to a userland function, retrieve %gs and compute the address
of its credentials, and finally grant itself root privileges.
data to the mbuf's data area instead of allocating a new page from the pool.
While there fix a struct xennet_rxreq leak if xennet_checksum_fill()
fails with ENOMEM.
If the CMD line is not in idle state, the interrupt handler routine will
misbehave causing an endless interrupt handler loop. This would prevent
the the kernel from getting to mountroot.
On my Pogoplug POGO-V4-A3-01, this was caused by U-Boot routing com1's TX
and RX signals to the SD card slot's CMD and DAT[0] lines respectively.
We should probably grow Marvell SoC MPP (pinmux) configuration frobs.
[v]fork() produces pid==1 (init) (if it were useful to test that, an
entirely different test would be appropriate) change the tests so
they check for [v]fork() failure, as probably intended, instead.
e.g. if
- WM_RX_PROCESS_LIMIT_DEFAULT is set 0
- WM_RX_INTR_PROCESS_LIMIT_DEFAULT is set -1 (means almost infinite)
that means wm(4) does not use polling mode.
Added:
support QPassSignals (PT_SET_SIGPASS/PT_GET_SIGPASS) in the kernel, a way to
stop routing a set of signals to tracer as they are uninteresting - GDB and
LLDB expect this feature
layout to allow direct map for all boards.
OVERO/DUOVERO/PEPPER aren't tested.
PR/52010: Regression: Gumstix Verdex is hanging in enabling cache + KASSERT ram_size
