[HN Gopher] Directly access your physical memory (dev/mem)
___________________________________________________________________
Directly access your physical memory (dev/mem)
Author : blueblueue
Score : 32 points
Date : 2023-01-11 19:59 UTC (2 days ago)
(HTM) web link (bakhi.github.io)
(TXT) w3m dump (bakhi.github.io)
| wmwmwm wrote:
| 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)
| yakubin wrote:
| To be pedantic, that's provided by bash, not devfs. You
| wouldn't be able to do it like this from e.g. a C program.
| drpyser22 wrote:
| You mean that bash interprets the path and creates the socket
| itself?
| yakubin wrote:
| Yes.
| st_goliath wrote:
| Yes, bash does that. It's a bash feature:
|
| https://www.gnu.org/savannah-
| checkouts/gnu/bash/manual/bash....
|
| > 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.
| jrockway wrote:
| 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.
| zeroimpl wrote:
| 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.
| h2odragon wrote:
| 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?
| sumtechguy wrote:
| Think you just described core war.
| https://en.wikipedia.org/wiki/Core_War
| abc_lisper wrote:
| Lol. Back in TurboC days I wrote my first "random" number
| generator by reading off memory. Win 98 I think
| hecanjog wrote:
| This is pretty tangential but seeing this reminds me of the days
| when the puredyne distro used to pipe /dev/mem to /dev/dsp as a
| noisy startup chime.
| basementcat wrote:
| 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.
| Eleison23 wrote:
| [dead]
| sedatk wrote:
| Talk about a memory leak.
| [deleted]
| tgsovlerkhgsel wrote:
| I'm surprised access through /dev/mem happens below the caching
| layer. I wouldn't have even thought of that possibility. Any idea
| why that is?
| righttoolforjob wrote:
| 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.
| zerohp wrote:
| A very common usage for /dev/mem is to access a device through
| memory mapped IO from user space.
|
| Cacheable accesses would break that use case.
| bbhfb wrote:
| 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.
| dezgeg wrote:
| The 'devmem' command is pretty neat when doing embedded systems,
| allowing you to write entire device drivers in bash!
| justapassenger wrote:
| That's a horrible idea. You should use javascript instead.
| rsj_hn wrote:
| if you aren't using Lisp, then are you even a real driver
| developer?
| mikotodomo wrote:
| Isn't this a security risk?
| tenebrisalietum wrote:
| - `/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.
|
| - read about CONFIG_STRICT_DEVMEM - https://man7.org/linux/man-
| pages/man4/mem.4.html#:~:text=Sin....
|
| - wait until you hear about `/dev/kmem`.
|
| - 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.
___________________________________________________________________
(page generated 2023-01-13 23:01 UTC)