Secure Boot. Why don't you take the wind out of their sails?

Secure Boot. Why don't you take the wind out of their sails?

[Graham Cunnington]

[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]

Subject:  Secure Boot. Why don't you take the wind out of their sails?

(1) Now is the time to move quickly.
The development needs to be short and clear so that even a beginner can use it immediately.

(2)  The Problem:  

Microsoft and allied companies have an idea to force a Microsoft (Verisign) key on to hardware manufacturers which may be an attempt once again to bring in anti-competitive practices and may decrease the uptake of Linux systems.  The "Secure boot key" proposed could in fact limit consumer choice and drag Grub2 into a fight none of its making.

(3) The Problem of Verbosity: 

Grub2 already has the solution to protect Grub and therefore the kernels that Grub boots, but that solution is currently unavailable because Grub developers have no idea how to KISS. 

Keep It Simple Silly. Long-winded geeky sentences have no place in Grub.

"in some environments, such as kiosks, it may be appropriate to lock down
the boot loader to require authentication before performing certain operations.
The ‘password’ (see Section 14.3.33 [password], page 62) and ‘password_pbkdf2’ (see
Section 14.3.34 [password pbkdf2], page 62) commands can be used to define users, each
of which has an associated password. ‘password’ sets the password in plain text, requiring
‘grub.cfg’ to be secure; ‘password_pbkdf2’ sets the password hashed using the Password-
Based Key Derivation Function (RFC 2898), requiring the use of grub-mkpasswd-pbkdf2
(see Chapter 30 [Invoking grub-mkpasswd-pbkdf2], page 101) to generate password hashes.
In order to enable authentication support, the ‘superusers’ environment variable
must be set to a list of usernames, separated by any of spaces, commas, semicolons, pipes,
or ampersands. Superusers are permitted to use the GRUB command line, edit menu
entries, and execute any menu entry. If ‘superusers’ is set, then use of the command line
is automatically restricted to superusers."

The above is incomprehensible to most users who are not developers.  Why not just say:

"You can password-protect Grub.  This will secure it against malware and anybody taking over your computer."


(4) The Solution:

(a) Insert into the standard Grub Menu a link which says:  Set a password on Grub, which when clicked allows the user to do so.

(b) If this has already been done, then on switching on the computer, the password dialog box should pop up prior to the boot Menu.

(c) If this is done then we already have Secure Boot and the administrators of companies and home computers will have protected their computers and the Microsoft initiative becomes unnecessary, at least for Secure Boot (Secure Bios is another matter and another battle).

(d) do it quickly, keep it simple, keep it smart then tell the world what you have done.

Computer journalists will love you for it.

Remember, it has to be easy to understand even to people new to computers can quickly set a password on their boot.


(5) Who am I?
A pemsioner with no background in computing, science or mathematics.
I came to computing late and have been using only open-source software for 8 years.
I have 2 oldish computers. On one I am multi-bootiong 14 operating systems with Grub2 (13 Linux + Haiku, an experimental modular operating system).


Best wishes

grahamc

