public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Richard Retanubun <richardretanubun@ruggedcom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] sha256_crypt for uboot
Date: Mon, 9 Jul 2012 10:55:18 -0400	[thread overview]
Message-ID: <4FFAF0D6.80805@ruggedcom.com> (raw)
In-Reply-To: <20120709161253.6d856f28@aari01-12>

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

Uh-oh... Is it safe to place such a high concentration of hacker brains
so close to CERN? :)

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

This is the hints I am getting from reading past conversations in the
mailing list as well, which I why I am testing the waters before
finalizing the patch.

>
>> 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.
>
In principal I agree.

In practice, for situations where one does not control the payload,
how does one ensure it is trusted?

Our current approach is to say "as long as the automatic boot sequence is not
modified, everything in the execution sequence is trusted. When an operator
need to deviate from that auto boot sequence, then the operator needs
to be authenticated."

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

Understood. For the time being, I'll aim to make my modifications to the
source as standalone as I can so I don't get hit with merge conflicts.

Thanks for your time!

-- Richard Retanubun

  reply	other threads:[~2012-07-09 14:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 14:46 [U-Boot] sha256_crypt for uboot Richard Retanubun
2012-07-05  9:59 ` Albert ARIBAUD
2012-07-09 13:50   ` Richard Retanubun
2012-07-09 14:12     ` Albert ARIBAUD
2012-07-09 14:55       ` Richard Retanubun [this message]
2012-07-09 15:56         ` Albert ARIBAUD
2012-07-09 19:38     ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FFAF0D6.80805@ruggedcom.com \
    --to=richardretanubun@ruggedcom.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox