linux-kernel - Re: [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v5

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: <m18wywuooz.fsf@frodo.ebiederm.org>
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/