On Thu, Jun 9, 2016 at 2:03 PM, Michael Brown <mc...@ipxe.org> wrote: > On 09/06/16 12:53, Ladi Prosek wrote: >> >> On Thu, Jun 9, 2016 at 1:05 PM, Michael Brown <mc...@ipxe.org> wrote: >>> >>> On 09/06/16 11:46, Ladi Prosek wrote: >>>> >>>> The UNDI ROM ID structure declares the minimum required stack segment >>>> size but the value is not used by iPXE. >>> >>> >>> iPXE doesn't use any meaningful amount of real-mode stack space outside >>> of >>> its own data segment. Without checking, I think we should be using less >>> than 64 bytes before switching to our own stack. >> >> >> Is it not possible that what we start with is already less than what >> the NIC requires, though? I was surprised to see rm_sp pretty low on >> my system - 2F10. What guarantees that this will be enough for any >> UNDI ROM? > > > Sorry; I'd skim-read your patch and misread it as applying to our own UNDI > loader (i.e. when we are being loaded by something external). > > We provide a 4kB real-mode stack, which we use for any calls to an > underlying PXE ROM. The rm_sp value is somewhat meaningless to compare, > since the stack is placed at an arbitrary (non-zero) offset within our data > segment: this is a (very indirect) consequence of using gcc, which has no > concept of segmentation and effectively enforces %ds=%ss. We could > potentially move the stack to the start of the data segment, but this would > complicate our decompressor since we assume that initialised-data precedes > uninitialised-data in each segment. > > There is code (e.g. IBM Tivoli / Rembo-ia32) which provides less than 512 > bytes of stack space. We should be safe offering 4kB.
Got it, thanks. We could still check the ROM ID stack size field against this 4k but if you don't think there is any real possibility of 4k not being enough, I'm happy to drop this. I don't have any evidence that it causes problems, just a suspicion still waiting to be confirmed or disproved. Thanks, Ladi _______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
