From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0FD97C61DB9 for ; Thu, 27 Aug 2026 08:56:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8O2+meqk+5errRTxRO38XMtHT8YBDqFda/htRjSRNT8=; b=Oab3VgIMDLeg1u5urzp2EuCBV6 Z7ZPlxQs9lkQgfG5/NPVuM0EJjOChquKh5Ozv5ActFSSim0VrPSHwLzXkq7TGzH9zhnJ6WfcVUFwb ZhPM3oHqDwGuN4BaDNX010SrUYCBqfD3pVbq+nQkm6q1HDjzwv/pL5r9XdYHDwsZBBM0iyUwwETNo rNC8x5ss3e+MVq89wUE8Spnj3Kp/9oB5LH5dG7+nt82EIleqlb6eVwAZxQrSgATU1zBXQh83KYWxd gvGt50wulAi6qEDzn8EO5p8MrYMXF6jKnsv7fc4ZDjyjyNzPpOdftLshVwlRaAwL7AodSTtijAlP7 FNK3uKZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wzVu2-00000003h1p-2G0Z; Thu, 27 Aug 2026 08:56:06 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wzVu0-00000003h1T-2CaQ for linux-arm-kernel@lists.infradead.org; Thu, 27 Aug 2026 08:56:05 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 839861691; Thu, 27 Aug 2026 01:55:57 -0700 (PDT) Received: from [10.43.20.79] (unknown [10.43.20.79]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 72F0C3F85F; Thu, 27 Aug 2026 01:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1787820961; bh=yry31P4khI+DRCBsZQHN2ujbaVqF7+s8d6cewX4+B1I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eteg5u/KjRoj4FqWoRxTrgkSEGR4f8fW0aVO5jwh1hz61B2z2iPGtiU82NS9WV9JT ZMYCuFuGK/zi0HegqQE/Y/R4pKvDOIk9vBKgcOa699KxUiPkVxDtngXV0YPfqvM7Tv hUcCWW01AMbuMDiY2Csh1ojTfk35TAijFUYNmMwo= Message-ID: Date: Thu, 27 Aug 2026 10:55:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] arm64: mm: Map fixmap PTE tables r/o in the linear map To: Ard Biesheuvel , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org Cc: Will Deacon , Catalin Marinas , Mark Rutland , Ryan Roberts , Anshuman Khandual , Liz Prucka , Seth Jenkins , Kees Cook , Jann Horn , linux-hardening@vger.kernel.org References: <20260805104042.1107678-2-ardb+git@google.com> <5a3b89a6-bc42-42c3-82e8-25d6f1a2c5d2@arm.com> From: Kevin Brodsky Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260827_015604_654572_A5429CFA X-CRM114-Status: GOOD ( 24.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 26/08/2026 11:07, Ard Biesheuvel wrote: >>> [...] >>> >>> +static int __init fixmap_remap_ro(void) >>> +{ >>> + return set_direct_map_ro((unsigned long)lm_alias(&bm_pte), NR_BM_PTE_TABLES); >> Should we not also remap bm_pmd and bm_pud? >> >> For that matter, do we need RW access via the linear map for any page >> annotated with __bss_pgtbl? I suppose that might be the case for >> kasan_early_shadow_* but I don't know enough about KASAN to tell for sure. >> > bm_pte[] is special because it is only ever written via the kernel mapping, > and never via the linear map. This is why it is being singled out in this > patch. Right I see __set_fixmap(). This is a very special case of calling __set_pte() on a pointer derived from a global (i.e. pointing to the kernel image and not the LM) so it makes sense to treat it differently. I do wonder whether there is that much value in protecting bm_pte while all page tables in init_pg_dir (also at a fixed offset in the LM) remain writeable though. Either way all this is interesting for my series protecting page tables with pkeys [1] - it seems that to protect the fixmap, the easiest option would be to change the pkey of .pgtlb in both the kernel image and LM (the former for bm_pte, and the latter for everything else). [1] https://lore.kernel.org/all/20260818-kpkeys-v9-0-743ad31b2c8f@arm.com/ > Whether or not bm_pmd[] can be treated as a special case depends on the page > size: with 4k pages, the whole array covers a virtual region of 1G, which is > currently guaranteed to be shared only with the PCI I/O space (but we could > move that out). With 16k pages, it covers 64G, and so it is shared with the > vmemmap and other virtual mappings in the vmalloc region, and so the current > kernel mapping code expects to be able to write those entries. > > What we might do is generalize the logic that uses the fixmap to modify > pgd level entries in swapper_pg_dir, and use it for all modifications > at PMD level or higher if those tables are in .rodata > > But this is a bit more complicated than this change, so I decided to > present this as a separate change. Definitely, this is orthogonal to this patch. I wonder what the performance impact would be if we used the fixmap for setting all kernel entries at PMD and above. It would be nice to keep that logic easily togglable, because with the kpkeys approach I mentioned above we have a (most likely) much cheaper way of protecting these page tables. >>> +} >>> +late_initcall(fixmap_remap_ro); >> Is mark_rodata_ro() definitely too early to remap these pages RO? >> > No, we might just call this from there, afaict. Sounds good, could we then use update_mapping_prot()? I suppose not as that would require mapping bm_pte separately in map_mem()? - Kevin