* [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
@ 2018-01-22 18:34 Heinrich Schuchardt
2018-01-25 17:47 ` Alexander Graf
0 siblings, 1 reply; 8+ messages in thread
From: Heinrich Schuchardt @ 2018-01-22 18:34 UTC (permalink / raw)
To: u-boot
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>
---
MAINTAINERS | 2 +
doc/README.iscsi | 178 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 180 insertions(+)
create mode 100644 doc/README.iscsi
diff --git a/MAINTAINERS b/MAINTAINERS
index d459153503..6e94cee5d3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -286,6 +286,8 @@ EFI PAYLOAD
M: Alexander Graf <agraf@suse.de>
S: Maintained
T: git git://github.com/agraf/u-boot.git
+F: doc/README.efi
+F: doc/README.iscsi
F: include/efi*
F: lib/efi*/
F: test/py/tests/test_efi*
diff --git a/doc/README.iscsi b/doc/README.iscsi
new file mode 100644
index 0000000000..f095ad1ddf
--- /dev/null
+++ b/doc/README.iscsi
@@ -0,0 +1,178 @@
+# iSCSI booting with U-Boot and iPXE
+
+## Motivation
+
+U-Boot has only a reduced set of supported network protocols. A major gap is
+the lack of a TCP stack.
+
+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).
+
+These protocols are insecure. The client cannot validate the authenticity
+of the contacted servers. And the server cannot verify the identity of the
+client.
+
+Furthermore the services providing the operating system loader or kernel are
+not the ones that the operating system will use. Especially in a SAN environment
+this makes updating the operating system a hassle. After installing a new
+kernel version the boot files have to be copied to the TFTP server directory.
+
+The HTTPS protocol provides certificate based validation of servers. Sensitive
+data like passwords can be securely transmitted.
+
+The iSCSI protocol is used for connecting storage attached networks. It
+provides mutual authentication using the CHAP protocol. It typically runs on
+a TCP transport.
+
+Thus a better solution than DHCP/TFTP boot would be to load a boot script via
+HTTPS and to download any other files needed for booting via iSCSI.
+
+An alternative to implementing these protocols in U-Boot is to use an existing
+software that can run on top of U-Boot. 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.
+
+iPXE can be built as an EFI application (named snp.efi) which can be loaded and
+run by U-Boot.
+
+## Boot sequence
+
+U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This
+application has network access via the simple network protocol offered by
+U-Boot.
+
+iPXE executes its internal script. This script may optionally chain load a
+secondary boot script via HTTPS or open a shell.
+
+For the further boot process iPXE connects to the iSCSI server. This includes
+the mutual authentication using the CHAP protocol. After the authentication iPXE
+has access to the iSCSI targets.
+
+For a selected iSCSI target iPXE sets up a handle with the block IO protocol. It
+uses the ConnectController boot service of U-Boot to request U-Boot to connect a
+file system driver. U-Boot reads from the iSCSI drive via the block IO protocol
+offered by iPXE. It creates the partition handles and install the simple file
+protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses
+the block IO protocol offered by iPXE to fulfill the request.
+
+Once Grub is started it uses the same simple file protocol to load Linux. Via
+the EFI stub Linux is called as an EFI application.
+
+```
+ +--------+ +--------+
+ | | Runs | |
+ | U-Boot |=========>| iPXE |
+ | EFI | | snp.efi|
++--------+ | | DHCP | |
+| |<====|********|<=========| |
+| DHCP | | | Request | |
+| Server | | | | |
+| |====>|********|=========>| |
++--------+ | | Response | |
+ | | | |
+ | | | |
++--------+ | | HTTPS | |
+| |<====|********|<=========| |
+| HTTPS | | | Request | |
+| Server | | | | |
+| |====>|********|=========>| |
++--------+ | | Response | |
+ | | | |
+ | | | |
++--------+ | | iSCSI | |
+| |<====|********|<=========| |
+| iSCSI | | | Auth | |
+| Server |====>|********|=========>| |
+| | | | | |
+| | | | Loads | |
+| |<====|********|<=========| | +--------+
+| | | | Grub | | Runs | |
+| |====>|********|=========>| |=======>| Grub |
+| | | | | | | |
+| | | | | | | |
+| | | | | | Loads | |
+| |<====|********|<=========|********|<=======| | +--------+
+| | | | | | Linux | | Runs | |
+| |====>|********|=========>|********|=======>| |=====>| Linux |
+| | | | | | | | | |
++--------+ +--------+ +--------+ +--------+ | |
+ | |
+ | |
+ | ~ ~ ~ ~|
+```
+
+## Security
+
+The iSCSI protocol is not encrypted. The traffic could be secured using IPsec
+but iPXE does not support this. So we should at least separate the iSCSI traffic
+from all other network traffic. This can be achieved using a virtual local area
+network (VLAN).
+
+```
+ +-----------+
+ | |
+ | |
+ | iSCSI |
+ | Server |
+ | |
+ | |
+ +-----------+
+ |
+ |iSCSI
+ |
++-----------+ +-----------+ +-----------+
+| | VLAN 2 | * | | |
+| |----------|****** | | |
+| Diskless | | Managed | | Firewall |
+| Computer | VLAN 1 | Switch | HTTP | |
+| |==========|***********|==========|***********|=====$
+| | | | | |
++-----------+ +-----------+ +-----------+
+```
+
+## Configuration
+
+### iPXE
+
+For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is needed.
+
+ git clone http://git.ipxe.org/ipxe.git
+ cd ipxe/src
+ make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe
+
+The available commands for the boot script are documented at:
+
+http://ipxe.org/cmd
+
+Credentials are managed as environment variables. These are described here:
+
+http://ipxe.org/cfg
+
+iPXE by default will put the CPU to rest when waiting for input. U-Boot does
+not wake it up due to missing interrupt support. To avoid this behavior create
+file src/config/local/nap.h.
+
+ /* nap.h */
+ #undef NAP_EFIX86
+ #undef NAP_EFIARM
+ #define NAP_NULL
+
+The supported commands in iPXE are controlled by an include, too. Putting the
+following into src/config/local/general.h is sufficient for most use cases.
+
+ /* general.h */
+ #define NSLOOKUP_CMD /* Name resolution command */
+ #define PING_CMD /* Ping command */
+ #define NTP_CMD /* NTP commands */
+ #define VLAN_CMD /* VLAN commands */
+ #define IMAGE_EFI /* EFI image support */
+ #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer Protocol */
+ #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */
+ #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */
+ #define DOWNLOAD_PROTO_FILE /* Local file system access */
+
+## Links
+
+* https://ipxe.org - iPXE open source boot firmware
+* https://www.gnu.org/software/grub/ - GNU Grub (Grand Unified Bootloader)
--
2.11.0
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
2018-01-22 18:34 [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI Heinrich Schuchardt
@ 2018-01-25 17:47 ` Alexander Graf
[not found] ` <45383395.428819.1516906029443@mail.yahoo.com>
2018-01-25 21:36 ` Heinrich Schuchardt
0 siblings, 2 replies; 8+ messages in thread
From: Alexander Graf @ 2018-01-25 17:47 UTC (permalink / raw)
To: u-boot
On 01/22/2018 07:34 PM, Heinrich Schuchardt wrote:
> 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>
> ---
> MAINTAINERS | 2 +
> doc/README.iscsi | 178 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 180 insertions(+)
> create mode 100644 doc/README.iscsi
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d459153503..6e94cee5d3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -286,6 +286,8 @@ EFI PAYLOAD
> M: Alexander Graf <agraf@suse.de>
> S: Maintained
> T: git git://github.com/agraf/u-boot.git
> +F: doc/README.efi
> +F: doc/README.iscsi
> F: include/efi*
> F: lib/efi*/
> F: test/py/tests/test_efi*
> diff --git a/doc/README.iscsi b/doc/README.iscsi
> new file mode 100644
> index 0000000000..f095ad1ddf
> --- /dev/null
> +++ b/doc/README.iscsi
> @@ -0,0 +1,178 @@
> +# iSCSI booting with U-Boot and iPXE
> +
> +## Motivation
> +
> +U-Boot has only a reduced set of supported network protocols. A 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.
> +
> +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).
> +
> +These protocols are insecure. The client cannot validate the authenticity
> +of the contacted servers. And the server cannot verify the identity of the
> +client.
> +
> +Furthermore the services providing the operating system loader or kernel are
> +not the ones that the operating system will use. Especially in a SAN environment
> +this makes updating the operating system a hassle. After installing a new
> +kernel version the boot files have to be copied to the TFTP server directory.
> +
> +The HTTPS protocol provides certificate based validation of servers. Sensitive
> +data like passwords can be securely transmitted.
> +
> +The iSCSI protocol is used for connecting storage attached networks. It
> +provides mutual authentication using the CHAP protocol. It typically runs on
> +a TCP transport.
> +
> +Thus a better solution than DHCP/TFTP boot would be to load a boot script via
> +HTTPS and to download any other files needed for booting via iSCSI.
> +
> +An alternative to implementing these protocols in U-Boot is to use an existing
> +software that can run on top of U-Boot. 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.
> +
> +iPXE can be built as an EFI application (named snp.efi) which can be loaded and
> +run by U-Boot.
> +
> +## Boot sequence
> +
> +U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This
> +application has network access via the simple network protocol offered by
> +U-Boot.
> +
> +iPXE executes its internal script. This script may optionally chain load a
> +secondary boot script via HTTPS or open a shell.
> +
> +For the further boot process iPXE connects to the iSCSI server. This includes
> +the mutual authentication using the CHAP protocol. After the authentication iPXE
> +has access to the iSCSI targets.
> +
> +For a selected iSCSI target iPXE sets up a handle with the block IO protocol. It
> +uses the ConnectController boot service of U-Boot to request U-Boot to connect a
> +file system driver. U-Boot reads from the iSCSI drive via the block IO protocol
> +offered by iPXE. It creates the partition handles and install the simple file
installs
> +protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses
> +the block IO protocol offered by iPXE to fulfill the request.
> +
> +Once Grub is started it uses the same simple file protocol to load Linux. Via
Are you sure grub uses the file system protocol? IIRC it uses block
directly.
> +the EFI stub Linux is called as an EFI application.
> +
> +```
> + +--------+ +--------+
> + | | Runs | |
> + | U-Boot |=========>| iPXE |
> + | EFI | | snp.efi|
> ++--------+ | | DHCP | |
> +| |<====|********|<=========| |
> +| DHCP | | | Request | |
> +| Server | | | | |
> +| |====>|********|=========>| |
> ++--------+ | | Response | |
> + | | | |
> + | | | |
> ++--------+ | | HTTPS | |
> +| |<====|********|<=========| |
> +| HTTPS | | | Request | |
> +| Server | | | | |
> +| |====>|********|=========>| |
> ++--------+ | | Response | |
> + | | | |
> + | | | |
> ++--------+ | | iSCSI | |
> +| |<====|********|<=========| |
> +| iSCSI | | | Auth | |
> +| Server |====>|********|=========>| |
> +| | | | | |
> +| | | | Loads | |
> +| |<====|********|<=========| | +--------+
> +| | | | Grub | | Runs | |
> +| |====>|********|=========>| |=======>| Grub |
> +| | | | | | | |
> +| | | | | | | |
> +| | | | | | Loads | |
> +| |<====|********|<=========|********|<=======| | +--------+
> +| | | | | | Linux | | Runs | |
> +| |====>|********|=========>|********|=======>| |=====>| Linux |
> +| | | | | | | | | |
> ++--------+ +--------+ +--------+ +--------+ | |
> + | |
> + | |
> + | ~ ~ ~ ~|
> +```
> +
> +## Security
> +
> +The iSCSI protocol is not encrypted. The traffic could be secured using IPsec
> +but iPXE does not support this. So we should at least separate the iSCSI traffic
> +from all other network traffic. This can be achieved using a virtual local area
> +network (VLAN).
> +
> +```
> + +-----------+
> + | |
> + | |
> + | iSCSI |
> + | Server |
> + | |
> + | |
> + +-----------+
> + |
> + |iSCSI
> + |
> ++-----------+ +-----------+ +-----------+
> +| | VLAN 2 | * | | |
> +| |----------|****** | | |
> +| Diskless | | Managed | | Firewall |
> +| Computer | VLAN 1 | Switch | HTTP | |
> +| |==========|***********|==========|***********|=====$
> +| | | | | |
> ++-----------+ +-----------+ +-----------+
> +```
Is VLAN really in scope for this document? I guess it doesn't hurt, but
it feels slightly out of place :)
Alex
> +
> +## Configuration
> +
> +### iPXE
> +
> +For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is needed.
> +
> + git clone http://git.ipxe.org/ipxe.git
> + cd ipxe/src
> + make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe
> +
> +The available commands for the boot script are documented at:
> +
> +http://ipxe.org/cmd
> +
> +Credentials are managed as environment variables. These are described here:
> +
> +http://ipxe.org/cfg
> +
> +iPXE by default will put the CPU to rest when waiting for input. U-Boot does
> +not wake it up due to missing interrupt support. To avoid this behavior create
> +file src/config/local/nap.h.
> +
> + /* nap.h */
> + #undef NAP_EFIX86
> + #undef NAP_EFIARM
> + #define NAP_NULL
> +
> +The supported commands in iPXE are controlled by an include, too. Putting the
> +following into src/config/local/general.h is sufficient for most use cases.
> +
> + /* general.h */
> + #define NSLOOKUP_CMD /* Name resolution command */
> + #define PING_CMD /* Ping command */
> + #define NTP_CMD /* NTP commands */
> + #define VLAN_CMD /* VLAN commands */
> + #define IMAGE_EFI /* EFI image support */
> + #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer Protocol */
> + #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */
> + #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */
> + #define DOWNLOAD_PROTO_FILE /* Local file system access */
> +
> +## Links
> +
> +* https://ipxe.org - iPXE open source boot firmware
> +* https://www.gnu.org/software/grub/ - GNU Grub (Grand Unified Bootloader)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
[not found] ` <45383395.428819.1516906029443@mail.yahoo.com>
@ 2018-01-25 19:39 ` Duncan Hare
2018-01-25 21:19 ` Heinrich Schuchardt
2018-01-26 13:43 ` Heinrich Schuchardt
0 siblings, 2 replies; 8+ messages in thread
From: Duncan Hare @ 2018-01-25 19:39 UTC (permalink / raw)
To: u-boot
> ----- 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
2018-01-25 19:39 ` Duncan Hare
@ 2018-01-25 21:19 ` Heinrich Schuchardt
2018-01-26 13:43 ` Heinrich Schuchardt
1 sibling, 0 replies; 8+ messages in thread
From: Heinrich Schuchardt @ 2018-01-25 21:19 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
2018-01-25 17:47 ` Alexander Graf
[not found] ` <45383395.428819.1516906029443@mail.yahoo.com>
@ 2018-01-25 21:36 ` Heinrich Schuchardt
1 sibling, 0 replies; 8+ messages in thread
From: Heinrich Schuchardt @ 2018-01-25 21:36 UTC (permalink / raw)
To: u-boot
On 01/25/2018 06:47 PM, Alexander Graf wrote:
> On 01/22/2018 07:34 PM, Heinrich Schuchardt wrote:
>> 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>
>> ---
>> MAINTAINERS | 2 +
>> doc/README.iscsi | 178
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 180 insertions(+)
>> create mode 100644 doc/README.iscsi
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index d459153503..6e94cee5d3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -286,6 +286,8 @@ EFI PAYLOAD
>> M: Alexander Graf <agraf@suse.de>
>> S: Maintained
>> T: git git://github.com/agraf/u-boot.git
>> +F: doc/README.efi
>> +F: doc/README.iscsi
>> F: include/efi*
>> F: lib/efi*/
>> F: test/py/tests/test_efi*
>> diff --git a/doc/README.iscsi b/doc/README.iscsi
>> new file mode 100644
>> index 0000000000..f095ad1ddf
>> --- /dev/null
>> +++ b/doc/README.iscsi
>> @@ -0,0 +1,178 @@
>> +# iSCSI booting with U-Boot and iPXE
>> +
>> +## Motivation
>> +
>> +U-Boot has only a reduced set of supported network protocols. A 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.
>
I can mention that this is work in progress.
>> +
>> +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).
>> +
>> +These protocols are insecure. The client cannot validate the
>> authenticity
>> +of the contacted servers. And the server cannot verify the identity
>> of the
>> +client.
>> +
>> +Furthermore the services providing the operating system loader or
>> kernel are
>> +not the ones that the operating system will use. Especially in a SAN
>> environment
>> +this makes updating the operating system a hassle. After installing a
>> new
>> +kernel version the boot files have to be copied to the TFTP server
>> directory.
>> +
>> +The HTTPS protocol provides certificate based validation of servers.
>> Sensitive
>> +data like passwords can be securely transmitted.
>> +
>> +The iSCSI protocol is used for connecting storage attached networks. It
>> +provides mutual authentication using the CHAP protocol. It typically
>> runs on
>> +a TCP transport.
>> +
>> +Thus a better solution than DHCP/TFTP boot would be to load a boot
>> script via
>> +HTTPS and to download any other files needed for booting via iSCSI.
>> +
>> +An alternative to implementing these protocols in U-Boot is to use an
>> existing
>> +software that can run on top of U-Boot. 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.
>> +
>> +iPXE can be built as an EFI application (named snp.efi) which can be
>> loaded and
>> +run by U-Boot.
>> +
>> +## Boot sequence
>> +
>> +U-Boot loads the EFI application iPXE snp.efi using the bootefi
>> command. This
>> +application has network access via the simple network protocol
>> offered by
>> +U-Boot.
>> +
>> +iPXE executes its internal script. This script may optionally chain
>> load a
>> +secondary boot script via HTTPS or open a shell.
>> +
>> +For the further boot process iPXE connects to the iSCSI server. This
>> includes
>> +the mutual authentication using the CHAP protocol. After the
>> authentication iPXE
>> +has access to the iSCSI targets.
>> +
>> +For a selected iSCSI target iPXE sets up a handle with the block IO
>> protocol. It
>> +uses the ConnectController boot service of U-Boot to request U-Boot
>> to connect a
>> +file system driver. U-Boot reads from the iSCSI drive via the block
>> IO protocol
>> +offered by iPXE. It creates the partition handles and install the
>> simple file
>
> installs
>
>> +protocol. Now iPXE can call the simple file protocol to load Grub.
>> U-Boot uses
>> +the block IO protocol offered by iPXE to fulfill the request.
>> +
>> +Once Grub is started it uses the same simple file protocol to load
>> Linux. Via
>
> Are you sure grub uses the file system protocol? IIRC it uses block
> directly.
>
>> +the EFI stub Linux is called as an EFI application.
>> +
>> +```
>> + +--------+ +--------+
>> + | | Runs | |
>> + | U-Boot |=========>| iPXE |
>> + | EFI | | snp.efi|
>> ++--------+ | | DHCP | |
>> +| |<====|********|<=========| |
>> +| DHCP | | | Request | |
>> +| Server | | | | |
>> +| |====>|********|=========>| |
>> ++--------+ | | Response | |
>> + | | | |
>> + | | | |
>> ++--------+ | | HTTPS | |
>> +| |<====|********|<=========| |
>> +| HTTPS | | | Request | |
>> +| Server | | | | |
>> +| |====>|********|=========>| |
>> ++--------+ | | Response | |
>> + | | | |
>> + | | | |
>> ++--------+ | | iSCSI | |
>> +| |<====|********|<=========| |
>> +| iSCSI | | | Auth | |
>> +| Server |====>|********|=========>| |
>> +| | | | | |
>> +| | | | Loads | |
>> +| |<====|********|<=========| | +--------+
>> +| | | | Grub | | Runs | |
>> +| |====>|********|=========>| |=======>| Grub |
>> +| | | | | | | |
>> +| | | | | | | |
>> +| | | | | | Loads | |
>> +| |<====|********|<=========|********|<=======| |
>> +--------+
>> +| | | | | | Linux | | Runs
>> | |
>> +| |====>|********|=========>|********|=======>|
>> |=====>| Linux |
>> +| | | | | | | |
>> | |
>> ++--------+ +--------+ +--------+ +--------+
>> | |
>> +
>> | |
>> +
>> | |
>> +
>> | ~ ~ ~ ~|
>> +```
>> +
>> +## Security
>> +
>> +The iSCSI protocol is not encrypted. The traffic could be secured
>> using IPsec
>> +but iPXE does not support this. So we should at least separate the
>> iSCSI traffic
>> +from all other network traffic. This can be achieved using a virtual
>> local area
>> +network (VLAN).
>> +
>> +```
>> + +-----------+
>> + | |
>> + | |
>> + | iSCSI |
>> + | Server |
>> + | |
>> + | |
>> + +-----------+
>> + |
>> + |iSCSI
>> + |
>> ++-----------+ +-----------+ +-----------+
>> +| | VLAN 2 | * | | |
>> +| |----------|****** | | |
>> +| Diskless | | Managed | | Firewall |
>> +| Computer | VLAN 1 | Switch | HTTP | |
>> +| |==========|***********|==========|***********|=====$
>> +| | | | | |
>> ++-----------+ +-----------+ +-----------+
>> +```
>
> Is VLAN really in scope for this document? I guess it doesn't hurt, but
> it feels slightly out of place :)
The security of iSCSI is worth mentioning but I can remove the drawing.
>
>
> Alex
>
>> +
>> +## Configuration
>> +
>> +### iPXE
>> +
>> +For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is
>> needed.
>> +
>> + git clone http://git.ipxe.org/ipxe.git
>> + cd ipxe/src
>> + make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe
>> +
>> +The available commands for the boot script are documented at:
>> +
>> +http://ipxe.org/cmd
>> +
>> +Credentials are managed as environment variables. These are described
>> here:
>> +
>> +http://ipxe.org/cfg
>> +
>> +iPXE by default will put the CPU to rest when waiting for input.
>> U-Boot does
>> +not wake it up due to missing interrupt support. To avoid this
>> behavior create
>> +file src/config/local/nap.h.
>> +
>> + /* nap.h */
>> + #undef NAP_EFIX86
>> + #undef NAP_EFIARM
>> + #define NAP_NULL
>> +
>> +The supported commands in iPXE are controlled by an include, too.
>> Putting the
>> +following into src/config/local/general.h is sufficient for most use
>> cases.
>> +
>> + /* general.h */
>> + #define NSLOOKUP_CMD /* Name resolution command */
>> + #define PING_CMD /* Ping command */
>> + #define NTP_CMD /* NTP commands */
>> + #define VLAN_CMD /* VLAN commands */
>> + #define IMAGE_EFI /* EFI image support */
>> + #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer
>> Protocol */
>> + #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */
>> + #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */
>> + #define DOWNLOAD_PROTO_FILE /* Local file system access */
>> +
>> +## Links
>> +
>> +* https://ipxe.org - iPXE open source boot firmware
>> +* https://www.gnu.org/software/grub/ - GNU Grub (Grand Unified
>> Bootloader)
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
2018-01-25 19:39 ` Duncan Hare
2018-01-25 21:19 ` Heinrich Schuchardt
@ 2018-01-26 13:43 ` Heinrich Schuchardt
1 sibling, 0 replies; 8+ messages in thread
From: Heinrich Schuchardt @ 2018-01-26 13:43 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
[not found] <1511481180.994792.1516981733136.ref@mail.yahoo.com>
@ 2018-01-26 15:48 ` Duncan Hare
0 siblings, 0 replies; 8+ messages in thread
From: Duncan Hare @ 2018-01-26 15:48 UTC (permalink / raw)
To: u-boot
From: Heinrich Schuchardt <xypron.debian@gmx.de>
To: Duncan Hare <dh@synoia.com>; Alexander Graf <agraf@suse.de>
Subject: Re: [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
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.
>>>>
>> 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.
>>
> RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0
> You should not program to please another accommodating software but
> according to a standard.
I agree. The comment was a FYI.
> The key to TCP performance is supporting multiple packets in flight.
And we do. That's set in include/net.h in the buffer definitions.With single packet-at-a time one might as well stick with udp.
I've worked on network communication protocols since 1973.c programming, not so much. git, I'm a newb.
HeinrichIt is not yet pushed to git.I need to fix the bugs in SACK before taking that step.
I had hoped this week but I was delayed by flu.
It adheres to http 1.0. It is a minimal implementation.
It is relatively fast. It drives a Raspberry Pi at 10 M bits/sec,
the limitation being the raspberry pi processor speed.
I can send you a tarball, together with the changes to tftp.c for testing that a downloaded image is correct.
Regards Duncan Hare
714 931 7952
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
@ 2018-01-28 14:26 Heinrich Schuchardt
0 siblings, 0 replies; 8+ messages in thread
From: Heinrich Schuchardt @ 2018-01-28 14:26 UTC (permalink / raw)
To: u-boot
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>
---
v3
Remove non-related changes.
Fix a typo.
v2
mention work on TCP and wget
remove VLAN drawing
fix reference of EFI service used by Grub
---
MAINTAINERS | 1 +
doc/README.iscsi | 159 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 160 insertions(+)
create mode 100644 doc/README.iscsi
diff --git a/MAINTAINERS b/MAINTAINERS
index d459153503..0ff787866d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -286,6 +286,7 @@ EFI PAYLOAD
M: Alexander Graf <agraf@suse.de>
S: Maintained
T: git git://github.com/agraf/u-boot.git
+F: doc/README.iscsi
F: include/efi*
F: lib/efi*/
F: test/py/tests/test_efi*
diff --git a/doc/README.iscsi b/doc/README.iscsi
new file mode 100644
index 0000000000..0f4d88ab0d
--- /dev/null
+++ b/doc/README.iscsi
@@ -0,0 +1,159 @@
+# iSCSI booting with U-Boot and iPXE
+
+## Motivation
+
+U-Boot has only a reduced set of supported network protocols. The focus for
+network booting has been on UDP based protocols. A TCP stack and HTTP support
+are expected to be integrated in 2018 together with a wget command.
+
+For booting a diskless computer this leaves us with BOOTP or DHCP to get the
+address of a boot script. TFTP or NFS can be used to load the boot script, the
+operating system kernel and the initial file system (initrd).
+
+These protocols are insecure. The client cannot validate the authenticity
+of the contacted servers. And the server cannot verify the identity of the
+client.
+
+Furthermore the services providing the operating system loader or kernel are
+not the ones that the operating system typically will use. Especially in a SAN
+environment this makes updating the operating system a hassle. After installing
+a new kernel version the boot files have to be copied to the TFTP server
+directory.
+
+The HTTPS protocol provides certificate based validation of servers. Sensitive
+data like passwords can be securely transmitted.
+
+The iSCSI protocol is used for connecting storage attached networks. It
+provides mutual authentication using the CHAP protocol. It typically runs on
+a TCP transport.
+
+Thus a better solution than DHCP/TFTP/NFS boot would be to load a boot script
+via HTTPS and to download any other files needed for booting via iSCSI from the
+same target where the operating system is installed.
+
+An alternative to implementing these protocols in U-Boot is to use an existing
+software that can run on top of U-Boot. iPXE is the "swiss army knife" of
+network booting. It supports both HTTPS and iSCSI. It has a scripting engine for
+fine grained control of the boot process and can provide a command shell.
+
+iPXE can be built as an EFI application (named snp.efi) which can be loaded and
+run by U-Boot.
+
+## Boot sequence
+
+U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This
+application has network access via the simple network protocol offered by
+U-Boot.
+
+iPXE executes its internal script. This script may optionally chain load a
+secondary boot script via HTTPS or open a shell.
+
+For the further boot process iPXE connects to the iSCSI server. This includes
+the mutual authentication using the CHAP protocol. After the authentication iPXE
+has access to the iSCSI targets.
+
+For a selected iSCSI target iPXE sets up a handle with the block IO protocol. It
+uses the ConnectController boot service of U-Boot to request U-Boot to connect a
+file system driver. U-Boot reads from the iSCSI drive via the block IO protocol
+offered by iPXE. It creates the partition handles and installs the simple file
+protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses
+the block IO protocol offered by iPXE to fulfill the request.
+
+Once Grub is started it uses the same block IO protocol to load Linux. Via
+the EFI stub Linux is called as an EFI application.
+
+```
+ +--------+ +--------+
+ | | Runs | |
+ | U-Boot |=========>| iPXE |
+ | EFI | | snp.efi|
++--------+ | | DHCP | |
+| |<====|********|<=========| |
+| DHCP | | | Get IP | |
+| Server | | | Adress | |
+| |====>|********|=========>| |
++--------+ | | Response | |
+ | | | |
+ | | | |
++--------+ | | HTTPS | |
+| |<====|********|<=========| |
+| HTTPS | | | Load | |
+| Server | | | Script | |
+| |====>|********|=========>| |
++--------+ | | | |
+ | | | |
+ | | | |
++--------+ | | iSCSI | |
+| |<====|********|<=========| |
+| iSCSI | | | Auth | |
+| Server |====>|********|=========>| |
+| | | | | |
+| | | | Loads | |
+| |<====|********|<=========| | +--------+
+| | | | Grub | | Runs | |
+| |====>|********|=========>| |=======>| Grub |
+| | | | | | | |
+| | | | | | | |
+| | | | | | Loads | |
+| |<====|********|<=========|********|<=======| | +--------+
+| | | | | | Linux | | Runs | |
+| |====>|********|=========>|********|=======>| |=====>| Linux |
+| | | | | | | | | |
++--------+ +--------+ +--------+ +--------+ | |
+ | |
+ | |
+ | ~ ~ ~ ~|
+```
+
+## Security
+
+The iSCSI protocol is not encrypted. The traffic could be secured using IPsec
+but neither U-Boot nor iPXE does support this. So we should at least separate
+the iSCSI traffic from all other network traffic. This can be achieved using a
+virtual local area network (VLAN).
+
+## Configuration
+
+### iPXE
+
+For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is needed.
+
+ git clone http://git.ipxe.org/ipxe.git
+ cd ipxe/src
+ make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe
+
+The available commands for the boot script are documented at:
+
+http://ipxe.org/cmd
+
+Credentials are managed as environment variables. These are described here:
+
+http://ipxe.org/cfg
+
+iPXE by default will put the CPU to rest when waiting for input. U-Boot does
+not wake it up due to missing interrupt support. To avoid this behavior create
+file src/config/local/nap.h.
+
+ /* nap.h */
+ #undef NAP_EFIX86
+ #undef NAP_EFIARM
+ #define NAP_NULL
+
+The supported commands in iPXE are controlled by an include, too. Putting the
+following into src/config/local/general.h is sufficient for most use cases.
+
+ /* general.h */
+ #define NSLOOKUP_CMD /* Name resolution command */
+ #define PING_CMD /* Ping command */
+ #define NTP_CMD /* NTP commands */
+ #define VLAN_CMD /* VLAN commands */
+ #define IMAGE_EFI /* EFI image support */
+ #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer Protocol */
+ #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */
+ #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */
+ #define DOWNLOAD_PROTO_FILE /* Local file system access */
+
+## Links
+
+* https://ipxe.org - iPXE open source boot firmware
+* https://www.gnu.org/software/grub/ - GNU Grub (Grand Unified Bootloader)
--
2.14.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-01-28 14:26 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-22 18:34 [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI Heinrich Schuchardt
2018-01-25 17:47 ` Alexander Graf
[not found] ` <45383395.428819.1516906029443@mail.yahoo.com>
2018-01-25 19:39 ` Duncan Hare
2018-01-25 21:19 ` Heinrich Schuchardt
2018-01-26 13:43 ` Heinrich Schuchardt
2018-01-25 21:36 ` Heinrich Schuchardt
[not found] <1511481180.994792.1516981733136.ref@mail.yahoo.com>
2018-01-26 15:48 ` Duncan Hare
-- strict thread matches above, loose matches on Subject: below --
2018-01-28 14:26 Heinrich Schuchardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox