linux-kernel - Re: [PATCH 5/5] misc: sram: add Atmel securam support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 31 Aug 2016 19:04:56 +0200
From:   Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:     Philipp Zabel <p.zabel@...gutronix.de>
Cc:     Nicolas Ferre <nicolas.ferre@...el.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
Subject: Re: [PATCH 5/5] misc: sram: add Atmel securam support

On 31/08/2016 at 18:45:37 +0200, Philipp Zabel wrote :
> Hi Alexandre,
> 
> Am Mittwoch, den 31.08.2016, 18:11 +0200 schrieb Alexandre Belloni:
> > The Atmel secure SRAM is connected to a security module and may be erased
> > automatically under certain conditions. For that reason, it is necessary to
> > wait for the security module to flag that SRAM accesses are allowed before
> > accessing it.
> > 
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
> > ---
> > Cc: Arnd Bergmann <arnd@...db.de>
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Cc: Philipp Zabel <p.zabel@...gutronix.de>
> > Cc: Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
> >  drivers/misc/sram.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-------
> >  1 file changed, 45 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> > index f84b53d6ce50..8d411c64d07f 100644
> > --- a/drivers/misc/sram.c
> > +++ b/drivers/misc/sram.c
> > @@ -19,12 +19,16 @@
> >   */
> >  
> >  #include <linux/clk.h>
> > +#include <linux/delay.h>
> >  #include <linux/genalloc.h>
> >  #include <linux/io.h>
> >  #include <linux/list_sort.h>
> >  #include <linux/of_address.h>
> >  #include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> >  #include <linux/slab.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <soc/at91/atmel-secumod.h>
> >  
> >  #define SRAM_GRANULARITY	32
> >  
> > @@ -334,12 +338,43 @@ static int sram_reserve_regions(struct sram_dev *sram, struct resource *res)
> >  	return ret;
> >  }
> >  
> > +static int atmel_securam_wait(void)
> > +{
> > +	struct regmap *regmap;
> > +	unsigned long timeout = jiffies + HZ;
> 
> Can this really take up to a second?
> 

Well, probably not but it can take some time. My understanding is that
it can take up to almost half a second (4096 bytes at 8kHz). But quite
frankly, by the time linux is starting, the delay has probably already
expired so the while loop is unlikely to run.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com