On Wed, 23 Aug 2006 17:23:13 +0200, tim Rowledge wrote:
> On 23-Aug-06, at 12:14 AM, Klaus D. Witzel wrote:
...
>> The short story is, to not have the key passed to the image (i.e.  
>> during startup) and to not generate the key within the image (i.e.  
>> between startup and shutdown and/or snapshot).
>>
>> The protection mechanism is to not allow to take a copy of the running  
>> executable (means: VM) and also to not swap the executable out of real  
>> (chip) memory, that means: the executable is never written back onto  
>> disk again. Buy a B5000 (or a modern successor) and its hardware and OS  
>> already does that for you ;-)
>
> The nearest hardware equivalent that I know of would be the latest ARM  
> designs; they have a software controlled chunk on on-cpu memory that is  
> cache-speed and never reflected on any if the package pins.

Yes, that's the modern equivalent of it. How did someone say it: "back to  
the future", the B5000 is from the 195x's ;-)

> Thus you could load the routine to generate the uuid into this memory,  
> execute entirely in there with no shadow of the intermediate results  
> ever being visible, and then store the result and and testing routine in  
> there. Of course, I would want to install crucial parts of the VM in  
> this memory space as well.

Sure, that's the right place.

> It is essentially a writable control store that can be used for data as  
> well. Nice idea.

/Klaus

> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Satisfaction Guaranteed: We'll send you another copy if it fails.
>
>
>
>