linux-kernel - Re: [SFI-devel] [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial support

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] [day] [month] [year] [list]

Message-ID: <20090713032559.23220.qmail@stuge.se>
Date:	Mon, 13 Jul 2009 05:25:59 +0200
From:	Peter Stuge <peter@...ge.se>
To:	Pavel Machek <pavel@....cz>
Cc:	Len Brown <lenb@...nel.org>, sfi-devel@...plefirmware.org,
	linux-kernel@...r.kernel.org, coreboot@...eboot.org
Subject: Re: [SFI-devel] [RFC/PATCH 2.6.32] Simple Firmware Interface
	(SFI): initial support

Hi Pavel,

Pavel Machek wrote:
> > > ACPI can already do the job, right?

As Len explains, it can't.

> > > and operating systems already have to support ACPI.

I disagree here. How so? There are certainly other ways to accomplish
what ACPI does.

> > > So what are the reasons to reinvent the wheel?

Hardware developments push firmware and operating systems to new
places. I believe that's both neccessary and normal.

> > The Moorestown platform doesn't use ACPI because its chip-set
> > fundamentally does not support it.  Not only is the required
> > register set missing, *all* IO accesses are missing, and there is
> > no SMM support present to emuate it.
..
> Well, you should have just selected subset of ACPI, documenting that
> and implementing that. You would not have 'acpi compliant' logo, and
> windows XP would not boot on that, but at least you would not have
> created one more bios standard for people to support.

I don't think that's a practical option though.

I've been involved in the coreboot (formerly LinuxBIOS) project for a
good number of years, in part because I realized that the PC firmware
environment had lacked any serious developments for a very long time
and anything new, especially open source, was a good idea.

There's a certain stigma to coreboot in parts of the Linux kernel
community, because it's something very new and different in the x86
firmware landscape. Let me just say that I completely understand the
desire to resist changes in what is a somewhat functioning and at any
rate very wide spread technology. It seems that SFI is now facing
some of the same resistance, for much the same reason.

x86 architecture is changing, and firmware must change with it. It
will do operating systems good to join in, early on. Ideally there
will be much more cooperation across disciplines than in the past,
especially since hardware and software are already converging to a
point where good engineers on either side really must know also how
the other camp works. The only thing that remains with x86 is the
instruction set, every other part of the architecture has changed, is
changing, and will continue to change. That affects both firmware and
operating system of course.

ACPI is not always ideal, some may argue never. SFI strikes me as a
good complement. I think we will come to see further alternatives,
and finally I think that's a good thing, as software and hardware
continues to develop.

Of course it's not simple for operating systems. Nor for firmware.
But I don't believe the optimal and practical solution is to resist
rounder and lighter wheels.

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