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: Tue, 29 Apr 2008 18:16:44 -0700 From: ebiederm@...ssion.com (Eric W. Biederman) To: Thomas Gleixner <tglx@...utronix.de> Cc: Yinghai Lu <yhlu.kernel@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>, Gabriel C <nix.or.die@...glemail.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Mika Fischer <mika.fischer@...pnet.de> Subject: Re: [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v5 Thomas Gleixner <tglx@...utronix.de> writes: > On Tue, 29 Apr 2008, Eric W. Biederman wrote: >> Think of SMM mode is a lightweight hypervisor that we can't get rid >> of, if you want to understand the worst case. >> >> In theory SMM mode is completely unnecessary as soon as we enable >> ACPI. In practice ACPI appears to frequently trap into SMM mode. > > SMM does more than that. It emulates legacy hardware and fixes > chip(set) bugs as well. Disabling it just makes your box stop > working. There are certain types of systems where essential safety > nets rely on SMIs (you can deep-fry P4s by disabling SMIs). There is truth in that but it is over dramatic. P4s don't deep fry they almost always turn off before they overheat (you make take physical damage to your motherboard though). The best definition I have heard of SMM mode is: smack the stupid OS that isn't doing what it should be doing at runtime mode. It is the way board designers and BIOS writers can work around what they perceive as broken OS code, that keeps them from doing what they need to do. Getting them to give up SMM mode even though technically possible is requesting they give up a degree of control and thus a major social engineering challenge for anyone who wishes to achieve it. So any time we tread on territory that could mess up SMM mode we need to be careful, especially as we can not turn it off to diagnose problems. The interactions can be hard to root cause. Replacing overlapping MTRRs with a non overlapping set to allow X to set a WB region as YH is doing appears safe and reasonable, and worth doing. Going one step farther and reducing some of the WB memory to UC so we can free up an MTRR for video and to accelerate X is a bit chancy and something I don't feel comfortable with enabling by default. Especially as we have a better long term fix on the way. This problem is hitting enough people and the odds of something really bad happening when you take a 100x or 1000x slowdown in SMM are pretty low so I do think it is useful to have a kernel option that rounds down the amount of memory you have converts WB memory to UC to accelerate X. Hopefully by this point we are all now reminded how this can interact with SMM mode (although no one has ever seen a bad interaction) and how interacting with SMM mode can be a problem. Eric -- 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