More on in-memory zeroisation

[Leichter, Jerry]

| > If the function is defined as I suggested - as a static or inline -
| > you can, indeed, takes its address.  (In the case of an inline, this
| > forces the compiler to materialize a copy somewhere that it might
| > not otherwise have produced, but not to actually *use* that copy,
| > except when you take the address.)  You are allowed to invoke the
| > function using the address you just took.  However, what in that
| > tells you that the compiler - knowing exactly what code will be
| > invoked - can't elide the call?
| 
| Case of static function definition: the standard says that standard
| library headers *declare* functions, not *define* them.
Where does it say it *can't* define them?  How could a Standard-conforming
program tell the difference?  If no Standard-conforming program can
tell the difference between two implementations, it makes no difference
what you, as an omniscient external observer, might know - they are either
both compatible with the Standard, or neither is.

| Case of inline: I don't know if inline definition falls in the
| standard definition of declaration.
It makes not difference.

| Also, the standard refers to these identifiers as external
| linkage. This language *might* not creare a mandatory provision if
| there was a compelling reason to have static or inline implementation,
| but I doubt the very infrequent use of (memset)(?,0,?) instead of
| memset(?,0,?) is a significant optimization opportunity. The compiler
| writer risks a non-compliance assessment in making such strectched
| reading of the standard in the present instance, for no gain in any
| benchmark or production software speed measurement.
| 
| Obviously, a pointer to an external linkage scope function must adhere
| to the definition of pointer equality (==) operator.
What do you think "the definition of pointer equality" actually is?  Keep
in mind that you need to find the definition *in the Standard*.  The
*mathematical* definition is irrelevant.

| Maybe a purposedly stretched reading of the standard might let you
| make your point. I don't want to argue too theoretically. Peter and I
| just want to clear memory!
Look, I write practical programs all the time - mainly in C++ recently,
but the same principles apply.  My programs tend to be broadly portable
across different compilers and OS's.  I've been doing this for close to
30 years.  I stick to the published standards where possible, but there's
no way to avoid making assumptions that go beyond the standards in a few
cases:  Every standard I know of is incomplete, and no implementation I've
ever worked with is *really* 100% compliant.

It's one thing to point out a set of practical techniques for getting
certain kinds of things done.  It's another to make unsupportable arguments
that those practical techniques are guaranteed to work.  There's tons of
threaded code out there, for example.  Given the lack of any discussion of
threading in existing language standards, most of them skate on thin ice.
Some things are broadly agreed upon, and "quality of implementation"
requirements make it unlikely that a compiler will break them.  Other
things are widely believed by developers to have been agreed upon, but
have *not* really be agreed upon by providers.  Programs that rely on
these things - e.g., that C++ function-scope static initializers will be
run in a thread-safe way - will fail here and there, because in fact
compiler developers don't even try to support them.  Because of the ever-
growing importance of threaded programs, this situation is untenable, and
in fact the language groups are starting to grapple with how to incorporate
threads.

Security issues are a similar issue.  The fact is, secure programming
sometimes requires primitives that the standards simply don't provide.
Classic example:  For a long time, there was *no* safe way to use
sprintf(), since there was no a priori way of determining how long the
output string might be.  People had various hacks, but all of them could
be fooled, unless you pretty much re-implemented sprintf() yourself.
snprintf() fixed that.

There is, today, no way to guarantee that memset() will be run, within the
confines of the standard.  This is a relatively minor oversight - C has
seen such issues as important since volatile was introduced well before
the language was standardized.  I expect we'll see some help on this in
a future version.  In the meanwhile, it would be nice if compiler
developers would agree on some extra-Standard mechanisms.  The gcc hack
could be a first step - but it should be written down, not just something
a few insiders know about.  Standards are supposed to grow by standardi-
zing proven practice, not by innovation.

The problem with unsupportable assumptions that some hack or another
provides a solution is that they block *actual* solutions.  By all means
use them where necessary - but push for better approaches.

							-- Jerry

| Kind regards,
| 
| 
| -- 
| 
| - Thierry Moreau
| 
| CONNOTECH Experts-conseils inc.
| 9130 Place de Montgolfier
| Montreal, Qc
| Canada   H2M 2A1
| 
| Tel.: (514)385-5691
| Fax:  (514)385-5900
| 
| web site: http://www.connotech.com
| e-mail: thierry.moreau at connotech.com
| 
| 
| 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com