No crypto here, just C language lawyering.
On Thu, 07 Nov 2002, Don Davis wrote:
At 3:07 PM +1300 11/7/02, Peter Gutmann wrote:
[Moderator's note: FYI: no pragma is needed.
This is what C's volatile keyword is for.
No it isn't. This was done to death on vuln-dev,
see the list
[cc's pruned]
static void
burn_stack (int bytes)
{
char buf[64];
memset (buf, 0, sizeof buf);
bytes -= sizeof buf;
if (bytes 0)
burn_stack (bytes);
}
This may also not quite do what you think:
1) burn_stack() may reasonably be made tail-recursive by a
I remember this issue from days when I wrote modem drivers.
I had a fight with a compiler vendor over the interpretation
of volatile.
They agreed with me that volatile meant that all *writes*
to the memory had to happen as directed; but had taken the
approach that *reads* of volatile memory
At 8:36 AM -0800 11/8/02, bear wrote:
I remember this issue from days when I wrote modem drivers.
I had a fight with a compiler vendor over the interpretation
of volatile.
They agreed with me that volatile meant that all *writes*
to the memory had to happen as directed; but had taken the
approach
On Thu, 7 Nov 2002, Don Davis wrote:
* standards-compliant compilers normally distinguish
between conformant source programs and noncon-
formant source programs. for example, a noncon-
formant program might be one that uses a deprecated
feature. with nonconformant
At 8:40 PM -0800 11/7/02, Peter Gutmann wrote:
It's worth reading the full thread on vuln-dev, which starts at
http://online.securityfocus.com/archive/82/297827/2002-10-29/2002-11-04/0.
This discusses lots of fool-the-compiler tricks, along with rebuttals
on why they could fail.
In that
Probably moving out of the domain of the crypto list.
volatile char *foo;
volatile, like const, is a storage-class modifier. As written, it
means a pointer to memory that is volatile; this means, in particular,
that you can't optimize away dereferences. If you wrote
char *
In message [EMAIL PROTECTED], Peter Gutmann writes
:
[Moderator's note: FYI: no pragma is needed. This is what C's volatile
keyword is for.
No it isn't. This was done to death on vuln-dev, see the list archives for
the discussion.
[Moderator's note: I'd be curious to hear a summary -- it
At 03:55 PM 11/7/02 +0100, Steven M. Bellovin wrote:
Regardless of whether one uses volatile or a pragma, the basic point
remains: cryptographic application writers have to be aware of what a
clever compiler can do, so that they know to take countermeasures.
Wouldn't a crypto coder be using
At 3:07 PM +1300 11/7/02, Peter Gutmann wrote:
[Moderator's note: FYI: no pragma is needed.
This is what C's volatile keyword is for.
No it isn't. This was done to death on vuln-dev,
see the list archives for the discussion.
[Moderator's note: I'd be curious to hear a summary --
it
From: Trei, Peter [EMAIL PROTECTED]
[Moderator's note: FYI: no pragma is needed. This is what C's
volatile keyword is for. Unfortunately, not everyone writing in C
knows the language. --Perry]
Thanks for the reminder about volatile. It is an ancient and valuable
feature of C and I suppose
From: Trei, Peter [EMAIL PROTECTED]
[Moderator's note: FYI: no pragma is needed. This is what C's
volatile keyword is for. Unfortunately, not everyone writing in C
knows the language. --Perry]
Thanks for the reminder about volatile. It is an ancient and valuable
feature of C and I suppose
David Honig [EMAIL PROTECTED] writes:
Wouldn't a crypto coder be using paranoid-programming skills, like
*checking* that the memory is actually zeroed? (Ie, read it back..)
I suppose that caching could still deceive you though?
You can't, in general, assume the compiler won't optimise this away
[Moderator's note: FYI: no pragma is needed. This is what C's
volatile keyword is for. Unfortunately, not everyone writing in C
knows the language. --Perry]
From RISKS:
http://catless.ncl.ac.uk/Risks/22.35.html#subj6
Those of us who write code need to be reminded of this
now and then.
Peter
Someone wrote to me:
According to KR 2nd Ed. p. 211, compilers may ignore
volatile; volatile objects have no implementation-
independent semantics.
KR is not the C standard. Quoting the C99 standard, section 6.7.3.6:
An object that has volatile-qualified type may be modified in
If I use
volatile char *foo;
is the pointer volatile or is the memory it points to volatile? What
does the standard say? Obviously, I want to memory to be treated as
volatile...
M.
-
The
[Moderator's note: FYI: no pragma is needed. This is what C's volatile
keyword is for.
No it isn't. This was done to death on vuln-dev, see the list archives for
the discussion.
[Moderator's note: I'd be curious to hear a summary -- it appears to
work fine on the compilers I've tested.
17 matches
Mail list logo
