... the fastest implementation is always the lean, event-loop (e.g. while/select loop)
version that never blocks.
This is because when a threaded implementation works properly on a single CPU, that's what it ends
up doing anyway -- code in each thread runs, until it does something that blocks that thread, and
another thread wakes up... If you split out those same code segments into a common event loop,
you get rid of the thread context-switch overhead. You can even break up long event-handlers
with "Idle events" -- you do part of the work, and send yourself an "idle event" to remind yourself
to do the next chunk when you don't have new work coming in. This is generally less overhead
than a thread time-slicing context switch.
If you then want to take advantage of multiple CPU's efficiently, you need to look at the
event handler code in the above implementation, and see if you have race conditions if
two branches are run in parallel. If not, you can just fork a couple of processes and/or
threads to tag-team the same event stream, and the code just cruises and uses more CPUs.
If there are race conditions between branches, you take those branches that need to share a resource, make a single separate thread/process for those handlers, and forward the required events to that thread/process so they get handled sequentially.
This style of code is often harder to design than a more obvious multiple-threads type
implementation, but it is faster (and often easier to maintain) when properly done.
In either case, the source of obscure bugs is race conditions that are overlooked.
Yeah, that's great, until the company goes out of business, or (for a really fun thought)
loses the encryption keys (due to fire, flood, terrorist bombing or BOFH...)
Now you're forever stuck with whatever their last release was, and you may not ever get new
software.
Yes! I was thinking about this the other week. We need new permissions sets for systems today, and browsers need to run as several components:
* Browser id/permission-set/whatever that can *only*
- fetch web content from the network
- put it in a web download spool area
- tell viewers, etc. about content via a tightly syntax-checked channel. * Image viewer id/permission-set/whatever that can *only*
- read your web download spool
- display media on the screen * File saver that will run as end user
- prompt user for where to save content
- virus filter, etc. before actually saving
This is archetecturaly how the really early web browsers worked -- separate applications displayed the inline images, etc. But in this case they would be running as different users or with different permission sets, so if they are taken control of via a code bug and malicious content, they can't do anything besides scribble on parts of the screen to which they are restricted...
While this discussion is getting hopelessly longwinded, this does bring the sort of point up that is
the problem. If the desktop is the security boundary, then does Microsoft do anything to make sure that, say,
administrative tasks (software installation, etc.) are partitioned into a separate desktop from large
applications that might have security issues? No! Quite the opposite -- they use Microsoft Explorer, quite possibly the most
security-bug-ridden mass of code known to mankind, to to do their system software updates, guaranteeing
that most users use it with administrator privleges on their system, and regularly. And do you know of any
home Windows systems that run more than one desktop, ever?
So I guess I needed to amend my initial point. It's not just that the underlying code base is robust, mature, and moderately
well designed from a security perspective. It's also that the people doing the overall system seem to understand how
the security model works, and don't do silly things that thwart it.
Well, it may have been some of the same developers who did some of VMS, but clearly
none of the VMS least-privelege security model made it into NT, nor did
the VMS "every bug reported becomes a mandatory test case for the next release"
regression testing model.
Even the best design can be implented sloppily, and Microsoft has made that
practice a part of their culture, IMHO.
This is why when the guys at wisc.edu did fuzz testing
of Windows/NT (and later Windows 2000), they noted [emphasis mine]:
We noted (as a result of our completely random input testing) that any application running on Windows platforms is vulnerable to random input streams generated by any other application running on the same system. This appears to be a flaw in the Win32 message interface.
Ah, so it's a combination of two old, stable code bases, Mach and BSD. The point still stands.
And I suppose I'm insane then, as I used Mt. Xinu Mach as my home system for years.
So thanks for your characterization.
And I'd have to see a reference to your claim of Mach system calls being "An order of magnitude slower".
I was at USENIX when the CMU folks were presenting Mach with a BSD emulation process (and an old MacOS
Multi-finder emulation, running Solaris and MacOS(5?) binaries on the same Motorolla 68k box...), and at
the time they said that using the BSD emulation through Mach was "almost as slow as BSD", as opposed to the
native Mach calls, which were faster, and they had benchmarks to prove it.
I think there are good technical reasons why MacOS/X is more secure than MSWindows.
(the fact that Sophos didn't bother to cite them nonwithstanding).
The fact of the matter is that more people are going to believe a simple quantified statement
than an abstract technical discussion; so Sophos is making the argument that will convince the
most people, rather than an argument that would convince, say, the more technical folks on Slashdot.
Oh, you want the technical reasons? Okay, here goes my list:
MacOS/X has a much more stable and mature core Operating System base (Mach).
Mach is MUCH older (circa 1985) than the windows NT core (circa 1993), and has been
changed less. For example NextStep, released in 1989, was based on Mach, and already
did much of what MacOS/X does.
Mach (the underlying OS) was designed with security in mind.
Note however, the Mach layer doesn't define security policy, it just gives you tools with which
to implement such policies. That said, if the current MacOS upper layers get the policies wrong,
flexible tools are there to fix it. Contrast that with Windows which has serious design flaws in its
interprocess communication mechanism.
The MacOS command-line code, so far, also seems to have a lower bug-density (similar to Linux) in fuzz testing than the MS code, although
GUI code is unfortunately sucky in both OS-es.
But coordination is key. A change must be made by England, Australia, India, South Africa, and America simultaneously for best effect.
After all, if we don't do that, then on one side of the Atlantic they'll spell it "color" and on the other side they'll spell it "colour", and some folks will spell it "grey" and others "gray", and...
<emily latella mode>
Ooooh... Never mind.
</emily latella mode>
(And while we're at it, how about agreeing on which of "suspenders" and "garters" means which,
whether on cars it's a "boot" or a "trunk", and whether it's a "bonnet" or a "hood" and...
)
The point is that your "tests", above *are* trial multiplications by 10000, 1000, etc., checking to see if the
product is too big.
The only thing you're doing shorthand is omitting zeros.
The fact that you don't understand that that's what you are doing in doing long division tells
me that you don't in fact know *why* it works, you just do it in a rote fashion.
I suspect most people in the USA who get minimum wage spend at least half their income on room and board.
Is it a good thing? No. But saying that a Chinese company is a 'sweatshop' for paying their workers
better than WalMart does in California (relative to local economic conditions) is not an accurate statement.
You said
Having an ever increasing portion of the world's people living in worse and worse conditions isn't a good thing.
I was pointing out that the people working in this factory are in better conditions than most of the rest of China. So how is that "worse and worse conditions"?
We should save our ire and righteous indignation for the companies who are making conditions worse and worse.
If we waste our energy and breath on companies who are actually doing pretty well, we just look like ranting, clueless people.
Okay, so according to undp.org's China data
(an independant report commissioned by the United Nations Development Programme (UNDP))
46% of Chinas population earns less then $2/day, and 16% earn less than $1/day.
So if you assume 4, 6-day work weeks per month, thats about 24 work days/month $2/day == $48/month.
So they're doing better than 46% of the population of China on total income.
50% of your pay on room and board is pretty reasonable.
And not having visitors can be a bonus if you're a young single gal worried
about her virtue (which I'm told actually happens in China;-))
I don't hear anything here about anyone being beaten, worked more than 50 hours/week, etc.
And given the slant here, they would have mentioned it if they had a whisper of it.
And compare this to old U.S. "mining towns" where between rent and the company store
for food you spent 90% of your income on room and board, it's really quite good.
The Morris Worm (the first internet Worm to infect a large portion of the Internet, back in '88) included a very short list (~500) of passwords to try to get root with. It also tried people's first names, last names, etc. (read all about it in spaf's analysis).
Obvious current candidates for obvious-password-cracking are things like MS-SQL, which allows you to send a whole request with
a single UDP packet (as demonstrated by the old SQL-Slammer worm in 2003...)
So yes, cracking poor password choices has lead to signifigant breakin and security woes through the years.
On the other hand, rules like "Include mixed case and special symbols" doesn't particularly solve the
problem. toggling the case of letters and appending digits on obvious words has been a feature of programs like "crack" for decades, and that's what those rules promote. When user Fred Jones makes his password "FredJonesFredJones123!" to pass the rules check,
it still isn't a terribly secure password. Or the user just writes down their password and PostitNotes it to the screen...
A much better approach would be one like one posted here to Slashdot a while back, Inkblot Passwords, where you show a user
a series of randomly generated images which are associated with their account, and they enter a two-word
phrase associated with each inkblot.
Yeah, those guys like McVey who blew up the Oklahoma City Federal building, he was... er...
And that Unabomber guy, he was clearly... uh...
Oh. Nevermind
</emily-latella-mode>
And how is that different from long division the way we learned it, exactly?
Lets say you're trying to devide 123 into 24723. If you're doing long division, you write:
_______ 123 / 24723
and then you guess where to put a number above the line. You put a 2 above the 7, and you write 24600 underneath -- what you've just done is guessed 200 and found that 24600 is too small, and that 300 (36900) would be too big.
Next having established that in long division the way we learned it you subtract out the 24600 part, and work on the rest. But that's just bookeeping to establish that we have a guess on the digits so far...
If you really want to read some code, print it with a good old fashioned chain printer on green bar paper
formatted with "pr" for page numbers, and get a set of colored highlighters to mark useful things.
For code you want to browse through, hack up a little perl script that gives you page number
references for each symbol and subroutine/function/method, and print that out on a separate
stack.
Go sit somewhere nice where you can relax, flip through your stack of green bar and sip your favorite caffiene, and life is good.
If instead of going for full-blown AJAX, you just do some simple dynamic html tricks,
like hiding/unhiding various sections of the page, you can in many cases get a very
responsive pages, without going back to the server so often. For example,
going back to the list of items from the specific item detail can be simply changing
the style to hidden and back on two different page elements. Ditto for browsing
hierarcies (folder/subfolder, etc.) -- you can make a static html list of
the fully unfolded hierarchy, and use dynamic html trics to unfold the parts
of the list the user is interested in seeing.
Of course, without more details on what you're trying to do, it's hard to be more specific.
But you can do a lot without storing cookies, running ActiveX bits, etc.
The real threat is someone with bad intent getting a job at Lucent and putting a backdoor in the telephone switch code, and another guy who is affiliated with him who
gets a job at Microsoft and puts a backdoor in Windows, and a third guy who got a job
at Sun hacking up Solaris, and another guy gets a job doing the software for gas pumps,
and another gets a job at Diebold, etc.
When they send out The Signal, every computer system with a modem gets it, (including the gas pumps, who use their phone line to check credit cards...) and they send to every system they can reach over the internet. So you get a multipoint flood of what's apparently a multi-platform worm/virus...
The bad guys can make phone calls to contact one another, (cause they phreaking 0wn the phone system) but no-one else can, and the power grid goes down (cause they got the controlling Solaris boxes), and every gas pump in the country stops working (or starts spewing gasoline all over the ground?) The ATM's start spewing money on the ground...
And of course to find out how they did it, you need to peruse the entirety of those
assorted operating systems to find a "bug" that's intentionally well hidden... How long
do you think it would take? Days? Weeks?
Until we start building software systems in a manner that assumes possible evil intent from our devlopers, and tests and reviews the living daylights out of them, we won't have a defense against this. Oh, and by the way, it will catch lots of basic garden variety (non-evil-intent) bugs, too.
...that your browser basically hangs several times a week if you go to secure sites, becuase the OCSP server is either down/not-reachable/overloaded. I don't know anyone
who has ever left it turned on more than a month.
I suspect this is why it is off by default in the release of the browsers -- it makes
browsing secure sites far too painful.
Slashdot Mirror
If you then want to take advantage of multiple CPU's efficiently, you need to look at the event handler code in the above implementation, and see if you have race conditions if two branches are run in parallel. If not, you can just fork a couple of processes and/or threads to tag-team the same event stream, and the code just cruises and uses more CPUs.
If there are race conditions between branches, you take those branches that need to share a resource, make a single separate thread/process for those handlers, and forward the required events to that thread/process so they get handled sequentially.
This style of code is often harder to design than a more obvious multiple-threads type implementation, but it is faster (and often easier to maintain) when properly done. In either case, the source of obscure bugs is race conditions that are overlooked.
Basically, at this point MS has to pay the money. If they win the appeal, they might get it back...
Yeah, that's great, until the company goes out of business, or (for a really fun thought) loses the encryption keys (due to fire, flood, terrorist bombing or BOFH...) Now you're forever stuck with whatever their last release was, and you may not ever get new software.
Yes! I was thinking about this the other week. We need new permissions sets for systems
today, and browsers need to run as several components:
* Browser id/permission-set/whatever that can *only*
- fetch web content from the network
- put it in a web download spool area
- tell viewers, etc. about content via a tightly syntax-checked channel.
* Image viewer id/permission-set/whatever that can *only*
- read your web download spool
- display media on the screen
* File saver that will run as end user
- prompt user for where to save content
- virus filter, etc. before actually saving
This is archetecturaly how the really early web browsers worked --
separate applications displayed the inline images, etc. But in this
case they would be running as different users or with different permission
sets, so if they are taken control of via a code bug and malicious content,
they can't do anything besides scribble on parts of the screen to which
they are restricted...
So I guess I needed to amend my initial point. It's not just that the underlying code base is robust, mature, and moderately well designed from a security perspective. It's also that the people doing the overall system seem to understand how the security model works, and don't do silly things that thwart it.
Even the best design can be implented sloppily, and Microsoft has made that practice a part of their culture, IMHO. This is why when the guys at wisc.edu did fuzz testing of Windows/NT (and later Windows 2000), they noted [emphasis mine]:
And I suppose I'm insane then, as I used Mt. Xinu Mach as my home system for years. So thanks for your characterization.
And I'd have to see a reference to your claim of Mach system calls being "An order of magnitude slower". I was at USENIX when the CMU folks were presenting Mach with a BSD emulation process (and an old MacOS Multi-finder emulation, running Solaris and MacOS(5?) binaries on the same Motorolla 68k box...), and at the time they said that using the BSD emulation through Mach was "almost as slow as BSD", as opposed to the native Mach calls, which were faster, and they had benchmarks to prove it.
The fact of the matter is that more people are going to believe a simple quantified statement than an abstract technical discussion; so Sophos is making the argument that will convince the most people, rather than an argument that would convince, say, the more technical folks on Slashdot.
Oh, you want the technical reasons? Okay, here goes my list:
After all, if we don't do that, then on one side of the Atlantic they'll spell it "color" and on the other side they'll spell it "colour", and some folks will spell it "grey" and others "gray", and...
<emily latella mode>
Ooooh... Never mind.
</emily latella mode>
(And while we're at it, how about agreeing on which of "suspenders" and "garters" means which, whether on cars it's a "boot" or a "trunk", and whether it's a "bonnet" or a "hood" and... )
- creating a dummy company
- giving Enron money to said dummy company
- taking money back into Enron from said dummy company
- reporting both of the above as revenue
- lather, rinse, repeat to the tune of a few billion.
That doesn't sound like fraud to you? It sure does to me...Can I prove it? Of course not -- but who cares.
Did the Feds prove it? You betcha.
The only thing you're doing shorthand is omitting zeros.
The fact that you don't understand that that's what you are doing in doing long division tells me that you don't in fact know *why* it works, you just do it in a rote fashion.
Is it a good thing? No. But saying that a Chinese company is a 'sweatshop' for paying their workers better than WalMart does in California (relative to local economic conditions) is not an accurate statement.
You said
I was pointing out that the people working in this factory are in better conditions than most of the rest of China. So how is that "worse and worse conditions"?We should save our ire and righteous indignation for the companies who are making conditions worse and worse. If we waste our energy and breath on companies who are actually doing pretty well, we just look like ranting, clueless people.
Actually, reviewing TFA, they do say the folks are working 15 hours/day. That is pretty steep. Sigh.
So if you assume 4, 6-day work weeks per month, thats about 24 work days/month $2/day == $48/month.
So they're doing better than 46% of the population of China on total income. 50% of your pay on room and board is pretty reasonable.
And not having visitors can be a bonus if you're a young single gal worried about her virtue (which I'm told actually happens in China ;-))
I don't hear anything here about anyone being beaten, worked more than 50 hours/week, etc. And given the slant here, they would have mentioned it if they had a whisper of it.
And compare this to old U.S. "mining towns" where between rent and the company store for food you spent 90% of your income on room and board, it's really quite good.
And then you get the Dvorak keyboard, and Ouch! you can't remember your password anymore :-)
Obvious current candidates for obvious-password-cracking are things like MS-SQL, which allows you to send a whole request with a single UDP packet (as demonstrated by the old SQL-Slammer worm in 2003...)
So yes, cracking poor password choices has lead to signifigant breakin and security woes through the years.
On the other hand, rules like "Include mixed case and special symbols" doesn't particularly solve the problem. toggling the case of letters and appending digits on obvious words has been a feature of programs like "crack" for decades, and that's what those rules promote. When user Fred Jones makes his password "FredJonesFredJones123!" to pass the rules check, it still isn't a terribly secure password. Or the user just writes down their password and PostitNotes it to the screen...
A much better approach would be one like one posted here to Slashdot a while back, Inkblot Passwords, where you show a user a series of randomly generated images which are associated with their account, and they enter a two-word phrase associated with each inkblot.
Yeah, those guys like McVey who blew up the Oklahoma City Federal building, he was... er...
And that Unabomber guy, he was clearly... uh...
Oh. Nevermind
</emily-latella-mode>
When I go to the grocery store, folks are giving away free samples of food all the time.
Movie companies show parts of their movies for free on TV all the time to get folks to come see them.
So Glickman's point doesn't hold water for me at all. Media companies have been giving stuff away to sell stuff forever...
And how is that different from long division the way we learned it, exactly?
Lets say you're trying to devide 123 into 24723. If you're doing
long division, you write:
_______
123 / 24723
and then you guess where to put a number above the line. You
put a 2 above the 7, and you write 24600 underneath -- what you've
just done is guessed 200 and found that 24600 is too small,
and that 300 (36900) would be too big.
Next having established that in long division the way we learned it
you subtract out the 24600 part, and work on the rest. But that's
just bookeeping to establish that we have a guess on the digits so
far...
If you really want to read some code, print it with a good old fashioned chain printer on green bar paper formatted with "pr" for page numbers, and get a set of colored highlighters to mark useful things.
For code you want to browse through, hack up a little perl script that gives you page number references for each symbol and subroutine/function/method, and print that out on a separate stack.
Go sit somewhere nice where you can relax, flip through your stack of green bar and sip your favorite caffiene, and life is good.
Of course, without more details on what you're trying to do, it's hard to be more specific. But you can do a lot without storing cookies, running ActiveX bits, etc.
Actually, the people who really do understood Unix, reimplemented it well.
The real threat is someone with bad intent getting a job at Lucent and putting a backdoor in the telephone switch code, and another guy who is affiliated with him who gets a job at Microsoft and puts a backdoor in Windows, and a third guy who got a job at Sun hacking up Solaris, and another guy gets a job doing the software for gas pumps, and another gets a job at Diebold, etc.
When they send out The Signal, every computer system with a modem gets it, (including the gas pumps, who use their phone line to check credit cards...) and they send to every system they can reach over the internet. So you get a multipoint flood of what's apparently a multi-platform worm/virus...
The bad guys can make phone calls to contact one another, (cause they phreaking 0wn the phone system) but no-one else can, and the power grid goes down (cause they got the controlling Solaris boxes), and every gas pump in the country stops working (or starts spewing gasoline all over the ground?) The ATM's start spewing money on the ground...
And of course to find out how they did it, you need to peruse the entirety of those assorted operating systems to find a "bug" that's intentionally well hidden... How long do you think it would take? Days? Weeks?
Until we start building software systems in a manner that assumes possible evil intent from our devlopers, and tests and reviews the living daylights out of them, we won't have a defense against this. Oh, and by the way, it will catch lots of basic garden variety (non-evil-intent) bugs, too.
Uh... Dollar sign ($)?
I suspect this is why it is off by default in the release of the browsers -- it makes browsing secure sites far too painful.