27 ms·

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

ben-schaaf 2y ago
This is for hardware encoding/decoding.
ec109685 2y ago
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.
- fulafel 2y ago
  What happens if you send bad bitstreams to the hardware?
  - adastra22 2y ago
    You can have it overwrite kernel memory.
    - screcth 2y ago
      Isn't it possible to restrict what memory regions a device may have access to?
      - adastra22 2y ago
        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.
        Firerouge 2y ago
        > 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?
        stefan_ 2y ago
        Maybe the grandparent is trying to refer to IOMMUs.
        adastra22 2y ago
        This. Your system will almost certainly have an IOMMU. But that can’t be said for all systems that the Linux kernel supports.
        lathiat 2y ago
        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 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971699 Some other history: https://www.phoronix.com/news/Intel-IOMMU-Gfx-Default-Try 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-video/firewire-memory-attack-a-how-to-video/ 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 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 :)
  - Ecoste 2y ago
    Explosions
  - johntb86 2y ago
    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.
    - Animats 2y ago
      Which hardware decoders are not callable from user space and unsafe to call from kernel space?
      - saagarjha 2y ago
        Badly-implemented ones
    - deleted 2y ago
      [deleted]
  - deleted 2y ago
    [deleted]
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 ago
  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.
  - gary_0 2y ago
    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.
    - 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. :(
        2y ago
akira2501 2y ago
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.
- deleted 2y ago
  [deleted]
saagarjha 2y ago
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

ben-schaaf 2y ago

This is for hardware encoding/decoding.

ec109685 2y ago

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.

fulafel 2y ago
What happens if you send bad bitstreams to the hardware?
- adastra22 2y ago
  You can have it overwrite kernel memory.
  - screcth 2y ago
    Isn't it possible to restrict what memory regions a device may have access to?
    - adastra22 2y ago
      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.
      - Firerouge 2y ago
        > 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?
        stefan_ 2y ago
        Maybe the grandparent is trying to refer to IOMMUs.
        adastra22 2y ago
        This. Your system will almost certainly have an IOMMU. But that can’t be said for all systems that the Linux kernel supports.
        lathiat 2y ago
        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 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971699 Some other history: https://www.phoronix.com/news/Intel-IOMMU-Gfx-Default-Try 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-video/firewire-memory-attack-a-how-to-video/ 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 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 :)
- Ecoste 2y ago
  Explosions
- johntb86 2y ago
  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.
  - Animats 2y ago
    Which hardware decoders are not callable from user space and unsafe to call from kernel space?
    - saagarjha 2y ago
      Badly-implemented ones
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]

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 ago
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.
- gary_0 2y ago
  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.
  - 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. :(
      - 2y ago

akira2501 2y ago

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.

deleted 2y ago
[deleted]

saagarjha 2y ago

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