16 Replies Latest reply on Oct 8, 2010 8:47 PM by andrewpalumbo

    ATI fglrx Linux 64-bit installer not working with kernel update

    edward_yang

      I am using opensuse 11.3. The installer stop working after kernel patch CVE-2010-3081 is applied.

      Web search found this: http://www.pubbs.net/201009/debian/36654-cve-2010-3081-changes-internal-api.html

      Is this indeed the problem? If so, a quick update to ATI's fglrx driver is urgently needed. Thanks!

        • ATI fglrx Linux 64-bit installer not working with kernel update
          edward_yang

          After some searching on the Internet I was able to "fix" this problem.

          If anyone cares to know--

          • after the installation fails, go to /lib/modules/fglrx/build_mod
          • edit kcl_ioctl.c by changing (near end of the file)
            return compat_alloc_user_space(size);
             to
            return arch_compat_alloc_user_space(size);
          • run ./make.sh and follow the output
          • reboot

          Reference: http://marc.info/?l=linux-kernel&m=128477416507390&w=2

           

          • ATI fglrx Linux 64-bit installer not working with kernel update
            HarryH

            just using arch_compat_alloc_user_space instead of compat_alloc_user_space will

            re-introduce the security hole fixed in this patch, the url you refer to states it should

            be called safely. Meaning that before calling it you should check no

            application is exploiting this security hole (which is being exploited in the wild BTW).

            Refer to

            http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3081

            http://isc.sans.edu/diary.html?storyid=9574

            for info about the vulnerability.

             

            Just using arch_compat_alloc_user_space as you suggest is unsafe.

             

             

              • ATI fglrx Linux 64-bit installer not working with kernel update
                timattox

                I ran into this same problem on RHEL 5.5 with the latest kernel secruity patch (2.6.18-194.11.4.el5 x86_64).

                It's put my OpenCL development out of commision, since I am not allowed to run without the security patched kernel.  I've had to switch back to an NVIDIA card so I can continue to work!

                Searching the web, I found this comment by Felix Kuehling on 9/21/2010, and was wondering if there is an estimate on when we might get a new Catalyst driver that fixes this (the comment says "October")?

                https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/642518/comments/53

                    • ATI fglrx Linux 64-bit installer not working with kernel update
                      jarim

                       

                      Originally posted by: timattox I found the hotfix for this issue:

                       

                      http://support.amd.com/us/kbarticles/Pages/GPU83ATICatalystLinuxHotfix.aspx

                       

                      Now to try it out.

                       

                       

                      Didn't compile atleast in my CentOS 5.5 system (64bit). How about others?

                       

                      [Message] Kernel Module : Trying to install a precompiled kernel module. [Message] Kernel Module : Precompiled kernel module version mismatched. [Message] Kernel Module : Found kernel module build environment, generating kernel module now. AMD kernel module generator version 2.1 doing Makefile based build for kernel 2.6.x and higher rm -rf *.c *.h *.o *.ko *.GCC* .??* *.symvers make -C /lib/modules/2.6.18-194.11.4.el5/build SUBDIRS=/lib/modules/fglrx/build_mod/2.6.x modules make[1]: Entering directory `/usr/src/kernels/2.6.18-194.11.4.el5-x86_64' CC [M] /lib/modules/fglrx/build_mod/2.6.x/firegl_public.o /lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:2445: warning: ‘kcl_flush_tlb_one’ defined but not used CC [M] /lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.o CC [M] /lib/modules/fglrx/build_mod/2.6.x/kcl_agp.o CC [M] /lib/modules/fglrx/build_mod/2.6.x/kcl_debug.o CC [M] /lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.o /lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.c: In function ‘KCL_IOCTL_AllocUserSpace32’: /lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.c:196: error: implicit declaration of function ‘compat_alloc_user_space’ /lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.c:196: warning: initialization makes pointer from integer without a cast make[2]: *** [/lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.o] Error 1 make[1]: *** [_module_/lib/modules/fglrx/build_mod/2.6.x] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.18-194.11.4.el5-x86_64' make: *** [kmod_build] Error 2 build failed with return value 2 [Error] Kernel Module : Failed to compile kernel module - please consult readme. [Message] Kernel Module : update initramfs not required

                        • ATI fglrx Linux 64-bit installer not working with kernel update
                          himanshu.gautam

                          hi jarim,

                          The hotfix might work for CentOS but it is not guaranteed to work.CentOS is not officially supported by AMD.

                          See SDK release notes.

                            • ATI fglrx Linux 64-bit installer not working with kernel update
                              jarim

                               

                              Originally posted by: himanshu.gautam hi jarim,

                               

                              The hotfix might work for CentOS but it is not guaranteed to work.CentOS is not officially supported by AMD.

                               

                              See SDK release notes.

                               


                              Well CentOS 5.5 is basically same as RHEL 5.5 so *SHOULD* work but doesn't.

                                • ATI fglrx Linux 64-bit installer not working with kernel update
                                  timattox

                                  On my RHEL 5.5 system, my sysadmin had to fiddle with the hotfix for it to work.  As best I could tell looking over his shoulder, was that the hotfix didn't properly detect that it needed to apply the "workaround", and tried to compile without the workaround.  Once he forced the build script to apply the workaround, things worked.  It looked like the script was looking for a specific file in a path .../x86/... when it should have been looking in .../x86_64/..., at least on my machine.  I don't have root on this box, so I can't go look at it myself.

                                    • ATI fglrx Linux 64-bit installer not working with kernel update
                                      andrewpalumbo

                                       

                                      Originally posted by: timattox On my RHEL 5.5 system, my sysadmin had to fiddle with the hotfix for it to work.  As best I could tell looking over his shoulder, was that the hotfix didn't properly detect that it needed to apply the "workaround", and tried to compile without the workaround.  Once he forced the build script to apply the workaround, things worked.  It looked like the script was looking for a specific file in a path .../x86/... when it should have been looking in .../x86_64/..., at least on my machine.  I don't have root on this box, so I can't go look at it myself.

                                       

                                       

                                      I'm Having the same problem on a fresh install of RHEL5.5.  Getting the same errors as the regular install.  Has anyone figured out exactly how to force the workaround in the install script of the hotfix?

                                        • ATI fglrx Linux 64-bit installer not working with kernel update
                                          andrewpalumbo

                                           

                                          Originally posted by: andrewpalumbo
                                          Originally posted by: timattox On my RHEL 5.5 system, my sysadmin had to fiddle with the hotfix for it to work.  As best I could tell looking over his shoulder, was that the hotfix didn't properly detect that it needed to apply the "workaround", and tried to compile without the workaround.  Once he forced the build script to apply the workaround, things worked.  It looked like the script was looking for a specific file in a path .../x86/... when it should have been looking in .../x86_64/..., at least on my machine.  I don't have root on this box, so I can't go look at it myself.

                                           

                                           

                                           

                                           

                                           

                                           

                                          I'm Having the same problem on a fresh install of RHEL5.5.  Getting the same errors as the regular install.  Has anyone figured out exactly how to force the workaround in the install script of the hotfix?

                                           

                                            
                                             After the hotfix failed to build the fglrx module I saw the following:

                                          <See Code Below>

                                          so this seems to be where the build is failing- actually just failing to see the updated kernel.  so it goes ahead and tries to build without the update.

                                          Right now looking at this makefile, i'm not sure there's any reason to even define that path correctly since its just checking to see if the its working with the updated kernel fixed for CVE-2010-3081, and passing it as a flag when compiling.  So it seems that you could just modify the makefile and force this flag.  (arch_compat_alloc_user_space vs. compat_alloc_user_space)

                                          sloppy but I'll probaly give it a shot in the morning and see if that's all it is.

                                           

                                          # cat -n /lib/modules/fglrx/build_mod/make.sh | more 393 # ============================================================== 394 # resolve if we are building for a kernel with a fix for CVE-2010-3081 395 # On kernels with the fix, use arch_compat_alloc_user_space instead 396 # of compat_alloc_user_space since the latter is GPL-only 397 398 COMPAT_ALLOC_USER_SPACE=compat_alloc_user_space 399 400 src_file=$linuxincludes/../arch/x86/include/asm/compat.h 401 if [ ! -e $src_file ]; 402 then 403 echo "Warning:" >> $logfile 404 echo "kernel includes at $linuxincludes not found or incomplete" >> $logfile 405 echo "file: $src_file" >> $logfile 406 echo "" >> $logfile 407 else 408 if [ `cat $src_file | grep -c arch_compat_alloc_user_space` -gt 0 ] 409 then 410 COMPAT_ALLOC_USER_SPACE=arch_compat_alloc_user_space 411 fi 412 echo "file $src_file says: COMPAT_ALLOC_USER_SPACE=$COMPAT_ALLOC_USER_SPACE" >> $logfile 413 fi 414 <....> 450 make CC=${CC} \ 451 LIBIP_PREFIX=$(echo "$LIBIP_PREFIX" | sed -e 's|^\([^/]\)|../\1|') \ 452 MODFLAGS="-DMODULE -DATI -DFGL -DPAGE_ATTR_FIX=$PAGE_ATTR_FIX -DCOMPAT_ALLOC_USER_SPACE=$COMPAT_ALLOC_USER_SPACE $def_smp $def_modversions" \ 453 KVER=${uname_r} \ 454 PAGE_ATTR_FIX=$PAGE_ATTR_FIX \ 455 > tlog 2>&1 456 457 res=$? <....> /lib/modules/fglrx/build_mod/make.sh.log shows a warning: Warning: kernel includes at /lib/modules/2.6.18-194.17.1.el5/build/include not found or incomplete file: /lib/modules/2.6.18-194.17.1.el5/build/include/../arch/x86/include/asm/compat.h when it's grepping compat.h for arch_compat_alloc_user_space in the incorrect directory: /lib/modules/2.6.18-194.17.1.el5/build/include/../arch/x86/include/asm/ on my (updated) RHEL 5.5 installation compat.h is in /lib/modules/2.6.18-194.17.1.el5/build/include/asm-x86_64/compat.h /lib/modules/2.6.18-194.17.1.el5/build/include/asm/compat.h

                                            • ATI fglrx Linux 64-bit installer not working with kernel update
                                              andrewpalumbo

                                              i can verify that this workaround will force the hotfix :

                                              To force hotfix in RHEL 5.5 (and likely CentOS 5.5) add line 418 below to .../fglrx/build_mod/make.sh:

                                                 $ cat -n /lib/modules/fglrx/build_mod/make.sh |less

                                                 415  # ===================================

                                                 416  # force arch_compat_alloc_user_space flag
                                                 417 
                                                 418  COMPAT_ALLOC_USER_SPACE=arch_compat_alloc_user_space
                                                 419 

                                              then make from

                                                    # /lib/modules/fglrx/build_mod/make.sh

                                              you'll still get the warning  in make.sh.log about a missing file

                                              make install from:

                                                    # /lib/modules/fglrx/make_install.sh

                                               

                                               

                                               

                              • ATI fglrx Linux 64-bit installer not working with kernel update
                                edward_yang

                                 

                                Originally posted by: HarryH just using arch_compat_alloc_user_space instead of compat_alloc_user_space will

                                 

                                re-introduce the security hole fixed in this patch, the url you refer to states it should

                                 

                                be called safely. Meaning that before calling it you should check no

                                 

                                application is exploiting this security hole (which is being exploited in the wild BTW).



                                 

                                I am only change this function within the installer source code. Since this function is only called at the time the installer is executed, it should be safe as long as the installer doesn't exploit it, right?

                                But now that hotfix is out, it's probably the easier/better way.