Mailinglist Archive: opensuse (1839 mails)

< Previous Next >
Re: [opensuse] latest kernel update breaks ATI binary driver
  • From: Andrew Joakimsen <joakimsen@xxxxxxxxx>
  • Date: Mon, 27 Sep 2010 19:26:47 -0400
  • Message-id: <AANLkTinVZF4=KbupoUc9iGZt+GWAF0jZ9CcUsqj-MJW7@xxxxxxxxxxxxxx>
On Mon, Sep 27, 2010 at 06:19, Tejas Guruswamy <masterpatricko@xxxxxxxxx> 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).

- -- Cheers,
       Carlos E. R.
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()).
...
Summary:
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.

What's the big deal? As far as I can tell, both openSUSE and the kernel
devs have done a great job fixing a nasty bug very fast.
If you want to discuss the merits of having EXPORT-SYMBOL-GPL at all, go
to lkml, not here.

Regards,
Tejas

[1] http://seclists.org/fulldisclosure/2010/Sep/268
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c41d68a513c71e35a14f66d71782d27a79a81ea6
[3] http://lists.debian.org/debian-user/2010/09/msg01708.html
[4] http://lkml.org/lkml/2010/9/18/18
[5] http://lists.opensuse.org/opensuse/2010-09/msg01489.html
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx



So now malicious code marks itself as GPL and nothing is fixed,
because it has access to the same API as before.


--
Med Vennlig Hilsen,

A. Helge Joakimsen
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >