IRC channel logs


back to list of logs

***Server sets mode: +nt
***Server sets mode: +nt
***Server sets mode: +nt
***Server sets mode: +nt
<tpanmajia>does anyone know how GNU Mach restricts raw device read and write?
<tpanmajia>for example, the kernel only allows some threads to make raw access of a SCSI disk
<tpanmajia>sorry for my English
<tpanmajia>OK, I'm trying to clarity, had been on a headache just now
<tpanmajia>I'm not quite sure whether there is a mechanism provided by GNU Mach that can restrict raw device access
<tpanmajia> certain processes, such as a Hurd block manager daemon
<damo22>tpanmajia: im not an expert but im guessing the file permissions on the device node would do it
<tpanmajia>IIRC microkernel-based OSes typically delegate block device access functionality to some userspace daemons
<damo22>a lot of hurd is managed by permissions on file nodes
<tpanmajia>damo22: just like Linux?
<damo22>i think so
<tpanmajia>damo22: therefore there is a concept on file nodes as special device nodes, representing block and character devices?
<tpanmajia>s/there is/is there/
<tpanmajia>I mean specificially in Hurd
<damo22>there is a concept of nodes that are backed by "translators"
<tpanmajia>yes, it's just that
<damo22>so when you access a file node that activates a translator, if you have access to the node you can run the translator
<tpanmajia>but the translators providing indirect access of raw devices must access the corresponding raw devices itself...
<tpanmajia>so I guess it's the old unix model applied here?
<damo22>yeah posix probably
<tpanmajia>translators ran as root providing access to raw devices
<damo22>not all translators must run as root
<tpanmajia>and only root could invoke raw device-related syscalls
<tpanmajia>I'm not quite sure that there are actual syscalls in Hurd
<damo22>there are
<tpanmajia>but I can't quite find them in the docs
<tpanmajia>in glibc Hurd port?
<tpanmajia>oh brilliant
<tpanmajia>I forgot the syscall interface in libc
<tpanmajia> who in terms of user could invoke raw device-related syscalls?
<damo22>any user i think
<tpanmajia>*any* user?
<tpanmajia>then anyone could do the equivalent of `dd if=/dev/zero of=/some/disk` and ruin the OS
<damo22>no because the device node is not owned by them
<tpanmajia>not a good security practice I guess
<tpanmajia>but if any user could have access to all devices
<tpanmajia>...why wouldn't they do the raw things themselves?
<damo22>yeah, any user can share the devices
<tpanmajia>then any user could do a raw write to the disk
<tpanmajia>simply overwrite it with zero and "call it a day"
<damo22>its up to you how you share the permissions
<damo22>if you want to grant a user access to a raw disk, you can
<tpanmajia>no I'm not telling about permissions
<tpanmajia>granting the access of a raw disk to some user is traditional...
<damo22>block devices are special
<damo22>you cant easily share those
<damo22>but you can share files on a mounted filesystem
<tpanmajia>I mean if any user could be granted access to raw devices it could constitute a security bypass
<tpanmajia>can't a user easily share block devices?
<damo22>well if you are mounting a filesystem from a block device, you cant exactly mount it twice
<damo22>so it makes sense for root to control that
<tpanmajia>by "granted" I mean granted the ability of directly making syscalls to access the device
<damo22>but i am working on PCI such that users can share access to other devices
<tpanmajia>so the ability of sharing devices is determined by the actual device driver?
<tpanmajia>sharing of PCI devices is uncommon in conventional OSes
<tpanmajia>what does "probably" mean...?
<tpanmajia>is it also decided by the device itself?
<damo22>we are working on a pci-arbiter that should allow users to share access to pci card
<damo22>so instead of root owning everything
<tpanmajia>oh got it
<tpanmajia>typically root *owns* everything
<damo22>root doesnt need to own the ethernet card if your user has opened the card instead
<damo22>and other users can share the card perhaps
<tpanmajia>so... what exactly is the translator providing conventional devices nodes, such as disk nodes and tty nodes?
<tpanmajia>s/devices nodes/device nodes/
<tpanmajia>sounds like paravirtualization in userspace
<damo22>there are different translators for different jobs
<tpanmajia>...where users serves the purpose of lightweight VMs here
<tpanmajia>oh this
<damo22>eg, netdde for ethernet
<tpanmajia>I'm *assuming* that there is such thing like `udevd` in Hurd, which is not correct
<damo22>i dont think there is udevd
<tpanmajia>so what translator is for disk?
<damo22>i am working on rumpdisk translator for disk
<damo22>it currently needs root
<tpanmajia>get FreeBSD sources, tweak and then profit?
<tpanmajia>they've built their own rumpkernel implementations and interfaces as well
<damo22>i have built librump for hurd
<tpanmajia>oh got it
<tpanmajia>FreeBSD's rumpkernel is somewhat more impressionable in my mind
<damo22>i didnt know FreeBSD did rump
<damo22>i only know NetBSD's
<tpanmajia>my bad
<tpanmajia>FreeBSD didn't do them
<tpanmajia>NetBSD did
<damo22>currently it needs work so it can boot /
<damo22>with rump
<tpanmajia>therefore the new translator you're writing just needs R/W and ioctl access to the underlying nodes?
<tpanmajia>device nodes
<damo22>it actually implements the device node
<tpanmajia>how could it?
<damo22>because it is the driver
<tpanmajia>the FS driver or the device driver?
<damo22>running in userspace
<damo22>the device driver
<tpanmajia>my bad
<tpanmajia>I forgot you told me that
<damo22>thats ok
<tpanmajia>so what parts that is more low-level the device driver would talk to?
<damo22>the driver talks PCI to the AHCI controller
<tpanmajia>maybe I'm assuming that a device driver in Hurd must talk to something else
<tpanmajia>it's a disk driver, isn't it?
<damo22>it needs access to PCI
<tpanmajia>how exactly does it talk to PCI?
<damo22>it runs a tiny NetBSD kernel
<damo22>as a unikernel
<damo22>with only one purpose, to expose the disk driver
<tpanmajia>yes I know the way of talking
<tpanmajia>I just mean that does it use `device_read()` or something in the Mach kernel?
<damo22>it implements the mach device interface
<tpanmajia>the mach device interface?
<tpanmajia>I'm not quite sure of that
<damo22>yes, so it appears as a mach device
<damo22>but not from the kernel
<tpanmajia>my best guess is a struct of many function pointers...
<tpanmajia>just as other OSes does
<tpanmajia>therefore how does the mach device interface work?
<tpanmajia>by standardized kernel IPC?
<damo22>let me find the code
<tpanmajia>ok thx
<tpanmajia>are you a FSF employee?
<damo22>i am a FSF member
<tpanmajia>got it
<damo22>but to contribute code to hurd i think you have to assign copyright to FSF
<tpanmajia>oh that
<tpanmajia>I'm not surprised to see FSF in copyright lines now...
<youpi>tpanmajia: just one thing I see missing in the discussion: raw I/O access (inb/outb) are restricted through the I/O task mask in the x86 processor
<tpanmajia>oh got it
<youpi>root-owned processes can request allowance through the ioperm() function that calls into the kernel
<tpanmajia>youpi: MMIO or raw I/O?
<youpi>the actual call into the kernel is actually a capability-based thing
<youpi>and pci-arbiter will be able to just transfer that capability
<tpanmajia>got it
<youpi>thus effectively transferring the right to manipulate a given PCI card, and only that
<tpanmajia>oh this
<youpi>with DMA virtualization (VT-D), that's safe
<youpi>both MMIO and raw I/O
<tpanmajia>yeah finally
<youpi>not the same exact call, but same principle: capability
<tpanmajia>I'm trying to find just that
<youpi>the capability name?
<tpanmajia>I'm wondering that why there is no equivalent of process capability in Hurd
<tpanmajia>there's something similar in Minix IIRC
<youpi>there is, it's basically *all* about it
<youpi>*everything* is a capability
<youpi>an open file is simply a capability to read/write its data
<youpi>__i386_io_perm_create for the I/O port access
<youpi>the capabilities being represented by a mach port
<tpanmajia>...and I'm researching how a microkernel could restrict its potential of raw device access
<tpanmajia>s/its potential of//g
<youpi>err, by not providing the capability to everybody, simply?
<tpanmajia>...since without restriction everyone could access raw devices
<damo22>i was thinking of implementing IOMMU support for the pci-arbiter but its not easy
<youpi>it's not about "restricting", it's about "allowing"
<youpi>by default (without any mach port) a process can really not do much
<tpanmajia>oh this
<youpi>apart from allocating memory, creating a thread, and computing
<tpanmajia>I forgot Mach ports
<tpanmajia>can ports be understood as transfered capabilities...
<youpi>that's a way to see them
<youpi>transferred and transferrable
<tpanmajia>oh this
<bk1603>Hey! Is the task for GNU mach code cleanup still up for grabs? I'd like to help with it if possible :)
<tpanmajia>thanks everyone
<tpanmajia>it's really clarifying
<youpi>bk1603: sure, it's always welcome :)
<bk1603>youpi: Cool then! I will start right away. Also a disclaimer, I am a bit new to kernel development in general, and am also currently supposed to spend 6-7 hours on another project (the lockdown still leaves me with enough time though), so I might not be very productive in the beginning :p
<bk1603>Though I hope to learn a lot from this and improve over time
***rekado_ is now known as rekado
<janneke>i'm writing a shepherd service for guix (on gnu/linux) that starts a qemu vm running the hurd
<janneke>the working-title of that service is 'hurd-vm'
<janneke>but we were wondering if there's a real name for such a thing
<janneke>(thinking of neighborhurd, subhurd, ...)
<janneke>...thinking of a "childhurd"
<ThinkT510>would subhurd imply that the parent is a hurd
<janneke>that's my understanding "A sub-Hurd is like a neighbor Hurd, however, makes use of some resources provided by another Hurd." =>
<ThinkT510>it's a shame the website doesn't have any news posts since 2016. it gives the impression nothing noteworthy has happened since.
***slyfox_ is now known as slyfox