Firefox 104 released

Posted Aug 28, 2022 9:31 UTC (Sun) by geuder (subscriber, #62854)
In reply to: Firefox 104 released by flussence
Parent article: Firefox 104 released

Excuse my ignorance, I am largely unfamiliar with hwmon. Why are privileged-only drivers unacceptable? Of course I don't want that my browser and other untrusted code access sensitivity data. But as root I want to have full access to my hardware.

to post comments

Firefox 104 released

Posted Aug 28, 2022 10:51 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (2 responses)

Being root does not inherently mean that you should have direct access to secrets that are held by the kernel, for instance. As a device owner you should have the ability to make that possible, but there's no reason in general that any runtime process running as root that has a vulnerability should be able to extract my disk encryption key.

Firefox 104 released

Posted Aug 28, 2022 12:34 UTC (Sun) by geuder (subscriber, #62854) [Link] (1 responses)

Right, the old model of root can do everything has been known to be not enough for ages. Then we got CAP_SYS_MAINTAINER which did not really help that much...

In a single user system like my Linux workstation or also any R&D system I need to do performance analysis on full access is what I want.

On the other side having my code running in the cloud, doesn't make me wanting that the sysadmin or even my virtual neighbor can extract my keys. But with current hardware that's never fully impossible, at least not in the sysadmin case.

What surprised me here that a Linux driver has been removed, obviously with the argument that it can be misused by root? Or what was the exact argument of privileged-only drivers should not exist in hwmon? It feels with this argument a lot of code would need to be removed from the kernel.

Firefox 104 released

Posted Sep 9, 2022 19:43 UTC (Fri) by flussence (guest, #85566) [Link]

The problem was that it created the first instance of a bunch of chmod-0400 files in /sys/class/hwmon, and it turns out libsensors has no grace when it's unexpectedly told "no" - error spam everywhere in `sensors` output. That constitutes a breakage of the kernel's stable userspace API rule and the only solution was to revert it outright.