Storage under Trusty

In trusty/app/sample/storage-unittest/ there’s a trusted application
that can’t, I think, be built, because the storage.h header is
missing, and probably wouldn’t work anyway because the way the
corresponding Android application works is by talking to
com.android.trusty.storage.client.td, which I don’t think we have,
either.

Is there a way in Trusty of storing data, even tiny amounts of data,
in a way that survives through a reboot?

Edmund

hello edmund.grimley-evans,

you should check the readme file (i.e. atf_and_trusty_README.txt) for setting up environments.
please also refer to Topic 123207 for specify armhf (32-bit) toolchain could fix the building failures.
thanks

I don’t think any armhf code is involved, and I’m not observing any build failures. I’m asking generally about permanent storage under Trusty.

Thanks,

Edmund

hello edmund.grimley-evans,

you’re asking about the secure storage service,
it has two file systems by default, which stores two super-blocks on a device that has tamper detection; the rest of the data can be stored in a non-secure partition or file.
you might also refer to Secure storage service, check [Disk Layout] session for more details.
thanks

Would it be easy to incorporate the secure storage service from Google Source into Nvidia’s version of Trusty? Has anyone already done that?

Thanks,

Edmund

hello edmund.grimley-evans,

may I have more details about your previous comments, i.e. >>> to survive reboot for storing data
thanks

Suppose we want to store cryptographic keys inside Trusty on behalf of applications running outside Trusty. We don’t want an arbitrary limit on the number of keys, so instead of storing them inside Trusty we might store them outside Trusty but encrypted with a key that is derived from the fuses and kept safely inside Trusty. Problem solved? Not quite, because we might want to securely destroy a particular key. It’s not possible to destroy all copies of the encrypted key because it may have been copied all over the place outside Trusty. Unless Trusty has a way of permanently recording the fact that a particular key has been “destroyed” then an attacker can always supply a copy of the encrypted key to the trusted application and say “use this key”.

The secure storage service solves this problem, and does a lot more, by providing an encrypted and tamper-proof file system, with atomic transactions, and, if I’ve understood correctly how it works, it does this by having two superblocks inside Trusty while the rest of the data, in the form of a tree of blocks, is kept outside Trusty. This would be great if it runs on the Xavier, but it’s not clear to me whether it has been ported. It’s also not clear to me where those two superblocks would be stored on the Xavier. Is there a secure block device that I could myself access from a trusted application, if I did want to directly store a bounded number of keys, for example?

Thanks for any help with this

Edmund

hello edmund.grimley-evans,

either writing into a file to a storage or pre-flashed data. the former could be writing an encrypted file in a disk. the latter could be an encrypted partition on the emmc.
If it is similar to our TOS samples reading a file and encrypt the buffer and decrypt to demonstrate key usage, when reboot, it will be back to original file content.
thanks

Is the “secure storage service” included with NVIDIA DRIVE? If so, why is it not included with NVIDIA Jetson?

Is it possible to directly access the eMMC from a Trusted Application under Jetson?

Thanks,

Edmund

you may refer to Trusty documentation, and check Accessing MMIO Regions session for details.
thanks

you may refer to Trusty documentation, and check Accessing MMIO Regions session for details.

How do I discover what addresses to use for those MMIO regions in order to access the eMMC?

Thanks,

Edmund

please also refer to similar discussion thread, Topic 140353 for reference. thanks