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

[Tom Rini]

On Sun, Oct 27, 2019 at 12:49:28PM -0600, Simon Glass wrote:
> 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.

Right, so the help text can be clarified a little bit more to be clear
that it's checking for various types of formatting and construction
problems with that data only.

> > 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.

We also need to be careful as the defaults we push here are the defaults
that will be used when companies build their product on top.  I'm in
favor of the default being as much sanity checking as we an afford and
to note and allow for instances where other safeguards exist, or more
risk is tolerated to save some size.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191028/673801ae/attachment.sig>