Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.08.16 at 15:10, <s.munaut@xxxxxxxxxxxxxxxxxxxx> wrote:
> Hi,
> 
> On Fri, Aug 26, 2016 at 3:06 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 26.08.16 at 11:09, <s.munaut@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/arch/x86/boot/head.S
>>> @@ -108,6 +108,8 @@ __start:
>>>          shl     $10-4,%edx
>>>          cmp     %eax,%edx           /* compare with BDA value */
>>>          cmovb   %edx,%eax           /* and use the smaller */
>>> +        cmp     $0x1000,%eax        /* or if the BDA value is too small */
>>> +        cmovb   %edx,%eax           /* (and probably not valid) */
>>
>> Considering there is a bounds check of the EBDA values a few
>> lines up from here (against 0x4000) I don't think I see how this
>> code can help, assuming the given explanation is applicable.
> 
> Because in my case, the EBDA value is rejected, it then falls back to
> reading the "base memory size" from the BDA, but that also reads as
> 0x00.

Ah, but that is a basic boot environment violation. Any sane OS
should be permitted to refuse to boot without any low memory.

> Then because 0 is smaller than the value from multiboot, it actually
> takes that. Then decrements it by 0x1000 (which doesn't go well) and
> try to place the trampoline there ...

And it would certainly make sense to try to handle this underflow
case.

>> In any event is bounding by 0x1000 likely not enough, as placing
>> the trampoline at address zero is unlikely to be a good idea.
> 
> I just took that value since that was the lower bound used for the
> multiboot value.
> 
> What would be reasonable as a lower bound for validity check ?

At the very least we shouldn't overlap with the BDA (starting at
0040:0000 and iirc covering up to 256 bytes, which is why DOS
never used any memory below 0050:0000).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel