UEFI Secure Boot
Hi, according to distrowatch.com: FreeBSD developer Marshall Mickusick told IT Wire that the FreeBSD team would probably follow in the footsteps of cutting-edge Linux distributions. Indeed we will likely take the Linux shim loader, put our own key in it, and then ask Microsoft to sign it. Since Microsoft will have already vetted the shim loader code, we hope that there will be little trouble getting them to sign our version for us. http://www.itwire.com/business-it-news/open-source/60498-freebsd-begins-process-to-support-secure-boot I am just wondering why Linus Torvald is concerned about Microsoft's role ... http://www.zdnet.com/torvalds-clarifies-linuxs-windows-8-secure-boot-position-711918/ I hope FreeBSD (and other OSs) luminaries, devs and users will find a way not to harm themselves. jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
Hello, You can call me naive, but until today, I could not find only a one user that wants to use FreeBSD and/or LInux AND windows in any machine I mount/sold, and I have mount it by the dozen, servers running FreeBSD, notebooks running a custom version of Arch Linux... In the freeBSD servers, when a user needs windows for some reason mainly access bank account or enterprise small business I use Virtualbox and I offer him NT2003 server (32 bits), windows 7(64) or windows XP(32). all work fine with a server running FreeBSD 9, 16GB of memory, 500GB of zfs mirrored disks. This small server, running on an AMD FX8120 (8cores) processor costs about U$600 and can hold 40 users running on the virtualbox NT 2003... without problem, and the FreeBSD part can hold gnome 2.32, pf, webserver, firewall, dhcp, printer server, scanner, wireless server, vpn, vlan, asterisk for telephony, even a cloud server running on top of apache using webdav... On the notebooks, the Arch linux runs like a charm, very fast integrated with the FreeBSD server. if a user needs access to the company software or bank software(that runs only on IE8) a rdesktop session is used (tsclient). Besides the FreeBSD does diskless stations too.. So the question: Why or when will I need an secure UEFI boot??? Thank you for ANY comment... Sergio ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
On Jul 8, 2013, at 3:24 PM, Sergio de Almeida Lenzi wrote: [snip] So the question: Why or when will I need an secure UEFI boot??? From what I've read of UEFI Secure boot, I've parceled out into these nuggets: (correct any nuggets I got wrong) 1. UEFI Secure boot is actually UEFI + Secure boot. You can disable Secure boot and still have UEFI. 2. Windows 8 requires UEFI Secure boot to ... boot. 3. Any OS can work with UEFI Secure boot... you just have to sign your drivers (which puts a burden on development, testing, etc.) 4. FreeBSD today can work on a machine if you disable UEFI (implied disabling of Secure boot sub-feature) 5. FreeBSD could eventually support UEFI. 6. Don't know if we want to support secure-boot... but I think we should. It's really up to how the end-user wants FreeBSD to function. If they want FreeBSD to reject module-loads for custom-compiled modules, secure boot seems to be a way to go. But for me at least, I won't be enabling it (even if we support it). However, I know customers that might think it's a great idea (think financial institutions running FreeBSD on bare metal both as workstations and servers). Now, I must admit, when the conversation of UEFI and Secure boot starts turning toward involving M$, I get confused. To my understanding, it's a methodology to allow a customer to secure his/her box against root-kit. The OS does this by communicating with the UEFI framework the keys of modules to load. That's between the BIOS and the OS (whatever OS you may be running). -- Devin P.S. Again, correct me if I'm wrong on anything -- I'm still wrapping my head around this stuff too. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
On Mon, 08 Jul 2013 19:24:38 -0300 Sergio de Almeida Lenzi wrote: I could not find only a one user that wants to use FreeBSD and/or LInux AND windows Some people don't want to delete a preinstalled copy of Windows so they can buy another and install it in a virtual server. There are also fairly obvious reasons why one may want Windows to have direct access to the hardware. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/8/2013 6:28 PM, Teske, Devin wrote: On Jul 8, 2013, at 3:24 PM, Sergio de Almeida Lenzi wrote: [snip] So the question: Why or when will I need an secure UEFI boot??? From what I've read of UEFI Secure boot, I've parceled out into these nuggets: (correct any nuggets I got wrong) 1. UEFI Secure boot is actually UEFI + Secure boot. You can disable Secure boot and still have UEFI. 2. Windows 8 requires UEFI Secure boot to ... boot. Not entirely correct. Microsoft licensing requires UEFI Secure boot for PCs sold with preinstalled Win8 and the Windows 8 logo. Win8 itself boots and runs fine on legacy hardware without UEFI (and often outperforms XP or Win7 on the same hardware). But the real-world end result is the vast majority of future computers will be sold with UEFI secure boot enabled as the default. 3. Any OS can work with UEFI Secure boot... you just have to sign your drivers (which puts a burden on development, testing, etc.) 4. FreeBSD today can work on a machine if you disable UEFI (implied disabling of Secure boot sub-feature) 5. FreeBSD could eventually support UEFI. 6. Don't know if we want to support secure-boot... but I think we should. It's really up to how the end-user wants FreeBSD to function. If they want FreeBSD to reject module-loads for custom-compiled modules, secure boot seems to be a way to go. But for me at least, I won't be enabling it (even if we support it). However, I know customers that might think it's a great idea (think financial institutions running FreeBSD on bare metal both as workstations and servers). Now, I must admit, when the conversation of UEFI and Secure boot starts turning toward involving M$, I get confused. To my understanding, it's a methodology to allow a customer to secure his/her box against root-kit. The OS does this by communicating with the UEFI framework the keys of modules to load. That's between the BIOS and the OS (whatever OS you may be running). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR21sPAAoJEHIluGOd3V4FGmgH/2vcwWP5juy7txU7pS5oTPdA MXc29tAIpPcLuGILyFICKtjlZ3isINX8kwBA9xZKoSjiDSCng/I+90+dIjpukAt2 DwLuek6+7oC9dYaBDxobjhhoogw5txcKnqwVhC4LjpBdQMuTiJSIunQOOzqqEybU kvedi5nlmmso6GYVYEKLRS7NrbgMW9W+2TvwrYOcBJw3yTeN4XRcpk7rQRi/U0+/ oRqxy1W9z51T6sGdO5UrkdxQEcNT6UgJedIo/0QLNUPOPEzGbapqak1QCbDSpxDc G8GOPLZnSrTM/FnM8KMzFaM2C6yoMyJHqsCs4tsbu1sRGxpLbs3HUJF984HTRDw= =vozW -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/8/2013 6:28 PM, Teske, Devin wrote: Not entirely correct. Microsoft licensing requires UEFI Secure boot for PCs sold with preinstalled Win8 and the Windows 8 logo. Win8 itself boots and runs fine on legacy hardware without UEFI (and often outperforms XP or Win7 on the same hardware). But the real-world end result is the vast majority of future computers will be sold with UEFI secure boot enabled as the default. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR21sLAAoJEHIluGOd3V4FmG0H/3a8yfrZOs0hhZmD2koIOBks ELNfNqvktBICX+7lhHFVQM9i10LIHWR2Vgb+0BZSYavGQ+TmE6tds3iIprDXzGF9 fKO1OHsD/5rCWPraus9uOBoeLrD9wQMirB3JV9f5p0hNLHqtiWYr1p0wsC9/vDYN q92JINJe80Aqznq746JIbIEibmCDDjVTrTgDB2xidi3ZlkD6nN3RKNJ+DDnj/O19 sHDCmRU/Daw+3OisjaVwmaJpksPJxSmNxIlFqWlbZ8nMgjwbB/2YxkELVaRnLJZG rBSeyxiOA7Y1m9OLGRZXCeraFedk8ccE2JXDbv7OBR/mC7066PZkNq/bpjZjlEA= =ZZRj -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
On Mon, 8 Jul 2013 16:21:28 + (UTC), jb wrote: I hope FreeBSD (and other OSs) luminaries, devs and users will find a way not to harm themselves. A massive problem I (personally) have is that with Restricted Boot (this is what Secure Boot basically is) you are no longer able to _ignore_ MICROS~1 and their products. A restrictive boot loader mechanism that requires signed and confirmed keys, handled by a major offender of free decisions and a healthy market - no thanks. What prevents MICROS~1 from revoking keys of a possible competitor? Or from messing with the specs just that things start breaking? Don't get me wrong: I don't even argument that a mechanism where a competitor requires you to pay money to run _your_ software instead of _their_ software sounds horribly wrong. This approach will introduce a philosophical or even legal context to the technical problem. I see interesting chances in UEFI per se. It can be called a kind of micro-OS which can be rich on features that could also be useful. But history has shown that if such an infrastructure is provided, it will lead to bloated, insecure and incompatible implementations quickly, and the worst, it will happen at a very low level. This is simly dangerous. Regarding UEFI + Restricted Boot: To obtain MICROS~1's sticker of approval for hardware, vendors need to implement those features. Even worse, on _specific_ platforms, they are not allowed to make it possible to _remove_ those features, so on by default is required - if I remember correctly (Intel vs. ARM architectures). As you see, I try to ignore this whole topic as I am not interested in using it. In the past, this has been possible. When building a new system, buying a blank disk and _no_ Windows was particularly easy. For systems that already came with some Windows preinstalled, simply deleting the partition was a solution; install FreeBSD boot mechanism, initialize disk, and be done. No more dealing with what MICROS~1 seems to insist is normal. When _their_ product decisions make _me_ invest time to find a way to remove and ignore them, I feel offended. I would like to see a way UEFI hardware, with or without Restricted Boot, can be used with FreeBSD _without_ involving the good will of MICROS~1. But as they have already gotten their fingers everywhere, this doesn't seem to happen all too soon... :-( -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
On Tue, 9 Jul 2013 02:31:40 +0200 Polytropon free...@edvax.de wrote: On Mon, 8 Jul 2013 16:21:28 + (UTC), jb wrote: I hope FreeBSD (and other OSs) luminaries, devs and users will find a way not to harm themselves. A massive problem I (personally) have is that with Restricted Boot (this is what Secure Boot basically is) you are no longer able to _ignore_ MICROS~1 and their products. A restrictive boot loader mechanism that requires signed and confirmed keys, handled by a major offender of free decisions and a healthy market - no thanks. What prevents MICROS~1 from revoking keys of a possible competitor? Or from messing with the specs just that things start breaking? Don't get me wrong: I don't even argument that a mechanism where a competitor requires you to pay money to run _your_ software instead of _their_ software sounds horribly wrong. This approach will introduce a philosophical or even legal context to the technical problem. I see interesting chances in UEFI per se. It can be called a kind of micro-OS which can be rich on features that could also be useful. But history has shown that if such an infrastructure is provided, it will lead to bloated, insecure and incompatible implementations quickly, and the worst, it will happen at a very low level. This is simly dangerous. Regarding UEFI + Restricted Boot: To obtain MICROS~1's sticker of approval for hardware, vendors need to implement those features. Even worse, on _specific_ platforms, they are not allowed to make it possible to _remove_ those features, so on by default is required - if I remember correctly (Intel vs. ARM architectures). As you see, I try to ignore this whole topic as I am not interested in using it. In the past, this has been possible. When building a new system, buying a blank disk and _no_ Windows was particularly easy. For systems that already came with some Windows preinstalled, simply deleting the partition was a solution; install FreeBSD boot mechanism, initialize disk, and be done. No more dealing with what MICROS~1 seems to insist is normal. When _their_ product decisions make _me_ invest time to find a way to remove and ignore them, I feel offended. I would like to see a way UEFI hardware, with or without Restricted Boot, can be used with FreeBSD _without_ involving the good will of MICROS~1. But as they have already gotten their fingers everywhere, this doesn't seem to happen all too soon... :-( -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org If I have understood correctly, it is quite easy to disable secure boot on most current machines; it is just an option in the UEFI setup. The real danger is machines where it cannot be disabled. This includes some recent HP machines; whether by design or incompetence I cannot say. These are the real danger to non-Microsoft operating systems, and the free software movement needs to fight tooth and nail against them. I can all too easily see them proliferating in the marketplace, perhaps secretly 'encouraged' by Microsoft. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
Mike Jeays mike.jeays at rogers.com writes: On Tue, 9 Jul 2013 02:31:40 +0200 Polytropon freebsd at edvax.de wrote: On Mon, 8 Jul 2013 16:21:28 + (UTC), jb wrote: I hope FreeBSD (and other OSs) luminaries, devs and users will find a way not to harm themselves. A massive problem I (personally) have is that with Restricted Boot (this is what Secure Boot basically is) you are no longer able to _ignore_ MICROS~1 and their products. A restrictive boot loader mechanism that requires signed and confirmed keys, handled by a major offender of free decisions and a healthy market - no thanks. What prevents MICROS~1 from revoking keys of a possible competitor? Or from messing with the specs just that things start breaking? ... If I have understood correctly, it is quite easy to disable secure boot on most current machines; it is just an option in the UEFI setup. The real danger is machines where it cannot be disabled. This includes some recent HP machines; whether by design or incompetence I cannot say. As readers on distrowatch.com put it regarding Secure Boot: Secure Boot can be turned off completely or, custom mode entered and other keys added if so desired thus avoiding the need to deal with Microsoft. Although it does add extra steps to installing a Linux or BSD system it's not that difficult to deal with and Secure Boot is part of the UEFI specifications, not Microsoft's. In some cases Secure Boot CANNOT be turned off completely, and in other cases Secure Boot may be desired. In theses cases, an independent authority should be signing the key, NOT Microsoft. We shouldn't have to forgo the use of Secure Boot to avoid dealing with Microsoft. It deeply disturbs me that Linux and BSD projects must grovel before Microsoft to get their key signed to be allowed to install their OS. Why should MS have such power? There should be an independent entity to handle this. jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot
On Mon, Jul 8, 2013 at 8:31 PM, Polytropon free...@edvax.de wrote: On Mon, 8 Jul 2013 16:21:28 + (UTC), jb wrote: I hope FreeBSD (and other OSs) luminaries, devs and users will find a way not to harm themselves. A massive problem I (personally) have is that with Restricted Boot (this is what Secure Boot basically is) you are no longer able to _ignore_ MICROS~1 and their products. A restrictive boot loader mechanism that requires signed and confirmed keys, handled by a major offender of free decisions and a healthy market - no thanks. What prevents MICROS~1 from revoking keys of a possible competitor? Or from messing with the specs just that things start breaking? Don't get me wrong: I don't even argument that a mechanism where a competitor requires you to pay money to run _your_ software instead of _their_ software sounds horribly wrong. This approach will introduce a philosophical or even legal context to the technical problem. I see interesting chances in UEFI per se. It can be called a kind of micro-OS which can be rich on features that could also be useful. But history has shown that if such an infrastructure is provided, it will lead to bloated, insecure and incompatible implementations quickly, and the worst, it will happen at a very low level. This is simly dangerous. Regarding UEFI + Restricted Boot: To obtain MICROS~1's sticker of approval for hardware, vendors need to implement those features. Even worse, on _specific_ platforms, they are not allowed to make it possible to _remove_ those features, so on by default is required - if I remember correctly (Intel vs. ARM architectures). As you see, I try to ignore this whole topic as I am not interested in using it. In the past, this has been possible. When building a new system, buying a blank disk and _no_ Windows was particularly easy. For systems that already came with some Windows preinstalled, simply deleting the partition was a solution; install FreeBSD boot mechanism, initialize disk, and be done. No more dealing with what MICROS~1 seems to insist is normal. When _their_ product decisions make _me_ invest time to find a way to remove and ignore them, I feel offended. I would like to see a way UEFI hardware, with or without Restricted Boot, can be used with FreeBSD _without_ involving the good will of MICROS~1. But as they have already gotten their fingers everywhere, this doesn't seem to happen all too soon... :-( -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... To assume that UEFI with some magic numbers is a security provider with current hardware is only a day dream . Consider stolen security signing keys and other by-passing mechanisms . For me , I think , over time there will exist free , but really free operating systems which they are not enslaved themselves to some companies , and hardware ( mainly main boards ) which will not require such enslaving . Then , to do task is just plainly to switch to such hardware and software . Personally , I will never want to live under a restriction tried to be enforced by a company and blindly accepted by its followers . I think I am not the only one in the world . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
Any server manufacturer who chooses to only support MS products is going to find they don't get much business from the academic market. such behaviour is even more stupid today as globally PC market is shrinking. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
Hi Cordula, Good points you made. The sooner it's blocked the easier to block. *BSD, + *Linux, Solaris etc people could start contacting their local anti monopoly / anti free trade, government departments to give them time to look into the issues. If eg EU commision found it a monopolist conspiracy, imposed swingeing fines like on Microsoft last time, that could persuade Asian mainboard manufacturers not to monopolise with Microsoft. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
On Fri, Jun 15, 2012 at 12:23 AM, C. P. Ghost cpgh...@cordula.ws wrote: Only if they fully follow the spec. This is rather unlikely. Even today, there are still many broken DMI/SMBIOS tables out there that contain barely enough stuff for Windows to boot successfully. What makes you think UEFI BIOS makers will go all the trouble to implement such a complex spec, if all they have to do is to ensure compliance with MS requirements? I wouldn't count on an option or switch to override this system. Any server manufacturer who chooses to only support MS products is going to find they don't get much business from the academic market. So I suspect this may crop up on some desktop machines and laptops, but most servers will probably allow installing whatever OS you like. And the market will probably reject even desktop machines with this problem quickly, just like it quickly forced manufacturers to add a way to turn off Intel's CPU ID feature when it became a privacy concern. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
grarpamp writes: Plenty of millionaires out there now who are in tune with opensource who could startup, buy the same ARM/ATOM/etc chips, the same support chips, load Android and sell it to the masses. Would you please post a list of these millionaire FLOSS entrepreneurs? Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
On Sat, Jun 9, 2012 at 12:17 AM, grarpamp grarp...@gmail.com wrote: I did say effectively. If people would actually read that chapter in the spec (minimally 27.5) they would find that they can: - Load a new PK without asking if in default SetupMode - If not in SetupMode, chainload a new PK provided it is signed by the current PK. - Clear the PK in a 'secure platform specific method'. Only if they fully follow the spec. This is rather unlikely. Even today, there are still many broken DMI/SMBIOS tables out there that contain barely enough stuff for Windows to boot successfully. What makes you think UEFI BIOS makers will go all the trouble to implement such a complex spec, if all they have to do is to ensure compliance with MS requirements? I wouldn't count on an option or switch to override this system. Technically, we may very well have to replace the BIOS, or even the BIOS chip itself (that'll be fun if it is physically mounted on the board!), and replace it with a chip flashed with a free BIOS. And by then, the corps who are responsible for this UEFI mess will have made it illegal to 1. tinker with your own hardware, as it would be DRM circumvention and 2. implement a free UEFI BIOS as it would violate some UEFI patents. Basically, we may end up in a situation where running FreeBSD on a modified motherboard could be outright illegal. Which is exactly the point, isn't it? -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
grarpamp wrote: Isn't there a lot of needless handwaving going on when the spec is pretty clear that installing your own complete PKI tree will all boil down to what is effectively a jumper on the motherboard? The hope for a jumper is insufficient. Cracking open laptops is no fun. It's not often that they unscrew easily; usually considerable fear of breaking innards or chassis. Hoping a jumper Might be under an easily unscrewable panel seems unlikely. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
Isn't there a lot of needless handwaving going on when the spec is pretty clear that installing your own complete PKI tree will all boil down to what is effectively a jumper on the motherboard? Hoping a jumper Might be under an easily unscrewable panel seems unlikely. I did say effectively. If people would actually read that chapter in the spec (minimally 27.5) they would find that they can: - Load a new PK without asking if in default SetupMode - If not in SetupMode, chainload a new PK provided it is signed by the current PK. - Clear the PK in a 'secure platform specific method'. There's nothing that says PK SetupMode has to be a jumper. Entering the equivalent of good old pre-boot BIOS setup mode would work so long as the OS can't get to it without the request being signed by the current PK. The point of Secure Boot is firmware checked protection against software access... not physical access protection. The spec speaks liberally of 'platform owner' being able to do whatever they want. More handwaving about EULA's and branding aside, that means US. I seriously think that people are blowing this topic way out of context, and seeing it everywhere is getting really old. People should instead be working on the facts and writing the various motherboard manufacturers to ask them what their expected PK update model will be, and to educate them if not. And to work at committing it to their OS. And yes, that includes Compal and Quanta and those sorts of OEM laptop/embedded makers. I'll send $100 to the FreeBSD foundation if those retail board makers I listed don't give the option to install/replace the PK. Nuff said. ps: I don't really care what MS does with their own branded products in the embedded/small space. Plenty of millionaires out there now who are in tune with opensource who could startup, buy the same ARM/ATOM/etc chips, the same support chips, load Android and sell it to the masses. Lot's of overseas ODM's out there for them to pick from too. Phones, tablets, notebooks, laptops... it's all there. FreeBSD on your phone in 10 years. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
Isn't there a lot of needless handwaving going on when the spec is pretty clear that installing your own complete PKI tree will all boil down to what is effectively a jumper on the motherboard? No, considering 99.99% of of current Windows victims can't even install a fresh copy of Windows. Users could fully utilize the UEFI Secure Boot hardware by say: - Using openssl to generate their keys - Jumper the board, burn it into the BIOS in UEFI SB SetupMode - Have all the MBR, slice, partition, installkernel, etc tools install and manage the signed disk/loader/kernel/module bits - Have the BIOS check sigs on whatever first comes off the media Yeah that's trivial for 99.99% of users. I have no idea what everyone is on about. I just program my own PROM and make my own motherboards. Now back to reality, most people don't know how to use openssl. They don't want to break the seal on their PC and void the warranty. They don't want to play with jumpers. They don't know how to use Linux fdisk or BSD disklabel. They can't set up their BIOS. They may not be the typical BSD or Linux poweruser but they represent most users. And sadly even a significant percentage of BSD and even a more significant percentage of Linux users (thank you Ubuntu) aren't capable of doing these things. And if they really were that dumb, there's Gigabyte, Asus, Msi, Supermicro, Biostar, etc who will not be so dumb and will soak up all the remaining sales gravy. We're going to see if that happens but it won't. The WinTel Mafia controls more than what you think and these vendors know they get many magnitudes more money from selling Windows commodity shitboxes than they ever will from all the BSD and Linux users multiplied together. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
UEFI Secure Boot Specs - And some sanity
Isn't there a lot of needless handwaving going on when the spec is pretty clear that installing your own complete PKI tree will all boil down to what is effectively a jumper on the motherboard? First, some sanity... Users could fully utilize the UEFI Secure Boot hardware by say: - Using openssl to generate their keys - Jumper the board, burn it into the BIOS in UEFI SB SetupMode - Have all the MBR, slice, partition, installkernel, etc tools install and manage the signed disk/loader/kernel/module bits - Have the BIOS check sigs on whatever first comes off the media I don't see that the user will actually NOT be able to do this on anything but 'designed for windows only' ARM systems. Seeing how open Android/Linux is firmly in that space, this will just devalue the non open windows product. There have been 25 years of generic mass produced motherboards. And 25 years of open source OS commits to utilize them. That is not changing anytime soon. Non generic attempts fail. Even corporate kings Dell and HP know they would be foolish to sell motherboards that will not allow their buyers to swap out the PK keys... because they know their buyers run more than just windows and that they need various security models. And if they really were that dumb, there's Gigabyte, Asus, Msi, Supermicro, Biostar, etc who will not be so dumb and will soak up all the remaining sales gravy. The masses have seen and now want openness, open systems, sharing. The old models are but speed bumps on their own way out the door. Though it seems a non issue to me, if you want to protest, protest for 'Setup Mode'. And not here on this list, but to the hardware makers. We should want to use this PKI in our systems. Not disable it. Not pay $100 to terminate the PKI chain early. Not pay $100 to lock us into unmodifiable releases (aka: BSD corporate version). I look forward to seeing the UEFI SB PK SetupMode AMD and Intel generic motherboard list :) On to facts... http://www.uefi.org/ Spec Chapter 27 Secure Boot, SetupMode, PK, Shell, etc https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface https://en.wikipedia.org/wiki/Unified_EFI_Forum http://ozlabs.org/docs/uefi-secure-boot-impact-on-linux.pdf https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot http://mjg59.dreamwidth.org/12368.html http://mjg59.livejournal.com/ https://www.tianocore.org/ http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=962584 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UEFI Secure Boot Specs - And some sanity
Thank you for this. I didn't realize that a simple (somewhat technical) question asked in all innocence would generate so much flammage. Kurt On Wed, Jun 6, 2012 at 1:13 PM, grarpamp grarp...@gmail.com wrote: Isn't there a lot of needless handwaving going on when the spec is pretty clear that installing your own complete PKI tree will all boil down to what is effectively a jumper on the motherboard? First, some sanity... Users could fully utilize the UEFI Secure Boot hardware by say: - Using openssl to generate their keys - Jumper the board, burn it into the BIOS in UEFI SB SetupMode - Have all the MBR, slice, partition, installkernel, etc tools install and manage the signed disk/loader/kernel/module bits - Have the BIOS check sigs on whatever first comes off the media I don't see that the user will actually NOT be able to do this on anything but 'designed for windows only' ARM systems. Seeing how open Android/Linux is firmly in that space, this will just devalue the non open windows product. There have been 25 years of generic mass produced motherboards. And 25 years of open source OS commits to utilize them. That is not changing anytime soon. Non generic attempts fail. Even corporate kings Dell and HP know they would be foolish to sell motherboards that will not allow their buyers to swap out the PK keys... because they know their buyers run more than just windows and that they need various security models. And if they really were that dumb, there's Gigabyte, Asus, Msi, Supermicro, Biostar, etc who will not be so dumb and will soak up all the remaining sales gravy. The masses have seen and now want openness, open systems, sharing. The old models are but speed bumps on their own way out the door. Though it seems a non issue to me, if you want to protest, protest for 'Setup Mode'. And not here on this list, but to the hardware makers. We should want to use this PKI in our systems. Not disable it. Not pay $100 to terminate the PKI chain early. Not pay $100 to lock us into unmodifiable releases (aka: BSD corporate version). I look forward to seeing the UEFI SB PK SetupMode AMD and Intel generic motherboard list :) On to facts... http://www.uefi.org/ Spec Chapter 27 Secure Boot, SetupMode, PK, Shell, etc https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface https://en.wikipedia.org/wiki/Unified_EFI_Forum http://ozlabs.org/docs/uefi-secure-boot-impact-on-linux.pdf https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot http://mjg59.dreamwidth.org/12368.html http://mjg59.livejournal.com/ https://www.tianocore.org/ http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=962584 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
