linux-kernel - Re: [PATCH 2/2] LoongArch: Extend the maximum number of watchpoints

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1036be20-7d6f-4066-8777-41f9ea6c53ff@xen0n.name>
Date: Sat, 25 Jan 2025 00:09:50 +0800
From: WANG Xuerui <kernel@...0n.name>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>, Xi Ruoyao <xry111@...111.site>,
 Huacai Chen <chenhuacai@...nel.org>
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] LoongArch: Extend the maximum number of watchpoints

On 1/22/25 11:09, Tiezhu Yang wrote:
> On 01/21/2025 09:46 PM, Xi Ruoyao wrote:
>> On Tue, 2025-01-21 at 21:35 +0800, WANG Xuerui wrote:
>>> one cannot account for older (in fact, *every existing*) clients
>>> expecting the old UAPI, hence providing a smaller buffer than struct
>>> user_watch_state_v2. In which case the kernel will happily write
>>> out-of-bounds if the client asks for the current watchpoint state. This
>>> is not acceptable I'm afraid.
>>
>> Yes, many distros support running the latest kernel with an old
>> userspace for hardware compatibility reason and the change will blow up
>> gdb on all those distros.  We need to do something smarter to retain the
>> backward compatibility.
> 
> Hi Xuerui and Ruoyao,
> 
> 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.
> 
> If you have more comments, please let me know.

Thanks for posting the analysis; it was good to know the equivalent of 
sizeof(input) handling actually resides in the arch-independent side.

But next time please just include the explanation in v1 commit message 
to save us many replies back-and-forth. ;-)

-- 
WANG "xen0n" Xuerui

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