No subject
Fri Jun 24 16:40:32 EST 2011
Perhaps a release that firmly and fairly challenges OEMs to announce their plans would be a good start?
<BR>
<BR>
I also have questions around virtual bootloaders....
<BR>
<BR>
Will UEFI eventually be implemented in hypervisors?
BW
<TABLE CELLSPACING="0" CELLPADDING="0" BORDER="1">
<TR>
<TD>
<FONT SIZE="2">email message attachment (Re: [Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?)</FONT>
</TD>
</TR>
</TABLE>
-------- Forwarded Message --------<BR>
<B>From</B>: James Turnbull <<A HREF="mailto:James%20Turnbull%20%3cjames at lovedthanlost.net%3e">james at lovedthanlost.net</A>><BR>
<B>Reply-to</B>: james at lovedthanlost.net<BR>
<B>To</B>: <A HREF="mailto:linux-aus at lists.linux.org.au">linux-aus at lists.linux.org.au</A><BR>
<B>Subject</B>: Re: [Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?<BR>
<B>Date</B>: Sat, 04 Aug 2012 23:02:14 -0700<BR>
<BR>
<PRE>
Here's my ten cents - firstly what's your actual call to arms? Why
should anyone care about the issue? The press release should leave the
journo with a clear picture of: "UEFI Secure Boot is a danger to ... and
we would like x."
A good press release should be structured like:
1. Headline
What's it all about... "Linux Australia opposes UEFI Secure Boot"
2. Lead
Catchy short, paragraph grabbing the journo and laying out the problem
in two-three short sentences. Half the journos that read press releases
have zero idea what the technology is and what the implications are so
you need to lay out what it actually is and why they should bother to
care about it and your opinion on it.
3. Position & Backup
LA's position is that ... whatever the position is ... because ... xyz.
Backed up my x other organisations/research/etc.
4. Call to arms
LA would like people/govt/industry to do x and y.
5. Closing & Follow-up
Linux Australia is the peak body for Linux and open source software in
Australia and represents ... blah blah constituents, LCA, LUGs, etc,
etc. Links to contacts for the issue/sites/news etc.
Regards
James Turnbull
</PRE>
<TABLE CELLSPACING="0" CELLPADDING="0" BORDER="1">
<TR>
<TD>
<FONT SIZE="2">email message attachment</FONT>
</TD>
</TR>
</TABLE>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" BORDER="1">
<TR>
<TD>
<FONT SIZE="2">email message attachment (Re: [Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?)</FONT>
</TD>
</TR>
</TABLE>
-------- Forwarded Message --------<BR>
<B>From</B>: Russell Coker <<A HREF="mailto:Russell%20Coker%20%3crussell at coker.com.au%3e">russell at coker.com.au</A>><BR>
<B>Reply-to</B>: russell at coker.com.au<BR>
<B>To</B>: <A HREF="mailto:linux-aus at lists.linux.org.au">linux-aus at lists.linux.org.au</A><BR>
<B>Subject</B>: Re: [Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?<BR>
<B>Date</B>: Sun, 5 Aug 2012 16:21:19 +1000<BR>
<BR>
<PRE>
On Sun, 5 Aug 2012, Adam Nielsen <<A HREF="mailto:a.nielsen at shikadi.net">a.nielsen at shikadi.net</A>> wrote:
> 3. Secure Boot is great, providing we have control over the keys our
> equipment recognises as valid.
>
> My personal position is the last one. I think Secure Boot could work well,
> if I can remove the Microsoft keys (since they're bound to be compromised
> sooner or later) and install my own, only allowing my chosen Linux kernels
> to boot and nothing else.
For the personal use of people like me a solution could involve typing in a
string of 32 hexadecimal digits. For the general public that won't work.
So merely having control over the keys isn't adequate if the usability issues
prevent most people from being able to perform reasonable tasks such as
installing a random distribution of Linux.
Secure boot should be relatively easy to turn off by authorized people. Years
ago it was common to have a keyboard lock on the front of a PC. Turn the key
and no-one can type on an AT keyboard that's connected. It wouldn't be
difficult to design a PC in a similar manner, turn the physical key and you
can install an OS without a RSA key - or update the BIOS set of keys in some
easy manner.
The Red Hat solution of paying money to MS for a signature on their boot
loader is a reasonable solution for them, but it's bad for Linux companies to
be forced to pay money to MS. Just imagine how MS would complain if they had
to pay money to a company like IBM for signatures. If the first IBM PC had
such a boot lock then MS might not even exist as we know it today.
On Sun, 5 Aug 2012, Brent Wallis <<A HREF="mailto:brent.wallis at gmail.com">brent.wallis at gmail.com</A>> wrote:
> I also have questions around virtual bootloaders....
>
> Will UEFI eventually be implemented in hypervisors?
I had the impression that someone had already written such support for testing
UEFI booting. But in terms of actual use, why bother? With Xen or KVM you
can boot a kernel that's stored outside the virtual machine environment. In
that case any trojan running in the VM can't attack it and any trojan that can
attack it can probably do something worse than just attacking one VM.
</PRE>
<TABLE CELLSPACING="0" CELLPADDING="0" BORDER="1">
<TR>
<TD>
<FONT SIZE="2">email message attachment (Re: [Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?)</FONT>
</TD>
</TR>
</TABLE>
-------- Forwarded Message --------<BR>
<B>From</B>: Adam Nielsen <<A HREF="mailto:Adam%20Nielsen%20%3ca.nielsen at shikadi.net%3e">a.nielsen at shikadi.net</A>><BR>
<B>To</B>: <A HREF="mailto:linux-aus at lists.linux.org.au">linux-aus at lists.linux.org.au</A><BR>
<B>Subject</B>: Re: [Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?<BR>
<B>Date</B>: Sun, 05 Aug 2012 17:34:42 +1000<BR>
<BR>
<PRE>
>> I also have questions around virtual bootloaders....
>>
>> Will UEFI eventually be implemented in hypervisors?
>
> I had the impression that someone had already written such support for testing
> UEFI booting. But in terms of actual use, why bother? With Xen or KVM you
> can boot a kernel that's stored outside the virtual machine environment. In
> that case any trojan running in the VM can't attack it and any trojan that can
> attack it can probably do something worse than just attacking one VM.
I thought the long-term idea behind Secure Boot was that once the OS kernel is
secure, it can enforce the signing of applications too. Unlike now, there
would be no way to circumvent this by patching the kernel to allow unsigned
applications to run, as then the kernel wouldn't be allowed to boot. If your
application hasn't been signed, you can't run it.
From there it would be a simple matter to require all VM software to only
boot correctly signed kernels within the VM, or MS won't sign the VM
application. Thus if (when?) this day arrives, you won't be able to boot an
unsigned Linux kernel on your PC at all, not even in a VM...
Cheers,
Adam.
</PRE>
<TABLE CELLSPACING="0" CELLPADDING="0" BORDER="1">
<TR>
<TD>
<FONT SIZE="2">email message attachment (Re: [Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?)</FONT>
</TD>
</TR>
</TABLE>
-------- Forwarded Message --------<BR>
<B>From</B>: Bianca Gibson <<A HREF="mailto:Bianca%20Gibson%20%3cbianca.rachel.gibson at gmail.com%3e">bianca.rachel.gibson at gmail.com</A>><BR>
<B>To</B>: <A HREF="mailto:linux-aus at lists.linux.org.au">linux-aus at lists.linux.org.au</A><BR>
<B>Subject</B>: Re: [Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?<BR>
<B>Date</B>: Sun, 5 Aug 2012 18:31:15 +1000<BR>
<BR>
On 5 August 2012 13:20, Adam Nielsen <<A HREF="mailto:a.nielsen at shikadi.net">a.nielsen at shikadi.net</A>> wrote:
<BLOCKQUOTE>
3. Secure Boot is great, providing we have control over the keys our<BR>
equipment recognises as valid.
</BLOCKQUOTE>
<BR>
That was the consensus reached at the face to face. As Russel pointed out, there could also be usability issues. We also need to plan the release timing to make sure it will get attention - if we put it out at a time when no one cares it won't generate any coverage or action.<BR>
<BR>
Cheers,<BR>
Bianca
<PRE>
_______________________________________________
linux-aus mailing list
<A HREF="mailto:linux-aus at lists.linux.org.au">linux-aus at lists.linux.org.au</A>
<A HREF="http://lists.linux.org.au/listinfo/linux-aus">http://lists.linux.org.au/listinfo/linux-aus</A>
</PRE>
</BODY>
</HTML>
--=-2oE1U7AxbbBwefBzPrN5--
More information about the linux-aus
mailing list