linux-kernel - Re: [RFC] - Mapping ACPI tables as CACHED

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]

Message-ID: <4C743C0F.2010101@zytor.com>
Date:	Tue, 24 Aug 2010 14:39:27 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
CC:	Jack Steiner <steiner@....com>, mingo@...e.hu, tglx@...utronix.de,
	lenb@...nel.org, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] - Mapping ACPI tables as CACHED

On 07/23/2010 05:14 PM, Henrique de Moraes Holschuh wrote:
> 
> Well, as it was raised in this thread, ACPI tables are likely to be near RAM
> regions used for IPC with the firmware or SMBIOS, and we have no idea of the
> kind of crap that could happen if we enable caching on those areas.
> 

I'm really not sure I buy that argument -- at least not on x86: if that
is the case, then when PAT is off (and we fall down to MTRR-only
control) then we'd have the same failures.  If we mark them cacheable
and the MTRRs say uncachable, then we will *still* not cache them (since
MTRR UC overrides PAT WB -- in fact "PAT off" really just means ALL the
pagetables are marked WB.)

In that sense it is probably *safer* to map them WB, since the firmware
if it uses page tables at all is extremely likely to have all the cache
control bits at zero (meaning WB) -- and if it doesn't use page tables,
they are functionally zero by default (MTRR control only.)

So I think it'd be safer to map them cacheable -- regardless of if we
want to copy them to RAM or not.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/