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

Re: [PATCH v4 01/21] AMD/IOMMU: correct potentially-UB shifts


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 27 Apr 2022 15:57:32 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • 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=ZX6Q2qIw8ZWRtMMu00Avbk2WY4ydH0MH70DMP2my8sw=; b=QDB11znjGPa/P/Vo2zUtKP/NcgXEgcs//gMtl9yzfIJLeJpRzuU03DjDTqoaUJlwL0Tq1/sRsVw+rLq7e/jqdnWrdZfo+L60V7HfKJkEyG/UkRgH69H58Hwd7Ymth7LdEWJ7wT6i6IgPTKEMrVItjHA57CwVSHP6+qUnC/L/P/IMBh64M44EC1OPWImntTxSLVorW2RnWTJck0g8NK/vtF0yreI0wg9njCQukW64yRvz9Bzi5ECQGDd3y2oHWcoKvVd71nN62B5n1CftJi8wyYbVMc9bI6FtB/Ka7p1P5/COtll/bd4QmkKVJMFmuOpUS2qXr/rotPIv7IJe0PrG6A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=imZm/26SavVn/suYPXa15InEQQCaJ6QLY30Ps36dkNZCzqSlPg9GMCvy/2F5s5JUG+6SkAcS6+MlsbS8AmfLXvXsLR1caqBwWOKx0wQclAgoNFaUCri99tGYjN1FDWXdquyXCsHflsXvCo4O4nO9KVOjXcZl3gY1UWPouTyDTLB5GM7wls5IWvoZtPhk9JFMbdx2ysu3WwvaC+WaugF1Lv8uPEVTWFHmFeUSh2esoyGUI1xMrglz+nwaRSbcMEGtc/Q029HsEVT0rcJwtLUN3zAPkF2Oqiy3C23ABhw/UfwuW262HUCznVmgIkRx9kESPTZMdYv/D2UctsNR3LiFcw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Paul Durrant <paul@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 27 Apr 2022 13:57:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.04.2022 15:08, Andrew Cooper wrote:
> On 25/04/2022 09:30, Jan Beulich wrote:
>> Recent changes (likely 5fafa6cf529a ["AMD/IOMMU: have callers specify
>> the target level for page table walks"]) have made Coverity notice a
>> shift count in iommu_pde_from_dfn() which might in theory grow too
>> large. While this isn't a problem in practice, address the concern
>> nevertheless to not leave dangling breakage in case very large
>> superpages would be enabled at some point.
>>
>> Coverity ID: 1504264
>>
>> While there also address a similar issue in set_iommu_ptes_present().
>> It's not clear to me why Coverity hasn't spotted that one.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> v4: New.
>>
>> --- a/xen/drivers/passthrough/amd/iommu_map.c
>> +++ b/xen/drivers/passthrough/amd/iommu_map.c
>> @@ -89,11 +89,11 @@ static unsigned int set_iommu_ptes_prese
>>                                             bool iw, bool ir)
>>  {
>>      union amd_iommu_pte *table, *pde;
>> -    unsigned int page_sz, flush_flags = 0;
>> +    unsigned long page_sz = 1UL << (PTE_PER_TABLE_SHIFT * (pde_level - 1));
> 
> There's an off-by-12 error somewhere here.
> 
> Judging by it's use, it should be named mapping_frames (or similar) instead.

Hmm, I think the author meant "size of the (potentially large) page
in units of 4k (base) pages". That's still some form of "page size".

> With that fixed, Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

If anything there could be another patch renaming the variable; that's
certainly not the goal here. But as said, I don't think the variable
name is strictly wrong. And with that it also doesn't feel entirely
right that I would be on the hook of renaming it. I also think that
"mapping_frames" isn't much better; it would need to be something
like "nr_frames_per_pte", which is starting to get longish.

So for the moment thanks for the R-b, but I will only apply it once
we've sorted the condition you provided it under.

Jan




 


Rackspace

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