[U-Boot] [PATCH 2/4] fdt: Add Kconfig options to control code size

[Simon Glass]

Hi Heinrich,

On Sun, 27 Oct 2019 at 12:06, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 10/27/19 4:47 PM, Simon Glass wrote:
> > For better or worse libfdt recent grew a lot of code that checks the
> > validity of the device tree in great detail. When using unsigned or
> > unverified data this makes things safer, but it does add to code size.
> >
> > Add some controls to select the trade-off between safety and code size.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> >   lib/Kconfig         | 33 +++++++++++++++++++++++++++++++++
> >   lib/libfdt/Makefile |  3 ++-
> >   2 files changed, 35 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index 135f0b372b..b8a8509d72 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -464,6 +464,17 @@ config OF_LIBFDT
> >         particular compatible nodes. The library operates on a flattened
> >         version of the device tree.
> >
> > +config OF_LIBFDT_ASSUME_MASK
> > +     hex "Mask of conditions to assume for libfdt"
> > +     depends on OF_LIBFDT || FIT
> > +     default 0
> > +     help
> > +       Use this to change the assumptions made by libfdt about the
> > +       device tree it is working with. A value of 0 means that no assumptions
> > +       are made, and libfdt is able to deal with malicious data. A value of
>
> What do you mean by malicious here?

Someone trying to compromise the system with a carefully crafted DT.

>
> The checks in libfdt are about inconsistent FDT files. But they would
> not discover malicious settings like a destructive voltage or frequency.

That's right. To cover that people should probably use verified boot.

>
> Would FDT_ASSUME_SANE match what we have been checking up to now? Why
> not use 1 as the default here to reduce the code size of U-Boot?

Possibly. I'm open to changing this as the code size increase is a paind.

But most of the new checking code could be dropped by enabling
FDT_ASSUME_FRIENDLY. Take a look at that and see what you think.

>
> > +       0xff means all assumptions are made and any invalid data may cause
> > +       unsafe execution. See FDT_ASSUME_PERFECT, etc. in libfdt_internal.h
> > +
> >   config OF_LIBFDT_OVERLAY
> >       bool "Enable the FDT library overlay support"
> >       depends on OF_LIBFDT
> > @@ -481,6 +492,17 @@ config SPL_OF_LIBFDT
> >         particular compatible nodes. The library operates on a flattened
> >         version of the device tree.
> >
> > +config SPL_OF_LIBFDT_ASSUME_MASK
> > +     hex "Mask of conditions to assume for libfdt"
> > +     depends on SPL_OF_LIBFDT || FIT
> > +     default 0xff
>
> On some devices the device tree is provided by the device (e.g. QEMU).
> Is it wise to set FDT_ASSUME_LATEST in this case?

Well I think we have been on the current version for about 13 years,
so probably.

Regards,
Simon
[..]