All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Kuppuswamy,
	Sathyanarayanan"  <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Borislav Petkov <bp@alien8.de>, X86 ML <x86@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Jason Wang <jasowang@redhat.com>,
	Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PCI <linux-pci@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>,
	virtualization@lists.linux-foundation.org, "Reshetova,
	Elena" <elena.reshetova@intel.com>
Subject: Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest
Date: Fri, 1 Oct 2021 08:49:28 -0700	[thread overview]
Message-ID: <64eb085b-ef9d-dc6e-5bfd-d23ca0149b5e@linux.intel.com> (raw)
In-Reply-To: <YVaywQLAboZ6b36V@kroah.com>


On 10/1/2021 12:03 AM, Greg Kroah-Hartman wrote:
> On Thu, Sep 30, 2021 at 12:04:05PM -0700, Kuppuswamy, Sathyanarayanan wrote:
>>
>> On 9/30/21 8:23 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Sep 30, 2021 at 08:18:18AM -0700, Kuppuswamy, Sathyanarayanan wrote:
>>>>
>>>> On 9/30/21 6:36 AM, Dan Williams wrote:
>>>>>> And in particular, not all virtio drivers are hardened -
>>>>>> I think at this point blk and scsi drivers have been hardened - so
>>>>>> treating them all the same looks wrong.
>>>>> My understanding was that they have been audited, Sathya?
>>>> Yes, AFAIK, it has been audited. Andi also submitted some patches
>>>> related to it. Andi, can you confirm.
>>> What is the official definition of "audited"?
>>
>> In our case (Confidential Computing platform), the host is an un-trusted
>> entity. So any interaction with host from the drivers will have to be
>> protected against the possible attack from the host. For example, if we
>> are accessing a memory based on index value received from host, we have
>> to make sure it does not lead to out of bound access or when sharing the
>> memory with the host, we need to make sure only the required region is
>> shared with the host and the memory is un-shared after use properly.
> You have not defined the term "audited" here at all in any way that can
> be reviewed or verified by anyone from what I can tell.
>
> You have only described a new model that you wish the kernel to run in,
> one in which it does not trust the hardware at all.  That is explicitly
> NOT what the kernel has been designed for so far,

It has been already done for a few USB/TB drivers, but yes not for the 
majority of the kernel.

>   and if you wish to
> change that, lots of things need to be done outside of simply running
> some fuzzers on a few random drivers.

The goal is to do similar work as USB/TB did, but do it for a small set 
of virtio drivers and use a custom allow list for those for the specific 
secure guest cases.

