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
From: James A. Donald [EMAIL PROTECTED]
...
If the optimizer ever optimizes away a write to volatile
memory, device drivers will fail. Most device drivers are
written in C. If anyone ever produces a C compiler in which
volatile does not do what we want, not only are they out of
spec, but smoke
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
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
At 10:20 AM 11/8/2002 +, Vincent Penquerc'h wrote:
On Thu, Nov 07, 2002 at 07:36:41PM -0500, Patrick Chkoreff wrote:
Everybody probably also knows about the gnupg trick, where they define a
recursive routine called burn_stack:
[...]
Then there's the vararg technique discussed in Michael
At 02:22 PM 11/8/2002 +, Vincent Penquerc'h wrote:
On Fri, Nov 08, 2002 at 08:35:06AM -0500, Patrick Chkoreff wrote:
That's an interesting idea. You'd take the pointer returned by alloca and
pass it to memset. How could the optimizer possibly know that the pointer
With GCC, it's a
James A. Donald [EMAIL PROTECTED] writes:
If the optimizer ever optimizes away a write to volatile
memory, device drivers will fail. Most device drivers are
written in C. If anyone ever produces a C compiler in which
volatile does not do what we want, not only are they out of
spec, but smoke
On Fri, Nov 08, 2002 at 08:35:06AM -0500, Patrick Chkoreff wrote:
That's an interesting idea. You'd take the pointer returned by alloca and
pass it to memset. How could the optimizer possibly know that the pointer
With GCC, it's a builtin, so it will know.
I was thinking the only way to
On Thu, Nov 07, 2002 at 07:36:41PM -0500, Patrick Chkoreff wrote:
Everybody probably also knows about the gnupg trick, where they define a
recursive routine called burn_stack:
[...]
Then there's the vararg technique discussed in Michael Welschenbach's book
Cryptography in C and C++:
How
At 02:22 PM 11/8/2002 +, Vincent Penquerc'h wrote:
while (!is_all_memory_zero(ptr)) zero_memory(ptr);
Right, unfortunately the compiler might be insightful enough just to
optimize that whole thing to skip() -- Dijkstra's null statement.
Even Welschenbach calls ispurged immediately after
At 10:50 AM -0800 11/7/02, Matt Blaze wrote:
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
Peter Gutmann writes:
James A. Donald [EMAIL PROTECTED] writes:
If the optimizer ever optimizes away a write to volatile
memory, device drivers will fail. Most device drivers are
written in C. If anyone ever produces a C compiler in which
volatile does not do what we want, not only are they
Back in the early days of compiler benchmarks, one fancy compiler noticed
that the result of a lengthy calculation wasn't being used, and dutifully
removed the calculations. That calculation was, of course, the kernel of
the benchmark. The solution was to print the result.
Or you do
At 02:22 PM 11/8/2002 +, Vincent Penquerc'h wrote:
On Fri, Nov 08, 2002 at 08:35:06AM -0500, Patrick Chkoreff wrote:
That's an interesting idea. You'd take the pointer returned by alloca and
pass it to memset. How could the optimizer possibly know that the pointer
With GCC, it's a
At 10:20 AM 11/8/2002 +, Vincent Penquerc'h wrote:
On Thu, Nov 07, 2002 at 07:36:41PM -0500, Patrick Chkoreff wrote:
Everybody probably also knows about the gnupg trick, where they define a
recursive routine called burn_stack:
[...]
Then there's the vararg technique discussed in Michael
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
On Thu, Nov 07, 2002 at 07:36:41PM -0500, Patrick Chkoreff wrote:
Everybody probably also knows about the gnupg trick, where they define a
recursive routine called burn_stack:
[...]
Then there's the vararg technique discussed in Michael Welschenbach's book
Cryptography in C and C++:
How
At 02:22 PM 11/8/2002 +, Vincent Penquerc'h wrote:
while (!is_all_memory_zero(ptr)) zero_memory(ptr);
Right, unfortunately the compiler might be insightful enough just to
optimize that whole thing to skip() -- Dijkstra's null statement.
Even Welschenbach calls ispurged immediately after
at Thursday, November 07, 2002 6:13 PM, David Honig [EMAIL PROTECTED]
was seen to say:
Wouldn't a crypto coder be using paranoid-programming
skills, like *checking* that the memory is actually zeroed?
That is one of the workarounds yes - but of course a (theoretical)
clever compiler could
Kevin Elliott wrote:
The point is though, that according to C99 today
volatile int myflag;
myflag=0;
if (myflag!=0) { do stuff } ;
does _exactly_ what you want, per the spec. The only compilers that
don't work this way are by definition out of spec, so adding new
stuff isn't going to
David Honig wrote:
I was thinking more in terms of arrays
memset( arr, 0, sizeof(arr)) // zero
unsigned int v=1;
for (int i=0; i arr_size; i++) v += arr[i]; // check
if ( v0 v2 ) // test
sanity();
else
insanity();
But I suppose that if compilers can be arbitrarily 'clever'
(eg about
--
From: Dave Howe[SMTP:[EMAIL PROTECTED]]
Sent: Thursday, November 07, 2002 3:46 PM
To: Email List: Cypherpunks
Subject: Re: Did you *really* zeroize that key?
David Honig wrote:
I was thinking more in terms of arrays
memset( arr, 0, sizeof(arr
At 19:30 + on 11/7/02, David Howe wrote:
at Thursday, November 07, 2002 6:13 PM, David Honig [EMAIL PROTECTED]
was seen to say:
Wouldn't a crypto coder be using paranoid-programming
skills, like *checking* that the memory is actually zeroed?
That is one of the workarounds yes - but of
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
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
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
[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.
Peter.
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
Kevin Elliott wrote:
The point is though, that according to C99 today
volatile int myflag;
myflag=0;
if (myflag!=0) { do stuff } ;
does _exactly_ what you want, per the spec. The only compilers that
don't work this way are by definition out of spec, so adding new
stuff isn't going to
--
On 7 Nov 2002 at 16:36, Trei, Peter wrote:
The 'volatile' keyword seems to have poorly defined
behaviour.
Volatile memory typically both receives input from outside
the abstract machine, and generates output outside the abstract
machine. Indeed the expected reason to write to
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
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
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
On Wednesday November 6 2002 10:22, Trei, Peter wrote:
What it really needs is the addition of a #pragma
dont_remove_this_code_you_bastard in the compiler.
Until then, a lot of security code will be affected by this problem.
Somehow I don't think they'll quite call it this. But you've got to
36 matches
Mail list logo
