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 5F06CC433DF for ; Wed, 3 Jun 2020 11:51:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36F4B20678 for ; Wed, 3 Jun 2020 11:51:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mI5aPFlm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725859AbgFCLv6 (ORCPT ); Wed, 3 Jun 2020 07:51:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725854AbgFCLv5 (ORCPT ); Wed, 3 Jun 2020 07:51:57 -0400 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADB5EC08C5C0 for ; Wed, 3 Jun 2020 04:51:57 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id n24so2293191lji.10 for ; Wed, 03 Jun 2020 04:51:57 -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=ZdBB5hfXeMUbxEadj8HyXcRzRwZM+PPwSB4AAz3DRGw=; b=mI5aPFlm4k8KFAD/9YB1eDbVdeziZR/ErHPbp/wRCC8wXXF+CZyztaQ4Kk/vvYyuBJ HozI4UzdsNGaqHg4MJhQmWRdoOvBD5r5yexuyUa3ee5i2E2ZwGKIFPP1wy5iCV97459W fT9k1KSus2StCFqzxCGTAqFVk1HXRXWRXSbnF8FBqrv+JuDh0KzhFwnq6CLrwH2iN9E0 wza4bf3IOPqxJCvH+mtlBd4SCduGmeCciSI4X4oeaVDYAdsLCH1enJG/8vd1vH3f3JEu ZG4XXt/RJzF5PgH9pftNeFs0E/agvaR6f3P3h9TIV3dguN8ypGKrwWmhoZnZvS6VVhAA Faew== 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=ZdBB5hfXeMUbxEadj8HyXcRzRwZM+PPwSB4AAz3DRGw=; b=DYgoG2jpyjRD7hyxqVLUe9HYFzebl9/QmLrs4z0h69leZEVxvQFPwkDyrGt4izTZnb ZinvEyR5NQaXP/umzW06OG/iy4LjthLG2RHDNhkrh66UoZ211I96Vmhln/Pi1JoY9r+b WIcoBnK1ErcSpfnC1RFiTp26u8tgS5CVJcPp8LzchL3qXBmiIjcp9wjHXubUf6v0qtmW XZgFekuRlnO2ayAWD4cIAxAjotOmcF1XfhIrxWSpyWzfk/9Yprr83lZj3wdjabmv2WHd k6UU7HcQvhc8YiI4UP49Z8xdupVjN4hrnMjq7hg4RrEYgasgT6HTk89yvvUqZjPcxkGW n/KQ== X-Gm-Message-State: AOAM532y4bDibUVF82XUD6maZWqGCG7nMLpuV4EmfBCpDP5mV9xCSblM njLdIJXjjmVJck3aoU0iiLtMNgYnW8c0pLHrSnSjnw== X-Google-Smtp-Source: ABdhPJyf5ID0wFLZrpBtkoD4Bbg02jpPZv24wGHOaCOu5JUKLGvhg2+QXOqH5CyRdbH2HtcXK+IXsJLgkB9JGLk0PJM= X-Received: by 2002:a2e:8554:: with SMTP id u20mr1865102ljj.188.1591185115803; Wed, 03 Jun 2020 04:51:55 -0700 (PDT) MIME-Version: 1.0 References: <20200601232542.GA473883@bjorn-Precision-5520> <20200602050626.GA2174820@kroah.com> <20200603060751.GA465970@kroah.com> In-Reply-To: <20200603060751.GA465970@kroah.com> From: Rajat Jain Date: Wed, 3 Jun 2020 04:51:18 -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 , 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 , Jesse Barnes , Christian Kellner , Alex Williamson , Joerg Roedel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Hello, > > > Thanks for the pointer! I'm still looking at the details yet, but a > > quick look (usb_dev_authorized()) seems to suggest that this API is > > "device based". The multiple levels of "authorized" seem to take shape > > from either how it is wired or from userspace choice. Once authorized, > > USB device or interface is authorized to be used by *anyone* (can be > > attached to any drivers). Do I understand it right that it does not > > differentiate between drivers? > > Yes, and that is what you should do, don't fixate on drivers. Users > know how to control and manage devices. Us kernel developers are > responsible for writing solid drivers and getting them merged into the > kernel tree and maintaining them over time. Drivers in the kernel > should always be trusted, ... 1) Yes, I agree that this would be ideal, and this should be our mission. I should clarify that I may have used the wrong term "Trusted/Certified drivers". I didn't really mean that the drivers may be malicious by intent. What I really meant is that a driver may have an attack surface, which is a vulnerability that may be exploited. Realistically speaking, finding vulnerabilities in drivers, creating attacks to exploit them, and fixing them is a never ending cat and mouse game. At Least "identifying the vulnerabilities" part is better performed by security folks rather than driver writers. Earlier in the thread I had mentioned certain studies/projects that identified and exploited such vulnerabilities in the drivers. I should have used the term "Vetted Drivers" maybe to convey the intent better - drivers that have been vetted by a security focussed team (admin). What I'm advocating here is an administrator's right to control the drivers that he wants to allow for external ports on his systems. 2) In addition to the problem of driver negligences / vulnerabilities to be exploited, we ran into another problem with the "whitelist devices only" approach. We did start with the "device based" approach only initially - but quickly realized that anything we use to whitelist an external device can only be based on the info provided by *that device* itself. So until we have devices that exchange certificates with kernel [1], it is easy for a malicious device to spoof a whitelisted device (by presenting the same VID:DID or any other data that is used by us to whitelist it). [1] https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html I hope that helps somewhat clarify how / why we reached here? Thanks & Best Regards, Rajat > thanks, > > greg k-h