4 ms·
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
by gary_0 2y ago
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?
- jeffbee 2y agoThe 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.
- gary_0 2y agoWhy 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.
- drdaeman 2y agoIt 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.
- toast0 2y agoTo avoid the cost of copying the data from wherever it was to where it needs to be...
- Veserv 2y agoThe 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.
- binary132 2y agoand even a correct hardware specification could have an implementation bug...
- ok123456 2y agoHow 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.
- singron 2y agoI 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.
- saagarjha 2y agoThis is correct, typically these devices need some page tables/IOMMU be set up to be told where they should read and write from.
- surajrmal 2y agoEven 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.