|
Message
From: RT<mfoc73@d...>
Date: Wed Mar 23 10:10:43 CET 2005
Subject: [oc] Hardware and OS integration and security
What's your agenda? Academic? Commercial? Ideological? It helps to set
some context.
Try comp.arch for your technical points but, after a couple of minutes,
my reaction is:
Charlton Heston wrote:
> The technology components are as follows:
>
> 1. Encrypted instruction sets - What is the overhead of translating
> instructions via a lookup table
This is already done commercially for translating one instruction set to
another on the fly. Nazomi (?), at least, claims a "patent" on JVM
implementation this way. The immediate overhead is more silicon and,
possibly, an extra pipeline stage, with all the complications that brings.
> in the cache prior to execution of the instruction? If a processor
> had this capability every buffer overflow
> would get translated into garbage and not execute.
How does it protect against buffer overflows? The overflow must contain
valid instructions or it would be of no use to the attacker.
> The system owner
> could translate software
> based on the lookup table in the install process using tools that
> come with the operating system
> that executes in this environement. Disk space is cheap so a user
> could even use several
> encrypted versions of their favorite OS. Since no one knows the
> translation lookup table no viruses
> could execute on the computer. This would end the code and patch
> cycle. By the way this idea was patented
> in the 1970s but not for virus protection. Obviously, the computer
> owner must not install any viruses
> to protect her/his computer but other computers will not let it in
> the door or allow it to propagate
> across the network by using this approach.
I can't see that this gives you any protection. You have to get your
software from somebody else, unencrypted. You then encrypt it yourself
on your machine. The attacker simply sends you unencrypted software,
like everybody else, and you encrypt it for yourself. It doesn't even
address HTML and JVM-type attacks.
> 2. A shadow stack could be built into the processor. Comparing the
> shadow stack to the final stack
> using the shadow stack on procedure return could determine if the
> stack was over run. The stack would be activated when RAM is
> installed in a special slot on the motherboard to prevent hacking some
> system
> parameter to turn it off. I haven't fould this idea in any papers on the
> Internet so far...
So how do you update the shadow stack? Why would the shadow stack be any
different from the 'real' stack? Your own trusted software can't tell
that there are 2 stacks any more than the attacker can.
> 3. Multiple instruction set processors. Java virtual machines provide
> extra security by doing careful
> bounds checking on arrays, etc... Perhaps a processor could be built
> to use multiple instruction sets
> where additional checking can be done faster.
>
> 4. Better processor virtualization. The i386 uses a register to contain
> the physical address of the page tables
> while other processor designs allow virtual addresses to be used
> thus allowing the processor to virtualize itself.
> This allows for the building of better "sandboxes" to test software.
Virtualisation is a major research area; you should be able to find any
number of papers on this. My local uni has a security research unit and
will let outsiders into seminars if they ask nicely; try yours.
Richard
|
 |
Browse
