[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 4/7] xen/device-tree: Fix bootfdt.c to tolerate 0 reserved regions


  • To: Julien Grall <julien@xxxxxxx>, Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Wed, 10 Jan 2024 09:15:35 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eJOLcC///zSSpjfavTY1zDBDUVkn+Xb8r3UJY+OGL7g=; b=jx4sMqXG3J42g+YxEdaM8jr8lUfdGNFjVu9JaFscgUdka0j+jKCx0gwaTl7sC0UogkDXij+Voyv4YQnnCx0AO15R+YGycLZ9eRSizlVy5snTO+nwAoGFwgro1re5Qdt6TU/CMIU2x6ULFzbk2ZKjKMXUlK4ruyZ+oFIJoWrKEElyw3BixRM5HCqOgv4Gv8/Fq+wyIXxtqRFf0fTyZhW61Skyy7jC1nTLCVFTUkmmomj+ZN4cZ6aOrLceTkLXjuEXoatKx8IbMLBWyHgvEmdm0HSpV7QK+KNrEav0LHxDyt2HEu2Wqlv+r+6grni5nDgzOx3ys7PqCtoisPnTgqSvag==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HzkbwPKq3d2XZdKsP3akhEAXStsU5KayofJ7AhnoHDXYRWi3Tq5ZmQ8s0k9SGL9BfifM5I6t+nAv1Yj8SpDEv2j7mTXRWY0Qk2EMTQKO2QfECXonB/PF/cW+XFIqbu44wGvZRzVP2VIEViLlS7+5pjJPO9G8IPblsqIUORRVDhjY7PEJ03/5PCp0TO1hoQvXhm0XBNw3xDqnyu1hvgTr3rDOmCkrxjDIk+O/bZi0F7Dhs62rGvQ2+v2TqvxCj+UN5m2KL1aaBEczIcvcyFAhd/FU+bYfu4QeCZP6Iu/0c8gOetgXXXoik5NLQLCcxji6lag+MEBgbk3o/EqJm3NjKQ==
  • Cc: Timothy Pearson <tpearson@xxxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Wed, 10 Jan 2024 08:15:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 09/01/2024 19:14, Julien Grall wrote:
> 
> 
> (+ Stefano)
> 
> Hi Shawn,
> 
> On 15/12/2023 02:43, Shawn Anastasio wrote:
>> The early_print_info routine in bootfdt.c incorrectly stores the result
>> of a call to fdt_num_mem_rsv() in an unsigned int, which results in the
>> negative error code being interpreted incorrectly in a subsequent loop
>> in the case where the device tree does not contain any memory reserve
>> map entries.
> 
> I have some trouble to reconciliate the code with your explanation.
> Looking at the implementation fdt_num_mem_rsv() should return 0 if there
> are no reserved regions. A negative value would only be returned if the
> device-tree is malformated.
I agree with Julien. The function takes an offset to reserve map and grabs 
blocks of type fdt_reserve_entry
from there. In case of no regions, there will be one entry with addr/size 0 
which always acts as a termination region.
The only way to return < 0 is when you have a buggy FDT.

> 
> Do you have a Device-Tree where the issue occurs?
> 
> That said, I agree that the code could be hardened.
> 
>>
>> Signed-off-by: Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>
>> ---
>>   xen/common/device-tree/bootfdt.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/common/device-tree/bootfdt.c 
>> b/xen/common/device-tree/bootfdt.c
>> index ae9fa1e3d6..796ac01c18 100644
>> --- a/xen/common/device-tree/bootfdt.c
>> +++ b/xen/common/device-tree/bootfdt.c
>> @@ -466,7 +466,8 @@ static void __init early_print_info(void)
>>       struct meminfo *mem_resv = &bootinfo.reserved_mem;
>>       struct bootmodules *mods = &bootinfo.modules;
>>       struct bootcmdlines *cmds = &bootinfo.cmdlines;
>> -    unsigned int i, j, nr_rsvd;
>> +    unsigned int i, j;
>> +    int nr_rsvd;
>>
>>       for ( i = 0; i < mi->nr_banks; i++ )
>>           printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
>> @@ -481,7 +482,7 @@ static void __init early_print_info(void)
>>                   boot_module_kind_as_string(mods->module[i].kind));
>>
>>       nr_rsvd = fdt_num_mem_rsv(device_tree_flattened);
> 
> If I am correct above, then I think we should panic() rather than trying
> to continue with a buggy DT.
+1. Furthermore, we already call panic in such case in dt_unreserved_regions().

> 
>> -    for ( i = 0; i < nr_rsvd; i++ )
>> +    for ( i = 0; nr_rsvd > 0 && i < nr_rsvd; i++ )
>>       {
>>           paddr_t s, e;
>>
> 
> Cheers,
> 
> --
> Julien Grall
> 

~Michal



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.