[Cryptography] NVIDIA Dynamic Code Optimization (DCO)

Henry Baker hbaker1 at pipeline.com
Sat May 23 13:46:51 EDT 2015


At 07:30 PM 5/22/2015, Tom Mitchell wrote:
>On Thu, May 21, 2015 at 9:09 AM, Henry Baker <hbaker1 at pipeline.com> wrote:
>FYI -- "DCO": Yet more lovely places for malware to hide.  The executing code is "translated" into a microcode buffer, but who gets to be in charge of said translation?
>.....
>What, me worry?
>
>If this is a worry it pays to look hard at JIT in your favorite interpreted
>language. JustInTime compilation is how Java, JavaScript, Dalvik,
>and many more modern interpreted languages run fast.
>There are also tricks where a JavaScript program can contain native
>binary code which is difficult to scan and debug.
>Yes there be dragons there....
>
>Hardware sandboxes with tall walls please.

In a well-ordered universe, there aren't untrusted turtles all the way down;
i.e., there should be a way for _user_ code to turn the d*mn DCO/JIT off.
Unfortunately, there isn't any way to enforce this, or even to check on it.
(The big lie technique.)

For a DCO system to even begin to be trusted, there has to be some mechanism
to inspect the DCO/JIT compiler, and audit its code.  It should be possible
for _userland_ programs to randomly trap & inspect (& "measure"?) the
compiled code buffer.

Otherwise, we have now institutionalized the "split TLB" hack, which enables
malware instructions to hide in an instruction cache while the virus scanner
sees a benign picture in the data cache.

https://www.wired.com/2015/02/crypto-trick-makes-software-nearly-impossible-reverse-engineer/



More information about the cryptography mailing list