linux-kernel - Re: [Question] mprotect() can't clear PROT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3fe7e501-b319-4b9b-b129-dce5e945bf9a@os.amperecomputing.com>
Date: Mon, 3 Nov 2025 10:22:12 -0800
From: Yang Shi <yang@...amperecomputing.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: LAK <linux-arm-kernel@...ts.infradead.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Question] mprotect() can't clear PROT_MTE



On 10/31/25 11:48 AM, Catalin Marinas wrote:
> Hi Yang,
>
> On Wed, Oct 29, 2025 at 03:41:17PM -0700, Yang Shi wrote:
>> Our customers have usecase to untag memory w/o unmapping it, but mprotect
>> can't do it. It seems like an intended behavior because I saw MTE doc
>> explicitly says PROT_MTE flags can't be cleared by mprotect().
>> But I don't see why mprotect() can't do it if I don't miss anything. So I'd
>> like to know why it behaves in this way.
> It would be interesting to know more about the use-case. At the time,
> clearing PROT_MTE got in the way. The theory was that an allocator
> controls the tags and the PROT_MTE property but if that range is used by
> something like a JIT, toggling between PROT_WRITE and PROT_EXEC would
> inadvertently clear PROT_MTE. I'm not sure whether this would happen in
> practice though but it's ABI already, so we can't change it.

I'm not quite sure about their usecase yet.

Yeah, understand. It has been an established behavior.

>
> I'm happy to add support for this if there's a concrete use-case but it
> will need to be gated by a prctl() flag to keep the current ABI. A
> weirder approach would be to add a PROT_MTE_CLEAR flag (I think I prefer
> the prctl).

I agree we should not change the current ABI, some applications may 
already rely on it. prctl sounds fine to me. Anyway we can discuss more 
about how to implement it once we have more solid usecase.

Thanks for educating me about the context.

Yang

>