Re: [gentoo-dev] borked release media
Greg KH schrieb: On Mon, Dec 10, 2012 at 12:21:29AM +0100, Chí-Thanh Christopher Nguyễn wrote: Greg KH schrieb: No, all we need is to enable EFI stub support in the kernel, and integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in some location where UEFI looks for it (/efi/boot/bootx64.efi). This has the disadvantage of not allowing to pass additional kernel parameters during boot. But it might still be an acceptable stopgap measure if the alternative is to not boot at all. No, don't do that for an install kernel, that way is madness, just use a real UEFI bootloader which can handle an initrd and the like properly Can you explain what problems you see with that? How does CONFIG_INITRAMFS_SOURCE handle initrd improperly? Ah, didn't notice that, it might work, have you tried it? Yes, it works here. This is the kernel which I used to boot my development box at work (including genkernel initramfs for mdraid+luks+lvm): http://dev.gentoo.org/~chithanh/efi/boot/bootx64.efi It has hardcoded crypt_root and real_root via CONFIG_CMDLINE, and initramfs executables are built with -march=bdver2 so this particular file will probably not be useful to many people. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 2:52 AM, Rich Freeman ri...@gentoo.org wrote: I really would like Gentoo to support a self-signed secure boot framework (obviously this would be for after the system is installed). https://bugs.gentoo.org/show_bug.cgi?id=444830 You can see how such framework works by booting Liberté Linux 2012.3 on a machine with Secure Boot. Just extract the .zip file into USB key root (or burn the .iso to CD), and import EFI/Liberte-SecureBoot-CA.der certificate in UEFI Secure Boot interface: http://dee.su/liberte-install (see “Secure Boot” section). The shim might work, but I'd hardly call it secure boot if every motherboard manufacturer and OEM in the world has the ability to sign things, even if MS vouched for them all. I think there are some popular misunderstanding about the purpose of shim. What shim essentially allows a user to do is to enroll custom certificates into Secure Boot databases in an interactive, user-friendly fashion (caveat emptor: I didn't try shim yet). It does some clever UEFI API interaction and management of certificates in protected variables, but the effect is identical to enrolling a certificate into DB or KEK (OVMF names) via UEFI interface. Being signed by MS is just a technical way to achieve that user friendliness. So personally, I don't think that rushing to support shim in Gentoo is that critical, since users can be expected to enroll certificates by themselves. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] borked release media
On Sat, Dec 08, 2012 at 11:57:13PM -0500, Fernando Reyes wrote iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO # did if=image.ISO of=/dev/sdb bs=8192k sdb being your removable device. Also keep in mind that any data on sdb will be wiped after running the dd command. Thanks. Much easier than the instructions on the Gentoo wiki. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 06:37:56PM -0800, Greg KH wrote Not necessarily, as I'm finding out with real hardware. My only options on the box I have is to either zero out all keys, or specifically tell the BIOS what binary to run (doesn't need to be signed, and can not be changed after telling the BIOS to use it.) Howsabout the binary being Matthew Garret's chainloader shim as per http://mjg59.dreamwidth.org/20303.html I'm working with others to see if we can programatically add keys, which we should, and if so we will offer the code up to do so (it's published already, we are working on getting it signed by the needed Microsoft keys right now.) He's already done the heavy lifting. Aren't you re-inventing the wheel? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 10:31:25AM -0500, Walter Dnes wrote: On Sun, Dec 09, 2012 at 06:37:56PM -0800, Greg KH wrote Not necessarily, as I'm finding out with real hardware. My only options on the box I have is to either zero out all keys, or specifically tell the BIOS what binary to run (doesn't need to be signed, and can not be changed after telling the BIOS to use it.) Howsabout the binary being Matthew Garret's chainloader shim as per http://mjg59.dreamwidth.org/20303.html That's a nice one, but note my previous comment about a bug in it at the moment that prevents it from working on some hardware. It's also a valid solution for some implementations, have you tried it yourself? I'm working with others to see if we can programatically add keys, which we should, and if so we will offer the code up to do so (it's published already, we are working on getting it signed by the needed Microsoft keys right now.) He's already done the heavy lifting. Aren't you re-inventing the wheel? Not at all, we are sharing the same code base here, just two different frontend implementations that do different things, with the same crypto backend and local (MOK) key checking functionality, which was done by SUSE. Matthew's frontend shim code is nice and tiny, but the one I am referring to provides the ability to enroll your own keys in the BIOS, which shim does not. Don't worry, we are all working together here, it's not like there is a ton of people involved :) greg there is no cabal k-h
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 8:36 PM, Greg KH gre...@gentoo.org wrote: Matthew's frontend shim code is nice and tiny, but the one I am referring to provides the ability to enroll your own keys in the BIOS, which shim does not. I just tried shim in OVMF, and it provides an interface to enroll keys / signatures. It works as advertised, even after enrolling “Microsoft Corporation UEFI CA 2011” certificate into UEFI (instead of shim.efi hash), which is supposedly trusted by vendors, but the keys and signatures are only visible to shim — as I understand, it keeps them in authenticated variables. I don't think the difference matters much to the user. By the way, shim's interface is not much prettier than the one provided by OVMF — I am a bit disappointed. :) -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] borked release media
On 9 December 2012 05:04, Peter Stuge pe...@stuge.se wrote: Fernando Reyes wrote: iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2 target in a nice way, and file a bug with updated ebuilds for catalyst which add the dependency. Many thanks! //Peter I think it is possible to use the unetbootin utility to make the minimal iso image boot from a USB flash disk. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 11:18 AM, Markos Chandras hwoar...@gentoo.org wrote: I think it is possible to use the unetbootin utility to make the minimal iso image boot from a USB flash disk. Just make the real thing… https://github.com/mkdesu/liberte/blob/master/src/root/mkimage -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] borked release media
Peter Stuge schrieb: Fernando Reyes wrote: iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2 target in a nice way, and file a bug with updated ebuilds for catalyst which add the dependency. Bug was already reported some time ago https://bugs.gentoo.org/show_bug.cgi?id=251719 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
Fernando Reyes schrieb: The problem with the isohybrid approach is that it doesn't support UEFI booting and this is why I wouldn't recommended as a feature in catalyst. However, this should be documented somewhere so that users know its possible without having to follow the liveusb guide which is probably outdated by today's standards. isohybrid works with UEFI by passing --uefi option. This requires a UEFI bootable image (such as a UEFI capable boot loader or kernel with EFI stub support) to be present. Starting with syslinux-6.00 it will be possible to boot UEFI systems in EFI mode. Until then, one of the other boot loaders (rEFIt, GRUB 2, ELILO) might be used. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios. Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Fernando Reyes schrieb: The problem with the isohybrid approach is that it doesn't support UEFI booting and this is why I wouldn't recommended as a feature in catalyst. However, this should be documented somewhere so that users know its possible without having to follow the liveusb guide which is probably outdated by today's standards. isohybrid works with UEFI by passing --uefi option. This requires a UEFI bootable image (such as a UEFI capable boot loader or kernel with EFI stub support) to be present. Starting with syslinux-6.00 it will be possible to boot UEFI systems in EFI mode. Until then, one of the other boot loaders (rEFIt, GRUB 2, ELILO) might be used. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 12:23 PM, Fernando Reyes likew...@weboperative.com wrote: grub seems out of the questions because of licensing issues. What licensing issues? Just distribute the source. If the Gentoo Foundation goes into the hardware business and starts distributing hardware that only boots Gentoo-signed grub bootloaders then we'll have to distribute our private key. Or we could just be intelligent and not distribute hardware that only boots Gentoo-signed grub bootloaders. For some reason everybody goes nuts over UEFI and GPLv3. The license isn't any more unclear about that than anything else that people go nuts over the GPL about. GPLv3 states: If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. You only need to provide installation information if the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term. So, as long as Gentoo doesn't distribute hardware, we aren't bound by that clause. If somebody else distributes hardware that only boots Gentoo-signed GRUB bootloaders then they'll need to distribute the Gentoo private keys along with them or they can be sued by the Grub copyright holders. If they ask us for said keys we'll just say no, and they can fight it out with the FSF. We aren't the ones distributing Grub out of compliance, so we haven't violated the license. If somebody has a specific licensing-related concern we can always have the Foundation/ licensing team look into it, as we are already doing with the copyright attribution question. Rich
Re: [gentoo-dev] borked release media
I don't know the details of the issue but I know that I was prevented from using grub on the livedvd. Rich Freeman ri...@gentoo.org wrote: On Sun, Dec 9, 2012 at 12:23 PM, Fernando Reyes likew...@weboperative.com wrote: grub seems out of the questions because of licensing issues. What licensing issues? Just distribute the source. If the Gentoo Foundation goes into the hardware business and starts distributing hardware that only boots Gentoo-signed grub bootloaders then we'll have to distribute our private key. Or we could just be intelligent and not distribute hardware that only boots Gentoo-signed grub bootloaders. For some reason everybody goes nuts over UEFI and GPLv3. The license isn't any more unclear about that than anything else that people go nuts over the GPL about. GPLv3 states: If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. You only need to provide installation information if the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term. So, as long as Gentoo doesn't distribute hardware, we aren't bound by that clause. If somebody else distributes hardware that only boots Gentoo-signed GRUB bootloaders then they'll need to distribute the Gentoo private keys along with them or they can be sued by the Grub copyright holders. If they ask us for said keys we'll just say no, and they can fight it out with the FSF. We aren't the ones distributing Grub out of compliance, so we haven't violated the license. If somebody has a specific licensing-related concern we can always have the Foundation/ licensing team look into it, as we are already doing with the copyright attribution question. Rich
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes likew...@weboperative.com wrote: I don't know the details of the issue but I know that I was prevented from using grub on the livedvd. Well, if some perceived legal constraint is keeping us from doing whatever seems to be technically most appropriate we should investigate the matter and resolve it. If, on the other hand, it simply makes sense to use something else, then no sense belaboring the point. People just seem to be really paranoid about GPLv3 and Grub. We're already talking to the FSF about how they handle copyright attribution on their own projects, so I suppose we could get their opinion on UEFI as well. However, I don't see anything in the language of the license that creates a problem when using it with UEFI, unless one wants to sell locked-down hardware. Doing that would be a violation of our social contract, let alone the GPLv3. Rich
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 01:13:38PM -0500, Rich Freeman wrote: On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes likew...@weboperative.com wrote: I don't know the details of the issue but I know that I was prevented from using grub on the livedvd. Well, if some perceived legal constraint is keeping us from doing whatever seems to be technically most appropriate we should investigate the matter and resolve it. If, on the other hand, it simply makes sense to use something else, then no sense belaboring the point. People just seem to be really paranoid about GPLv3 and Grub. We're already talking to the FSF about how they handle copyright attribution on their own projects, so I suppose we could get their opinion on UEFI as well. However, I don't see anything in the language of the license that creates a problem when using it with UEFI, unless one wants to sell locked-down hardware. Doing that would be a violation of our social contract, let alone the GPLv3. The FSF has already said that using Grub2 and the GPLv3 is just fine with the UEFI method of booting, so there is no problem from that side. There's a statement about this somewhere on their site if you are curious. The only one objecting to GPLv3 and UEFI is the current rules for getting a shim/bootloader signed by Microsoft, but the current implementations we have all have either a GPLv2 or BSD licensed shim which then loads GRUB, so all is fine from a licensing and legal standpoint from everyone involved. Hope this helps, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 1:24 PM, Greg KH gre...@gentoo.org wrote: The FSF has already said that using Grub2 and the GPLv3 is just fine with the UEFI method of booting, so there is no problem from that side. There's a statement about this somewhere on their site if you are curious. The only one objecting to GPLv3 and UEFI is the current rules for getting a shim/bootloader signed by Microsoft, but the current implementations we have all have either a GPLv2 or BSD licensed shim which then loads GRUB, so all is fine from a licensing and legal standpoint from everyone involved. Makes sense to me, thanks. An MS-signed bootloader isn't nearly as critical for Gentoo as it is for other distros - we're not really aiming for the stick-a-CD-in-and-you're-done crowd. If somebody can partition their drive, build and install a kernel and grub, configure make.conf, and build a system, then I'm not too concerned that they have to run some script to generate a key, sign their bootloader, and register that key with their firmware, or disable secure boot just to boot the install CD (though it sounds like some firmwares just pop up a warning and let you proceed, which is what my Chromebook does in dev mode). Rich
Re: [gentoo-dev] borked release media
Fernando Reyes schrieb: That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios. No, all we need is to enable EFI stub support in the kernel, and integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in some location where UEFI looks for it (/efi/boot/bootx64.efi). This has the disadvantage of not allowing to pass additional kernel parameters during boot. But it might still be an acceptable stopgap measure if the alternative is to not boot at all. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
Then let's get UEFI support on our release media and out the box usb booting so users don't have to go boot other livecds. likewhoa Greg KH gre...@gentoo.org wrote: On Sun, Dec 09, 2012 at 01:13:38PM -0500, Rich Freeman wrote: On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes likew...@weboperative.com wrote: I don't know the details of the issue but I know that I was prevented from using grub on the livedvd. Well, if some perceived legal constraint is keeping us from doing whatever seems to be technically most appropriate we should investigate the matter and resolve it. If, on the other hand, it simply makes sense to use something else, then no sense belaboring the point. People just seem to be really paranoid about GPLv3 and Grub. We're already talking to the FSF about how they handle copyright attribution on their own projects, so I suppose we could get their opinion on UEFI as well. However, I don't see anything in the language of the license that creates a problem when using it with UEFI, unless one wants to sell locked-down hardware. Doing that would be a violation of our social contract, let alone the GPLv3. The FSF has already said that using Grub2 and the GPLv3 is just fine with the UEFI method of booting, so there is no problem from that side. There's a statement about this somewhere on their site if you are curious. The only one objecting to GPLv3 and UEFI is the current rules for getting a shim/bootloader signed by Microsoft, but the current implementations we have all have either a GPLv2 or BSD licensed shim which then loads GRUB, so all is fine from a licensing and legal standpoint from everyone involved. Hope this helps, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 07:46:59PM +0100, Chí-Thanh Christopher Nguyễn wrote: Fernando Reyes schrieb: That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios. No, all we need is to enable EFI stub support in the kernel, and integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in some location where UEFI looks for it (/efi/boot/bootx64.efi). This has the disadvantage of not allowing to pass additional kernel parameters during boot. But it might still be an acceptable stopgap measure if the alternative is to not boot at all. No, don't do that for an install kernel, that way is madness, just use a real UEFI bootloader which can handle an initrd and the like properly (like gummiboot, which arch is using for their UEFI bootloader, and I've been using for months quite successfully.) Only boot a kernel directly from UEFI if you build your own and have customized it for your hardware. Some bioses will let you do this in secure boot mode without having to sign anything, I took a video of this on Friday showing how easy it can be: https://plus.google.com/u/0/111049168280159033135/posts/81V5oyzwK63 thanks, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 01:35:57PM -0500, Rich Freeman wrote: On Sun, Dec 9, 2012 at 1:24 PM, Greg KH gre...@gentoo.org wrote: The FSF has already said that using Grub2 and the GPLv3 is just fine with the UEFI method of booting, so there is no problem from that side. There's a statement about this somewhere on their site if you are curious. The only one objecting to GPLv3 and UEFI is the current rules for getting a shim/bootloader signed by Microsoft, but the current implementations we have all have either a GPLv2 or BSD licensed shim which then loads GRUB, so all is fine from a licensing and legal standpoint from everyone involved. Makes sense to me, thanks. An MS-signed bootloader isn't nearly as critical for Gentoo as it is for other distros - we're not really aiming for the stick-a-CD-in-and-you're-done crowd. If somebody can partition their drive, build and install a kernel and grub, configure make.conf, and build a system, then I'm not too concerned that they have to run some script to generate a key, sign their bootloader, and register that key with their firmware, or disable secure boot just to boot the install CD (though it sounds like some firmwares just pop up a warning and let you proceed, which is what my Chromebook does in dev mode). The UEFI spec does not allow that mode of operation in secure boot mode, sorry. You will have to disable it in order to boot a Gentoo image, which is fine, but there's no reason why Gentoo can't use the MS-signed shim bootloader like all other distros are using, right? thanks, greg k-h
Re: [gentoo-dev] borked release media
On 12/09/2012 01:46 PM, Chí-Thanh Christopher Nguyễn wrote: Fernando Reyes schrieb: That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios. No, all we need is to enable EFI stub support in the kernel, and integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in some location where UEFI looks for it (/efi/boot/bootx64.efi). This has the disadvantage of not allowing to pass additional kernel parameters during boot. But it might still be an acceptable stopgap measure if the alternative is to not boot at all. Best regards, Chí-Thanh Christopher Nguyễn interesting and probably something we can get away with since not all users actually touch the kernel line but some do so it might not be a smart option to disable kernel parameters on UEFI only systems.
Re: [gentoo-dev] borked release media
Greg KH schrieb: No, all we need is to enable EFI stub support in the kernel, and integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in some location where UEFI looks for it (/efi/boot/bootx64.efi). This has the disadvantage of not allowing to pass additional kernel parameters during boot. But it might still be an acceptable stopgap measure if the alternative is to not boot at all. No, don't do that for an install kernel, that way is madness, just use a real UEFI bootloader which can handle an initrd and the like properly Can you explain what problems you see with that? How does CONFIG_INITRAMFS_SOURCE handle initrd improperly? Only boot a kernel directly from UEFI if you build your own and have customized it for your hardware. I booted genkernel generated non-customized kernels as well as customized hand-configured kernels using that method. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
likewhoa schrieb: interesting and probably something we can get away with since not all users actually touch the kernel line but some do so it might not be a smart option to disable kernel parameters on UEFI only systems. The kernel parameters are not disabled, they just have to be specified at build time instead of runtime. With a customized kernel you typically set CONFIG_CMDLINE=root=PARTUUID=... or similar. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
On 09/12/2012 19:59, Greg KH wrote: The UEFI spec does not allow that mode of operation in secure boot mode, sorry. You will have to disable it in order to boot a Gentoo image, which is fine, but there's no reason why Gentoo can't use the MS-signed shim bootloader like all other distros are using, right? I wouldn't say we have any problem with that. Fabio already got Sabayon to support the shim. The only problem is that we'd have to provide a shim binary that _is_ signed, rather than building it from source, but I don't see it as a mayor problem myself. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 7:24 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 09/12/2012 19:59, Greg KH wrote: The UEFI spec does not allow that mode of operation in secure boot mode, sorry. You will have to disable it in order to boot a Gentoo image, which is fine, but there's no reason why Gentoo can't use the MS-signed shim bootloader like all other distros are using, right? I thought I had read something in Google+ posted by somebody who mentioned that their firmware was doing exactly that. It may very well be prohibited by the spec though, in which case we shouldn't count on it. I wouldn't say we have any problem with that. Fabio already got Sabayon to support the shim. The only problem is that we'd have to provide a shim binary that _is_ signed, rather than building it from source, but I don't see it as a mayor problem myself. Agreed. We don't need to make our own shim either - we can just use one of the ones floating around. It should be open source, though obviously if anybody wants to build their own they'll need to get MS to sign it, or install the key in their firmware. I really would like Gentoo to support a self-signed secure boot framework (obviously this would be for after the system is installed). The shim might work, but I'd hardly call it secure boot if every motherboard manufacturer and OEM in the world has the ability to sign things, even if MS vouched for them all. Even if I installed Windows I'd want the ability to re-sign it with a key I controlled and tell the firmware to refuse to boot the MS key. But, we can learn to walk before we learn to run - anything that works with UEFI is a good first step. Oh, and for anybody who is really daring - you can have that kind of security even without UEFI. Just use Trusted Grub and enable TPM support in Linux, and then encrypt all but the boot partition with a key stored in the TPM that it only yields when the boot path is validated. Probably wouldn't hurt to stick a copy of the key on a flash drive or something just in case you update your kernel and forget to update the TPM. Rich
Re: [gentoo-dev] borked release media
On 10/12/2012 01:52, Rich Freeman wrote: The shim might work, but I'd hardly call it secure boot if every motherboard manufacturer and OEM in the world has the ability to sign things, even if MS vouched for them all. Even if I installed Windows I'd want the ability to re-sign it with a key I controlled and tell the firmware to refuse to boot the MS key. I don't think it's Gentoo's place to do that kind of stuff especially since I think you're in dreamland if you think that's achievable in _every_ case. It probably works in some cases, though. Oh, and for anybody who is really daring - you can have that kind of security even without UEFI. Just use Trusted Grub and enable TPM support in Linux, and then encrypt all but the boot partition with a key stored in the TPM that it only yields when the boot path is validated. From the comments I read from Matthew Garrett, this looks like it's going to be a world full of pain. Again I don't think we have to go there. Also the title of the threads is now completely misleading so let's stop here, k? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] borked release media
Chí-Thanh Christopher Nguyễn wrote: # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2 target in a nice way, and file a bug with updated ebuilds for catalyst which add the dependency. Bug was already reported some time ago https://bugs.gentoo.org/show_bug.cgi?id=251719 That bug doesn't complete the more important action item. It's nice that the isolinux cdtars include isohybrid, but please do patch livecd2 in a nice way to also use it. (Note, I don't know what would be nice, I haven't used catalyst for livecds.) //Peter
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 7:57 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 10/12/2012 01:52, Rich Freeman wrote: The shim might work, but I'd hardly call it secure boot if every motherboard manufacturer and OEM in the world has the ability to sign things, even if MS vouched for them all. Even if I installed Windows I'd want the ability to re-sign it with a key I controlled and tell the firmware to refuse to boot the MS key. I don't think it's Gentoo's place to do that kind of stuff especially since I think you're in dreamland if you think that's achievable in _every_ case. It probably works in some cases, though. Any Windows-logo-compliant firmware has to support changing the keys. I have no idea whether Windows itself supports this, but that really isn't our concern. In any case, nobody is forcing anybody to build in that support - I just think it is a good idea. I doubt it would be difficult to accomplish - it just requires signing the bootloader. But, if nobody wants to do it now I'll just deal with it when I buy something with UEFI firmware in a year or two. :) Oh, and for anybody who is really daring - you can have that kind of security even without UEFI. Just use Trusted Grub and enable TPM support in Linux, and then encrypt all but the boot partition with a key stored in the TPM that it only yields when the boot path is validated. From the comments I read from Matthew Garrett, this looks like it's going to be a world full of pain. Again I don't think we have to go there. Wasn't really suggesting that we go there - only that anybody who wants to do it is welcome to do so. There are even howtos floating around. I wasn't suggesting that Gentoo support TPM-based full-disk encryption - just UEFI. Rich
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 01:24:53AM +0100, Diego Elio Pettenò wrote: On 09/12/2012 19:59, Greg KH wrote: The UEFI spec does not allow that mode of operation in secure boot mode, sorry. You will have to disable it in order to boot a Gentoo image, which is fine, but there's no reason why Gentoo can't use the MS-signed shim bootloader like all other distros are using, right? I wouldn't say we have any problem with that. Fabio already got Sabayon to support the shim. The only problem is that we'd have to provide a shim binary that _is_ signed, rather than building it from source, but I don't see it as a mayor problem myself. I see the shim is checked into Sabayon, with my recent testing on real hardware, I think there's a bug in the existing shim binary that will keep it from working on most hardware, so it will need to be updated. Some of us are currently working with Microsoft to do that right now... But, if you have access to UEFI secure boot hardware, please test, it might work for you and if so, please let us know. thanks, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 07:52:16PM -0500, Rich Freeman wrote: On Sun, Dec 9, 2012 at 7:24 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 09/12/2012 19:59, Greg KH wrote: The UEFI spec does not allow that mode of operation in secure boot mode, sorry. You will have to disable it in order to boot a Gentoo image, which is fine, but there's no reason why Gentoo can't use the MS-signed shim bootloader like all other distros are using, right? I thought I had read something in Google+ posted by somebody who mentioned that their firmware was doing exactly that. It may very well be prohibited by the spec though, in which case we shouldn't count on it. I have not seen that at all, any pointers? Based on my interactions with the UEFI group, and Microsoft, that's either a bug that will be fixed up, or some misinformation. thanks, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 08:08:01PM -0500, Rich Freeman wrote: On Sun, Dec 9, 2012 at 7:57 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 10/12/2012 01:52, Rich Freeman wrote: The shim might work, but I'd hardly call it secure boot if every motherboard manufacturer and OEM in the world has the ability to sign things, even if MS vouched for them all. Even if I installed Windows I'd want the ability to re-sign it with a key I controlled and tell the firmware to refuse to boot the MS key. I don't think it's Gentoo's place to do that kind of stuff especially since I think you're in dreamland if you think that's achievable in _every_ case. It probably works in some cases, though. Any Windows-logo-compliant firmware has to support changing the keys. Not necessarily, as I'm finding out with real hardware. My only options on the box I have is to either zero out all keys, or specifically tell the BIOS what binary to run (doesn't need to be signed, and can not be changed after telling the BIOS to use it.) I'm working with others to see if we can programatically add keys, which we should, and if so we will offer the code up to do so (it's published already, we are working on getting it signed by the needed Microsoft keys right now.) thanks, greg k-h
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 12:21:29AM +0100, Chí-Thanh Christopher Nguyễn wrote: Greg KH schrieb: No, all we need is to enable EFI stub support in the kernel, and integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in some location where UEFI looks for it (/efi/boot/bootx64.efi). This has the disadvantage of not allowing to pass additional kernel parameters during boot. But it might still be an acceptable stopgap measure if the alternative is to not boot at all. No, don't do that for an install kernel, that way is madness, just use a real UEFI bootloader which can handle an initrd and the like properly Can you explain what problems you see with that? How does CONFIG_INITRAMFS_SOURCE handle initrd improperly? Ah, didn't notice that, it might work, have you tried it? greg k-h
Re: [gentoo-dev] borked release media
On Sat, Dec 8, 2012 at 12:25 AM, Matt Turner matts...@gentoo.org wrote: I have never once been able to grab a portage snapshot and build a stage 1, 2, 3 series from it without encountering at least a couple of problems with the tree. Ditto - the latest issue I've run into is: 443472. Probably won't impact the average user, and perhaps I should just modify the script to not bother reading that file and figure out what the latest build is on its own. I think we should consider things that break release media serious regressions. I don't know what that entails specifically, but whether it need be QA bashing down your door or a quick fix or revert, it sure would be nice to get Gentoo to a place where release media always works. Agreed. If a user can't just burn a CD and then do an emerge kde-meta there is a problem. In short, I think the conversation we should be having should be about how to avoid breaking release builds and how to quickly fix problems when they're discovered. I think those working with catalyst have the most to add regarding what breaks them. As far as detect-ability goes, do we need some kind of tinderbox that just does a daily build. Perhaps just build from stage3 to a couple of world targets, including one with some server-oriented software, one with gnome, and one with kde? I've reported a bunch of bugs with the EC2 bootstrap script described on my blog (not my original work), but it is only automated from a build perspective - testing is manual. That takes about 18 hours to build (with an emphasis on economy), and I use spot instances so it really only costs maybe a buck or two. My experience has been that if it builds it usually works. So, simply testing for whether the build completes is a pretty-good first step. Of course, for system packages our recourse isn't necessarily good, since we don't have a test branch or anything like that. If we wanted to revert we'd have to impact users who already upgraded. Obviously the goal would be to fix in place with a new revbump, assuming that were possible. Rich
Re: [gentoo-dev] borked release media
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2012 06:50 AM, Rich Freeman wrote: On Sat, Dec 8, 2012 at 12:25 AM, Matt Turner matts...@gentoo.org wrote: I have never once been able to grab a portage snapshot and build a stage 1, 2, 3 series from it without encountering at least a couple of problems with the tree. Ditto - the latest issue I've run into is: 443472. Probably won't impact the average user, and perhaps I should just modify the script to not bother reading that file and figure out what the latest build is on its own. I think we should consider things that break release media serious regressions. I don't know what that entails specifically, but whether it need be QA bashing down your door or a quick fix or revert, it sure would be nice to get Gentoo to a place where release media always works. Agreed. If a user can't just burn a CD and then do an emerge kde-meta there is a problem. In short, I think the conversation we should be having should be about how to avoid breaking release builds and how to quickly fix problems when they're discovered. I think those working with catalyst have the most to add regarding what breaks them. As far as detect-ability goes, do we need some kind of tinderbox that just does a daily build. Perhaps just build from stage3 to a couple of world targets, including one with some server-oriented software, one with gnome, and one with kde? I've reported a bunch of bugs with the EC2 bootstrap script described on my blog (not my original work), but it is only automated from a build perspective - testing is manual. That takes about 18 hours to build (with an emphasis on economy), and I use spot instances so it really only costs maybe a buck or two. I build about ~1300 packages for amd64 and x86 nearly every day from a fresh snapshot. I'm working on automating it so it really is every day. Once it is automated I suppose I can add kde-meta to the list, even though... well... it's kde. - -Zero My experience has been that if it builds it usually works. So, simply testing for whether the build completes is a pretty-good first step. Of course, for system packages our recourse isn't necessarily good, since we don't have a test branch or anything like that. If we wanted to revert we'd have to impact users who already upgraded. Obviously the goal would be to fix in place with a new revbump, assuming that were possible. Rich -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQw2tZAAoJEKXdFCfdEflKrh4P/i1aJCtnVWh5IlTJ5QMd36S+ eE6chQuZGpm+7TLUsGkRG3rfTKe1vTkDj+e0R5KNQTWL3URsfo9Bc+x87EKBDlZd xkx2VRA+AojFcKwJzUDznwAwCYRz9NIhEz+6bX/Gd0w1PR7ig6JucPa9e6dj4XqG pWvf9me3D78WuNOGcQ70jYX7JxNr0+vzzRu0e4EoEphSLYzIPpdz2FIs6CHov0qD y/imKNG8TjpWRP6/It4s3+83B6nsPfGl9JcwlMXjqncAXNHc0WStFWx5oV/NfqT/ myvV/90YdY2oI5++RcWXsI52aEYuTfvnxZM1WghiymW0UVdR7r7OYMHbiE3Tq59f p8kLgGSxwyleOQHmX9o822mIF53A2PRZ/FEs6Jhr7r1R/NTnvMnePQUUMEAntwlq DjPKui7MhQr8KgnekAqw6EU42spgyKc22QXvp2rdAUnviBA5+c5CtU3RDvx5b9GO VDvuCCI24fsXe9/HyKknoyLjMwfQGHIFp8Cy3oLG40pT9LLzip+jehdv+Kdmy7nX x69bsEioIoVw23wtuWou1+a+HAlfZzTQWlr4TbeAZug9V1YGg9HxP/amzxOrBbcs qbT4Rtf332Kzx4FqYfU/ex6uaMN9fHLv6MAfS5D0l3+P5KK9zMc5P8Tlla3pRFZN I0g6imtLeVA0pMQFgsym =2tcz -END PGP SIGNATURE-
Re: [gentoo-dev] borked release media
Matt Turner wrote: I think we should consider things that break release media serious regressions. I think we should consider things that break anything serious regressions. Why should release media be more special than anything else? My email and bugzilla sweep a few days ago was during a stage4 catalyst run. I found several trivial problems which I fixed in seconds by pushing some commits to my overlay. In Gentoo, nothing has changed since then. Nothing has happened to those bugs in bugzilla, and nothing has happened in gentoo-x86. I don't think it's neccessarily less serious that existing tested trivial bug fixes don't make it to the tree. //Peter
Re: [gentoo-dev] borked release media
On Fri, Dec 07, 2012 at 08:55:04PM -0800, Pawe?? Hajdan, Jr. wrote The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) While we're at it, can we please also make a USB-key install ISO? I'm not asking merely because other distros do it. I'm asking because the situation has changed in the past half-dozen years. Back in 2005 or 2006, almost all machines had a CD and/or DVD, and many older PC BIOSes did not allow for booting from a USB key. Fast-forward to 2012 (and soon 2013) and... * just about every PC is capable of booting from USB * quite a few netbooks/notebooks do not have a CD or DVD drive. E.g. I had to boot from a Knoppix USB key as my working environment to do the initial portion of the Gentoo install on my netbook. Yes, I'm aware of http://www.gentoo.org/doc/en/liveusb.xml, but even I have occasionally fouled up those intructions. It doesn't exactly encourage new Gentoo users to have to go through that tap-dance. Arch linux https://wiki.archlinux.org/index.php/USB_Installation_Media manages to have a dual-bootable (CD / USB-key) image as a standard feature. In addition to installation, it would make the base of a good system rescue utility. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO # did if=image.ISO of=/dev/sdb bs=8192k sdb being your removable device. Also keep in mind that any data on sdb will be wiped after running the dd command. likewhoa Walter Dnes waltd...@waltdnes.org wrote: On Fri, Dec 07, 2012 at 08:55:04PM -0800, Pawe?? Hajdan, Jr. wrote The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) While we're at it, can we please also make a USB-key install ISO? I'm not asking merely because other distros do it. I'm asking because the situation has changed in the past half-dozen years. Back in 2005 or 2006, almost all machines had a CD and/or DVD, and many older PC BIOSes did not allow for booting from a USB key. Fast-forward to 2012 (and soon 2013) and... * just about every PC is capable of booting from USB * quite a few netbooks/notebooks do not have a CD or DVD drive. E.g. I had to boot from a Knoppix USB key as my working environment to do the initial portion of the Gentoo install on my netbook. Yes, I'm aware of http://www.gentoo.org/doc/en/liveusb.xml, but even I have occasionally fouled up those intructions. It doesn't exactly encourage new Gentoo users to have to go through that tap-dance. Arch linux https://wiki.archlinux.org/index.php/USB_Installation_Media manages to have a dual-bootable (CD / USB-key) image as a standard feature. In addition to installation, it would make the base of a good system rescue utility. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
Fernando Reyes wrote: iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2 target in a nice way, and file a bug with updated ebuilds for catalyst which add the dependency. Many thanks! //Peter
Re: [gentoo-dev] borked release media
The problem with the isohybrid approach is that it doesn't support UEFI booting and this is why I wouldn't recommended as a feature in catalyst. However, this should be documented somewhere so that users know its possible without having to follow the liveusb guide which is probably outdated by today's standards. likewhoa Peter Stuge pe...@stuge.se wrote: Fernando Reyes wrote: iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2 target in a nice way, and file a bug with updated ebuilds for catalyst which add the dependency. Many thanks! //Peter
[gentoo-dev] borked release media
Hey people, what are we going to do with bugs like: https://bugs.gentoo.org/show_bug.cgi?id=421839 https://bugs.gentoo.org/show_bug.cgi?id=445848 I'd like to help with things. Is the process of building livecd .isos and stages documented somewhere? I'd like to reproduce problems locally, work on fixes, and join the release teams. I also think points made at https://bugs.gentoo.org/show_bug.cgi?id=438234 are very reasonable, and we should do more testing of published media/stages. The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) Again, I'm willing to do the work, just need some documentation/pointers. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] borked release media
On Fri, Dec 7, 2012 at 8:55 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Hey people, what are we going to do with bugs like: https://bugs.gentoo.org/show_bug.cgi?id=421839 https://bugs.gentoo.org/show_bug.cgi?id=445848 I'd like to help with things. Is the process of building livecd .isos and stages documented somewhere? I'd like to reproduce problems locally, work on fixes, and join the release teams. I also think points made at https://bugs.gentoo.org/show_bug.cgi?id=438234 are very reasonable, and we should do more testing of published media/stages. The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) Again, I'm willing to do the work, just need some documentation/pointers. Paweł Indeed, it is a problem. Fortunately the missing /run was confirmed fixed earlier today on IRC, so that should be resolved shortly and with it the second bug you mention. The main problem here is that it's really easy to break the release media. Mistakes happen and are a normal part of development, but for instance stabilizing linux-headers-3.6 (bug 443532) with multiple outstanding bugs caused some completely predictable breakage. I have never once been able to grab a portage snapshot and build a stage 1, 2, 3 series from it without encountering at least a couple of problems with the tree. I think we should consider things that break release media serious regressions. I don't know what that entails specifically, but whether it need be QA bashing down your door or a quick fix or revert, it sure would be nice to get Gentoo to a place where release media always works. In any case, we'd love some extra help. jmbsvicetto and armin76 have been managing all of the autobuilds, to my knowledge, for a long time. catalyst could also use some work. Spend a day or so building some stages and I have no doubt you'd find things you want to change. :) In short, I think the conversation we should be having should be about how to avoid breaking release builds and how to quickly fix problems when they're discovered. Thanks, Matt
