--Apple-Mail=_21E76CFE-44C8-4703-B333-05DB9A8BBFD0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jan 29, 2021, at 12:01 PM, Marcus Meissner <meissner@suse.de> =
wrote:
> Mitre has now assigned CVE-2021-3347.
>=20
> On Fri, Jan 29, 2021 at 05:42:08PM +0100, Solar Designer wrote:
>> Hi,
>>=20
>> I'm not familiar with futexes, but just to save others a few minutes =
on
>> looking this up:
>=20
> (Is anyone? Futex are too complex for me at least, I would guess also=20=

> using them is error prone.)

Here=E2=80=99s some helpful context. "A futex overview and update=E2=80=9D=
 (2009) at https://lwn.net/Articles/360699/
"The futex mechanism... is a fast, lightweight kernel-assisted locking =
primitive for user-space applications. It provides for very fast =
uncontended lock acquisition and release. The futex state is stored in a =
user-space variable (an unsigned 32-bit integer on all platforms). =
Atomic operations are used in order to change the state of the futex in =
the uncontended case without the overhead of a syscall. In the contended =
cases, the kernel is invoked to put tasks to sleep and wake them up. =
Futexes are the basis of several mutual exclusion constructs commonly =
used in threaded programming."

More recently: "Rethinking the futex API=E2=80=9D (2020): =
https://lwn.net/Articles/823513/
"The current effort to rework futexes appears to be driven by a couple =
of concerns. One that goes mostly unstated is the desire to create a =
system-call interface that makes a bit more sense than futex(), which is =
a complex, multiplexed API with wildly varying arguments and a number of =
special cases.=E2=80=9D

--- David A. Wheeler


--Apple-Mail=_21E76CFE-44C8-4703-B333-05DB9A8BBFD0--