SCIENTIFIC-LINUX-USERS Archives

February 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Fri, 1 Mar 2013 08:12:51 +0900
Content-Type:
text/plain
Parts/Attachments:
text/plain (46 lines)
On 03/01/2013 04:56 AM, Tom H wrote:
> On Thu, Feb 28, 2013 at 2:38 PM, Robert Blair<[log in to unmask]>  wrote:
>> On 02/28/2013 01:35 PM, Tom H wrote:
>>>
>>> I wouldn't be surprised if SB became "un-disable-able" in the next
>>> few years. We'd then have to use an MS-signed shim to boot, as is
>>> now the case with the default Fedora and Ubuntu SB setups.
>>
>> Maybe I've missed something here. If a generic "MS signed shim" is
>> available what value does this add? Wouldn't such a shim make booting
>> anything alternative possible?
>
> I'm sorry. It's not as generic as I made it look. AIUI, the shim is a
> basic stage 1 (or maybe stage 0.5) bootloader whose signature's
> validated against an MS key in the computer's ROM. Grub and the kernel
> (and its modules in Fedora's case but not in Ubuntu's) are then
> validated against a Fedora key in the shim.

Board makers are willing to place alternatives to the MS key on boards 
if asked. I doubt that will be permitted for single purchases, though. 
This has the unfortunate effect of locking a buyer in to the non-MS 
vendor the same way the MS key locks the buyer in to MS (whether a shim 
is signed by the MS key via the RH/MS deal or not is not the point -- 
they hold all the power in that relationship). So if my company decided 
to sell secure boot boards/devices with our key on it and secure boot 
enabled, we could. But it would lower the value of the board to the 
buyer because they would be stuck hoping that whatever distro(s) we felt 
like providing signed versions of.

It still doesn't do anything to actually protect the running system, 
especially since it plays zero role in what happens after boot. We've 
been trying for over a decade now to segregate parts of instruction 
memory from data memory by dictating the map and how its loaded, getting 
more inventive each time. With UEFI we're pushing that as far down as 
possible without hardwiring the OS bits -- but none of it matters when, 
ultimately, regardless how and what runtime is loaded data and 
instruction bits are still living in the same space. To attack this 
problem any further is to re-discover the Harvard architecture and 
viola, x86 (indeed, most things about the von Neumann arch family) are 
obsoleted by a return to segregated throughput architectures...

Anyway, I doubt that board makers will completely close the door to 
alternative keys and/or shipping systems with CRM-boot enableable by 
default on request. But this isn't going to help an individual purchaser 
looking for a laptop or other pre-built through retail channels.

ATOM RSS1 RSS2