[-- Attachment #2: Type: text/html, Size: 3713 bytes --]

Re: Secure Boot. Why don't you take the wind out of their sails?

[Chris Murphy]

On Jul 9, 2012, at 4:38 PM, Graham Cunnington wrote:

> 
> "You can password-protect Grub.  This will secure it against malware and anybody taking over your computer."

Because it's an untrue statement.

It is not the same thing as key-signing a boot loader. While GRUB2's UI's can be protected, I can easily cause grub.efi to be replaced with some other bootloader which happens to be malware, or replace the kernel a password protected GRUB2 is set to load with a kernel that contains malware.

> e then we already have Secure Boot and the administrators of companies and home computers will have protected their computers and the Microsoft initiative becomes unnecessary, at least for Secure Boot (Secure Bios is another matter and another battle).

There is no meaning to secure BIOS. And what you're describing GRUB2 do in lieu of Secure Boot doesn't prevent any of the problems/concerns Secure Boot is supposed to solve. That there are significant negative concerns for how OEM's are going to implement Secure Boot, this is not a compelling argument against Secure Boot or against the real threat of pre-boot malware.

Your complaint is with OEMs way more than Microsoft, and way more than GNU GRUB2.


Chris Murphy

Re: Secure Boot. Why don't you take the wind out of their sails?

[Andreas Born]

Am 10.07.2012 00:38, schrieb Graham Cunnington:
> The above is incomprehensible to most users who are not developers.  
> Why not just say:
>
> "You can password-protect Grub.  This will secure it against malware 
> and anybody taking over your computer."
This is in no way comparable to Secure Boot or TPM measure in general. A 
password just prevents THIS instance of grub and THIS grub configuration 
from being used to boot systems in an unintended manner by unauthorized 
individuals. It can be easily circumvented by e.g. booting from a CDROM 
or USB drive (hardware access is the key here). Password-based menus are 
inherently insecure when used with physical access. It's commonly 
described as security by obscurity. Just locking the one most obvious 
entry in a secure manner doesn't make the whole building safe if there 
are other slightly hidden, unlocked entries. Security AND obscurity 
combined can offer additional security (e.g. all doors locked and hidden).

Furthermore password-based menus don't prevent that installation of grub 
to be replaced by a malicious modified instance of grub which could e.g. 
log your password and could load a maliciously modified kernel. That's 
because unlike other measure like Secure Boot it does not verify the 
code executed. Instead you're just trusting the code to correctly verify 
the password and it does not even check the kernel. To be protected 
against malicious code there needs to be a secure component that checks 
every code executed by the computer at any point for trustworthiness. 
That's simply put and sort of an optimal scenario. In reality you won't 
be able to check more than a sensible selection for administrative 
reasons (except for clearly defined use cases like some embedded 
devices) and it's somewhat more complicated.

So we have two completely different use cases here:
- passwords: verification of the user i.e. the human individual trying 
to use that bootloader instance (not anything else), could be 
ineffective with malicious code which is not checked here
- TPM or Secure Boot: verification of the actual code executed i.e. no 
malicious software is executed if everything is verified (practically 
impossible) and if nobody is able to get his malicious code trusted due 
to human or administrative mistakes e.g.

AFAIK as with Secure Boot almost nothing is verified the glamorously 
advertised, all-encompassing, magic protection is actually a fallacy and 
just very limited. If it weren't for the seemingly obvious true concerns 
of global companies, it could actually be quite an interesting technology.


Andreas Born

Re: Secure Boot. Why don't you take the wind out of their sails?

[richardvoigt]

I'll decloak to offer my response, but please remember that I'm not
one of the developers so my opinion is of limited value.  By the same
token, I've been recognized by Microsoft for community contributions,
but I do not work for them and do not speak for them.

First, putting things in simple language is very positive and necessary.

However, your short easy-to-understand summary is incorrect.  The
bootloader password doesn't protect against malware, and it offers
only a little protection against "anybody taking over your computer".
In fact, if some malware rewrote the grub configuration file, it could
be quite annoying to recover.

Also, the bootloader password solves a very different problem from the
secure boot initiative.  The grub password check doesn't verify
integrity of system files.

Finally, the secure boot initiative isn't a threat to open source
operating systems.  The computer administrator has to install a signed
OS and then enable signature verification in the firmware.  All
systems ship with verification disabled, and all the major motherboard
manufacturers have indicated that secure boot will always stay an
opt-in mechanism.  And even then, the firmware setup utility can be
used to once again disable verification, so it isn't even a hindrance
to resale of used equipment, as long as the sale is authorized and the
configuration is changed.  It might create some barrier to use of
stolen equipment, but even then it is likely that clearing the NVRAM
by removing the backup battery will gain access.  Full-disk encryption
is still the best safeguard in case physical security is compromised.

So definitely, this sort of thing needs to be summarized and then
explained in detail using plain English that can be understood by
those who aren't so technically astute.  But lets not sacrifice
accuracy in the desire to use simpler words.

Ben Voigt

On Mon, Jul 9, 2012 at 5:38 PM, Graham Cunnington <geecee4u5@yahoo.co.uk> wrote:
> Subject:  Secure Boot. Why don't you take the wind out of their sails?
>
> (1) Now is the time to move quickly.
> The development needs to be short and clear so that even a beginner can use
> it immediately.
>
> (2)  The Problem:
>
> Microsoft and allied companies have an idea to force a Microsoft (Verisign)
> key on to hardware manufacturers which may be an attempt once again to bring
> in anti-competitive practices and may decrease the uptake of Linux systems.
> The "Secure boot key" proposed could in fact limit consumer choice and drag
> Grub2 into a fight none of its making.
>
> (3) The Problem of Verbosity:
>
> Grub2 already has the solution to protect Grub and therefore the kernels
> that Grub boots, but that solution is currently unavailable because Grub
> developers have no idea how to KISS.
>
> Keep It Simple Silly. Long-winded geeky sentences have no place in Grub.
>
> "in some environments, such as kiosks, it may be appropriate to lock down
> the boot loader to require authentication before performing certain
> operations.
> The ‘password’ (see Section 14.3.33 [password], page 62) and
> ‘password_pbkdf2’ (see
> Section 14.3.34 [password pbkdf2], page 62) commands can be used to define
> users, each
> of which has an associated password. ‘password’ sets the password in plain
> text, requiring
> ‘grub.cfg’ to be secure; ‘password_pbkdf2’ sets the password hashed using
> the Password-
> Based Key Derivation Function (RFC 2898), requiring the use of
> grub-mkpasswd-pbkdf2
> (see Chapter 30 [Invoking grub-mkpasswd-pbkdf2], page 101) to generate
> password hashes.
> In order to enable authentication support, the ‘superusers’ environment
> variable
> must be set to a list of usernames, separated by any of spaces, commas,
> semicolons, pipes,
> or ampersands. Superusers are permitted to use the GRUB command line, edit
> menu
> entries, and execute any menu entry. If ‘superusers’ is set, then use of the
> command line
> is automatically restricted to superusers."
>
> The above is incomprehensible to most users who are not developers.  Why not
> just say:
>
> "You can password-protect Grub.  This will secure it against malware and
> anybody taking over your computer."
>
>
> (4) The Solution:
>
> (a) Insert into the standard Grub Menu a link which says:  Set a password on
> Grub, which when clicked allows the user to do so.
>
> (b) If this has already been done, then on switching on the computer, the
> password dialog box should pop up prior to the boot Menu.
>
> (c) If this is done then we already have Secure Boot and the administrators
> of companies and home computers will have protected their computers and the
> Microsoft initiative becomes unnecessary, at least for Secure Boot (Secure
> Bios is another matter and another battle).
>
> (d) do it quickly, keep it simple, keep it smart then tell the world what
> you have done.
>
> Computer journalists will love you for it.
>
> Remember, it has to be easy to understand even to people new to computers
> can quickly set a password on their boot.
>
>
> (5) Who am I?
> A pemsioner with no background in computing, science or mathematics.
> I came to computing late and have been using only open-source software for 8
> years.
> I have 2 oldish computers. On one I am multi-bootiong 14 operating systems
> with Grub2 (13 Linux + Haiku, an experimental modular operating system).
>
>
> Best wishes
>
> grahamc
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Secure Boot. Why don't you take the wind out of their sails?

[Andreas Born]

Am 10.07.2012 03:23, schrieb richardvoigt@gmail.com:
> I'll decloak to offer my response, but please remember that I'm not
> one of the developers so my opinion is of limited value.  By the same
> token, I've been recognized by Microsoft for community contributions,
> but I do not work for them and do not speak for them.
>
> First, putting things in simple language is very positive and necessary.
Did anybody comment on or deny it?
>
> However, your short easy-to-understand summary is incorrect.  The
> bootloader password doesn't protect against malware, and it offers
> only a little protection against "anybody taking over your computer".
> In fact, if some malware rewrote the grub configuration file, it could
> be quite annoying to recover.
No, you're incorrect. The password is stored IN the grub configuration 
file. So if that person can rewrite the grub configuration file it can 
rewrite the password too (or fully disable it or ...). Thus that 
protection becomes fully INEFFECTIVE. Even if the password were stored 
in a separate file that file could be changed just as well.
>
> Also, the bootloader password solves a very different problem from the
> secure boot initiative.  The grub password check doesn't verify
> integrity of system files.
Yes, that's the point. As they are not related one can't do the job of 
the other one unlike what you suggest in your initial mail.
>
> Finally, the secure boot initiative isn't a threat to open source
> operating systems.  The computer administrator has to install a signed
> OS and then enable signature verification in the firmware.  All
> systems ship with verification disabled, and all the major motherboard
> manufacturers have indicated that secure boot will always stay an
> opt-in mechanism.  And even then, the firmware setup utility can be
> used to once again disable verification, so it isn't even a hindrance
> to resale of used equipment, as long as the sale is authorized and the
> configuration is changed.  It might create some barrier to use of
> stolen equipment, but even then it is likely that clearing the NVRAM
> by removing the backup battery will gain access.
Nobody's saying that the basic technology which is not exactly new 
either is a threat. But the implementation SecureBoot is. You're 
misinformed. While on x86 systems there's a switch required to disable 
SecureBoot that same switch is NOT ALLOWED for ARM systems 
(https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/restricted-boot-comic-contest-defend-user-freedom-on-tablets-and-smartphones). 
Please get your facts straight.
Apart from that even if there is a switch the question remains how 
easily accessible it is going to be? How obvious the need to use it is 
going to be? You're the guy asking for stuff to be simple so that point 
should be clear to you.
> Full-disk encryption
> is still the best safeguard in case physical security is compromised.
There's still some code loaded and executed before opening the volume. 
That code is responsible for initially decrypting the volume and loading 
something else from within it. Now I say "decrypt" so that means that 
code needs to get credentials from somewhere and if that code were 
malicious it would be given the credentials (as it would appear no 
different to the user) and could use them for anything. No way getting 
around verification of the code unless you have a firmware that supports 
booting from that volume directly but then again the firmware needs to 
be verified by some means too.
Imagine you're giving a party and want some sort of entry control. As 
long as you don't verify somebody (code) to be trusted to execute the 
entry control by checking everybody's invite (credentials), there's no 
way to have it invites-only. If you're lacking credentials it won't work 
and if the doorman are untrusted they could not be checking the 
invites/credentials properly. You can't get rid of either one of them 
completely.
>
> So definitely, this sort of thing needs to be summarized and then
> explained in detail using plain English that can be understood by
> those who aren't so technically astute.  But lets not sacrifice
> accuracy in the desire to use simpler words.
>
> Ben Voigt
>
> On Mon, Jul 9, 2012 at 5:38 PM, Graham Cunnington <geecee4u5@yahoo.co.uk> wrote:
>> Subject:  Secure Boot. Why don't you take the wind out of their sails?
>>
>> (1) Now is the time to move quickly.
>> The development needs to be short and clear so that even a beginner can use
>> it immediately.
>>
>> (2)  The Problem:
>>
>> Microsoft and allied companies have an idea to force a Microsoft (Verisign)
>> key on to hardware manufacturers which may be an attempt once again to bring
>> in anti-competitive practices and may decrease the uptake of Linux systems.
>> The "Secure boot key" proposed could in fact limit consumer choice and drag
>> Grub2 into a fight none of its making.
>>
>> (3) The Problem of Verbosity:
>>
>> Grub2 already has the solution to protect Grub and therefore the kernels
>> that Grub boots, but that solution is currently unavailable because Grub
>> developers have no idea how to KISS.
>>
>> Keep It Simple Silly. Long-winded geeky sentences have no place in Grub.
>>
>> "in some environments, such as kiosks, it may be appropriate to lock down
>> the boot loader to require authentication before performing certain
>> operations.
>> The ‘password’ (see Section 14.3.33 [password], page 62) and
>> ‘password_pbkdf2’ (see
>> Section 14.3.34 [password pbkdf2], page 62) commands can be used to define
>> users, each
>> of which has an associated password. ‘password’ sets the password in plain
>> text, requiring
>> ‘grub.cfg’ to be secure; ‘password_pbkdf2’ sets the password hashed using
>> the Password-
>> Based Key Derivation Function (RFC 2898), requiring the use of
>> grub-mkpasswd-pbkdf2
>> (see Chapter 30 [Invoking grub-mkpasswd-pbkdf2], page 101) to generate
>> password hashes.
>> In order to enable authentication support, the ‘superusers’ environment
>> variable
>> must be set to a list of usernames, separated by any of spaces, commas,
>> semicolons, pipes,
>> or ampersands. Superusers are permitted to use the GRUB command line, edit
>> menu
>> entries, and execute any menu entry. If ‘superusers’ is set, then use of the
>> command line
>> is automatically restricted to superusers."
>>
>> The above is incomprehensible to most users who are not developers.  Why not
>> just say:
>>
>> "You can password-protect Grub.  This will secure it against malware and
>> anybody taking over your computer."
>>
>>
>> (4) The Solution:
>>
>> (a) Insert into the standard Grub Menu a link which says:  Set a password on
>> Grub, which when clicked allows the user to do so.
>>
>> (b) If this has already been done, then on switching on the computer, the
>> password dialog box should pop up prior to the boot Menu.
>>
>> (c) If this is done then we already have Secure Boot and the administrators
>> of companies and home computers will have protected their computers and the
>> Microsoft initiative becomes unnecessary, at least for Secure Boot (Secure
>> Bios is another matter and another battle).
>>
>> (d) do it quickly, keep it simple, keep it smart then tell the world what
>> you have done.
>>
>> Computer journalists will love you for it.
>>
>> Remember, it has to be easy to understand even to people new to computers
>> can quickly set a password on their boot.
>>
>>
>> (5) Who am I?
>> A pemsioner with no background in computing, science or mathematics.
>> I came to computing late and have been using only open-source software for 8
>> years.
>> I have 2 oldish computers. On one I am multi-bootiong 14 operating systems
>> with Grub2 (13 Linux + Haiku, an experimental modular operating system).
>>
>>
>> Best wishes
>>
>> grahamc
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Secure Boot. Why don't you take the wind out of their sails?

[richardvoigt]

>> However, your short easy-to-understand summary is incorrect.  The
>> bootloader password doesn't protect against malware, and it offers
>> only a little protection against "anybody taking over your computer".
>> In fact, if some malware rewrote the grub configuration file, it could
>> be quite annoying to recover.
>
> No, you're incorrect. The password is stored IN the grub configuration file.
> So if that person can rewrite the grub configuration file it can rewrite the
> password too (or fully disable it or ...). Thus that protection becomes
> fully INEFFECTIVE. Even if the password were stored in a separate file that
> file could be changed just as well.

You just made my point ;)  Malware can change the bootloader password,
since it's simply stored in a file, making you jump through quite a
number of hoops before being able to use your computer again.


