phc-discussions - Re: [PHC] Defensive use of GPUs (Was: A review per day

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 3 Sep 2014 10:09:22 -0700
From: Andy Lutomirski <luto@...capital.net>
To: discussions <discussions@...sword-hashing.net>
Subject: Re: [PHC] Defensive use of GPUs (Was: A review per day - Parallel)

On Wed, Sep 3, 2014 at 9:58 AM, Rich Felker <dalias@...c.org> wrote:
> On Wed, Sep 03, 2014 at 09:21:53AM -0400, Bill Cox wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I am going to personally give Parallel a qualified "A" grade, and
>> suggest to the judges that Parallel make it to the next round.
>>
>> Do we have any graphics experts here who could chime in?
>>
>> The competition has no other entry designed to make use of graphics
>> accelerators for defensive purposes.  Even our cell phones have
>> graphics hardware now days.  It seems crazy not to use these resources
>> for defensive purposes.  I would hate to see our only entry in this
>> category get dropped from the competition.
>
> Forgive me for being a non-expert in the application of GPUs for
> non-graphics (or even graphics) purposes, but how do you reconcile
> your "it seems crazy..." with my view that "it seems crazy" for code
> that's performing authentication (on behalf of unauthenticated users)
> to have access to the GPU, which often requires elevated or full
> hardware access privileges on the OS side, and may also expose full
> read/write memory access via the GPU? My (naive; I haven't followed it
> closely) impression is that this kind of hardware has repeatedly been
> found to have security flaws to the point where "it seems crazy" to
> use it for much of anything where you don't have full control over the
> code and data being sent to it.
>
> Obviously there are various levels of privsep up to and including
> putting GPUs on separate boards/busses that have no access to the host
> memory and that are fully reset between runs, but what's actually
> practical for defenders? Are there viable setups already that would
> mitigate the risks to a reasonable level? Or am I just over-estimating
> the risks? I think these questions need to be answered (if they
> haven't already) before defensive use of GPUs is considered viable.
>

In theory, things like XenGT and whatever Amazon is using for GPU
virtualization ought to be reasonably secure.  Admittedly, this isn't
widely available yet, but it might be in the near future.

Also, using the GPU for things like full disk encryption seems
entirely safe, at least from the point of view of memory corruption
attacks involving the GPU.

--Andy