linux-kernel - Re: [PATCH 2/4] iommu/vt-d: Don't consider copied context entries as present

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]

Date:	Thu, 11 Jun 2015 15:44:56 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Joerg Roedel <jroedel@...e.de>
Cc:	Joerg Roedel <joro@...tes.org>, iommu@...ts.linux-foundation.org,
	zhen-hual@...com, bhe@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] iommu/vt-d: Don't consider copied context entries
 as present

On Thu, 2015-06-11 at 16:25 +0200, Joerg Roedel wrote:
> On Thu, Jun 11, 2015 at 03:07:02PM +0100, David Woodhouse wrote:
> > On Thu, 2015-06-11 at 15:47 +0200, Joerg Roedel wrote:
> > > From: Joerg Roedel <jroedel@...e.de>
> > > 
> > > Hide the copied context entries from the IOMMU driver by
> > > considering them as non-present. This is implemented by
> > > setting the first AVL bit (bit 67) in the context entry to
> > > one. If this bit is set, the context_present() function
> > > returns false.
> > > 
> > > Signed-off-by: Joerg Roedel <jroedel@...e.de>
> > 
> > In the extended context entry, bit 67 is the PGE bit. There are no bits
> > which are available to software, to my knowledge.
> 
> Okay, reading the VT-d spec again, the extended context-entry table seem
> to exist in parallel to the current context-entry table, right? So this
> patch should still work, even with extended entries present.

No, the extended context-entry exists *instead* of the legacy
context-entry. Note that all the bits in the legacy context-entry are
present in precisely the same place in the extended context-entry. It's
just that the extended context-entry defines meanings for more of them.

When you enable the DMA_RTADDR_RTT bit in the Root Table Address
register, the context-entries magically double in size.

It used to look like this:


Root Table Address Register
       |
       V

Root Table (struct root_entry)     Context Table (struct context_entry)
------------------------------     ------------------------------------
0x00: Context-table pointer  ----->  Context entry for 00:00.0
0x08: unused                         Context entry for 00:00.1 
0x10: unused                         Context entry for 00:00.2
...   ...                            ...
0xff8:...                            Context entry for ff:1f.7


Now it looks like this

Root Table Address Register
       |
       V

Root Table (struct root_entry)     Context Table (struct context_entry)
------------------------------     ------------------------------------
0x00: Context-table ptr #1  ----->  Context entry for 00:00.0: lo
0x08: Context-table ptr #2  --,     Context entry for 00:00.0: hi
0x10: unused                  |     Context entry for 00:00.1: lo
...   ...                     |     ...
0xff8:...                     |     Context entry for 7f:1f.7: hi
                              |
                              |
                              |    Context Table (struct context_entry)
                               --> ------------------------------------
0x00:                               Context entry for 80:00.0: lo
0x08:                               Context entry for 80:00.1: hi
...                                 ...
0xff8:                              Context entry for ff:1f.7: hi


This was implemented in http://git.kernel.org/linus/03ecc32c52 but
*all* that patch did was allocate the second page of context-table,
fill in the appropriate new pointer in the root table, and adjust the
way we calculate the *location* of a context-entry. In 4.1 we're still
only using the same old bits of the context-entry, which as noted are
in the same place in both cases. Even the mapping from the old 2-bit T
field to the new 3-bit TT field works out that way, for now.

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)