IRC channel logs

***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>s/clarity/clarify/

<tpanmajia>I'm not quite sure whether there is a mechanism provided by GNU Mach that can restrict raw device access

<tpanmajia>...to 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...

<damo22>yes

<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

<damo22>glibc

<tpanmajia>in glibc Hurd port?

<damo22>yeah

<tpanmajia>oh brilliant

<tpanmajia>I forgot the syscall interface in libc

<tpanmajia>...so 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>oh

<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>wow

<tpanmajia>so the ability of sharing devices is determined by the actual device driver?

<damo22>probably

<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>yes

<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

<tpanmajia>rumpkernel?

<damo22>it currently needs root

<damo22>yes

<tpanmajia>get FreeBSD sources, tweak and then profit?

<damo22>NetBSD

<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>:)

<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>yes

<damo22>it actually implements the device node

<tpanmajia>wow

<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>oh

<tpanmajia>it's a disk driver, isn't it?

<damo22>yes

<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>s/does/do

<damo22>no

<tpanmajia>no...?

<tpanmajia>therefore how does the mach device interface work?

<tpanmajia>by standardized kernel IPC?

<damo22>let me find the code

<tpanmajia>ok thx

<damo22> http://git.zammit.org/hurd-sv.git/tree/rumpdisk/main.c?id=fb3bb7b998654cc67ea31a2961f7a8e454b5a00e#n51

<tpanmajia>are you a FSF employee?

<damo22>no

<damo22> http://git.zammit.org/hurd-sv.git/tree/rumpdisk/block-rump.c?id=fb3bb7b998654cc67ea31a2961f7a8e454b5a00e#n327

<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>s/that/this/

<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>thx

<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

<tpanmajia>yes

<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." => https://www.gnu.org/software/hurd/hurd/subhurd.html

<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

IRC channel logs

2020-06-11.log