Re: [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
----- Forwarded Message ----- From: Alexander Graf agraf@suse.de To: Heinrich Schuchardt xypron.glpk@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@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.
On 01/25/2018 08:39 PM, Duncan Hare wrote:
----- Forwarded Message ----- From: Alexander Graf agraf@suse.de To: Heinrich Schuchardt xypron.glpk@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@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.
On 01/25/2018 08:39 PM, Duncan Hare wrote:
----- Forwarded Message ----- From: Alexander Graf agraf@suse.de To: Heinrich Schuchardt xypron.glpk@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@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 implementing a 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.
In which git can I find the code?
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.
I would prefer if the implementation were compliant with either of RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 or RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0
You should not program to please another accommodating software but according to a standard.
The key to TCP performance is supporting multiple packets in flight.
Best regards
Heinrich
participants (3)
-
Duncan Hare -
Heinrich Schuchardt -
Heinrich Schuchardt