Subject: | |
From: | |
Reply To: | |
Date: | Fri, 1 Mar 2013 08:12:51 +0900 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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.
|
|
|