| 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
| ||
|
Message-ID: <20100724004532.GA9240@srcf.ucam.org> Date: Sat, 24 Jul 2010 01:45:32 +0100 From: Matthew Garrett <mjg59@...f.ucam.org> 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 Fri, Jul 23, 2010 at 09:14:50PM -0300, 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. > > OTOH, we *know* of systems that force us to copy the ACPI tables to regular > RAM, otherwise, the utterly broken BIOS corrupts the ACPI tables after the > kernel has loaded. > > Couldn't we simply always copy all tables to regular RAM and mark THAT as > cacheable (since there will be no IPC regions in it)? For the tables that > are only used once, we can free the RAM later. I think this is reasonable. There's an argument that we shouldn't cache operation regions that may be sitting next to the ACPI tables, but I can't see any problems being caused by copying the tables to RAM. -- Matthew Garrett | mjg59@...f.ucam.org -- 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/
Powered by blists - more mailing lists