Re: How to develop a random number generation device

On Tue, 11 Sep 2007 19:16:34 -0700, MooseFET wrote:

Nothing the OS does can prevent machine code from overrunning a buffer.

Absolute nonsense. Perhaps buffer overruns can't be prevented using
C++, but they *can* be prevented.

Not by the *OS*.

[Using the traditional definition (the kernel, i.e. the part that the
process can't bypass), not Microsoft's definition (the OS plus a bunch of
user-level applications which are bundled in order to kill the market for
competing applications).]

A C++ compiler could be created that inserted checking code in every
operation that may overrun. Every buffer would have to have its
length recorded somewhere.

The language can prevent overruns; the OS just sees machine code.

The OS can let your program single step and check what every
instruction does.

The OS doesn't know where one "buffer" ends and the next one begins; it's
all just memory. And single-stepping programs would be out of the question
from an efficiency perspective.

The OS can always leave a dead page after every malloc() block so you
get a segment fault on stepping off the end.

That prevents overflowing malloc()ed buffers, but it doesn't work for
those on the stack ("auto" local variables) or in the data segment (global
or "static" local variables).

Historically, stack overflows have caused the most problems, due to the
ability to overwrite the function's return address.

Also, malloc() is part of the library, not the OS (kernel). Requesting
individual blocks directly from the kernel would cause a substantial
performance hit (not as bad as single-stepping, but still too high to be
practical).

Even if you consider malloc() (and C++'s "new", etc) to be part of the OS,
it's not uncommon for programs to use custom allocators (C++ allows
"operator new()" to be overriden for this specific purpose).

As I said:

Nothing the OS does can prevent machine code from overrunning a buffer.

There are lots of things which can be done to prevent overruns (and other
things which can be done to prevent overruns from being exploitable), but
most of them need to be done at a higher level than the OS.


.

Relevant Pages

  • Re: Thorny Serial Comms "UART: Overrun" error Windows CE 5.0
    ... If it does not uses PDC or DMA, this could explain the overruns ... > I don't know if it is the serial driver or the UART. ... >> Do you know if it's the UART's FIFO buffer or the Serial Driver's ... and if you are not handshaking should solve this. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [Lit.] Buffer overruns
    ... > Why stop with disabling ABC if cycles are so expensive? ... > How do I know that the program truly has no buffer overruns? ... >> If it modded the source code, ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... But I'm not advocating perfect security. ... > I agree that buffer overruns are unreasonable. ... > cause - sloppy programming practices. ...
    (sci.crypt)
  • Re: New Microsoft Bug Problems Blamed On Globalization
    ... No matter how much buffer you allocate it can always be overrun by an attacker. ... question is how you handle overruns. ... ]> Writing Global Software." ...
    (comp.security.misc)
  • Re: Merging relayfs?
    ... > kernel to implement speculative tracing, ... relayfs was prepared for low latency on move data outside kernel space, ... getting data from probes do not require organize all them in regular ... Only in all cases where buffer must be neccessarly moved outside kernel ...
    (Linux-Kernel)