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: <0a650379-e4b4-0a30-e4b0-e8d131ae1dbb@huawei.com>
Date: Thu, 29 Jan 2026 21:06:27 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: Kevin Brodsky <kevin.brodsky@....com>, <catalin.marinas@....com>,
	<will@...nel.org>, <oleg@...hat.com>, <tglx@...utronix.de>,
	<peterz@...radead.org>, <luto@...nel.org>, <shuah@...nel.org>,
	<kees@...nel.org>, <wad@...omium.org>, <deller@....de>,
	<akpm@...ux-foundation.org>, <charlie@...osinc.com>, <mark.rutland@....com>,
	<anshuman.khandual@....com>, <song@...nel.org>, <ryan.roberts@....com>,
	<thuth@...hat.com>, <ada.coupriediaz@....com>, <broonie@...nel.org>,
	<pengcan@...inos.cn>, <liqiang01@...inos.cn>, <kmal@...k.li>,
	<dvyukov@...gle.com>, <reddybalavignesh9979@...il.com>,
	<richard.weiyang@...il.com>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH v11 03/14] arm64: ptrace: Move rseq_syscall() before
 audit_syscall_exit()



On 2026/1/29 20:06, Kevin Brodsky wrote:
> On 28/01/2026 04:19, Jinjie Ruan wrote:
>> commit a9f3a74a29af ("entry: Provide generic syscall exit function")
>> introduce generic syscall exit function and call rseq_syscall()
>> before audit_syscall_exit() and arch_syscall_exit_tracehook().
>>
>> And commit b74406f37737 ("arm: Add syscall detection for restartable
>> sequences") add rseq support for arm32, which also call rseq_syscall()
>> before audit_syscall_exit() and tracehook_report_syscall().
>>
>> However, commit 409d5db49867c ("arm64: rseq: Implement backend rseq
>> calls and select HAVE_RSEQ") implement arm64 rseq and call
>> rseq_syscall() after audit_syscall_exit() and tracehook_report_syscall().
>> So compared to the generic entry and arm32 code, arm64 calls
>> rseq_syscall() a bit later.
>>
>> But as commit b74406f37737 ("arm: Add syscall detection for restartable
>> sequences") said, syscalls are not allowed inside restartable sequences,
>> so should call rseq_syscall() at the very beginning of system call
>> exiting path for CONFIG_DEBUG_RSEQ=y kernel. This could help us to detect
>> whether there is a syscall issued inside restartable sequences.
>>
>> As for the impact of raising SIGSEGV via rseq_syscall(), it makes no
>> practical difference to signal delivery because signals are processed
>> in arm64_exit_to_user_mode() at the very end.
>>
>> As for the "regs", rseq_syscall() only checks and update
>> instruction_pointer(regs), ptrace can not modify the "pc" on syscall exit
>> path but 'only changes the return value', so calling rseq_syscall()
>> before or after ptrace_report_syscall_exit() makes no difference.
> 
> Let's update this as discussed on v10 - PC can be modified when
> ptrace_report_syscall_exit() is called.

Should rseq see the PC modified by ptrace on the syscall exit path?
If the PC modified by ptrace happens to fall inside the user-space rseq
critical section, is that reasonable? If so, doesn't that make the order
of rseq and ptrace syscall exit in generic entry incorrect?

Could we have an rseq expert join the discussion — Thomas, what is your
opinion?

> 
>> And audit_syscall_exit() only checks the return value (x0 for arm64),
>> so calling rseq_syscall() before or after audit syscall exit makes
>> no difference. trace_sys_exit() only uses syscallno and the return value,
>> so calling rseq_syscall() before or after trace_sys_exit() also makes
>> no difference.
>>
>> In preparation for moving arm64 over to the generic entry code, move
>> rseq_syscall() ahead before audit_syscall_exit().
>>
>> No functional changes.
> 
> And naturally this is not the case.
> 
> - Kevin
> 
>> Reviewed-by: Kevin Brodsky <kevin.brodsky@....com>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@...wei.com>
>> ---
>>  arch/arm64/kernel/ptrace.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>> index 9f9aa3087c09..785280c76317 100644
>> --- a/arch/arm64/kernel/ptrace.c
>> +++ b/arch/arm64/kernel/ptrace.c
>> @@ -2443,6 +2443,8 @@ int syscall_trace_enter(struct pt_regs *regs, unsigned long flags)
>>  
>>  void syscall_trace_exit(struct pt_regs *regs, unsigned long flags)
>>  {
>> +	rseq_syscall(regs);
>> +
>>  	audit_syscall_exit(regs);
>>  
>>  	if (flags & _TIF_SYSCALL_TRACEPOINT)
>> @@ -2450,8 +2452,6 @@ void syscall_trace_exit(struct pt_regs *regs, unsigned long flags)
>>  
>>  	if (flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP))
>>  		report_syscall_exit(regs);
>> -
>> -	rseq_syscall(regs);
>>  }
>>  
>>  /*
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