Palladium: hardware layering model (Re: Palladium: technical limits and implications)

[Adam Back]

some definitions:

hw layer -- SCP which I think provides crypto key store, crypto
 	    co-processor for sealing, remote attesation

ring 0 -- new layer which controls memory management unit and secured
code compartments

supervisor mode -- normal supervisor mode, which can now only read
user space, but not trusted agents running in code compartments

user mode -- legacy user level apps under complete control of
supervisor mode

and some ASCII art:

+---------------+------------+
| trusted-agent | user mode  |
|    space      | app space  |
|    (code      +------------+
| compartment)  | supervisor |
|               |    mode    |
+---------------+------------+
| ring-0  / Memory mgmt unit |
+----------------------------+
| hardware / SCP key manager |
+----------------------------+

each layer below can decide policy and information disclosure through
APIs to the layer above.  

The implications of which are:

- the SCP can implement sealing with data separation against ring-0
(ring-0 can't bypass sealing data separation)

- ring-0 can read all superviser, user, and trusted agent space, but

- ring-0 and MMU can compartmentalize trusted agents so they can't
tamper with each other, and

- ring-0 and MMU can exclude supervisor mode from trusted agent space
and ring-0 space; supervisor mode is itself just another
compartmentalized trusted-agent level space.  Therefore ring-0 can
restrict what supervisor mode (where the normal OS is located) can do.

whereas the normal protected CPU architecture is just:

+------------+
| user mode  |
| app space  |
+------------+
| supervisor |
|   mode     |
+------------+

- from these assumptions it appears an OS could be implemented so that
all OS calls pass through ring-0 APIs and mediation to get to
supervisor mode OS.  In this case the OS could observe system calls
the trusted agent makes, but not in general read, debug, modify
virtualize or modify trusted-agent code.  The non-virtualization
presumes encrypted trusted-agent code, which Peter said is not done,
so this can't be how it works.


I would be interested to hear what model takes for Palladium mapping
the interactions and restrictions between Trusted Agents, user space,
OS kernel, TOR to the hardware.  We need this kind of detail to reason
about limits of the Palladium and make distinctions between what is
possible with Palladium implementation choices vs what other types of
OSes could be built from the hardware features.


One idea I think would be interest is as follows:

- the TOR (which lives in ring-0) _could_ be used together with the OS
to force all trusted-agent in-flows and out-flows (network traffic) to
go through code under supervisor mode control.  

I don't think this is likely in the current design; but this change
would be an improvement: 

- it would at least allow user audit and control of in-flows and
out-flows;

- the user could block suspicious phone-home information out-flows,

- the user could read out-flows and demand un-encrypted documented
formats, or if encrypted, encrypted with keys the supervisor mode gets
copies of.

- similarly in-flow control is interesting, because with no in-flows a
trusted agent could be more liberally allowed to make out-flows (if it
has no input knowledge, and is in a code compartment, and the user
gave it no sensitive it doesn't know anything to leak.)

(Even with encrypted code, or public code which could not otherwise be
audited actively in the sense of debugging it's actual operation to
see what it does in practice in your machine given your data and
circumstances rather than looking at static code and third party
certifications to try to deduce that.  Not all apps may be unencrypted
(a TOR and SCP could clearly be built to support this feature).


So on anonymous comments about OS control:

> Obviously no application can reliably know anything if the OS is
> hostile.  Any application can be meddled with arbitrarily by the OS.

I'm not sure if anonymous is just generalising when he says the app
can't in any circumstances know anything if the OS is hostile, but I
think it could potentially know things if the OS is hostile.  As I
described with the control and layer I think the palladium hardware
uses.  It seems possible to build some of separations and exclude the
OS from certain types of application.  It depends what you include in
the OS; if the OS includes the TOR, then no.  But it was stated that
the TOR is somewhat independent from the OS.  You could mix and match
and use an MS Palladium TOR with linux potentially (though perhaps not
in practice, it would have to be designed to allow it).  It also
depends on how the OS, trusted agents and supervisor mode is mapped to
the hardware.

> What Palladium can do, though, is arrange that the app can't get at
> previously sealed data if the OS has meddled with it.  The sealing
> is done by hardware based on the app's hash.  So if the OS has changed
> the app per the above, it won't be able to get at old sealed data.

Peter seemed to claim these kinds of assurance.  Sealing doesn't
prevent application virtualization, it just prevents the sealed data
being shared between non-virtualized instances of the apps and
virtualized instances.

So I was wondering how Peter could simultaneously claim that
encryption was not used and that "SW can known that it is running on a
given platform."

> And of course remote attestation will not work either, if the app
> has been meddled with.

Remote attestation, which is not itself general -- just a remote
dongle thing -- if not tied to remote dongle controlled sealing which
is necessary for the main application function could be nopped out.

So in the general case it seems that remote attestation is also
effectively virtualizable, modifiable and debuggable by first nopping
out remote attestation checks.  (This is not strictly virtualizable as
the remote dongle call nopping modification makes it no longer the
same application, but as I said unless this is necessary for the
application it doesn't otherwise change it's behavior, so it's
effectively virtualizable).

Adam