From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Retanubun Date: Mon, 9 Jul 2012 10:55:18 -0400 Subject: [U-Boot] sha256_crypt for uboot In-Reply-To: <20120709161253.6d856f28@aari01-12> References: <4FEB1CE1.609@ruggedcom.com> <20120705115952.11c4574d@aari01-12> <4FFAE18D.3080809@ruggedcom.com> <20120709161253.6d856f28@aari01-12> Message-ID: <4FFAF0D6.80805@ruggedcom.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >> 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