Bill Frantz wrote:
> There is a common example of this corner case where the memory is
> paged. The page containing the key is swapped out, then it is read
> back in and the key is overwritten, and then the page is deallocated.
> Many OSs will not zero the disk copy of the key.
Given the nature of
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 discus
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 nonconfo
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
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
[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-recurs
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
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
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
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
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
> 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 c
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 usin
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 summ
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 * volat
>[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. -
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 Cryptography
At 11:58 -0500 on 11/6/02, Perry E. Metzger wrote:
Someone wrote to me:
According to K&R 2nd Ed. p. 211, compilers may ignore
"volatile"; volatile objects have no implementation-
independent semantics.
K&R is not the C standard. Quoting the C99 standard, section 6.7.3.6:
An object th
Someone wrote to me:
> According to K&R 2nd Ed. p. 211, compilers may ignore
> "volatile"; volatile objects have no implementation-
> independent semantics.
K&R 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
[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.
Pete
20 matches
Mail list logo
