Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...
http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro...
What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?
C.
On 06/06/12 18:21, C wrote:
Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...
http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro...
What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?
F****** Microsoft again!
Is this "blog", or whatever, is now telling me that I have been booting my computer INSECURELY for the past 30 years?
The problem here is UEFI.
So, get rid of the parasite.
There was a reason for why I never used Intel in my computers - but I didn't really know why I never did. It was always a "gut feeling". Well I think I now know why I had this feeling-
/quote
The original EFI (Extensible Firmware Interface) specification was developed by Intel. Some of its practices and data formats mirror ones from Windows.
/unquote
Intel, Microsoft, Red Hat....
'Nuff said.
BC
On Wed, Jun 6, 2012 at 1:15 PM, Basil Chupin blchupin@iinet.net.au wrote:
Is this "blog", or whatever, is now telling me that I have been booting my computer INSECURELY for the past 30 years?
It's not Swapnil telling you... he's just the messenger. Don't shoot him, he's a member of the openSUSE community too :-)
The problem here is UEFI.
So, get rid of the parasite.
In a perfect world.. but the harsh reality is, it IS coming, and it will be a part of all hardware in the not so distant future. Supposedly not possible to disable on ARM devices, and can be disabled in the BIOS on all other devices.
We can bury our heads in the proverbial sand, and hope it goes away... or we can face the reality that it will be here regardless of what we think.
So, do we make the best of the situation? Or do we do nothing, and openSUSE simply won't work (unless you're technically savvy enough to register your own keys or know how to bypass UEFI) on new UEFI limited hardware where other distros will?
C.
On 06/06/12 21:23, C wrote:
On Wed, Jun 6, 2012 at 1:15 PM, Basil Chupin blchupin@iinet.net.au wrote:
Is this "blog", or whatever, is now telling me that I have been booting my computer INSECURELY for the past 30 years?
It's not Swapnil telling you... he's just the messenger. Don't shoot him, he's a member of the openSUSE community too :-)
The problem here is UEFI.
So, get rid of the parasite.
In a perfect world.. but the harsh reality is, it IS coming, and it will be a part of all hardware in the not so distant future. Supposedly not possible to disable on ARM devices, and can be disabled in the BIOS on all other devices.
We can bury our heads in the proverbial sand, and hope it goes away... or we can face the reality that it will be here regardless of what we think.
So, do we make the best of the situation? Or do we do nothing, and openSUSE simply won't work (unless you're technically savvy enough to register your own keys or know how to bypass UEFI) on new UEFI limited hardware where other distros will?
C.
I take it that it is something which is part of BIOS as we now know it. So, if a manufacturer decides not to provide this abomination in their chip(s) then it would not be a problem and people would then buy systems using these unadulterated chips?
There was this thing called DRM introduced a few years ago and for which a crack was released only hours after DRM was first used in a device.
Microsoft can go and fly a kite as the world is not that stupid about its intentions.
BC
On Wed, Jun 06, 2012 at 10:18:51PM +1000, Basil Chupin wrote:
On 06/06/12 21:23, C wrote:
On Wed, Jun 6, 2012 at 1:15 PM, Basil Chupin blchupin@iinet.net.au wrote:
Is this "blog", or whatever, is now telling me that I have been booting my computer INSECURELY for the past 30 years?
It's not Swapnil telling you... he's just the messenger. Don't shoot him, he's a member of the openSUSE community too :-)
The problem here is UEFI.
So, get rid of the parasite.
In a perfect world.. but the harsh reality is, it IS coming, and it will be a part of all hardware in the not so distant future. Supposedly not possible to disable on ARM devices, and can be disabled in the BIOS on all other devices.
We can bury our heads in the proverbial sand, and hope it goes away... or we can face the reality that it will be here regardless of what we think.
So, do we make the best of the situation? Or do we do nothing, and openSUSE simply won't work (unless you're technically savvy enough to register your own keys or know how to bypass UEFI) on new UEFI limited hardware where other distros will?
C.
I take it that it is something which is part of BIOS as we now know it. So, if a manufacturer decides not to provide this abomination in their chip(s) then it would not be a problem and people would then buy systems using these unadulterated chips?
There was this thing called DRM introduced a few years ago and for which a crack was released only hours after DRM was first used in a device.
Microsoft can go and fly a kite as the world is not that stupid about its intentions.
The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.
So we will probably have some support like this.
This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...
Ciao, Marcus
On Wed, 06 Jun 2012 14:25:29 +0200, Marcus Meissner wrote:
The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.
So we will probably have some support like this.
This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...
Not to mention people who build their own kernels or need customized kernels for hardware on their systems (such as I needed for my Dell laptop to support the touchpad properly).
Seems like the sort of thing OIN was created to help combat, wasn't it?
Jim
Jim Henderson wrote:
On Wed, 06 Jun 2012 14:25:29 +0200, Marcus Meissner wrote:
The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.
So we will probably have some support like this.
This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...
Not to mention people who build their own kernels or need customized kernels for hardware on their systems (such as I needed for my Dell laptop to support the touchpad properly).
Yes, very interesting point. There are plenty of such examples.
On Wed, Jun 6, 2012 at 6:53 PM, Per Jessen per@computer.org wrote:
On Wed, 06 Jun 2012 14:25:29 +0200, Marcus Meissner wrote:
The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.
So we will probably have some support like this.
This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...
Not to mention people who build their own kernels or need customized kernels for hardware on their systems (such as I needed for my Dell laptop to support the touchpad properly).
Yes, very interesting point. There are plenty of such examples.
Quoting from Swapnil's blog post....
"For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."
Other clarifications on this discussion...
"The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want"
So Microsoft is not getting the money like some people have grumbled rather loudly about here.
Please read this posting from Matthew Garret at RedHat.... http://mjg59.dreamwidth.org/12368.html which adds a lot more in depth information surrounding the issue.
C.
C wrote:
On Wed, Jun 6, 2012 at 6:53 PM, Per Jessen per@computer.org wrote:
On Wed, 06 Jun 2012 14:25:29 +0200, Marcus Meissner wrote:
The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.
So we will probably have some support like this.
This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...
Not to mention people who build their own kernels or need customized kernels for hardware on their systems (such as I needed for my Dell laptop to support the touchpad properly).
Yes, very interesting point. There are plenty of such examples.
Quoting from Swapnil's blog post....
"For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."
Ah, okay. Thanks.
On Wednesday, June 06, 2012 07:00:55 PM C wrote:
On Wed, Jun 6, 2012 at 6:53 PM, Per Jessen per@computer.org wrote:
On Wed, 06 Jun 2012 14:25:29 +0200, Marcus Meissner wrote:
The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.
So we will probably have some support like this.
This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...
Not to mention people who build their own kernels or need customized kernels for hardware on their systems (such as I needed for my Dell laptop to support the touchpad properly).
Yes, very interesting point. There are plenty of such examples.
Quoting from Swapnil's blog post....
"For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."
Other clarifications on this discussion...
"The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want"
So Microsoft is not getting the money like some people have grumbled rather loudly about here.
Please read this posting from Matthew Garret at RedHat.... http://mjg59.dreamwidth.org/12368.html which adds a lot more in depth information surrounding the issue.
C.
This is what Red Hat clarified about UEFI and the undesirable key
http://linux.slashdot.org/story/12/06/06/1232243/red-hat-clarifies-doubts- over-uefi-secure-boot-solution
Check the link comments below too.
Garret has been working on UEFI workarrounds several months with no satisfactory outcomes to implement an easy and low cost solution. Hence the decision to buy it the key and building an universal Linux bootloader able to boot any Linux. At least , it was one of the ideas with some drawbacks too.
It's an uneasy solution and sure it's not the best. At least, it's the one for this first lauching.
Regards,
I am not sure about the intricate details about UEFI but could the bootloader be signed and then that executes an unsigned kernel?
On Wed, Jun 06, 2012 at 09:23:40PM -0400, Andrew Joakimsen wrote:
I am not sure about the intricate details about UEFI but could the bootloader be signed and then that executes an unsigned kernel?
This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything.
It will get the certificate revoked quite fast (although I do not how they do it).
Ciao, Marcus
El jue, 07-06-2012 a las 11:32 +0200, Marcus Meissner escribió:
On Wed, Jun 06, 2012 at 09:23:40PM -0400, Andrew Joakimsen wrote:
I am not sure about the intricate details about UEFI but could the bootloader be signed and then that executes an unsigned kernel?
This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything.
It will get the certificate revoked quite fast (although I do not how they do it).
Ciao, Marcus
Marcus has described one of the issues by creating this workaround. Signing with an universal key and creating a bootloader able to boot any operating system disable the secureboot purposes. Secure Boot itself may not be a bad idea just not mature enough to be a Good neighbor for the software industry (there is plenty issues, keys capacity, who is going to manage the keys, how to disable it, etc...)
Just in the case UEFI has a way to disable SecureBoot (not in ARM):
One of the issues is how many keys is needed by year. If community software is released at least twice a year. Does it mean we need to sign twice? So it means 2 x $99= $100 per year (one key per release). Even worse one key per any customized software image. Just figuring it out. It is speculative.
Another approach is one key per distro. There is a lot distros and operating systems. The UEFI+SecureBoot is not able to handle many signed keys. So many distros will not run in the machine concomitantly (Virtualized is not impacted). It makes life very hard to Software Testers and Software Switchers. You would need to install one signed key per distro released to be able to boot it each time)
This is a very complex issue with multiple levels and channels affected. This is only the Iceberg tip.
Not sure if I want to buy any new computer with those UEFI+SecureBoot implementation looking for another protection layer or taking the risk and going the way we were until no more way is allowed. It's obvious the forces are rising up to reduce options.
Regards,
* Ricardo Chung ricardo.a.chung@gmail.com [06-07-12 10:34]: ...
Not sure if I want to buy any new computer with those UEFI+SecureBoot implementation looking for another protection layer or taking the risk and going the way we were until no more way is allowed. It's obvious the forces are rising up to reduce options.
And, unfortunately, the security/safety of the hardware system is not probably foremost in the presenter's eyes. It most probably can be *completely* explained as someone saw an opportunity to gain control of something that they could wield to realize financial advantage.
On 06/07/2012 09:54 AM, Patrick Shanahan wrote:
- Ricardo Chungricardo.a.chung@gmail.com [06-07-12 10:34]: ...
Not sure if I want to buy any new computer with those UEFI+SecureBoot implementation looking for another protection layer or taking the risk and going the way we were until no more way is allowed. It's obvious the forces are rising up to reduce options.
And, unfortunately, the security/safety of the hardware system is not probably foremost in the presenter's eyes. It most probably can be *completely* explained as someone saw an opportunity to gain control of something that they could wield to realize financial advantage.
Or it was chosen as a temporary way to harden a particular OS from Redmond that has a fundamentally flawed security model/implementation, *AND*, as an additional benefit, it causes a road block for those pesky Linux folks!
On Thursday, June 07, 2012 10:05:30 AM Larry Finger wrote:
On 06/07/2012 09:54 AM, Patrick Shanahan wrote:
- Ricardo Chungricardo.a.chung@gmail.com [06-07-12 10:34]: ...
Not sure if I want to buy any new computer with those UEFI+SecureBoot implementation looking for another protection layer or taking the risk and going the way we were until no more way is allowed. It's obvious the forces are rising up to reduce options.
And, unfortunately, the security/safety of the hardware system is not probably foremost in the presenter's eyes. It most probably can be *completely* explained as someone saw an opportunity to gain control of something that they could wield to realize financial advantage.
Or it was chosen as a temporary way to harden a particular OS from Redmond that has a fundamentally flawed security model/implementation, *AND*, as an additional benefit, it causes a road block for those pesky Linux folks!
"So, The boot process on EFI without secure boot is
EFI firmware | v grub(2) | v kernel
With secure boot, it will run something like this
Efi firmware (signed and validated by hardware). This holds the MS public keys, and verifies the signature of then next bootloader | v First stage bootloader, Signed by the MS keys. This contains the Distro Keys, and will check the signature of the next stage. | v Grub(2). This is signed by the Distro keys. It checks the signature of the kernel against the Distro keys. | v Kernel
If grub2 were loaded directly from firmware, every time grub2 was updated, it would need to be submitted to MS for signing. This would take time, and create hassles.
The reason that a first stage bootloader is needed, is that Grub 2 is updated somewhat frequently. By having a small, static first stage loader which contains the Distro keys, this means that it is less frequent that this will need replacing, and more over, does not need resigning by microsoft every time a grub2 update occurs. In theory, the only time the First stage loader would need replacing is when the MS keys expire, when the Distro keys expire, or when an update to this needs to occur. But of course, this would be small and simple, so updates would be infrequent, if ever." [1]
Quoted from http://www.linux-archive.org/community-support-fedora-users-users- lists-fedoraproject-org/673028-need-more-info-uefi-secure-boot-fedora.html just distro name switched to make it generic.
And this http://www.linux-archive.org/ubuntu-user/579319-uefi-secure- boot-4.html
This is the theoretical scenario taking place other mailing lists. We, the other operating system users, are involved anyway to prevent the beginning of facto technological apartheid.
No corporate excuses should be able to hijack any hardware architecture or platform to its own benefits.
I found this opinion article by Sam Varghese maybe not precise but bothersome revealer inviting to reflect about the what is happening now http://www.itwire.com/opinion-and-analysis/open-sauce/55198-red-hat-deal-wit... microsoft-is-a-bad-idea
We need to find a true solution with true resources to keep our community open and free to learn and sharing.
Please, this is not a flame war startup and don't even try it!
Regards,
What's the *simplest* solution to the *immediate* problem that will meet the deadline?
We need something in place that won't lock us out between 12.2 and the next release. We need something that provides a minimum of hassles in a world where nearly everybody uses something other than openSUSE already.
M. Edward (Ed) Borasky wrote:
What's the *simplest* solution to the *immediate* problem that will meet the deadline?
We need something in place that won't lock us out between 12.2 and the next release. We need something that provides a minimum of hassles in a world where nearly everybody uses something other than openSUSE already.
We've got more time than that - until 12.3, the main impact will be on newbies and Win8 dual-booters buying new Win8-compliant hardware. Does anyone have an ETA for Win8-compliant hardware on the shelves at Mediamarkt?
On Thu, Jun 7, 2012 at 5:32 AM, Marcus Meissner meissner@suse.de wrote:
On Wed, Jun 06, 2012 at 09:23:40PM -0400, Andrew Joakimsen wrote:
I am not sure about the intricate details about UEFI but could the bootloader be signed and then that executes an unsigned kernel?
This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything.
It will get the certificate revoked quite fast (although I do not how they do it).
So wouldn't the certificate be revoked if we put it in the OBS and SuSE Studio and let anyone sign their stuff?
Also how about malware authors, will their certificates be revoked?
On Thu, 07 Jun 2012 13:17:41 -0400, Andrew Joakimsen wrote:
This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything.
It will get the certificate revoked quite fast (although I do not how they do it).
So wouldn't the certificate be revoked if we put it in the OBS and SuSE Studio and let anyone sign their stuff?
If you're referring to the idea I suggested, I wasn't suggesting that a single certificate be used for all of OBS and Studio, but rather that there be a CA server with a trusted chain back to Verisign, and that upon request, Studio and OBS could issue a unique certificate with a valid chain of trust back to Verisign that could be revoked by OBS/Studio if it were abused in some way.
But that assumes that CRLs could be used by UEFI, and it's not clear to me that they could be - since it's implemented in hardware and updating the CRL would require Internet connectivity.
Jim
Jim Henderson wrote:
On Thu, 07 Jun 2012 13:17:41 -0400, Andrew Joakimsen wrote:
This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything.
It will get the certificate revoked quite fast (although I do not how they do it).
So wouldn't the certificate be revoked if we put it in the OBS and SuSE Studio and let anyone sign their stuff?
If you're referring to the idea I suggested, I wasn't suggesting that a single certificate be used for all of OBS and Studio, but rather that there be a CA server with a trusted chain back to Verisign, and that upon request, Studio and OBS could issue a unique certificate with a valid chain of trust back to Verisign that could be revoked by OBS/Studio if it were abused in some way.
But that assumes that CRLs could be used by UEFI, and it's not clear to me that they could be - since it's implemented in hardware and updating the CRL would require Internet connectivity.
It seems reasonable that CRLs could be retrieved and hardware/firmware updated with an appropriate utility running when the system is up, but OTOH, revoking a certificate in this context seems to be a potentially really dangerous move - disable hundreds-of-thousands of PCs in one fell swoop.
Wrt to $SUBJ, I see no problem in the fee itself - if that's what it takes to work on this new hardware without having to disable the secure-whatever. Let us not lose sight of that - as far as I understand, we're not looking to utilize whatever it is UEFI provides, we're only looking to help newbies and other converts overcome an initial hurdle that would otherwise make them go elsewhere.
On Fri, 08 Jun 2012 08:33:49 +0200, Per Jessen wrote:
It seems reasonable that CRLs could be retrieved and hardware/firmware updated with an appropriate utility running when the system is up, but OTOH, revoking a certificate in this context seems to be a potentially really dangerous move - disable hundreds-of-thousands of PCs in one fell swoop.
I don't know that we have individually compiled kernels out there that are used on hundreds of thousands of PCs. We'd be talking about (potentially) the users of an individual build service repo.
But certainly having a certificate revoked has the potential to render a system unbootable, if the CRL does get updated (and we should find out rather than hypothesize about how that works. Unfortuntely, the closest I get to UEFI on any of my systems is in VirtualBox, and I'm not sure how to enable secure boot yet).
Wrt to $SUBJ, I see no problem in the fee itself - if that's what it takes to work on this new hardware without having to disable the secure-whatever. Let us not lose sight of that - as far as I understand, we're not looking to utilize whatever it is UEFI provides, we're only looking to help newbies and other converts overcome an initial hurdle that would otherwise make them go elsewhere.
The fee is pennies per installed system (if that), and yeah, I think we should for the distribution just handle it. But beyond the distro, I think it's important to understand the ramifications to systems like OBS and Studio and deal with that as well. That's probably a bigger issue to deal with than the releases of openSUSE with 'official' kernels.
Jim
Jim Henderson wrote:
On Fri, 08 Jun 2012 08:33:49 +0200, Per Jessen wrote:
It seems reasonable that CRLs could be retrieved and hardware/firmware updated with an appropriate utility running when the system is up, but OTOH, revoking a certificate in this context seems to be a potentially really dangerous move - disable hundreds-of-thousands of PCs in one fell swoop.
I don't know that we have individually compiled kernels out there that are used on hundreds of thousands of PCs. We'd be talking about (potentially) the users of an individual build service repo.
Sorry, I must have missed the context.
But certainly having a certificate revoked has the potential to render a system unbootable, if the CRL does get updated (and we should find out rather than hypothesize about how that works.
A CRL is typically only valid for e.g. 30 days, some systems (MS Exchange for instance) will not work unless they have a valid CRL. I guess the UEFI spec has a section on the importance/use of CRLs.
Wrt to $SUBJ, I see no problem in the fee itself - if that's what it takes to work on this new hardware without having to disable the secure-whatever. Let us not lose sight of that - as far as I understand, we're not looking to utilize whatever it is UEFI provides, we're only looking to help newbies and other converts overcome an initial hurdle that would otherwise make them go elsewhere.
The fee is pennies per installed system (if that), and yeah, I think we should for the distribution just handle it. But beyond the distro, I think it's important to understand the ramifications to systems like OBS and Studio and deal with that as well. That's probably a bigger issue to deal with than the releases of openSUSE with 'official' kernels.
Perhaps users of those could just disable the UEFI secure functionality? I appreciate that dual-booting Windows8 would be an issue, but maybe it would be worth looking at the user or system "demographics" - to gauge the impact.
On Fri, 08 Jun 2012 10:45:38 +0200, Per Jessen wrote:
I don't know that we have individually compiled kernels out there that are used on hundreds of thousands of PCs. We'd be talking about (potentially) the users of an individual build service repo.
Sorry, I must have missed the context.
No problem. The CRL would apply not to the signing CA, but rather to the certificate used for signing (issued by the CA). So the scope would be small unless the official kernel signing key were invalidated accidentally (which would be disastrous). But it would be pretty inconvenient to recover from.
I'm also wondering, though, how this all fits into using live media as well. If secure boot is enabled in the BIOS, does that prevent DVD/USB booting? (Don't know the answer to that one, but clearly something to consider as well since many people try the LiveCD or build a LiveUSB from the LiveCD to try out openSUSE).
But certainly having a certificate revoked has the potential to render a system unbootable, if the CRL does get updated (and we should find out rather than hypothesize about how that works.
A CRL is typically only valid for e.g. 30 days, some systems (MS Exchange for instance) will not work unless they have a valid CRL. I guess the UEFI spec has a section on the importance/use of CRLs.
From what I recall, CRL lifetimes often are < 24 hours, requiring
frequent updates to be considered valid (makes sense, since you want a certificate that's invalidated to be considered invalid by clients as quickly as possible).
Looking at the 2.3.1 B specification, I don't see any defaults defined (the spec doc reads more like an API doc, though).
Perhaps users of those could just disable the UEFI secure functionality? I appreciate that dual-booting Windows8 would be an issue, but maybe it would be worth looking at the user or system "demographics" - to gauge the impact.
It probably would be worth looking at down the road, not sure how widely distributed UEFI is yet in the hardware available for purchase. I bought a new laptop back in December, and it's not UEFI-capable as far as I can tell.
There might not be enough of a user base to get a good sense of this yet.
Jim
On Fri, 08 Jun 2012 09:14:39 +0000, Jim Henderson wrote:
I'm also wondering, though, how this all fits into using live media as well. If secure boot is enabled in the BIOS, does that prevent DVD/USB booting? (Don't know the answer to that one, but clearly something to consider as well since many people try the LiveCD or build a LiveUSB from the LiveCD to try out openSUSE).
It seems that UEFI fully supports booting from external media even with secure boot enabled.
There's an article in the Intel Technology Journal (Vol 15 Issue 1, 2011) entitled "UEFI Networking and Pre-OS Security" that provides a very good overview of how the boot process (and secure boot in particular) works.
Jim
On Thu, Jun 07, 2012 at 05:26:54PM +0000, Jim Henderson wrote:
On Thu, 07 Jun 2012 13:17:41 -0400, Andrew Joakimsen wrote:
This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything.
It will get the certificate revoked quite fast (although I do not how they do it).
So wouldn't the certificate be revoked if we put it in the OBS and SuSE Studio and let anyone sign their stuff?
If you're referring to the idea I suggested, I wasn't suggesting that a single certificate be used for all of OBS and Studio, but rather that there be a CA server with a trusted chain back to Verisign, and that upon request, Studio and OBS could issue a unique certificate with a valid chain of trust back to Verisign that could be revoked by OBS/Studio if it were abused in some way.
But that assumes that CRLs could be used by UEFI, and it's not clear to me that they could be - since it's implemented in hardware and updating the CRL would require Internet connectivity.
As far as I know, uefi defined "dbx" variable to hold those blacklisted certications/hashes which serves similar purpose to CRL IMHO.
However in order to write new variables to dbx (read have no restrictions) that variable has to be signed with KEK_priv and firmware would use KEK_pub (certificate) to verify the signature. Only those variables that pass the authentication could be allowed to write. In UEFI specification such variables are classed as "authenticated variable" and is decribed in Variable Serivces in Chapter 7.2 of UEFI spec.
That means you couldn't update dbx unless firmware enrolled your key, which implies only microsoft could do that for now since it's the only OSV that has it's key in the firmware.
Regards, Michael
Jim
Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 06 of June 2012 22:18EN, Basil Chupin wrote:
I take it that it is something which is part of BIOS as we now know it. So, if a manufacturer decides not to provide this abomination in their chip(s) then it would not be a problem and people would then buy systems using these unadulterated chips?
If they do, they can't put the "Windows 8 compatible" (or whatever) logo on the box. I'm afraid not many will risk that.
It's the same with DVD/BD players: if a manufacturer allows its user (who is actually their customer and pays them for the product) to ignore those extremely annoying "skip of fast forward not allowed here" features, they don't get a certification and can't put a logo on their boxes. See for yourself how many manufacturers go this way...
Michal Kubeček
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06.06.2012 14:28, Michal Kubeček wrote:
On Wednesday 06 of June 2012 22:18EN, Basil Chupin wrote:
I take it that it is something which is part of BIOS as we now know it. So, if a manufacturer decides not to provide this abomination in their chip(s) then it would not be a problem and people would then buy systems using these unadulterated chips?
If they do, they can't put the "Windows 8 compatible" (or whatever) logo on the box. I'm afraid not many will risk that.
It's the same with DVD/BD players: if a manufacturer allows its user (who is actually their customer and pays them for the product) to ignore those extremely annoying "skip of fast forward not allowed here" features, they don't get a certification and can't put a logo on their boxes. See for yourself how many manufacturers go this way...
Windows Hardware Certification requirements, page 116 states
"all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys"
not sure how it will look in reality but I hope that one can simply disable this feature.
bye Chris
Michal Kubeček
On Wednesday 06 of June 2012 15:20EN, Christian Hueller wrote:
Windows Hardware Certification requirements, page 116 states
"all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys"
not sure how it will look in reality but I hope that one can simply disable this feature.
As I understand it, this means going into setup and disabling the feature (and perhaps confirm that you understand that it will expose your computer to all kinds of bad guys).
It is easy for me or for you. The question, however, is whether we want to require every potential user of OpenSuSE (with sufficiently new hardware) to do this - while Fedora won't.
Michal Kubeček
On Wed, Jun 6, 2012 at 3:41 PM, Michal Kubeček mkubecek@suse.cz wrote:
On Wednesday 06 of June 2012 15:20EN, Christian Hueller wrote:
Windows Hardware Certification requirements, page 116 states
"all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys"
not sure how it will look in reality but I hope that one can simply disable this feature.
As I understand it, this means going into setup and disabling the feature (and perhaps confirm that you understand that it will expose your computer to all kinds of bad guys).
It is easy for me or for you. The question, however, is whether we want to require every potential user of OpenSuSE (with sufficiently new hardware) to do this - while Fedora won't.
Additionally, this "feature" (currently) cannot be disabled on ARM based devices which will run Windows 8 (eg ARM tablets which will be perfectly capable of running Linux, but will be blocked by UEFI which cannot be disabled).
C.
Le mercredi 06 juin 2012 à 15:41 +0200, Michal Kubeček a écrit :
On Wednesday 06 of June 2012 15:20EN, Christian Hueller wrote:
Windows Hardware Certification requirements, page 116 states
"all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys"
not sure how it will look in reality but I hope that one can simply disable this feature.
As I understand it, this means going into setup and disabling the feature (and perhaps confirm that you understand that it will expose your computer to all kinds of bad guys).
It is easy for me or for you. The question, however, is whether we want to require every potential user of OpenSuSE (with sufficiently new hardware) to do this - while Fedora won't.
and people using dual boot with Windows 8 will need to enable it back in firmware each time they want to boot Windows 8..
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-06 16:01, Frederic Crozat wrote:
Le mercredi 06 juin 2012 à 15:41 +0200, Michal Kubeček a écrit :
On Wednesday 06 of June 2012 15:20EN, Christian Hueller wrote:
Windows Hardware Certification requirements, page 116 states
"all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys"
not sure how it will look in reality but I hope that one can simply disable this feature.
As I understand it, this means going into setup and disabling the feature (and perhaps confirm that you understand that it will expose your computer to all kinds of bad guys).
It is easy for me or for you. The question, however, is whether we want to require every potential user of OpenSuSE (with sufficiently new hardware) to do this - while Fedora won't.
and people using dual boot with Windows 8 will need to enable it back in firmware each time they want to boot Windows 8..
So we have to do it, or do it. No way round...
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Wed, 06 Jun 2012 16:35:01 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
and people using dual boot with Windows 8 will need to enable it back in firmware each time they want to boot Windows 8..
So we have to do it, or do it. No way round...
Hi Some interesting reading here.. http://www.rodsbooks.com/bios2uefi/ http://www.rodsbooks.com/gdisk/booting.html
Depends on the end user situation....
I'm not worried too much. The tech industry has a funny way of sorting itself out when it comes to stuff like. Just kick back, grab yourself another drink and wait and see what happens. :-)
Regards
Chris Jones
On Thu, Jun 07, 2012 at 06:48:14PM +1000, Chris Jones wrote:
I'm not worried too much. The tech industry has a funny way of sorting itself out when it comes to stuff like. Just kick back, grab yourself another drink and wait and see what happens. :-)
We are part of the sorting out team though ... ;)
Ciao, Marcus
Marcus Meissner wrote:
On Thu, Jun 07, 2012 at 06:48:14PM +1000, Chris Jones wrote:
I'm not worried too much. The tech industry has a funny way of sorting itself out when it comes to stuff like. Just kick back, grab yourself another drink and wait and see what happens. :-)
We are part of the sorting out team though ... ;)
Ciao, Marcus
True, but my comment was more of a generalization targeted towards users who have no say or control of the topic.
Cheers
Chris
Pony up the $99 would be my view also, although that worries me. Can be certain this will be a one time $99 fee and not an 'in for a penny, in for a pound' type rabbit hole ?
Lee
On 06/06/2012 10:21 AM, C wrote:
Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...
http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro...
What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?
C.
On Wed, 2012-06-06 at 16:31 +0200, oldcpu wrote:
Pony up the $99 would be my view also, although that worries me. Can be certain this will be a one time $99 fee and not an 'in for a penny, in for a pound' type rabbit hole ?
Lee
I'm not fully versed in this topic, but from what I've skimmed through out there, it seems that the $99 wouldn't be a one-time thing, or I'd say just pay it and let's get on with our lives.
If I'm reading correctly, kernel variations and even customized images created with SUSEStudio might be affected. Maybe I'm wrong, but if I'm reading it right, this is a $99 tax on anyone who wants to create custom images.
That said, if we can't get around it, I guess we have to figure out how to deal with it head on. That's what we should be discussing here on the Project ML. How to "react" to this from a political or social position. But if there's an actual technical solution, then it probably should be discussed on -Factory ML.
Bryen M Yunashko openSUSE Project
On 2012-06-06 11:04:14 (-0500), Bryen M Yunashko suserocks@bryen.com wrote:
On Wed, 2012-06-06 at 16:31 +0200, oldcpu wrote:
Pony up the $99 would be my view also, although that worries me. Can be certain this will be a one time $99 fee and not an 'in for a penny, in for a pound' type rabbit hole ?
out there, it seems that the $99 wouldn't be a one-time thing, or I'd say just pay it and let's get on with our lives.
If I'm reading correctly, kernel variations and even customized images created with SUSEStudio might be affected. Maybe I'm wrong, but if I'm reading it right, this is a $99 tax on anyone who wants to create custom images.
That said, if we can't get around it, I guess we have to figure out how to deal with it head on. That's what we should be discussing here on the Project ML. How to "react" to this from a political or social position. But if there's an actual technical solution, then it probably should be discussed on -Factory ML.
For as far as I've skimmed over the UEFI boot topic, the deal is to actually have one of the vendors who have their CA certificate in the PC vendors' trust store to sign images.
It seems to me to be essentially the same as when you want a TLS certificate for e.g. doing HTTPS: you send a request to a root CA (Certificate Authority) (such as Verisign, Thawte, ...), pay a fee, and they send you back your certificate, signed by them.
In the same way as e.g. Verisign's CA certificate (which is used to verify that _your_ certificate has been signed by their private key) is included in all the CA certificate bundles (by Mozilla for Firefox, by Google for Chrome, by Opera for Opera, for the operating system, ...), Microsoft's CA certificate (or its technical equivalent in UEFI) is included and, hence, trusted, by hardware vendors. I don't know whether there are other CAs that can be asked to sign our openSUSE release images though.
So, about "one time or not": it is one time for each openSUSE release image we want to be installable on hardware that uses UEFI.
For custom images, such as those created by SUSE Studio, it's toast, indeed.
Haven't checked the details about what is verified by the UEFI bootstrap though.
(For those who want details about how the signing and CA stuff works, read up on X.509, PKI and asymmetric cryptographic (such as RSA or ECC)).
cheers
On Wed, 06 Jun 2012 20:57:19 +0200, Pascal Bleser wrote:
It seems to me to be essentially the same as when you want a TLS certificate for e.g. doing HTTPS: you send a request to a root CA (Certificate Authority) (such as Verisign, Thawte, ...), pay a fee, and they send you back your certificate, signed by them.
In the same way as e.g. Verisign's CA certificate (which is used to verify that _your_ certificate has been signed by their private key) is included in all the CA certificate bundles (by Mozilla for Firefox, by Google for Chrome, by Opera for Opera, for the operating system, ...), Microsoft's CA certificate (or its technical equivalent in UEFI) is included and, hence, trusted, by hardware vendors. I don't know whether there are other CAs that can be asked to sign our openSUSE release images though.
So, about "one time or not": it is one time for each openSUSE release image we want to be installable on hardware that uses UEFI.
For custom images, such as those created by SUSE Studio, it's toast, indeed.
So what if SUSE/openSUSE were to get a signing key signed by Verisign, allowing OBS to issue signing certificates that had a valid chain of trust back to a CA that's on the 'approved' list?
Seems that if OBS could just sign kernel images with a valid certificate, that might solve the problem. It might introduce another issue, though - that of someone using OBS to build a 'malware' kernel that was signed by OBS.
Jim
On Wednesday 06 June 2012 19.06:00 Jim Henderson wrote:
On Wed, 06 Jun 2012 20:57:19 +0200, Pascal Bleser wrote:
It seems to me to be essentially the same as when you want a TLS certificate for e.g. doing HTTPS: you send a request to a root CA (Certificate Authority) (such as Verisign, Thawte, ...), pay a fee, and they send you back your certificate, signed by them.
In the same way as e.g. Verisign's CA certificate (which is used to verify that _your_ certificate has been signed by their private key) is included in all the CA certificate bundles (by Mozilla for Firefox, by Google for Chrome, by Opera for Opera, for the operating system, ...), Microsoft's CA certificate (or its technical equivalent in UEFI) is included and, hence, trusted, by hardware vendors. I don't know whether there are other CAs that can be asked to sign our openSUSE release images though.
So, about "one time or not": it is one time for each openSUSE release image we want to be installable on hardware that uses UEFI.
For custom images, such as those created by SUSE Studio, it's toast, indeed.
So what if SUSE/openSUSE were to get a signing key signed by Verisign, allowing OBS to issue signing certificates that had a valid chain of trust back to a CA that's on the 'approved' list?
Seems that if OBS could just sign kernel images with a valid certificate, that might solve the problem. It might introduce another issue, though - that of someone using OBS to build a 'malware' kernel that was signed by OBS.
Jim
Even better, help CACert to get a sub-ca key that work with uefi, and then use that free & open circle of trust.
On Wed, 06 Jun 2012 21:19:28 +0200, Bruno Friedmann wrote:
So what if SUSE/openSUSE were to get a signing key signed by Verisign, allowing OBS to issue signing certificates that had a valid chain of trust back to a CA that's on the 'approved' list?
Seems that if OBS could just sign kernel images with a valid certificate, that might solve the problem. It might introduce another issue, though
that of someone using OBS to build a 'malware' kernel that was signed by OBS.
Even better, help CACert to get a sub-ca key that work with uefi, and then use that free & open circle of trust.
There's an idea.
Since the certificates issued to sign OBS-project builds would be individual certs, if a malware build was released, the key could be revoked, problem solved (as long as UEFI supports certificate revocation)
Jim
Pay the fee and stop arguing. *Nobody* is going to use a distro if there's an extra hassle to do so.
Given that, I'd also expect that Microsoft would sell a virtualization solution for desktops. Why should they lose revenue to VMware Workstation and users to Oracle VM VirtualBox?
On Wed, Jun 6, 2012 at 1:21 AM, C smaug42@opensuse.org wrote:
Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...
http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro...
What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?
C.
openSUSE 12.1 x86_64, KDE 4.8.3
To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 07 Jun 2012 11:25:34 -0700, M. Edward (Ed) Borasky wrote:
Pay the fee and stop arguing. *Nobody* is going to use a distro if there's an extra hassle to do so.
There's more to it than just paying the fee. OBS and Studio are two obvious areas where just paying the fee won't solve the issue.
Given that, I'd also expect that Microsoft would sell a virtualization solution for desktops. Why should they lose revenue to VMware Workstation and users to Oracle VM VirtualBox?
They do. They purchased Connectix (I think that was the name of the company) years ago, and sell Virtual PC as well as their own Hyper-V virtualization solution.
Jim
This is to keep Linux out of the coming ARM server market not just the desktop/tablet market.
I say we figure out how to manage this requirement and just do it.
Steven ____________ Apply appropriate technology. Use what works without prejudice. Steven L Hess ARS KC6KGE DM05gd22 Google Voice 661 769 6201 +SMS openSUSE Linux 12.1 KDE 4.7.2 Known as FlameBait and The Sock Puppet of Doom.
Again this speculation needs to end. How exactly does this certificate arragement work. Will Verisign even sign an intermediate certificate to openSUSE or any other developer for that matter?
What Jim points out is very valid. Let's say each kernel/complete packaged os release requires a unique certificate. Let's put money and whatever aside. If I want to go on the hypothetical future OBS to build an OS, I go through verisign and get the certificate, let's say that takes 24 hours, once I get that certificate would it be valid to boot on the ARM PC? Or does then the certificate holder have to go through a process to get their certificate included with the hardware vendor's product?
there's an extra hassle to do so.
Given that, I'd also expect that Microsoft would sell a virtualization solution for desktops. Why should they lose revenue to VMware Workstation and users to Oracle VM VirtualBox?
On Wed, Jun 6, 2012 at 1:21 AM, C smaug42@opensuse.org wrote:
Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...
http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro...
What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?
C.
openSUSE 12.1 x86_64, KDE 4.8.3
To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver
Data is the new coal - abundant, dirty and difficult to mine.
To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 07 Jun 2012 16:21:41 -0400, Andrew Joakimsen wrote:
Let's say each kernel/complete packaged os release requires a unique certificate.
I don't expect it'd be a unique certificate per release - the certificate is used for generating a digital signature (checksum + chain of trust), so as long as the certificate is within it's certificate validity interval (I've seen some issued for as few as 2 years and as much as 10 years, though certainly other intervals can be valid as well).
The purpose of the signature is to prove that the compiled kernel was built by a trusted source and is unmodified.
So being my own "devil's advocate", if we did issue certs (assuming an intermediate signing CA could be approved), what steps would we need to put in place to ensure that those using OBS or Studio were trustworthy?
Come to think of it, though, a separate signature probably wouldn't be necessary for Studio as long as a validly signed kernel were used in the build. If a custom kernel were used (from an unofficial repo without a signed key), then that's where the additional kernel would be signed.
But the more I think about it, the more I wonder if the official kernels are signed so UEFI could work, whether it would be necessary to have Studio builds have any additional signing done.
Jim
This goes back to my last message: how do we determine the specifics instead of speculating?
On Thu, 07 Jun 2012 16:50:15 -0400, Andrew Joakimsen wrote:
This goes back to my last message: how do we determine the specifics instead of speculating?
If EFI and UEFI are the same (and it appears they are; EFI was a specification developed by Intel, and UEFI is managed by the UEFI forum as UEFI.
So assuming the EFI and UEFI specs are the same, it seems we could answer some of the questions experimentally using VirtualBox, which has EFI support in it.
I agree that we need to move beyond speculation and into the realm of determining what practical steps need to be taken.
Jim
On Thu, Jun 07, 2012 at 04:21:41PM -0400, Andrew Joakimsen wrote:
Again this speculation needs to end. How exactly does this certificate arragement work. Will Verisign even sign an intermediate certificate to openSUSE or any other developer for that matter?
This is the original blog post from one of the Fedora hackers, which might contain a workable solution: http://mjg59.dreamwidth.org/12368.html
I cannot answer the rest.
Ciao, Marfcus
On Wednesday 06 Jun 2012 10:21:19 C wrote:
Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...
http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro soft
What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?
I don't believe that the CA authority in question that would need to sign any of our bootloaders is trustworthy at all. I think it will prove to be a mistake to "trust" these technically weak corporations.
Additionaly, I reject the premise that this new form of restrictions is related to security. UEFI code will be permanently running on any machine that implements it and of course it will be running at level that even your OS will be have to obey. And of course it's all proprietary.
If I'm mistaken, please correct me.
Cheers the noo, Graham
Graham Anderson wrote:
On Wednesday 06 Jun 2012 10:21:19 C wrote:
Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...
http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro
soft
What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?
I don't believe that the CA authority in question that would need to sign any of our bootloaders is trustworthy at all. I think it will prove to be a mistake to "trust" these technically weak corporations.
Additionaly, I reject the premise that this new form of restrictions is related to security. UEFI code will be permanently running on any machine that implements it and of course it will be running at level that even your OS will be have to obey. And of course it's all proprietary.
If I'm mistaken, please correct me.
No need to, you're spot on.
On Fri, 08 Jun 2012 22:29:22 +0200, Graham Anderson wrote:
Additionaly, I reject the premise that this new form of restrictions is related to security. UEFI code will be permanently running on any machine that implements it and of course it will be running at level that even your OS will be have to obey. And of course it's all proprietary.
Well, I think whether it's about security or not is debatable (but not actually relevant in the end - because it's coming and that's how it's being /sold/ to the mass market). If secure boot is enabled for Windows8 and the user keeps Win8 on the machine, then it has to be dealt with by any additional OSes on the system if the Win8 install is going to be booted into with any sort of regularity.
If openSUSE is the only OS on the box, then the specifications (and what's been publicly stated) state that for x86 platforms, UEFI secure boot can be disabled by the user. At least that's my understanding of the situation.
I think the most useful thing we could do at this stage is see how it's actually implemented on a real (or virtual) system. At least for me, if I can see what it actually does and how it behaves, that gives me a better feel for what there is to actually deal with.
Jim
On Friday 08 Jun 2012 20:43:10 Jim Henderson wrote:
On Fri, 08 Jun 2012 22:29:22 +0200, Graham Anderson wrote:
Additionaly, I reject the premise that this new form of restrictions is related to security. UEFI code will be permanently running on any machine that implements it and of course it will be running at level that even your OS will be have to obey. And of course it's all proprietary.
Well, I think whether it's about security or not is debatable (but not actually relevant in the end - because it's coming and that's how it's being /sold/ to the mass market).
The original paladium (TPM) chips were seen as inevitable, and while they have made their way onto many boards that corporations and governments buy (because of the obvious implications of lockdown) these chips have not seen much penetration outside the paranoia of large industry. That in itself is quite amusing because the alleged security that TPM provided, has never come to pass. The penetration of corporate and government networks that specifcy having a TPM chip should raise flags to just about anyone except maybe those that frequent the South China Sea near Taiwan.
A few years on and now we have son of paladium, and that's TPM+UEFI. The hope is that there can be control or monitoring or shutdown of "unauthorised software". It's frankly a pipe dream. And on matters of trust we just have to look to the recent CA's that issue generic certs for cash. And that's just the cheap wankers, flame authors are desperately and efficiently covering their tracks even with government backing.
So i ask you again. Do you really want your bootloader and kernel to only be "authorised" by the likely candidates that will crack your system for political or monitary gain?
Cheers the noo, G
On Friday, June 08, 2012 11:18:18 PM Graham Anderson wrote:
On Friday 08 Jun 2012 20:43:10 Jim Henderson wrote:
On Fri, 08 Jun 2012 22:29:22 +0200, Graham Anderson wrote:
Additionaly, I reject the premise that this new form of restrictions is related to security. UEFI code will be permanently running on any machine that implements it and of course it will be running at level that even your OS will be have to obey. And of course it's all proprietary.
Well, I think whether it's about security or not is debatable (but not actually relevant in the end - because it's coming and that's how it's being /sold/ to the mass market).
The original paladium (TPM) chips were seen as inevitable, and while they have made their way onto many boards that corporations and governments buy (because of the obvious implications of lockdown) these chips have not seen much penetration outside the paranoia of large industry. That in itself is quite amusing because the alleged security that TPM provided, has never come to pass. The penetration of corporate and government networks that specifcy having a TPM chip should raise flags to just about anyone except maybe those that frequent the South China Sea near Taiwan.
A few years on and now we have son of paladium, and that's TPM+UEFI. The hope is that there can be control or monitoring or shutdown of "unauthorised software". It's frankly a pipe dream. And on matters of trust we just have to look to the recent CA's that issue generic certs for cash. And that's just the cheap wankers, flame authors are desperately and efficiently covering their tracks even with government backing.
So i ask you again. Do you really want your bootloader and kernel to only be "authorised" by the likely candidates that will crack your system for political or monitary gain?
Cheers the noo, G
I love your arguments in disfavor using UEFI+SecureBoot or even not so useful TPM
I just want ro remind you we can not contlol vendors implementation. They are going to launch 2 options (if they really make it):
1) ARM with Windows8 Certification Logo + UEFI + SecureBoot: On these devices SecureBoot is not going to be possible to disable it "easily".
2) x86 xxx with Windows 8 could include some way to disable SecureBoot.: On these devices an option on UEFI settings might be implemented by hardware vendors.
Both options will come to the scenario this year.
We (community) could watch what is coming up next months or taking actions to not missing pieces on this map (users market).
Options:
1) Buying a Key (something complex to the whole OBS, releases, appliances, customized operating system, etc.). We need to know How To for the whole options we offer. Maybe changing the whole way we work (package approval process to be signed) Yes, I know is crazy and an huge work. 2) Building something able to boot despite Secure Boot (Dream at no cost or highest cost) 3) Complaining before international courts (anti- trust). I don't think there are much partners involved to start it) 4) Keeping us off these limits.
I have no read any worries from SUSE Enterprise, or any other associated. And I don't know if they are working on any directions to solve these issues as no oficial communications has been made. Maybe the ARM team on factory have been working on, I could not say it.
Any other ideas?
Regards,
On Fri, 08 Jun 2012 23:18:18 +0200, Graham Anderson wrote:
So i ask you again. Do you really want your bootloader and kernel to only be "authorised" by the likely candidates that will crack your system for political or monitary gain?
Certainly I don't /want/ that, but at this stage of the game, it seems the stage is set for that to happen. So rather than push for what I want, it seems reasonable to deal with the hand that's been dealt.
That doesn't mean giving up on what I want - but there is a practical reality to consider, which is if we don't adjust to cope with this new thing, this new thing will keep us from running on people's hardware, and openSUSE will cease being a choice for them.
This is a case where perhaps taking a page from Microsoft's "Embrace, Extend, Extinguish" strategy might be helpful.
Jim
On Fri, Jun 8, 2012 at 5:14 PM, Jim Henderson hendersj@gmail.com wrote:
On Fri, 08 Jun 2012 23:18:18 +0200, Graham Anderson wrote:
So i ask you again. Do you really want your bootloader and kernel to only be "authorised" by the likely candidates that will crack your system for political or monitary gain?
Certainly I don't /want/ that, but at this stage of the game, it seems the stage is set for that to happen. So rather than push for what I want, it seems reasonable to deal with the hand that's been dealt.
That doesn't mean giving up on what I want - but there is a practical reality to consider, which is if we don't adjust to cope with this new thing, this new thing will keep us from running on people's hardware, and openSUSE will cease being a choice for them.
This is a case where perhaps taking a page from Microsoft's "Embrace, Extend, Extinguish" strategy might be helpful.
Jim
I don't think openSUSE is in a position to "strategize" or even "lead" in this matter. I'm not sure openSUSE is in a position to lead anywhere except with SUSE Studio and Open Build Service. You're right - we either come up with a fix by a certain date or there are people who will *never* run openSUSE.
Just out of curiosity, is there an OpenFATE or Bugzilla entry for this? Seems to me it's not a "bug" but a new feature request. Issues have owners, and I don't see anyone stepping up to own this yet.
Well, I think whether it's about security or not is debatable (but not actually relevant in the end - because it's coming and that's how it's being /sold/ to the mass market). If secure boot is enabled for Windows8 and the user keeps Win8 on the machine, then it has to be dealt with by any additional OSes on the system if the Win8 install is going to be booted into with any sort of regularity.
I'm not convinced it's coming, apart from in marketing materials. The general public have shown remarkably little appetite for the relentless upgrading from one version of your-OS-of-choice to the next, especially with no perceived benefit. "Security" isn't a major concern for most people using computers & the internet, so it will take major scaremongering or some variety of blackmail to convince people that they should move.
Win7 has only just (or will soon, depending upon who you believe) made it to 50% share, 3 years after release.
We should exclude the major corporate from our consideration as they don't do openSUSE. Unfortunately, I can't find stats excluding these guys.
David
On Sat, Jun 9, 2012 at 4:06 AM, Administrator admin@different-perspectives.com wrote:
Well, I think whether it's about security or not is debatable (but not actually relevant in the end - because it's coming and that's how it's being /sold/ to the mass market). If secure boot is enabled for Windows8 and the user keeps Win8 on the machine, then it has to be dealt with by any additional OSes on the system if the Win8 install is going to be booted into with any sort of regularity.
I'm not convinced it's coming, apart from in marketing materials. The general public have shown remarkably little appetite for the relentless upgrading from one version of your-OS-of-choice to the next, especially with no perceived benefit. "Security" isn't a major concern for most people using computers & the internet, so it will take major scaremongering or some variety of blackmail to convince people that they should move.
Win7 has only just (or will soon, depending upon who you believe) made it to 50% share, 3 years after release.
We should exclude the major corporate from our consideration as they don't do openSUSE. Unfortunately, I can't find stats excluding these guys.
David
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
1. Yes, the "post-PC" mass market is in a rapid state of flux, mostly because you can *almost* be as productive as a mobile knowledge worker with a cloud-backed iPad as you can with a 5+ pound $1200US laptop, and the iPad provides a *much* better platform for consuming media.
2. Security on Windows is a major hassle. That's probably the only thing Google's ChromeBooks have going for them - their security model is hassle-free. UEFI is Microsoft's best shot at a hassle-free security model. They're going to push it hard with all the cash and hype they can muster. Linux desktops *are* going to be wounded in the process, and Linux distros that delay dealing effectively with the UEFI issue will simply cease to exist as a force on the desktop/laptop.
3. Only time will tell whether Windows 8 tablets can create new customers and take customers away from iPads. If Microsoft can find insecurities in iOS that aren't in Windows 8 tablets and the Windows 8 tablets are less expensive and more secure, you'd better believe that's going to matter to consumers.
On Sat, Jun 9, 2012 at 7:44 PM, M. Edward (Ed) Borasky znmeb@znmeb.net wrote:
- Security on Windows is a major hassle. That's probably the only
thing Google's ChromeBooks have going for them - their security model is hassle-free. UEFI is Microsoft's best shot at a hassle-free security model. They're going to push it hard with all the cash and hype they can muster. Linux desktops *are* going to be wounded in the process, and Linux distros that delay dealing effectively with the UEFI issue will simply cease to exist as a force on the desktop/laptop.
A little more on this topic....
http://www.zdnet.com/blog/open-source/linus-torvalds-on-windows-8-uefi-and-f...
C.
On Sun, Jun 10, 2012 at 10:36 PM, C smaug42@opensuse.org wrote:
On Sat, Jun 9, 2012 at 7:44 PM, M. Edward (Ed) Borasky znmeb@znmeb.net wrote:
- Security on Windows is a major hassle. That's probably the only
thing Google's ChromeBooks have going for them - their security model is hassle-free. UEFI is Microsoft's best shot at a hassle-free security model. They're going to push it hard with all the cash and hype they can muster. Linux desktops *are* going to be wounded in the process, and Linux distros that delay dealing effectively with the UEFI issue will simply cease to exist as a force on the desktop/laptop.
A little more on this topic....
http://www.zdnet.com/blog/open-source/linus-torvalds-on-windows-8-uefi-and-f...
C.
openSUSE 12.1 x86_64, KDE 4.8.2
To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Thanks!!
1. Who owns this issue? 2. What steps need to happen before it is closed? 3. When can we expect closure?
The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution. As it stands now, I have little choice but to migrate from openSUSE to Fedora over the next few months because it's not certain a large class of users will be able to use my software collections on bare metal should they desire to do so. At least with Fedora, that possibilty is open.
M. Edward (Ed) Borasky wrote:
- Who owns this issue?
- What steps need to happen before it is closed?
- When can we expect closure?
The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution.
Unfortunately, we don't really have anyone behind anything, we (the community) have to work out a solution for ourselves.
On Tue, 12 Jun 2012 08:33:56 +0200, Per Jessen wrote:
M. Edward (Ed) Borasky wrote:
- Who owns this issue?
- What steps need to happen before it is closed?
- When can we expect closure?
The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution.
Unfortunately, we don't really have anyone behind anything, we (the community) have to work out a solution for ourselves.
One question that comes to mind (don't know why it didn't before) - is there something that openSUSE might leverage in the agreement between SUSE and Microsoft?
Seems like exactly the sort of thing the technical agreement might be leveraged to address.
Jim
On Tue, 12 Jun 2012 17:05:50 +0000 (UTC) Jim Henderson hendersj@gmail.com wrote:
On Tue, 12 Jun 2012 08:33:56 +0200, Per Jessen wrote:
M. Edward (Ed) Borasky wrote:
- Who owns this issue?
- What steps need to happen before it is closed?
- When can we expect closure?
The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution.
Unfortunately, we don't really have anyone behind anything, we (the community) have to work out a solution for ourselves.
One question that comes to mind (don't know why it didn't before) - is there something that openSUSE might leverage in the agreement between SUSE and Microsoft?
Seems like exactly the sort of thing the technical agreement might be leveraged to address.
Jim
AFAIK openSUSE needs to take the lead as they are upstream ;)
Might be time to start a thread in the Factory ML to consider the technical aspects?
Maybe a forum poll to see how many have UEFI bootable systems or plan on buying hardware to run the other OS....
Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....
On Tue, Jun 12, 2012 at 10:51 AM, Malcolm malcolm_lewis@bellsouth.net wrote:
On Tue, 12 Jun 2012 17:05:50 +0000 (UTC) Jim Henderson hendersj@gmail.com wrote:
On Tue, 12 Jun 2012 08:33:56 +0200, Per Jessen wrote:
M. Edward (Ed) Borasky wrote:
- Who owns this issue?
- What steps need to happen before it is closed?
- When can we expect closure?
The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution.
Unfortunately, we don't really have anyone behind anything, we (the community) have to work out a solution for ourselves.
One question that comes to mind (don't know why it didn't before) - is there something that openSUSE might leverage in the agreement between SUSE and Microsoft?
Seems like exactly the sort of thing the technical agreement might be leveraged to address.
Jim
AFAIK openSUSE needs to take the lead as they are upstream ;)
Might be time to start a thread in the Factory ML to consider the technical aspects?
Maybe a forum poll to see how many have UEFI bootable systems or plan on buying hardware to run the other OS....
Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....
-- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default up 22:05, 3 users, load average: 0.61, 0.42, 0.38 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I'd have to go read through the Fedora postings again, but as I understand it, the Fedora community and the Red Hat corporation *collaborated* to forge a solution *and* defend it in the press against the inevitable howls of people who don't understand the pragmatics of either running a business or developing open source software. ;-) I think that's what needs to happen here - the openSUSE community and Attachmate / SUSE corporate need to collaborate on a solution. I'm way down here on the food chain and I have to trust those with the experience and authority to come up with something that will work for me.
The fact of the matter from my position is that if my laptop dies and I'm forced to buy a new Windows 8 laptop, at the moment I will be unable to install openSUSE on it. It's about a year old and I typically only get two years out of them because I buy low-end ones. So Linux probably has a year to get their act together for *me*, but for the world at large, I think Linux needs to be UEFI-ready as soon as Windows 8 hardware starts shipping in volume.
On Tuesday, June 12, 2012 11:37:14 AM M. Edward Borasky wrote:
On Tue, Jun 12, 2012 at 10:51 AM, Malcolm malcolm_lewis@bellsouth.net
wrote:
On Tue, 12 Jun 2012 17:05:50 +0000 (UTC)
Jim Henderson hendersj@gmail.com wrote:
On Tue, 12 Jun 2012 08:33:56 +0200, Per Jessen wrote:
M. Edward (Ed) Borasky wrote:
- Who owns this issue?
- What steps need to happen before it is closed?
- When can we expect closure?
The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution.
Unfortunately, we don't really have anyone behind anything, we (the community) have to work out a solution for ourselves.
One question that comes to mind (don't know why it didn't before) - is there something that openSUSE might leverage in the agreement between SUSE and Microsoft?
Seems like exactly the sort of thing the technical agreement might be leveraged to address.
Jim
AFAIK openSUSE needs to take the lead as they are upstream ;)
Might be time to start a thread in the Factory ML to consider the technical aspects?
Maybe a forum poll to see how many have UEFI bootable systems or plan on buying hardware to run the other OS....
Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....
You should be able to enable/disable the SecureBoot option on UEFI with no further issues.
-- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default up 22:05, 3 users, load average: 0.61, 0.42, 0.38 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I'd have to go read through the Fedora postings again, but as I understand it, the Fedora community and the Red Hat corporation *collaborated* to forge a solution *and* defend it in the press against the inevitable howls of people who don't understand the pragmatics of either running a business or developing open source software. ;-) I think that's what needs to happen here - the openSUSE community and Attachmate / SUSE corporate need to collaborate on a solution. I'm way down here on the food chain and I have to trust those with the experience and authority to come up with something that will work for me.
The fact of the matter from my position is that if my laptop dies and I'm forced to buy a new Windows 8 laptop, at the moment I will be unable to install openSUSE on it. It's about a year old and I typically only get two years out of them because I buy low-end ones. So Linux probably has a year to get their act together for *me*, but for the world at large, I think Linux needs to be UEFI-ready as soon as Windows 8 hardware starts shipping in volume.
The core issue is not on Windows 8 laptops. It's the specification ARM Architecture+Window 8 Certification Logo+UEFI+SecureBoot. This special scenario will come with a SecureBoot not able to deactivate on UEFI or any other ways.
Other architectures like x86 may be coming with the option to deactivate SecureBoot on UEFI.
Any concerns related to boot other operating systems than Windows 8 with Certification Logo must be addressed to get a key registered with Microsoft Keys Manager. At this right moment, it seems no other options cost-effective feasible and available.
Regards,
On Tue, Jun 12, 2012 at 9:17 PM, Ricardo Chung amon0.thoth1@gmail.com wrote:
You should be able to enable/disable the SecureBoot option on UEFI with no further issues.
That assumes that: 1. The manufacturer puts that option into the UEFI setup (it's not mandatory, from what I read, that they allow you to disable it... they can allow it.. or not...it's only on Arm that they currently cannot allow it to be disabled if they want the Win8 Certified logo.. which they all want) 2. The end user is aware of this requirement to disable UEFI 3. The end user is capable of disabling UEFI
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The core issue is not on Windows 8 laptops. It's the specification ARM Architecture+Window 8 Certification Logo+UEFI+SecureBoot. This special scenario will come with a SecureBoot not able to deactivate on UEFI or any other ways.
Other architectures like x86 may be coming with the option to deactivate SecureBoot on UEFI.
Operative word there being "may".
Any concerns related to boot other operating systems than Windows 8 with Certification Logo must be addressed to get a key registered with Microsoft Keys Manager. At this right moment, it seems no other options cost-effective feasible and available.
I agree 100% here. We should stop waffling... buy the darned key and let's get on with implementing it into the standard openSUSE releases. We can be ready on time for the releases - which are happening later this year... or we can play catchup.... again.
If we don't have enough money in the marketing budget or wherever, then ask on the project list.. I'm sure that one or several of us could cough up the $99 US to cover it for the project.
C.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-12 21:36, C wrote:
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The problem is that if that person wants to later boot the Windows 8 they bought, they can't until they re-enable uefi secure booting.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. robin.listas@telefonica.net wrote:
On 2012-06-12 21:36, C wrote:
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The problem is that if that person wants to later boot the Windows 8 they bought, they can't until they re-enable uefi secure booting.
So... even more reason we need to step up and support this UEFI thing.
We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)
C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-12 21:48, C wrote:
On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. <> wrote:
We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)
That's clear to me and many, I guess. What is not clear is the mechanics of it. Like what is certified, grub, or the kernel. Have you got to pay again for each version. etc.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Tuesday, June 12, 2012 10:09:12 PM Carlos E. R. wrote:
On 2012-06-12 21:48, C wrote:
On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. <> wrote:
We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)
That's clear to me and many, I guess. What is not clear is the mechanics of it. Like what is certified, grub, or the kernel. Have you got to pay again for each version. etc.
We (openSUSE or SUSE) would need to buy a Key from Verisign (for a period, most probabe it's an annual fee) and go to register to Microsoft Keys Management.
My concerns on this particular (key registration) is how many keys could UEFI handling simultaneously. I mean Windows 8 is coming by default, we add another key for openSUSE, SUSE. What about you need another operating system or full customized system with some personal tweaks and modifications. Even more, what about Open Build Services customized appliances?
Regards,
On 13/06/12 05:48, C wrote:
On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. robin.listas@telefonica.net wrote:
On 2012-06-12 21:36, C wrote:
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The problem is that if that person wants to later boot the Windows 8 they bought, they can't until they re-enable uefi secure booting.
So... even more reason we need to step up and support this UEFI thing.
We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)
C
My question is:
What does the EU think about all of this?
Does the EU see this as yet another attempt by Microsoft to monopolise the market?
BC
Basil Chupin wrote:
On 13/06/12 05:48, C wrote:
On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. robin.listas@telefonica.net wrote:
On 2012-06-12 21:36, C wrote:
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The problem is that if that person wants to later boot the Windows 8 they bought, they can't until they re-enable uefi secure booting.
So... even more reason we need to step up and support this UEFI thing.
We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)
C
My question is:
What does the EU think about all of this?
Does the EU see this as yet another attempt by Microsoft to monopolise the market?
Except for a few discussions/blogs, I have been unable to find much/anything on that topic (EU & Secureboot), but at a glance it does seem like something the EU ought to take a closer look at. Especially the key management and the potential exclusion of non-MS or non-corporate software.
On 13/06/12 16:13, Per Jessen wrote:
Basil Chupin wrote:
On 13/06/12 05:48, C wrote:
On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. robin.listas@telefonica.net wrote:
On 2012-06-12 21:36, C wrote:
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The problem is that if that person wants to later boot the Windows 8 they bought, they can't until they re-enable uefi secure booting.
So... even more reason we need to step up and support this UEFI thing.
We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)
C
My question is:
What does the EU think about all of this?
Does the EU see this as yet another attempt by Microsoft to monopolise the market?
Except for a few discussions/blogs, I have been unable to find much/anything on that topic (EU & Secureboot), but at a glance it does seem like something the EU ought to take a closer look at. Especially the key management and the potential exclusion of non-MS or non-corporate software.
Thanks, Per.
So, as I suspected, the whole thing may have even caught the EU twiddling its thumbs.....
And I wonder what its reaction will be when it finally gets to really know about this UEFI-thingie.
But then, the EU is about to implode anyway so who really cares, eh? :-(
However, there is still the rest of the world, especially the Eastern part of the world.
BC
On Wednesday, June 13, 2012 03:02:10 PM Basil Chupin wrote:
On 13/06/12 05:48, C wrote:
On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R.
robin.listas@telefonica.net wrote:
On 2012-06-12 21:36, C wrote:
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The problem is that if that person wants to later boot the Windows 8 they bought, they can't until they re-enable uefi secure booting.
So... even more reason we need to step up and support this UEFI thing.
We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)
C
My question is:
What does the EU think about all of this?
Does the EU see this as yet another attempt by Microsoft to monopolise the market?
BC
I have been following the UEFI+SecureBoot stuff several months ago. And certainly I have not heard anything from EU or any International rulers. Mostly the whole interaction is coming from Hardware Vendors, Software Developers and Press.
Regards,
On 14/06/12 00:35, Ricardo Chung wrote:
On Wednesday, June 13, 2012 03:02:10 PM Basil Chupin wrote:
On 13/06/12 05:48, C wrote:
On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R.
robin.listas@telefonica.net wrote:
On 2012-06-12 21:36, C wrote:
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The problem is that if that person wants to later boot the Windows 8 they bought, they can't until they re-enable uefi secure booting.
So... even more reason we need to step up and support this UEFI thing.
We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)
C
My question is:
What does the EU think about all of this?
Does the EU see this as yet another attempt by Microsoft to monopolise the market?
BC
I have been following the UEFI+SecureBoot stuff several months ago. And certainly I have not heard anything from EU or any International rulers. Mostly the whole interaction is coming from Hardware Vendors, Software Developers and Press.
Regards,
Thanks for the response.
So in the end it may just be some FUD?
Quite apart from the EU et al, what has the FOSS come up with re this issue?
BC
On Tuesday, June 12, 2012 09:36:09 PM C wrote:
On Tue, Jun 12, 2012 at 9:17 PM, Ricardo Chung amon0.thoth1@gmail.com
wrote:
You should be able to enable/disable the SecureBoot option on UEFI with no further issues.
That assumes that:
- The manufacturer puts that option into the UEFI setup (it's not
mandatory, from what I read, that they allow you to disable it... they can allow it.. or not...it's only on Arm that they currently cannot allow it to be disabled if they want the Win8 Certified logo.. which they all want)
Completely true.
- The end user is aware of this requirement to disable UEFI
Just a small correcitons. It's to disable the SecureBoot on UEFI. UEFI is the new BIOS equivalent capable to handle the devices connected and the way it communicate each other with the operating system.
- The end user is capable of disabling UEFI
Again, you should switch UEFI to SecureBoot.
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
As far as it's tested, LiveCD are not impacted. Said so, you could be able to boot a LiveCD to play it Live Only. Not installing it. Though is possible it will change next months.
You are right. New users and not experienced enough will stop themselves to go beyond if they receive too many scary messages or not messages at all during boot process.
The core issue is not on Windows 8 laptops. It's the specification ARM Architecture+Window 8 Certification Logo+UEFI+SecureBoot. This special scenario will come with a SecureBoot not able to deactivate on UEFI or any other ways.
Other architectures like x86 may be coming with the option to deactivate SecureBoot on UEFI.
Operative word there being "may".
Right. Vendors "may". There is no obligation from Anti-trust Courts or anyone.
Any concerns related to boot other operating systems than Windows 8 with Certification Logo must be addressed to get a key registered with Microsoft Keys Manager. At this right moment, it seems no other options cost-effective feasible and available.
I agree 100% here. We should stop waffling... buy the darned key and let's get on with implementing it into the standard openSUSE releases. We can be ready on time for the releases - which are happening later this year... or we can play catchup.... again.
If we don't have enough money in the marketing budget or wherever, then ask on the project list.. I'm sure that one or several of us could cough up the $99 US to cover it for the project.
Completely agreed. If we don't have a better wildcard to play that's the way it should go and problably making a public statement from SUSE because at the end it is a commercial issue impacted.
Note: Anyway the user needs some minimal technical knowledge to able and/or to disable SecureBoot from UEFI. And this is another point of concerns for the next future operating system releases.
C.
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-12 22:18, Ricardo Chung wrote:
As far as it's tested, LiveCD are not impacted. Said so, you could be able to boot a LiveCD to play it Live Only. Not installing it. Though is possible it will change next months.
Mmm... this doesn't make much sense, booting anything is dangerous, it could be a virus. This is what they are trying to protect, people booting unsecured things. Once a malware boot code in a CD boots it can do lots of damage to a computer.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Tuesday, June 12, 2012 10:47:28 PM Carlos E. R. wrote:
On 2012-06-12 22:18, Ricardo Chung wrote:
As far as it's tested, LiveCD are not impacted. Said so, you could be able to boot a LiveCD to play it Live Only. Not installing it. Though is possible it will change next months.
Mmm... this doesn't make much sense, booting anything is dangerous, it could be a virus. This is what they are trying to protect, people booting unsecured things. Once a malware boot code in a CD boots it can do lots of damage to a computer.
That's becasue I said it's possible they change it the next months.
MS is considering to launch a total new toolset to protect their installed system. I'm speculating now, they trust their toolset enough.
As sample, http://www.zdnet.com/blog/microsoft/microsoft-kicks-off-beta-of-new-windows-... encryption-tool/12908
Regards,
On 13/06/12 06:47, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-12 22:18, Ricardo Chung wrote:
As far as it's tested, LiveCD are not impacted. Said so, you could be able to boot a LiveCD to play it Live Only. Not installing it. Though is possible it will change next months.
Mmm... this doesn't make much sense, booting anything is dangerous, it could be a virus. This is what they are trying to protect, people booting unsecured things. Once a malware boot code in a CD boots it can do lots of damage to a computer.
I guess that I must be completely missing the point here about this subject.
People have been booting a virus/malware-attracting system for decades - and people are still alive and the world has kept revolving[****].
People have been booting Linux systems for 2 decades and updating them, and installing new applications on them, and no Linux system has been taken down by a virus/malware - and the world has just kept on revolving in this period...
So why, suddenly, is this UEFI-thing come to the forefront? Nobody knew about this UEFI-thing beforehand, and now, out of the blue, Microsoft comes out with it - and everybody is supposed to go into panic mode?
Has someone been "asleep at the wheel", or am I missing the point about all this?
[****] A multi-million dollar industry exists because of this. What is their reaction to this UEFI-thing considering that they will be losing $millions and laying off people?
BC
On Wednesday 13 Jun 2012 15:21:12 Basil Chupin wrote:
So why, suddenly, is this UEFI-thing come to the forefront? Nobody knew about this UEFI-thing beforehand, and now, out of the blue, Microsoft comes out with it - and everybody is supposed to go into panic mode?
Has someone been "asleep at the wheel", or am I missing the point about all this?
This is not a new or unexpected innovation. This is an extension of the Palladium/TMP/Trusted Computing[1] innitiative to lock down computers so that only software in userland can be run without the absolute permission of the hardware and operating system vendor.
There are numerous real life applications for this technology such as intelligence, millitary, anti-malware, digital rights restrictions and so forth. The list of companies contributing to this in the link provided should raise a few eyebrows at least, for some of them this is about security, for others this is about control. None of it is about freedom of computing.
The objections that many, including myself, have to this technology is that you are absolutely handing control of your hardware over to a select band of corporations and their vested interests by enabling secure boot via TPM, signed boot loaders and kernels.
This technology may prove to be both a blessing and a curse. On one hand you can reduce the attack vectors and make computer systems more secure; on the other hand consumers are now having to ask permission from technology corporations, and by extension the interests that pressure them (entertainment corporations, governments, intelligence services etc...) to use the hardware you already own.
Additionally, how can you trust the harware implementation to not have back doors[2] in it anyway? And do you really trust the certificate authority given that some of root CA's in SSL chains have already been giving out generic certificates for cash for the express purpose of man-in-the-middle attacks. Do you trust Verisign to never give their signing keys to the US Government or intelligence services? Do you trust them enough to assume that no other nation state such as China has not already compromised them and can appropriate the signing keys?
The implications for free software, privacy and industrial espionage may be far reaching and severe. How do you know what your hardware is doing if you cannot interrogate it without permission? How do you know what your operating system is doing if you cannot run code in kernel space without permission?
Yes, I'm paranoid, but history, corporate behaviour and growing evidence suggest that I'm probably right to be so.
[1] http://en.wikipedia.org/wiki/Trusted_Computing_Group [2] http://en.wikipedia.org/wiki/Huawei#Security_concerns
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-13 12:30, Graham Anderson wrote:
On Wednesday 13 Jun 2012 15:21:12 Basil Chupin wrote:
Has someone been "asleep at the wheel", or am I missing the point about all this?
They have been fighting malware since... ever, and losing. Each time they release a new Windows version they boast of new security and antimalware features, than later fail or don't meet expectations.
...
This technology may prove to be both a blessing and a curse. On one hand you can reduce the attack vectors and make computer systems more secure; on the other hand consumers are now having to ask permission from technology corporations, and by extension the interests that pressure them (entertainment corporations, governments, intelligence services etc...) to use the hardware you already own.
Right.
Additionally, how can you trust the harware implementation to not have back doors[2] in it anyway? And do you really trust the certificate authority given that some of root CA's in SSL chains have already been giving out generic certificates for cash for the express purpose of man-in-the-middle attacks. Do you trust Verisign to never give their signing keys to the US Government or intelligence services? Do you trust them enough to assume that no other nation state such as China has not already compromised them and can appropriate the signing keys?
Right as well.
But all that is irrelevant. The technology is here this cycle and we can not avoid it, so we need to run with it.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On 13/06/12 21:09, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-13 12:30, Graham Anderson wrote:
On Wednesday 13 Jun 2012 15:21:12 Basil Chupin wrote:
Has someone been "asleep at the wheel", or am I missing the point about all this?
They have been fighting malware since... ever, and losing. Each time they release a new Windows version they boast of new security and antimalware features, than later fail or don't meet expectations.
...
This technology may prove to be both a blessing and a curse. On one hand you can reduce the attack vectors and make computer systems more secure; on the other hand consumers are now having to ask permission from technology corporations, and by extension the interests that pressure them (entertainment corporations, governments, intelligence services etc...) to use the hardware you already own.
Right.
Additionally, how can you trust the harware implementation to not have back doors[2] in it anyway? And do you really trust the certificate authority given that some of root CA's in SSL chains have already been giving out generic certificates for cash for the express purpose of man-in-the-middle attacks. Do you trust Verisign to never give their signing keys to the US Government or intelligence services? Do you trust them enough to assume that no other nation state such as China has not already compromised them and can appropriate the signing keys?
Right as well.
But all that is irrelevant. The technology is here this cycle and we can not avoid it, so we need to run with it.
Again, have I been missing something in all of this?
Has there been a definitive statement about what *exactly* is going to occur?
Or whatever is being written about simply speculation and hearsay?
I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?
BC
On Thu, 14 Jun 2012 23:33:45 +1000 Basil Chupin blchupin@iinet.net.au wrote:
I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?
Hi Correct, only for new systems/hardware that users wish to run Windows 8 as well as other OSes.
On this DELL E5510 my concern is that it appears I can't disable..... and it's only a concern, I only run linux on this machine...
On 15/06/12 00:09, Malcolm wrote:
On Thu, 14 Jun 2012 23:33:45 +1000 Basil Chupin blchupin@iinet.net.au wrote:
I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?
Hi Correct, only for new systems/hardware that users wish to run Windows 8 as well as other OSes.
Usage of correct terminology here seems to be of vital importance considering all the kerffuffle being written so far by people in this thread :-) .
Are you saying that the problem only affects those who want to DUAL BOOT (or run anything-Windows in a VM environment) with anything-Windows when using any Linux distro as their main operating system? or are you saying that this crap will apply to any new mobos in the coming months which not only may want to use Windows 8 but to any other operating system of whatever flavour including a Linux system which they may want to install?
On this DELL E5510 my concern is that it appears I can't disable..... and it's only a concern, I only run linux on this machine...
Which is what is confusing. If you only run Linux then why would you want to disable it? - especially as you are not using one of these yet-to-come UEFI enabled gizmos? (Actually, my mobo has this UEFI on it but I haven't looked at it yet.)
I am still confused by the fact that there has not been much stomping of feet and gnashing of teeth about this matter and that people at Fedora have made decisions about this while openSUSE has only this week suddenly woken up that something has to be done about this (if anything that is); not to mention that FOSS has been silent about it (at least I haven't seen any articles re their thinking) and the EU has not been stirring the pot about it.
Is all this just a storm in a tea cup or a serious thing?
BC
On Fri, 15 Jun 2012 01:02:10 +1000 Basil Chupin blchupin@iinet.net.au wrote:
On 15/06/12 00:09, Malcolm wrote:
On Thu, 14 Jun 2012 23:33:45 +1000 Basil Chupin blchupin@iinet.net.au wrote:
I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?
Hi Correct, only for new systems/hardware that users wish to run Windows 8 as well as other OSes.
Usage of correct terminology here seems to be of vital importance considering all the kerffuffle being written so far by people in this thread :-) .
Are you saying that the problem only affects those who want to DUAL BOOT (or run anything-Windows in a VM environment) with anything-Windows when using any Linux distro as their main operating system? or are you saying that this crap will apply to any new mobos in the coming months which not only may want to use Windows 8 but to any other operating system of whatever flavour including a Linux system which they may want to install?
Yes, just dual/multi boot with windows 8 on bare-metal (I would guess this two year old system would meet the requirements). Now, the virtualization method is an unknown for me, I guess kvm, xen etc would work as long as the kernels have the signed key. Not sure about a vm machine, I would guess as long as the BIOS is capable (and they have paid for keys?)
On this DELL E5510 my concern is that it appears I can't disable..... and it's only a concern, I only run linux on this machine...
Which is what is confusing. If you only run Linux then why would you want to disable it? - especially as you are not using one of these yet-to-come UEFI enabled gizmos? (Actually, my mobo has this UEFI on it but I haven't looked at it yet.)
Because the indications are that you can disable it.... in my case that appears from my earlier screenshot it's not possible, it's almost as though it's an OTP (One Time Program) I can enable but not disable (which also indicates I cannot update my BIOS unless it's signed by DELL).
I am still confused by the fact that there has not been much stomping of feet and gnashing of teeth about this matter and that people at Fedora have made decisions about this while openSUSE has only this week suddenly woken up that something has to be done about this (if anything that is); not to mention that FOSS has been silent about it (at least I haven't seen any articles re their thinking) and the EU has not been stirring the pot about it.
Is all this just a storm in a tea cup or a serious thing?
BC
Because Fedora don't expect their users to have to stomp around in the BIOS to change things.
To me on this system I have openSUSE (Default), SLED 11 and soon to be SLES. I turn my computer on and it boots to openSUSE as I'm only running elilo. If I want the others I hit the F12 key to get to the BIOS boot menu and select from there.
My assumption is that if I had windows 8 on it and the ability to disable the signed keys I would need to press F2 to get to the BIOS setup, disable the signed key system, reboot and then select my 'unsigned' system to boot (I'm also assuming this would be the case for windows 7?)
Having openSUSE with a signed key negates the BIOS routine....
Now if you custom compile stuff (eg kernel modules [which would include vm stuff?]) you either buy your own key (to avoid the BIOS step) or self sign (method??) and move forward.
Maybe some more details on your M/B, have you browsed the BIOS to look for any signed firmware option?
I actually like this UEFI and having a gpt partition system (no more extended partition) and 128 partitions all in a row....
Now the above comments are all observations on my part from reading the articles and my BIOS.... Maybe I need a flow chart of my booting and BIOS
At present if I was to enable a signed key system with windows 8, openSUSE and SLE along with virtualization, the way I see it I would need signed keys from;
1 - DELL 2 - Microsoft 3 - openSUSE 4 - SUSE 5 - VirtualBox 6 - Me for any customized kernel modules
On Thu, 14 Jun 2012 11:23:58 -0500 Malcolm malcolm_lewis@bellsouth.net wrote:
At present if I was to enable a signed key system with windows 8, openSUSE and SLE along with virtualization, the way I see it I would need signed keys from;
1 - DELL 2 - Microsoft 3 - openSUSE 4 - SUSE 5 - VirtualBox 6 - Me for any customized kernel modules
Hi I guess there is a number 7, any third party kernel modules would need to be signed... so for example a hardware provider decides to not provide a signed kernel driver for say a RAID card, one would imagine you could run into an issue....
On Fri, 15 Jun 2012 01:02:10 +1000, Basil Chupin wrote:
Are you saying that the problem only affects those who want to DUAL BOOT (or run anything-Windows in a VM environment) with anything-Windows when using any Linux distro as their main operating system? or are you saying that this crap will apply to any new mobos in the coming months which not only may want to use Windows 8 but to any other operating system of whatever flavour including a Linux system which they may want to install?
Dual-boot and systems with Win8 preinstalled. Even if you want to replace the installed Win8, the user has to disable the secure boot feature if we don't sign whatever it is that needs to be signed, which means we need to teach them how to do this (AIUI, it /must/ be disabled in the BIOS and can't be done from the installer or a running OS).
So the scenarios are:
1. New system with no OS on it - secure boot is probably disabled and not a concern.
2. New system with Win8 on it - Secure boot is enabled and has to be disabled in order to install openSUSE, regardless of whether it's a replacement of Win8 or a dual-boot configuration
Jim
On Thu, 14 Jun 2012 17:10:55 +0000, Jim Henderson wrote:
So the scenarios are:
- New system with no OS on it - secure boot is probably disabled and
not a concern.
- New system with Win8 on it - Secure boot is enabled and has to be
disabled in order to install openSUSE, regardless of whether it's a replacement of Win8 or a dual-boot configuration
I wonder what the risk is of a signed component going wrong/not validating - what would the recovery would be for such a scenario?
What I remember from reading the specs over, it seems that preserving a previous set of signed components (whatever there is that's needed) would be a good idea.
Jim
On 15/06/12 14:29, Jim Henderson wrote:
On Thu, 14 Jun 2012 17:10:55 +0000, Jim Henderson wrote:
So the scenarios are:
- New system with no OS on it - secure boot is probably disabled and
not a concern.
- New system with Win8 on it - Secure boot is enabled and has to be
disabled in order to install openSUSE, regardless of whether it's a replacement of Win8 or a dual-boot configuration
I wonder what the risk is of a signed component going wrong/not validating - what would the recovery would be for such a scenario?
What I remember from reading the specs over, it seems that preserving a previous set of signed components (whatever there is that's needed) would be a good idea.
Jim
If you have to do an addendum to what you wrote only a few minutes ago then can you understand my confusion - and I cannot be alone on this - about this whole matter? :-)
What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!
Where is "the Board"? Where is "the Foundation"? Where is anyone who actually knows what is going on and what has to done about this situation?
Oh, right...one must not ask questions like this... not the sort of questions one asks in polite company..... Asking questions like this only gets you the title of "troll"......
BC
On Tue, 19 Jun 2012 17:18:55 +1000, Basil Chupin wrote:
If you have to do an addendum to what you wrote only a few minutes ago then can you understand my confusion - and I cannot be alone on this - about this whole matter? :-)
Well, that was a separate thought, not really an 'addendum'.
What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!
From a practical standpoint, the openSUSE community is who builds the
distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.
It would be good, though, to hear what the board's collective thoughts are here.
Jim
On Tue, 19 Jun 2012 15:58:07 +0000 (UTC) Jim Henderson hendersj@gmail.com wrote:
What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!
From a practical standpoint, the openSUSE community is who builds the distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.
Hi That's why I added a couple of topics on next weeks project meeting... hopefully we will get a good attendance on IRC. http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting
On Tue, 19 Jun 2012 11:17:24 -0500, Malcolm wrote:
On Tue, 19 Jun 2012 15:58:07 +0000 (UTC) Jim Henderson hendersj@gmail.com wrote:
What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!
From a practical standpoint, the openSUSE community is who builds the distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.
Hi That's why I added a couple of topics on next weeks project meeting... hopefully we will get a good attendance on IRC. http://en.opensuse.org/
openSUSE:Project_meeting#Agenda_for_the_next_meeting
Ah, yes, now how did I forget that? :)
Jim
On 06/19/2012 06:17 PM, Malcolm wrote:
On Tue, 19 Jun 2012 15:58:07 +0000 (UTC) Jim Henderson hendersj@gmail.com wrote:
What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!
From a practical standpoint, the openSUSE community is who builds the distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.
Hi That's why I added a couple of topics on next weeks project meeting... hopefully we will get a good attendance on IRC. http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting
Michael Chang and some others in SUSE are looking into this and will propose a solution - for both SUSE and openSUSE. If you like to work with them, please speak up.
Otherwise, I think the project meeting is the wrong place for this, Andreas
On Wed, 20 Jun 2012 09:43:38 +0200 Andreas Jaeger aj@suse.com wrote:
On 06/19/2012 06:17 PM, Malcolm wrote:
On Tue, 19 Jun 2012 15:58:07 +0000 (UTC) Jim Henderson hendersj@gmail.com wrote:
What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!
From a practical standpoint, the openSUSE community is who builds the distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.
Hi That's why I added a couple of topics on next weeks project meeting... hopefully we will get a good attendance on IRC. http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting
Michael Chang and some others in SUSE are looking into this and will propose a solution - for both SUSE and openSUSE. If you like to work with them, please speak up.
Otherwise, I think the project meeting is the wrong place for this, Andreas
Hi Andreas
Thanks for the information, for sure I'd be happy to help if I can :)
Is there a Mailing List for this?
I will remove the two topics from the meeting topics.
On 06/20/2012 03:15 PM, Malcolm wrote:
On Wed, 20 Jun 2012 09:43:38 +0200 Andreas Jaeger aj@suse.com wrote:
On 06/19/2012 06:17 PM, Malcolm wrote:
On Tue, 19 Jun 2012 15:58:07 +0000 (UTC) Jim Henderson hendersj@gmail.com wrote:
What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!
From a practical standpoint, the openSUSE community is who builds the distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.
Hi That's why I added a couple of topics on next weeks project meeting... hopefully we will get a good attendance on IRC. http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting
Michael Chang and some others in SUSE are looking into this and will propose a solution - for both SUSE and openSUSE. If you like to work with them, please speak up.
Otherwise, I think the project meeting is the wrong place for this, Andreas
Hi Andreas
Thanks for the information, for sure I'd be happy to help if I can :)
Is there a Mailing List for this?
Talk with Michael directly,
Andreas
I will remove the two topics from the meeting topics.
On 20/06/12 01:58, Jim Henderson wrote:
On Tue, 19 Jun 2012 17:18:55 +1000, Basil Chupin wrote:
If you have to do an addendum to what you wrote only a few minutes ago then can you understand my confusion - and I cannot be alone on this - about this whole matter? :-)
Well, that was a separate thought, not really an 'addendum'.
What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve! From a practical standpoint, the openSUSE community is who builds the
distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.
It would be good, though, to hear what the board's collective thoughts are here.
Jim
Yes it would be nice to hear such views. And as SUSE is downstream to openSUSE and therefore have some interest in what happens at the openSUSE level it would also nice to hear their views.
BTW, I have seen written from time-to-time that some things have to be referred to "the legal team" for clarification/approval.
Who is the "legal team" employed by/responsible to?
BC
On 06/22/2012 02:26 PM, Basil Chupin wrote:
[...] Who is the "legal team" employed by/responsible to?
opensuse-bar is their mailing list, if you have specific questions or are a lawyer yourself and like to join the team, use that list.
Currently it's primarily Ciaran doing this for openSUSE - employed by SUSE.
Andreas
Speaking of UEFI and lawyers ...
[Phoronix] Ubuntu's Plans To Implement UEFI SecureBoot: No GRUB2 http://ow.ly/bM1WW
On 23/06/12 04:52, Andreas Jaeger wrote:
On 06/22/2012 02:26 PM, Basil Chupin wrote:
[...] Who is the "legal team" employed by/responsible to?
opensuse-bar is their mailing list, if you have specific questions or are a lawyer yourself and like to join the team, use that list.
Currently it's primarily Ciaran doing this for openSUSE - employed by SUSE.
Andreas
Thank you, Andreas.
I just came across this:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
BC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 15:33, Basil Chupin wrote:
I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?
As far as I know, it is correct, it only affects those that double boot to Windows 8. And the understanding is that they would need to disable the feature to boot Linux, and reenable to boot Windows 8 - every single time. This is unverified yet.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 15:33, Basil Chupin wrote:
I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?
As far as I know, it is correct, it only affects those that double boot to Windows 8. And the understanding is that they would need to disable the feature to boot Linux, and reenable to boot Windows 8 - every single time. This is unverified yet.
What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 19:36, Per Jessen wrote:
Carlos E. R. wrote:
What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.
I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Thu, 14 Jun 2012 22:58:13 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 19:36, Per Jessen wrote:
Carlos E. R. wrote:
What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.
I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios.
Hi That was me, the way I understand (and I hope I'm wrong) it is, that is the key signature option (SecureBoot) that is in my current BIOS... just one way for me if I used it.....
There must be other folks on the list with UEFI in their BIOSes... what options do they have?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-15 00:58, Malcolm wrote:
On Thu, 14 Jun 2012 22:58:13 +0200 "Carlos E. R." <> wrote:
I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios.
Hi That was me, the way I understand (and I hope I'm wrong) it is, that is the key signature option (SecureBoot) that is in my current BIOS... just one way for me if I used it.....
It is early, I think, for secure bios, few machines will have it.
Your photo says:
+++··················
[ ] signed firmware update
This feature, when enabled, will enforce the verification of digital signatures in the firmware update payload prior to performing an update of the firmware. Once enabled, the system BIOS cannot be updated to any revision that DOES NOT contain a valid signature.
Note: You will not be able to change the setting once the feature is enabled. ··················++-
It is about _BIOS_ update, which is normally named flashing the bios. This is not about signature of the boot code of the operating system. It is not the secure boot feature, IMO.
There must be other folks on the list with UEFI in their BIOSes... what options do they have?
UEFI yes. Secure boot, fewer.
http://en.wikipedia.org/wiki/Uefi
it mentions use of UEFI several years ago.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On 15/06/12 08:58, Malcolm wrote:
On Thu, 14 Jun 2012 22:58:13 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 19:36, Per Jessen wrote:
Carlos E. R. wrote:
What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.
I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios.
Hi That was me, the way I understand (and I hope I'm wrong)
But you are not sure, right? :-)
it is, that is the key signature option (SecureBoot) that is in my current BIOS... just one way for me if I used it.....
But you aren't sure, right? :-)
There must be other folks on the list with UEFI in their BIOSes... what options do they have?
Beats me! :-[
But you don't know either, right? :-D
And you and I, and Carlos and Per and Jim are all part of "the community" - and we haven't a damn idea of how it is all supposed to work :-) .
BC
2012/6/19 Basil Chupin blchupin@iinet.net.au:
On 15/06/12 08:58, Malcolm wrote:
On Thu, 14 Jun 2012 22:58:13 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 19:36, Per Jessen wrote:
Carlos E. R. wrote:
What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.
I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios.
Hi That was me, the way I understand (and I hope I'm wrong)
But you are not sure, right? :-)
it is, that is the key signature option (SecureBoot) that is in my current BIOS... just one way for me if I used it.....
But you aren't sure, right? :-)
There must be other folks on the list with UEFI in their BIOSes... what options do they have?
I ever joined some UEFI event and talked to some of the bios engineer wrt secure boot options in bios. As far as I know the option varies from ODM, but in bios there would be three possible options to "circumvent" secure boot .. I saw one of the bios vendor presented these options to us.
1. Disable Secure Boot
Means bios would allow files failed in authentication to execute, but there would be warning message when you attempt to do so
2. Set to Legacy or Dual (Legacy + UEFI) mode
Which implies disable secure boot, as secure boot implementation requires running in pure UEFI mode (no legacy emulation module exist). This is also promise to the Windows 7 to run I think.
3. Add files to hash table
Allow user manually add file hash to db and allow to run in secure boot enabled mode.
But I must say it's unsure whether those options is common, OEM would custom their bios to offer different options and I think above just possibilities.
Thanks, Michael
Beats me! :-[
But you don't know either, right? :-D
And you and I, and Carlos and Per and Jim are all part of "the community" - and we haven't a damn idea of how it is all supposed to work :-) .
BC
-- Using openSUSE 12.1 x86_64 KDE 4.8.4 and kernel 3.4.4 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 19/06/12 18:19, Michael Chang wrote:
2012/6/19 Basil Chupin blchupin@iinet.net.au:
On 15/06/12 08:58, Malcolm wrote:
On Thu, 14 Jun 2012 22:58:13 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 19:36, Per Jessen wrote:
Carlos E. R. wrote:
What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.
I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios.
Hi That was me, the way I understand (and I hope I'm wrong)
But you are not sure, right? :-)
it is, that is the key signature option (SecureBoot) that is in my current BIOS... just one way for me if I used it.....
But you aren't sure, right? :-)
There must be other folks on the list with UEFI in their BIOSes... what options do they have?
I ever joined some UEFI event and talked to some of the bios engineer wrt secure boot options in bios. As far as I know the option varies from ODM, but in bios there would be three possible options to "circumvent" secure boot .. I saw one of the bios vendor presented these options to us.
- Disable Secure Boot
Means bios would allow files failed in authentication to execute, but there would be warning message when you attempt to do so
- Set to Legacy or Dual (Legacy + UEFI) mode
Which implies disable secure boot, as secure boot implementation requires running in pure UEFI mode (no legacy emulation module exist). This is also promise to the Windows 7 to run I think.
- Add files to hash table
Allow user manually add file hash to db and allow to run in secure boot enabled mode.
But I must say it's unsure whether those options is common, OEM would custom their bios to offer different options and I think above just possibilities.
Thanks, Michael
Thank you, Michael, for this explanation.
But, as you state, there is no consensus as to what is going to happen, and only 1 vendor proffered the 3 options you mentioned.
BC
On Fri, 22 Jun 2012 22:39:17 +1000, Basil Chupin wrote:
But, as you state, there is no consensus as to what is going to happen, and only 1 vendor proffered the 3 options you mentioned.
Looks like Canonical is now involved in solving it for Ubuntu - they're going to use efiboot it looks like, which apparently (from a slashdot article, so follow the link to the "real" story) means they only need to sign the bootloader and not the kernel.
But that is likely to make things difficult for multi-boot Linux users, if the distros have different solutions and require different bootloaders.
Jim
On 23/06/12 02:33, Jim Henderson wrote:
On Fri, 22 Jun 2012 22:39:17 +1000, Basil Chupin wrote:
But, as you state, there is no consensus as to what is going to happen, and only 1 vendor proffered the 3 options you mentioned.
Looks like Canonical is now involved in solving it for Ubuntu - they're going to use efiboot it looks like, which apparently (from a slashdot article, so follow the link to the "real" story) means they only need to sign the bootloader and not the kernel.
But that is likely to make things difficult for multi-boot Linux users, if the distros have different solutions and require different bootloaders.
Jim
As I just mentioned to Andreas, I came across this a few minutes ago:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
BC
On Fri, Jun 22, 2012 at 9:59 PM, Basil Chupin blchupin@iinet.net.au wrote:
On 23/06/12 02:33, Jim Henderson wrote:
On Fri, 22 Jun 2012 22:39:17 +1000, Basil Chupin wrote:
But, as you state, there is no consensus as to what is going to happen, and only 1 vendor proffered the 3 options you mentioned.
Looks like Canonical is now involved in solving it for Ubuntu - they're going to use efiboot it looks like, which apparently (from a slashdot article, so follow the link to the "real" story) means they only need to sign the bootloader and not the kernel.
But that is likely to make things difficult for multi-boot Linux users, if the distros have different solutions and require different bootloaders.
Jim
As long as the most recently installed bootloader:
1. Is legal, paid for, blessed by all the attorneys, accountants, etc. and 2. Can find and boot everything that was bootable before it was installed
I'd say everyone should be happy. I'm currently thrashing about getting openSUSE 12.2 beta 2 and Fedora 17 bootloaders to acknowledge everything and I must say neither's version of GRUB2 is looking very good right now. ;-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-23 06:59, Basil Chupin wrote:
On 23/06/12 02:33, Jim Henderson wrote:
As I just mentioned to Andreas, I came across this a few minutes ago:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
Well, at least these people clearly know what they have to do.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
* Carlos E. R. carlos.e.r@opensuse.org [06-23-12 07:54]:
On 2012-06-23 06:59, Basil Chupin wrote:
On 23/06/12 02:33, Jim Henderson wrote:
As I just mentioned to Andreas, I came across this a few minutes ago:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
Well, at least these people clearly know what they have to do.
Would it be a "good idea" for all of linux to embrace this *solution* and use/share the same key/loader?
As I just mentioned to Andreas, I came across this a few minutes ago:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
Well, at least these people clearly know what they have to do.
So what do we (openSUSE) need to do so we also have a decision about which path we will follow?
Can we create a (short) list of proposals and a list of decision criteria?
David
On Sat, Jun 23, 2012 at 5:57 AM, Administrator admin@different-perspectives.com wrote:
As I just mentioned to Andreas, I came across this a few minutes ago:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
Well, at least these people clearly know what they have to do.
So what do we (openSUSE) need to do so we also have a decision about which path we will follow?
Can we create a (short) list of proposals and a list of decision criteria?
David
So far there are two strategies on the books: the Red Hat / Fedora strategy and the Canonical / Ubuntu strategy. Instead of further discussion, proposals, decision criteria, etc., let's make a list of peoples' names. Who will make the decision? And I don't mean "SUSE corporate", "the openSUSE team", "the lawyers", etc. I mean actual names of actual people with email addresses and phone numbers that we can hold accountable for the decision.
On 24/06/12 14:54, M. Edward (Ed) Borasky wrote:
On Sat, Jun 23, 2012 at 5:57 AM, Administrator admin@different-perspectives.com wrote:
As I just mentioned to Andreas, I came across this a few minutes ago:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
Well, at least these people clearly know what they have to do.
So what do we (openSUSE) need to do so we also have a decision about which path we will follow?
Can we create a (short) list of proposals and a list of decision criteria?
David
So far there are two strategies on the books: the Red Hat / Fedora strategy and the Canonical / Ubuntu strategy. Instead of further discussion, proposals, decision criteria, etc., let's make a list of peoples' names. Who will make the decision? And I don't mean "SUSE corporate", "the openSUSE team", "the lawyers", etc. I mean actual names of actual people with email addresses and phone numbers that we can hold accountable for the decision.
Here is the latest in this unholy M$ created saga:
http://www.ubuntuvibes.com/2012/06/ubuntu-plans-to-drop-grub-2-for.html
BC
As I just mentioned to Andreas, I came across this a few minutes ago:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
Well, at least these people clearly know what they have to do.
So what do we (openSUSE) need to do so we also have a decision about
which
path we will follow?
Can we create a (short) list of proposals and a list of decision
criteria?
David
So far there are two strategies on the books: the Red Hat / Fedora strategy and the Canonical / Ubuntu strategy. Instead of further discussion, proposals, decision criteria, etc., let's make a list of peoples' names. Who will make the decision? And I don't mean "SUSE corporate", "the openSUSE team", "the lawyers", etc. I mean actual names of actual people with email addresses and phone numbers that we can hold accountable for the decision.
Not really a "community" approach - you decide (without guidance) and we'll get upset with you (hold you accountable) if we don't like the decision.
I like the decision criteria presented in the Ubuntu piece: - must be able to boot to a live CD / DVD without the need to go into BIOS settings - must be able to install without the need to go into BIOS settings - we must be able to continue community development of all parts of the distribution including kernel & boot loader - it must not require new keys (or whatever externally provided security doo-dahs) for new releases of the distribution / software package - it should allow a boot menu where people can have installed and be able to choose different installs of Linux (or O/Ss of their choice) - it must be compatible with the licences of the existing distribution packages i.e. no radical overhaul / restructuring - it should be familiar to and understandable by our community (developers and users) i.e. no extensive relearning needed
Any other criteria?
If we give criteria like these to a group of experts and they devise a solution which fits, then (implicitly or explicitly) we agree.
David
On 25/06/12 00:47, Administrator wrote:
As I just mentioned to Andreas, I came across this a few minutes ago:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
Well, at least these people clearly know what they have to do.
So what do we (openSUSE) need to do so we also have a decision about
which
path we will follow?
Can we create a (short) list of proposals and a list of decision
criteria?
David
So far there are two strategies on the books: the Red Hat / Fedora strategy and the Canonical / Ubuntu strategy. Instead of further discussion, proposals, decision criteria, etc., let's make a list of peoples' names. Who will make the decision? And I don't mean "SUSE corporate", "the openSUSE team", "the lawyers", etc. I mean actual names of actual people with email addresses and phone numbers that we can hold accountable for the decision.
Not really a "community" approach - you decide (without guidance) and we'll get upset with you (hold you accountable) if we don't like the decision.
We we also need the addresses so that we can go to those addresses and burn crosses on their front yards and possibly torch the residents if the moon is in the right position in the heavens.
That's what the community is all about: community decisions and community action.
There are parallels in history about actions carried out based on community decisions. One which comes to mind is something which happened in some place called Salem and also Rosewood....
BC
On 15/06/12 03:36, Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 15:33, Basil Chupin wrote:
I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?
As far as I know, it is correct, it only affects those that double boot to Windows 8. And the understanding is that they would need to disable the feature to boot Linux, and reenable to boot Windows 8 - every single time. This is unverified yet.
What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.
"Unverified". And yet "the comminuty" is being asked how to solve this "unverified" problem.
Akin to the situation of the blind leading the blind.
I don' know what it all means.
Carlos does not know what it all means.
Jim doesn't know what it all means.
You don't know what it all means.
Who does know?
Perhaps Jos who seems to know everything.
BC
On 15/06/12 03:24, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-14 15:33, Basil Chupin wrote:
I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?
As far as I know, it is correct, it only affects those that double boot to Windows 8. And the understanding is that they would need to disable the feature to boot Linux, and reenable to boot Windows 8 - every single time. This is unverified yet.
"This is unverified yet".
The crux of the whole mess, Carlos.
BC
On 13/06/12 20:30, Graham Anderson wrote:
On Wednesday 13 Jun 2012 15:21:12 Basil Chupin wrote:
So why, suddenly, is this UEFI-thing come to the forefront? Nobody knew about this UEFI-thing beforehand, and now, out of the blue, Microsoft comes out with it - and everybody is supposed to go into panic mode?
Has someone been "asleep at the wheel", or am I missing the point about all this?
This is not a new or unexpected innovation. This is an extension of the Palladium/TMP/Trusted Computing[1] innitiative to lock down computers so that only software in userland can be run without the absolute permission of the hardware and operating system vendor.
There are numerous real life applications for this technology such as intelligence, millitary, anti-malware, digital rights restrictions and so forth. The list of companies contributing to this in the link provided should raise a few eyebrows at least, for some of them this is about security, for others this is about control. None of it is about freedom of computing.
The objections that many, including myself, have to this technology is that you are absolutely handing control of your hardware over to a select band of corporations and their vested interests by enabling secure boot via TPM, signed boot loaders and kernels.
This technology may prove to be both a blessing and a curse. On one hand you can reduce the attack vectors and make computer systems more secure; on the other hand consumers are now having to ask permission from technology corporations, and by extension the interests that pressure them (entertainment corporations, governments, intelligence services etc...) to use the hardware you already own.
Additionally, how can you trust the harware implementation to not have back doors[2] in it anyway? And do you really trust the certificate authority given that some of root CA's in SSL chains have already been giving out generic certificates for cash for the express purpose of man-in-the-middle attacks. Do you trust Verisign to never give their signing keys to the US Government or intelligence services? Do you trust them enough to assume that no other nation state such as China has not already compromised them and can appropriate the signing keys?
The implications for free software, privacy and industrial espionage may be far reaching and severe. How do you know what your hardware is doing if you cannot interrogate it without permission? How do you know what your operating system is doing if you cannot run code in kernel space without permission?
Yes, I'm paranoid, but history, corporate behaviour and growing evidence suggest that I'm probably right to be so.
No need to feel that you are paranoid about this, Graham. It is exactly how I feel - and there must be tens of thousands of others as well who feel the same - about the whole thing.
I can almost guarantee that if this scheme was deviced by some company in China then the whole sheebang would be ridiculed, thrown out of consideration as a cyber warfare weapon and what not.
[1] http://en.wikipedia.org/wiki/Trusted_Computing_Group [2] http://en.wikipedia.org/wiki/Huawei#Security_concerns
BC
On Thursday, June 14, 2012 11:27:30 PM Basil Chupin wrote:
On 13/06/12 20:30, Graham Anderson wrote:
On Wednesday 13 Jun 2012 15:21:12 Basil Chupin wrote:
So why, suddenly, is this UEFI-thing come to the forefront? Nobody knew about this UEFI-thing beforehand, and now, out of the blue, Microsoft comes out with it - and everybody is supposed to go into panic mode?
Has someone been "asleep at the wheel", or am I missing the point about all this?
This is not a new or unexpected innovation. This is an extension of the Palladium/TMP/Trusted Computing[1] innitiative to lock down computers so that only software in userland can be run without the absolute permission of the hardware and operating system vendor.
There are numerous real life applications for this technology such as intelligence, millitary, anti-malware, digital rights restrictions and so forth. The list of companies contributing to this in the link provided should raise a few eyebrows at least, for some of them this is about security, for others this is about control. None of it is about freedom of computing.
The objections that many, including myself, have to this technology is that you are absolutely handing control of your hardware over to a select band of corporations and their vested interests by enabling secure boot via TPM, signed boot loaders and kernels.
This technology may prove to be both a blessing and a curse. On one hand you can reduce the attack vectors and make computer systems more secure; on the other hand consumers are now having to ask permission from technology corporations, and by extension the interests that pressure them (entertainment corporations, governments, intelligence services etc...) to use the hardware you already own.
Additionally, how can you trust the harware implementation to not have back doors[2] in it anyway? And do you really trust the certificate authority given that some of root CA's in SSL chains have already been giving out generic certificates for cash for the express purpose of man-in-the-middle attacks. Do you trust Verisign to never give their signing keys to the US Government or intelligence services? Do you trust them enough to assume that no other nation state such as China has not already compromised them and can appropriate the signing keys?
The implications for free software, privacy and industrial espionage may be far reaching and severe. How do you know what your hardware is doing if you cannot interrogate it without permission? How do you know what your operating system is doing if you cannot run code in kernel space without permission?
Yes, I'm paranoid, but history, corporate behaviour and growing evidence suggest that I'm probably right to be so.
No need to feel that you are paranoid about this, Graham. It is exactly how I feel - and there must be tens of thousands of others as well who feel the same - about the whole thing.
I can almost guarantee that if this scheme was deviced by some company in China then the whole sheebang would be ridiculed, thrown out of consideration as a cyber warfare weapon and what not.
[1] http://en.wikipedia.org/wiki/Trusted_Computing_Group [2] http://en.wikipedia.org/wiki/Huawei#Security_concerns
BC
Being paronoid is smart on these days. Trying not to be is not so smart. We need clear criteria to know that. There is enough technological devices tracking or collecting data from us every moment. Some of those devices are not user controlled. In other case, we pay some services to be tracked or collecting our data.
OTOH, In case anyone is interested.
The last reflections Mathew Garrett has posted about SecureBoot on this link http://mjg59.dreamwidth.org/13061.html
Regards,
On Tue, 12 Jun 2012 21:36:09 +0200 C smaug42@opensuse.org wrote:
I agree 100% here. We should stop waffling... buy the darned key and let's get on with implementing it into the standard openSUSE releases. We can be ready on time for the releases - which are happening later this year... or we can play catchup.... again.
If we don't have enough money in the marketing budget or wherever, then ask on the project list.. I'm sure that one or several of us could cough up the $99 US to cover it for the project.
C.
Hi According to this, if I want to roll my own... I need to pay up as well... http://www.redhat.com/about/news/archive/2012/6/uefi-secure-boot
"A healthy dynamic of the Linux open source development model is the ability to roll-your-own. For example, users take Fedora and rebuild custom variants to meet personal interest or experiment in new innovations. Such creative individuals can also participate by simply enrolling in the $99 one time fee to license UEFI. For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."
Not sure about the intentions of the last sentence though.... to me that indicates I can create my own key at no cost and boot to linux as well as use an MS signed key for windows 8... which sort of negates the need?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-13 04:30, Malcolm wrote:
According to this, if I want to roll my own... I need to pay up as well... http://www.redhat.com/about/news/archive/2012/6/uefi-secure-boot
"A healthy dynamic of the Linux open source development model is the ability to roll-your-own. For example, users take Fedora and rebuild custom variants to meet personal interest or experiment in new innovations. Such creative individuals can also participate by simply enrolling in the $99 one time fee to license UEFI. For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."
Not sure about the intentions of the last sentence though.... to me that indicates I can create my own key at no cost and boot to linux as well as use an MS signed key for windows 8... which sort of negates the need?
I understand that you may add your local certificate somehow, valid only for you.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Tuesday 12 June 2012 21:36:09 C wrote:
On Tue, Jun 12, 2012 at 9:17 PM, Ricardo Chung amon0.thoth1@gmail.com
wrote:
You should be able to enable/disable the SecureBoot option on UEFI with no further issues.
That assumes that:
- The manufacturer puts that option into the UEFI setup (it's not
mandatory, from what I read, that they allow you to disable it... they can allow it.. or not...it's only on Arm that they currently cannot allow it to be disabled if they want the Win8 Certified logo.. which they all want) 2. The end user is aware of this requirement to disable UEFI 3. The end user is capable of disabling UEFI
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The core issue is not on Windows 8 laptops. It's the specification ARM Architecture+Window 8 Certification Logo+UEFI+SecureBoot. This special scenario will come with a SecureBoot not able to deactivate on UEFI or any other ways.
Other architectures like x86 may be coming with the option to deactivate SecureBoot on UEFI.
Operative word there being "may".
Any concerns related to boot other operating systems than Windows 8 with Certification Logo must be addressed to get a key registered with Microsoft Keys Manager. At this right moment, it seems no other options cost-effective feasible and available.
I agree 100% here. We should stop waffling... buy the darned key and let's get on with implementing it into the standard openSUSE releases. We can be ready on time for the releases - which are happening later this year... or we can play catchup.... again.
If we don't have enough money in the marketing budget or wherever, then ask on the project list.. I'm sure that one or several of us could cough up the $99 US to cover it for the project.
Sensible.
I'll try and bring this up with SUSE, see if MS can indeed help us with this. Seems to me like we simply would have to do what Fedora did.
C.
On Wed, 13 Jun 2012 21:09:13 +0200 Jos Poortvliet jos@opensuse.org wrote:
On Tuesday 12 June 2012 21:36:09 C wrote:
On Tue, Jun 12, 2012 at 9:17 PM, Ricardo Chung amon0.thoth1@gmail.com
wrote:
You should be able to enable/disable the SecureBoot option on UEFI with no further issues.
That assumes that:
- The manufacturer puts that option into the UEFI setup (it's not
mandatory, from what I read, that they allow you to disable it... they can allow it.. or not...it's only on Arm that they currently cannot allow it to be disabled if they want the Win8 Certified logo.. which they all want) 2. The end user is aware of this requirement to disable UEFI 3. The end user is capable of disabling UEFI
The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.
The core issue is not on Windows 8 laptops. It's the specification ARM Architecture+Window 8 Certification Logo+UEFI+SecureBoot. This special scenario will come with a SecureBoot not able to deactivate on UEFI or any other ways.
Other architectures like x86 may be coming with the option to deactivate SecureBoot on UEFI.
Operative word there being "may".
Any concerns related to boot other operating systems than Windows 8 with Certification Logo must be addressed to get a key registered with Microsoft Keys Manager. At this right moment, it seems no other options cost-effective feasible and available.
I agree 100% here. We should stop waffling... buy the darned key and let's get on with implementing it into the standard openSUSE releases. We can be ready on time for the releases - which are happening later this year... or we can play catchup.... again.
If we don't have enough money in the marketing budget or wherever, then ask on the project list.. I'm sure that one or several of us could cough up the $99 US to cover it for the project.
Sensible.
I'll try and bring this up with SUSE, see if MS can indeed help us with this. Seems to me like we simply would have to do what Fedora did.
C.
Hi And to follow up, I took the liberty of adding it as an agenda item for the next project meeting. http://en.opensuse.org/openSUSE:Project_meeting#Agenda
On Tue, 12 Jun 2012 14:17:38 -0500 Ricardo Chung amon0.thoth1@gmail.com wrote:
Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....
You should be able to enable/disable the SecureBoot option on UEFI with no further issues.
You would think.... http://paste.opensuse.org/96506247
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-12 21:47, Malcolm wrote:
You would think.... http://paste.opensuse.org/96506247
No, that's a different thing.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Tuesday, June 12, 2012 02:47:58 PM Malcolm wrote:
On Tue, 12 Jun 2012 14:17:38 -0500 Ricardo Chung amon0.thoth1@gmail.com
wrote:
Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....
You should be able to enable/disable the SecureBoot option on UEFI with no further issues.
You would think.... http://paste.opensuse.org/96506247
That picture shows once it key signature option (SecureBoot) is enabled there is no way to go back to unsigned option to boot any not signed operating system.
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-12 22:37, Ricardo Chung wrote:
On Tuesday, June 12, 2012 02:47:58 PM Malcolm wrote:
You would think.... http://paste.opensuse.org/96506247
That picture shows once it key signature option (SecureBoot) is enabled there is no way to go back to unsigned option to boot any not signed operating system.
What is secured there is flashing the bios, IMO.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Tuesday, June 12, 2012 10:49:04 PM Carlos E. R. wrote:
On 2012-06-12 22:37, Ricardo Chung wrote:
On Tuesday, June 12, 2012 02:47:58 PM Malcolm wrote:
You would think.... http://paste.opensuse.org/96506247
That picture shows once it key signature option (SecureBoot) is enabled there is no way to go back to unsigned option to boot any not signed operating system.
What is secured there is flashing the bios, IMO.
I wouldn't dare to say it that way. Once it's flashed there is no way to reverse it or modifying it. And that's the MS Dream come true.
If this would flash the ROM or any other mechanism theoretically it's possible to change it.. Not on this case.
At least, this is the information as far as I have been collecting about UEFI+SecureBoot+Digital Keys+Microfosoft Key Management+etc...
Regards,
On Tuesday, June 12, 2012 02:47:58 PM Malcolm wrote:
On Tue, 12 Jun 2012 14:17:38 -0500 Ricardo Chung amon0.thoth1@gmail.com
wrote:
Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....
You should be able to enable/disable the SecureBoot option on UEFI with no further issues.
You would think.... http://paste.opensuse.org/96506247
Personally, I think this (SecureBoot with Digital Key Signature) is a MS trustworthy initiative looking for keep off Windows operating system piracy.. Digitally Not signed systems will not boot. A digital key signature may be difficult to clone without the proper permissions.
Regards,
On Tue, 12 Jun 2012 12:51:21 -0500, Malcolm wrote:
AFAIK openSUSE needs to take the lead as they are upstream ;)
My thinking here is that the openSUSE community has taken a lot of guff as a result of the Novell/MS (now SUSE/MS) deal - so we should be able to benefit from the deal as well.
A collaboration between openSUSE, SUSE, and MS would seem a way to move things forward - SUSE needs us to be able to boot in those environments since we're upstream to them, and it would be a good sign of support of the openSUSE project (not that SUSE doesn't continually show good signs of support to the project, quite the contrary).
Jim
On Tue, Jun 12, 2012 at 2:05 PM, Jim Henderson hendersj@gmail.com wrote:
On Tue, 12 Jun 2012 12:51:21 -0500, Malcolm wrote:
AFAIK openSUSE needs to take the lead as they are upstream ;)
My thinking here is that the openSUSE community has taken a lot of guff as a result of the Novell/MS (now SUSE/MS) deal - so we should be able to benefit from the deal as well.
A collaboration between openSUSE, SUSE, and MS would seem a way to move things forward - SUSE needs us to be able to boot in those environments since we're upstream to them, and it would be a good sign of support of the openSUSE project (not that SUSE doesn't continually show good signs of support to the project, quite the contrary).
Jim
Yes, negotiated win-win-win contracts are the only way this can work. ;-) Microsoft has more problems than just malware and piracy, by the way:
1. Competition in security from Google ChromeBooks 2. Competition from Apple and Google in mobile devices 3. Competition from Red Hat, VMware and Oracle in virtualization / hypervisors
in addition to having a barely credible search engine and a useless browser. ;-)
But actually - since the Novell sale to Attachmate, what parts of the Microsoft / Novell deal are still active? I never saw all the "fine print" discussed in the trade press, just plenty of reassurance from the new owners about SUSE and openSUSE.
On Tue, 12 Jun 2012 14:30:51 -0700, M. Edward (Ed) Borasky wrote:
But actually - since the Novell sale to Attachmate, what parts of the Microsoft / Novell deal are still active? I never saw all the "fine print" discussed in the trade press, just plenty of reassurance from the new owners about SUSE and openSUSE.
From what I understand (and was discussed briefly at the SUSE Linux Days
2012 event I attended this morning - though the presenters were just SEs and not involved in the legal stuff), the agreement was renewed by SUSE. The indemnification clause that everyone got jumpy about is still in place, as is the technical collaboration agreement.
Seems like the latter of those is - or could be - relevant here.
Jim
Well If I right understood, this new secure feature, deep impact and affect the computer manufacturers too like, IBM, DELL, HP, POSITIVO, and many others that already provide their Linux offers at the same machine.
I believe this new boot feature that only make people able to boot and install OSs if it is already signed by someone, will not be so good to hardware machine builders companies, because the manufactures will loose the power and flexibility of Linux in their offers also make them unable to provide any kind of support or not, or at least they will need to change something in theirs strategy to be compliant with a company like microsoft that has nothing related with their business?
In some countries we have an common selling practice and strategy called "Venda Casada"[1] something similar to "linked sale" or "cross-selling" that is not legally in some countries
"Cross-selling is when additional products and/or services are offered to the customer in order to meet specific needs associated with the original service request."
The question is, there is no law that make this feature illegally?
If manufactures starts to know about that and refuse to implement this "secure boot" feature into their products like IBM, Dell, POSITIVO, HP so maybe Microsoft starts to think in another way to implemented such thing without forcing these companies to be dependent of this company.
Of course we need to keep looking for a technical solution, but also I think is a good idea to start to think about political, economical and based on specifics laws solutions to help us to keep the freedom of choice and diversity on top of humanity needs instead of "secure".
I remember that sometimes in past customers power makes companies to do unbelievable agreements that we could never imagine, and I'm not talking if their agreements was good or not, just unpredictable.
Another point is that some big, huge, enormous customers of these manufactures like walmart, casas bahia, petrobras and many others around the world have heterogeneous IT infrastructure and probably they will not be happy to know that in few time they will not more be able to have freedom of choice about which OS they will run or flexibility to change from one to another one. So this is not only about 99 pieces of a value metal, depending of the point of view could be also a problem to some companies strategy and freedom to run their business just like they want and not imposed by other company that have nothing related with their market or business and could be a legal issue too.
How many companies are building their solutions using SUSE Studio, how many building their solutions with kiwi, obs. ? Makes sense to involve companies that are running obs and studio? Do they will effectively be affected?
[1] http://pt.wikipedia.org/wiki/Venda_casada
CarlosRibeiro
2012/6/12 Jim Henderson hendersj@gmail.com:
On Tue, 12 Jun 2012 12:51:21 -0500, Malcolm wrote:
AFAIK openSUSE needs to take the lead as they are upstream ;)
My thinking here is that the openSUSE community has taken a lot of guff as a result of the Novell/MS (now SUSE/MS) deal - so we should be able to benefit from the deal as well.
A collaboration between iopenSUSE, SUSE, and MS would seem a way to move things forward - SUSE needs us to be able to boot in those environments since we're upstream to them, and it would be a good sign of support of the openSUSE project (not that SUSE doesn't continually show good signs of support to the project, quite the contrary).
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 12 Jun 2012 19:04:19 -0300, Carlos Ribeiro wrote:
Of course we need to keep looking for a technical solution, but also I think is a good idea to start to think about political, economical and based on specifics laws solutions to help us to keep the freedom of choice and diversity on top of humanity needs instead of "secure".
I agree that there are potential legal issues here as well (which is something SUSE and The Attachmate Group need to address). This entire feature smells to me like an attempt at more anti-competitive behaviour on MS' part (especially on ARM).
But until some court rules that it is actually anti-competitive, the technical challenge remains, and for the openSUSE project, the technical issues are something we need to work out - on our own or with SUSE's help.
Just seems to me that SUSE really could help us with this.
Jim
On Tue, Jun 12, 2012 at 3:04 PM, Carlos Ribeiro carlosalberto.net@gmail.com wrote:
Well If I right understood, this new secure feature, deep impact and affect the computer manufacturers too like, IBM, DELL, HP, POSITIVO, and many others that already provide their Linux offers at the same machine.
I believe this new boot feature that only make people able to boot and install OSs if it is already signed by someone, will not be so good to hardware machine builders companies, because the manufactures will loose the power and flexibility of Linux in their offers also make them unable to provide any kind of support or not, or at least they will need to change something in theirs strategy to be compliant with a company like microsoft that has nothing related with their business?
In some countries we have an common selling practice and strategy called "Venda Casada"[1] something similar to "linked sale" or "cross-selling" that is not legally in some countries
"Cross-selling is when additional products and/or services are offered to the customer in order to meet specific needs associated with the original service request."
The question is, there is no law that make this feature illegally?
If manufactures starts to know about that and refuse to implement this "secure boot" feature into their products like IBM, Dell, POSITIVO, HP so maybe Microsoft starts to think in another way to implemented such thing without forcing these companies to be dependent of this company.
Of course we need to keep looking for a technical solution, but also I think is a good idea to start to think about political, economical and based on specifics laws solutions to help us to keep the freedom of choice and diversity on top of humanity needs instead of "secure".
I remember that sometimes in past customers power makes companies to do unbelievable agreements that we could never imagine, and I'm not talking if their agreements was good or not, just unpredictable.
Another point is that some big, huge, enormous customers of these manufactures like walmart, casas bahia, petrobras and many others around the world have heterogeneous IT infrastructure and probably they will not be happy to know that in few time they will not more be able to have freedom of choice about which OS they will run or flexibility to change from one to another one. So this is not only about 99 pieces of a value metal, depending of the point of view could be also a problem to some companies strategy and freedom to run their business just like they want and not imposed by other company that have nothing related with their market or business and could be a legal issue too.
How many companies are building their solutions using SUSE Studio, how many building their solutions with kiwi, obs. ? Makes sense to involve companies that are running obs and studio? Do they will effectively be affected?
[1] http://pt.wikipedia.org/wiki/Venda_casada
CarlosRibeiro
I don't know about other parts of the world, but in the USA there is only one *customer* that has the power to modify vendors' behavior - the US Federal Government. Only if the Feds refuse to purchase "UEFI-crippled" devices will vendors stop shipping them and re-tool.
On Tue, 12 Jun 2012 15:28:32 -0700, M. Edward (Ed) Borasky wrote:
I don't know about other parts of the world, but in the USA there is only one *customer* that has the power to modify vendors' behavior - the US Federal Government.
Not strictly true, try being a vendor to Walmart. ;)
Jim
-
Administrator -
Andreas Jaeger -
Andrew Joakimsen -
Basil Chupin -
Bruno Friedmann -
Bryen M Yunashko -
C -
Carlos E. R. -
Carlos E. R. -
Carlos Ribeiro -
Chris Jones -
Christian Hueller -
Frederic Crozat -
Graham Anderson -
Jim Henderson -
Jos Poortvliet -
Larry Finger -
M. Edward (Ed) Borasky -
Malcolm -
Marcus Meissner -
Michael Chang -
Michal Kubeček -
oldcpu -
Pascal Bleser -
Patrick Shanahan -
Per Jessen -
Ricardo Chung -
Ricardo Chung -
Steven Hess