Not super related but a pleasantly surprising linux /dev trick I discovered yesterday was piping “hello” to /dev/udp/<ip>/<port> in order to check connectivity between two machines (the other was listening using nc)
> Bash handles several filenames specially when they are used in redirections, as described in the following table. If the operating system on which Bash is running provides these special files, bash will use them; otherwise it will emulate them internally with the behavior described below.
> ...
> Bash attempts to open the corresponding [...] socket.
Even more fun is that if you create /dev/udp/127.0.0.1 (and chmod a+rwx), it won't create the file 53 if you "echo hello > /dev/udp/127.0.0.1/53". Instead it sends a UDP packet to your DNS server.
If you create a symlink to a path like /dev/udp/127.0.0.1/53 and redirect output to the symlink, a packet is not sent; the file is written as normal.
I'm guessing nobody has ever actually had a problem with this, so it's not actually a bad design choice, but I personally wouldn't have written that code. Leaky abstraction.
I dunno, if you “echo foo > /dev/null” then “cat /dev/null” you won’t get foo back. Plenty of assumptions about filesystem behaviour don’t work in all cases.
That being said, I’d prefer if the symlink actually worked and sent the packet.
That’s probably because bash is only looking for those types of paths in a redirection context. But if you try to use regular file utilities those paths don’t have any special meaning so they just work as normal.
If you had lots of ram this may have taken a while. In grad school we piped vmlinux and other files to /dev/dsp as a crude acoustic "tripwire" to "listen" to the system configuration.
I think we need to examine the definition of "pipe" in a POSIX context here. Pipelines feed the output of one program into the input of another one. You don't "pipe" files, you copy them.
Make a game of it: How many random bytes can you write (to random locations) before (your program | the entire system) goes badly awry or unresponsive?
Drawing to the vga frame buffer back in dos used to be as simple as setting a pointer to 0xA0000 in your c(++) program and writing to it.
Fond memories!
This is also handy for directly accessing memory that's been mapped in from peripherals and special-purpose processors. Though it might not always work because of clock gating.
If my memory serves me correctly you can control the mapped caching attributes using file flags, like O_SYNC, etc. Might also be architecture dependent. If you want to manipulate a memory-mapped device then you don't want caching, but if you want to see memory the same way a typical application does, then you want to keep the caching attributes in your mapping. It's a low-level tool, so there is no right or wrong really.
- `/dev/mem` should only be accessible by root or whoever you set the permissions to (don't `chmod 777 /dev/mem`).
- root can install device drivers which have full executable run of the system anyway and do anything you can do with this device; this is also true on Windows.
- it's possible to build a Linux kernel without `/dev/mem` support and also without loadable module support (I think), so if your threat model indicates this needs to be addressed it is possible.
>root can install device drivers which have full executable run of the system anyway and do anything you can do with this device; this is also true on Windows.
Oddly enough, no. Or atleast last time I tried on Ubuntu I had to disable secure boot. Seemed like an easier way than to sign the build files
Secure Boot can be configured to also trust user keys. Ubuntu's installer does it automatically if you choose to install it with third-party drivers (like Nvidia). Those user keys are then available to root to sign any DKMS kernel modules.