[U-Boot] sha256_crypt for uboot

Albert ARIBAUD albert.u.boot at aribaud.net
Mon Jul 9 16:12:53 CEST 2012


Hi Richard,

On Mon, 9 Jul 2012 09:50:05 -0400, Richard Retanubun
<richardretanubun at ruggedcom.com> wrote:
> On 05/07/12 05:59 AM, Albert ARIBAUD wrote:
> Hi Albert,
> 
> Thanks for responding, I realize most people are probably away on
> summer holiday.

Actually some of them are at a U-Boot developer's meeting in Geneva.

> > Can't speak for Wolfgang of course, but my main question would be
> > why would U-Boot need to identify users when its payload OS can do
> > this with much more ease and flexibility?
>  > IOW, what use case are you considering?
> 
> The primary concern here is the power of u-boot CLI. Once here,
> someone can manually load and boot the payload OS in a different mode
> that can bypass any user identification.

Ok, so this risk scenario is about untrusted payloads, not about
untrusted individuals. The difference is that u-boot already has a
concept of 'payload' but does not have or need any concept of 'user' so
far.

> Thus, we aim to add the ability uboot to identify users, much like
> the payload OS does before granting access to its CLI (if the user
> interrupts the boot process).

This risk mitigation answer seems to address another risk than the one
above, i.e. you could address the risk above just as with payload trust
(i.e., some form of trusted boot) without needing to introduce a whole
user identification system.

> So far I got sha256_crypt() and sha512_crypt() working (sha512 is a
> bit slow due to non-arch optimized string lib functions, but its
> working okay).
> 
> If there is interest in sha512, I can send it as a separate patch.
> 
> One question to the mailing list though, the sha256_context struct
> that exist in u-boot
> 
> typedef struct {
> 	uint32_t total[2];
> 	uint32_t state[8];
> 	uint8_t buffer[64];
> } sha256_context;
> 
> Is a little different from the one in libc (i.e. it adds buflen and
> has a 128 char buffer)
> 
> struct sha256_ctx {
> 	uint32_t H[8];
> 	uint32_t total[2];
> 	uint32_t buflen;
> 	char buffer[128]; /* NB: always correctly aligned for
> uint32_t.  */ };
> 
> I can't seem to find mainlined boards that uses sha256.h (I am sure
> there are private ones)
> 
> Is it okay if I update the sha256.[ch] API to track the
> implementation from libc?

For the time being, I am still failing to see a viable reason for
introducing user management in mainline u-boot at all: it seems only
your solution (not even your problem) needs it.

> -- Richard Retanubun --

Amicalement,
-- 
Albert.


More information about the U-Boot mailing list