On Thu, Feb 28, 2013 at 6:12 PM, zxq9 <[log in to unmask]> wrote:
> 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.

Until x86's locked down like ARM, you'll be able to upload your own
key to the hardware.

Ubuntu has a hardware program to have system's shipped with its key;
and unlike MS, it doesn't have a program to sign shims (I don't know
whether its specs allow you to upload your key). I'm sure that
Apple'll have its own key when it adopts SB; who knows how it'll
implement it. Chromebooks have a Google/ChromeOS/non-MS key and you
have to run in CMS mode to use another OS on them.

Most manufacturers will have the MS key and SB on by default because
that's the condition to have a Win8 sticker on their systems.