[snip]

>> Finally, the secure boot initiative isn't a threat to open source
>> operating systems.  The computer administrator has to install a signed
>> OS and then enable signature verification in the firmware.  All
>> systems ship with verification disabled, and all the major motherboard
>> manufacturers have indicated that secure boot will always stay an
>> opt-in mechanism.  And even then, the firmware setup utility can be
>> used to once again disable verification, so it isn't even a hindrance
>> to resale of used equipment, as long as the sale is authorized and the
>> configuration is changed.  It might create some barrier to use of
>> stolen equipment, but even then it is likely that clearing the NVRAM
>> by removing the backup battery will gain access.
>
> Nobody's saying that the basic technology which is not exactly new either is
> a threat. But the implementation SecureBoot is. You're misinformed. While on
> x86 systems there's a switch required to disable SecureBoot that same switch
> is NOT ALLOWED for ARM systems
> (https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/restricted-boot-comic-contest-defend-user-freedom-on-tablets-and-smartphones).
> Please get your facts straight.
> Apart from that even if there is a switch the question remains how easily
> accessible it is going to be? How obvious the need to use it is going to be?
> You're the guy asking for stuff to be simple so that point should be clear
> to you.

Uh no, I'm not "that guy".  I was calling out "that guy" on his claim
that a bootloader password protects against malware, while trying to
be very clear that it isn't the idea of a simple explanation I object
to, but the fact that accuracy was sacrificed.  I was in a meeting
between reading the OP and the time my response went out, I didn't see
the other replies.

