Yes, wanted to show the problem with encrypting a SSD that stored unencrypted data before. For security reasons you should always "secure erase" the SSDs first before encrypting them so there would be nothing left on the SSDs and "encrypting an existing 2xssd zfs mirror rpool" would be useless.
Encrypting Proxmox VE (Best Methods)
- Thread starter Whitterquick
- Start date
Now I understand, thanks!
The poroxmox (re)installation didn't/wouldn't securely erase them?
Also, does this vulnerability apply only to zfs native encryption? I.e. would a LUKS full disk encryption protect my SSDs without exposing such vulnerability?
No, its a problem in general, no matter what encryption you use. And doing a secure erase isn't that easy. Like I already said, there is no way for the operating system to access all areas of a SSD so a OS also can't fully delete/overwrite it. You really need to tell the firmware of the SSD to do a "secure erase" operation and than the SSDs by itself will (hopefully) wipe everything using its build in algorithms. You basically need to trigger a buildin factory reset function and the SSD will wipe itself on its own. Only the SSDs firmware can access this hidden spare area, so the firmware is also the only thing which can wipe it and delete your unencrypted sensitive data stored there.
Here is shown how to do it with hdparm in linux for sata SSDs. Often the manufacturers will offer a tool with GUI to manage their SSD. But often (like Samsung Magican for Samsung SSDs) these tools will only run on Windows and there is no linux/unix support.
Here is shown how to do it with hdparm in linux for sata SSDs. Often the manufacturers will offer a tool with GUI to manage their SSD. But often (like Samsung Magican for Samsung SSDs) these tools will only run on Windows and there is no linux/unix support.
Last edited:
Thanks for pointing this out, it's crystal clear now! I will need to secure erase... (
)If using LUKS for full disk encryption, is it better to encrypt the partition or the physical volume (I may have named them wrong)? i.e. is it best practice to encrypt sda sdb sdc, or sda1 sdb1 sdc1? Assuming they are the single partition on the disk and take up the full quota of usable storage space.
I read somewhere that it’s best practice to have a partition even when it’s the only one with the whole disk used, as some software may have trouble detecting and try to create one (although I have never experienced that issue). If the main sda sdb sdc are encrypted then I see no point in the partition existing as it can’t be seen without being decrypted anyway.
Someone please enlighten me
I read somewhere that it’s best practice to have a partition even when it’s the only one with the whole disk used, as some software may have trouble detecting and try to create one (although I have never experienced that issue). If the main sda sdb sdc are encrypted then I see no point in the partition existing as it can’t be seen without being decrypted anyway.
Someone please enlighten me
Last edited:
The structure I see everywhere is:
sda
|__sda1
……|__volume_group
…………|__logical_volume
In what way is that better than:
sda
…|__volume_group
………|__logical_volume
sda
|__sda1
……|__volume_group
…………|__logical_volume
In what way is that better than:
sda
…|__volume_group
………|__logical_volume
Last edited:
Ok I have another question
Technically more of a Debian question but as I’m installing Proxmox over it’s a valid one…
Is it possible to install Debian onto LUKS encrypted LVM with a gpt partition table, sha512, and self-created custom partitions? The Debian installer formats as “dos” (mbr) and the encryption options only allow up to sha256. Also it wants us to use the installer to create encrypted LVM rather than install on a disk that has already been setup.
Technically more of a Debian question but as I’m installing Proxmox over it’s a valid one…
Is it possible to install Debian onto LUKS encrypted LVM with a gpt partition table, sha512, and self-created custom partitions? The Debian installer formats as “dos” (mbr) and the encryption options only allow up to sha256. Also it wants us to use the installer to create encrypted LVM rather than install on a disk that has already been setup.
Did you choose the "Graphical expert install" under the "Advanced option..." entry when booting from the Debian ISO?
That will give you alot of more options.
And you can use the installer to manually partition your disk instead of using the guided partitioning.
I for example got 2 disks that I wanted to use as a mirror. Your boot partitions need to be unencrypted, So I first created a sda1 and sdb1 with each 1MB as my grub partition.
Then I created the partition sda2 and sdb2 of 300MB (you really should use 512MB nowadays) each for my ESP.
Then I created sda3 and sdb3 as a mdadm raid1 array for my unencrypted but mirrored boot partition.
Then I created sda4 and sdb4 as a mdadm raid1 array for my LUKS.
Ontop of that LUKS I created a LVM.
Ontop of that LVM my VG.
Ontop of that VG my Swap and my root LVs.
And that all can be done using the GUI of the Debian installer so this will be created:
That will give you alot of more options.
And you can use the installer to manually partition your disk instead of using the guided partitioning.
I for example got 2 disks that I wanted to use as a mirror. Your boot partitions need to be unencrypted, So I first created a sda1 and sdb1 with each 1MB as my grub partition.
Then I created the partition sda2 and sdb2 of 300MB (you really should use 512MB nowadays) each for my ESP.
Then I created sda3 and sdb3 as a mdadm raid1 array for my unencrypted but mirrored boot partition.
Then I created sda4 and sdb4 as a mdadm raid1 array for my LUKS.
Ontop of that LUKS I created a LVM.
Ontop of that LVM my VG.
Ontop of that VG my Swap and my root LVs.
And that all can be done using the GUI of the Debian installer so this will be created:
Code:
root@Hypervisor:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 93.2G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 286M 0 part
├─sda3 8:3 0 488M 0 part
│ └─md0 9:0 0 487M 0 raid1 /boot
└─sda4 8:4 0 92.4G 0 part
└─md1 9:1 0 92.3G 0 raid1
└─md1_crypt 253:0 0 92.3G 0 crypt
├─vgpmx-lvroot 253:1 0 21G 0 lvm /
└─vgpmx-lvswap 253:2 0 61G 0 lvm [SWAP]
sdb 8:16 0 93.2G 0 disk
├─sdb1 8:17 0 1M 0 part
├─sdb2 8:18 0 286M 0 part /boot/efi
├─sdb3 8:19 0 488M 0 part
│ └─md0 9:0 0 487M 0 raid1 /boot
└─sdb4 8:20 0 92.4G 0 part
└─md1 9:1 0 92.3G 0 raid1
└─md1_crypt 253:0 0 92.3G 0 crypt
├─vgpmx-lvroot 253:1 0 21G 0 lvm /
└─vgpmx-lvswap 253:2 0 61G 0 lvm [SWAP]
Last edited:
I have not looked into mdadm or RAID yet. I also see the expert installer only allows up to sha256.
Is 1M enough for GRUB? How do you get it on there once you have partitioned? I didn’t see any option to install the boot loader on multiple partitions…
Here it was fine so far. But you can ofcause use more. Using 8MB and loosing 7MB more space probably won't hurt you
According to my notes I've choosen while installing...
...so the bootloader was just installed to sda. But after logging in as root I ran
dpkg-reconfigure grub-pc and there I selected "/dev/sda" and "/dev/sdb" as the target so that grub gets installed on both disks.Someone knows if that still works fine with the new proxmox-boot-tool? Should replacing a failed disk work the same way like described in the wiki?
I'm looking into booting Proxmox from an encrypted ZFS dataset (being a mirror), so I'm also interested in this question.
@Dunuin Did you investigate this and have some insights?
Not yet.I'm looking into booting Proxmox from an encrypted ZFS dataset (being a mirror), so I'm also interested in this question.
@Dunuin Did you investigate this and have some insights?
For anyone following this thread and wondering (like I was), I tried the recovery instructions posted above in an OVMF guest. I set up an encrypted ZFS boot mirror, using @nschemel's instructions, for the test. It worked fine; after removing a vdisk from the mirror, and adding a new vdisk, I followed the instructions for proxmox-boot-tool and was able to boot from the new vdisk.
But be warned...I wasn't able to keep in short and on the point...right now it's more a complete guide from creating the install USB stick, over a way too long excessive monologue about ZFS fundamentals to the complete configuration of the encrypted PVE installation including LUKS encrypted swap and remote unlocking with VLAN support.