SCIENTIFIC-LINUX-USERS Archives

March 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:
Tue, 5 Mar 2013 18:32:27 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
On Sat, Mar 2, 2013 at 11:09 PM, jdow <[log in to unmask]> wrote:
> On 2013/03/02 15:18, Tom H wrote:
>> On Fri, Mar 1, 2013 at 11:15 PM, jdow <[log in to unmask]> wrote:
>>> On 2013/03/01 09:26, Tom H wrote:
>>>> On Thu, Feb 28, 2013 at 7:08 PM, jdow <[log in to unmask]> wrote:
>>>>> On 2013/02/28 11:56, 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.
>>>>>
>>>>> Which is the end of compiling your own code.
>>>>
>>>> You mean "compiling your own kernel without spending a one-time fee of
>>>> USD
>>>> 99."
>>>
>>> A difference which makes no practical difference is no difference at all.
>>
>> Of course there's a difference. It's grub and the kernel and its
>> modules that you can't compile without signing.
>
> You missed the point, Tom. To a retired person a $100 bill is a serious
> amount of eating that has to be traded off with it. If that cannot be
> afforded without sacrifice then it might as well not exist as an option.
> That is the difference that makes no practical difference.
>
> The Microsoft extension to the issue is essentially the locked cellphone
> situation under which I could not code up any new assistive technology
> for myself and use it. It becomes me paying to have Microsoft own my
> device. And I'd have to pay them to use my own work on a machine I have
> every right to regard as my own machine.
>
> If Linux is going to systematically support that kind of a model in any
> way, I'm outahere.

You're "outahere" to where?! As long as you can turn off SB, you're OK
using whatever you want to use. If we get to a point where we can't
turn off SB on x86, you'll have to use a non-x86, non-ARM processor.

I didn't consider the USD 99 because I didn't think it relevant.
Compiling your own SB-compatible kernel's a luxury. Your computer
isn't non-functional without doing so.

Anyway, I found out today that my SB knowledge's out of date. The shim
now supports MOKs (Machine Owner Keys) and is distributed with a
"MokManager" program. So you can generate keys with openssl, sign your
EFI binaries with them, and enroll your MOK certificate with
"MokManager".

ATOM RSS1 RSS2