lkml.org 
[lkml]   [2021]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}
    On Mon, Aug 23, 2021 at 6:06 PM Dan Williams <dan.j.williams@intel.com> wrote:
    >
    > On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan
    > <sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
    > >
    > >
    > >
    > > On 8/23/21 4:56 PM, Michael S. Tsirkin wrote:
    > > >> Add a new variant of pci_iomap for mapping all PCI resources
    > > >> of a devices as shared memory with a hypervisor in a confidential
    > > >> guest.
    > > >>
    > > >> Signed-off-by: Andi Kleen<ak@linux.intel.com>
    > > >> Signed-off-by: Kuppuswamy Sathyanarayanan<sathyanarayanan.kuppuswamy@linux.intel.com>
    > > > I'm a bit puzzled by this part. So why should the guest*not* map
    > > > pci memory as shared? And if the answer is never (as it seems to be)
    > > > then why not just make regular pci_iomap DTRT?
    > >
    > > It is in the context of confidential guest (where VMM is un-trusted). So
    > > we don't want to make all PCI resource as shared. It should be allowed
    > > only for hardened drivers/devices.
    >
    > That's confusing, isn't device authorization what keeps unaudited
    > drivers from loading against untrusted devices? I'm feeling like
    > Michael that this should be a detail that drivers need not care about
    > explicitly, in which case it does not need to be exported because the
    > detail can be buried in lower levels.
    >
    > Note, I specifically said "unaudited", not "hardened" because as Greg
    > mentioned the kernel must trust drivers, its devices that may not be
    > trusted.

    Can you please point me to the thread where this discussion with Greg
    is ongoing?

    Thanks,

    Rajat

    \
     
     \ /
      Last update: 2021-08-24 23:58    [W:8.572 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site