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] [day] [month] [year] [list]
Date:   Tue, 09 Aug 2022 08:18:54 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Gavin Shan <gshan@...hat.com>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Sean Christopherson <seanjc@...gle.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: tools/testing/selftests/kvm/rseq_test and glibc 2.35

* Gavin Shan:

> Hi Florian,
>
> On 8/9/22 2:01 AM, Florian Weimer wrote:
>> It has come to my attention that the KVM rseq test apparently needs to
>> be ported to glibc 2.35.  The background is that on aarch64, rseq is the
>> only way to get a practically useful sched_getcpu.  (There's no hidden
>> per-task CPU state the vDSO could reveal as the CPU ID.)
>> 
>
> Yes, kvm/selftests/rseq needs to support glibc 2.35. The question is
> about glibc 2.34 or 2.35 because kvm/selftest/rseq fails on glibc 2.34
>
> I would guess upstream-glibc-2.35 feature is enabled on downstream
> glibc-2.34?
>
> # ./rseq_test
> ==== Test Assertion Failure ====
>   rseq_test.c:60: !r
>   pid=112043 tid=112043 errno=22 - Invalid argument
>      1	0x0000000000401973: main at rseq_test.c:226
>      2	0x0000ffff84b6c79b: ?? ??:0
>      3	0x0000ffff84b6c86b: ?? ??:0
>      4	0x0000000000401b6f: _start at ??:?
>   rseq failed, errno = 22 (Invalid argument)
> # rpm -aq | grep glibc-2
> glibc-2.34-39.el9.aarch64

Yes, we have enabled it downstream.

  glibc: Restartable sequences interfaces and sched_getcpu accelerated
  by default
  <https://bugzilla.redhat.com/show_bug.cgi?id=2085529>

However,

  GLIBC_TUNABLES=glibc.pthread.rseq=0 ./rseq_test

should still work (we added the ability to disable rseq registration
precisely to enable scenarios like this), but tunables are an optional
glibc feature, so the upstream kernel should probably still be fixed.

> Mathieu and Florian, the fixes have been posted. It would be nice for you
> to review if you have free cycles :)
> 
> https://lore.kernel.org/kvmarm/20220809060627.115847-1-gshan@redhat.com/T/#t

Excellent.  I'm going to have a look.

Thanks,
Florian

Powered by blists - more mailing lists