>
>> Full-disk encryption
>> is still the best safeguard in case physical security is compromised.
>
> There's still some code loaded and executed before opening the volume. That
> code is responsible for initially decrypting the volume and loading
> something else from within it. Now I say "decrypt" so that means that code
> needs to get credentials from somewhere and if that code were malicious it
> would be given the credentials (as it would appear no different to the user)
> and could use them for anything. No way getting around verification of the
> code unless you have a firmware that supports booting from that volume
> directly but then again the firmware needs to be verified by some means too.
> Imagine you're giving a party and want some sort of entry control. As long
> as you don't verify somebody (code) to be trusted to execute the entry
> control by checking everybody's invite (credentials), there's no way to have
> it invites-only. If you're lacking credentials it won't work and if the
> doorman are untrusted they could not be checking the invites/credentials
> properly. You can't get rid of either one of them completely.

Where did I say otherwise?

Re: Secure Boot. Why don't you take the wind out of their sails?

[Chris Murphy]

On Jul 9, 2012, at 7:23 PM, richardvoigt@gmail.com wrote:
>  All
> systems ship with verification disabled, and all the major motherboard
> manufacturers have indicated that secure boot will always stay an
> opt-in mechanism.

This is mystifying because it directly contradicts the Microsoft Windows hardware certification requirements, which require that to get the made for Windows 8 certification, the hardware must be UEFI, must implement Secure Boot, must have it enabled by default (except servers), and must have a Microsoft key included. It also requires a user chooseable option to disable Secure Boot on x86, but not ARM.