(there are some other goals, but let's not discuss them here for now)


>
> For one example, how do you ensure that the memory you are reading from
> hasn't been modified by the host between writing to it the last time you
> did?

It's similar techniques as we do on user space accesses. For example if 
you bound check some value the code needs to ensure it is cached in 
private memory, not reread from MMIO or shared memory. Of course that's 
a good idea anyways for performance because MMIO is slow.

In the concrete cases of virtio the main problem was the free list in 
shared memory, but that has been addressed now.



>   Do you have a list of specific drivers and kernel options that you
> feel you now "trust"?

For TDX it's currently only virtio net/block/console

But we expect this list to grow slightly over time, but not at a high 
rate (so hopefully <10)


> If so, how long does that trust last for?  Until
> someonen else modifies that code?  What about modifications to functions
> that your "audited" code touches?  Who is doing this auditing?  How do
> you know the auditing has been done correctly?  Who has reviewed and
> audited the tools that are doing the auditing?  Where is the
> specification that has been agreed on how the auditing must be done?
> And so on...

Well, I mean we already have a similar situation with user space APIs. 
So it's not a new problem. For those we've done it for many years, with 
audits and extra fuzzing.

There are people working on the audit and fuzzing today. How exactly it 
will be ensured long term is still be worked out, but I expect we can 
work out something.

>
> I feel like there are a lot of different things all being mixed up here
> into one "oh we want this to happen!" type of thread.



Agreed. The thread ended up about a lot of stuff which is outside the 
scope of the patches.

>    Please let's just
> stick to the one request that I had here, which was to move the way that
> busses are allowed to authorize the devices they wish to control into a
> generic way instead of being bus-specific logic.
>
> Any requests outside of that type of functionality are just that,
> outside the scope of this patchset and should get their own patch series
> and discussion.


Yes that's the intention. This patch kit is only about controlling what 
devices can enumerate.

Also please let's avoid the "trusted" term. It's really misleading and 
confusing in the context of confidential computing.


-Andi


WARNING: multiple messages have this Message-ID
From: Andi Kleen <ak@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Kuppuswamy,
	Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Linux PCI <linux-pci@vger.kernel.org>, X86 ML <x86@kernel.org>,
	virtualization@lists.linux-foundation.org,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andreas Noever <andreas.noever@gmail.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"Reshetova, Elena" <elena.reshetova@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	USB list <linux-usb@vger.kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest
Date: Fri, 1 Oct 2021 08:49:28 -0700	[thread overview]
Message-ID: <64eb085b-ef9d-dc6e-5bfd-d23ca0149b5e@linux.intel.com> (raw)
In-Reply-To: <YVaywQLAboZ6b36V@kroah.com>


On 10/1/2021 12:03 AM, Greg Kroah-Hartman wrote:
> On Thu, Sep 30, 2021 at 12:04:05PM -0700, Kuppuswamy, Sathyanarayanan wrote:
>>
>> On 9/30/21 8:23 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Sep 30, 2021 at 08:18:18AM -0700, Kuppuswamy, Sathyanarayanan wrote:
>>>>
>>>> On 9/30/21 6:36 AM, Dan Williams wrote:
>>>>>> And in particular, not all virtio drivers are hardened -
>>>>>> I think at this point blk and scsi drivers have been hardened - so
>>>>>> treating them all the same looks wrong.
>>>>> My understanding was that they have been audited, Sathya?
>>>> Yes, AFAIK, it has been audited. Andi also submitted some patches
>>>> related to it. Andi, can you confirm.
>>> What is the official definition of "audited"?
>>
>> In our case (Confidential Computing platform), the host is an un-trusted
>> entity. So any interaction with host from the drivers will have to be
>> protected against the possible attack from the host. For example, if we
>> are accessing a memory based on index value received from host, we have
>> to make sure it does not lead to out of bound access or when sharing the
>> memory with the host, we need to make sure only the required region is
>> shared with the host and the memory is un-shared after use properly.
> You have not defined the term "audited" here at all in any way that can
> be reviewed or verified by anyone from what I can tell.
>
> You have only described a new model that you wish the kernel to run in,
> one in which it does not trust the hardware at all.  That is explicitly
> NOT what the kernel has been designed for so far,

It has been already done for a few USB/TB drivers, but yes not for the 
majority of the kernel.

>   and if you wish to
> change that, lots of things need to be done outside of simply running
> some fuzzers on a few random drivers.

The goal is to do similar work as USB/TB did, but do it for a small set 
of virtio drivers and use a custom allow list for those for the specific 
secure guest cases.

(there are some other goals, but let's not discuss them here for now)


>
> For one example, how do you ensure that the memory you are reading from
> hasn't been modified by the host between writing to it the last time you
> did?

It's similar techniques as we do on user space accesses. For example if 
you bound check some value the code needs to ensure it is cached in 
private memory, not reread from MMIO or shared memory. Of course that's 
a good idea anyways for performance because MMIO is slow.

In the concrete cases of virtio the main problem was the free list in 
shared memory, but that has been addressed now.



>   Do you have a list of specific drivers and kernel options that you
> feel you now "trust"?

For TDX it's currently only virtio net/block/console

But we expect this list to grow slightly over time, but not at a high 
rate (so hopefully <10)


> If so, how long does that trust last for?  Until
> someonen else modifies that code?  What about modifications to functions
> that your "audited" code touches?  Who is doing this auditing?  How do
> you know the auditing has been done correctly?  Who has reviewed and
> audited the tools that are doing the auditing?  Where is the
> specification that has been agreed on how the auditing must be done?
> And so on...

Well, I mean we already have a similar situation with user space APIs. 
So it's not a new problem. For those we've done it for many years, with 
audits and extra fuzzing.

There are people working on the audit and fuzzing today. How exactly it 
will be ensured long term is still be worked out, but I expect we can 
work out something.

>
> I feel like there are a lot of different things all being mixed up here
> into one "oh we want this to happen!" type of thread.



Agreed. The thread ended up about a lot of stuff which is outside the 
scope of the patches.

>    Please let's just
> stick to the one request that I had here, which was to move the way that
> busses are allowed to authorize the devices they wish to control into a
> generic way instead of being bus-specific logic.
>
> Any requests outside of that type of functionality are just that,
> outside the scope of this patchset and should get their own patch series
> and discussion.


Yes that's the intention. This patch kit is only about controlling what 
devices can enumerate.

Also please let's avoid the "trusted" term. It's really misleading and 
confusing in the context of confidential computing.


-Andi

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-10-01 15:49 UTC|newest]

Thread overview: 132+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  1:05 [PATCH v2 0/6] Add device filter support Kuppuswamy Sathyanarayanan
2021-09-30  1:05 ` [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core Kuppuswamy Sathyanarayanan
2021-09-30  1:42   ` Alan Stern
2021-09-30  1:42     ` Alan Stern
2021-09-30  1:55     ` Dan Williams
2021-09-30  1:55       ` Dan Williams
2021-09-30  2:38       ` Kuppuswamy, Sathyanarayanan
2021-09-30  4:59         ` Dan Williams
2021-09-30  4:59           ` Dan Williams
2021-09-30  9:05           ` Rafael J. Wysocki
2021-09-30  9:05             ` Rafael J. Wysocki
2021-09-30 14:59       ` Alan Stern
2021-09-30 14:59         ` Alan Stern
2021-09-30 15:25         ` Dan Williams
2021-09-30 15:25           ` Dan Williams
2021-09-30 11:19   ` Yehezkel Bernat
2021-09-30 15:28     ` Dan Williams
2021-09-30 15:28       ` Dan Williams
2021-09-30 18:25       ` Yehezkel Bernat
2021-09-30 19:04         ` Dan Williams
2021-09-30 19:04           ` Dan Williams
2021-09-30 19:50           ` Kuppuswamy, Sathyanarayanan
2021-09-30 20:23             ` Dan Williams
2021-09-30 20:23               ` Dan Williams
2021-09-30  1:05 ` [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices Kuppuswamy Sathyanarayanan
2021-09-30 10:59   ` Michael S. Tsirkin
2021-09-30 10:59     ` Michael S. Tsirkin
2021-09-30 13:52     ` Greg Kroah-Hartman
2021-09-30 13:52       ` Greg Kroah-Hartman
2021-09-30 14:38       ` Michael S. Tsirkin
2021-09-30 14:38         ` Michael S. Tsirkin
2021-09-30 14:49         ` Greg Kroah-Hartman
2021-09-30 14:49           ` Greg Kroah-Hartman
2021-09-30 15:00           ` Michael S. Tsirkin
2021-09-30 15:00             ` Michael S. Tsirkin
2021-09-30 15:22             ` Greg Kroah-Hartman
2021-09-30 15:22               ` Greg Kroah-Hartman
2021-09-30 17:17               ` Andi Kleen
2021-09-30 17:17                 ` Andi Kleen
2021-09-30 17:23                 ` Greg Kroah-Hartman
2021-09-30 17:23                   ` Greg Kroah-Hartman
2021-09-30 19:15                   ` Andi Kleen
2021-09-30 19:15                     ` Andi Kleen
2021-10-01  6:29                     ` Greg Kroah-Hartman
2021-10-01  6:29                       ` Greg Kroah-Hartman
2021-10-01 15:51                       ` Alan Stern
2021-10-01 15:51                         ` Alan Stern
2021-10-01 15:56                         ` Andi Kleen
2021-10-01 15:56                           ` Andi Kleen
2021-09-30 14:43       ` Alan Stern
2021-09-30 14:43         ` Alan Stern
2021-09-30 14:48         ` Michael S. Tsirkin
2021-09-30 14:48           ` Michael S. Tsirkin
2021-09-30 15:32           ` Alan Stern
2021-09-30 15:32             ` Alan Stern
2021-09-30 15:52             ` Michael S. Tsirkin
2021-09-30 15:52               ` Michael S. Tsirkin
2021-09-30 14:58         ` Michael S. Tsirkin
2021-09-30 14:58           ` Michael S. Tsirkin
2021-09-30 15:35           ` Alan Stern
2021-09-30 15:35             ` Alan Stern
2021-09-30 15:59             ` Michael S. Tsirkin
2021-09-30 15:59               ` Michael S. Tsirkin
2021-09-30 19:23               ` Andi Kleen
2021-09-30 19:23                 ` Andi Kleen
2021-09-30 20:44                 ` Alan Stern
2021-09-30 20:44                   ` Alan Stern
2021-09-30 20:52                   ` Dan Williams
2021-09-30 20:52                     ` Dan Williams
2021-10-01  1:41                     ` Alan Stern
2021-10-01  1:41                       ` Alan Stern
2021-10-01  2:20                       ` Dan Williams
2021-10-01  2:20                         ` Dan Williams
2021-09-30 21:12                   ` Andi Kleen
2021-09-30 21:12                     ` Andi Kleen
2021-09-30  1:05 ` [PATCH v2 3/6] driver core: Allow arch to initialize the authorized attribute Kuppuswamy Sathyanarayanan
2021-09-30  1:05 ` [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest Kuppuswamy Sathyanarayanan
2021-09-30 11:03   ` Michael S. Tsirkin
2021-09-30 11:03     ` Michael S. Tsirkin
2021-09-30 13:36     ` Dan Williams
2021-09-30 13:36       ` Dan Williams
2021-09-30 13:49       ` Greg Kroah-Hartman
2021-09-30 13:49         ` Greg Kroah-Hartman
2021-09-30 15:18       ` Kuppuswamy, Sathyanarayanan
2021-09-30 15:20         ` Michael S. Tsirkin
2021-09-30 15:20           ` Michael S. Tsirkin
2021-09-30 15:23           ` Kuppuswamy, Sathyanarayanan
2021-09-30 15:23         ` Greg Kroah-Hartman
2021-09-30 15:23           ` Greg Kroah-Hartman
2021-09-30 19:04           ` Kuppuswamy, Sathyanarayanan
2021-09-30 19:16             ` Kuppuswamy, Sathyanarayanan
2021-09-30 19:30             ` Andi Kleen
2021-09-30 19:30               ` Andi Kleen
2021-09-30 19:40               ` Kuppuswamy, Sathyanarayanan
2021-10-01  7:03             ` Greg Kroah-Hartman
2021-10-01  7:03               ` Greg Kroah-Hartman
2021-10-01 15:49               ` Andi Kleen [this message]
2021-10-01 15:49                 ` Andi Kleen
2021-10-02 11:04                 ` Michael S. Tsirkin
2021-10-02 11:04                   ` Michael S. Tsirkin
2021-10-02 11:14                   ` Greg Kroah-Hartman
2021-10-02 11:14                     ` Greg Kroah-Hartman
2021-10-02 14:20                     ` Andi Kleen
2021-10-02 14:20                       ` Andi Kleen
2021-10-02 14:44                       ` Greg Kroah-Hartman
2021-10-02 14:44                         ` Greg Kroah-Hartman
2021-10-02 18:40                       ` Michael S. Tsirkin
2021-10-02 18:40                         ` Michael S. Tsirkin
2021-10-03  6:40                         ` Greg Kroah-Hartman
2021-10-03  6:40                           ` Greg Kroah-Hartman
2021-10-04 21:04                       ` Dan Williams
2021-10-04 21:04                         ` Dan Williams
2021-10-01 16:13               ` Dan Williams
2021-10-01 16:13                 ` Dan Williams
2021-10-01 16:45                 ` Alan Stern
2021-10-01 16:45                   ` Alan Stern
2021-10-01 18:09                   ` Dan Williams
2021-10-01 18:09                     ` Dan Williams
2021-10-01 19:00                     ` Alan Stern
2021-10-01 19:00                       ` Alan Stern
2021-10-01 19:45                       ` Kuppuswamy, Sathyanarayanan
2021-10-01 19:57                       ` Dan Williams
2021-10-01 19:57                         ` Dan Williams
2021-10-04  5:16                         ` Mika Westerberg
2021-10-05 22:33                           ` Dan Williams
2021-10-05 22:33                             ` Dan Williams
2021-10-06  5:45                             ` Greg Kroah-Hartman
2021-10-06  5:45                               ` Greg Kroah-Hartman
2021-09-30 19:25         ` Andi Kleen
2021-09-30 19:25           ` Andi Kleen
2021-09-30  1:05 ` [PATCH v2 5/6] x86/tdx: Add device filter support for x86 TDX guest platform Kuppuswamy Sathyanarayanan
2021-09-30  1:05 ` [PATCH v2 6/6] PCI: Initialize authorized attribute for confidential guest Kuppuswamy Sathyanarayanan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64eb085b-ef9d-dc6e-5bfd-d23ca0149b5e@linux.intel.com \
    --to=ak@linux.intel.com \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=elena.reshetova@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jasowang@redhat.com \
    --cc=knsathya@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=michael.jamet@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=rafael@kernel.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.