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

[Heinrich Schuchardt]

On 01/25/2018 08:39 PM, Duncan Hare wrote:
>> ----- 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.

A MAC adress can easily be spoofed. So an unauthorized system can
download the initram file system to obtain secret data like /etc/shadow.

Without DNSsec the client cannot be sure to whom he is talking.

 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.

With http the client cannot find out from where he is downloading.

iPXE offers to install an SSL certificate to verify that it is talking
to the right https server and can send user and password over the secure
channel so the server can verify that the client is authorized for the
requested resource. With iSCSI there is only the CHAP protocol for
mutual authentication.

For SSL you need good random numbers. For U-Boot the only viable source
of randomness is the network or a random seed updated by the operating
system. Some SOCs additionally offer an internal source of randomness.

> 
> 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.

Once you have loaded the image and initrd over a secure channel like
https or ipsec the kernel can connect to a network drive using ipsec.

> 
> 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.
> 

The limiting factors for all network protocols are the ping time for
IOps and the bandwidth for download speed. Only NVMe over TCP will bring
a real improvement for IOps.

Some small TCP stacks can only have one request in flight at the same
time which is further limiting.

With iPXE I have been downloading the kernel and intird at over 30 MB/s
which means less than 2 seconds out of 25 seconds for the full reboot on
an Odroid C2.