+1 vote for including the keydisk-on-same-hdd patch :) Re: Unable to sufficiently clean up softraid metadata (Re: crypto softraid and keydisk on same harddrive)
On 2015-12-02 08:26, Patrik Lundin wrote: Hello, I have a custom installer script which automatically creates RAID devices and assembles an sd1 CRYPTO device before the ordinary installer continues (making the installer use sd1 for the rest of the installation). This works well, other than needing this patch since the keydisk is on the same harddrive: http://marc.info/?l=openbsd-misc=141450636905550=2 http://marc.info/?l=openbsd-misc=141450636905550=2 I vote +1 for including this patch into OpenBSD! I found it to work well. Patrik do you vote +1 too? Did it work well for you? I have no idea if this is a high quality patch though, someone else would need to tell. But again it did have the desired effect.
Re: +1 vote for including the keydisk-on-same-hdd patch :) Re: Unable to sufficiently clean up softraid metadata (Re: crypto softraid and keydisk on same harddrive)
On Thu, Dec 03, 2015 at 05:52:13AM +0800, Tinker wrote: > On 2015-12-02 08:26, Patrik Lundin wrote: > > > >This works well, other than needing this patch since the keydisk is on > >the same harddrive: > >http://marc.info/?l=openbsd-misc=141450636905550=2 > > > I vote +1 for including this patch into OpenBSD! I found it to work well. > > Patrik do you vote +1 too? Did it work well for you? > > I have no idea if this is a high quality patch though, someone else would > need to tell. But again it did have the desired effect. > While I appreciate someone else pushing for this diff, I am in no position to "vote" for it. If the suitable devs find this a valuable use of their time I am sure no voting is needed. If they don't then it is up to me or someone else to present a diff that lives up to the expected code quality. I can add that it seems to work well on amd64, but that is all I have to offer for now. -- Patrik Lundin
Re: crypto softraid and keydisk on same harddrive
On Mon, Nov 03, 2014 at 01:17:52AM +1100, Joel Sing wrote: Thanks - I'll rehash it and get it in at some point... as an aside, the easiest way to destroy a softraid CRYPTO volume is to simply run 'bioctl -c C -C force ...' as that will replace the block encryption keys in the metadata (and works regardless of passphrase or key disk). Thanks for the tip on how to make the data unusable :). For now I will just build my own iso with your diff. I would of course appreciate if this patch or some version of it could be applied to CVS in the future :). Thanks again! Regards, Patrik Lundin
Re: crypto softraid and keydisk on same harddrive
On Wed, 29 Oct 2014, Patrik Lundin wrote: On Wed, Oct 29, 2014 at 01:24:30AM +1100, Joel Sing wrote: You could try this (only compile tested) diff: I tried this diff on 5.5-stable and it appeared to solve my problem! The system now boots from sr0a without asking for a passphrase. Overwriting the keydisk partition makes the bootloader stop at the passphrase prompt. Thanks - I'll rehash it and get it in at some point... as an aside, the easiest way to destroy a softraid CRYPTO volume is to simply run 'bioctl -c C -C force ...' as that will replace the block encryption keys in the metadata (and works regardless of passphrase or key disk). Thanks a lot! Regards, Patrik Lundin -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
Re: crypto softraid and keydisk on same harddrive
On Tue, Oct 28, 2014 at 08:44:19PM +0100, Patrik Lundin wrote: On Wed, Oct 29, 2014 at 01:24:30AM +1100, Joel Sing wrote: You could try this (only compile tested) diff: I tried this diff on 5.5-stable and it appeared to solve my problem! The system now boots from sr0a without asking for a passphrase. Overwriting the keydisk partition makes the bootloader stop at the passphrase prompt. Based on http://xkcd.com/538/ I'd like to think of this concept as non-access on a need-to-forget basis. Of course it implies that the information you want to protect is worth being imprisoned/tortured/killed for.. Erling
Re: crypto softraid and keydisk on same harddrive
On Tue, 28 Oct 2014, Patrik Lundin wrote: Thank you Stefan for taking a look, see comments inline: On Mon, Oct 27, 2014 at 12:32:30PM +0100, Stefan Sperling wrote: On Sun, Oct 26, 2014 at 09:19:25PM +0100, Patrik Lundin wrote: # disklabel -E wd0 Create the following partitions (in this order to make the biggest partition last): wd0b (swap) wd0d (RAID) - keydisk (1M) wd0a (RAID) - the remaining part of the drive that will be encrypted. I'd use wd0d instead of wd0a, because 'a' is usually expected to contain a root partition, not a softraid volume. That has nothing to do with the problem at hand though. Given that wd0d is used for the keydisk, do you mean i should use wd0e for the remainder of the drive instead of 'a'? This does not matter - wd0a can be RAID. Stefan was just suggesting you avoid using 'a' since it is normally root. There is no technical reason to change this. Would this also mean I should skip creating a sd0a altogether? === Using drive 0, partition 3. Loading. ERR M === This error means biosboot(8) can't find the boot(8) program. When booting from softraid, the boot program is stored at a particular offset in the softraid meta data area, and installboot(8) patches that offset into biosboot(8) before copying biosboot(8) to the MBR. Apparently, biosboot(8) has the wrong offset in your case. Hmm, interesting, thanks for the description! Your report lacks some information: - architecture (i386 / amd64 / ...) I am using amd64. - full output of 'disklabel wd0' to show exactly how you configured partitions I stuck to my original layout for consistency (this has been written down by hand): === # disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: VBOX HARDDISK duid: 175d4587e45a04a5 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 3916 total sectors: 62914560 boundstart: 64 boundend: 62910540 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a:586854454225095RAID b: 4208966 64swap c:62914560 0 unused d: 160654209030RAID === So wd0a is 28GB, wd0b is 2G, and wd0d is 7.8M. - output of running installboot with the -v option on the softraid volume: installboot -v sd0 Since I am not able to boot on the device i have to run installboot as the last step in the installer. For this i need to add -r /mnt (of course the following is also copied by hand): === # installbook -v -r /mnt sd0 Using /mnt as root installing bootstrap on /dev/rsd0c using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot sd0: softraid volume with 2 disk(s) sd0: installing boot loader on softraid volume /mnt/usr/mdec/boot is 5 blocks x 16384 bytes wd0a: installing boot blocks on /dev/rwd0c, part offset 4225175 master boot record (MBR) at sector 0 partition 3: type 0xA6 offset 64 size 62910476 /mnt/usr/mdec/biosboot will be written at sector 64 wd0d: installing boot blocks on /dev/rwd0c, part offset 4209110 master boot record (MBR) at sector 0 partition 3: type 0xA6 offset 64 size 62910476 /mnt/usr/mdec/biosboot will be written at sector 64 === A CRYPTO key disk is slightly special in that it has softraid metadata but is not technically part of the same volume (well, it is in some ways but it is not in others). The problem in question occurs since installboot(8) installs the first stage boot loader on each chunk that is a member of the volume - in this case it installs first stage boot loader twice (once for wd0a and again for wd0d). The second stage boot loader is installed in the softraid metadata area for the sd0 volume, however in the case of a CRYPTO key disk its metadata area does not end up with a copy of the boot of the second stage loader (unlike, say a RAID 1 chunk). If the first stage boot blocks are installed in the CRYPTO volume then the key disk, the boot loader (in the PBR of wd0) will end up pointing at a boot storage area (of the key disk) that does not contain the second stage boot loader. The fix is to probably avoid installing the boot loader on the key disk. When I do this the system manages to boot without a passphrase, using the encrypted drive. I suspect there is a problem in installboot(8) in case the keydisk is on the same disk as the crypto volume. The boot(8) program which is the first program to interpret softraid meta data doesn't even get to run in your case. I see, I hope the output I supplied above can give you some insight! Regards, Patrik Lundin -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
Re: crypto softraid and keydisk on same harddrive
On Wed, 29 Oct 2014, Joel Sing wrote:
On Tue, 28 Oct 2014, Patrik Lundin wrote:
[snip]
Since I am not able to boot on the device i have to run installboot as
the last step in the installer. For this i need to add -r /mnt (of
course the following is also copied by hand):
===
# installbook -v -r /mnt sd0
Using /mnt as root
installing bootstrap on /dev/rsd0c
using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot
sd0: softraid volume with 2 disk(s)
sd0: installing boot loader on softraid volume
/mnt/usr/mdec/boot is 5 blocks x 16384 bytes
wd0a: installing boot blocks on /dev/rwd0c, part offset 4225175
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 62910476
/mnt/usr/mdec/biosboot will be written at sector 64
wd0d: installing boot blocks on /dev/rwd0c, part offset 4209110
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 62910476
/mnt/usr/mdec/biosboot will be written at sector 64
===
A CRYPTO key disk is slightly special in that it has softraid metadata but
is not technically part of the same volume (well, it is in some ways but it
is not in others). The problem in question occurs since installboot(8)
installs the first stage boot loader on each chunk that is a member of the
volume - in this case it installs first stage boot loader twice (once for
wd0a and again for wd0d). The second stage boot loader is installed in the
softraid metadata area for the sd0 volume, however in the case of a CRYPTO
key disk its metadata area does not end up with a copy of the boot of the
second stage loader (unlike, say a RAID 1 chunk). If the first stage boot
blocks are installed in the CRYPTO volume then the key disk, the boot
loader (in the PBR of wd0) will end up pointing at a boot storage area (of
the key disk) that does not contain the second stage boot loader. The fix
is to probably avoid installing the boot loader on the key disk.
You could try this (only compile tested) diff:
Index: i386_softraid.c
===
RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v
retrieving revision 1.2
diff -u -p -r1.2 i386_softraid.c
--- i386_softraid.c 9 Jun 2014 13:13:48 - 1.2
+++ i386_softraid.c 28 Oct 2014 14:21:27 -
@@ -42,6 +42,7 @@ void sr_install_bootldr(int, char *);
void
sr_install_bootblk(int devfd, int vol, int disk)
{
+ struct bioc_vol bv;
struct bioc_disk bd;
struct disklabel dl;
struct partition *pp;
@@ -56,6 +57,15 @@ sr_install_bootblk(int devfd, int vol, i
bd.bd_diskid = disk;
if (ioctl(devfd, BIOCDISK, bd) == -1)
err(1, BIOCDISK);
+
+ /* Skip CRYPTO key disks. */
+ /* XXX - pass volume in rather than volume ID. */
+ memset(bv, 0, sizeof(bv));
+ bv.bv_volid = vol;
+ if (ioctl(devfd, BIOCVOL, bv) == -1)
+ err(1, BIOCVOL);
+ if (bv.bv_level == 'C' bd.bd_size == 0)
+ return;
/* Check disk status. */
if (bd.bd_status != BIOC_SDONLINE bd.bd_status != BIOC_SDREBUILD) {
--
Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard
Re: crypto softraid and keydisk on same harddrive
On Wed, Oct 29, 2014 at 01:24:30AM +1100, Joel Sing wrote: You could try this (only compile tested) diff: I tried this diff on 5.5-stable and it appeared to solve my problem! The system now boots from sr0a without asking for a passphrase. Overwriting the keydisk partition makes the bootloader stop at the passphrase prompt. Thanks a lot! Regards, Patrik Lundin
Re: crypto softraid and keydisk on same harddrive
On Sun, Oct 26, 2014 at 09:19:25PM +0100, Patrik Lundin wrote: Hello, I have a usecase for full disk encryption using softraid where the keydisk is placed on the same harddrive as the encrypted partition. This is not for protecting data on the drive in case it gets stolen, but rather to allow for a quick way of making the data unrecoverable (by destroying the keydisk and rebooting). I am not sure this is even supposed to work, but I have now been trying to make this work for a few hours and am getting pretty strange results. I am currently testing this on a virtual machine which when booted into the installer has a single physical drive: wd0. The way i have been going about this is to start the installer, directly drop to a shell and then do the following: # fdisk -iy wd0 # disklabel -E wd0 Create the following partitions (in this order to make the biggest partition last): wd0b (swap) wd0d (RAID) - keydisk (1M) wd0a (RAID) - the remaining part of the drive that will be encrypted. I'd use wd0d instead of wd0a, because 'a' is usually expected to contain a root partition, not a softraid volume. That has nothing to do with the problem at hand though. # bioctl -c C -l /dev/wd0a -k /dev/wd0d softraid0 After this sd0 is created, and i exit back to the installer where i select install and answer all the questions as usual. When it asks for a drive I give it sd0, and use the automatic partition layout inside sd0. Everything looks good at this point, but when rebooting the bootloader stops with the following message: === Using drive 0, partition 3. Loading. ERR M === This error means biosboot(8) can't find the boot(8) program. When booting from softraid, the boot program is stored at a particular offset in the softraid meta data area, and installboot(8) patches that offset into biosboot(8) before copying biosboot(8) to the MBR. Apparently, biosboot(8) has the wrong offset in your case. Your report lacks some information: - architecture (i386 / amd64 / ...) - full output of 'disklabel wd0' to show exactly how you configured partitions - output of running installboot with the -v option on the softraid volume: installboot -v sd0 If I boot back into the the installer at this point sd0 appears automatically, so even while the bootloader does not like what it finds, the softraid crypto device is able to assemble itself like it is supposed to. This is where it gets really funky. I _have_ been able to get it to work using the following schema: #1. Install the system with only wd0b (swap) and wd0a (RAID) using a passphrase. #2. Reinstall the system and modify the disklabel to look like: wd0b (swap), wd0d (RAID, 1M), wd0a. (Like my original plan). When I do this the system manages to boot without a passphrase, using the encrypted drive. I suspect there is a problem in installboot(8) in case the keydisk is on the same disk as the crypto volume. The boot(8) program which is the first program to interpret softraid meta data doesn't even get to run in your case. It feels to me like the key is that in the above order, the keydisk (wd0d) will align to the where wd0a with the passphrase was originally. As if there are some remains that makes it possible for the bootloader to locate it or something (that is not overwritten when it is used as the target for the -k argument. Any input on this would be greatly appreaciated! Regards, Patrik Lundin
Re: crypto softraid and keydisk on same harddrive
Thank you Stefan for taking a look, see comments inline: On Mon, Oct 27, 2014 at 12:32:30PM +0100, Stefan Sperling wrote: On Sun, Oct 26, 2014 at 09:19:25PM +0100, Patrik Lundin wrote: # disklabel -E wd0 Create the following partitions (in this order to make the biggest partition last): wd0b (swap) wd0d (RAID) - keydisk (1M) wd0a (RAID) - the remaining part of the drive that will be encrypted. I'd use wd0d instead of wd0a, because 'a' is usually expected to contain a root partition, not a softraid volume. That has nothing to do with the problem at hand though. Given that wd0d is used for the keydisk, do you mean i should use wd0e for the remainder of the drive instead of 'a'? Would this also mean I should skip creating a sd0a altogether? === Using drive 0, partition 3. Loading. ERR M === This error means biosboot(8) can't find the boot(8) program. When booting from softraid, the boot program is stored at a particular offset in the softraid meta data area, and installboot(8) patches that offset into biosboot(8) before copying biosboot(8) to the MBR. Apparently, biosboot(8) has the wrong offset in your case. Hmm, interesting, thanks for the description! Your report lacks some information: - architecture (i386 / amd64 / ...) I am using amd64. - full output of 'disklabel wd0' to show exactly how you configured partitions I stuck to my original layout for consistency (this has been written down by hand): === # disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: VBOX HARDDISK duid: 175d4587e45a04a5 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 3916 total sectors: 62914560 boundstart: 64 boundend: 62910540 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a:586854454225095RAID b: 4208966 64swap c:62914560 0 unused d: 160654209030RAID === So wd0a is 28GB, wd0b is 2G, and wd0d is 7.8M. - output of running installboot with the -v option on the softraid volume: installboot -v sd0 Since I am not able to boot on the device i have to run installboot as the last step in the installer. For this i need to add -r /mnt (of course the following is also copied by hand): === # installbook -v -r /mnt sd0 Using /mnt as root installing bootstrap on /dev/rsd0c using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot sd0: softraid volume with 2 disk(s) sd0: installing boot loader on softraid volume /mnt/usr/mdec/boot is 5 blocks x 16384 bytes wd0a: installing boot blocks on /dev/rwd0c, part offset 4225175 master boot record (MBR) at sector 0 partition 3: type 0xA6 offset 64 size 62910476 /mnt/usr/mdec/biosboot will be written at sector 64 wd0d: installing boot blocks on /dev/rwd0c, part offset 4209110 master boot record (MBR) at sector 0 partition 3: type 0xA6 offset 64 size 62910476 /mnt/usr/mdec/biosboot will be written at sector 64 === When I do this the system manages to boot without a passphrase, using the encrypted drive. I suspect there is a problem in installboot(8) in case the keydisk is on the same disk as the crypto volume. The boot(8) program which is the first program to interpret softraid meta data doesn't even get to run in your case. I see, I hope the output I supplied above can give you some insight! Regards, Patrik Lundin
Re: crypto softraid and keydisk on same harddrive
On Mon, Oct 27, 2014 at 07:14:10PM +0100, Patrik Lundin wrote: Given that wd0d is used for the keydisk, do you mean i should use wd0e for the remainder of the drive instead of 'a'? Would this also mean I should skip creating a sd0a altogether? Of course i meant Would this also mean I should skip creating a wd0a altogether? Regards, Patrik Lundin
crypto softraid and keydisk on same harddrive
Hello, I have a usecase for full disk encryption using softraid where the keydisk is placed on the same harddrive as the encrypted partition. This is not for protecting data on the drive in case it gets stolen, but rather to allow for a quick way of making the data unrecoverable (by destroying the keydisk and rebooting). I am not sure this is even supposed to work, but I have now been trying to make this work for a few hours and am getting pretty strange results. I am currently testing this on a virtual machine which when booted into the installer has a single physical drive: wd0. The way i have been going about this is to start the installer, directly drop to a shell and then do the following: # fdisk -iy wd0 # disklabel -E wd0 Create the following partitions (in this order to make the biggest partition last): wd0b (swap) wd0d (RAID) - keydisk (1M) wd0a (RAID) - the remaining part of the drive that will be encrypted. # bioctl -c C -l /dev/wd0a -k /dev/wd0d softraid0 After this sd0 is created, and i exit back to the installer where i select install and answer all the questions as usual. When it asks for a drive I give it sd0, and use the automatic partition layout inside sd0. Everything looks good at this point, but when rebooting the bootloader stops with the following message: === Using drive 0, partition 3. Loading. ERR M === If I boot back into the the installer at this point sd0 appears automatically, so even while the bootloader does not like what it finds, the softraid crypto device is able to assemble itself like it is supposed to. This is where it gets really funky. I _have_ been able to get it to work using the following schema: #1. Install the system with only wd0b (swap) and wd0a (RAID) using a passphrase. #2. Reinstall the system and modify the disklabel to look like: wd0b (swap), wd0d (RAID, 1M), wd0a. (Like my original plan). When I do this the system manages to boot without a passphrase, using the encrypted drive. It feels to me like the key is that in the above order, the keydisk (wd0d) will align to the where wd0a with the passphrase was originally. As if there are some remains that makes it possible for the bootloader to locate it or something (that is not overwritten when it is used as the target for the -k argument. Any input on this would be greatly appreaciated! Regards, Patrik Lundin
