[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] xen/arm: Fix off-by-one in iomem_deny_access() calls
- To: "Halder, Ayan Kumar" <ayankuma@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Orzel, Michal" <michal.orzel@xxxxxxx>
- Date: Fri, 10 Apr 2026 08:26:33 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.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=arcselector10001; 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=YfOmYGha/Ue2m5vrnZa2Nu+QmhZgfzGz0efzYiWJaGU=; b=EkDtN+d5KXorG2gWWBCjtKSlKaZdkAIdHBbagzJYWWjUR9fVqdm4TAhiuaHn72LzJSvP9wprvk55Z0rtNWpNcm2/cFA3K+9YETLZedlpmSE68cSnomMB6lppwvSVKANcoL8gRFLEiIJUXV73ZuO54bESZ6Q//GZTgsqhUx2Isi5nlOPkZcTahAV1pd+BjdZ7naHWES3fD7izdYDEJEDZtdh2QUdvhA5BsV1jLj05kawfpMbhJBeNz9UFtuJwxZlN2Aj7z8hzE7rDl+k8d1WZlxyM3+yQ2pq/UmwTs0S0QfWrZV0l2O7PYXSV6Sb7a3VLvS1IgDeoh0Txhnq2oBIDxQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JMzuPl8/BMbwwcPERX2C9gDETdgS1DcCqMBAdZEhs82Ktl2RLHHpEhjKAQoi65TiYVedXoAl8/eqi0BQShb6UhGxqkVvgpgylN+Ap+HOZpCEfsdJ6phBbznbBwY6unmKHxk8GRpcKkH2QT5R1fwIfW3HeNg1NzjxEAIJqyvvAhy5xMay81rmXJQcUi221NOeAjZ6Y4LmvXKbZZ8r9yeOiLmbc04tnQx+SrzPheVPFHDNAqwi0JtSdaWAraLwp6lX1R9wAiFavYgGtJyc85lDz6TUZ77333AXBqJ5Z0sHA0TJGZiJMbxP4jo+i4Xq5H9/HCQogL+hChCg73eUjGaOFg==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>
- Delivery-date: Fri, 10 Apr 2026 06:26:56 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 09/04/2026 13:49, Halder, Ayan Kumar wrote:
> Hi Michal,
>
> Apologies if my review is weird, I have been looking into too much of
> safety stuff.
Yes, I know :)
>
> On 09/04/2026 12:39, Michal Orzel wrote:
>> iomem_deny_access() wraps rangeset_remove_range() which takes inclusive
>> endpoints. All call sites in the GIC and ACPI code pass 'mfn + nr' (or
>> 'mfn + 1' for single-page regions) as the end parameter, which causes
>> one extra page beyond each region to be denied.
>>
>> For single-page regions, use 'mfn' as the end (denying exactly one page).
>> For all multi-page regions, use 'mfn + nr - 1'.
>
> Just reading this and the change below, it seems that the issue was
> caught while doing some boundary value analysis. In this specific case,
> it seems the boundary values were set incorrectly.
>
> Can you explain a bit more (the boundary/edge cases) in the commit
> message and give some reference to test (can be even a different repo or
> something) on how you caught this and verified it to be correct ?
>
> We can keep this test somewhere (and tag it to the commit) even if such
> tests does not make sense to be upstreamed.
As much as it looks like an issue found during BVA, the truth is I found it by
accident when debugging some issue where rangesets were involved. As always,
whenever I see a function with parameters {start, end}, I need to dive deeper to
verify whether end is inclusive or not. I also check the call-sites to validate
my observations and that's how I found these bugs.
~Michal
|
