Notices by Demi Marie Obenour (alwayscurious@infosec.exchange), page 2

@gregkh @sima @sourcejedi Is this because dev_t was 32 bits back then?

@gregkh @sima The problem is that whether a device should be trusted depends on what slot it is plugged into 😞. Are there systems that do expose slot information? If so, which ones are they, and is there a way for userspace to get it on these systems?

@gregkh @sima @sourcejedi Even if the path is never reused, the device major and minor number can still be reused. Right now I think one needs a custom FUSE filesystem if one wants opening e.g. /dev/disk/by-diskseq/1 to be race-free, and that’s bad.

@gregkh @sima Some more questions:

1. Which entry in sysfs correspond to physical (as opposed to logical) topology? Is it the path under /sys/devices?
2. How can I go from this path to a PCI bus/slot/function?
3. Will this path change when other cards are added or removed or if the system firmware is updated?
4. Is there a way for driver probing to be deferred until after userspace can check the device against the actual topology of the machine? That would allow checking if the device that claims to be a serial port in slot X is actually supposed to be a serial port, or if it is a GPU passed through to a VM that the VM compromised and is now pretending to be a serial console. In the latter case the device would never be allowed to be used except for passthrough.

@gregkh @sima @sourcejedi I really wish that the kernel never reused /dev nodes or major:minor numbers. RIght now, one must do verification after calling open() if one wants to avoid race conditions. Of course, lots of programs do not do that.

@sima @gregkh What should one use to get a persistent identifier for PCI devices? Anyone doing PCI device passthrough that persists across reboots needs this.

@sima @gregkh What is actually wanted is to be able to detect the physical topology of the system, as determined by what card is plugged into what slot.

@gregkh Are you saying that people who cannot reboot every week should not use Linux?

That’s a valid position to have, but if it is accurate, it needs to be much more widely known so that embedded systems vendors know not to use Linux for their uptime-critical products.