This cause problems with pledged applications like xterm, as reported by
Benjamin Baier and also lacks support for IPv6 as shown in
Xorg bug #7611https://bugs.freedesktop.org/show_bug.cgi?id=7611
Discussed with jca@ and deraadt@ and submitted upstreams
autoconf function tests run without --std and have c11 visibility
timespec_get(3), a c11 function is found this way.
With gcc < 4.6 Mesa will build with --std=gnu99 with clang it will
build with --std=c99 and timespec_get() will no longer be visibile.
Further complicating things gcc 4.2 does not recognise --std=c11.
This was not noticed on linux as they build with _GNU_SOURCE which
among other things gives c11 visibility even with --std=c99.
discussed with millert@
issetugid(), not just the sloppy uid != euid test. gid != egid cases
can occur also.
Part of 6.6/009_mesaxlock.patch.sig and 6.5/020_mesaxlock.patch.sig
From Qualys, ok
From Brian Paul
02c3dad0f3b4d26e0faa5cc51d06bc50d693dcdc in mainline Mesa
"A security advisory (TALOS-2019-0857/CVE-2019-5068) found that
creating shared memory regions with permission mode 0777 could allow
any user to access that memory. Several Mesa drivers use shared-
memory XImages to implement back buffers for improved performance.
This path changes the shmget() calls to use 0600 (user r/w).
Tested with legacy Xlib driver and llvmpipe."
The intel driver can be used with inteldrm on ivy bridge or newer.
The radeon driver only works with amdgpu not radeondrm.
As we can't use python in xenocara add phony targets to create the
same output as python scripts which create json files for the loader.
This is just the ICDs, to use vulkan the loader and additional ports
are required.
ok mpi@ on an earlier version. Changed to call shm_unlink()
directly after shm_mkstemp() as suggested by kettenis@
drm render nodes have the same major as drm primary devices but offset
the minor by a base of 128.
I expected the name of the device to have numbering starting at 0 when
these non-linux codepaths were added (before we had render nodes).
* XKB-Config(7), XKB-Enhancing(7): user-level documentation
for XKB configuration; not perfect, but the best available.
* xtrans(3): a library actively maintained upstream.
* libXmu and libXext: Many libraries are effectively frozen upstream.
According to matthieu@, the documentation of libXmu and libXext
is among the most valuable of those.
Feedback and OK matthieu@.
