From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Ryan Roberts" <ryan.roberts@arm.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, will@kernel.org,
catalin.marinas@arm.com, mark.rutland@arm.com,
"Anshuman Khandual" <anshuman.khandual@arm.com>,
"Liz Prucka" <lizprucka@google.com>,
"Seth Jenkins" <sethjenkins@google.com>,
"Kees Cook" <kees@kernel.org>,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 03/10] arm64: mm: Permit contiguous descriptors to be rewritten
Date: Tue, 27 Jan 2026 18:02:55 +0100 [thread overview]
Message-ID: <eff29cc6-29e6-4eda-8b44-aef30095252c@app.fastmail.com> (raw)
In-Reply-To: <da0b8783-590e-42a0-8937-f786a2ebcafa@arm.com>
On Tue, 27 Jan 2026, at 17:59, Ryan Roberts wrote:
> On 27/01/2026 15:03, Ard Biesheuvel wrote:
>> On Tue, 27 Jan 2026 at 10:45, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>
>>> On 26/01/2026 09:26, Ard Biesheuvel wrote:
>>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>>
>>>> Currently, pgattr_change_is_safe() is overly pedantic when it comes to
>>>> descriptors with the contiguous hint attribute set, as it rejects
>>>> assignments even if the old and the new value are the same.
>>>>
>>>> So relax the check to allow that.
>>>
>>> But why do we require the relaxation? Why are we re-writing a PTE in the first
>>> place? Either the caller already knows it's the same in which case it can be
>>> avoided, or it doesn't know in which case it is accidentally the same and couple
>>> probably just as easily been accidentally different? So it's better to warn
>>> regardless I would think?
>>>
>>
>> Based on rule RJQQTC in your reply to another patch in this series, my
>> conclusion here is that we can drop this check entirely.
>
> Hmm, I don't think that would be quite right; The rule permits _some_ bits of
> the PTE to change in a live mapping as long as the CONT bit remains unchanged.
> If you change the CONT bit on a live mapping, you could end up with overlapping
> TLB entries which would not go well on a system without bbml2.
I'm not suggesting we add it to 'mask', just to remove the check that forbids any manipulation of an entry that has PTE_CONT set. So toggling PTE_CONT itself would still be caught by the check.
next prev parent reply other threads:[~2026-01-27 17:03 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 9:26 [PATCH v2 00/10] arm64: Unmap linear alias of kernel data/bss Ard Biesheuvel
2026-01-26 9:26 ` [PATCH v2 01/10] arm64: Move the zero page to rodata Ard Biesheuvel
2026-01-27 9:34 ` Ryan Roberts
2026-01-27 9:49 ` Ard Biesheuvel
2026-01-27 10:03 ` Ryan Roberts
2026-01-27 10:50 ` Ard Biesheuvel
2026-01-26 9:26 ` [PATCH v2 02/10] arm64: Move fixmap page tables to end of kernel image Ard Biesheuvel
2026-01-27 9:42 ` Ryan Roberts
2026-01-26 9:26 ` [PATCH v2 03/10] arm64: mm: Permit contiguous descriptors to be rewritten Ard Biesheuvel
2026-01-27 9:45 ` Ryan Roberts
2026-01-27 15:03 ` Ard Biesheuvel
2026-01-27 16:59 ` Ryan Roberts
2026-01-27 17:02 ` Ard Biesheuvel [this message]
2026-01-27 17:37 ` Ryan Roberts
2026-01-26 9:26 ` [PATCH v2 04/10] arm64: mm: Preserve existing table mappings when mapping DRAM Ard Biesheuvel
2026-01-27 9:58 ` Ryan Roberts
2026-01-26 9:26 ` [PATCH v2 05/10] arm64: mm: Preserve non-contiguous descriptors " Ard Biesheuvel
2026-01-27 9:58 ` Ryan Roberts
2026-01-26 9:26 ` [PATCH v2 06/10] arm64: mm: Remove bogus stop condition from map_mem() loop Ard Biesheuvel
2026-01-27 10:06 ` Ryan Roberts
2026-01-26 9:26 ` [PATCH v2 07/10] arm64: mm: Drop redundant pgd_t* argument from map_mem() Ard Biesheuvel
2026-01-27 10:10 ` Ryan Roberts
2026-01-26 9:26 ` [PATCH v2 08/10] arm64: mm: Don't abuse memblock NOMAP to check for overlaps Ard Biesheuvel
2026-01-27 10:21 ` Ryan Roberts
2026-01-27 10:27 ` Ard Biesheuvel
2026-01-27 10:39 ` Ryan Roberts
2026-01-27 10:47 ` Ard Biesheuvel
2026-01-27 11:00 ` Ryan Roberts
2026-01-27 11:03 ` Ard Biesheuvel
2026-01-27 11:09 ` Ryan Roberts
2026-01-26 9:26 ` [PATCH v2 09/10] arm64: mm: Map the kernel data/bss read-only in the linear map Ard Biesheuvel
2026-01-27 10:33 ` Ryan Roberts
2026-01-27 10:36 ` Ard Biesheuvel
2026-01-27 10:41 ` Ryan Roberts
2026-01-26 9:26 ` [PATCH v2 10/10] arm64: mm: Unmap kernel data/bss entirely from " Ard Biesheuvel
2026-01-27 10:50 ` Ryan Roberts
2026-01-27 10:54 ` Ard Biesheuvel
2026-01-27 11:02 ` Ryan Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eff29cc6-29e6-4eda-8b44-aef30095252c@app.fastmail.com \
--to=ardb@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizprucka@google.com \
--cc=mark.rutland@arm.com \
--cc=ryan.roberts@arm.com \
--cc=sethjenkins@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox