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
| ||
|
Date: Sat, 14 Dec 2019 09:52:50 +0800 From: Lu Baolu <baolu.lu@...ux.intel.com> To: Barret Rhoden <brho@...gle.com>, 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: baolu.lu@...ux.intel.com, iommu@...ts.linux-foundation.org, x86@...nel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/3] iommu/vt-d bad RMRR workarounds On 12/13/19 10:31 PM, Barret Rhoden wrote: > On 12/11/19 9:43 PM, Lu Baolu wrote: >> The VT-d spec defines the BIOS considerations about RMRR in section 8.4: >> >> " >> BIOS must report the RMRR reported memory addresses as reserved (or as >> EFI runtime) in the system memory map returned through methods such as >> INT15, EFI GetMemoryMap etc. >> " >> >> So we should treat it as firmware bug if the RMRR range is not mapped as >> RESERVED in the system memory map table. >> >> As for how should the driver handle this case, ignoring buggy RMRR with >> a warning message might be a possible choice. > > Agreed, firmware should not be doing this. My first patch just skips > those entries, instead of aborting DMAR processing, and keeps the warning. > Hi Yian, Does this work for you? Best regards, baolu > So long as the machine still boots in a safe manner, I'm reasonably happy. > > Thanks, > > Barret > >
Powered by blists - more mailing lists