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

2018-01-28 Thread Heinrich Schuchardt 
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 
---
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 
 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 00..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   ||
+||>||=>||
+++ ||  ||
+   |

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

2018-01-26 Thread Duncan Hare 
From: Heinrich Schuchardt <xypron.deb...@gmx.de>
 To: Duncan Hare <d...@synoia.com>; Alexander Graf <ag...@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 <ag...@suse.de>
>>>  To: Heinrich Schuchardt <xypron.g...@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

   
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-01-26 Thread Heinrich Schuchardt 
On 01/25/2018 08:39 PM, Duncan Hare wrote:
>> - Forwarded Message -
>>  From: Alexander Graf 
>>  To: Heinrich Schuchardt  
> 
>>> 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 
>>> ---
>> +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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-01-25 Thread Heinrich Schuchardt 
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 
>> ---
>>   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 
>>   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 00..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 | |    |  |    |
>> +|   

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

2018-01-25 Thread Heinrich Schuchardt 
On 01/25/2018 08:39 PM, Duncan Hare wrote:
>> - Forwarded Message -
>>  From: Alexander Graf 
>>  To: Heinrich Schuchardt  
> 
>>> 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 
>>> ---
>> +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.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-01-25 Thread Duncan Hare 
> - Forwarded Message -
>  From: Alexander Graf 
>  To: Heinrich Schuchardt  

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



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-01-25 Thread Alexander Graf 

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

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

2018-01-22 Thread Heinrich Schuchardt 
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 
---
 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 
 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 00..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||
+|