4 ms·

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 co

• drdaeman 2y ago
  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.
  • gary_0 2y ago
    Ah. I see. And then the kernel needs to bend over backwards to cover up the security holes and design flaws. :(
    • jeanlucas 2y ago
      Especially security holes that are intended.
• toast0 2y ago
  To avoid the cost of copying the data from wherever it was to where it needs to be...
• Veserv 2y ago
  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.
  • binary132 2y ago
    and even a correct hardware specification could have an implementation bug...