[ggchappell]

This article makes a good point, but I think the problem is even worse than he describes.

Computer programs of all kinds are being executed on top of increasingly complicated abstractions. E.g., once upon a time, memory was memory; today it is an abstraction. The proposed attribute seems workable if you compile and execute a C program in the "normal" way. But what if, say, you compile C into asm.js?

Saying, "So don't do that" doesn't cut it. In not too many years I might compile my OS and run the result on some cloud instance sitting on top of who-knows-what abstraction written in who-knows-what language. Then someone downloads a carefully constructed security-related program and runs it on that OS. And this proposed ironclad security attribute becomes meaningless.

So I'm thinking we need to do better. But I don't know how that might happen.

[danielweber]

You remind me why it's so hard to do secure deletion: there are a bunch of abstractions built on old assumptions that no one cares about secure deletion. If you forget your pointer to that memory, it can be reused, so it's effectively deleted, we're all good, right? Meanwhile, the file you "sync"ed to disk might be synced to a network drive or flash memory or a zillion cache layers.

I think we need, right at the base metal, a way of saying "this data needs to not be copied" and/or "if you do copy it you must remember all copy locations so we can sanitize them all." And then we require every abstraction on up to have a way of maintaining this, the same way all the abstractions are required to, say, let us read data.

Or I guess this is part of what HSMs are supposed to do -- do all your "secure" work in something that is very strictly controlled.

[Nursie]

And if I run my C program in an emulator that allows me to freeze it and dump memory I can do this stuff too...

The point is, if you want security you need to look at the whole system and in the situation you describe you can't guarantee it, no.

I'm not going to say "So don't do that", but I am going to say "If you're going to do things like that, please realise that the assumptions the system security was built on no longer hold true".

I think to do it better we just need to pay a bit more attention. And try not to let ourselves get into situations (cough heartbleed cough) where memory zeroing is actually an important feature. IE - by the time the attacker is able to read your process memory you're probably already screwed.

[eru]

You could try for an abstraction / language that provides deterministic execution.