Pointers to mirroring partitions (w/ encryption?) help?
Hallo. I'm continuing on sinking in to btrfs, so pointers to concise help articles appreciated. I've got a couple new home systems, so perhaps it's time to investigate encryption, and given the bit rot I've seen here, perhaps time to mirror volumes so the wonderful btrfs self-healing facilities can be taken advantage of.
Problem with today's hard drives, a quick look at Canada Computer shows the smallest drives 500GB, 120GB SSDs, far more than the 20GB or so an OS needs. Yet not looking to put in a 2nd HD, either. It feels like mirroring volumes makes sense.
(EFI [partitions] also seem to be sticking their fingers in here.]
Assume a CD sized (680MB) /boot, and perhaps a 200MB (?) sized EFI partition, it seems to me one sets up / as usual (less complex install), then creates another partition for mirroring, later. IIUC, btrfs add device /dev/sda4 / is appropriate, then. Then running a balance seems recommended.
Confusing, however, is having those (both) partitions encrypted. Seems some work is needed beforehand. But I've never done encryption. I have come across https://github.com/gebi/keyctl_keyscript, so I understand there will be gotchas to deal with - later. But not there yet, and not real sure how to start.
The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption".
Any good links to concise instructions on building / establishing encrypted btrfs mirror volumes? dm_crypt seems to be the basis, and not looking to add LVM, seems an unnecessary extra layer of complexity.
It also feels like I could mkfs.btrfs /dev/sda3 /dev/sda4, then mirror subvolumes (or it inherently comes along for the ride?) - so my confusion level increases. Especially if encryption is added to the mix.
So, I could take an HD, create partitions as above (how? e.g. Set up encryption / btrfs mirror volumes), then clonezilla (?) partitions from a current machine in. I assume mounting a live cd then cp -a from old disk partition to new disk partition won't 'just work'. (?)
Article suggestions?
Here's some thoughts:
Quoted 1 line
Assume a CD sized (680MB) /boot
Some distros carry patches for grub that allow booting from Btrfs, so no separate /boot file system is required. (Fedora does not; Ubuntu -- and therefore probably all Debians -- does.)
Quoted 1 line
perhaps a 200MB (?) sized EFI partition
Way bigger than necessary. It should only be 1-2MiB, and IIRC 2MiB might be the max UEFI allows.
Quoted 1 line
then creates another partition for mirroring, later. IIUC, btrfs add device
/dev/sda4/ is appropriate, then. Then running a balance seems recommended.
Don't do this. It's not going to provide any additional protection that you can't do in a smarter way. If you only have one device and want data duplication, just use the dup data profile (settable via balance). In fact, by default Btrfs uses the dup profile for metadata (and single for data). You'll get all the data integrity benefits with dup.
One of the best features and initally confusing things about Btrfs is how much is done "within" a file system. (There is a certain "the Btrfs way" to it.)
Quoted 1 line
Confusing, however, is having those (both) partitions encrypted. Seems some work is needed beforehand. But I've never done encryption.
(This is moot if you go with dup.) It's actually quite easy with every major distro. If we're talking about a fresh install, the distro installer probably has full support for passphrase-based dm-crypt LUKS encryption, including multiple volumes sharing a passphrase. An existing install should be convertable without much trouble. It's ususally just a matter of setting up the container with cryptsetup, populating /etc/crypttab, possibly adding crypto modules to your initrd and/or updating settings, and rebuilding the initrd. (I have first-hand experience doing this on a Fedora install recently, and it took about half an hour and I knew nothing about Fedora's dracut initrd generator tool.)
If you do need multiple encrypted file systems, simply use the same passphrase for all volumes (but never do this by cloning the LUKS headers). You'll only need to enter it once at boot.
Quoted 1 line
The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption".
Yeah, when it comes to FDE, you either have to make your peace with trusting the manufacturer, or you can't. If you are going to boot your system with a traditional boot loader, an unencrypted partition is mandatory. That being said, we live in a world with UEFI Secure Boot. While your EFI parition must be unencrypted vfat, you can sign the kernels (or shims), and the UEFI can be configured to only boot signed executables, including only those signed by your own key. Some distros already provide this feature, including using keys probably already trusted by the default keystore.
Quoted 1 line
mirror subvolumes (or it inherently comes along for the ride?)
Yes, that is correct. Just to give some more background: the data and metadata profiles control "mirroring," and they are set at the file system level. Subvolumes live entirely within one file system, so whatever profile is set in the FS applies to subvolumes.
Quoted 1 line
So, I could take an HD, create partitions as above (how? e.g. Set up encryption / btrfs mirror volumes), then clonezilla (?) partitions from a current machine in.
Are you currently using Btrfs? If so, use Btrfs' send and receive commands. That should be lot friendlier to your SSD. (I'll take this opportunity to say that you need to consider the discard mount *and* /etc/crypttab options. Discard -- or scheduling fstrim -- is extremely important to maintain optimal performance of a SSD, but there are some privacy trade-offs on encrypted systems.) If not, then cp -a or similar will work. Obviously, you'll have to get your boot mechanism and file system identifiers updated in addition to /etc/crypttab described above.
Lastly, strongly consider autodefrag and possibly setting some highly violatile -- but *unimportant* -- directories to nodatacow via purging and chattr +C. (I do this for ~/.cache and /var/cache.)
Quoted 1 line
Yet not looking to put in a 2nd HD
If you change your mind and decide on a backup device, or even if you just want local backup snapshots, one of the best snapshot managers is btrfs-sxbackup (no association with the FS project).
Quoted 46 lines · B. S.
Hallo. I'm continuing on sinking in to btrfs, so pointers to concise help articles appreciated. I've got a couple new home systems, so perhaps it's time to investigate encryption, and given the bit rot I've seen here, perhaps time to mirror volumes so the wonderful btrfs self-healing facilities can be taken advantage of.
Problem with today's hard drives, a quick look at Canada Computer shows the smallest drives 500GB, 120GB SSDs, far more than the 20GB or so an OS needs. Yet not looking to put in a 2nd HD, either. It feels like mirroring volumes makes sense.
(EFI [partitions] also seem to be sticking their fingers in here.]
Assume a CD sized (680MB) /boot, and perhaps a 200MB (?) sized EFI partition, it seems to me one sets up / as usual (less complex install), then creates another partition for mirroring, later. IIUC, btrfs add device
/dev/sda4/ is appropriate, then. Then running a balance seems recommended.Confusing, however, is having those (both) partitions encrypted. Seems some work is needed beforehand. But I've never done encryption. I have come across https://github.com/gebi/keyctl_keyscript, so I understand there will be gotchas to deal with - later. But not there yet, and not real sure how to start.
The additional problem is most articles reference FDE (Full Disk Encryption)
- but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption".Any good links to concise instructions on building / establishing encrypted btrfs mirror volumes?
dm_cryptseems to be the basis, and not looking to add LVM, seems an unnecessary extra layer of complexity.It also feels like I could mkfs.btrfs
/dev/sda3/dev/sda4, then mirror subvolumes (or it inherently comes along for the ride?) - so my confusion level increases. Especially if encryption is added to the mix.So, I could take an HD, create partitions as above (how? e.g. Set up encryption / btrfs mirror volumes), then clonezilla (?) partitions from a current machine in. I assume mounting a live cd then cp -a from old disk partition to new disk partition won't 'just work'. (?)
Article suggestions?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · Justin Brown
Here's some thoughts:
Quoted 1 line
Assume a CD sized (680MB) /boot
Some distros carry patches for grub that allow booting from Btrfs, so no separate /boot file system is required. (Fedora does not; Ubuntu -- and therefore probably all Debians -- does.)
OTOH, a separate /boot keeps all possible future options open, and reduces complexity. e.g. unwinding a /boot from within /, later. Regardless, no harm in having separate /boot. (Assuming not worried about partition presence detection.)
Quoted 4 lines
Quoted 1 line
perhaps a 200MB (?) sized EFI partition
Way bigger than necessary. It should only be 1-2MiB, and IIRC 2MiB might be the max UEFI allows.
Thanks for that. https://en.wikipedia.org/wiki/EFI_system_partition,
which I stupidly didn't think to look at at the time, doesn't speak to
size, but does note, for Gummiboot, "Configuration file fragments, kernel images and initrd images are required to reside on the EFI System partition, as Gummiboot does not provide support for accessing files on
other partitions or file systems." So I'm not sure that 2MB is large
enough, and I suspect exceeding 2MB, reasonably, should do no harm
except waste some space.
Quoted 10 lines
Quoted 3 lines
then creates another partition for mirroring, later. IIUC, btrfs add device
/dev/sda4/ is appropriate, then. Then running a balance seems recommended.Don't do this. It's not going to provide any additional protection that you can't do in a smarter way. If you only have one device and want data duplication, just use the
dupdata profile (settable viabalance). In fact, by default Btrfs uses thedupprofile for metadata (andsinglefor data). You'll get all the data integrity benefits withdup.
Thank you for that. So a data dup'ed fs will overwrite a checksum failing file with the (checksum succeeding) 2nd copy, and the weekly scrub will ensure the reverse won't happen (likely). Cool!
I wonder if a separate physical partition brings anything to the party. OTOH, a botched partition, duplicated, is still botched. Hmm.
Having a btrfs partition currently, with / even, can the partition be grown and dup added after the fact?
Quoted 3 lines
One of the best features and initally confusing things about Btrfs is how much is done "within" a file system. (There is a certain "the Btrfs way" to it.)
Yep. Thus the questions. And thank you, list, for being here.
Quoted 8 lines
Quoted 4 lines
Confusing, however, is having those (both) partitions encrypted. Seems some work is needed beforehand. But I've never done encryption.
(This is moot if you go with
dup.) It's actually quite easy with every major distro. If we're talking about a fresh install, the distro installer probably has full support
... don't we wish. Just tried a Kubuntu 16.04 LTS install ... passphrase request hidden and broken. Some googling suggests staying away from K/Ubuntu at the moment for crypt installs. Installer broken.
So switched to Debian 8, which is bringing its own problems. e.g. network can ping locally but not outside. Set static address and it's fine - go figure. Broken video and updates, and more. This, I expect, has more to do with getting back into the Debian way.
Quoted 3 lines
for passphrase-based
dm-crypt LUKS encryption, including multiple volumes sharing a passphrase.
... and you're back to why I posted the OP. Just sinking into such, and the water is murky. No doubt, like so many other things Linux, in a few years in will be old hat. Not there yet, though.
Quoted 7 lines
An existing install should be convertable without much trouble. It's ususally just a matter of setting up the container with
cryptsetup, populating/etc/crypttab, possibly adding crypto modules to your initrd and/or updating settings, and rebuilding the initrd. (I have first-hand experience doing this on a Fedora install recently, and it took about half an hour and I knew nothing about Fedora'sdracutinitrd generator tool.)
Hmmm. Interesting thought. Perhaps I should clone a current install, and go through the exercise. Then trying to do it all at once on a new install should have a lower learning curve / botch risk.
Quoted 3 lines
If you do need multiple encrypted file systems, simply use the same passphrase for all volumes (but never do this by cloning the LUKS headers). You'll only need to enter it once at boot.
Good to know, thank you. That's not obvious / made readily apparent when googling.
Let alone, if trying to reduce complexity by ignoring LVM, it isn't readily apparent that dmcrypt involves LUKS. Too many terms and technologies flying by, cross-pollinating, even.
Quoted 10 lines
Quoted 4 lines
The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption".
Yeah, when it comes to FDE, you either have to make your peace with trusting the manufacturer, or you can't. If you are going to boot your system with a traditional boot loader, an unencrypted partition is mandatory. That being said, we live in a world with UEFI Secure Boot.
Another learning curve (UEFI) to swallow at the same time as all the other here. Current install is the first time it has occurred to me to try to incorporate SecureBoot, UEFI, crypt, and all such 'goodness' on a fresh (raw) install. Debian is bringing apt-secure along for the ride on me, too.
Quoted 6 lines
While your EFI parition must be unencrypted vfat, you can sign the kernels (or shims), and the UEFI can be configured to only boot signed executables, including only those signed by your own key. Some distros already provide this feature, including using keys probably already trusted by the default keystore.
Quoted 6 lines
Quoted 1 line
mirror subvolumes (or it inherently comes along for the ride?)
Yes, that is correct. Just to give some more background: the data and metadata profiles control "mirroring," and they are set at the file system level. Subvolumes live entirely within one file system, so whatever profile is set in the FS applies to subvolumes.
Gotcha, thus your dup observation.
However ... the question was aimed at a crypto sda3, thus containing @, and probably @home, sda4 created ... how might one kick in to (btrfs) mirror sda3 in sda4, including @ and @home.
I would guess, from your comment, once one adds sda4 to the sda3 set, all that (sda3) profile applies, gets applied to sda4, and all the btrfs magic goodness ... just happens.
Particularly after running balance to force all that goodness to happen at once / now, rather than upon next write.
Quoted 6 lines
Quoted 3 lines
So, I could take an HD, create partitions as above (how? e.g. Set up encryption / btrfs mirror volumes), then clonezilla (?) partitions from a current machine in.
Are you currently using Btrfs? If so, use Btrfs'
sendandreceivecommands.
Yeah. Ick. :-) Have had better luck in the past just cloning or mounting and cp -a. Likely, my lack of experience was the issue.
In any case, here, the question was pointed at a new install.
Quoted 6 lines
That should be lot friendlier to your SSD. (I'll
take this opportunity to say that you need to consider thediscardmount *and*/etc/crypttaboptions. Discard -- or schedulingfstrim-- is extremely important to maintain optimal performance of a SSD, but there are some privacy trade-offs on encrypted systems.) If not, thencp -aor similar will work.
SSD not yet in play here, but I do take your point. I had to work through all that on the SSD I do have, so I do know to peek at such whenever an SSD come into play.
Didn't know about the /etc/crypttab options, thanks for that. Heck, hadn't gotten as far as knowing there was an /etc/crypttab.
- thus, I think part of my OP question is what all am I attempting to swallow in one go on a fresh install here? I get dmcrypt and uefi is involved, so I can start to break down the googling into component pieces. Thus, I think, the request for an appropriate link. Something that does it all on a fresh install in one go would be good, particularly if it identifies the major sub-topics, and has 'links to more info'.
Quoted 8 lines
Obviously, you'll have to
get your boot mechanism and file system identifiers updated in addition to/etc/crypttabdescribed above.Lastly, strongly consider
autodefragand possibly setting some highly violatile -- but *unimportant* -- directories tonodatacowvia purging andchattr +C. (I do this for ~/.cache and/var/cache.)
Yep, autodefrag is in the mount options. I have a number of home systems running btrfs for some years now. Started with Kubuntu 12.04 LTS (since running hwe kernels to get later btrfs tools), and a couple of 14.04's. GB rsyncs and mondoarchives fly all about the house in cascading archives, nightly.
A recent 4TB HD failure is part of the reason for the OP questions. A scrub at the time revealed many failures, and dealing with that and figuring out which files to fetch from secondary archives was a challenge. BUT, FANTASTICALLY, for the first time (pre-btrfs days), at least btrfs / something specifically identified WHICH files were botched. I wasn't left wondering what botched file will reveal itself months from now ... after the botched file had cascaded to all backups!
Having been bitten, and facing a new install, thought I'd better OP.
Quoted 5 lines
Quoted 1 line
Yet not looking to put in a 2nd HD
If you change your mind and decide on a backup device, or even if you just want local backup snapshots, one of the best snapshot managers is btrfs-sxbackup (no association with the FS project).
Thank you for that!
Thus far, keeping only the OS on / and mondoarchiving it nightly, and rsync'ing /everythingelse seems to be doing the job. Perhaps even keeping the 'after the failure' complexity level down.
Quoted 52 lines · B. S.
Quoted 51 lines
Hallo. I'm continuing on sinking in to btrfs, so pointers to concise help articles appreciated. I've got a couple new home systems, so perhaps it's time to investigate encryption, and given the bit rot I've seen here, perhaps time to mirror volumes so the wonderful btrfs self-healing facilities can be taken advantage of.
Problem with today's hard drives, a quick look at Canada Computer shows the smallest drives 500GB, 120GB SSDs, far more than the 20GB or so an OS needs. Yet not looking to put in a 2nd HD, either. It feels like mirroring volumes makes sense.
(EFI [partitions] also seem to be sticking their fingers in here.]
Assume a CD sized (680MB) /boot, and perhaps a 200MB (?) sized EFI partition, it seems to me one sets up / as usual (less complex install), then creates another partition for mirroring, later. IIUC, btrfs add device
/dev/sda4/ is appropriate, then. Then running a balance seems recommended.Confusing, however, is having those (both) partitions encrypted. Seems some work is needed beforehand. But I've never done encryption. I have come across
https://github.com/gebi/keyctl_keyscript, so I understand there will be gotchas to deal with - later. But not there yet, and not real sure how to start.The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption".
Any good links to concise instructions on building / establishing encrypted btrfs mirror volumes?
dm_cryptseems to be the basis, and not looking to add LVM, seems an unnecessary extra layer of complexity.It also feels like I could mkfs.btrfs
/dev/sda3/dev/sda4, then mirror subvolumes (or it inherently comes along for the ride?) - so my confusion level increases. Especially if encryption is added to the mix.So, I could take an HD, create partitions as above (how? e.g. Set up encryption / btrfs mirror volumes), then clonezilla (?) partitions from a current machine in. I assume mounting a live cd then cp -a from old disk partition to new disk partition won't 'just work'. (?)
Article suggestions? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html
04.06.2016 04:39, Justin Brown пишет:
Quoted 8 lines
Here's some thoughts:
Quoted 1 line
Assume a CD sized (680MB) /boot
Some distros carry patches for grub that allow booting from Btrfs, so no separate /boot file system is required. (Fedora does not; Ubuntu -- and therefore probably all Debians -- does.)
Which grub (or which Fedora) do you mean? btrfs support is upstream since 2010.
There are restrictions, in particular RAID levels support (RAID5/6 are not implemented).
Quoted 5 lines
Quoted 1 line
perhaps a 200MB (?) sized EFI partition
Way bigger than necessary. It should only be 1-2MiB, and IIRC 2MiB might be the max UEFI allows.
You may want to review recent discussion on systemd regarding systemd boot (a.k.a. gummiboot) which wants to have ESP mounted as /boot.
UEFI mandates support for FAT32 on ESP so max size should be whatever max size FAT32 has.
...
Quoted 10 lines
Quoted 5 lines
The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption".
Yeah, when it comes to FDE, you either have to make your peace with trusting the manufacturer, or you can't. If you are going to boot your system with a traditional boot loader, an unencrypted partition is mandatory.
No, it is not with grub2 that supports LUKS (and geli in *BSD world). Of course initial grub image must be written outside of encrypted area and readable by firmware.
Quoted 7 lines
That being said, we live in a world with UEFI Secure
Boot. While your EFI parition must be unencrypted vfat, you can sign the kernels (or shims), and the UEFI can be configured to only boot signed executables, including only those signed by your own key. Some distros already provide this feature, including using keys probably already trusted by the default keystore.
UEFI Secure Boot is rather orthogonal to the question of disk encryption.
Quoted 10 lines · Andrei Borzenkov
04.06.2016 04:39, Justin Brown пишет:
Quoted 8 lines
Here's some thoughts:
Quoted 1 line
Assume a CD sized (680MB) /boot
Some distros carry patches for grub that allow booting from Btrfs, so no separate /boot file system is required. (Fedora does not; Ubuntu -- and therefore probably all Debians -- does.)
Quoted 5 lines
Which grub (or which Fedora) do you mean? btrfs support is upstream since 2010.
There are restrictions, in particular RAID levels support (RAID5/6 are not implemented).
Good to know / be reminded of (such specifics) - thanks.
Quoted 18 lines
Quoted 5 lines
Quoted 1 line
perhaps a 200MB (?) sized EFI partition
Way bigger than necessary. It should only be 1-2MiB, and IIRC 2MiB might be the max UEFI allows.
You may want to review recent discussion on systemd regarding systemd boot (a.k.a. gummiboot) which wants to have ESP mounted as /boot.
UEFI mandates support for FAT32 on ESP so max size should be whatever max size FAT32 has.
...Quoted 6 lines
Quoted 5 lines
The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption".
Quoted 8 lines
Quoted 4 lines
Yeah, when it comes to FDE, you either have to make your peace with trusting the manufacturer, or you can't. If you are going to boot your system with a traditional boot loader, an unencrypted partition is mandatory.
No, it is not with grub2 that supports LUKS (and geli in *BSD world). Of course initial grub image must be written outside of encrypted area and readable by firmware.
Good to know. Do you have a link to a how to on such?
Quoted 9 lines
Quoted 7 lines
That being said, we live in a world with UEFI Secure
Boot. While your EFI parition must be unencrypted vfat, you can sign the kernels (or shims), and the UEFI can be configured to only boot signed executables, including only those signed by your own key. Some distros already provide this feature, including using keys probably already trusted by the default keystore.UEFI Secure Boot is rather orthogonal to the question of disk encryption.
Perhaps, but not orthogonal to the OP question.
In the end, the OP is about all this 'stuff' landing at once, the majority btrfs centric, and a call for help finding the end of the string to pull on in a linear way. e.g., as pointed out, most articles premising FDE, which is not in play per OP. The OP requesting pointers to good concise how to links.
04.06.2016 20:31, B. S. пишет:
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Yeah, when it comes to FDE, you either have to make your peace with trusting the manufacturer, or you can't. If you are going to boot your system with a traditional boot loader, an unencrypted partition is mandatory.
Quoted 6 lines
Quoted 3 lines
No, it is not with grub2 that supports LUKS (and geli in *BSD world). Of course initial grub image must be written outside of encrypted area and readable by firmware.
Good to know. Do you have a link to a how to on such?
As long as you use grub-install and grub-mkconfig this "just works" in the sense they both detect encrypted container and add necessary drivers and other steps to access it. The only manual setup is to add
GRUB_ENABLE_CRYPTODISK=y
to /etc/default/grub.
You will need to enter LUKS password twice - once in GRUB, once in kernel (there is no interface for passing passphrase from bootloader to Linux kernel). Some suggest including passphrase in initrd (on assumption that it is encrypted anyway already); there are patches to support use of external keyfile in grub as well.
Quoted 5 lines · Justin Brown
Here's some thoughts:
Quoted 1 line
Assume a CD sized (680MB) /boot
Some distros carry patches for grub that allow booting from Btrfs
Upstream GRUB has had Btrfs support for a long time. There's been no need for distros to carry separate patches for years. The exception is openSUSE, where they have a healthy set of patches for supporting the discovery of and boot of read only snapshots created by snapper. Those patches are not merged upstream, I'm not sure if they will be.
Quoted 3 lines
, so
no separate /boot file system is required. (Fedora does not; Ubuntu -- and therefore probably all Debians -- does.)
The problem on Fedora is that they depend on grubby to modify the grub.cfg. And grubby gets confused when the kernel/initramfs are located on a Btrfs subvolume other than the top level. And Fedora's installer only installs the system onto a subvolume (specifically, every mount point defined in the installer becomes a subvolume if you use Btrfs). So it's stuck being unable to support /boot if it's on Btrfs.
Quoted 5 lines
Quoted 2 lines
perhaps a 200MB (?) sized EFI partition
Way bigger than necessary. It should only be 1-2MiB, and IIRC 2MiB might be the max UEFI allows.
You're confusing the ESP with BIOSBoot. The minimum size for 512 byte sector drives per Microsoft's technotes is 100MiB. Most OEMs use something between 100MiB and 300MiB. Apple creates a 200MB ESP even though they don't use it for booting, rather just to stage firmware updates.
The UEFI spec itself doesn't say how big the ESP should be. 200MiBi is sane for 512 byte drives. It needs to be 260MiB minimum for 4Kn drives, because of the minimum number of FAT allocation units at 4096 bytes each requires a 260MiB minimum volume.
Quoted 7 lines
Quoted 2 lines
The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption".
Yeah, when it comes to FDE, you either have to make your peace with trusting the manufacturer, or you can't. If you are going to boot your system with a traditional boot loader, an unencrypted partition is mandatory.
/boot can be encrypted, GRUB supports this, but I'm unaware of any installer that does. The ESP can't be encrypted.
http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/
It's vaguely possible for the SED variety of drive to support fully encrypted everything, including the ESP. The problem is we don't have OPAL support on Linux at all anywhere. And for some inexplicable reason, the TCG hasn't commissioned a free UEFI application for managing the keys and unlocking the drive in the preboot environment. For now, it seems, such support has to already be in the firmware.
Signature · 1 line
Chris Murphy
04.06.2016 22:05, Chris Murphy пишет:
...
Quoted 8 lines
Quoted 5 lines
Yeah, when it comes to FDE, you either have to make your peace with trusting the manufacturer, or you can't. If you are going to boot your system with a traditional boot loader, an unencrypted partition is mandatory.
/boot can be encrypted, GRUB supports this, but I'm unaware of any installer that does.
openSUSE supports installation on LUKS encrypted /boot. Installer has some historical limitations regarding how encrypted container can be setup, but bootloader part should be OK (including secure boot support).
Quoted 2 lines
The ESP can't be encrypted.
It should be possible if you use hardware encryption (SED).
Quoted 9 lines
http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/
It's vaguely possible for the SED variety of drive to support fully encrypted everything, including the ESP. The problem is we don't have OPAL support on Linux at all anywhere. And for some inexplicable reason, the TCG hasn't commissioned a free UEFI application for managing the keys and unlocking the drive in the preboot environment. For now, it seems, such support has to already be in the firmware.