How to develop a random number generation device

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

To be a little more pedantic, no library is part of "Linux", which is the kernel.

No, I quite definitely meant ABI. That's what determines whether a given binary will run on a particular system; the API determines whether you can compile your own binary from source.

Changes don't have to be major; a single missing or renamed symbol is enough to cause a binary to fail to run. Changing a function to a macro will do it; with C++, changing the type of a function parameter will do it (due to mangling to deal with overloading).

Yes, but I was talking about the ABI.

That was essentially what I meant by:

and:

With Linux, it would be feasible to change low-level details such as calling conventions or the executable format in order to facilitate new security mechanisms. OSes where proprietary software dominates don't have the same freedom.

Adding members will result in binary incompatibility if the executable is responsible for allocation (e.g. if the structure is a local or global variable which is filled in by a library function). A library which is expecting an "enlarged" structure will overrun the earlier, smaller version.

Even if the library performs allocation, you can only add to the end of the structure. This is a problem for object-oriented libraries (e.g. GUI toolkits), where it's common to implement subclasses by appending fields to the parent structure (both GTK+ and Xt work this way), as you can't add fields to any class which has a subclass without breaking binary compatibility.

I suppose you have accounted for youself, so who are the other two? May be, Larkin and... who? Could it be the "weenie leftist" ?

VLV

True statement. However the statistics is preserved through the linear operations. That allows for the simple analysis and exploitation.

A nonlinear operation between the two sequences such as hash, LUT, etc. would be much better if the secure random numbers are required.

How much of that seeming randomness is really random? There is a lot of correlation to the power supply, etc. That quasi randomness can actually produce more of the known plaintext vectors to aid the attacker.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

I program engineering apps in PowerBasic, and embedded stuff in absolute assembly. Both are fast, primitive, and bug-free. I write good programs because I use simple tools, and because I hate to program.

John

Heavens, no! But at least I have enough common sense to know that I'm _not_ competent in C++, unlike the MICRO$~1 crew! ;-)

However, I believe I could hold my own in vanilla C. ;-)

Cheers! Rich

With a hardware MMU, and software that can catch the exception, yes.

Cheers! Rich

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.

John

Actually, with the *nix permissions system, that's pretty much how it works anyway. The user can only write to subdirectories where he has write permission, which saves disk files; as far as allocating memory, it seems like you'd need either a hardware memory manager, or check every freaking instruction - hey, maybe that's why they need 3 GHz processors to add 2 + 2 these days! ;-)

Cheers! Rich

Of course it does.

If the pseudo-random generator is long enough, "simple" doesn't mean anyone will get it done this week.

Yes it is better but the XOR is still a long way from "very dangerous".

Quite a lot because it mostly is due to noise in the components.

If you do a bad design of the oscillator or the power supply perhaps.

Remember my comment about the "hit and miss" regulator. I added that because they do not make a reapeated pattern.

Huh?

That still doesn't address the question of how you decide that a write operation has overrun its buffer; the details of where one buffer starts and another ends are unknown to the OS.

You might be able to catch specific cases (e.g. overwriting a return address), if you're willing to take a massive performance hit (i.e. a context switch on all writes to the stack). Even then, that isn't the only type of buffer overrun which can be exploited.

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).

A buffer overrun is where a process trashes its own memory. The memory which is written is supposed to be written by that process, but the wrong part of the program writes the wrong data to it (e.g. writing a portion of a string to memory which is supposed to hold an integer or pointer).

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.

Please explain how "An OS can surely make it impossible to write safe code and a real OS is required to make safe code possible" addresses the question of whether the OS can prevent buffer overruns.

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.

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

You're an idiot.

You're an idiot.

You're an idiot.

No, he's right. It is not hard to make data segments non-executable, and even windows can do it to some extent (blocking execution on the stack segment). And he's also right that windows is not a modern OS - from the day DOS 1.0 came out to the day Vista arrived, the MS OS's have never been "modern" in terms of how they are designed and implemented. They have had plenty of modern features, and the age of a particular feature or idea is no indication of quality, of course.

No, he's right - I remember such hoax viruses (from early windows days rather than DOS days - IIRC jpg did not exist so early), and Windows did have a vulnerability allowing malware to spread by jpgs:

I also remember hoaxes about emails that would infect you just by reading them - and then MS managed to turn that into reality too (especially for those poor sods that used Outlook and had MS Office installed).

No, that sounds like a pretty good summary. There's no doubt that the NT line of windows is far more solid than the DOS line, but it is far from solid enough. I have a W2K machine that stops dead when Opera is showing certain web pages - there may be a bug in Opera, but it is windows' fault that it stops the whole machine.

You seem to be confusing "Windows" and an "OS".

No, he is right. The Harvard architecture may be an exception because "trying execute data" may be meaningless in that sort of processor.

Again what he said is true. The "DOS days" includes the early versions of Windows. One version of the joke had a JPEG file that really did have (what was claimed to be) a virus in it thanks to someones electron microscope.

So you didn't put in the patches LOL!