[U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI

[Duncan Hare]

> ----- Forwarded Message -----
>  From: Alexander Graf <agraf at suse.de>
>  To: Heinrich Schuchardt <xypron.glpk at gmx.de> 

> > The appended README explains how U-Boot and iPXE can be used
> > to boot a diskless system from an iSCSI SAN.
> >
> > The maintainer for README.efi and README.iscsi is set.
> >
> > Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> > ---
> +U-Boot has only a reduced set of supported network protocols. A
> major gap is
> > major gap is +the lack of a TCP stack.  
> 
> This is only semi-true. There is work in progress to get TCP support 
> into U-Boot. The protocols on top however are still missing and using 
> iPXE here is definitely a very reasonable approach.

We are implementeinga limited TCP and a wget (http 1.0) app.
It is almost ready for an test release. Selective Acknowledgment (SACK)
is under test as a final piece of the TCP stack.

We have noticed that omitting the http 1.0 declaration in
downloading the kernel from an nginx web server that we remove the
overhead of an http header completely.

> 
> > +
> > +For booting a diskless computer this leaves us with BOOTP or DHCP
> > to get the +address of a boot script. TFTP can be used to load the
> > boot script and the +operating system kernel and initial file
> > system (initrd). 

We use DHCP or DNS. DHCP assumes one has control of the DHCP server and
are generally inside the firewall, and is complex to adminsited is
there are many (branch office) DHCP servers. With MS 2012 R2 server
configuring DHCP options is complex.

> > +These protocols are insecure. The client cannot validate the
> > authenticity +of the contacted servers. And the server cannot
> > verify the identity of the +client.

Yes and no. We (optionally) use the burnt in MAC address or serial
number to identify a client machine, and can prevent boot if it is not
authorized by denying the download of the *nix kernel. If inside 
the firewall and using DHCP security is probably completly under
the control of the enterprise admins. We use locally
administered DNS servers to control address resolution under DNS.

> > iPXE is the
> > "swiss army knife" of +network booting. It supports both HTTPS and
> > iSCSI. It has a script engine for +fine grained control of the boot
> > process and can provide a command shell. +

(1)u-boot (+ missing functions)->iPXE->grub->kernel (appears complex)
or
(2)u-boot (+ missing functions)->kernel?

> > +protocol. Now iPXE can call the simple file protocol to load Grub.

I seem to be missing the point. We use U-boot to load and run
the kernel with tcp+http 1.0. https would be a nice enhancement, as
would an encrypted connection for the *nix kernel to access the image,
but complete security requires more.

If you are going to do this we need to discuss accessing the *nix
image over a secure protocol. AFAIK the *nix kernel does not
use secure protocols with network *nix images.

In the netboot process we'd address the performance limitations of NFS, 
especially during boot, with either lookahead caching at the client or
use HTTPS for image access, both of which are outside u-boot's scope.