[U-Boot] [PATCH 2/3] powerpc/p1010rdb: SECURE BOOT- enable workaround for IFC errata A003399

[aneesh.bansal at freescale.com]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, January 29, 2014 2:38 AM
> To: Bansal Aneesh-B39320
> Cc: u-boot at lists.denx.de; Sun York-R58495
> Subject: Re: [PATCH 2/3] powerpc/p1010rdb: SECURE BOOT- enable workaround
> for IFC errata A003399
> 
> On Sun, 2014-01-26 at 23:27 -0600, Bansal Aneesh-B39320 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, January 21, 2014 3:36 AM
> > > To: Bansal Aneesh-B39320
> > > Cc: u-boot at lists.denx.de; Sun York-R58495
> > > Subject: Re: [PATCH 2/3] powerpc/p1010rdb: SECURE BOOT- enable
> > > workaround for IFC errata A003399
> > >
> > > On Mon, 2014-01-20 at 14:57 +0530, Aneesh Bansal wrote:
> > > > The workaround for IFC errata A003399 was not enabled in case of
> > > > secure boot. So, secure boot from NOR was not working.
> > > >
> > > > Signed-off-by: Aneesh Bansal <aneesh.bansal at freescale.com>
> > > > ---
> > > >  include/configs/P1010RDB.h | 3 +--
> > > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > >
> > > > diff --git a/include/configs/P1010RDB.h
> > > > b/include/configs/P1010RDB.h index c21cf07..b0e51fb 100644
> > > > --- a/include/configs/P1010RDB.h
> > > > +++ b/include/configs/P1010RDB.h
> > > > @@ -455,8 +455,7 @@ extern unsigned long get_sdram_size(void);
> > > > #endif
> > > >
> > > >  #ifdef CONFIG_SYS_FSL_ERRATUM_IFC_A003399
> > > > -#if !defined(CONFIG_SPL) && !defined(CONFIG_SYS_RAMBOOT)\
> > > > -	&& !defined(CONFIG_SECURE_BOOT)
> > > > +#if !defined(CONFIG_SPL) && !defined(CONFIG_SYS_RAMBOOT)
> > > >  #define CONFIG_A003399_NOR_WORKAROUND  #endif  #endif
> > >
> > > Why do you need the workaround?  Doesn't secure boot involve the
> > > bootrom loading U-Boot into SRAM, rather than execute-in-place from
> NOR?
> > >
> > > -Scott
> > >
> > The Boot ROM code does not copy the U-boot from NOR into SRAM. In case
> > of secure boot from NOR, it is executed as an execute-in-place memory
> > and so this workaround is required.
> 
> That doesn't sound very secure.
> 
> -Scott
> 
Can you please elaborate on the kind of security threats that you see with this approach.
If you are concerned about someone replacing the NOR flash at runtime, then we have the
Hardware Tamper detect mechanism to deal with that.
So, currently the bootROM code does not copy from NOR to SRAM.