All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Buffer overrun risk in UBI SPL for secure boot
Date: Wed, 4 Sep 2019 15:01:35 +0200	[thread overview]
Message-ID: <85b1fcdc-6aad-1971-f36c-547972e8223e@denx.de> (raw)
In-Reply-To: <CAN3=V2uFjA3xWNHbUXuqVA-yri2FuOajb_LpcjP1fWfznrmXEQ@mail.gmail.com>

Hello Joel,

Am 04.09.2019 um 06:57 schrieb Joel Peshkin:
> It seems that, in the process of doing any sort of secure boot chain of
> trust, anything loading a UBI volume in preparation to authenticate it,
> will load a volume of unknown size into a buffer prior to checking the
> signature of that volume.

Hmm.. it is not an unknown size, it loads the complete UBI Volume, so
it is the size of the UBI Volume ...
but yes, if an attacker changes the size of UBI Volumes ...

Could you please give us a reference to which piece of code you refer?

is it this part:

drivers/mtd/ubispl/ubispl.c
static int ipl_load(struct ubi_scan_info *ubi, const u32 vol_id, uint8_t *laddr)

yes ... no size...

> Has anyone considered a solution for this?  Should all implementations just
> carve out a buffer at the top of memory for ubispl_load_volume or should
> the ubispl_load data structure be amended to include a size?  It would seem
> appropriate to include a size, but not clear how to do that without
> breaking compatibility with existing implementations.

Hmm... yes may an option to add a maxsize to ubispl_load data struct
ubispl_load.

regarding backwards compatibility, there are not much boards yet, which
use this feature:

hs at threadripper:u-boot  [master] $ grep -lr SPL_UBI | grep defconfig
configs/am335x_igep003x_defconfig
configs/igep00x0_defconfig
hs at threadripper:u-boot  [master] $

So this should be solveable problem.

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

  reply	other threads:[~2019-09-04 13:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-04  4:57 [U-Boot] Buffer overrun risk in UBI SPL for secure boot Joel Peshkin
2019-09-04 13:01 ` Heiko Schocher [this message]
2019-09-04 14:19   ` Joel Peshkin
2019-09-09 21:48     ` Joel Peshkin

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=85b1fcdc-6aad-1971-f36c-547972e8223e@denx.de \
    --to=hs@denx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.