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 850F2C432BE for ; Thu, 5 Aug 2021 17:52:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 68C93610A2 for ; Thu, 5 Aug 2021 17:52:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240794AbhHERw1 (ORCPT ); Thu, 5 Aug 2021 13:52:27 -0400 Received: from mga06.intel.com ([134.134.136.31]:36807 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236297AbhHERw0 (ORCPT ); Thu, 5 Aug 2021 13:52:26 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10067"; a="275263248" X-IronPort-AV: E=Sophos;i="5.84,296,1620716400"; d="scan'208";a="275263248" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 10:52:11 -0700 X-IronPort-AV: E=Sophos;i="5.84,296,1620716400"; d="scan'208";a="437873096" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.212.183.241]) ([10.212.183.241]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 10:52:11 -0700 Subject: Re: [PATCH v1] driver: base: Add driver filter support To: "Kuppuswamy, Sathyanarayanan" , Dan Williams , Greg Kroah-Hartman Cc: "Rafael J . Wysocki" , Jonathan Corbet , Kuppuswamy Sathyanarayanan , Linux Kernel Mailing List , Linux Doc Mailing List References: <20210804174322.2898409-1-sathyanarayanan.kuppuswamy@linux.intel.com> <1e9efeb3-4aef-68e2-6af3-cf6bb5decb38@linux.intel.com> From: Andi Kleen Message-ID: Date: Thu, 5 Aug 2021 10:52:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <1e9efeb3-4aef-68e2-6af3-cf6bb5decb38@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/5/2021 10:25 AM, Kuppuswamy, Sathyanarayanan wrote: > > > On 8/5/21 9:37 AM, Dan Williams wrote: >> I overlooked the "authorized" attribute in usb and thunderbolt. The >> collision problem makes sense. Are you open to a core "authorized" >> attribute that buses like usb and thunderbolt would override in favor >> of their local implementation? I.e. similar to suppress_bind_attrs: > > Even if such overriding is allowed in default boot, it should not be > allowed in protected guest + driver_filter model. Allowing overriding would be acceptable, as long as nobody does it by default. In theory a (root) user program can already do other things that make the guest insecure. Still it's not clear to me how this proposal solves the builtin and platform drivers problem. AFAIK that needs a builtin allowlist in any case. And once we have that likely we don't need anything else for current TDX at least, because the allowlist is so small and there is no concept of hotplug or similar. Also another consideration is that we were trying to avoid relying too much on user space for this. One of the goals was to move an existing guest image to a confidential guest with only minor changes (new kernel / enable attestation). Complex changes for securing it would make that much harder. -Andi