Fwd: [free-software-melb] Draft Fedora plan to cope with Secure Boot on x86 hardware
Hi everyone, Update on secure boot from the Melbourne Free Software mailing list. ---------- Forwarded message ---------- From: Chris Samuel <chris@csamuel.org> Date: 31 May 2012 16:43 Subject: [free-software-melb] Draft Fedora plan to cope with Secure Boot on x86 hardware To: Melbourne Free Software Interest Group < free-software-melb@lists.softwarefreedom.com.au> Hi all, Matthew Garrett has just posted a draft plan on how Fedora 18 plans to cope with Windows 8 certified x86 hardware that has Secure Boot enabled in EFI. http://mjg59.dreamwidth.org/12368.html Basically it involves signing up with Microsoft, paying a $99 one-off fee and then getting them to sign a boot shim that will boot Grub2 that has been signed by a Fedora key. Then it has to be signed code all the way down to user space, so no loading out-of-tree drivers, filesystems or other modules, either FLOSS or proprietary (and certainly not a custom kernels) whilst Secure Boot is enabled. For those who've not come across what this means, he has a nice summary: # Secure boot is built on the idea that all code that can touch the # hardware directly is trusted, and any untrusted code must go through # the trusted code. This can be circumvented if users can execute # arbitrary code in the kernel. So, we'll be moving to requiring # signed kernel modules and locking down certain aspects of kernel # functionality. The most obvious example is that it won't be possible # to access PCI regions directly from userspace, which means all # graphics cards will need kernel drivers. Userspace modesetting will # be a thing of the past. Again, disabling secure boot will disable # these restrictions. # # Signed modules are obviously troubling from a user perspective. # We'll be signing all the drivers that we ship, but what about out # of tree drivers? We don't have a good answer for that yet. As # before, we don't want any kind of solution that works for us # but doesn't work for other distributions. Fedora-only or # Ubuntu-only drivers are the last thing anyone wants, and this # really needs to be handled in a cross-distribution way. Interestingly he also shows that you can use Secure Boot to ensure that your system will only be able to boot Fedora (etc) and never boot a proprietary OS: # A system in custom mode should allow you to delete all existing keys # and replace them with your own. After that it's just a matter of # re-signing the Fedora bootloader (like I said, we'll be providing # tools and documentation for that) and you'll have a computer that # will boot Fedora but which will refuse to boot any Microsoft code. # It may be a little more awkward for desktops because you may have # to handle the Microsoft-signed UEFI drivers on your graphics and # network cards, but this is also solvable. I'm looking at ways to # implement a tool to allow you to automatically whitelist the # installed drivers. Barring firmware backdoors, it's possible to # configure secure boot such that your computer will only run software # you trust. Freedom means being allowed to run the software you want # to run, but it also means being able to choose the software you # don't want to run. Interesting times! cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP _______________________________________________ Free-software-melb mailing list Free-software-melb@lists.softwarefreedom.com.au http://lists.softwarefreedom.com.au/mailman/listinfo/free-software-melb
I have 4*3TB disks in a RAID-Z. zpool list says the size is 10.9TB, df -h says the size is 7.8TB. I expected to see 9TB as the reported size. What is happening? Is the full capacity of the disks being used? Bianca Gibson <bianca.rachel.gibson@gmail.com> wrote:
Hi everyone,
Update on secure boot from the Melbourne Free Software mailing list.
---------- Forwarded message ---------- From: Chris Samuel <chris@csamuel.org> Date: 31 May 2012 16:43 Subject: [free-software-melb] Draft Fedora plan to cope with Secure Boot on x86 hardware To: Melbourne Free Software Interest Group < free-software-melb@lists.softwarefreedom.com.au>
Hi all,
Matthew Garrett has just posted a draft plan on how Fedora 18 plans to cope with Windows 8 certified x86 hardware that has Secure Boot enabled in EFI.
http://mjg59.dreamwidth.org/12368.html
Basically it involves signing up with Microsoft, paying a $99 one-off fee and then getting them to sign a boot shim that will boot Grub2 that has been signed by a Fedora key. Then it has to be signed code all the way down to user space, so no loading out-of-tree drivers, filesystems or other modules, either FLOSS or proprietary (and certainly not a custom kernels) whilst Secure Boot is enabled.
For those who've not come across what this means, he has a nice summary:
# Secure boot is built on the idea that all code that can touch the # hardware directly is trusted, and any untrusted code must go through # the trusted code. This can be circumvented if users can execute # arbitrary code in the kernel. So, we'll be moving to requiring # signed kernel modules and locking down certain aspects of kernel # functionality. The most obvious example is that it won't be possible # to access PCI regions directly from userspace, which means all # graphics cards will need kernel drivers. Userspace modesetting will # be a thing of the past. Again, disabling secure boot will disable # these restrictions. # # Signed modules are obviously troubling from a user perspective. # We'll be signing all the drivers that we ship, but what about out # of tree drivers? We don't have a good answer for that yet. As # before, we don't want any kind of solution that works for us # but doesn't work for other distributions. Fedora-only or # Ubuntu-only drivers are the last thing anyone wants, and this # really needs to be handled in a cross-distribution way.
Interestingly he also shows that you can use Secure Boot to ensure that your system will only be able to boot Fedora (etc) and never boot a proprietary OS:
# A system in custom mode should allow you to delete all existing keys # and replace them with your own. After that it's just a matter of # re-signing the Fedora bootloader (like I said, we'll be providing # tools and documentation for that) and you'll have a computer that # will boot Fedora but which will refuse to boot any Microsoft code. # It may be a little more awkward for desktops because you may have # to handle the Microsoft-signed UEFI drivers on your graphics and # network cards, but this is also solvable. I'm looking at ways to # implement a tool to allow you to automatically whitelist the # installed drivers. Barring firmware backdoors, it's possible to # configure secure boot such that your computer will only run software # you trust. Freedom means being allowed to run the software you want # to run, but it also means being able to choose the software you # don't want to run.
Interesting times!
cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
_______________________________________________ Free-software-melb mailing list Free-software-melb@lists.softwarefreedom.com.au http://lists.softwarefreedom.com.au/mailman/listinfo/free-software-melb _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
-- Sent from my Samsung Galaxy S Android phone with K-9 Mail.
Firstly sorry for quoting a previous message. K9 is difficult for some things and the regular internet gateway is being converted to ZFS... Anyway I divided the number of bytes in the disk size by 2^40 and got 2.729TiB for the disk size. Multiplied by 4 gives me 10.916TiB for the total size, the same as the zpool list output. So all my disk capacity is being used. 3/4 of that is 8.187TiB so it seems that everything is ok. -- Sent from my Samsung Galaxy S Android phone with K-9 Mail.
On 6 June 2012 14:35, Russell Coker <russell@coker.com.au> wrote:
I have 4*3TB disks in a RAID-Z. zpool list says the size is 10.9TB, df -h says the size is 7.8TB.
I expected to see 9TB as the reported size. What is happening? Is the full capacity of the disks being used?
Furthermore, with ZFS you probably shouldn't rely on df to report the correct filesystem size; Use "zfs list" instead, as the df command wont be aware of, or understand descendant filesystems, snapshots, compression, dedup etc -- Joel Shea <jwshea@gmail.com>
On Wed, Jun 06, 2012 at 03:51:34PM +1000, Joel W Shea wrote:
On 6 June 2012 14:35, Russell Coker <russell@coker.com.au> wrote:
I have 4*3TB disks in a RAID-Z. zpool list says the size is 10.9TB, df -h says the size is 7.8TB.
I expected to see 9TB as the reported size. What is happening? Is the full capacity of the disks being used?
Furthermore, with ZFS you probably shouldn't rely on df to report the correct filesystem size;
unlike btrfs, df is accurate on zfs.
Use "zfs list" instead, as the df command wont be aware of, or understand descendant filesystems, snapshots, compression, dedup etc
or 'zpool list'. # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 3.62T 2.49T 1.14T 68% 1.00x ONLINE - export 3.62T 2.45T 1.18T 67% 1.00x ONLINE - that's two zpools, each made up of 4 x 1TB drives in raidz-1. 3.6TB formatted from 4x1TB native is about what you'd expect. 'zfs list' shows the filesystems and/or zvols and/or snapshots within the zpools. e.g. # zfs list -t filesystem NAME USED AVAIL REFER MOUNTPOINT backup 1.81T 804G 291K none backup/asterisk 969M 804G 953M /backup/hosts/asterisk backup/durga 10.2G 804G 10.2G /backup/hosts/durga backup/ganesh 1.62T 804G 1.60T /backup/hosts/ganesh backup/hanuman 683M 804G 673M /backup/hosts/hanuman backup/indra 139G 804G 136G /backup/hosts/indra backup/kali 39.9G 804G 37.6G /backup/hosts/kali export 1.85T 756G 727G /export export/ftp 133G 756G 133G /export/ftp export/home 927G 756G 927G /export/home export/src 6.14G 756G 6.14G /export/src craig -- craig sanders <cas@taz.net.au> BOFH excuse #388: Bad user karma.
On Wed, 6 Jun 2012, Joel W Shea wrote:
On 6 June 2012 14:35, Russell Coker <russell@coker.com.au> wrote:
I have 4*3TB disks in a RAID-Z. zpool list says the size is 10.9TB, df -h says the size is 7.8TB.
I expected to see 9TB as the reported size. What is happening? Is the full capacity of the disks being used?
Furthermore, with ZFS you probably shouldn't rely on df to report the correct filesystem size; Use "zfs list" instead, as the df command wont be aware of, or understand descendant filesystems, snapshots, compression, dedup etc
It's not that df is "lying" but it does not tell you "the ZFS surroundings" of the file system. All the ZFS filesystems are sharing one zpool (at least here), and it is a bit confusing, to deal with the numbers if you are used to partition in a style like "/ 200MB, /usr 4GB, /var/log 2GB" etc. I don't run a large farm of ZFS servers at the moment so I can deal with the file systems more or less "half-automated" but it is a bit messy. One box as an example: It has 7 jails and one Virtualbox, and a mirror of 5 jails running on a similar box. It has 122 file systems ans 219 snapshots. (For an active file system there are 5 daily snapshots per week, and seven weeks of weekly snapshots, and two for the migration to the "mirror box".) It is easy "to forget" snapshots or temporary clones. It is useful to compare the various usedby* properties of the file systems (used = usedbydataset + usedbysnapshots + usedbychildren + usedbyrefreservation) At the moment I am monitoring the "overall" size of a zpool, and check the variables above manually. If you are running a bigger farm of services, it can become a nightmare easily. Regards Peter
participants (5)
-
Bianca Gibson -
Craig Sanders -
Joel W Shea -
Peter Ross -
Russell Coker