From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH 1/1] rsa: fix retrieving public exponent on big-endian systems
Date: Fri, 9 Oct 2020 09:08:07 -0400 [thread overview]
Message-ID: <20201009130807.GD14816@bill-the-cat> (raw)
In-Reply-To: <089270b6-b2a4-26f8-ac4f-a04e79b29c42@prevas.dk>
On Wed, Oct 07, 2020 at 12:17:56AM +0200, Rasmus Villemoes wrote:
> On 07/10/2020 00.02, Simon Glass wrote:
> > Hi Rasmus,
> >
> > On Tue, 6 Oct 2020 at 04:10, Rasmus Villemoes
> > <rasmus.villemoes@prevas.dk> wrote:
> >>
> >> Commit fdf0819afb (rsa: fix alignment issue when getting public
> >> exponent) changed the logic to avoid doing an 8-byte access to a
> >> possibly-not-8-byte-aligned address.
> >>
> >> However, using rsa_convert_big_endian is wrong: That function converts
> >> an array of big-endian (32-bit) words with the most significant word
> >> first (aka a BE byte array) to an array of cpu-endian words with the
> >> least significant word first. While the exponent is indeed _stored_ as
> >> a big-endian 64-bit word (two BE words with MSW first), we want to
> >> extract it as a cpu-endian 64 bit word. On a little-endian host,
> >> swapping the words and byte-swapping each 32-bit word works, because
> >> that's the same as byte-swapping the whole 64 bit word. But on a
> >> big-endian host, the fdt32_to_cpu are no-ops, but
> >> rsa_convert_big_endian() still does the word-swapping, breaking
> >> verified boot.
> >>
> >> To fix that, while still ensuring we don't do unaligned accesses, add
> >> a little helper that first memcpy's the bytes to a local fdt64_t, then
> >> applies fdt64_to_cpu(). [The name is chosen based on the
> >> [bl]eXX_to_cpup in linux/byteorder/generic.h].
> >>
> >> Fixes: fdf0819afb ("rsa: fix alignment issue when getting public exponent")
> >> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> >> ---
> >> lib/rsa/rsa-mod-exp.c | 11 +++++++++--
> >> 1 file changed, 9 insertions(+), 2 deletions(-)
> >>
> >
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> >
> > Is there a way to add a test for this?
>
> Not that I can think of, other than finding some BE board and hooking it
> up in some CI. Apparently not very many people use verified boot on BE
> platforms :( or at least they don't follow upstream U-Boot closely.
We have tests for verified boot for sandbox. Can we not expand them to
run on qemu* including ppce500?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201009/18428f29/attachment.sig>
next prev parent reply other threads:[~2020-10-09 13:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 14:10 verified boot changes since 2020.04 Rasmus Villemoes
2020-10-06 10:09 ` [PATCH 0/1] fix verified boot on BE hosts Rasmus Villemoes
2020-10-06 10:09 ` [PATCH 1/1] rsa: fix retrieving public exponent on big-endian systems Rasmus Villemoes
2020-10-06 22:02 ` Simon Glass
2020-10-06 22:17 ` Rasmus Villemoes
2020-10-09 13:08 ` Tom Rini [this message]
2020-10-12 7:04 ` Rasmus Villemoes
2020-10-12 11:41 ` Tom Rini
2020-10-12 16:54 ` Simon Glass
2020-10-13 14:07 ` Tom Rini
2020-10-12 3:34 ` verified boot changes since 2020.04 Simon Glass
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=20201009130807.GD14816@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.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