On Wed, Jun 27, 2012 at 07:13:22PM +1000, Basil Chupin wrote:
On 26/06/12 16:56, Tim Serong wrote:
On 06/26/2012 04:43 PM, Basil Chupin wrote:
On 26/06/12 15:13, M. Edward (Ed) Borasky wrote:
On Mon, Jun 25, 2012 at 9:01 PM, Michael Chang
wrote:
[snip]
Is this "uefi" thingie mean that *EVERY* piece of software which is to be installed on a system will require to be '"uefi"-compliant' before it will be installable so that the OS can be booted/rebooted with this piece of software installed?
It's not uefi, but microsoft windows 8 logo requirement program. The technology itself is neutral and if used properly, it could benefit people who really wants it. However Microsoft renders it to "restricted boot" is not a problem of uefi, I would consider it as victim since many peopler mis-understand it. :) Basil, you would be interested in looking this "Free Software Foundation recommendations for free operating system distributions considering Secure Boot " https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web The recommanded solution for operation system in terms of supporting uefi secureboot. == 1) fully supporting user-generated keys, including providing tools and full documentation for booting and installing both modified and official versions of the distribution using this method; 2) using a GPLv3-covered bootloader to help protect users against the dangers of Restricted Boot; 3) avoiding requiring or encouraging users to trust Microsoft or any company which makes proprietary software; and 4) joining the FSF and the broader free software movement in pressuring computer distributors to facilitate easy and independent installation of free software operating systems on any computer. == Apparently the recommendations did not encourage free distribution to adopt neither Fedora nor Ubuntu's process, each has it's own defect in FSF's point of view. I could say the real situration is much *worse* than what FSF's comprehend. And that's why free distribution are struggling in figurint out solution that could circumvent the situration. We can't change it and we see no light. :( 1) is simply not possible for now. As user-generated key means the chain-of-trust rooted on user (otherwise it's exploitable) but not OEM manufacturer. OEM support it means it can't satisfy microsoft logo requirement. And I also don't think for consumer product OEM would like to ship this feature because it's real need is few, and it's really big burden for them, for example, in terms of support user and in inventing their new factory|production process. (As I know the platform key is enrolled during production process ( to make sure it's secure .. lol) and it's one-way-only to turn from setup mode to user mode, it can turn back to setup mode unless you refresh your rom entirely 2) Per FSF's suggestion free distribution did not have to be in charge of the responsibilty of gplv3, it's hardware manufacturer as they are the distributer of software. Even though this is true, we still can't use grub2 because *OEM manufacturer will request to not to use gplv3 loader, as they don't want to expose on potential law suit either". Otherwise they will not accept your key .. quite irony fate to us. 3) Not possible, in current situration Microsoft Key is common in all firmware and that's the major reason why OEM are working to support secure boot => To get a Windows key in their machine that could run Win 8. 4) yes. :) Regards, Michael
If not, then what is the good of going thru this "uefi" saga just to be able to boot the *operating* *system* - but then allow later/subsequent upgrades/updates to be installed without them being "uefi-compliant"? Or is every piece of software going to be thoroughly examined as a separate exercise to ensure that it contains no malware before it gets included as part of, say, openSUSE update/upgrade?
BC
-- Using openSUSE 12.2 x86_64 KDE 4.8.4 and kernel 3.4.3 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
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org