Pointers to mirroring partitions (w/ encryption?) help?

Pointers to mirroring partitions (w/ encryption?) help?

[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_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?

Re: Pointers to mirroring partitions (w/ encryption?) help?

[Justin Brown]

Here's some thoughts:

> 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.)

> 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.

>  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.)

> 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.

> 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.

> 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.

> 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.)

> 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).

On Fri, Jun 3, 2016 at 3:30 PM, B. S. <bs27975@gmail.com> wrote:
> 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?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pointers to mirroring partitions (w/ encryption?) help?

[B. S.]

On 06/03/2016 09:39 PM, Justin Brown wrote:
> Here's some thoughts:
>
>> 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.)

>> 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.

>> 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`.

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?

> 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.

>
>> 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.

> 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.

> 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.)

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.

> 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.

>> 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.

> 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.
>
>> 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.

>> 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.

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.

 > 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.

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'.

> 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.)

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.

>> 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.

> On Fri, Jun 3, 2016 at 3:30 PM, B. S. <bs27975@gmail.com> wrote:
>> 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? -- To unsubscribe from this list: send the
>> line "unsubscribe linux-btrfs" in the body of a message to
>> majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html

Re: Pointers to mirroring partitions (w/ encryption?) help?

[Andrei Borzenkov]

04.06.2016 04:39, Justin Brown пишет:
> Here's some thoughts:
> 
>> 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).

>> 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.

...
> 
>> 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.

> 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.

Re: Pointers to mirroring partitions (w/ encryption?) help?

[B. S.]

On 06/04/2016 03:46 AM, Andrei Borzenkov wrote:
> 04.06.2016 04:39, Justin Brown пишет:
>> Here's some thoughts:
>>
>>> 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).

Good to know / be reminded of (such specifics) - thanks.

>>> 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.
> ...
>>
>>> 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.

Good to know. Do you have a link to a how to on such?

>> 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.

Re: Pointers to mirroring partitions (w/ encryption?) help?

[Andrei Borzenkov]

04.06.2016 20:31, B. S. пишет:
>>>
>>> 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?
> 

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.

Re: Pointers to mirroring partitions (w/ encryption?) help?

[Chris Murphy]

On Fri, Jun 3, 2016 at 7:39 PM, Justin Brown <justin.brown@fandingo.org> wrote:
> Here's some thoughts:
>
>> 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.


>, 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.



>
>> 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.




>
>> 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.




-- 
Chris Murphy

Re: Pointers to mirroring partitions (w/ encryption?) help?

[Andrei Borzenkov]

04.06.2016 22:05, Chris Murphy пишет:
...
>>
>> 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).

> The ESP can't be encrypted.
> 

It should be possible if you use hardware encryption (SED).

> 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.
>