In article <ca6rqj$2300$1@digitaldaemon.com>, Arcane Jill says...
>
>Question: is optimization done before or after the insertion of inline assembler? That is, is inline assembler "what you see is what you get", or does the optimizer munge it? I should mention that I don't actually mind what the answer is.
>
>If the answer turns out to be that the opimizer MAY modify even my inline assembler then I do have a workaround, so it doesn't matter. I just want to know.
>
>If the answer turns out to be that the optimizer WILL NOT modify inline assembler, then I must ask a follow-up question: Do we have any kind of guarantee that this will always be the case in the future? That is, does there exist a stability policy in this regard which future incarnations of the compiler must always respect?
>
>Arcane Jill

As a tangential comment:

I wonder if it would makes sense to allocate all security-sensitive data from a special pool, perhaps portions of a large malloced chunk, or a linked list of malloc'd chunks.  A call at the end of main() could clear this memory.  It could XOR the return value (of main) with several random array elements after it is cleared to try to prevent optimization.

As the code runs, each object would try to clear its own pieces, to further minimize lifetimes.  The security pool could also verify that the pool was all nulls, perhaps spitting out messages if the pool was not cleared (even in release mode).  This would also inhibit optimization.

A side benefit of this is that you could do all your mlock or don't-page-out precautions (however that is done) in one place.

Kevin

In article <ca8149$r84$1@digitaldaemon.com>, Kevin Bealer says...

>As a tangential comment:
>
>I wonder if it would makes sense to allocate all security-sensitive data from a special pool, perhaps portions of a large malloced chunk, or a linked list of malloc'd chunks.  A call at the end of main() could clear this memory.

It makes perfect sense, except for the fact that, in a server, main() never returns. The program just keeps running forever.


>It could
>XOR the return value (of main) with several random array elements after it is
>cleared to try to prevent optimization.

It's easy enough just to fill it with zeroes using inline assembler, since Walter says this will never be optimized away.


>As the code runs, each object would try to clear its own pieces, to further minimize lifetimes.

Yup. I just spent the last couple of weeks implementing exactly that. Now the only problem is, it doesn't work - BECAUSE - I have no way of knowing when an object is no longer visible (and hence eligible for wiping). Now, this wouldn't be a problem if operators new() and delete() were globally overloadable, but they're not. Unless I've got that wrong.

For example, I could recode Int to use just such a custom allocator. Then they could be used to do RSA calculations, etc. BUT - realistically, no-one is ever going to call delete() on an Int. That would seriously complicate using them. And the GC won't touch it, because it has a custom allocator.

Wait - just had an idea! <ping> I'll make that a separate post and see what Walter thinks.



>The security pool could also verify that the pool was all
>nulls, perhaps spitting out messages if the pool was not cleared (even in
>release mode).  This would also inhibit optimization.

I might do that in a Debug build - that's DbC - but not in a Release build. I mean, if assembler doesn't get optimized away, there's just no problem. It WILL happen.


>A side benefit of this is that you could do all your mlock or don't-page-out precautions (however that is done) in one place.

Yup. Just need that global new() and delete() now.

I like your thinking.
Jill

In article <ca836b$usn$1@digitaldaemon.com>, Arcane Jill says...
>
>Yup. I just spent the last couple of weeks implementing exactly that. Now the only problem is, it doesn't work - BECAUSE - I have no way of knowing when an object is no longer visible (and hence eligible for wiping). Now, this wouldn't be a problem if operators new() and delete() were globally overloadable, but they're not. Unless I've got that wrong.
>
>For example, I could recode Int to use just such a custom allocator. Then they could be used to do RSA calculations, etc. BUT - realistically, no-one is ever going to call delete() on an Int. That would seriously complicate using them. And the GC won't touch it, because it has a custom allocator.

You could ask that we be allowed to overload the dot operator to make implementing smart pointers a bit simpler, though aside from that one use the idea kind of horrifies me :)


Sean

In article <ca6vk6$28o6$1@digitaldaemon.com>, Norbert Nemec says...
>
[...]
>Therefore, I don't know why you are afraid of the optimizer touching your inline assembler code.

Maybe working on a self-integrity check? I can pre-calculate the CRC of a bounch of functions and check them at runtime.

Ciao