Free user space for non-graphics drivers [LWN.net]

Free user space for non-graphics drivers

Posted Jun 7, 2020 8:26 UTC (Sun) by marcH (subscriber, #57642)
In reply to: Free user space for non-graphics drivers by blackwood
Parent article: Free user space for non-graphics drivers

> These compute/gpu things run touring complete code with hw security features you have to take on faith, ...

So this is basically Asymetric Multi Processing (CPU and [GP]GPU) with one side running open-source (Linux) and the other side running random closed source code with little or no security boundary between the two processors. Correct?

To be honest I'm not sure how that compares from a security perspective to loading a dozen /lib/firmwares without even a debug statement in the firmware loader showing every file loaded. Which is worse? There are has been for a long time more than two processors running closed source in any modern [D]SoC; how much isolation between them? Can the kernel even tell?

[D] Distributed

to post comments

Free user space for non-graphics drivers

Posted Jun 7, 2020 21:49 UTC (Sun) by marcH (subscriber, #57642) [Link]

> loading a dozen /lib/firmwares without even a debug statement in the firmware loader showing every file loaded.

Of course /lib/firmware doesn't include a number of other closed-source bits loaded even before the kernel (generally because they play a role in... booting the kernel).

https://www.ptsecurity.com/ww-en/analytics/disabling-inte...

Now the security of these is different because they can't be unsigned code, unlike most stuff in /lib/firmware I guess or the GPU/AI workloads mentioned above. But they're not open-source either.

Free user space for non-graphics drivers

Posted Jun 7, 2020 22:11 UTC (Sun) by mfuzzey (subscriber, #57966) [Link] (2 responses)

>I'm not sure how that compares from a security perspective to loading a dozen /lib/firmwares

That depends what is done with the stuff loaded from lib/firmware.

Normally it will be loaded onto some other device so the risk depends on the level of hardware access that device has to memory and the degree to which Linux can restrict it (by an IOMMU for example).

So for example firmware loaded into an I2C connected touchscreen controller is unlikely to be able to do much harm since that bus provides no DMA capacity, worst case it could simulate clicks to enter false data (assuming it knows what is on the screen).

On the other hand firmare for hardware with bus mastering DMA capabilities not restricted by an IOMMU basically has full system access.

Free user space for non-graphics drivers

Posted Jun 8, 2020 19:05 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> Normally it will be loaded onto some other device so the risk depends on the level of hardware access that device has to memory and the degree to which Linux can restrict it (by an IOMMU for example).

IOMMU is apparently hit-and-miss: https://lwn.net/Articles/782381/

> On the other hand firmare for hardware with bus mastering DMA capabilities not restricted by an IOMMU basically has full system access.

Thanks, so let's stop pretending the kernel cares about attack vectors from co-processors when it doesn't even log the filenames loaded from /lib/firmware/ by default [*]

These attack vectors and pseudo-security concerns being out of the picture, that leaves only the maintenance (troubleshooting and refactoring) questions. I suspect the kernel <-> GPU interfaces are generally much more complex than the interfaces between the kernel and stuff in /lib/firmware, hence the reluctance. Is
that higher GPU complexity why there is a "line in the sand" somewhere in the middle, do I get that right? Or because /lib/firmware has been causing fewer maintenance headaches in the past? Or both.

[*] As the distributed system bootloader that it is, in an ideal world request_firmware() should check signatures. I digress.

Free user space for non-graphics drivers

Posted Jun 8, 2020 19:43 UTC (Mon) by mfuzzey (subscriber, #57966) [Link]

> I suspect the kernel <-> GPU interfaces are generally much more complex than the interfaces between the kernel and stuff in /lib/firmware, hence the reluctance.

I think it's also a question of exposure of the interface to an attacker.

On the general /lib/firmware side the issue is more potentially malicious firmware.

Unpriveleged users can't (or shouldn't) be able to change the firmware files. Most of the time the firmware won't be receiving commands directly from userspace without the kernel sanitizing them first. In fact normally the uapi will be something standard on Linux for that subsystem and the commands sent to the firmware will be completely determined by the kernel driver.

On the GPU side though it's a bit different as unpriveleged applications can submit commands to the GPU via /dev/dri (otherwise stuff like games wouldn't work). The kernel is mostly a pipe. So a malicious actor who has knowledge of a GPU exploit could submit crafted buffers to compromise the system.

The kernel can't assume that userspace is Mesa or something trusted.

But the existence of an open source userspace, even if it is bypassed by an attacker, means that the knowledge is available for the kernel to sanitize the commands. Up to a point at least because there could still exist undiscovered holes. But it's way better than an open source kernel driver accepting opaque command buffers with no idea what they do or the security implications.

Free user space for non-graphics drivers

Posted Jun 8, 2020 2:32 UTC (Mon) by pabs (subscriber, #43278) [Link] (6 responses)

Is anyone working on reverse engineering /lib/firmware? There is precious little open firmware out there and it is mainly for increasingly obsolete hardware.

https://wiki.debian.org/Firmware/Open

Free user space for non-graphics drivers

Posted Jun 8, 2020 12:40 UTC (Mon) by pizza (subscriber, #46) [Link] (5 responses)

As a general response, nobody is working on reverse-engineering the stuff in /lib/firmware, but there are some folks working on specific devices with varying degrees of success.

The thing is, each device has to be independently reverse-engineered, a process so involved that by the time the effort yields something usable, the device will have been obsolete for a decade.

(At least these days the embedded CPUs are usually an ARM variant, or some other licensed/documented core...)

Free user space for non-graphics drivers

Posted Jun 8, 2020 12:42 UTC (Mon) by pabs (subscriber, #43278) [Link] (4 responses)

Do you have some examples of the projects you mentioned?

Free user space for non-graphics drivers

Posted Jun 8, 2020 14:26 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

Offhand I can only think of three that saw success:

* Broadcom wifi f(openfwwf)
* Cypress FX/FX2 (fx2lib)
* EMU10K1 (Sound Blaster Live/Audigy)

But there are others out there in varying stages of functionality.

Free user space for non-graphics drivers

Posted Jun 9, 2020 2:09 UTC (Tue) by pabs (subscriber, #43278) [Link] (2 responses)

openfwwf was already on the wiki, along with Prism54 FreeMAC, and the carl9170fw and open-ath9k-htc-firmware projects released by Atheros.

http://netweb.ing.unibs.it/~openfwwf/
https://perso.m-labs.hk/sb/prism54/freemac.html
https://perso.m-labs.hk/sb/prism54/snapshots/prism54_free...
https://github.com/qca/open-ath9k-htc-firmware
https://github.com/chunkeey/carl9170fw

I added fx2lib (and sigrok fx2lafw) to the wiki.

https://github.com/djmuhlestein/fx2lib/
https://sigrok.org/wiki/Fx2lafw

I wasn't able to find anything about the EMU10K1 work you mentioned, only about the GPLed but sourceless blobs (sigh) in the alsa-firmware git repository:

https://github.com/alsa-project/alsa-firmware/tree/master...

If you have any links to the EMU10K1 work or the others, that would be welcome.

Free user space for non-graphics drivers

Posted Jun 9, 2020 2:40 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> https://perso.m-labs.hk/sb/prism54/freemac.html

I'm not sure this really belongs on the list, as they don't know how to control anything beyond the basic ARM9 core and other off-the-shelf peripherals (eg PCI and USB cores). Hardware timers and the radio itself are complete unknowns, So while technically there is "open firmware" it's good for little more than blinking LEDs.

(In a former life, I had access to the firmware source code and low-level hardware documentation for the entire p54 "Arm MAC" family..)

> I wasn't able to find anything about the EMU10K1 work you mentioned, only about the GPLed but sourceless blobs (sigh) in the alsa-firmware git repository

That firmware appears to be FPGA bitstreams for certain pro-grade E-MU hardware, and isn't needed for the prosumer SBLive/Audigy cards built on the EMU10K1/10K2 chips.

(IIRC, if you plug in a SBLIve/Audigy card, it does not rely on any external firmware, though the driver uploads little DSP snippets to implement driver-exposed functionality such as multichannel mixing and other such things. Those DSP programs were written using the 'as10k1' assembler, users could upload arbitrary programs if they so chose..)

Free user space for non-graphics drivers

Posted Jun 9, 2020 3:18 UTC (Tue) by pabs (subscriber, #43278) [Link]

Hmm, I can't find anything that uses as10k1. It seems instead the linux.git sound/pci/emu10k1/emufx.c driver has a couple of functions called by the OP/A_OP defines that use instruction set defines in the include/uapi/sound/emu10k1.h header.