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] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fty9hc2u.fsf@mid.deneb.enyo.de>
Date:   Sun, 16 Sep 2018 14:16:25 +0200
From:   Florian Weimer <fw@...eb.enyo.de>
To:     Rich Felker <dalias@...c.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>, linux-man@...r.kernel.org,
        "Michael Kerrisk \(man-pages\)" <mtk.manpages@...il.com>
Subject: Re: futex_cmpxchg_enabled breakage

* Rich Felker:

> I just spent a number of hours helping someone track down a bug that
> looks like it's some kind of futex_cmpxchg_enabled detection error on
> powerpc64 (still not sure of the root cause; set_robust_list producing
> -ENOSYS), and a while back I hit the same problem on sh2 due to lack
> of EFAULT on nommu, leading to commit 72cc564f16ca. I think the test
> (introduced way back in commit a0c1e9073ef7) is fundamentally buggy;
> if anything, it should be checking for !=-ENOSYS, not ==-EFAULT.
> Presumably it could also fail to produce -EFAULT if mmap_min_addr is 0
> and page 0 is mapped (a bad idea, but maybe someone does it...). And
> of course other nommu archs are possibly still broken.

Maybe it was related to this (“Kernel 4.15 lost set_robust_list
support on POWER 9”):

<https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-February/168570.html>

The Kconfig change you suggest was explicitly rejected as the fix.

I believe the expected userspace interface is that you probe support
with set_robust_list first, and then start using the relevant futex
interfaces only if that call succeeded.  If you do that, most parts of
a typical system will work as expected even if the kernel support is
not there, which is a bit surprising.  It definitely makes the root
cause harder to spot.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