mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Maik Otto <m.otto@phytec.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] habv4: add the possibility to changing the signing area from Kconfig
Date: Wed, 11 Dec 2019 10:10:10 +0100	[thread overview]
Message-ID: <e29fd96e-10ca-26de-d393-6ae95fe3e17e@phytec.de> (raw)
In-Reply-To: <20191211081525.d5vpz2naqlgrf2wv@pengutronix.de>

Hi Sascha,

so do you think we should always start from-dcdofs instead of full?
at the moment i use this configuration with from-dcdofs and i think you
have right, there is
not really a good case to sign the area between 0x00 and dcdofs in the
barebox build
What is the best solution in your opinion?
change default from full to dcdofs in the scripts/imx/imx.c ?
additional delete full and skip-mbr ?

Best regards

Maik


Am 11.12.2019 um 09:15 schrieb Sascha Hauer:
> On Wed, Dec 11, 2019 at 08:57:45AM +0100, Maik Otto wrote:
>> Hi Sascha,
>>
>> in my opinion it is better to have it configurable, because ther are
>> different use cases and security requirements.
>> i found the problem by creating  a sd-card \emmc image with wic.  The
>> mbr, the partition table and bootloader became be signed at barebox
>> build and wic changes
>> the partition table at the end of the build process. Then the sd card
>> image could not boot , because the signature was wrong. yeah secure boot
>> works :-)
>> the highest protection you have, when mbr and partition table is signed
>> with the bootloader, but it is not always necessary.
> But in which cases is it really necessary? I can't think of any. The mbr
> and partition table are not evaluated by the ROM code, hence they do not
> need to be signed for HAB.
>
> The images generated by the build system all do not have a partition table
> included, so basically we are currently enforcing no partition table at
> all which is just not useful.
>
> I think the current way of including the first KiB in signed area comes
> from the fact that we started doing HAB on a NAND device which doesn't
> have a partition table. Other projects we are currently doing use eMMC
> where we use the boot partitions, again no MBR or partition table.
>
> If we had started on SD cards, we wouldn't have included the partition
> table in the signature and also would never have thought it would be a
> good idea to do so.
>
> Regards
>  Sascha
>


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2019-12-11  9:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 15:06 Maik Otto
2019-12-10 15:21 ` Sascha Hauer
2019-12-11  7:57   ` Maik Otto
2019-12-11  8:15     ` Sascha Hauer
2019-12-11  9:10       ` Maik Otto [this message]
2019-12-13  8:25         ` Sascha Hauer

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=e29fd96e-10ca-26de-d393-6ae95fe3e17e@phytec.de \
    --to=m.otto@phytec.de \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.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