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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5B8ABB4480AEBB4ABFF06629589B20CD7230EEF8@orsmsx509.amr.corp.intel.com>
Date:	Tue, 23 Jun 2009 16:00:43 -0700
From:	"Justen, Jordan L" <jordan.l.justen@...el.com>
To:	Len Brown <lenb@...nel.org>, Matthew Garrett <mjg59@...f.ucam.org>
CC:	"sfi-devel@...plefirmware.org" <sfi-devel@...plefirmware.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [SFI-devel] [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI):
	initial support

Len,

> Should a platform require them, any and all of the ACPI
> defined/reserved tables can be accessed on an SFI system
> if needed.  Today, the PCI MCFG is the only ACPI table
> implemented in the known universe of SFI systems.

When for ACPI tables are used in SFI, they retain the common
ACPI header format, including the OEM Revision, Creator ID and
Creator Revision fields unlike the other SFI structure, correct?

Regarding stripping those fields from the SFI structures,
how much space does it save in a typical system versus if they
had retained the common header format that ACPI defines?

-Jordan

-----Original Message-----
From: sfi-devel-bounces@...plefirmware.org [mailto:sfi-devel-bounces@...plefirmware.org] On Behalf Of Len Brown
Sent: Tuesday, June 23, 2009 3:20 PM
To: Matthew Garrett
Cc: sfi-devel@...plefirmware.org; linux-kernel@...r.kernel.org
Subject: Re: [SFI-devel] [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial support

On Tue, 23 Jun 2009, Matthew Garrett wrote:

> I think I've got a clearer understanding of my objections to this now. 
> The first is that SFI is designed to support the subset of information 
> that's in ACPI and which can't be intuited by the OS. However, that 
> subset is predicated on the system looking like Moorestown. A system 
> that wants to provide any information beyond that subset can't use SFI 
> unless it defines additional tables.

Correct.

Per my previous message...

Should a platform require them, any and all of the ACPI
defined/reserved tables can be accessed on an SFI system
if needed.  Today, the PCI MCFG is the only ACPI table implemented
in the known universe of SFI systems.

WRT to native SFI table names...

int sfi_table_parse(char *signature, char *oem_id, char *oem_table_id,
                        uint flag, sfi_table_handler handler);

While the invocations in the tree today have NULL oem_id
and NULL oem_table_id, it is possible for a vendor to
stick their own name in there with their own table_id
and get the OS or a driver to find their home-brewed table
without reserving a table signature to the SFI spec.

However, should overwhemling demand for table signatures materialize,
I'm sure that a process can be put in place to manage collisions...

> And that brings me onto my second issue. ACPI is sufficiently 
> generalised that there's little need for vendors to add additional 
> tables. SFI isn't, and so vendor adoption is going to require 
> vendor-specific tables. This potentially results in SFI bloating out to 
> cover much of the functionality of ACPI, while at the same time turning 
> into a namespacing nightmare. Without a formal process for adding new 
> tables and without any kind of certification requirements before 
> claiming SFI compatibility, we're looking at a real risk of collisions.

The SFI table signatures are totally independent of the ACPI table
signatures -- they can not collide.  The only overlap is the XSDT
itself, which exists in SFI explicitly to separate the ACPI namespace
from the SFI namespace.

> SFI appears to be presented as a generic firmware interface, but in 
> reality it's currently tightly wed to Moorestown and I don't see any way 
> that that can be fixed without reinventing chunks of ACPI. I'm certainly 
> not enthusiastic about seeing this presented as a fait accompli in 
> generic driver code, rather than under arch/x86/moorestown.

SFI was invented with the goal to help a somewhat generic 
distro-supported kernel to boot and run optimally
on the Moorestown platform.  If SFI helps enable Moorestown
to participate in even just a small part of the vibrant
x86 open source development community, than it has been successful.

Yes, SFI is written to be "generic enough" so that it can be
used by more than Moorestown.  It is not trying to displace ACPI
on systems that are willing and able to support ACPI, but it
is freely available for those platforms that can't.

cheers,
-Len Brown, Intel Open Source Technology Center

_______________________________________________
sfi-devel mailing list
sfi-devel@...plefirmware.org
http://lists.simplefirmware.org/listinfo/sfi-devel
--
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/