At this point it is highly unlikely this 1999 device still has users,
but it still comes up in the context of maxv's USB-fuzzing (and any device
could pretend to be a urio(4)), so it's best to get rid of it.
Renamed all major entries to obsolete, as was done in previous removals.
This still requires an update to sanitizers, but they're located in
"external", perhaps it should be first committed upstream?
Proposed on tech-kern a month ago.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/01/13/msg025938.html
This was never (intentionally) enabled by default, and the design has
some shortcomings. You can get mostly the same results with ktrace,
as in usr.bin/make/filemon/filemon_ktrace.c which is now used instead
of filemon for make's meta mode.
If applications require higher performance than ktrace, or nesting
that ktrace doesn't support, we might consider adding something back
into the vfs system calls themselves, without hijacking the syscall
table. (Might want a more reliable output format too, e.g. one that
can handle newlines in file names.)
from userland via /dev/vhci. Using this, it becomes possible to test and
fuzz the USB stack and all the USB drivers without having the associated
hardware.
The vHCI device has four ports independently addressable.
For each xfer on each port, we create two packets: a setup packet (which
indicates mostly the type of request) and a data packet (which contains
the raw data). These packets are processed by read and write operations
on /dev/vhci: userland poll-reads it to fetch usb_device_request_t
structures, and dispatches the requests depending on bRequest and
bmRequestType.
A few ioctls are available:
VHCI_IOC_GET_INFO - Get the current status
VHCI_IOC_SET_PORT - Choose a vHCI port
VHCI_IOC_USB_ATTACH - Attach a USB device on the current port
VHCI_IOC_USB_DETACH - Detach the USB device on the current port
vHCI has already allowed me to automatically find several bugs in the USB
stack and its drivers.
My keyboard and mouse use multiple device nodes each. I can't use
any other devices once they're attached. With my keyboard, mouse,
and two game controllers attached, a total of 9 nodes are required.
Particularly, high-end keyboards with N-key rollover support require
more device nodes, since they pretend to be multiple keyboards to work
around limitations in the uhid compat spec.
My original intention was to raise it from 4 to 12, but martin
suggested increasing it to 16.
"somewhat insane, but so is reality" - mlelstv
(like sensor readout) are locked, so that a userland program may interfere with
envsys operation.
To use this you need a program like ipmitool built with OpenIPMI support.
Previously spi would configure the controller to use the lowest speed of
all connected devices since the kernel started and to fail attempted mode
changes. This is now improved to keep individual modes and speeds for each
slave and to reconfigure the controller as necessary for each transfer.
Added man page for spi(9).
The KCOV driver implements collection of code coverage inside the kernel.
It can be enabled on a per process basis from userland, allowing the kernel
program counter to be collected during syscalls triggered by the same
process.
The device is oriented towards kernel fuzzers, in particular syzkaller.
Currently the only supported coverage type is -fsanitize-coverage=trace-pc.
The KCOV driver was initially developed in Linux. A driver based on the
same concept was then implemented in FreeBSD and OpenBSD.
Documentation is borrowed from OpenBSD and ATF tests from FreeBSD.
This patch has been prepared by Siddharth Muralee, improved by <maxv>
and polished by myself before importing into the mainline tree.
All ATF tests pass.
provides support for hardware-accelerated virtualization on NetBSD.
It is made of an MI frontend, to which MD backends can be plugged. One
MD backend is implemented, x86-SVM, for x86 AMD CPUs.
We install
/usr/include/dev/nvmm/nvmm.h
/usr/include/dev/nvmm/nvmm_ioctl.h
/usr/include/dev/nvmm/{arch}/nvmm_{arch}.h
And the kernel module. For now, the only architecture where we do that
is amd64 (arch=x86).
NVMM is not enabled by default in amd64-GENERIC, but is instead easily
modloadable.
Sent to tech-kern@ a month ago. Validated with kASan, and optimized
with tprof.
is of poor quality, and is now an obstacle to MP-ification. It was removed
ten years ago from FreeBSD for the same reason.
This retires a big user of the mbuf API, and will ease maintenance of the
kernel.
node results in a non working config, despite following manual to get setup.
Remove a step for the user by creating a device node for veriexec by default.
ok mrg jakllsch
for more than one of the -m -p -s -t args (and checks whether any were given
to pick one if not) to be more shell friendly.
Note that while the method here is the same as was discussed on the list,
the actual implementation is free of the typos, and just pure lunacy that
was in the code that was shown there.
Also note these changes are intended to be completely internal, there
should be no visible impact upon the way that MAKEDEV works.
ok:christos. Thanks to pgoyette for the code review.
tech-kern in messages with a Subject starting [Re:] /dev/sdN -> /dev/sdN[cd]
and in PR port-amd64/51216 :
Create bare (no letter suffix) device names (block & raw) that
refer to the raw device ('c' or 'd' partition as appropriate).
This commit was delayed waiting to see if there was to be any more
discussion - there wasn't a lot.
Caution: this is going to consume 2 more inodes per disc device
configured, everywhere that devices are configured using MAKEDEV
mode 664 and group ownership set to 'gpio'. This allows controlled access
to specifically enabled gpio pins to members of the gpio group. See
gpioctl(8), and, gpio(4) for details.
