Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4531006ybg; Mon, 8 Jun 2020 10:06:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPRGSI8SL8evtfj0XOv+oZP5owBTAejoN990MthtJYIUNuqmxEoyBsyWE7u5xnXFbVKrR0 X-Received: by 2002:a17:906:71b:: with SMTP id y27mr14855627ejb.537.1591635986754; Mon, 08 Jun 2020 10:06:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591635986; cv=none; d=google.com; s=arc-20160816; b=DbjRnIdlWOOh92l9W8nAw7O3+4iTr1IaHkMvKcjjX2yDy7M6Yl9DdqAMwL7z8SNkaO 2R28NWnuFAT6jxXwVOWy+mPGKx3UThbU84cJIsUEpEru4STm0EMWfJmVJGiLzu8/rTEy fEpyHWzlpXCapQbyRknpA0X0uXqTS9TsqnCpAQE4uGRb0GU7/vxQeZ9VGuygD5X4Z5Dc VEvw235CpJYhmAVcLsWjOO2fAUJlLCAF8E/Fl6CqRoTdTnEUwGivubOJ0aJMfJRFZ6th CGUwFZFUT7joe3DJ71RyPf0bnPaR1+F0EAwdWVhgRHedYvDauiAwihfRfTIuuBmw2LAi 8ZKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=NgQYxvFZWg8R3Nlegrpw6Fmx8zeh+1Yrh8H37pzF9NY=; b=aQJCctcqTBYvt4heG8kq0XfMGEl1HMKplPqXmXOij154XH4vTAZtVcHiYQT/nvoT9i f5BDU09jUPyW1truO6OEy2dujCoGSgxEE8giAyMSFhu7bnt8d2DJkuY0G7oFglm8tPbt Hlcu91LPwKjYP+CPuFgGC3KDmcWB75SjVJ/2hKBZJD+5kkAuqx3sGyqoY6qvg0vrzEfg zZheIk+TbMlrnZqMf4fPCrHtGqJXxaHUiASWe/y6Fmz8gLHtvCgegO4QrjBe7L4hEvOi ByVdRA+MYG9MZDu8/8nKSvd9cRr91Cx4j49wwykiSpQ02T0V3lWfRCGghYZ4RfhGcyQ8 jAVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bLhMddbs; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n25si8996763edv.294.2020.06.08.10.06.04; Mon, 08 Jun 2020 10:06:26 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=bLhMddbs; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730737AbgFHRDw (ORCPT + 99 others); Mon, 8 Jun 2020 13:03:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730669AbgFHRDv (ORCPT ); Mon, 8 Jun 2020 13:03:51 -0400 Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3640DC08C5C2 for ; Mon, 8 Jun 2020 10:03:51 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id x202so15944659oix.11 for ; Mon, 08 Jun 2020 10:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NgQYxvFZWg8R3Nlegrpw6Fmx8zeh+1Yrh8H37pzF9NY=; b=bLhMddbsGCNRw0hSzT5j2w5p2YPFaoPVJF3QZXzvZEB8C8j7v2yRtntrqmMnR7/aEc y7ZPyWU1jDno4pmlLLhJFwjJvsFZSBNEwVv5DEyRqxcb+1Ky3fSWchIJXMSHwBVtSfKu rwnChBaVdQq21YU6h7eNL+kRHUlw23HMT2CHSxEyp5xpenPbb1Bz8srah+OC/R835z57 aSLpbQmSlU4mCeF8WZeZorz4fkbZ0lOBw2X6Axq2Pd/k9ulEHCD4VYkPeMA20kduUFdf 00pGq8oeE+r1rV3/BEHt5RfXDOlxXlAvv06g7QFP7oWbK4kKsKHSN/OQ5L8iPB+tZWE9 rTNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NgQYxvFZWg8R3Nlegrpw6Fmx8zeh+1Yrh8H37pzF9NY=; b=rRsb69KDCgw6EuOwh+0ypxpnF4UKdFsn1qUhxHsM/C1i1776irOToke7Xc3crXe/uC A71ogXiw/Px6jhTwq+tW9OJushPyxB5vaKJ9GFR9FUZ/q2CDlUOsgyJ6xieNpS2jAw0J dD5WmD+4F40fXuhj3j5Dtbr2ej6YtQAI7RudOPpaQwnHq/qVvJ+Z+XG/MiZrhz5dO/7W sPXtrxz9FcCJ9Jx6YCDVW4CRyKw6gEg9wE4Gr91Md35Uq0M5UCe5FZjJ/Ig8nU0RM9C8 QK12WnYKXLC09JInVii56kZG6tMiKvpnyDGdmdxpj7a1/V27+OjfDRNTQejeDGkL/7/4 K9/g== X-Gm-Message-State: AOAM531Jph0Md6+jam0/8sfe17bGWHTuXRnA2cYbKoub851XJDJ+yghD lskK58wzgATrcOmV4SiPkRBDLSvk1NFVNgHb20PXtQ== X-Received: by 2002:aca:da56:: with SMTP id r83mr260756oig.106.1591635830100; Mon, 08 Jun 2020 10:03:50 -0700 (PDT) MIME-Version: 1.0 References: <20200601232542.GA473883@bjorn-Precision-5520> <20200602050626.GA2174820@kroah.com> <20200603060751.GA465970@kroah.com> <20200603121613.GA1488883@kroah.com> <20200605080229.GC2209311@kroah.com> <20200607113632.GA49147@kroah.com> In-Reply-To: <20200607113632.GA49147@kroah.com> From: Jesse Barnes Date: Mon, 8 Jun 2020 10:03:38 -0700 Message-ID: Subject: Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers To: Greg Kroah-Hartman Cc: 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > I feel a lot of resistance to the proposal, however, I'm not hearing > > any realistic solutions that may help us to move forward. We want to > > go with a solution that is acceptable upstream as that is our mission, > > and also helps the community, however the behemoth task of "inspect > > all drivers and fix them" before launching a product is really an > > unfair ask I feel :-(. Can you help us by suggesting a proposal that > > does not require us to trust a driver equally for internal / external > > devices? > > I have no idea why you feel you have to "inspect all drivers" other than > the fact that for some reason _you_ do not feel they are secure today. > > What type of "assurance" are you, or anyone else going to be able to > provide for any kernel driver that would meet such a "I feel good now" > level? Have you done that work for any specific driver already so that > you can show us what you mean by this effort? Perhaps it's as simple as > "oh look, this tool over here runs 'clean' on the source code, all is > good!", or not, I really have no idea. I think there's a disconnect somewhere in this discussion... maybe we're just approaching this with different assumptions? I think you recognize the potential for driver vulnerabilities when binding to new or potentially hostile devices that may be spoofing DID/VID/class/etc than then go on to abuse driver trust or the driver using unvalidated inputs from the device to crash or run arbitrary code on the target system. 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. 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. Thanks, Jesse