Hi Simon,
On 28/06/2016 20:43, Simon Glass wrote:
Hi,
On 27 June 2016 at 03:38, Stefano Babic sbabic@denx.de wrote:
Hi Andrej,
On 20/06/2016 18:18, Andrej Rosano wrote:
I ten to NACK this. You can do exactly the same with a U-Boot script, and if you want to have this as default, you can change your default environment. This is just a wrapper around the hush shell.
The intention of the patch is to boot the kernel while having the CLI disabled (CONFIG_CMDLINE=n). The U-Boot script needs the CLI to be enabled AFAIK.
It is better having the CLI disabled when using the Verified Boot, otherwise there are chances to bypass the FIT image verification (e.g. using md/mw commands in case are available):
Why is it not enough to disable the CONSOLE ? I mean, if there is no user interface (and this is done in a lot of ways, for example setting stdin / stdout), there is no ways to bypass it because the interface is not availabel. Or is there some other security issues I am not aware of ?
It is an extra level of security - providing a very simple command execution instead of the general CLI. That is actually the original purpose of board_run_command(). E.g. for Chrome OS we had an option to either run the normal CLI or a simple (secure) one. Also see cli_process_fdt() which provides for a 'bootsecure' mode, controlled from the FDT.
I see, thanks for explanation. My fear is that the process diverges and boards start to embed U-Boot scripts inside the code, letting them not very maintainable. But I have understood the issue and I put this patch for merging in my queue.
Best regards, Stefano