Firefly and PC GAMESS-related discussion club

Learn how to ask questions correctly

Jim Kress
jimkress_35@kressworks.com

Glad you got NVidia to finally admit their error and fix it.  Have you confirmed the fix works?

Jim

On Sun Jan 30 '11 10:10am, Alex Granovsky wrote
-----------------------------------------------
>Well, finally the updated drivers are here.

>From the Nvidia's web site:

>

Version: 260.19.36 Certified
Release Date: 2011.01.21
Operating System: Linux 64-bit
Language: English (U.S.)
File Size: 45.8 MB

Updated the NVIDIA kernel module to ensure that all system memory
allocated by it for use with GPUs or within user-space components 
of the NVIDIA driver stack is initialized to zero. A new NVIDIA 
kernel module option, InitializeSystemMemoryAllocations, allows 
administrators to revert to the previous behavior.

>Regards,
>Alex Granovsky

>On Tue Jan 11 '11 8:07am, Alex Granovsky wrote
>----------------------------------------------
>>Some more updates:
>
>
>>Last Friday to Monday, in a series of private emails Nvidia
>>finally confirmed that this is a serious security issue.
>>Nvidia is now working to provide solution to this problem.
>>However, it seems that Nvidia will not release any security
>>advisory on this bug, nor it likes the idea the information
>>on this bug to become publicly available.

>>Regards,
>>Alex Granovsky
>>
>>
>>
>>On Fri Jan 7 '11 11:10pm, Alex Granovsky wrote
>>----------------------------------------------
>>>The issue is very serious as CUDA functionality is built in into
>>>every (relatively recent) version of Nvidia graphics drivers for
>>>Windows, Linux and OSX. Moreover, to install CUDA toolkit (all that
>>>is needed to exploit this bug) one does not need any special
>>>privileges so everybody having access to system with Nvidia video
>>>drivers running can do this.

>>>After toolkit installation, one just need to write simple C program
>>>which calls cudaHostAlloc() to allocate sufficiently large piece of
>>>pinned memory, and then dump all non-zero content to HDD for later
>>>examination. One can do this on a timely fashion gathering more and
>>>more information.

>>>As an example, our simplest "proof of concept" program was able to
>>>catch large fragments of files (or even entire files) being written or
>>>read by other users - emails, documents, various system logs, inputs,
>>>outputs, etc... - virtually everything one can imagine to find in the
>>>OS file cache and in the released memory of other programs.

>>>It seems the bug was here from the first days of CUDA. It does not
>>>exist under Windows (my Microsoft's contacts pointed me out that
>>>Windows forcibly zeroes any memory exported to user space so most
>>>likely this is the reason why it is not here), and I have not checked
>>>OSX as of yet.

>>>However, every owner of Nvidia graphics card running Linux and Nvidia
>>>graphics drivers should now consider switching to Nouveau driver, or
>>>even to GPUs of other vendors (or maybe to Windows OS :) ).

>>>As to Nvidia's response, it was really strange - their point
>>>was that if application does not like its data to be visible by
>>>other programs/users via this security issue, it should explicitly
>>>clear data in memory before releasing it. This is really strange and
>>>absolutely wrong idea, moreover, the contents of OS file cache,
>>>unused physical memory etc... cannot be cleared from within user
>>>programs at all.

>>>More globally, this is a question of how trustworthy are all
>>>third-party proprietary drivers which are capable to expose
>>>memory into user space.

>>>Alex Granovsky

>>>On Thu Jan 6 '11 5:02pm, Alex Granovsky wrote
>>>---------------------------------------------
>>>>Dear All,

>>>>>P.S. Working on the Linux port of our MP4/CUDA code initially
>>>>>developed a year ago for Windows version, we unexpectedly found
>>>>>that (unlike Windowd CUDA implementation), cudaHostAlloc/cuMemHostAlloc
>>>>>CUDA API calls return non-initialized pinned memory.
>>>>>Depending on how exactly this pinned memory is allocated by CUDA
>>>>>runtime/CUDA driver, this may be the serious system-wide security
>>>>>hole potentially allowing one to examine regions of memory previously
>>>>>used by other programs and Linux kernel itself. We are now in contact
>>>>>with NVidia trying to clarify as much details on this problem as
>>>>>possible. Meanwhile, we'd recommend everybody to stop running CUDA
>>>>>drivers on any multiuser Linux system.

>>>>After some more tests, we can confirm this is indeed the
>>>>very serious security hole. E.g, we were able to examine contents
>>>>of pages evicted from Linux file cache using this hole.

>>>>

For reference purposes, here is the info on CUDA driver version: 

devdriver_3.2_linux_64_260.19.26.run

and Linux version:

OpenSuSE 11.3 x64, uname -a: 

Linux phen 2.6.34-12-desktop #1 SMP PREEMPT 2010-06-29 02:39:08 +0200 x86_64 x86_64 x86_64 GNU/Linux

>>>>Regards,
>>>>Alex Granovsky