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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 42328C433E2 for ; Mon, 8 Jun 2020 18:42:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1CAF32063A for ; Mon, 8 Jun 2020 18:42:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="IUlTeRvU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726100AbgFHSmC (ORCPT ); Mon, 8 Jun 2020 14:42:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726027AbgFHSl7 (ORCPT ); Mon, 8 Jun 2020 14:41:59 -0400 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4D52C08C5C2 for ; Mon, 8 Jun 2020 11:41:58 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id n23so21813738ljh.7 for ; Mon, 08 Jun 2020 11:41:58 -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=xdYVMi4TB1AynZV/TE42S+K8GYgFVjpwEvPiHdeHwW0=; b=IUlTeRvUgK8FEJG+Sn6jQfueJQe1C/imU4WYRWV2PuXL0DIMXxcRLd3RBoYavNHScZ vX2zz4xElfE07LNxxcY2PcKOxWZWYDTr8eMWppKxcAh/KsojiLKR0rLTYeoejnobKNG2 pZZpZMagWFDlGfMHVB9lzDhGFxuyRd9QkEU5pjXEJUfHLdAGS+6qV2MaQqpWxMcvG49q Iulw8WcBepoCEeFsp2tPHSSde26hUfJCgue82fduBrgy5NlOaekOMZ0Hch2/fBWLkiYF 8BspwkgWLKWZedKJ76UM/ofI/g9mHhZeGTfF/87eYzZ17X6TjR5lB+2Y3N9AL7r9yqi1 gSjA== 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=xdYVMi4TB1AynZV/TE42S+K8GYgFVjpwEvPiHdeHwW0=; b=ErEvR3d82HUeSxUNSCdW8Z9nIIJPjJfqCqM+H9OXhEnl8VISgnmM/ae+x6/jH4rs7M SkkqGlnhelbP4aahUzXvefD+b1QZMpx5b3JOIZ4L6MFE2G/SGPxgFMK3ZZjOb51Sv1pc ksnOFv8c1TMtvZth9DnXH/AJQVzepYEJHIxJx83JT2rCQYsgqTGvf68/LdIlAZFQ86l2 nyWluj6MnqcUvCd4pt/4fRqnWOteqsPlvRPfIkG4SkgQBFv8/EVvDXnx1FwQkV+MQJrk KF9Yp19ID73AfibXu4fK7QoBQoV/XmGXv2OOJZ289yx5FnYHF/yOgWyB+FgJHweZZskX Y8cg== X-Gm-Message-State: AOAM5311s1baVQjqkrj1eQdaODGHA2f34+iiQ9j3oHrxh+sz1lyk4Obz tgXHmzZqlIr+6obnHTPkyrR/x3/n+tYHAXgSEW6dJQ== X-Google-Smtp-Source: ABdhPJzTbJz0aBGuHmzGA+lFFgmNz5sWB5R746ny52RgSF2CDnKe0/GyLz0cvZeq0OMLOIp+8mvZ6xdkOTsXbpZwDuA= X-Received: by 2002:a2e:908f:: with SMTP id l15mr7160592ljg.307.1591641716733; Mon, 08 Jun 2020 11:41:56 -0700 (PDT) MIME-Version: 1.0 References: <20200602050626.GA2174820@kroah.com> <20200603060751.GA465970@kroah.com> <20200603121613.GA1488883@kroah.com> <20200605080229.GC2209311@kroah.com> <20200607113632.GA49147@kroah.com> <20200608175015.GA457685@kroah.com> In-Reply-To: From: Rajat Jain Date: Mon, 8 Jun 2020 11:41:19 -0700 Message-ID: Subject: Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers To: Jesse Barnes Cc: Greg Kroah-Hartman , 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 Hi Jesse and Greg, On Mon, Jun 8, 2020 at 11:30 AM Jesse Barnes wrote: > > > > 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. > > > > For USB, yes, we have now had to deal with "untrusted devices" lieing > > about their ids and sending us horrible data. That's all due to the > > fuzzing tools that have been written over the past few years, and now we > > have some of those in the kernel tree itself to help with that testing. This is great to hear! I tried to look up but didn't find anything else in-kernel, except the kcov support to export coverage info for userspace fuzzers. Can you please give us some pointers for in-kernel fuzzing tools? > > > > For PCI, heh, good luck, those assumptions about "devices sending valid > > data" are everywhere, if our experience with USB is any indication. > > > > But, to take USB as an example, this is exactly what the USB > > "authorized" flag is there for, it's a "trust" setting that userspace > > has control over. This came from the wireless USB spec, where it was > > determined that you could not trust devices. So just use that same > > model here, move it to the driver core for all busses to use and you > > should be fine. > > > > If that doesn't meet your needs, please let me know the specifics of > > why, with patches :) > > Yeah will do for sure. I don't want to carry a big infra for this on our own! > > > Now, as to you all getting some sort of "Hardware flag" to determine > > "inside" vs. "outside" devices, hah, good luck! It took us a long time > > to get that for USB, and even then, BIOSes lie and get it wrong all the > > time. So you will have to also deal with that in some way, for your > > userspace policy. > > I think that's inherently platform specific to some extent. We can do > it with our coreboot based firmware, but there's no guarantee other > vendors will adopt the same approach. But I think at least for the > ChromeOS ecosystem we can come up with something that'll work, and > allow us to dtrt in userspace wrt driver binding. Agree, we can work with our firmware teams to get that right, and then expose it from kernel to userspace to help it implement the policy we want. Thanks & Best Regards, Rajat > > Thanks, > Jesse