linux-kernel - Re: [RFC][Patch] IBM Real-Time "SMI Free" mode drive -v2

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]

Date:	Wed, 16 Dec 2009 17:50:55 -0800
From:	Keith Mannthey <kmannth@...ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	John Stultz <johnstul@...ibm.com>
Subject: Re: [RFC][Patch] IBM Real-Time "SMI Free" mode drive -v2

On Thu, 2009-12-17 at 00:09 +0100, Peter Zijlstra wrote:
> On Tue, 2009-12-15 at 12:09 -0800, Keith Mannthey wrote:
> > This driver supports the Real-Time Linux (RTL) BIOS feature.  The RTL
> > feature allows non-fatal System Management Interrupts (SMIs) to be
> > disabled on supported IBM platforms. 
> > 
> > 
> > The Device is presented as a special "_rtl_" table to the OS in the
> > Extended BIOS Data Area.  There is a simple protocol for entering and
> > exiting the mode at runtime.  This driver creates a simple sysfs
> > interface to allow a simple entry and exit from RTL mode in the
> > UFI/BIOS. 
> 
> Why not simply always run with these non-fatal SMIs disabled and provide
> their function through the OS proper?
> 
> That way you don't need no silly switches and gain consistent platform
> behaviour.

Peter, 

This driver will load and work on widely used Intel and AMD based IBM
hardware.  A decent amount of the IBM blades and a few of the rack-mount
servers with regular firmware support this mode.  This is not special
hardware with special features is is regular hardware/firmware that can
enter this special mode.

There are 2 major things that change when you in this mode that keep it
from being a good fit for many situations. 

1. ECC memory error detection and reporting is the sole responsibility
of the OS. I have practical experience with this and let just say this
does not "just work" everywhere even within Linux. 

2. The cpu can no longer be externally throttled. This means externally
implemented cooling or power saving options just don't work. 

These 2 things make it impractical for it to be an all the time
everywhere type of thing.  I think a run time state change the OS can
request is a good fit for the issues and complications at hand.

Thanks,
  Keith Mannthey 
  LTC Real-Time 

--
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/