request: patch for catalyst (10.7) to get 2.6.36-rc* working

[kernelOfTruth]

My guess is you're missing CONFIG_COMPAT=y in your .config, which is selected automatically when enabling IA32_EMULATION (at least on an x86_64 system).

In 2.6.36-rc-4-git2 this will break again, because compat_alloc_user_space is renamed to arch_compat_alloc_user_space:
http://www.kernel.org/diff/diffview....-git2.bz2;z=15

I have it enabled:

# CONFIG_COMPAT_BRK is not set
CONFIG_BLOCK_COMPAT=y
# CONFIG_COMPAT_VDSO is not set
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_COMPAT_NETLINK_MESSAGES=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_I2C_COMPAT=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_QUOTACTL_COMPAT=y

so it's the latter

thanks !

[Spasswolf]

Actually, I was wrong with my assumption that compat_alloc_user_space is rennamed to arch_compat_alloc_user_space. compat_alloc_user_space get's some extra checking and calls the "new" arch_compat_alloc_user_space (which is the old compat_alloc_user_space)
http://www.kernel.org/diff/diffview....-git2.bz2;z=62
http://git.kernel.org/?p=linux/kerne...82d27a79a81ea6
The new compat_alloc_user_space is declared in linux/compat.h which should be included by kcl_ioctl.c.

[aidanlinz]

In 2.6.36-rc-4-git2 this will break again, because compat_alloc_user_space is renamed to arch_compat_alloc_user_space:
http://www.kernel.org/diff/diffview....-git2.bz2;z=15

Thanks for the warning, I've got the modules built in 2.6.36-rc4-git2 now.

--- fglrx/build_mod/kcl_ioctl.c    2010-09-01 10:05:31.000000000 -0400
+++ kcl_ioctl.c 2010-09-16 23:11:12.066336002 -0400
@@ -193,7 +193,7 @@
  */
 void* ATI_API_CALL KCL_IOCTL_AllocUserSpace32(long size)
 {
-    return compat_alloc_user_space(size);
+    return arch_compat_alloc_user_space(size);
 }
 
 #endif // __x86_64__

[Apfelkuchen]

Hi all,

I have had the same problem as descriped in the first post.
The patch later on worked for me an 2.6.36-rc3.

But now I have the following issu.
My system looks like this
- one installation on internel hdd - as working system
- and the same at an externel hdd (copied via cp -a) - as experimental system

The above things worked well on the external system and I could start X, so I wanted to get the same one the internal installation.

Build and install with dkms worked well but when starting X I get the following error
"fglrx incompatible kernel module detected"

(as mentioned both systems run the same kernel-image 2.6.36-rc3)

I found another forum where this issue is discriped but the final answer is missing and I can't get behind it.(http://www.linux-club.de/viewtopic.p...107085&start=0)

Would be great if anyone could give me a hint :-)

bye

[kernelOfTruth]

New compat_alloc_user_space() GPLness and fglrx
<--

@bridgman:

could you please tell the devs for the proprietary driver / fglrx to fix it that it won't leave a security-hole open in the kernel with versions newer than 2.6.36-rc4-git2+ ?

thanks !

[bridgman]

I don't think there is a good way to do that (at least nothing yet). The patch that caused problems wrapped the arch-specific compat_alloc_user_space calls with a new, common call which included a security fix (yay !), but that new call was then marked GPL-only so we can't use it from fglrx (boo !).

If the routine that "everyone thinks we should be using" has been marked GPL-only there may not be a better solution than what Evan implemented, which is continuing to use the arch_ call but implementing a similar security fix. A number of other options have been discussed but right now all of them seem worse.

[kernelOfTruth]

I don't think there is a good way to do that (at least nothing yet). The patch that caused problems wrapped the arch-specific compat_alloc_user_space calls with a new, common call which included a security fix (yay !), but that new call was then marked GPL-only so we can't use it from fglrx (boo !).

If the routine that "everyone thinks we should be using" has been marked GPL-only there may not be a better solution than what Evan implemented, which is continuing to use the arch_ call but implementing a similar security fix. A number of other options have been discussed but right now all of them seem worse.

you're right,

IMO it's pretty user-unfriendly to do this kind of stuff: this also effectively prevents using lock tracking:

[ ] Lock debugging: detect incorrect freeing of live locks
[ ] Lock debugging: prove locking correctness
[ ] Lock usage statistics

why is there no problem with nvidia and their binary blob ?

in the past when I had this enabled it nevertheless worked

do they mark parts of their driver GPL or some other kind of black magic ?

anyways: if that's the only (best of all) way(s) to do it - then leave it at that ...

Thanks !

[hdas]

Argh, looks like they did this to 2.6.35.5 too. Why do they do such stuff in stable kernels. It is stupid to keep up with these kind of changes for 3rd party software in general.

Anyway, thanks for all the help here .

[nanonyme]

Argh, looks like they did this to 2.6.35.5 too. Why do they do such stuff in stable kernels. It is stupid to keep up with these kind of changes for 3rd party software in general.

Because while apparently at least some developers accept the reality that binary drivers exist, most of them don't feel feel responsibility to keep the kernel API's from breaking things for out-of-tree stuff, let alone binary drivers?

[RemcoL]

I don't think there is a good way to do that (at least nothing yet). The patch that caused problems wrapped the arch-specific compat_alloc_user_space calls with a new, common call which included a security fix (yay !), but that new call was then marked GPL-only so we can't use it from fglrx (boo !).

If the routine that "everyone thinks we should be using" has been marked GPL-only there may not be a better solution than what Evan implemented, which is continuing to use the arch_ call but implementing a similar security fix. A number of other options have been discussed but right now all of them seem worse.

Since CVE-2010-3081 is a high impact vulnerability, it's now getting into pretty much every kernel, not just the experimental ones. With the difference between the arch and non-arch version being a non-working fglrx, what are the implications of changing it?

From your reply it looks like there is no way to get it working 'the right way' at the moment. With the fglrx release cycle of multiple months and the fact that *all* previous releases are also affected, will we really have to wait until next year for acceleration without this gaping security hole? Or is a security release of fglrx a real possibility?