Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp77575ybt; Tue, 30 Jun 2020 15:11:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxOfrNkfATSMrGGZ8Jh0tpRzSBeye2x3/czPb54dSZs7J9WSKFeNg3eZASBGGIG1Qr+BMCC X-Received: by 2002:a17:906:fa92:: with SMTP id lt18mr8305160ejb.534.1593554700984; Tue, 30 Jun 2020 15:05:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593554700; cv=none; d=google.com; s=arc-20160816; b=KQ5QR1BYLBVRn+LwF4FcEmoAJrnZFhH/BTPwyv1g2zPrDKY4xax0uCwtwDB0Bw9Rd6 AAF2X6b20aiJGxhB283UYy23fb5pcwSn0aybh9UGyvhLUKvicVoaaShBl0MdzGHcD09X 8G6RGOefCa/imeG6GsYygYVP2An5r7IuaQqvELU+dYtgD7KVbDx5LzzSX+xYDV2qDpbd 3lEd1Y5i2NIZqJr57dXQ6gYwAUalIzhz/ZZsVSQ0lohTRw/ep23QTqRF7DkrJ1oGx3OB 0yNmtHGL2Z28oF772/b0kCIOo67I3VK8s8EMGch8HwHICtd+tYwYhfs4w2bjOwb4PVuF FixA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=aKL1xqp1oFLEKU9DF08YrWhlv2wj+NMSO0n/Vz+ixO0=; b=Bskh3BcytjScwE+/X0xgMjJbfHVkDzgJovoK57wy1pjlOHbw9bMS6s+ItbHSSc99lA 0ojIzZsLwAzmpEDsaAabisOSf/nH/yi0/Yxz95Kh2JJnBpVp0AkTTaidfDvRtpbCNhsi F/TToGdoBBwR2Ivasz1/2OzlQ2ybiyupjfWWFG9XBsIpyPxJQI1Fvx1Z4wslHWgE8aKg sjrBzXfnF1aY3ii6BAx+vNUB1z9PXE+QOpDnRPQNa3nrijqHMYi0HoEVWc4j4yRbw4r7 77/cxR+mgdohy7mLqcSNhVfej91o8RrlEBnC/ptoXtu4nxem9PGjv30av5UktVfDT3fo szqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dv20si2587589ejb.582.2020.06.30.15.04.36; Tue, 30 Jun 2020 15:05:00 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728720AbgF3VqD (ORCPT + 99 others); Tue, 30 Jun 2020 17:46:03 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:53576 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728109AbgF3VqD (ORCPT ); Tue, 30 Jun 2020 17:46:03 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 797B31C0C0A; Tue, 30 Jun 2020 23:45:59 +0200 (CEST) Date: Tue, 30 Jun 2020 23:45:59 +0200 From: Pavel Machek To: Jesse Barnes Cc: Greg Kroah-Hartman , Rajat Jain , Rajat Jain , Bjorn Helgaas , "Raj, Ashok" , "Krishnakumar, Lalithambika" , Bjorn Helgaas , linux-pci , Mika Westerberg , Jean-Philippe Brucker , Prashant Malani , Benson Leung , Todd Broch , Alex Levin , Mattias Nissler , Zubin Mithra , Bernie Keany , Aaron Durbin , Diego Rivas , Duncan Laurie , Furquan Shaikh , Christian Kellner , Alex Williamson , Joerg Roedel , Linux Kernel Mailing List Subject: Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers Message-ID: <20200630214559.GA7113@duo.ucw.cz> References: <20200602050626.GA2174820@kroah.com> <20200603060751.GA465970@kroah.com> <20200603121613.GA1488883@kroah.com> <20200605080229.GC2209311@kroah.com> <20200607113632.GA49147@kroah.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > Yes such drivers should be fixed, no doubt. But without lots of > fuzzing (we're working on this) and testing we'd like to avoid > exposing that attack surface at all. >=20 > I think your suggestion to disable driver binding once the initial > bus/slot devices have been bound will probably work for this > situation. I just wanted to be clear that without some auditing, > fuzzing, and additional testing, we simply have to assume that drivers > are *not* secure and avoid using them on untrusted devices until we're > fairly confident they can handle them (whether just misbehaving or > malicious), in combination with other approaches like IOMMUs of > course. And this isn't because we don't trust driver authors or > kernel developers to dtrt, it's just that for many devices (maybe USB > is an exception) I think driver authors haven't had to consider this > case much, and so I think it's prudent to expect bugs in this area > that we need to find & fix. We normally trust the hardware NOT to be malicious. (Because if hacker has physical access to hardware and lot of resources, you lost). This is still true today, but maybe trusting USB devices is bad idea, so drivers are being cleaned up. PCI drivers will be WORSE in this regard. And you can't really protect against malicious CPU, and it is very very hard to protect against malicous RAM (probably not practical without explicit CPU support). Linux was designed with "don't let hackers near your hardware" threat model in mind. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCXvuylwAKCRAw5/Bqldv6 8vGdAJ0QKiY2OtzgdgyV2OtyuW+u9KMnagCcD9BR/9VGydJ0oNx7BA9liQVujEY= =2jEj -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh--