These are devices exposed in Ironclad regardless of target system when present, with standardized interfaces.
/dev/console wraps architecture-specific debug output channels for use
with file operations. For x86-based targets, this is COM1, for other targets,
this may be UART.
If the target implements reading from the debug channels, read will be supported as well. If not implemented, the device will be read-only.
The kernel also uses the debug channels for output, so keep in mind the contentions that can cause. If you are doing a lot of spaced writes, do not be surprised if the kernel pops in the middle! In the other hand, the kernel does not read from the debug channels.
The devices starting by ramdev are virtual devices representing the
RAM driver passed by some boot protocols, an FS can be mounted to them, or be
otherwise used like any other block device. These RAM devices are read/write,
but they cannot grow in size, so changes are constrained to the area the
RAM device already has allocated.
The device random is equivalent to the one featured in other UNIX-like
kernels, and can be read to get a stream of cryptographically secure
pseudo-random bytes. It is implemented using a Fortuna-like PRNG, and does
not block when waiting for new entropy.
random allows for writing as well, which will take random data for
mixing into the kernel’s entropy pools.
Ironclad does not go out of its way to feed user-accessible discrete randomness
sources to the kernel’s entropy pools, like a hardware RNG, or x86’s
rdrand. It is highly recommended to use userland daemons to periodically
feed the kernel entropy with these kind of sources by writing to random.
This can also be used to implement seed files, for example:
# On boot, maybe as part of the init system. cat seedfile.bin > /dev/random # On poweroff. dd if=/dev/random of=seedfile.bin bs=4M count=1 iflag=fullblock
/dev/urandom does the same as /dev/random, and is only provided
as a virtual alias for compatibility.
getrandom is provided as well for avoiding the file interface when
interfacing with random, as that may avoid certain kinds of DoS
attacks related to opened file limits.
null returns EOF whenever read, and all the write operations are
discarded.
zero returns exclusively a stream of zeros when read, and all write
operations are discarded.
i6300esb is a hardware watchdog featured in a lot of intel hardware, it
can be reset by using write and can be configured using
ioctl like:
WDOG_START = 1 // Start the count. WDOG_STOP = 2 // Stop the count. WDOG_HEARTBEAT = 3 // Reset and set a new heartbeat period in seconds. ioctl(wdog, WDOG_START, ignored); // Enable 2:1 scaling. ioctl(wdog, WDOG_STOP, ignored); // Enable 1:1 scaling. ioctl(wdog, WDOG_HEARTBEAT, pointer_to_uint32_t);
There is no default heartbeat count, so be sure to configure it if you do not want mayhem. Access to reset and configuration can be restricted by using MAC.
While this piece of hardware allows for hooking up interrupts and reboot separately when the timer expires, Ironclad right now will only reboot when the timer expires.
The devices starting by sata represent several SATA AHCI block devices.
For now only SATA drives are supported, support for ATAPI is not present.
These SATA drives have internal caching at the driver level, so they must be
sync’d for data integrity when wanting to ensure data coherency.
The devices starting by nvme represent NVMe block devices, namespaces
are named using n followed by the namespace number.
NVMe drives have internal caching at the driver level, so they must be
sync’d for data integrity when wanting to ensure data coherency.
These devices are provided only by platforms implementing power and sleep
buttons. Programs can poll on them for read permission. When the
corresponding device reports being able to read, it shall be interpreted as a
oneshot event representing a pressing of the corresponding button.