[Nottingham] Writing Linux Kernel Functions In CUDA With KGPU

[Sergiusz Pawlowicz]

On Sat, May 7, 2011 at 15:06, Martin <martin at ml1.co.uk> wrote:
> Rory,
>
> On 6 May 2011 22:25, Rory Holland <rory at linux.com> wrote:
>> I know Martin will be interested in this, and maybe some general interest too?
>>
>> ... KGPU is a
>> workaround to enable Linux kernel functionality written in CUDA.
>> Instead of figuring out GPU specs via reverse-engineering, it simply
>> uses a userspace helper to do CUDA-related work for kernelspace
>> requesters. ...
>>
>> Read more at Slashdot
>> http://hardware.slashdot.org/story/11/05/06/1940220/Writing-Linux-Kernel-Functions-In-CUDA-With-KGPU
>
> Rather interesting, but one commenter has already picked up on what
> would be one of my concerns:
>
> http://hardware.slashdot.org/comments.pl?sid=2132414&cid=36052010
>
> "Is it a good idea for the protected kernel to rely on unprotected
> code for critical functions such as filesystem operations? I know that
> user-space code cannot directly interfere with the kernel, but it also
> doesn't have to do anything the kernel requests of it. Unless the
> kernel is designed to treat such user-space code as altogether
> untrustworthy, it seems to me a bad idea for the kernel to rely on
> user-space code in this manner."
>
> Is GPGPU memory protected against surreptitious reading or
> modification by a trojan or whatever malware during KGPU filesystem or
> encryption operations...?

i do not get it, do you (eventually a comment author) do not believe
any userspace encryption can be secure? trojan can do everything with
all files visible in virtual file system, both encryptfs and the lower
filesystem (ext4, nfs, xfs, whatever) are registered in the kernel
vfs, so if we follow this bit, no protection exists.

if you are scared about trojans, there is selinux, which gives more
security, but it is not related only to any gpu accelerated
encryption, but to vfs.

i would love to hear any scenario which threats you, as i do not get it.

s.