Hi Zippy, I appreciate what you are trying to do and the problems with the currently available solutions. Unfortunately I do not see any solutions beyond those you have already identified. Whilst I would love to provide you with a workable solution, we do not have the resources to develop additional features on an old CAmkES version. Adrian On Thu 23-Nov-2017 9:04 PM, Zippy Maniac wrote:

We have a security requirement on our ARM based product using CAmkES 2.2.x to ensure all sensitive data declared in specific seL4SharedData regions are erased on detection of a power failure. We achieve this by overwriting the data with a known pattern that we read back from a separate component before declaring the device as secured. This is working fine. But we need to guarantee that the overwrite data is actually written to DDR and we aren't just using cached values. This means flushing the L1 and L2 data caches specific regions.

We could use seL4HardwareMMIO regions and declare our data in the memory map and use these regions as un-cached. Or use the _hardware_cached attribute and call the provided flush method when necessary. Our main issue with doing this, except the fiddle of mapping multiple different sized regions into the memory map, is we could potentially expose the physical locations of the sensitive data rather than having it wrapped in the virtual address space of a component.

Having a flush method on seL4SharedData would be the ideal solution.

We are not in a position to upgrade our CAmkES version on this product at the moment.

Any thoughts?

Zippy

_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel

On Thu, Nov 23, 2017 at 1:57 PM Zippy Maniac <zippymaniac@gmail.com> wrote:

We have a security requirement on our ARM based product using CAmkES 2.2.x to ensure all sensitive data declared in specific seL4SharedData regions are erased on detection of a power failure. We achieve this by overwriting the data with a known pattern that we read back from a separate component before declaring the device as secured. This is working fine. But we need to guarantee that the overwrite data is actually written to DDR and we aren't just using cached values. This means flushing the L1 and L2 data caches specific regions.

Power fail detection would start a time window for the clean and secure shutdown. Have you timed writing to your hardware? Have you double checked your processor for cache flush operation and timing. Sustaining power long enough might be important. Flushing cache for regions seems incorrect. Mapping regions to be uncashed yes but cache is all flushed or not. Review the cache design. Some drivers reserve a block of RAM to read or write to forcing cach flush. Device drivers and multi processing need to get this right. Atomic operations for multi processing (locks and counters) can be difficult on ARM depending on the core you use. The insight you will need will be in drivers and mutex code. -- Tinny keyboard.. Mobile ... I am