Chris Murphy

Re: Secure Boot. Why don't you take the wind out of their sails?

[richardvoigt]

On Tue, Jul 10, 2012 at 12:04 AM, Chris Murphy <lists@colorremedies.com> wrote:
>
> On Jul 9, 2012, at 7:23 PM, richardvoigt@gmail.com wrote:
>>  All
>> systems ship with verification disabled, and all the major motherboard
>> manufacturers have indicated that secure boot will always stay an
>> opt-in mechanism.
>
> This is mystifying because it directly contradicts the Microsoft Windows hardware certification requirements, which require that to get the made for Windows 8 certification, the hardware must be UEFI, must implement Secure Boot, must have it enabled by default (except servers), and must have a Microsoft key included. It also requires a user chooseable option to disable Secure Boot on x86, but not ARM.

Maybe I'm missing something, but when I read this, it doesn't say the
hardware must have Secure Boot enabled by default.  Rather, it must be
enabled by the OEM as part of the Windows preinstallation process, so
that it's enabled when it reaches the end user.  System builders are
still going to purchase UEFI Secure Boot-capable motherboards with
Secure Boot disabled-by-default, and they will "just work" if you want
to install Linux.  End-users who bought pre-installed Windows will
have to change the configuration option in system setup, which for
someone planning to install a new OS from scratch is not a major
hurdle.  It will be a minor road bump for people using live-CD style
media (including USB), but won't be a showstopper if the user actually
has permission from the computer owner to boot the alternate media.
What likely is that it will prevent unauthorized (by the owner)
rebooting public computers using alternate media, but that's not
exactly a valid scenario to begin with.

