Dear Graeme,
In message <4f38f91d.6070...@gmail.com> you wrote:
>
> > Not remove it, but don't give the user an interactive shell when he is
> > running in production mode. You can then still use it in scripts, or
> > when you switch to test mode (which should be doen through a jumper or
> > har
Hi Wolfgang,
On 02/13/2012 06:31 PM, Wolfgang Denk wrote:
>> So basically you are suggesting to completely remove shell access in U-Boot
>> which is one thing that make U-Boot so attractive.
>
> Not remove it, but don't give the user an interactive shell when he is
> running in production mode.
Dear Graeme Russ,
In message
you wrote:
>
> > There is nothing that a boot loadr can do, that cannot be done as well
> > by appropriate Linux kernel code.
>
> Yes, but that access can be controlled through logon credentials after
> the OS has been loaded.
Well spotted. And this is the very r
Hi Wolfgang,
On Mon, Feb 13, 2012 at 6:17 AM, Wolfgang Denk wrote:
> Dear Graeme,
>
> In message <4f378753.4070...@gmail.com> you wrote:
>>
>> > Do not do this in the boot loader. It is not the environment for such
>> > things. When it comes to security, you are automatically pulling in
>> > th
Dear Graeme,
In message <4f378753.4070...@gmail.com> you wrote:
>
> > Do not do this in the boot loader. It is not the environment for such
> > things. When it comes to security, you are automatically pulling in
> > things like encryption technologies, key management, etc. We do not
> > want t
On Sunday 12 February 2012 04:33:07 Graeme Russ wrote:
> Suitable encryption is already in U-Boot (we have SHA and MD5 libraries
> already)
these are hashing functions, not encryption routines
-mike
signature.asc
Description: This is a digitally signed message part.
_
Hi Frans,
On 02/11/2012 08:00 PM, Frans Meulenbroeks wrote:
>
> Graeme, if you want to keep people outisde the bootloader in a
> reasonably safe way and are developing your own hardware an option is
> to put the password in e.g. an eeprom and do a compare in u-boot.
> Of course a persistent hacker
Hi Wolfgang,
On 02/12/2012 07:09 AM, Wolfgang Denk wrote:
> Dear Graeme,
>
> In message <4f35ebbf.3050...@gmail.com> you wrote:
>>
>> I do a lot of work with Programmable Logic Controllers (PLCs) and Remote
>> Telemetry Units (RTUs). One example of what the bootloader is used for is
>> low-level
Dear Frans,
In message
you wrote:
>
> Graeme, if you want to keep people outisde the bootloader in a
> reasonably safe way and are developing your own hardware an option is
> to put the password in e.g. an eeprom and do a compare in u-boot.
> Of course a persistent hacker could retrieve the pass
Dear Graeme,
In message <4f35ebbf.3050...@gmail.com> you wrote:
>
> I do a lot of work with Programmable Logic Controllers (PLCs) and Remote
> Telemetry Units (RTUs). One example of what the bootloader is used for is
> low-level configuration of the analogue input out output channels
> (calibrati
2012/2/11 Graeme Russ :
> Hi Mike,
>
> On 02/11/2012 07:37 AM, Mike Frysinger wrote:
>
>> waving your hands around and saying "doing XXX is more secure and therefore
>> we
>> should do it" is theater. i'm not against passwords or ASLR or anything else
>
> Agreed - I've already said as much in the
Hi Mike,
On 02/11/2012 07:37 AM, Mike Frysinger wrote:
> waving your hands around and saying "doing XXX is more secure and therefore
> we
> should do it" is theater. i'm not against passwords or ASLR or anything else
Agreed - I've already said as much in the ASLR thread
> in u-boot, but lik
Dear Frans,
In message
you wrote:
>
> > If you want security, then don;t allow access to U-Boot at all, and
> > run an OS. There you can do fancy things, including password
> > protection.
>
> The issue is mainly that we would like a service engineer to upgrade
> if for some reason the os goes
2012/2/10 Wolfgang Denk :
> Dear Frans Meulenbroeks,
>
> In message
> you
> wrote:
>> Generally speaking there is a use case for a password.
>
> Of course there is. The question is if the oot loader is the right
> place for it.
>
>> E.g. if you deliver boards/systems with u-boot on it and you d
On Friday 10 February 2012 15:29:05 Mike Frysinger wrote:
> On Friday 10 February 2012 09:12:10 Frans Meulenbroeks wrote:
> > E.g. if you deliver boards/systems with u-boot on it and you do not
> > want customers to enter u-boot (e.g. by accident or because they want
> > to hack the board), but you
On Friday 10 February 2012 09:12:10 Frans Meulenbroeks wrote:
> E.g. if you deliver boards/systems with u-boot on it and you do not
> want customers to enter u-boot (e.g. by accident or because they want
> to hack the board), but you would allow authorized service personnel
> to access the board.
Dear Frans Meulenbroeks,
In message
you wrote:
> Generally speaking there is a use case for a password.
Of course there is. The question is if the oot loader is the right
place for it.
> E.g. if you deliver boards/systems with u-boot on it and you do not
> want customers to enter u-boot (e.g.
Generally speaking there is a use case for a password.
E.g. if you deliver boards/systems with u-boot on it and you do not
want customers to enter u-boot (e.g. by accident or because they want
to hack the board), but you would allow authorized service personnel
to access the board.
For this case
Dear Marek,
In message <201202101330.14119.marek.va...@gmail.com> you wrote:
>
> > Yes, but if you don't allow setting of environment variables from the host
> > OS, how can you change the settings if you need to
>
> You usually don't want to frob with ie. CPU speed of your Xray :-D
Medical devi
Dear Graeme Russ,
In message <4f3505f8.1070...@gmail.com> you wrote:
>
> > We already have such protection, even if it's very simplistic: see
> > doc/README.autoboot (search for CONFIG_AUTOBOOT_DELAY_STR,
> > CONFIG_AUTOBOOT_STOP_STR resp. "bootdelaykey" and "bootstopkey").
>
> OK, so the though
> Hi Wolfgang,
>
> On 02/10/2012 10:38 PM, Wolfgang Denk wrote:
> > Dear Graeme Russ,
> >
> > In message
you wrote:
> >> As an adjunct to a recent discussion, I wonder if there would be much
> >> point in password protecting access to the U-Boot command line. The
> >> password could be saved in
Hi Wolfgang,
On 02/10/2012 10:38 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message
> you
> wrote:
>>
>> As an adjunct to a recent discussion, I wonder if there would be much
>> point in password protecting access to the U-Boot command line. The
>> password could be saved in an enviro
Dear Graeme Russ,
In message
you wrote:
>
> As an adjunct to a recent discussion, I wonder if there would be much
> point in password protecting access to the U-Boot command line. The
> password could be saved in an environment variable as an MD-5 or SHA-256
> hash.
We already have such protec
Hi All,
As an adjunct to a recent discussion, I wonder if there would be much
point in password protecting access to the U-Boot command line. The
password could be saved in an environment variable as an MD-5 or SHA-256
hash.
But I wonder if:
a) It's worth it, and;
b) If it would be secure anyw
24 matches
Mail list logo
