linux-kernel - Re: [PATCH v7 3/4] rseq: Make rseq work with protection keys

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: <87y0nrfsls.ffs@tglx>
Date: Thu, 27 Nov 2025 15:38:39 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Florian Weimer <fweimer@...hat.com>
Cc: Kevin Brodsky <kevin.brodsky@....com>, Dmitry Vyukov
 <dvyukov@...gle.com>, mathieu.desnoyers@...icios.com,
 peterz@...radead.org, boqun.feng@...il.com, mingo@...hat.com,
 bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
 aruna.ramakrishna@...cle.com, elver@...gle.com, "Paul E. McKenney"
 <paulmck@...nel.org>, x86@...nel.org, linux-kernel@...r.kernel.org, Jens
 Axboe <axboe@...nel.dk>
Subject: Re: [PATCH v7 3/4] rseq: Make rseq work with protection keys

On Wed, Nov 26 2025 at 23:06, Florian Weimer wrote:
> * Thomas Gleixner:
>>          cur = pkey_extend(signal_perms);
>>
>> --> Perms are now [PK0=RW, PK1=R, PK2=RW, PK7=R]         
>>
>>          access_user_rseq();
>>          pkey_set(cur);
>>
>> If the RSEQ access is nested in the signal delivery return then nothing
>> happens as the permissions are not changing because they are already
>> extended: A | A = A :).
>
> Agreed.  And the pkey_extend/pkey_set don't have a prohibitive cost, I
> assume.  I got the impression you were trying to avoid that sequence,
> but I think it's more about defining the way pkey_extend works.

Correct.

I was trying to avoid doing it on the exit to user path, but after
thinking more about it, I'm not so worried about it anymore.

With the recent rewrite of the RSEQ handling in the exit code path that
should more or less vanish in the noise. I'll hack something up and
evaluate the impact.

The real question is the semantics of this mechanism. In your proposed
patch you define it as (if I read it correctly):

   1) The default signal protection is the same as the default for fork,
      which is PKEY0 unless user space changes it.

   2) pkey_alloc() with PKEY_ALLOC_SETSIGNAL set propagates the
      protection to the signal mask/permission set

   3) The permissions on signal delivery are:

          (default & signal_mask) | signal_perms

I'm not entirely sure whether #3 is the right thing to do. My initial
thought was to keep the current permission set at the point where the
task got interrupted and expand it with the signal permissions, i.e:

          (current & signal_mask) | signal_perms

Both variants can be argued for, but we have to agree on one them :)

Thanks,

        tglx