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
1) This topic must be taken seriously. A standard technique
for attacking a system is to request a bunch of memory or
disk space, leave it uninitialized, and see what you've got.
2) As regards the volatile keyword, I agree with Perry.
The two punchlines are:
if, for example, gcc did not honor
TGi has NEVER been all that interested in DOS attacks because a number
of people argued that all you need to do is turn on a spark gap
transmitter. While this is true, I think it is harder (one can argue
how much) to get a spark gap transmitter and use it correctly than a
laptop, NIC card, and
[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
John S. Denker [EMAIL PROTECTED] writes:
1) This topic must be taken seriously. A standard technique
for attacking a system is to request a bunch of memory or
disk space, leave it uninitialized, and see what you've got.
I find that this thread doesn't discuss the threat model behind
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
