Mailinglist Archive: opensuse (1839 mails)

< Previous Next >
Re: [opensuse] latest kernel update breaks ATI binary driver
  • From: "Carlos E. R." <carlos.e.r@xxxxxxxxxxxx>
  • Date: Mon, 27 Sep 2010 12:42:18 +0200 (CEST)
  • Message-id: <alpine.LNX.2.00.1009271237370.12451@xxxxxxxxxxxxxxxxx>
Hash: SHA1

On Monday, 2010-09-27 at 11:19 +0100, Tejas Guruswamy wrote:

On 26/09/10 21:55, Carlos E. R. wrote:
I don't see why SUSE/Novell has to apply this change to a kernel that
was already released to us, in a stable distro. I believe the should
simply correct bugs, as they always do, without upgrading the kernel,
and leave further changes for factory (or KOTD).

I think people are missing/forgetting something. This WAS a security
patch - all these changes are associated with CVE 2010-3081 ([1]). It's
that massive 32-bit compatibility mode root exploit on 64-bit systems
bug that was being discussed last week. This bug was ridiculously nasty
and exploitable and a kernel security update had to be pushed out ASAP.
Linus's commit: [2].

Here's an explanation of the effects of the change from the debian ML [3]:
"compat-alloc-user-space() is only used for syscalls AFAIK. The rule is:
you do that, you have to track the kernel. In fact, it is now GPL-only
(so, for example, fglrx needs to be modified as it is forbidden from
using compat-alloc-user-space()).
compat-alloc-user-space() is now EXPORT-SYMBOL-GPL
* cannot be used by fglrx and other non-GPL modules
* using arch-compat-alloc-user-space() may reopen CVE-2010-3081 if the
non-GPL module doesn't do access-ok by itself
compat-alloc-user-space() moved from asm/compat.h to linux/compat.h
* requires #include changes on out-of-tree modules that use
compat-alloc-user-space() for them to build"

And here's a quote from lkml [4]:
"compat-alloc-user-space is still a horrible hack and shouldn't be used
at all if possible."

The ATI fglrx driver used buggy code - and so had to be changed. A
temporary patch was available almost immediately (see Anders's post
[6]), and hopefully a better one will be included in the next driver
release. This was not some psuedo-religious attempt to smite evil binary
drivers, this was a genuine security issue.

Regardless of the merits of having GPL_ONLY kernel code at all (which is
a different discussion with very important people with good arguments on
both sides), this is what was necessary to fix this bug according to the
kernel devs.

Thanks for the clear explanation, it was needed and appreciated. Nobody had said here yet (or we missed it) that the security problem was precisely that function that the ati driver uses.

The remaining question is to document what users of ATI cards (all types) have to do to get a working driver.

- -- Cheers,
Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)

Version: GnuPG v2.0.12 (GNU/Linux)

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >