Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

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

  1. #11
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    607

    Default

    Quote Originally Posted by Spasswolf View Post
    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:

    Quote Originally Posted by cat /usr/src/linux/.config | grep COMPAT
    # 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 !

  2. #12
    Join Date
    Aug 2010
    Posts
    4

    Default

    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.

  3. #13
    Join Date
    Sep 2010
    Posts
    1

    Default

    Quote Originally Posted by Spasswolf View Post
    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.
    Code:
    --- 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__

  4. #14
    Join Date
    Sep 2010
    Posts
    2

    Default

    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

  5. #15
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    607

    Default

    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 !

  6. #16
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    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.

  7. #17
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    607

    Default

    Quote Originally Posted by bridgman View Post
    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 !

  8. #18
    Join Date
    Jul 2007
    Posts
    176

    Default

    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 .

  9. #19
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,567

    Default

    Quote Originally Posted by hdas View Post
    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?

  10. #20
    Join Date
    Nov 2009
    Location
    The Netherlands
    Posts
    23

    Default

    Quote Originally Posted by bridgman View Post
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •