OPENCORES.ORG

What's your agenda? Academic? Commercial? Ideological? It helps to set

----- Original Message ----- 
From: "RT" <mfoc73@d...>
To: "Discussion list about free open source IP cores" <cores@o...>
Sent: Wednesday, March 23, 2005 4:10 AM
Subject: Re: [oc] Hardware and OS integration and security

> What's your agenda? Academic? Commercial? Ideological? It helps to set
> some context.
>

The true context for my interests is technical.
I'm sorry for the background in the other areas but it is interesting/scarry
what
some see as potential futures where Open Source won't work in a TCPA
universe legislated
by at least the U.S. Government.

> 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.
>

>From what I read and seen in the classroom a processor instruction is
(hopefully) fetched into
cache awaiting execution so there are few cache misses. The processor
fetches instructions from
the caches, decodes the instruction and then executes them. The encryption
step fits into this three step
process as follows:

1. Fetch the instruction in its encrypted form.
2. Decrypt the instruction.
3. Decode the instruction.
4. Execute the instruction.

All I'm suggesting is that the decryption is a simple lookup table (LUT). As
an example a NOP instruction
is represented as 0x80 in a machine. The LUT would contain 0x80 in position
0xFE for example. The entire
operating system and all applications would have been previously translated
using the LUT, which is essentially a key. Now when the encrypted program
image is fetched into the processor the additional LUT lookup occurs
which subsititutes 0xFE from the encrypted image to 0x80. The processor
understands 0x80 is a NOP instruction. The LUT would an a lookup for every
processor instruction.

Therefore, if a program receives "data" from another program over the
network that is really a buffer overflow
attack, the return address the attacker thinks he or she is putting on the
stack must get decrypted. The
attacker must know the LUT contents in order to launch a successful attack
where the contents of the
buffer gets decrypted correctly in order to execute. An email containing a
virus written in the normal machine code of the processor would go through
the decryption in the processor when it attempts to execute. The decryption
of the normal machine code would result in jibberish. As an example if the
0x80 (NOP) code
was looked up in the LUT perhaps the value would be 0x4D? Eventually the
processor hits an exception for the program (virus) and the operating system
would terminate the process. Process termination is betten than
virus propagation.

> > 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.

The shadow stack would be available to the processor exclusively where push
and pop
instructions would do parallel operations on the shadow stack. The physical
RAM for the shadow stack
could not be accessed by anyone or the normal memory management as it would
be on a separate
bus. This approach would be a hardware assisted bounds checking for programs
written in C that don't do bounds checking. This gets to the heart of my
interests - what
can be moved to hardware or software to reach a better security environment.
Also, if stack smashing is
detected can the correct stack be rebuilt so the program can continue
processing? Preventing the
process from terminating is better than having to restart a process.

>
> > 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
>
>

Thank you very much for your feedback. I don't want to reinvent wheels or
have solutions in search of
problems.

> _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores