[HN Gopher] Restricted DMA
       ___________________________________________________________________
        
       Restricted DMA
        
       Author : Tomte
       Score  : 29 points
       Date   : 2021-01-08 09:53 UTC (13 hours ago)
        
 (HTM) web link (lwn.net)
 (TXT) w3m dump (lwn.net)
        
       | 95014_refugee wrote:
       | > Mobile systems usually lack an IOMMU.
       | 
       | That should read "non-Apple mobile systems".
       | 
       | And you might stop to wonder why that is.
        
       | jstanley wrote:
       | In case you're wondering how this is a security feature...
       | 
       | > Readers may be wondering, though, how the use of the swiotlb
       | will protect the system against a malicious or compromised
       | device; such devices may well ignore polite requests to restrict
       | their DMA activities to the designated area, after all. The
       | answer is that it will not protect systems from this type of
       | attack -- at least, not on its own.
       | 
       | ...it isn't.
       | 
       | This is obviously useful otherwise nobody would be working on it,
       | but I don't really understand what this is defending against. Is
       | it just so that buggy drivers/hardware don't cause so much
       | trouble?
        
         | als0 wrote:
         | > Is it just so that buggy drivers/hardware don't cause so much
         | trouble?
         | 
         | Yes, it's intended to reduce the impact of buggy drivers. A
         | driver itself could have a transient bug that corrupts kernel
         | memory of some other subsystem. Or an attacker can trick a
         | vulnerable driver into performing a DMA transaction to a
         | sensitive area of memory.
        
         | monocasa wrote:
         | Cribbing from the comments on the original article, this does
         | still seem to depend on hardware support to be helpful, but
         | doesn't require an IOMMU. Doing things like reducing the size
         | of the PCIE controller's aperture into RAM, or using ARM's
         | Secure/Nonsecure modes in a cute on way some chips can give you
         | a simple base+bounds restriction for all DMA, that's still
         | beneficial but not really a full MMU.
         | 
         | https://lwn.net/ml/linux-kernel/d7043239-12cf-3636-4726-2e3b...
         | 
         | So that paragraph from the article is at best extremely
         | confusing.
        
         | temac wrote:
         | On existing hardware it is mostly useless from a security point
         | of view, but if you design new hardware it is way simpler to
         | have per device physical base+lenght limits than a full
         | featured IOMMU. This is to be restricted to somehow light
         | embedded devices though. For a generalist expensible computer
         | it would not make sense.
        
         | ajross wrote:
         | Buggy drivers and device firmware do indeed cause a ton of
         | trouble. This looks to me like it's reducing the attack surface
         | in a very reasonable way. A driver written to this API is
         | likely to be much more robust than one that deals with raw
         | memory itself.
         | 
         | But yes: it's not hardware isolation.
        
           | monocasa wrote:
           | I would think that adding an abstraction layer like this
           | would increase the number of bugs, not reduce them.
        
         | diegocg wrote:
         | Hardware hasn't historically been seen as a security boundary.
         | A buggy driver has always been able to take over your computer
         | and crash it by fiddling with the hardware.
        
           | monocasa wrote:
           | Right, but the question is what are these extra memcpys
           | getting you then other than using up your CPU just to bounce
           | bytes around?
           | 
           | And the answer is that there exists hardware today that can
           | help restrict DMA access to main RAM, but take the form of
           | base+bounds primitives rather than a full MMU. This appears
           | to be in support of that.
        
       | saagarjha wrote:
       | > Using this kind of bounce-buffering offers some benefit on its
       | own. Your editor, who has written device drivers in the past,
       | would never have committed such an error, but it is not unheard
       | of for driver bugs to result in a device performing DMA when the
       | rest of the system thinks it should be idle. Having memory
       | buffers seemingly randomly overwritten in unreproducible ways can
       | (again, your editor relies on the word of others for this) result
       | in corrupt data, painful debugging sessions, and excessive
       | alcohol use. By separating the buffer used by the device from the
       | buffer used by the kernel, restricted DMA can mitigate many of
       | the more unpleasant effects of this sort of bug.
       | 
       | lol
        
       ___________________________________________________________________
       (page generated 2021-01-08 23:02 UTC)