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: <191d85a5-c801-49d6-890c-f3c8e5e7f3ef@xen0n.name>
Date: Sat, 25 Jan 2025 00:10:54 +0800
From: WANG Xuerui <kernel@...0n.name>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>, Huacai Chen <chenhuacai@...nel.org>
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] LoongArch: Extend the maximum number of
 watchpoints

On 1/22/25 11:23, Tiezhu Yang wrote:
> The maximum number of load/store watchpoints and fetch instruction
> watchpoints is 14 each according to LoongArch Reference Manual, so
> extend the maximum number of watchpoints from 8 to 14 for ptrace.
> 
> By the way, just simply change 8 to 14 for the definition in struct
> user_watch_state at the beginning, but it may corrupt uapi, then add
> a new struct user_watch_state_v2 directly.
> 
> As far as I can tell, the only users for this struct in the userspace
> are GDB and LLDB, there are no any problems of software compatibility
> between the application and kernel according to the analysis.
> 
> The compatibility problem has been considered when developing and testing
> the patches, when the applications in the userspace get watchpoint state,
> the length will be specified which will not bigger than the sizeof struct
> user_watch_state or user_watch_state_v2, the actual length is assigned as
> the minimal value of the application and kernel in the generic ptrace:
> 
> kernel/ptrace.c: ptrace_regset():
> 
> 	kiov->iov_len = min(kiov->iov_len,
> 			    (__kernel_size_t) (regset->n * regset->size));
> 
> 	if (req == PTRACE_GETREGSET)
> 		return copy_regset_to_user(task, view, regset_no, 0,
> 					   kiov->iov_len, kiov->iov_base);
> 	else
> 		return copy_regset_from_user(task, view, regset_no, 0,
> 					     kiov->iov_len, kiov->iov_base);
> 
> For example, there are four kind of combinations, all of them work well.
> 
> (1) "older kernel + older gdb", the actual length is 8+(8+8+4+4)*8=200;
> (2) "newer kernel + newer gdb", the actual length is 8+(8+8+4+4)*14=344;
> (3) "older kernel + newer gdb", the actual length is 8+(8+8+4+4)*8=200;
> (4) "newer kernel + older gdb", the actual length is 8+(8+8+4+4)*8=200.
> 
> Link: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
> Fixes: 1a69f7a161a7 ("LoongArch: ptrace: Expose hardware breakpoints to debuggers")
> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
> ---
>   arch/loongarch/include/uapi/asm/ptrace.h | 10 ++++++++++
>   arch/loongarch/kernel/ptrace.c           |  6 +++---
>   2 files changed, 13 insertions(+), 3 deletions(-)

Looks good now with the UAPI stability analysis:

Reviewed-by: WANG Xuerui <git@...0n.name>

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