Re: How to develop a random number generation device

Nobody wrote:
On Wed, 12 Sep 2007 13:42:56 +0000, No Spam wrote:

Nothing the OS does can prevent machine code from overrunning a buffer.
That's not true. Many operating systens are by design, immune to buffer over-runs modifying unrelated code.

The issue isn't about modifying code, related or otherwise. It's about
either injecting new code or executing existing code with
attacker-supplied data.

This isn't about protecting one process from another, but about protecting
a process from itself. Most of the existing mechanisms for mitigating
buffer overruns are implemented in either the compiler or libraries. The
only OS-level mechanisms (things that work on any executable, however it
was built) involve making it harder to exploit an overrun (e.g.
randomising memory locations) rather than actually preventing the overrun.

Given that:

a) this would make Windows totally incompatible with most existing
software, and
Did you mean to write "nothing the *Windows* OS does can prevent machine code from overrunning a buffer?

No, the issues apply to any OS. But binary compatibility is much more
important for Windows (and Mac) than for Linux.

If you try to run a 5-year old Linux binary on a current distribution,
you'll probably find that a lot of the interfaces on which it depends have
either disappeared or have changed in an incompatible manner. Lack of a
stable ABI is a simple fact of life on Linux.


Binary compatibility for the user-level API is extremely important for Linux, and the API is very stable - new API's and system calls are added, but existing ones are seldom changed or removed, and never without very good reason. Most five year old Linux binaries will run fine on the same architecture as they were build for (assuming you have the right libraries) - the only API calls that have changed are very seldom used.

I think you are confusing the issue with the device driver binary API, as used by device drivers internal to the kernel. There the API is very explicitly flexible, and may be changed whenever it is convenient (the *source* level API compatibility is high - no one wants to have to make extra source level changes without reason. But if all that's needed is a recompile, that's okay).
.

Relevant Pages

  • Re: How to develop a random number generation device
    ... buffer over-runs modifying unrelated code. ... buffer overruns are implemented in either the compiler or libraries. ... randomising memory locations) rather than actually preventing the overrun. ... If you try to run a 5-year old Linux binary on a current distribution, ...
    (sci.electronics.design)
  • Re: If it works, this might be interesting
    ... Software is written to the Linux API. ... more than many scheme VMs or other functional languages. ... For a compiler or other command-line tool, ...
    (alt.lang.asm)
  • Re: Digital-tv card drivers and API discussion
    ... Designing completely new api takes some time and I ... > driver development experience, I have a couple of questions for you. ... > 2) As linux kernel is GPL-licensed, I cannot just port the linux driver ... I'm able to watch DVB programs converted from MPEG TS substreams to MPEG ...
    (freebsd-arch)
  • Re: [PATCH 6/6] sched: disabled rt-bandwidth by default
    ... standards and previous Linux behaviour by default for something that it is ... monopolization" is OK to me - it still keeps runaway CPU loops (which ... RT tasks have always been debuggable by using a simple watchdog thread. ... us breaking our API to cater for their idiocity. ...
    (Linux-Kernel)
  • Re: [Alsa-devel] Re: [PATCH 2.6.13.1 1/1] CS5535 AUDIO ALSA driver
    ... I thought of creating an API for coherent SG-buffers, ... The question is whether mmap of non-coherent buffer may ...
    (Linux-Kernel)