8 posts • joined 17 Sep 2007
Stability for a time
I well remember running NT3.1 and NT3.5 as my DESKTOP OS (remember NT Workstation?) because I just couldn't deal with the garbage that was WFW/Win32s at the time - constant crashing and running out of "resources" caused by poor GDI heap management. You needed what was, at the time, considered just GOBS of RAM to get the job done. However, these OSs finally let me run my development environment for more than 24 hours straight :-). I stayed in the server OS world for my desktop through NT4, WIN2K, and WIN2K3 because WIN95/WIN98/WINXP were much less stable. Windows 7 finally delivered what I would consider to be equal stability to the server counterpart. However, as many have already mentioned, NT4 architecture put the graphics handling into ring 0, which was was a bad move. NT4/WIN2K definitely suffered more crashes because of this move. Anyway, here's one guy that's happy they loaded the desktop GUI into their "server" product. It made my work day much more productive.
Better writing please...
Well, I'm just piling on - everyone else sees it too, but I have to say it.
The problem isn't the doctors, although I agree completely with "It seems as of late doctors are changing way to often." I end up liking almost ALL of the actors on the series - some took a while to grow on me, but the acting is quite good.
The problem is the writing. The show was watchable for new seasons 1-2, but I would say the "good" episodes are less than 50% of the lot. Season 3? Keep "Blink", discard the rest.
I hope the break has given some people time to CREATE better stories. Enough with the rehash...
Can we standardize on an external bus, please?
This entire USB/Firewire/eSATA business has been a big waste of time, IMO.
What I would like to see is more of a hybrid use of the Ethernet port. Put it into true 'network' mode for talking on a net, but have the option to put it into a 'peripheral bus' mode.
I enjoyed the article - but I had the same double-take as Stu Reeves at the mention of an "Ethernet" cable.
All pretty much as expected - except for one
Anyone else surprised Toshiba is ranking so well? My experience has been that this brand is absolute rubbish both in quality of kit and with support.
Playground needs new toys
NASA is like kids who get bored with their toys and want to play with new ones.
The problem with the moon and mars toys is they are likely to cost billions to trillions of dollars.
And honestly, not too many other people get much enjoyment out of watching them play with the toys.
I am more in favor of projects like SpaceShipOne. If you people want to go play around in space, do it with your own $$$.
Solving how exactly the DNS poisioning is occurring is not the point.
As Robert Brockway and others pointed out, ...
Why are people putting their credentials into a form that their browser is surely warning has an invalid certificate (if the spoof site is emulating the SSL layer), or doesn't have the padlock (if the spoof site is not).
The fact that probably the MAJORITY of the population will freely enter their banking credentials into bogus forms ought to stop banks from setting up internet banking in the first place.
This is a legitimate discussion
I agree with Ken Hagan AND De Zeurkous.
I quibble with Ken Kagen only in the statement about "implementing critical security functions in userland", because we're talking about syscall wrappers here - this is kernelland.
Ken Kagen took everyone down the right road by pointing out that CALL atomically places arguments onto a privileged stack, which system calls read and act on, therefore seemingly no opportunity for exploit. (but this is actually not quite correct - see below)
What Robert Watson is mostly discussing is
a. what happens when you WEDGE something between the two?
b. Particularly when you can have concurrent processes with same access to memory where the args are?
When a userland process makes a syscall, the argument for strings/structures is merely a pointer to the string/structure in userland memory area.
While the pointer could not be changed due to the stack being used, the memory being pointed at, being in userland, certainly could.
If the execution sequence is
wrapper (reads string, accepts argument as valid, or changes them)
<WINDOW OF OPPORTUNITY>
WINDOW 1: wrapper interrupted (yields time, scheduler interrupts, etc), wrapper gets a CPU back
WINDOW 2: another process, concurrently running in another CPU, changes userland memory
SYSCALL (real one) triggered
WINDOW #1 is the single CPU window.
Window #2 is the multi CPU/multi core window.
In these windows, another process with userland access (a child process with same memory access) can replace the string/structure contents before the real SYSCALL gets triggered.
So, how do syscall wrapper application developers make sure there is no window of opportunity, particularly WINDOW #2?
As De Zeurkous says, "these problems arise from incorrect design".
The way this kind of issue is handled in a kernel is to use semaphore locking architecture, but this doesn't seem to work here, because you'd have to put semaphore structures around arbitrary userland memory used as arguments to function calls, and you'd have to trust userland apps to obey the semaphore.
A better approach would be to have the syscall wrapper application transfer data structures themselves (copy entire structures, not just pointers to structures), into protected syscall wrapper memory.
There may be even better approaches - but the point about an "incorrect design" being used to insert a wrapper between userland and kernel syscall does seem valid to me.