linux-kernel - Re: [git pull] drm request 3

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ff13bc9a1003050756rca44e03uffbfa3090f96e0ac@mail.gmail.com>
Date:	Fri, 5 Mar 2010 16:56:10 +0100
From:	Luca Barbieri <luca.barbieri@...il.com>
To:	Daniel Stone <daniel@...ishbar.org>,
	David Miller <davem@...emloft.net>, skeggsb@...il.com,
	airlied@...ux.ie, linux-kernel@...r.kernel.org,
	jbarnes@...tuousgeek.org, dri-devel@...ts.sf.net, mingo@...e.hu,
	torvalds@...ux-foundation.org, alan@...rguk.ukuu.org.uk
Subject: Re: [git pull] drm request 3

It seems to me that Linus' technical argument is indeed being mostly ignored.

While breaking the ABI is unfortunate, the real problem that Linus
complained about is that you can't install several userspace versions
side-by-side.

This means that if you install your new kernel and userspace, reboot,
and find the new kernel doesn't work for some reason, you can't just
go back to the old kernel and have working X, because you just
replaced userspace with a version that no longer works with the kernel
that worked correctly.

This is even worse for distributions that want to upgrade the kernel,
because each kernel package would need to have a Depends on the exact
userspace package version.
Thus, the package manager would remove the older kernel when the new
one is installed (since they depend on different versions of the same
userspace package).
If the new kernel somehow doesn't work, the user is totally screwed
and must reboot from a live CD.

As pointed out, in this case, it is relatively easy to solve by adding
a version number to libdrm-nouveau, the X driver and the DRI drivers.
X will then have to load the correct driver and give Mesa the DRI
driver name with the correct version appended.

It may be a good idea to do this before the new nouveau ABI gets
shipped in released distributions, and with a generic mechanisms that
can be used by all X/drm drivers.

Workarounds are possible, such as replacing /usr/bin/X with a script
that loads the correct version, or using X over /dev/fb0 (which should
work fine with any DRM KMS driver, and any non-DRI framebuffer), but
they shouldn't be needed.

BTW, the nVidia proprietary driver also ties the kernel and userspace
version in this way, and is actually worse because it replaces the X
libglx.so, breaking all other drivers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/