linux-kernel - Re: BUG: debug_exception_enter() disables preemption and may call sleeping functions on aarch64 with RT

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: <20250212112145.BIE8_6T2@linutronix.de>
Date: Wed, 12 Feb 2025 12:21:45 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: "Luis Claudio R. Goncalves" <lgoncalv@...hat.com>
Cc: Mark Rutland <mark.rutland@....com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-rt-devel@...ts.linux.dev,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
	Ryan Roberts <ryan.roberts@....com>,
	Mark Brown <broonie@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
	Joey Gouly <joey.gouly@....com>, linux-kernel@...r.kernel.org
Subject: Re: BUG: debug_exception_enter() disables preemption and may call
 sleeping functions on aarch64 with RT

On 2025-02-11 21:48:08 [-0300], Luis Claudio R. Goncalves wrote:
> > Couldn't you delay sending signals until after the preempt-disable
> > section? 
> 
> Looking at do_debug_exception,
> 
> void do_debug_exception(unsigned long addr_if_watchpoint, unsigned long esr,
> 			struct pt_regs *regs)
> {
> 	const struct fault_info *inf = esr_to_debug_fault_info(esr);
> 	unsigned long pc = instruction_pointer(regs);
> 
> 	debug_exception_enter(regs);
> 
> 	if (user_mode(regs) && !is_ttbr0_addr(pc))
> 		arm64_apply_bp_hardening();
> 
> 	if (inf->fn(addr_if_watchpoint, esr, regs)) {
> 		arm64_notify_die(inf->name, regs, inf->sig, inf->code, pc, esr);
> 	}
> 
> 	debug_exception_exit(regs);
> }
> NOKPROBE_SYMBOL(do_debug_exception);
> 
> 
> Do you mean executing the
> 
> 	arm64_notify_die(inf->name, regs, inf->sig, inf->code, pc, esr);
> 
> after re-enabling the preemption or do you mean something more
> sophisticated?

single_step_handler() and brk_handler() can both send signals. If
inf->fn returns != 0 (which seems to be only be possible for
brk_handler() out of the possible four callbacks) this this
arm64_notify_die() sends a signal.
So we have three potential signal delivers. It shouldn't matter if the
signal is sent within the preempt-disable section or outside because the
signal will be queued for current and delivered on the return to
userland. So would just need to save the details and do it outside. Now
that I actually looked at the code, this might lead to a bit of a mess
so splitting out the signal part and avoiding the preempt-off part might
better which would be the rework that Mark was talking about.

> Luis

Sebastian