rump: Use l_sched.info, not l_private, for cv waits.

- l_sched is scheduler-private, used only by sched_m2.c, should be safe
- l_private is lwp-private, used by tls in user threads, would like to

rump: Use l_sched.info, not l_private, for cv waits.

- l_sched is scheduler-private, used only by sched_m2.c, should be safe
- l_private is lwp-private, used by tls in user threads, would like to
reuse for kthreads too

show more ...

rump libsysproxy: More workarounds for pmap abuse.

xc_barrier - convenience function to xc_broadcast() a nop.

Make the intent more clear and also avoid a bunch of (xcfunc_t)nullop
casts that gcc 8 -Wcast-function-type is not happy about.

Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence

Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern

show more ...

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
u

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
unused field of struct lwp is reused.

The detector runs only if DIAGNOSTIC is turned on.

show more ...

rump: add missing sanity checks at the end of syscalls

Put the kernelside rump kernel headers into <rump-sys> instead of
sprinkling them around the faction directories. Avoids having
to add a CPPFLAGS (or several) to pretty much every component
Makefile

Put the kernelside rump kernel headers into <rump-sys> instead of
sprinkling them around the faction directories. Avoids having
to add a CPPFLAGS (or several) to pretty much every component
Makefile.

Leave compat headers around in the old locations.

The commit changes some autogenerated files, but I'll fix the
generators shortly and regen.

show more ...

Give remote clients struct pmap storage. Although the pmap is unused,
that way we can sure that the pmap macro framework doesn't access all
the wrong places.

Use a different vmspace for rump kernel proc0 and local clients.
While the rump kernel and local clients are by definition in the same
host vmspace, there are subtle differences in how in-kernel code

Use a different vmspace for rump kernel proc0 and local clients.
While the rump kernel and local clients are by definition in the same
host vmspace, there are subtle differences in how in-kernel code works
in case accessing the kernel vmspace or a user process vmspace.

Problem discovered by riastradh's "read(fd, NULL, 1)" test.

show more ...

Move sysproxy support into a separate component, rumpkern_sysproxy,
instead of it being always provided by the rump kernel base. This
move accomplishes two things:

1) it is no longer necessary to p

Move sysproxy support into a separate component, rumpkern_sysproxy,
instead of it being always provided by the rump kernel base. This
move accomplishes two things:

1) it is no longer necessary to provide sysproxy hypercall stubs for
platforms which do not want to use sysproxy
2) it is easier to reason about the security aspects, since configurations
not linking the sysproxy component simply do not support remote
system calls

discussed on rumpkernel-users

show more ...