From: Yegor Yefremov <yegorslists@googlemail.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Sascha Hauer <sha@pengutronix.de>,
barebox <barebox@lists.infradead.org>,
kernel@pengutronix.de
Subject: Re: [PATCH 3/3] bootm: add initial FIT support
Date: Tue, 5 Jan 2016 14:05:28 +0100 [thread overview]
Message-ID: <CAGm1_kuAijx2ZqpJ7aSyLZvSoYDv306QyvtsSA8pRCpFrWM+3Q@mail.gmail.com> (raw)
In-Reply-To: <568BAF11.4090009@pengutronix.de>
On Tue, Jan 5, 2016 at 12:54 PM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 01/05/2016 11:40 AM, Yegor Yefremov wrote:
>> On Tue, Jan 5, 2016 at 11:32 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>>> On 01/05/2016 11:28 AM, Yegor Yefremov wrote:
>>>> Hi Marc,
>>>>
>>>> thanks for reposting the patches.
>>>>
>>>> On Tue, Jan 5, 2016 at 9:11 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>>>>> From: Jan Luebbe <jlu@pengutronix.de>
>>>>>
>>>>> This implementation is inspired by U-Boot's FIT support. Instead of
>>>>> using libfdt (which does not exist in barebox), configuration signatures
>>>>> are verified by using a simplified DT parser based on barebox's own
>>>>> code.
>>>>>
>>>>> Currently, only signed configurations with hashed images are supported,
>>>>> as the other variants are less useful for verified boot. Compatible FIT
>>>>> images can be created using U-Boot's mkimage tool.
>>>>
>>>> What about unsigned images?
>>>
>>> That's not our use case. We use plain zImages instead.
>>
>> The solution would be to introduce an option like in U-Boot?
>>
>> CONFIG_FIT_SIGNATURE:
>>
>> This option enables signature verification of FIT uImages,
>> using a hash signed and verified using RSA. If
>> CONFIG_SHA_PROG_HW_ACCEL is defined, i.e support for progressive
>> hashing is available using hardware, RSA library will use it.
>> See doc/uImage.FIT/signature.txt for more details.
>
> Technically possible, but I'm not sure what are the benefits of using
> fit images, if you don't need signatures. barebox implements
> freedesktop.org's bootspec and this is IMHO the way to go.
For me FIT is just a way to have a kernel and a bunch of device tree
blobs in one file. Signed or not signed is an option for me. Just like
U-Boot implements it. This is user responsibility.
In my use case I just read device ID from EEPROM, load my
kernel-fit.itb and select needed DTB via this ID. This way I have only
one SD card image, that can be run on more, than 10 different devices
using the same core module.
>>>> I also get: unsupported algo crc32
>>>> Is it intended to be supported?
>>>
>>> Not for our usecase - feel free to add crc32 support.
>>
>> OK.
>>
>> But what about FIT configuration selection syntax?
>
> What's this?
Have you seen my comments to this patch regarding
fit_open_configuration() routine?
http://lists.infradead.org/pipermail/barebox/2016-January/025718.html
Yegor
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2016-01-05 13:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 8:11 [PATCH 0/3] FIT Support Marc Kleine-Budde
2016-01-05 8:11 ` [PATCH 1/3] crypto: add enum Marc Kleine-Budde
2016-01-05 16:54 ` Sam Ravnborg
2016-01-06 14:39 ` Marc Kleine-Budde
2016-01-06 16:55 ` Sam Ravnborg
2016-01-05 8:11 ` [PATCH 2/3] crypto: add RSA support Marc Kleine-Budde
2016-01-05 8:11 ` [PATCH 3/3] bootm: add initial FIT support Marc Kleine-Budde
2016-01-05 10:28 ` Yegor Yefremov
2016-01-05 10:32 ` Marc Kleine-Budde
2016-01-05 10:40 ` Yegor Yefremov
2016-01-05 11:54 ` Marc Kleine-Budde
2016-01-05 13:05 ` Yegor Yefremov [this message]
2016-01-05 13:50 ` Marc Kleine-Budde
2016-01-05 13:58 ` Yegor Yefremov
2016-01-07 17:09 ` Jan Lübbe
2016-01-08 10:36 ` Yegor Yefremov
2016-01-05 20:28 ` Trent Piepho
2016-01-06 16:09 ` Marc Kleine-Budde
2016-01-07 17:00 ` Jan Lübbe
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=CAGm1_kuAijx2ZqpJ7aSyLZvSoYDv306QyvtsSA8pRCpFrWM+3Q@mail.gmail.com \
--to=yegorslists@googlemail.com \
--cc=barebox@lists.infradead.org \
--cc=kernel@pengutronix.de \
--cc=mkl@pengutronix.de \
--cc=sha@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