[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1378323117.2627.18.camel@shinybook.infradead.org>
Date: Wed, 04 Sep 2013 20:31:57 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Matthew Garrett <matthew.garrett@...ula.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"hpa@...or.com" <hpa@...or.com>
Subject: Re: [PATCH V3 02/11] PCI: Lock down BAR access when module security
is enabled
On Wed, 2013-09-04 at 19:01 +0000, Matthew Garrett wrote:
> But presumably the guest's view of RAM is what gets written to the BARs?
You're talking about the MMIO BARs of the devices which are given to the
guest, right? The register into which we write the 'ring buffer
address', and for that matter also the addresses which are written
*into* that ring buffer, etc.
It is indeed the guest's "physical address" which is written there. The
guest knows nothing of *host* physical addresses.
For the normal MMU, the guest sets up its page tables and, by the magic
of KVM, guest virtual addresses are translated twice — once to guest
*physical* addresses, and then to real physical addresses for stuff to
actually work.
For DMA, the guest hands 'guest physical' addresses directly to the
device. And we've set up the IOMMU to have a mapping of all of guest
physical address space, to the appropriate host physical pages.
> I guess if we know it's constrained then there's no need to restrict the
> addresses that can be set - we know that they'll be unable to overlap
> the host RAM.
There is no need to restrict the addresses that can be set. The only
addresses it can reach are pages which belong to the guest.
--
dwmw2
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)
Powered by blists - more mailing lists