Intel tri-gate finFETs

Then why does he keep looking for love in all the wrong places?

Come to think if it, yeah. With a "move(n,pattern)" routine, it'd _have_ to be recursive, or it'd be a billion lines long! ;-D

Heck, that'd be a case where static data would be to your advantage; keep track of the list of moves and use "unmove(n)" to back up!

(normally, they warn against static data with reentrant code.)

(Geez, I must have known all this a couple, three decades ago - I did write the damn thing once!)

Thanks! Rich

In embedded systems, I like to implement periodic interrupts (timing, display refresh, etc.) with a reentrant interrupt. It keeps track of which functions are still executing using /static/ variables.

Tim

Last time I used recursion, I made a Minesweeper solver. It's just a paint (fill) algorithm with specific decision rules per pixel, repeated until no more squares are uncovered.

I initially implemented the algorithm in QuickBasic, using recursion per se. Unfortunately, QB's stack frames are ridiculously large, and stack space rather small (i.e., In all cases, a lot of code was required the unwind the stack, if the

Meh, keep a global (or static) "okay" flag.

Tim

That paradigm sure failed with you and your small brain.

None of which would be the fault of the recursion code.

More like the 'questionable' coder.

If you know how to do it, it works when needed. If you do not know how to do it, you should never try without experienced assistance.

If John were to stop quickly, your nose would get all brown, RuntRat.

... handler?

I know what you mean, but technically, it's no longer reentrant. Darned handy, tho.

-- Les Cargill

