Firefly and PC GAMESS-related discussion club

Learn how to ask questions correctly

Alex Granovsky
gran@classic.chem.msu.su

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