And why, perchance, does it remain unsolved without actual investigation?
There is an issue of timeslice granularity -- each thread will only get a timeslice occasionally when there are many threads. So, you'll need to crank up HZ a bit and/or service multiple clients per thread.
The main thing, though, is that if you consider that the threads share their VM (that is, their program code and static data), you could probably do 10000 clients without too much heartache. The "COW" space (the amount on data that's private due to "copy on write") is the bounding factor.
Now, 10000 clients with 100% dynamic content? Ha. Too many dirty pages.
10000 clients with largely static content? Sure -- just sendfile it all.:-)
This is Linux. In Linux, the difference between a thread and a process is more-or-less whether the VM space is shared or copy-on-write. That's pretty much it as I understand it.
Starting 100000 processes, therefore, seems like it
should be doable, so long as there aren't so many "dirty" pages in the forked executables that the system thrashes itself to death handling the COW pages. This is where having a 64-bit system and a lot of RAM would help you. (You need the 64-bit system to address the RAM sanely. The whole "highmem" kludge on x86 is just that, a kludge.)
We had timed addition tests something like once every week or two in 2nd grade. The "advanced" kids got to do timed multiplication tests by the end of the year. These were simple 1-digit by 1-digit multiplications, and at that age, they were hard.
I remember it clearly, because I went to different schools for 1st, 2nd and 3rd grades. In 3rd grade, we actually started to learn simple division. They introduced long division and fractions in 4th grade. I remember working problems on the board in Mrs. Nunn's room.
(Yes, I remember my 2nd, 3rd, and 4th grade teachers' names--Mrs. Nietske, Mrs. Thomson/Mrs. Campbell, and Mrs. Nunn, respectively. I don't really remember my kindergarten or 1st grade years real well. I do remember seeing all the Carter vs. Reagan campaign paraphenalia when I was in kindergarten though.)
Careening suddenly back ontopic: To keep your kid interested in math -- I'd say give them fun things to work on that happen to require math. Don't necessarily introduce it as math, though. Magic Squares are always neat to play with, other puzzles are fun too.
Also, just point out places where you're using math to figure things out as you do it. Like when you're mentally figuring out how long it takes to drive somewhere, just work it out loud. Or maybe ask your kid to guess, and then ask them how they came to that conclusion.
For me, in second grade, those timed addition tests got me motivated to really work on those addition skills and get all 100 answers as quickly as possible. The competitive aspect got me going. It's a major stress and turnoff, though, for many people, so I don't necessarily recommend it for everyone.
The main thing is to not hide the math, and let them grab ahold of it if they're interested. Don't force it on them, just expose them to it. If they see that math is in use all around them, then it's suddenly not so abstract. It's not all "addition packets."
Uhm, I'm Mr. Z. That was Ctrl-Z you were replying
to.:-)
And, I'd like to point out that I too like to use contractions. Now go away, you stick in the mud.
You probably still cling to "whom" vs. "who." Even noted linguists have come out saying "whom" should largely go away.
No, swapping the MB power cables made a funny sound. I toasted an MB once doing exactly that.
As for g=c800:5... oh man that takes me back. That, and running OpTune to adjust the interleave for optimal performance... My crappy 8088 needed 5:1 interleave for decent performance.
I think Hungarian notation did serve a purpose, but nowadays it's obsoleted by modern compilers
and high-level languages.
The main usefulness of Hungarian notation was in the days when much of the OS was still written in assembler. There is no type-checking in the assembler, so having a convenient way of conveying type information to the programmer, consistently,
across a large organization is useful.
Consider a C program where you might have a struct foo. In one function, you might have
something which is struct foo variable and elsewhere you'll have one or more variables that are pointers to struct foo. Hungarian notation lets you see at a glance whether a given variable (which you happen to know deals with a struct foo) is the structure or just a pointer to it.
If you screw up "var->field" versus "var.field" in a C program, a modern compiler gently reminds you. If you screw that up in an assembly program, nothing warns you. You just end up crashing mysteriously.
That said, I think Hungarian notation specifically is just ugly. But it's better than trying to read through C++ name-mangling!
That's cool. I always thought "jag-wire" sounded
stupid. Maybe that's because I only ever heard that pronounciation when I was in grade school, from other grade schoolers. Either "jag-war" or "jag-u-are" makes much more sense.
FWIW, I also prefer to spell grey with an 'e'.
Though being a true USA'ian, I believe in "or", "er", "s" and "z" rather than "our", "re", "c" and "s". (eg. "color" vs. "colour", "center" vs. "centre", "defense" vs. "defence", and "analyze" vs. "analyse".):-)
Linewidth is essentially that "0.13 micron" number and similar that semiconductor manufacturers quote when they're quoting the process node that their device is manufactured on. It's a size gauge used to advertise how advanced the process is. Smaller is better.
Semi mfgrs usually quote "L_effective",
which is the "effective gate length of the smallest transistor". This is usually a bit smaller than "L_drawn" (the drawn gate length), and smaller than the line width. This page (down near the bottom) offers this blurb from a Motorola engineer:
In the case of line widths there may however be some legitimacy to the different numbers they feed you. Each company uses a different definition for this parameter, and within the same Company they may bounce between definitions to suit their purposes. One definition is the drawn width of the minimum poly-silicon feature. Another definition is called Leff ('L' effective), the minimum length of the electrically isolated region under the CMOS transistor. The value in this second definition is modulated by the drawn width from the first definition. It, however, is also modulated by diffusion of ions implanted into the silicon substrate which often makes it 15% to 40% smaller then the drawn width. This definition is also highly dependent on the algorithm and the equipment used to calculate the Leff parameter.
There is yet a third definition also commonly used for line-widths which is very similar to the first definition. This definition gives the average minimum width of the actual poly-silicon where it forms the gate of a transistor. Due to the polymerization of the masking resist during the poly-silicon etch and the magnitude of the exposure during the photo step, this value can be 10% greater or less than the drawn width.
This is even more true if you're paying mondo dollars for per-instance licenses on some compute heavy software.
For instance, here at work, our design team uses LSF to farm off simulation jobs to all our desktop machines. To get a certain throughput (so the engineers aren't idle), they need a certain number of licenses running all at once. Licenses for some of these packages go for something like $60,000/CPU. So, if you save even 20% on the compute time, you can cut your license costs dramatically and more than make back your investment on the hardware.
Interesting. I think I know where I got the
mistaken impression. The standard stack layout for Alpha places
the return address at the opposite end of the
stack frame from x86. At least, thats what
these two pages seem to say:
[here]
and [here].
Usually, the return address
is one of the first things pushed by the callee.
On x86, with PUSH/POP instructions, this means that the return address will be at a higher address than all the local variables. Alpha,
on the other hand, seems to allocate a frame and
then fill the frame from lower towards higher addresses. (This probably stems from using generic load/store instructions instead of special push/pop instructions.) Hence my confusion.
I realize upward growing stacks aren't a cure for
buffer overflows. I was merely pointing out that
differences in stack direction require different approaches.
Oh, and I did go look at extend_stack in the kernel source. Sure enough, the stack always grows downwards on Linux. Thanks for clearing up some confusion for me.
That's cool, just so long as people understand it's a short term band-aid.
The ultimate hack, though, would be to have the worm hook itself on port 80 and act as a proxy for Apache. Bet you don't have 80 blocked if your running a webserver....
In my own setup, I have just about everything inbound blocked except for 22 and 80 (don't need SSL, only need SSH and http). While that'd stop this particular worm, it wouldn't stop a trickier one that thought ahead about firewalls and packet filters. Therefore, I disabled SSL in the configs (I had just been using the defaults, which leave SSL on), and installed updated openssl libraries.
You might save yourself from *this* worm, but how long until someone 0wn3z you with some other 37331 worm that uses port 2003? or 2004? or 37331? or some other number? Hmmmmm?
While you could nuke GCC from your machine (ouch!)
why not just patch the hole and get on with life?
Actually, the stacks are usually pretty similar. (On most Linux boxes, stacks grow towards lower addresses, except on Alpha, IIRC. Heaps depend on the libc implementation, not the CPU.) As a result, the structure of a buffer flow vulnerability doesn't change much from machine
to machine.
The big difference that keeps this 'sploit tied
to x86 is the instruction set. You can't run x86 instructions on other CPUs by default.
(Ignoring FX!86 on Alpha, since it's not likely
to step up to bat on your shellcode anyway.)
Read the first text you quoted a little more closely: "The virus isn't trucking its complete source code around, you know."
While it may be carrying the source for the little
zombie/DDoS thing, it's not carrying around the
source for the binary "shellcode" it uses to overflow the stack.
If it could detect the remote host's CPU type, it
could indeed use shellcode tailored to the CPU
it is about it infect.
It does not. It carries around shellcode only
for x86.
Think a little more general: Some pool "N" of UML instances running on a smaller or same-sized pool "M" of physical machines.
If you could migrate a UML from machine to machine, you'd be all set. You could even load-balance, so that "M" could be noticeably smaller than "N". You could also change "M" on the fly, say, for maintenence purposes (eg. backups).
He wants a way for a web application to access the harddrive, because his app presumably needs it.
He recognizes that web applications should not have willy-nilly access to the hard drive as it is a security concern.
That's why he mentions 'trusted scripts' as a possible solution. It'd allow him access to the HD from his web application without changing the security policy.
FWIW, RIAA equalization exists to overcome the uneven frequency response of the vinyl / needle / tonearm
combination. Notice in the linked PDF that lower
frequencies are boosted, and higher frequencies are
attenuated.
In all likelihood, this extra bass boost is where some of that "warmer sound" comes from. Not to mention that low-level stereo white noise has a nice spatial (as in space-filling as opposed to point-like) quality to it. The two together, both artifacts, can actually make the music
seem "better." (Even though objectively it's
been distorted.)
Also, with some encoders, certain harmonics (such as an overtone from an instrument) are retained in such a way so as to turn into a 'morse code' instrument.
My wife has a rip of "The Day the Music Died" that does this. There's an annoying "deet de deet de de deet" that comes from a quantized overtone of some instrument. And what's worse is she can't here it.
As for the "underwater" sound -- it's similar to the sound you get from a warped, aged cassette tape. Sortuva "warbly" sound to anything high pitched, especially cymbals. And depending on the encoder, it may also sound a little muffled. Many encoders low-pass filter the sound before encoding it, so it sounds like you're listening to it over a telephone or through a cotton ball or something.
When you decode your MP3 in XMMS, you'll have all the wonderful, yummy MP3 artifacts in that nice WAV file you just wrote. These artifacts will be encoded into the Ogg, along with whatever other artifacts Ogg may introduce. Decoding an MP3 to a WAV does not exempt you from the lossiness that is MP3.
Guess what? The quality will be worse than the MP3 was by itself, and worse than what Ogg could do from a clean rip.
In short: Don't do it, unless you have an Ogg-only player that you need to play the music on, and you *cough* "lost your original."
nitpick: Weight doesn't matter quite as much for the ground-based launch system, which is what this article's about.
As for using Java and all that: I don't know if you actually read any of the details, but the system must cope with upwards of 50000 events with millisecond response times. This argues for a highly real time, perhaps rather distributed processing. In many ways, it argues for many smaller, simpler subsystems, just so you can keep the predictability! Java is NOT the way to go for such a system. Having a mondo mega centralized system on a super-powerful CPU with lots of RAM is a recipe for disaster unless you were extremely careful. A room full of 6502s each dedicated to a narrow task would cope with this problem much better.
I actually did run Linux on a 2MB RAM system (a 386 SX16). That was back in the 0.99.14 days, and I was using SLS 1.03.
My main machine was a 486DX33 with 4MB a the time. Everything fit fine on a 90MB partition when I was first getting started. Later, I got a 340MB drive and installed X. X was a bit painful until I managed to upgrade to a whopping 8MB RAM. Of course, olvwm has a much smaller footprint than GNOME or KDE, and there wasn't a web worth browsing in 1994.
Slashdot Mirror
And why, perchance, does it remain unsolved without actual investigation?
There is an issue of timeslice granularity -- each thread will only get a timeslice occasionally when there are many threads. So, you'll need to crank up HZ a bit and/or service multiple clients per thread.
The main thing, though, is that if you consider that the threads share their VM (that is, their program code and static data), you could probably do 10000 clients without too much heartache. The "COW" space (the amount on data that's private due to "copy on write") is the bounding factor.
Now, 10000 clients with 100% dynamic content? Ha. Too many dirty pages. 10000 clients with largely static content? Sure -- just sendfile it all. :-)
--JoeThis is Linux. In Linux, the difference between a thread and a process is more-or-less whether the VM space is shared or copy-on-write. That's pretty much it as I understand it.
Starting 100000 processes, therefore, seems like it should be doable, so long as there aren't so many "dirty" pages in the forked executables that the system thrashes itself to death handling the COW pages. This is where having a 64-bit system and a lot of RAM would help you. (You need the 64-bit system to address the RAM sanely. The whole "highmem" kludge on x86 is just that, a kludge.)
--JoeWe had timed addition tests something like once every week or two in 2nd grade. The "advanced" kids got to do timed multiplication tests by the end of the year. These were simple 1-digit by 1-digit multiplications, and at that age, they were hard.
I remember it clearly, because I went to different schools for 1st, 2nd and 3rd grades. In 3rd grade, we actually started to learn simple division. They introduced long division and fractions in 4th grade. I remember working problems on the board in Mrs. Nunn's room. (Yes, I remember my 2nd, 3rd, and 4th grade teachers' names--Mrs. Nietske, Mrs. Thomson/Mrs. Campbell, and Mrs. Nunn, respectively. I don't really remember my kindergarten or 1st grade years real well. I do remember seeing all the Carter vs. Reagan campaign paraphenalia when I was in kindergarten though.)
Careening suddenly back ontopic: To keep your kid interested in math -- I'd say give them fun things to work on that happen to require math. Don't necessarily introduce it as math, though. Magic Squares are always neat to play with, other puzzles are fun too. Also, just point out places where you're using math to figure things out as you do it. Like when you're mentally figuring out how long it takes to drive somewhere, just work it out loud. Or maybe ask your kid to guess, and then ask them how they came to that conclusion.
For me, in second grade, those timed addition tests got me motivated to really work on those addition skills and get all 100 answers as quickly as possible. The competitive aspect got me going. It's a major stress and turnoff, though, for many people, so I don't necessarily recommend it for everyone.
The main thing is to not hide the math, and let them grab ahold of it if they're interested. Don't force it on them, just expose them to it. If they see that math is in use all around them, then it's suddenly not so abstract. It's not all "addition packets."
--JoeUhm, I'm Mr. Z. That was Ctrl-Z you were replying to. :-)
And, I'd like to point out that I too like to use contractions. Now go away, you stick in the mud. You probably still cling to "whom" vs. "who." Even noted linguists have come out saying "whom" should largely go away.
--JoeNo, swapping the MB power cables made a funny sound. I toasted an MB once doing exactly that.
As for g=c800:5... oh man that takes me back. That, and running OpTune to adjust the interleave for optimal performance... My crappy 8088 needed 5:1 interleave for decent performance.
--JoeI think Hungarian notation did serve a purpose, but nowadays it's obsoleted by modern compilers and high-level languages.
The main usefulness of Hungarian notation was in the days when much of the OS was still written in assembler. There is no type-checking in the assembler, so having a convenient way of conveying type information to the programmer, consistently, across a large organization is useful.
Consider a C program where you might have a struct foo. In one function, you might have something which is struct foo variable and elsewhere you'll have one or more variables that are pointers to struct foo. Hungarian notation lets you see at a glance whether a given variable (which you happen to know deals with a struct foo) is the structure or just a pointer to it.
If you screw up "var->field" versus "var.field" in a C program, a modern compiler gently reminds you. If you screw that up in an assembly program, nothing warns you. You just end up crashing mysteriously.
That said, I think Hungarian notation specifically is just ugly. But it's better than trying to read through C++ name-mangling!
--JoeThat's cool. I always thought "jag-wire" sounded stupid. Maybe that's because I only ever heard that pronounciation when I was in grade school, from other grade schoolers. Either "jag-war" or "jag-u-are" makes much more sense.
FWIW, I also prefer to spell grey with an 'e'. Though being a true USA'ian, I believe in "or", "er", "s" and "z" rather than "our", "re", "c" and "s". (eg. "color" vs. "colour", "center" vs. "centre", "defense" vs. "defence", and "analyze" vs. "analyse".) :-)
--JoeIntellivision, of course! It was almost impossible to make a basket unless your aim was good. Just like real life. ;-)
--JoeIf you believe the car commercials, it's pronounced roughly "jhag-you-are".
--JoeSame here, until NES and Sega Genesis came out. :-)
Now I write games for Intellivision. ;-)
--JoeLinewidth is essentially that "0.13 micron" number and similar that semiconductor manufacturers quote when they're quoting the process node that their device is manufactured on. It's a size gauge used to advertise how advanced the process is. Smaller is better.
Semi mfgrs usually quote "L_effective", which is the "effective gate length of the smallest transistor". This is usually a bit smaller than "L_drawn" (the drawn gate length), and smaller than the line width. This page (down near the bottom) offers this blurb from a Motorola engineer:
--JoeThis is even more true if you're paying mondo dollars for per-instance licenses on some compute heavy software.
For instance, here at work, our design team uses LSF to farm off simulation jobs to all our desktop machines. To get a certain throughput (so the engineers aren't idle), they need a certain number of licenses running all at once. Licenses for some of these packages go for something like $60,000/CPU. So, if you save even 20% on the compute time, you can cut your license costs dramatically and more than make back your investment on the hardware.
--JoeInteresting. I think I know where I got the mistaken impression. The standard stack layout for Alpha places the return address at the opposite end of the stack frame from x86. At least, thats what these two pages seem to say: [here] and [here].
Usually, the return address is one of the first things pushed by the callee. On x86, with PUSH/POP instructions, this means that the return address will be at a higher address than all the local variables. Alpha, on the other hand, seems to allocate a frame and then fill the frame from lower towards higher addresses. (This probably stems from using generic load/store instructions instead of special push/pop instructions.) Hence my confusion.
I realize upward growing stacks aren't a cure for buffer overflows. I was merely pointing out that differences in stack direction require different approaches.
Oh, and I did go look at extend_stack in the kernel source. Sure enough, the stack always grows downwards on Linux. Thanks for clearing up some confusion for me.
--JoeThat's cool, just so long as people understand it's a short term band-aid.
The ultimate hack, though, would be to have the worm hook itself on port 80 and act as a proxy for Apache. Bet you don't have 80 blocked if your running a webserver....
In my own setup, I have just about everything inbound blocked except for 22 and 80 (don't need SSL, only need SSH and http). While that'd stop this particular worm, it wouldn't stop a trickier one that thought ahead about firewalls and packet filters. Therefore, I disabled SSL in the configs (I had just been using the defaults, which leave SSL on), and installed updated openssl libraries.
--JoeYou might save yourself from *this* worm, but how long until someone 0wn3z you with some other 37331 worm that uses port 2003? or 2004? or 37331? or some other number? Hmmmmm?
While you could nuke GCC from your machine (ouch!) why not just patch the hole and get on with life?
--JoeActually, the stacks are usually pretty similar. (On most Linux boxes, stacks grow towards lower addresses, except on Alpha, IIRC. Heaps depend on the libc implementation, not the CPU.) As a result, the structure of a buffer flow vulnerability doesn't change much from machine to machine.
The big difference that keeps this 'sploit tied to x86 is the instruction set. You can't run x86 instructions on other CPUs by default. (Ignoring FX!86 on Alpha, since it's not likely to step up to bat on your shellcode anyway.)
--JoeRead the first text you quoted a little more closely: "The virus isn't trucking its complete source code around, you know." While it may be carrying the source for the little zombie/DDoS thing, it's not carrying around the source for the binary "shellcode" it uses to overflow the stack.
If it could detect the remote host's CPU type, it could indeed use shellcode tailored to the CPU it is about it infect. It does not. It carries around shellcode only for x86.
--JoeThink a little more general: Some pool "N" of UML instances running on a smaller or same-sized pool "M" of physical machines. If you could migrate a UML from machine to machine, you'd be all set. You could even load-balance, so that "M" could be noticeably smaller than "N". You could also change "M" on the fly, say, for maintenence purposes (eg. backups).
--JoeHis dilemma is thus:
That's why he mentions 'trusted scripts' as a possible solution. It'd allow him access to the HD from his web application without changing the security policy.
--JoeFWIW, RIAA equalization exists to overcome the uneven frequency response of the vinyl / needle / tonearm combination. Notice in the linked PDF that lower frequencies are boosted, and higher frequencies are attenuated.
In all likelihood, this extra bass boost is where some of that "warmer sound" comes from. Not to mention that low-level stereo white noise has a nice spatial (as in space-filling as opposed to point-like) quality to it. The two together, both artifacts, can actually make the music seem "better." (Even though objectively it's been distorted.)
--JoeAlso, with some encoders, certain harmonics (such as an overtone from an instrument) are retained in such a way so as to turn into a 'morse code' instrument. My wife has a rip of "The Day the Music Died" that does this. There's an annoying "deet de deet de de deet" that comes from a quantized overtone of some instrument. And what's worse is she can't here it.
As for the "underwater" sound -- it's similar to the sound you get from a warped, aged cassette tape. Sortuva "warbly" sound to anything high pitched, especially cymbals. And depending on the encoder, it may also sound a little muffled. Many encoders low-pass filter the sound before encoding it, so it sounds like you're listening to it over a telephone or through a cotton ball or something.
--JoeUhm, no.
When you decode your MP3 in XMMS, you'll have all the wonderful, yummy MP3 artifacts in that nice WAV file you just wrote. These artifacts will be encoded into the Ogg, along with whatever other artifacts Ogg may introduce. Decoding an MP3 to a WAV does not exempt you from the lossiness that is MP3.
Guess what? The quality will be worse than the MP3 was by itself, and worse than what Ogg could do from a clean rip.
In short: Don't do it, unless you have an Ogg-only player that you need to play the music on, and you *cough* "lost your original."
--JoeOh, I know it's not really "small" in the grand scheme of things. It *is* small for a box running X, though.
Incidentally, those early Macs had only 128K of RAM. They weren't fully multitasking, but they did have a full (monochrome) GUI.
--Joenitpick: Weight doesn't matter quite as much for the ground-based launch system, which is what this article's about.
As for using Java and all that: I don't know if you actually read any of the details, but the system must cope with upwards of 50000 events with millisecond response times. This argues for a highly real time, perhaps rather distributed processing. In many ways, it argues for many smaller, simpler subsystems, just so you can keep the predictability! Java is NOT the way to go for such a system. Having a mondo mega centralized system on a super-powerful CPU with lots of RAM is a recipe for disaster unless you were extremely careful. A room full of 6502s each dedicated to a narrow task would cope with this problem much better.
Don't make me trot out the Engineer and the Toaster again...
--JoeI actually did run Linux on a 2MB RAM system (a 386 SX16). That was back in the 0.99.14 days, and I was using SLS 1.03.
My main machine was a 486DX33 with 4MB a the time. Everything fit fine on a 90MB partition when I was first getting started. Later, I got a 340MB drive and installed X. X was a bit painful until I managed to upgrade to a whopping 8MB RAM. Of course, olvwm has a much smaller footprint than GNOME or KDE, and there wasn't a web worth browsing in 1994.
--Joe