There is no 'right place' for an ugly queen like him. :(

What you describe here can be done with the ring priviledge Model as used in OS/2 without having to physically isolate the OS running CPU. OS/2 only used 3 of the 4 rings on Intels CPU but was much better than 'Doze which used only user and omnipotent rings. Too much 'Doze code runs in omnipotent mode and there is insufficient parameter checking. (and that is a cultural failing in the software industry)

Lets see if we can agree some common ground here.

The core OS should be small robust and run in ring0 and it should be absolutely paranoid about what it is asked to do. The core device drivers that are essential and trusted to the highest level should run in ring1. Other device drivers needing I/O or other priviledges in Ring2. User code in Ring3 and has to beg permission to do anything. If it steps out of line the OS sits on it hard and tells the user why.

Big software tends to suffer lots of competing effects most of which make it very hard to develop bug free code. The only people who really come close to the ideal use formal methods to specify, verify and validate their work. You then get into the how well do you trust the toolchain problem. Some are actually pretty good and true 6-sigma. This level of software reliability costs serious money to implement and is reserved for safety and mission critical work.

But this doesn't get around the consumer PC problems. The games players complained that 'Doze didn't respond fast enough and Mickeysoft's solution in part was to promote far too much code into Ring3 where it can do maximum damage with total control of anything. And computer games and home entertainment is now a very big slice of the PC market.

Some places are better than others but in general I tend to agree.

That is rather a dismal view of current version control practice. I have known places that did have reasonable sourcecode and build control.

I have also seen hardware in the field that pretty much matches that description too - the drawings and circuit diagrams were too bulky to keep in storage so they were thrown out when they moved offices!

Been there done that. Management could not see the point of keeping our chunky old TI990 development system after we stopped shipping 99xx kit. They could not be persuaded that changes to the embedded firmware might be needed as connected CPUs got ever faster.

That should not be the case unless you are using FORTH or APL!

Speak for yourself.

Starting out with a specification of what it is supposed to do helps.

You really should take a look at Modula2/3 or Oberon. I think you would like it. XDS is a now free Russian developed compiler. It is rather sad that they have to give it away now. The compiler technology is very clever at detecting common coding errors at compile time.

It embodies many of the principles we both espouse wrt to security.

Unfortunately, C does pretty much the opposite and will compile almost anything your feed it but not necessarily do what you expect. Lint helps a bit but it is feeble compared to proper static analysis tools used with a strongly typed language.

Many programmers don't like that discipline though and you have a big problem when university computer science projects are small enough that a potentially good software engineer can hack them out of the solid without using any kind of good process. It doesn't scale well.

And MS do not include their profiling and static analysis tools in anything except the most expensive corporate development toolset. They should be in the educational version and the next generation trained how to use them to maximise reliability of code under development.

Unfortunately the world is a crazy place.

Best way. It is amusing to be able to put the scope probe into places that would be unsafe or inaccessible in reality too.

It is amazingly good for a free product.

Regards, Martin Brown

That's not going to discourage him!

You mean like you just did? I suppose this makes you a fucktard by your own definition. Fucktard.

Anyway, I had no desire to comment on the rest of your dribblings, dim-wit.

Your flames are about as entertaining as reading assembly instructions for an outdoor garden set translated from Mandarin; but it is rather amusing to watch you make a complete fool of yourself and then flounder about while you try to recover.

A dumb fucktard like you needs instructions for something so simple, monkey boy.

A master like me never knew they were included in the box, as I never needed them to start with. I do assume that the engineers placed one in the box for monkey fucktards like you though.

You can't squirm away either, since it is you that is so familiar with their inclusion and the content.

That isn't right. OS/2 uses ring 0 for kernel code and device drivers, ring 3 for user code, and only uses ring 2 for 16-bit code with I/O privilege (IOPL). You can't run 32-bit code in ring 2. The IOPL thing was a backdoor to allow user code to use the serial and parallel ports back in the '286 days, because otherwise all those ring transitions would bring the app to its knees. So effectively OS/2 used only two rings as well. (Somewhere I have a copy of "The Design of OS/2", which goes into all of that in some detail.)

(I once wrote 16-bit IOPL code for a DLL called by a 32-bit app, which I used to control a fancy particle detector via the parallel port. Microsoft C 6.0ax was the bee's knees at the time.)

Depends on what you mean by "out of line". Do you make the OS scrub RAM before allocating it? What about secure erase of disc sectors? Memory protection is the easy part.

Test-driven design is a big help. You just have to have the right unit tests.

There's a huge (human) administrative overhead involved in getting security right, unfortunately. Try just setting up SELinux in enforcing mode, for instance--it's a nightmare.

Cheers

Phil Hobbs

OS2 started fading before the black-hat boys got serious. By the time you load it with browsers and Adobe junk and Java and all the modern stuff, it would probably have vulnerabilities too.

I agree about parameter checking, but a buffer or stack overflow should crash the bad code it's in, but should be impossible to crash the OS.

Since multicore is the way of the future, why not make the OS CPU absolutely protected? The amount of on-chip hardware required would be trivial.

IF the OS is still alive and in control. The best way to protect an OS is to make it *physically* impossible for apps to crash it.

So run the game on its own processor.

I know of, and work with, gigabuck companies whose mission-critical software has spun out of control. People who publish weekly patch lists. Good software is the exception in today's world.

John

Yes. you are right. I recall doing some 16bit IOPL ring2 stuff for OS/2 IEEE488 drivers and we subcontracted out the 32bit ring0 DLL for fully memory mapped I/O. Back in the days when it looked like a winner.

We used Logitech Modula2 compilers at that time (the company who later went on to popularise the mouse). TerraDatentechnik still supports it. Later JPI aka TopSpeed (renamed SoftVelocity) and now Clarion (though you would work hard to find the Modula2 inner core).

It all depends how defensive you want to be. For my money memory handed to a requestor should be put in a state such that read before write will trap (eg for bad parity). A couple of minis did this once. You should have the option of bounds check everything paranoid libraries and code generation or go faster ones but if you want to catch common and hard to find runtime errors trapping read before write is good.

These days I have static analysis tools that can catch most of these common defects in code *without* running it by dataflow analysis. It finds a surprising number of latent faults when run on production code. Usually in rarely (ie so far never) traversed paths like error recovery.

I agree absolutely.

Life is a lot easier if you are assembling modular components with clear specifications that are known to already work correctly in their test harnesses and can be regression tested when changed.

And even with hardware that is absolutely secure you cannot do anything about the idiot user that when told on a big red warning screen "pressing this will destroy all your data and/or compromise your machine to hackers" presses it anyway. And they do :(

OK the hackers use clever social engineering tricks to get people to do it. But the Vista certified drivers strategy would be fine if all suppliers did Verisign their output, but once you have conditioned everyone to expect lots of unsigned drivers even from major players and click on "I trust this" it is easy for Trojans to slip through.

And then you have all those US military sites that McKinnon hacked where the engineering and superuser accounts and passwords were either default or trivial to guess. US government wants him extradited to lock up and throw away the key - they should be thanking him for pointing out forcibly what was wrong with their military computer security.

Regards, Martin Brown

The environment for viruses and trojans was pretty bad even then. There just wasn't any internet connectivity for them to flow around quickly.

OS/2's descendent lives on as eComStation with full browser and a fairly comprehensive FTP server built in. I have never used it but it was allegedly pretty good as a turnkey system for some businesses.

Rings can do that. As Phil has pointed out even OS/2 put drivers in ring0 so my memory was playing tricks. But with todays faster CPUs we probably could use the additional the hardware protection rings.

As soon as it has to communicate with the outside world it is no longer completely invulnerable. And it will end up being a bottleneck.

A Ring3 application cannot crash a Ring0 one. Any more than a crash inside a virtual machine sandbox can affect the main host OS.

I think you are overly pessimistic.

Regards, Martin Brown

Maybe the perfect is the enemy of the good-enough.

-- Les Cargill

Roughly half of all large-scale software projects are total failures. Imagine if Boeing planes, or bridges, or buildings were that bad.

Programming is the worst technological thing humans do. Failure rates like this wouldn't be tolerated anywhere else.

John