Re: AMD Secure Encrypted Virtualization - FreeBSD Status?

From: Simon J. Gerraty <sjg_at_juniper.net>
Date: Mon, 14 Oct 2019 13:21:38 -0700
Clay Daniels Jr. <clay.daniels.jr_at_gmail.com> wrote:

> Simon, please do elaborate more on your implementation. I suspect you are
> talking about libsecureboot? I have played with the generation of certs
> with OpenSSL & LibreSSL, but libsecureboot seems to take a different
> approach. Please tell us more.

Yes I meant libsecureboot.

You should be able to create keys and certs with OpenSSL.
That's all we use, but we keep all the private keys etc isolated in
signing servers.  The local.trust.mk in libsecureboot leverages the
sign.py etc described at
http://www.crufty.net/sjg/blog/signing-server.htm
(which also contains a link to the src)

But that does not alter the fact that the certs are simply those created
by an OpenSSL based CA - there are a number of good tutorials on the net
on how to setup such things.

With all that said; you may find it more useful to use OpenPGP for
signing we again use sign.py to retrieve OpenPGP public key, but you can
do all you need using nothing more than gpg

For an embedded vendor like Juniper X.509 makes a lot of sense.
For an individual or small scale, OpenPGP is likely simpler.
libsecureboot supports both, but you need to tailor local.trust.mk to
suit.

IIRC you can have local.trust.mk simply set TA_PEM_LIST etc to paths of
pre-prepared pem files containing your trust anchors and ta.h
and/or TA_ASC_LIST to a list of .asc files containing ascii armored
openpgp trust anchors.

BTW in current boot1.efi is no more, loader.efi is used.
[I'm still mucking about trying to get a VM image booting using efi...]


> 
> Clay
> 
> On Mon, Oct 14, 2019 at 1:52 PM Simon J. Gerraty via freebsd-security <
> freebsd-security_at_freebsd.org> wrote:
> 
> > Tomasz CEDRO <tomek_at_cedro.info> wrote:
> >
> > > would be really nice also to get UEFI BOOT compatible with SECURE BOOT
> > :-)
> >
> > Unless you are using your own BIOS, the above means getting Microsoft
> > to sign boot1.efi or similar. Shims that simply work around lack of
> > acceptible signature don't help.
> >
> > That would need to then verify loader.efi - which can be built to
> > to verify all the modules and kernel.
> >
> > In my implementation (uses the non efi loader) trust anchors are
> > embedded in loader but there is code in current to lookup trust anchors
> > in /efi I think which would be more generally useful - I've not looked
> > at the attack vectors that introduces though.
> >
> > --sjg
> > _______________________________________________
> > freebsd-security_at_freebsd.org mailing list
> > https://urldefense.com/v3/__https://lists.freebsd.org/mailman/listinfo/freebsd-security__;!8WoA6RjC81c!TLaVmP78NH0BviSHHV_3_V0-ispe2o0I7E59vmxZ_8XnbmOYxeHxemscoWsaXA$ 
> > To unsubscribe, send any mail to "freebsd-security-unsubscribe_at_freebsd.org
> > "
> >
Received on Mon Oct 14 2019 - 18:21:48 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC