[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    [cap-talk] "Designing and implementing malicious hardware" (related
From:       "Baldur Johannsson" <zarutian+cap-talk () gmail ! com>
Date:       2008-04-19 0:52:47
Message-ID: 8c276afd0804181752s5d9c0e0eq77bd3a6bf35b0957 () mail ! gmail ! com
[Download RAW message or body]

H'lo cap-talk.

Interesting paper found at
http://www.usenix.org/event/leet08/tech/full_papers/king/

Specially the memory access mechanism taking so few gates to implement.

http://en.wikipedia.org/wiki/Secure_multi-party_computation might help
defending against both the MMU protection disabling mechanism and the
shadow mode. But that sacrifices both speed and the ability to run
unhalting programs.
Unhalting programs are what the halting problem in Computer Science is about.
Halting programs cannot contain indefinite loops and self-modifying code.
I am not sure about if self-appending quine like programs could be
used to regain
unhaltability and its benefits again.

This ties nicely into the discussion on  Lambda the Ultimate
http://lambda-the-ultimate.org/node/2773 which Mark Miller pointed out
here on cap-talk in an earlier post..
Specially the argument that only deployed computer systems can in
whole satisfy elementary security properties.
 If you cant trust the hardware to follow the functionality
specification and software instruction then how can you run an solid
system on top and trust that?

(and todays operating systems are too leaky of ambient authority to be
considered solid in that sense)

I predict that in the future (or indeed now) hardware firewalls would
be in use to prevent the the privilege escalation magic value (which
the memory access subversion circuit listens for) to reach the
processor of the machine containing confidential data.
But that is no protection from the sneaker-net way of usb-sticks.
So an different architecture of using an one processor (or processor
core) for kernel mode code and another for user mode code. (The one
used for user mode has no control of the MMU, only the kernel mode.
And to prevent any memory access subversion circuit in the one used by
the kernel an copy circuitry could be used for inter Ring Level
transfers.)

Thoughts? Comments? Need for clarification?

Without wax.
-Baldur
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]