linux-kernel - Re: [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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Jun 2009 21:45:24 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Len Brown <lenb@...nel.org>
Cc:	sfi-devel@...plefirmware.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial
	support

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.

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.

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.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/