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

Re: [PATCH] Arm: correct FIX_LAST


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Tue, 13 Aug 2024 11:50:11 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com 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=YJ/LvH3zV8PEFWrbfGmZ8AE8YfMQ1Ai3D24Nvr6WKhM=; b=CjrFxTd+sMrV4FHtplolOBKWw2bEQ8QQ8t8pr7vTNo4nkfa4OGgkfLLiqgj/gmMFGwGqskKx9gzQdUNFpho3HEK/KcEhdlkjTcjcrv/FhsVJRzoJTn9TbXrkjCSaFWgBypm+cUl4zHNgaF4tK7vAPvznN15rvN4luxPERoPPvKJ+gaLO4tZiSadUofnvgj5BKSs/LpIo+bKwxZPA8aRc/TR2uDlhURyJ40h/KDYtyx2WhMYKA9XhUBR0lvD8FDIIs4JDXsl+mPxThXYdng/Ap9Esq0XWJ6NNlIEsbeDzwWEaAH/bZcIxRndBmM8LC0qUeRVja8/LnBB9dYBQou2b+w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RPRpTPuiTvvJAKaye5HBwiSJBirSYR+gAqtkNsS76qEL+tVAwq8lS8wv4qSeri91Qxog0NEPoxM3XnvHL4Ohb7jjl2pJjPIUwUTO1ID6yhNSxhGxU+EzsThyfm/5VdgiXlIUpHuCW1wHNZYhtpX8uY21FryLoqad1O+yuoP3U8z5NdWZBKUH+jgMFtCRbifkxkC1yfNBvxQxH96oGI4PRpSdxxFK69WsY9N0Qk1kXnlTAOq3e4FF2uUntmtkwY7rzw0q6X8W1kLR5pHUYP5TUgwze1ZTcitMsKZ9R+rtA0GeJg4OIdIY7taIkKtWzGgU0t/QnrUNOFxBtSZSTp3aKg==
  • Cc: Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
  • Delivery-date: Tue, 13 Aug 2024 09:50:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 13/08/2024 10:36, Jan Beulich wrote:
> 
> 
> While reviewing a RISC-V patch cloning the Arm code, I noticed an
> off-by-1 here: FIX_PMAP_{BEGIN,END} being an inclusive range, FIX_LAST
> cannot be the same as FIX_PMAP_END, or else the BUG_ON() in
> virt_to_fix() would trigger if FIX_PMAP_END ended up being used.
> 
> Fixes: 4f17357b52f6 ("xen/arm: add Persistent Map (PMAP) infrastructure")
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> Alternatively the definition of FIXADDR_TOP could be changed, if "last"
> should retain its strict meaning. Possibly a guard page also wants
> having at the end of the fixmap range, which could be effected by
> changing both #define-s at the same time.
I understand FIX_LAST as the last slot used, so in this regard it should retain 
its definition.
That said, I realized that we don't even check that the highest slot is still 
within the max number
of fixmap slots (today we have 512 slots). IMO we should gain a BUILD_BUG_ON to 
catch it.

With:
#define FIXADDR_TOP FIXMAP_ADDR(FIX_LAST + 1)
and sth like:
BUILD_BUG_ON(FIXADDR_TOP >= BOOT_FDT_VIRT_START);
possibly in build_assertions() in setup.c, we would:
 - fix off-by-1 issue
 - catch out-of-slot issue
 - gain a guard page

~Michal



 


Rackspace

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