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
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 sm
> 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 some
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 ar
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
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 afte
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
"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, bu
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++":
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
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 Michae
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 built
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 su
--
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 vola
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 su
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 goin
> 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
> --
> 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 ar
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 ( v>0 && v<2 ) // test
> sanity();
> else
> insanity();
>
> But I suppose that if compilers can be arbitrarily 'cleve
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
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 rea
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
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
>[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.
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
26 matches
Mail list logo
