From: Sascha Hauer <s.hauer@pengutronix.de>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: barebox@lists.infradead.org, Christian Eggers <ceggers@arri.de>
Subject: Re: Configuring for secure boot
Date: Tue, 21 Jan 2020 12:11:44 +0100 [thread overview]
Message-ID: <20200121111144.cilncfjpucugt7ne@pengutronix.de> (raw)
In-Reply-To: <2df2f2dc-06ed-c85e-b37e-313e1ef51538@pengutronix.de>
On Tue, Jan 21, 2020 at 11:52:02AM +0100, Ahmad Fatoum wrote:
> Hello,
>
> On 1/20/20 8:53 PM, Sascha Hauer wrote:
> > Disabling the shell entirely with CONFIG_SHELL_NONE is the best you can
> > do. This also forces you to program your boot process in C which helps
> > you to get a well defined boot without diving into potentially unsafe
> > shell commands.
> >
> > To state the obvious, you have to enable HAB support, sign your barebox
> > images and burn the necessary fuses to forbid loading unsigned images.
>
> I think it would be great to have a CONFIG_LOCKDOWN option that has inverse
> dependencies on the stuff that should not be enabled and normal dependencies
> on the stuff that should be. Such a CONFIG_LOCKDOWN barebox can then be used in
> secure boot scenarios or for fuzzing efforts.
>
> Thoughts?
I don't think this is feasible. There are too many different expectations
what is secure and what is not. loadenv/saveenv might be desired at some
point (at least when we add signing support), for others it's a no-go.
Some accept the potential security risk of having a shell, others don't.
You might want to build a device which can boot in a secure mode with
signed kernels only, or alternatively any other kernel after dropping
the security privileges in the CAAM or whatever. That's just some
examples off the top of my head, there are surely more.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2020-01-21 11:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-20 16:38 Christian Eggers
2020-01-20 19:53 ` Sascha Hauer
2020-01-21 10:52 ` Ahmad Fatoum
2020-01-21 11:11 ` Sascha Hauer [this message]
2020-01-23 10:29 ` Configuring for secure boot / Using bootchooser Christian Eggers
2020-01-27 10:07 ` Sascha Hauer
2020-01-27 10:18 ` [RFC PATCH] bootm: Register as bootentry provider Christian Eggers
2020-01-27 12:49 ` Sascha Hauer
2020-01-27 19:26 ` Christian Eggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200121111144.cilncfjpucugt7ne@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=ceggers@arri.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox