Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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.

    Comment


    • #17
      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 !

      Comment


      • #18
        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 .

        Comment


        • #19
          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?

          Comment


          • #20
            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?

            Comment


            • #21
              My script has this patch now included:

              http://launchpadlibrarian.net/561998...010-3081.patch

              Comment


              • #22
                Originally posted by Kano View Post
                My script has this patch now included:

                http://launchpadlibrarian.net/561998...010-3081.patch
                Thanks for the patch, it works here on gentoo, for other gentoo users, please see ebuild here.

                Comment

                Working...
                X