linux-kernel - Re: [PATCH v2 1/1] x86/fred/signal: Prevent single-step upon ERETU completion

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ec1af0a2-d07a-4963-bae7-8a7f559798bd@zytor.com>
Date: Thu, 22 May 2025 20:48:44 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>,
        Dave Hansen <dave.hansen@...el.com>, "Xin Li (Intel)" <xin@...or.com>,
        linux-kernel@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, peterz@...radead.org,
        stable@...r.kernel.org
Subject: Re: [PATCH v2 1/1] x86/fred/signal: Prevent single-step upon ERETU
 completion

On 5/22/25 17:10, Andrew Cooper wrote:
>>>
>>> ~Andrew
>> SIGTRAP → sigreturn. Basically, we have to uplevel the suppression behavior to the kernel (where it belongs) instead of doing it at the ISA level. 
> 
> So the problem is specifically that we're in a SYSCALL context (from
> FRED's point of view), and we rewrite state in the FRED FRAME to be
> another context which happened to have eflags.TF set.
> 
> And the combination of these two triggers a new singlestep to be pending
> immediately.
> 
> I have to admit that I didn't like the implication from the SYSCALL bit,
> and argued to have it handled differently, but alas.  I think the real
> bug here is trying to ERETU with a splice of two different contexts
> worth of FRED state.
> 

To some degree it is, yes. And it is sigreturn that does that splicing.

But it is desirable to be able to single-step across sigreturn if one is
debugging from inside the signal handler, hence we should not clearing
TF if it is set on sigreturn entry.

This is in fact exactly analogous to ERETU ignoring the syscall bit if
TF is set before ERETU is executed, just one abstraction level higher up
in the stack.

	-hpa