[ipxe-devel] SRP booting linux, SRP volume with ISO stops seeing itself

[james harvey]

I hope I'm wrong here, but I think there needs to be an additional
kernel module to allow SRP booting.  Has no one done this yet, booted
linux by SRP, or am I off somewhere?

I do have a program that can search a given 640k area, and find and
parse a sBFT.  (Probably needs a tweak or two once I'm running it on
what iPXE leaves behind, rather than the test structures I'm randomly
making and randomly placing.)

Now that I'm at the point of wanting to try it during boot, I realized
what I should have earlier - I don't think there's any way for my
program to access the sBFT.

My understanding (could be outdated) is that the system boots in
16-bit real mode with no memory access protections, and the kernel
quickly switches over to protected mode.  If my userspace program runs
in protected mode, I believe it's impossible to access base memory and
find or read the sBFT.

Is there a way to make my program run before the switch, so it's in
real mode?  (I assume I'd have to use 16-bit compilation here too.)
I'm not seeing anything indicating that.

Otherwise, I think only kernelspace could find and parse the sBFT.

I looked at how iSCSI booting does it, and there's a kernel module
iscsi_ibft which gives a sysfs interface to the iBFT structure.  I
don't see anything along the lines of an ib_sbft kernel module.

Most of me wants this project over, done and working.  Part of me is
mildly interested in writing a kernel module if needed.


I'm wondering if the easiest way for me to move on from this would be
to duplicate the information, giving it to both iPXE, and the kernel
as parameters to be parsed, and just ignore the sBFT.


On Sun, Jul 17, 2016 at 7:24 AM, james harvey <jamespharvey20 at gmail.com> wrote:
> In other words, is offset to SCSI Subtable always going to be 48, and
> offset to SRP Subtable always going to be 56?  And, is offset to SRP
> Subtable always going to be 0 or 88?
>
> On Sun, Jul 17, 2016 at 6:09 AM, james harvey <jamespharvey20 at gmail.com> wrote:
>> I'm picking up this project again.  Wanted to make sure such a tool
>> hadn't been written since January.
>>
>> Also, am I correctly understanding the sBFT documentation, that there
>> is always exactly 1 SCSI Subtable and 1 SRP Subtable, and either 0 or
>> 1 IB Subtables?
>>
>> If there's always 1 SCSI Subtable and always 1 SRP Subtable, I'm
>> confused why there's an offset to those since at that point I'm not
>> seeing anything variable length.
>>
>> On Wed, Jan 27, 2016 at 7:17 PM, Michael Brown <mcb30 at ipxe.org> wrote:
>>> On 08/01/16 02:19, james harvey wrote:
>>>>
>>>> Before I keep going down the hole, let me make sure my plan isn't
>>>> futile.  I want to make a diskless system, by having iPXE in my
>>>> InfiniBand card's ROM, and being able to boot an Arch Linux Live ISO
>>>> (custom built with srp kernel modules) exported as a SRP volume backed
>>>> by the ISO, and install on other SRP volumes which are backed by LVM
>>>> volumes.
>>>>
>>>> I have a real general idea of how the iPXE to kernel handoff works,
>>>> through the iBFT (iSCSI Boot Firmware Table.)  Since I'm using SRP
>>>> rather than iSCSI, is the iBFT still used?  If not, how does the SRP
>>>> connection get handed off, with all the variables needed for an SRP
>>>> connection?
>>>
>>>
>>> There is an SRP boot firmware table constructed (the sBFT).  This is
>>> nominally documented at
>>>
>>>   http://ipxe.org/srp/sbft
>>>
>>> However, I'm not aware of any Linux userspace tools that are capable of
>>> parsing that structure.  It should be fairly easy to create such a tool,
>>> which would scan base memory for the sBFT signature, verify the checksum,
>>> extract the fields, and then write the relevant values into sysfs to
>>> initiate the connection.
>>>
>>> I thought I had written such a tool back in 2009, but all I can find
>>> relating to it is the proposal document.  It seems to have been an abandoned
>>> project back then.
>>>
>>> Michael