Re: How to develop a random number generation device

On Sat, 15 Sep 2007 04:52:54 +0100, Nobody <nobody@xxxxxxxxxxx> wrote:

On Fri, 14 Sep 2007 11:47:32 -0700, John Larkin 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*.

Sure it can. Not in Windows and not with C++, perhaps. An OS can
surely make it impossible to write safe code and a real OS is required
to make safe code possible.

That doesn't address the issue, which was whether the OS can prevent
buffer overruns.

I can't prevent them, but it could and should trap them and abort the
offending task, with no possibility of subsequent damage.

Under a decent OS, bad code should only hurt itself.

I don't think you understand what a buffer overrun is. FWIW, it isn't
related to process isolation (preventing one process from trashing another
process' memory). That's a non-issue with modern OSes and modern CPUs (for
x86, that means 80286 and later).

Well, Windows is not a modern OS, and x86 is not a modern processor.
Given decent hardware tools, an OS should abort a process that tries
to execute data.

There was a joke, in the DOS days, that a certain jpeg file contained
a virus. It was a joke because it was obviously impossible. A few
years later, Windows managed to make it happen.

And XP occasionally crashes when a user-level process screws up. Not
as often as '98 type systems, but it still happens. And Patch Tuesday
has become a ritual.


The reason why the OS cannot do anything about this is because it lacks
the detailed knowledge regarding which portions of memory are used for
what purpose. That information is normally discarded during compilation
(unless you compile with debug information). By the time you get to
running a binary executable, you're at a level of "code writes data",
with no details about which parts of memory belong to specific variables.

If the code segment was write protected and execute-only, and data
segments were not executable, and if there were separate data and
return-address stack pointers, the OS *would* know when a process does
something dangerous.

John

.

Relevant Pages

  • Re: How to develop a random number generation device
    ... Perhaps buffer overruns can't be prevented ... Compilers are constrained by the language. ... Windows is no worse than any other OS when it comes to buffer overruns. ... C was designed as a systems programming language, ...
    (sci.electronics.design)
  • Re: Of mice and men
    ... > With Windows there is a small finite number of configurations. ... The reason that it is relatively small is that Windows software cannot ... Buffer overruns on Windows have been exploited to load malicious code ... The security impact of loading malicious code is much more significant, ...
    (comp.lang.cobol)
  • Re: Of mice and men
    ... >> With Windows there is a small finite number of configurations. ... but I know how buffer overruns work. ... > With Linux it is likely that many different distros or versions are ... >> Security by obscurity is not a defense. ...
    (comp.lang.cobol)
  • Re: How to develop a random number generation device
    ... Many have said that Windows is useless. ... A C++ compiler could be created that inserted checking code in every ... existing Windows software, ... M$ broke that with VIsta and still didn't fix buffer overruns. ...
    (sci.electronics.design)
  • Re: [Lit.] Buffer overruns
    ... > the amd hardware and windows support is the inverse. ... > execute only support around for some time ... ... http://www.garlic.com/~lynn/2004q.html#82 [Lit.] Buffer overruns ...
    (sci.crypt)