linux-kernel - Re: [PATCH v1] driver: base: Add driver filter support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f4dedead-5b6c-2712-deca-0d59d314016b@linux.intel.com>
Date:   Thu, 5 Aug 2021 10:52:10 -0700
From:   Andi Kleen <ak@...ux.intel.com>
To:     "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "Rafael J . Wysocki" <rafael@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v1] driver: base: Add driver filter support

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