Message-Id: <20191211194606.87940-1-brho@google.com>
Date:   Wed, 11 Dec 2019 14:46:03 -0500
From:   Barret Rhoden <brho@...gle.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Joerg Roedel <joro@...tes.org>,
        Yian Chen <yian.chen@...el.com>,
        Sohil Mehta <sohil.mehta@...el.com>
Cc:     linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
        x86@...nel.org
Subject: [PATCH 0/3] iommu/vt-d bad RMRR workarounds

Hi -

Commit f036c7fa0ab6 ("iommu/vt-d: Check VT-d RMRR region in BIOS is
reported as reserved") caused a machine to fail to boot for me, but only
after a kexec.

Firmware provided an RMRR entry with base and end both == 0:

	DMAR: RMRR base: 0x00000000000000 end: 0x00000000000000

Yes, firmware should not do that.  I'd like to be able to handle it.

That bad entry was actually OK on a fresh boot, since the region of
0x0000..0x0001 ([start, end + 1)) was type RESERVED due to this e820
update call:

	e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

However, after a kexec, for whatever reason that first entry changed from

	BIOS-e820: [mem 0x0000000000000000-0x000000000009cbff] usable

to

	BIOS-e820: [mem 0x0000000000000100-0x000000000009cbff] usable

It starts at 0x100, not 0x000.  Ultimately, the range for that bad RMRR
[0x0, 0x1) isn't in the e820 map at all after a kexec.

The existing code aborts all of the DMAR parsing, eventually my disk
drivers fail, I can't mount the root filesystem, etc.  If you're
curious, I get a bunch of these errors:

	ata2.00: qc timeout (cmd 0xec)

I can imagine a bunch of ways around this.

One option is to hook in a check for buggy RMRRs in intel-iommu.c.  If
the base and end are 0, just ignore the entry.  That works for my
specific buggy DMAR entry.  There might be other buggy entries out
there.  The docs specify some requirements on the base and end (called
limit) addresses.

Another option is to change the sanity check so that unmapped ranges are
considered OK.  That would work for my case, but only because we're
hiding the firmware bug: my DMAR has a bad RMRR that happens to fall into a
reserved or non-existent range.  The downside here is that we'd
presumably be setting up an IOMMU mapping for this bad RMRR.  But at
least it's not pointing to any RAM we're using.  (That's actually what
goes on in the current, non-kexec case for me.  Phys page 0 is marked
RESERVED, and I have an RMRR that points to it.)  This option also would
cover any buggy firmwares that use an actual RMRR that pointed to memory
that was omitted from the e820 map.

A third option: whenever the RMRR sanity check fails, just ignore it and
return 0.  Don't set up the rmrru.  Right now, we completely abort DMAR
processing.  If there was an actual device that needed to poke this
memory that failed the sanity check (meaning, not RESERVED, currently),
then we're already in trouble; that device could clobber RAM, right?  If
we're going to use the IOMMU, I'd rather the device be behind an IOMMU
with *no* mapping for the region, so it couldn't clobber whatever we
happened to put in that location.

I actually think all three options are reasonable ideas independently of
one another.  This patchset that does all three.  Please take at least
one of them.  =)  (May require a slight revision if you don't take all
of them).

Barret Rhoden (3):
  iommu/vt-d: skip RMRR entries that fail the sanity check
  iommu/vt-d: treat unmapped RMRR entries as sane
  iommu/vt-d: skip invalid RMRR entries

 arch/x86/include/asm/iommu.h |  2 ++
 drivers/iommu/intel-iommu.c  | 16 ++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

-- 
2.24.0.525.g8f36a354ae-goog

Powered by blists - more mailing lists