From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7DE4C28CBC for ; Wed, 6 May 2020 15:53:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B4CE82070B for ; Wed, 6 May 2020 15:53:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588780382; bh=5Ml24nbPp+6AL6quJRya43kmFdmuY1+mzGDKmLrVOeU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=F/oTNj2ln/FyoHjIEKFblzp88wGARUGWeNF+5KYw+mqzlzbFSPiD5N+AmAyglJR10 NgvUnvlmxRh3nUW7H7Enz0ZQm7XOPfqSGqTjGzTNnrTzhAVDl7W8AZZogaiWbTiXMP Vcotohd0PLIKH3+R2FCryP37EBRssTMECuOzGRGA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729586AbgEFPxC (ORCPT ); Wed, 6 May 2020 11:53:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:48138 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729417AbgEFPxB (ORCPT ); Wed, 6 May 2020 11:53:01 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 59C1820708; Wed, 6 May 2020 15:52:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588780379; bh=5Ml24nbPp+6AL6quJRya43kmFdmuY1+mzGDKmLrVOeU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iYVbL9gMCwnHM/HYKWQJn/0BVizANqE58ooD8Hd8cR1xSdbyH3a58WXs3/tITEt4M XyQ5jQZg3AKyH/f+PER1iA8AmRrIYg+6W9KtyHUeOGt+CrAVFZ5S+uBee6/1OcteA3 qmSH3iq/rmYHaOHlxuiQoWglNOywPtSr38QlhX+s= Date: Wed, 6 May 2020 17:52:57 +0200 From: Greg KH To: Jia-Ju Bai 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 Subject: Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in ttusb_dec_handle_irq() when DMA failures/attacks occur Message-ID: <20200506155257.GB3537174@kroah.com> References: <20200505142110.7620-1-baijiaju1990@gmail.com> <20200505181042.GD1199718@kroah.com> <0e4a86ee-8c4e-4ac3-8499-4e9a6ed7bd1e@gmail.com> <20200506110722.GA2975410@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > Thus, it is dangerous that the whole kernel can be attacked via a simple > malicious device, through some vulnerabilities in the trusted driver. True, so restrict physical access. Or use a good iommu if you care about this :) > 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. If you trust a device enough to plug it in, well, you need to trust it :) thanks, greg k-h