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=-5.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 11002C4338F for ; Thu, 5 Aug 2021 19:09:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E77B460EEA for ; Thu, 5 Aug 2021 19:09:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242318AbhHETJP (ORCPT ); Thu, 5 Aug 2021 15:09:15 -0400 Received: from mga09.intel.com ([134.134.136.24]:64685 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242274AbhHETJL (ORCPT ); Thu, 5 Aug 2021 15:09:11 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10067"; a="214215896" X-IronPort-AV: E=Sophos;i="5.84,296,1620716400"; d="scan'208";a="214215896" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 12:08:55 -0700 X-IronPort-AV: E=Sophos;i="5.84,296,1620716400"; d="scan'208";a="512904115" Received: from dkdean-mobl.amr.corp.intel.com (HELO skuppusw-mobl5.amr.corp.intel.com) ([10.209.157.53]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 12:08:54 -0700 Subject: Re: [PATCH v1] driver: base: Add driver filter support To: Dan Williams , Andi Kleen Cc: Greg Kroah-Hartman , "Rafael J . Wysocki" , Jonathan Corbet , Kuppuswamy Sathyanarayanan , Linux Kernel Mailing List , Linux Doc Mailing List References: <20210804174322.2898409-1-sathyanarayanan.kuppuswamy@linux.intel.com> <21db8884-5aa1-3971-79ef-f173a0a95bef@linux.intel.com> <1e0967ee-c41e-fd5d-f553-e4d7ab88838c@linux.intel.com> From: "Kuppuswamy, Sathyanarayanan" Message-ID: <179a8351-5541-a4f0-bbb2-5d4f398e2476@linux.intel.com> Date: Thu, 5 Aug 2021 12:08:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/5/21 12:01 PM, Dan Williams wrote: > What's wrong with the generic authorized proposal? The core can > default to deauthorizing devices on the platform bus, or any bus, > unless on an allow list. It's a bit more work to uplevel the local > "authorized" implementations from USB and Thunderbolt to the core, but > it's functionally identical to the "filter" approach in terms of > protection, i.e. avoiding probe of unnecessary unvetted drivers. I have not yet read about the "authorized" model in USB and Thunderbolt. So bear with me if my question is basic or obvious. In the case USB authorized model, who maintains the allow list? kernel or userspace? If we are clubbing it with the driver filter model, I think allow list in kernel should take precedence. Agree? -- Sathyanarayanan Kuppuswamy Linux Kernel Developer