Message-ID: <20200506174345.GA3711921@kroah.com>
Date:   Wed, 6 May 2020 19:43:45 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
Cc:     mchehab@...nel.org, kstewart@...uxfoundation.org,
        tomasbortoli@...il.com, sean@...s.org, allison@...utok.net,
        tglx@...utronix.de, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in
 ttusb_dec_handle_irq() when DMA failures/attacks occur

On Thu, May 07, 2020 at 12:48:47AM +0800, Jia-Ju Bai wrote:
> 
> 
> On 2020/5/6 23:52, Greg KH wrote:
> > On Wed, May 06, 2020 at 11:30:22PM +0800, Jia-Ju Bai wrote:
> > > 
> > > On 2020/5/6 19:07, Greg KH wrote:
> > > > On Wed, May 06, 2020 at 06:13:01PM +0800, Jia-Ju Bai wrote:
> > > > > I have never modified DMA memory in the real world, but an attacker can use
> > > > > a malicious device to do this.
> > > > > There is a video that shows how to use the Inception tool to perform DMA
> > > > > attacks and login in the Windows OS without password:
> > > > > https://www.youtube.com/watch?v=HDhpy7RpUjM
> > > > If you have control over the hardware, and can write to any DMA memory,
> > > > again, there's almost nothing a kernel can do to protect from that.
> > > I think that each device can only access its own DMA memory, instead of any
> > > DMA memory for other hardware devices.
> > That's not true at all for all systems that Linux runs on.
> 
> I am not sure to understand this.
> For example, a driver requests DMA memory with "len" size by using:
>    mem = dma_alloc_coherent(..., len, ...);
> I think that the driver can only access DMA memory between "mem" and "mem +
> len", is it true?
> Can the driver access other DMA memory using some code like "mem + len *
> 10"?

Depends on the hardware platform.

> > > A feasible example is that, the attacker inserts a malicious device via
> > > PCI-E bus in a locked computer, when the owner of this computer leaves.
> > This is a semi-well-known issue.  It's been described in the past
> > regarding thunderbolt devices, and odds are, more people will run across
> > it again in the future and also complain about it.
> > 
> > The best solution is to solve this at the bus level, preventing
> > different devices access to other memory areas.
> > 
> > And providing physical access control to systems that you care about
> > this type of attack for.
> > 
> > Again, this isn't a new thing, but the ability for us to do much about
> > it depends on the specific hardware control, and how we set defaults up.
> 
> Yes, I agree that this issue is not new, because DMA attacks are old
> problems.
> But I am a little surprised that many current drivers are still vulnerable
> to DMA attacks.

Given that the attack vector is very hard to actually do, that's not
a suprise.

It's only a very recent thing that Linux drivers have started to work on
"we don't trust the data coming from the hardware" path.  Previously we
always trusted that, but did not trust data coming from userspace.  So
work on fixing up drivers in this area is always encouraged.

An example of this would be all of the fuzzing that USB drivers have
been getting with custom loop-back interfaces and the like over the past
year or so.  Expanding that to "we don't trust PCI device data" should
be the next step on this, and would help out your area as well.

> > If you trust a device enough to plug it in, well, you need to trust it
> > :)
> 
> Well, maybe I need to trust all devices in my computer :)
> 
> Anyway, thanks a lot for your patient explanation and reply.
> If you have encountered other kinds of DMA-related bugs/vulnerabilities,
> maybe I can help to detect them using my static-analysis tool :)

Did you only find a problem in this one driver?  Have you run it on any
more "complex" drivers and gotten any good results showing either that
we are programming defensively in this area, or not?

thanks,

greg k-h

Powered by blists - more mailing lists