linux-kernel - Re: [PATCH] selftests/rseq: Fix handling of glibc without rseq support

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: <28c050bb-d844-4b85-a49b-39f2defc20ef@efficios.com>
Date: Tue, 14 Jan 2025 19:45:56 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Shuah Khan <skhan@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, Raghavendra Rao Ananta
 <rananta@...gle.com>, Peter Zijlstra <peterz@...radead.org>,
 Boqun Feng <boqun.feng@...il.com>, "Paul E. McKenney" <paulmck@...nel.org>,
 Carlos O'Donell <carlos@...hat.com>, Florian Weimer <fweimer@...hat.com>,
 Michael Jeanson <mjeanson@...icios.com>, linux-kselftest@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH] selftests/rseq: Fix handling of glibc without rseq
 support

On 2025-01-14 19:14, Shuah Khan wrote:
> On 1/14/25 07:51, Mathieu Desnoyers wrote:
>> When porting librseq commit:
>>
>> commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
>>
>> from librseq to the kernel selftests, the following line was missed
>> at the end of rseq_init():
>>
>>    rseq_size = get_rseq_kernel_feature_size();
>>
>> which effectively leaves rseq_size initialized to -1U when glibc does not
>> have rseq support. glibc supports rseq from version 2.35 onwards.
>>
>> In a following librseq commit
>>
>> commit c67d198627c2 ("Only set 'rseq_size' on first thread registration")
>>
>> to mimic the libc behavior, a new approach is taken: don't set the
>> feature size in 'rseq_size' until at least one thread has successfully
>> registered. This allows using 'rseq_size' in fast-paths to test for both
>> registration status and available features. The caveat is that on libc
>> either all threads are registered or none are, while with bare librseq
>> it is the responsability of the user to register all threads using rseq.
>>
>> This combines the changes from the following librseq commits:
>>
>> commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
>> commit c67d198627c2 ("Only set 'rseq_size' on first thread registration")
>>
>> Fixes: 73a4f5a704a2 ("selftests/rseq: Fix mm_cid test failure")
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> 
> Hi Mathieu,
> 
> Can you double check these commits and make sure these are right
> ones in the mainline rc7?
> 
> I am seeing "Unknown commit id" warnings on all of these - my
> repo is at 6.13 rc7

This is because those are commits in the librseq project at
https://git.kernel.org/pub/scm/libs/librseq/librseq.git/
which is a different tree from the Linux kernel. I am not
sure what is the preferred approach when citing a
commit ID from a different project ?

I've been keeping both rseq selftests and librseq in
sync since 2018. I plan to eventually add a dependency
of the rseq selftests on librseq, but this cannot
happen until we freeze the API and cut a librseq
release.

This was premature before we reached the major milestone
of having extensible rseq support in glibc.

Now that it's merged into glibc (as of last week),
we can start looking forward to a librseq release,
which should eventually eliminate code duplication
with rseq selftests.

Perhaps we should add a Link: to the librseq
repository ?

> 
> Also would you like to add Reported-by for Raghavendra Rao Ananta?

Yes, please. Can you add it as you merge my patch ?

Thanks,

Mathieu

> 
> thanks,
> -- Shuah

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com