cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

edward_yang
Journeyman III

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

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!

0 Likes
16 Replies
edward_yang
Journeyman III

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

 

0 Likes

thanks edward for providing how you solved the problem.

As of now openSUSE 11.3 has not been tested by AMD and AMD do not guarantee the SDK functioning properly on this platform.

0 Likes

Originally posted by: himanshu.gautam thanks edward for providing how you solved the problem.

 

As of now openSUSE 11.3 has not been tested by AMD and AMD do not guarantee the SDK functioning properly on this platform.

 

But the same problem happens to opensuse 11.2, too.

Nevermind.... there's already the hotfix out.

BTW, you should also add opensuse 11.2 to the list of affected distributions.

0 Likes
HarryH
Journeyman III

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.

 

 

0 Likes

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

0 Likes

I found the hotfix for this issue:

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

Now to try it out.

0 Likes

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 /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 /lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.o CC /lib/modules/fglrx/build_mod/2.6.x/kcl_agp.o CC /lib/modules/fglrx/build_mod/2.6.x/kcl_debug.o CC /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

0 Likes

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.

0 Likes

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.

0 Likes

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.

0 Likes

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?

0 Likes

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

0 Likes

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

 

 

 

0 Likes

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.

0 Likes

I am only change this function within the installer source code.


What is being compiled is a wrapper around the binary blob that is the actual driver,

this is the interface between the AMD proprietary code and the Linux kernel. It is a

part of the ".ko" kernel module and not a part of the installer.

0 Likes

If AMD's driver (whether the installer or the binary) does not exploit this vulnerability, then it should be safe, right?

0 Likes