Hacker News Reader

Comment by codedokode | Hacker News Reader

I don't understand why video codecs must be in kernel and run with supervisor privileges. Why can't they run in a userspace?

View on HN

I believe the reason is that it’s not safe to send arbitrary bitstreams directly to hardware decoders and given the “stateless” nature of them, you need something trusted to run the full video encoder / decoder logic.

What happens if you send bad bitstreams to the hardware?

Explosions

You can have it overwrite kernel memory.

Isn't it possible to restrict what memory regions a device may have access to?

No, it's on the PCIe bus. It sends data straight to RAM, circumventing the memory controller on the CPU.

SOME systems have write protection logic on the RAM controllers themselves, but this is not universal.

> SOME systems have write protection logic on the RAM controllers themselves

How can one tell if a system has RAM controller based security, what name does this write protection go by?

Maybe the grandparent is trying to refer to IOMMUs.

This. Your system will almost certainly have an IOMMU. But that can’t be said for all systems that the Linux kernel supports.

However your IOMMU may not actually be in use. It's not in use by default on Linux and on most Linux distros as it tends to break things on random hardware that isn't setup right. It tends to work most of the time on servers.

Ubuntu 22.04 tried to turn it on by default but switched it off again due to random mostly graphics related regressions on random hardware: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971699

Some other history: https://www.phoronix.com/news/Intel-IOMMU-Gfx-Default-Try

We really do need it though. I am always reminded of the very old Apple "Firewire Memory Bypass" which rendered flames to the screen just by plugging a firewire device in - because firewire had direct and originally unprotected DMA access: https://www.pentestpartners.com/security-blog/hack-demo-vide...

It is for this reason that even without IOMMU, as a workaround, you have to often give permission to thunderbolt devices to connect. Some details on that here: https://wiki.archlinux.org/title/Thunderbolt

There is also a small but noticable performance hit to using the IOMMU, not so noticable on a general setup but if you are doing high-speed disk & network I/O like ceph storage in excess of 10Gbit/s or millions of IOPS you will notice it. You can Google that.

You can also run into other weird behaviour, for example when using kdump to create a kernel crash dump it will kexec from the old kernel into a new kernel to produce the crash dump. The system doesn't go through a firmwire/uefi/bios reset so the hardware state of network cards, etc, doesn't get reset. So if you have any hardware driver state that isn't properly reset, you might for example have your network card DMA a packet directly into host memory in the time window before it gets reset. With IOMMU that might trigger errors, with it off it will hopefully not overwrite anything important but may also overwrite something important :)

These things are all of course fixable, but since it's still off by default much of the time, lots of these bugs persist for a long time.

Disclaimer: I am not an expert in this area it's just anecodtes from my life as a Linux Geek & Support Engineer. Should be about 90% accurate but I am sure I glossed over some solid details :)

Iommus are very common on PC grade hardware, as well as premium smart phones. They just aren't that common on lower end phones and iot devices, but pcie is also fairly uncommon on those devices which makes your comment a bit confusing.

There's a lot of moderately powerful embedded Linux systems out there that either don't have an MMU equivalent or have one that the vendor BSP doesn't use by default. Too give one example, Xilinx doesn't set up the SMMU for AXI DMA devices on Zynq by default, iirc.

As I understand, Zync is a FPGA, it is not used in consumer devices like laptops and smartphones so nothing bad happens even if there is a vulnerability.

Most of the Zynq line include hard ARM A and/or R processors. Either way, just because something isn't in consumer electronics doesn't man vulnerabilities aren't important. Imagine a vulnerability in the control systems for your car or the planes you use.

In theory the hardware should return corrupted video, return an error, or at least hang, but not anything worse. It's worse if the data structures specifying memory buffers are incorrect; then you may be able to read/write arbitrary memory.

Which hardware decoders are not callable from user space and unsafe to call from kernel space?

Badly-implemented ones

