In a call to set_phys_range_identity, i-1 is used without checking that
i is non-zero. Although unlikely, a bug in the code before it could
cause the value to be 0, leading to erroneous behavior. This patch adds
a check against 0 value and a corresponding warning.
Signed-off-by: Martin Kelly <[email protected]>
---
arch/x86/xen/setup.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index af72161..26e39af 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -671,7 +671,10 @@ char * __init xen_memory_setup(void)
* PFNs above MAX_P2M_PFN are considered identity mapped as
* well.
*/
- set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul);
+ if (i > 0)
+ set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul);
+ else
+ WARN(1, "Something went wrong clamping memory to a factor of EXTRA_MEM_RATIO!");
/*
* In domU, the ISA region is normal, usable memory, but we
--
2.1.1
On 14/10/14 02:19, Martin Kelly wrote:
> In a call to set_phys_range_identity, i-1 is used without checking that
> i is non-zero. Although unlikely, a bug in the code before it could
> cause the value to be 0, leading to erroneous behavior. This patch adds
> a check against 0 value and a corresponding warning.
This can only happen if the toolstack supplies a memory map with zero
entries. I could see justification for adding a panic at the top of
this function in this case, but I can't see the usefulness of this warning.
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -671,7 +671,10 @@ char * __init xen_memory_setup(void)
> * PFNs above MAX_P2M_PFN are considered identity mapped as
> * well.
> */
> - set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul);
> + if (i > 0)
> + set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul);
> + else
> + WARN(1, "Something went wrong clamping memory to a factor of EXTRA_MEM_RATIO!");
>
> /*
> * In domU, the ISA region is normal, usable memory, but we
>
On 10/14/2014 02:22 AM, David Vrabel wrote:
> On 14/10/14 02:19, Martin Kelly wrote:
>> In a call to set_phys_range_identity, i-1 is used without checking that
>> i is non-zero. Although unlikely, a bug in the code before it could
>> cause the value to be 0, leading to erroneous behavior. This patch adds
>> a check against 0 value and a corresponding warning.
>
> This can only happen if the toolstack supplies a memory map with zero
> entries. I could see justification for adding a panic at the top of
> this function in this case, but I can't see the usefulness of this warning.
>
Yes, a panic is probably appropriate. What do you think about the relative merits of panicing in the callers vs. in the sanitize_e820_map function itself (thus to avoid a bunch of similar error checks in the callers)?
On 14/10/14 15:04, Martin Kelly wrote:
> On 10/14/2014 02:22 AM, David Vrabel wrote:
>> On 14/10/14 02:19, Martin Kelly wrote:
>>> In a call to set_phys_range_identity, i-1 is used without checking that
>>> i is non-zero. Although unlikely, a bug in the code before it could
>>> cause the value to be 0, leading to erroneous behavior. This patch adds
>>> a check against 0 value and a corresponding warning.
>>
>> This can only happen if the toolstack supplies a memory map with zero
>> entries. I could see justification for adding a panic at the top of
>> this function in this case, but I can't see the usefulness of this warning.
>>
>
> Yes, a panic is probably appropriate. What do you think about the
> relative merits of panicing in the callers vs. in the
> sanitize_e820_map function itself (thus to avoid a bunch of similar
> error checks in the callers)?
For Xen, it should panic immediately after getting the memory map.
You will note that there is fallback code for the case when no memory
map is provided. But I do not think this should be used in the case
where the toolstack provided an empty memory map.
David
On Tue, Oct 14, 2014 at 9:09 AM, David Vrabel <[email protected]> wrote:
> On 14/10/14 15:04, Martin Kelly wrote:
>> On 10/14/2014 02:22 AM, David Vrabel wrote:
>>> On 14/10/14 02:19, Martin Kelly wrote:
>>>> In a call to set_phys_range_identity, i-1 is used without checking that
>>>> i is non-zero. Although unlikely, a bug in the code before it could
>>>> cause the value to be 0, leading to erroneous behavior. This patch adds
>>>> a check against 0 value and a corresponding warning.
>>>
>>> This can only happen if the toolstack supplies a memory map with zero
>>> entries. I could see justification for adding a panic at the top of
>>> this function in this case, but I can't see the usefulness of this warning.
>>>
>>
>> Yes, a panic is probably appropriate. What do you think about the
>> relative merits of panicing in the callers vs. in the
>> sanitize_e820_map function itself (thus to avoid a bunch of similar
>> error checks in the callers)?
>
> For Xen, it should panic immediately after getting the memory map.
>
> You will note that there is fallback code for the case when no memory
> map is provided. But I do not think this should be used in the case
> where the toolstack provided an empty memory map.
>
> David
Sounds like the flow should be as follows:
1) Ask Xen for the memory map.
2) If no memory map is provided, use fallback code.
3) If the memory map has 0 entries, panic.
I will revise the patch to do that.
On 10/14/2014 09:28 AM, Martin Kelly wrote:
> On Tue, Oct 14, 2014 at 9:09 AM, David Vrabel <[email protected]> wrote:
>> On 14/10/14 15:04, Martin Kelly wrote:
>>> On 10/14/2014 02:22 AM, David Vrabel wrote:
>>>> On 14/10/14 02:19, Martin Kelly wrote:
>>>>> In a call to set_phys_range_identity, i-1 is used without checking that
>>>>> i is non-zero. Although unlikely, a bug in the code before it could
>>>>> cause the value to be 0, leading to erroneous behavior. This patch adds
>>>>> a check against 0 value and a corresponding warning.
>>>>
>>>> This can only happen if the toolstack supplies a memory map with zero
>>>> entries. I could see justification for adding a panic at the top of
>>>> this function in this case, but I can't see the usefulness of this warning.
>>>>
>>>
>>> Yes, a panic is probably appropriate. What do you think about the
>>> relative merits of panicing in the callers vs. in the
>>> sanitize_e820_map function itself (thus to avoid a bunch of similar
>>> error checks in the callers)?
>>
>> For Xen, it should panic immediately after getting the memory map.
>>
>> You will note that there is fallback code for the case when no memory
>> map is provided. But I do not think this should be used in the case
>> where the toolstack provided an empty memory map.
>>
>> David
>
> Sounds like the flow should be as follows:
> 1) Ask Xen for the memory map.
> 2) If no memory map is provided, use fallback code.
> 3) If the memory map has 0 entries, panic.
>
> I will revise the patch to do that.
>
I have sent a revision adding the panic:
"[PATCH] x86/xen: panic on bad Xen-provided memory map"