ARM is a red herring, IMO.  Pretty much all ARM processors include
some sort of code security module that blocks external access to the
bootloader without the correct reprogramming key.  This is pretty
standard for embedded systems, and has been for decades.  Most
embedded systems aren't designed to boot from removable media.

Most tablets don't give the end user root privilege.  That's a shame,
and something we should work to fix, but going around telling everyone
that the world will end if Microsoft gets Secure Boot onto media
devices is just dishonest.  Those devices have been locked down
already, and the world didn't end.

Re: Secure Boot. Why don't you take the wind out of their sails?

[Bruce Dubbs]

richardvoigt@gmail.com wrote:

> Maybe I'm missing something, but when I read this, it doesn't say the
> hardware must have Secure Boot enabled by default.  Rather, it must be
> enabled by the OEM as part of the Windows preinstallation process, so
> that it's enabled when it reaches the end user.  System builders are
> still going to purchase UEFI Secure Boot-capable motherboards with
> Secure Boot disabled-by-default, and they will "just work" if you want
> to install Linux.

For people who are not experts, trying Linux or another operating system 
becomes much more intimidating.  They have to go into the BIOS and 
change something.  Then, to go back to Windows, they have to do it again.

Will this discourage users from trying something else?  You bet.

End-users who bought pre-installed Windows will
> have to change the configuration option in system setup, which for
> someone planning to install a new OS from scratch is not a major
> hurdle.  It will be a minor road bump for people using live-CD style
> media (including USB), but won't be a showstopper if the user actually
> has permission from the computer owner to boot the alternate media.
> What likely is that it will prevent unauthorized (by the owner)
> rebooting public computers using alternate media, but that's not
> exactly a valid scenario to begin with.

But is is for private computers.  My LUG frequently gives out DVDs with 
various Live system and say try it.  That will become much more 
problematic.

I still don't know how someone is supposed to be able to boot Windows 
within a VM with this new paradigm.

   -- Bruce

Re: Secure Boot. Why don't you take the wind out of their sails?

[Lennart Sorensen]

On Tue, Jul 10, 2012 at 11:29:21AM -0500, Bruce Dubbs wrote:
> For people who are not experts, trying Linux or another operating
> system becomes much more intimidating.  They have to go into the
> BIOS and change something.  Then, to go back to Windows, they have
> to do it again.

No windows boots fine without the secure boot enabled.

> Will this discourage users from trying something else?  You bet.

Oh that's for sure.  That part is clearly on purpose. :)

> But is is for private computers.  My LUG frequently gives out DVDs
> with various Live system and say try it.  That will become much more
> problematic.
> 
> I still don't know how someone is supposed to be able to boot
> Windows within a VM with this new paradigm.

Windows will work fine without secure boot, it just won't have the
malware protection secure boot is supposed to offer.

-- 
Len Sorensen