This is for hardware encoding/decoding.

I had the same question. If your chip can do, say, the DCT in hardware, why not just expose that unit directly to userspace? And if userspace sends invalid data to that unit, surely the kernel can just handle the fault and return an error? I must be missing something.

At any rate, it's unfortunate that entire media file formats have to run in kernel space in order to implement hardware acceleration. There's no better way to do it?

The kernel has to interpose at least a little bit because some of these hardware devices can read and write anywhere, so you can't just let random users sent them commands.

Why would a hardware codec need the ability to arbitrarily read/write the entire address space, though? That seems like a needlessly dangerous design when it could easily have a register that restricts it to a kernel-designated address range.

It shouldn’t, but we live in a world where cheapest products that just barely work overwhelmingly win the market (most obvious proof is IoT, but it applies to just about everything else). General consumer market doesn’t care about proper designs, doesn’t understand geeky security concerns and whatever - if something somehow works satisfactorily enough for acceptable number of situations - it gets released and marketed, successfully.

Sorry. I hate it too.

Ah. I see. And then the kernel needs to bend over backwards to cover up the security holes and design flaws. :(

Especially security holes that are intended.

To avoid the cost of copying the data from wherever it was to where it needs to be...

The general answer is so that you can get the output at a program-configurable location rather than a hardware-fixed location. For instance, I want to shove out a frame of data and then get the decoded data back into a appropriately-sized static buffer. The hardware could always dump that at memory address 0x5000 and then I could copy it into my buffer, but from a programming perspective it is a lot cleaner if it just shoves the bytes directly into my buffer.

It is analogous to passing a pointer to a buffer to a library function so that the library can write the contents of the buffer directly. You rely on the library (device) operating properly and not writing outside of the designated buffer. That is the baseline.

As you state, you could add a enforcement mechanism that defines the extents of memory the external actor is allowed to store like how many language runtimes check and disallow out-of-bounds accesses. However, if you have multiple outstanding buffers, control structures, or other complex device-accessible structures then enforcing precise "bounds" checking rapidly demands very complex "bounds" definition/enforcement. Language runtimes can do this because they support arbitrary code, but enforcing in hardware that, say, every access lies within the nodes of a "user-constructed" red-black tree rapidly becomes infeasible.

You basically get one of two options at that point, either you rely on the hardware working properly and do nothing, or you design your driver to only require coarser isolation that fits within hardware-definable boundaries. Most opt for the former. If you do the latter then there are various ways of actually enforcing the isolation such as IOMMUs or you could have a DMA controller that basically functions as a IO MPU (define ranges the device can access) (I am not actually aware of any DMA controllers that actually do this as a security measure, but it is theoretically possible).

You do have to be careful that they actually enforce the isolation. For instance, I question if the x86-64 IOMMU implementation is actually safe against a malicious device due to certain supported features such as device IO TLBs, but I do not know about the actual hardware implementation to know for certain.

and even a correct hardware specification could have an implementation bug...

How is this interposition different from what the virtual memory subsystem already does? Many other memory-mapped devices have kernel support. Access to these is usually mediated through udev or an equivalent on Linux.

I have no specific knowledge, but it seems similar to issues we had before iommus. E.g. maybe the device accesses physical memory without memory protection and/or virtual address mapping, so the kernel needs to do that in its behalf.

This is correct, typically these devices need some page tables/IOMMU be set up to be told where they should read and write from.

Even without an iommu, there are still benefits to placing this logic in user space. It doesn't have to be all or nothing. Ideally if and when it becomes commonplace, iommus will also become more common.

Well, for example, if you only have one hardware decoder and two processes that want to use it someone’s got to mediate access to it

It's because the value proposition of Rust and the reality of it's implementation don't match. So, they went through all this effort to put it in the kernel, but then realized, it's not really useful for much, outside of making "safe" drivers that no one really needs.

Reply on news.ycombinator.com