Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in
 ttusb_dec_handle_irq() when DMA failures/attacks occur
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     mchehab@kernel.org, kstewart@linuxfoundation.org,
        tomasbortoli@gmail.com, sean@mess.org, allison@lohutok.net,
        tglx@linutronix.de, linux-media@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20200505142110.7620-1-baijiaju1990@gmail.com>
 <20200505181042.GD1199718@kroah.com>
 <0e4a86ee-8c4e-4ac3-8499-4e9a6ed7bd1e@gmail.com>
 <20200506110722.GA2975410@kroah.com>
 <b3af10e3-8709-3da0-6841-e5ddd6b4a609@gmail.com>
 <20200506155257.GB3537174@kroah.com>
From:   Jia-Ju Bai <baijiaju1990@gmail.com>
Message-ID: <46615f6e-11ec-6546-42a9-3490414f9550@gmail.com>
Date:   Thu, 7 May 2020 00:48:47 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200506155257.GB3537174@kroah.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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"?

>
>> 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.

>
> 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 :)


Best wishes,
Jia-Ju Bai