On Saturday 25 April 2015, Patrik Lundin wrote:
> On Wed, Oct 29, 2014 at 01:24:30AM +1100, Joel Sing wrote:
> > On Wed, 29 Oct 2014, Joel Sing wrote:
> > > 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 -0000 1.2
> > +++ i386_softraid.c 28 Oct 2014 14:21:27 -0000
> > @@ -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) {
> >
>
> Any developer feel like looking at merging this diff? It seems jsing is
> busy with other work. My interest in this is that it is helpful for
> OpenBSD machines used at Dreamhack (http://dreamhack.se) to quickly
> decommision them when the festival is over.
>
> The original thread can be found here:
> http://marc.info/?l=openbsd-misc&m=141435482820277&w=2
Apologies for not getting back to look at this - the above diff is in part a
hack and it needs to be more cleanly implemented before it is committed.
Additionally, it needs to be implemented and tested for all platforms that
support softraid boot. I'll attempt to get this done over the next couple of
weeks.
In the meantime, as previously mentioned, the more effective way of clearing a
softraid crypto volume is to recreate the volume with 'bioctl -C force' (or
even just dd over the first 1MB of the RAID partition) - that nukes the keys
that were used to encrypt the data, making the key disk or passphrase
completely useless. Also, keep in mind that anyone who has root access on
these machines has the ability to copy the key disk, the softraid metadata
with the encrypted disk keys and even the unencrypted disk encryption keys
once they're in memory...
--
"Action without study is fatal. Study without action is futile."
-- Mary Ritter Beard
