[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Pantelis Antoniou <panto@intracom.gr>]

Wolfgang Denk wrote:

>Dear Pantelis,
>
>in message <3E9EBB5B.4030609@intracom.gr> you wrote:
>
>>>>o Two level access password support.
>>>>
>>>>
>>>What do you mean with "two level"?
>>>
>>>
>>By two level I mean that when something is deployed normally there are 
>>two access
>>levels. One level is the user level, which is allowed to view settings 
>>and alter
>>very few parameters. The other level is the administrator level in which 
>>it is
>>permitted to do (almost) anything.
>>
>
>I cannot see a way to implement this  without  dramatically  changing
>the  functionality and code of U-Boot. You cannot easily restrict the
>user from - for example - overwriting certain  environment  variables
>without castrating him from the power of defining his own settings.
>
>I feel when you need such a level of authentification then the  boot
>loader is not the right environment for your task - use an OS.
>
We already use an OS. The problem is that the device's user/person who
has physical access to it, is not supposed to be allowed to alter anything
in the configuration; especially the network settings, since an error there
will render the device unoperable.
Think access control on a router or something similar.

True, it's a problem on how to implement it cleanly. We'll see how that 
will
turn out. A first simple step will be to have a single password for
entering the command mode.

>
>>>>o Different boot-modes.
>>>>
>>>>
>>>Please explain. There already are different boot modes, with a lot of
>>>configuration options depending on the specific board.
>>>
>>>
>>Sure. Depending on the deployment method for each site the configuration
>>of the devices differ.
>>
>>For example when you do a trial deployment it is pretty normal to have every
>>device configured individually  by the  administration.  In normal operation
>>the devices operate using DHCP/TFTP for obtaining their settings. In both
>>of these modes password are honoured, and the booting of the kernel is
>>immediate
>>Developers in the other hand are working in a
>>different level and like access to everything including to be able to
>>do a full factory-type resetting of the paramers.
>>
>>Think of it as simplified run-levels.
>>
>
>OK, but which of this part needs new or modified code? All  this  can
>be done with U-Boot as is now.
>
Almost nothing actually, it's just a method of managing the existing 
settings
by using a master switch.

>
>>>How good is your German? Can you parse board/lwmon/README.keybd ?
>>>
>>>
>>My German is not existant unfortunately, but I'll pass it to a collegue 
>>who is fluent.
>>
>
>Thanks. I guess I should provide an Engish version one day, too.  But
>so  far,  all  our  customers  who  used  features like that are from
>Germany, and insisted on German docs.
>
>
>>>>o Cisco router like command interface with history and command completion.
>>>>
>>>But please do not try to add readline support - the readline  lib  is
>>>way too big...
>>>
>>>
>>No it is not like readline. It is much more light-weight, the current 
>>version
>>weighs in at about 12k.
>>
>
>Light-weight? Ummm... that's about 10 times (or more) the size of the
>existing command line parser.
>
Oh well, it's pretty light weight for what it does ;)

>
>>DNS lookup capability. Yes I know that it is strange but actually some DHCP
>>options can return hostnames so it is needed.
>>
>
>Really? Which one? (Which RFC?)
>
RFC2132

For example:

Option #66 TFTP Server Name
Option #69 SMTP Server Name
Option #70 POP3 Server Name
etc.

I know, only the first one is actually meaningful for a boot loader.

>>Wolfgang you are free to veto anything that you deem unacceptable;
>>the best I can do is to present my case for the inclusion of these features.
>>
>
>In general I follow the very simple principle that something which is
>beneficial to one ore more people without hurting others is good  and
>will be added. 
>
>Best regards,
>
>Wolfgang Denk
>
>
I know, and I appreciate it.

Regards

Pantelis