It's an issue anywhere there is congestion. Which happens anywhere people don't like wasting money.
Buffering versus line utilization is an interesting relationship. You NEED buffering if you want to keep the line highly utilized because data comes in randomly from various places -- if you have small buffers, then the various TCPs will often collide, drop, and backoff even though the line isn't highly utilized. The "right" amount of buffering is a function of how much you want to pay, the utilization you want to achieve, the latency you are willing tolerate, and, assuming an adaptive protocol like TCP, the round trip time of from one endstation to the other (not just on your segment).
In the core, the lines are fast, but also very expensive. Providers want those things well utilized -- a 10Gb pipe which is only running at 20% isn't earning enough money. So the core tends to have deep buffering, lots of simultaneous flows, and hence runs at high utilization. It's not uncommon to have buffers on the order of several megabytes per port (providers often will measure it "milliseconds").
In a LAN, gigabit lines run everywhere, and the wires are short and cheap. They tend to be cheap switches, with shallow buffers. No one cares too much if packets are dropped, there is plenty of bandwidth to resend things. It's not uncommon to have 2-4 megabytes shared for the whole switch (24 ports or whatever).
In the first case, prioritizing helps avoid large latencies, since the core has deep buffers, and enough users to keep the buffers busy.
In the second case, prioritizing helps avoid packet drops, since the LAN has shallow buffers.
It's not as simple as whether the ISP is running at 100% or not (i.e. your packet will get through, or not). Some apps are very sensitive to latency (voice, gaming, etc) while most are not.
The switches have buffering which gets emptier, fuller, emptier, fuller. When it runs out of buffering, i.e. your 100% situation, packets get dropped, and TCP "backs off" to try to avoid that happening again in the immediate future. In fact, Random Early Discard (RED) protocols will drop the odd random packet, with increasing probability as the buffer fills, to let TCP know to backoff.... before LOTS of packets start getting dropped. If you do get to 100%, it shouldn't last long.
However when your time sensitive packets are in the same queue as it gets emptier, fuller, emptier, fuller, then even if the buffers never fill, you still suffer from increased latency... and also latency variation (jitter), which can be even more problematic (when do you decide the packets never coming and you need to fill in the gap?). Furthermore, you'd like to avoid dropping these time-sensitive packets with RED (which of course would be another "non neutral behavior"). That's because these kinds of apps generally send a steady stream, they will sorely miss the data in that dropped packet, and anyway they won't backoff in the face of drops, defeating the whole purpose of RED.
Enterprises who use IP Telephony will usually put that traffic at a higher priority (and, for that priority, disable RED). Not because their gigabit LANs are at 100%... they do it because it makes the telephone calls almost as robust and low-latency as "fixed lines".
The whole Net Neutrality debate would perhaps get somewhere if people agreed on what they were talking about. There's too many very different ideas bundled into the same name. The version that makes it illegal to willfully delay/block/etc will get 90% support. The version where it's illegal to prioritize ANYTHING is much more debatable. Those who have actually rolled out services over shared medium (IP telephony, video conferencing, etc) will have a lot of information to share on the latter.
Simply throwing bandwidth at the problem is not (yet) a viable solution, since folks are still figuring out ways to use all the bandwidth they can get. It's like saying "I don't need background threads and foreground threads, just treat them all the same and make the CPUs faster". Sounds nice, in theory.
Think of a service like Skype. Assume we want that kind of innovative service to prosper. This absolutely requires that service providers don't block/delay Skype packets. Meanwhile, to hit the quality and reliability of "fixed lines", some way to mark that small number of packets as "important" would help A LOT.
-netchipguy
I don't "sell my software" at Best Buy. I sell "upgrades" to an appliance that you must already own.
Your right to copy the software isn't based on whether I chose to build on commodity PC hardware, or design my boards or even chips.
Say I build an "email filter" which is actually a PC with two ethernet ports running my custom software. The hardware part is trivial, but obviously, I am spending effort writing the software, so I charge $2000 for the product.
Say I offer my customers annual upgrades to the software for $129, and I specify that it is to be used only on my hardware.
How can anyone even remotely consider arguing that another company can buy $500 PCs, buy my $129 UPGRADE CD, install it, and then go to market with this?
And, SERIOUSLY people, actually try to call me a monopolist when there are other people selling AND GIVING AWAY "email filter" software, that runs on the exact same hardware, and these other channels move way more copies of their software than I do my hardware?
Windows, Linux, etc... these are pieces of software that are meant to run on whatever x86 computer you have.
OS-X is a piece of software meant to run on an Apple-branded computer. Just because it also happens to be an operating system changes nothing. And frankly even if being an "OS" mattered, or being BSD based mattered, the OS-X install includes many applications, including some of which may have royalties associated (DVD Player? MP3 encoding?) which are accounted for during the sale of the original hardware.
Apple would IMHO be wrong if they were to sell OS-X for non-Apple machines with arbitrary approval of vendors. For example, if they let Dell, etc, sell OS-X, UNTIL the day Dell makes a really nice laptop, at which point they deny them the license. I would consider that anti-competitive. But honestly, depending on the details, it would still be easily arguable that they could sell to 3rd parties with strict control over exactly which vendors, and even which machines, are allowed to run OS-X. To preserve the experience. So Dell would have to prove that the denial was purely an anti-competitive move.
But this Pystar case should be open and shut. I am not a lawyer, I am a SANE PERSON who happens to understand the implications here.
Reading most of these posts gives you a pretty clear idea of where most Slashdot readers have spent a good portion of their time (doing assembly or 1-2 levels up from it).
The problem is that "programming" today is done at many different levels. At any level it's naturally helpful to know a bit about the couple of levels beneath you.
Trained in EECS, I once enjoyed thinking that I understood "all levels" of computing systems, something that was possible when C was a "high level" language. I had written Windows apps in C, written Z80 assembler, designed a MIPS CPU at the RTL level, built a 4-bit CPU out of gates, and done transistor layout for logic cells.
Those times are gone. There are many more higher layers ("programming" in Flash? Excel?) that it's not just not possible to for some people to have a good enough grasp of assembly to be worthwhile.
Then there's the fact that for some people "assembly code" is pretty high level. Assuming you mean those complex macro instructions that break down into N actual hardware operations (including loops)? Even those who say "I'm glad I learned assembly" usually don't understand how instructions are broken down and scheduled differently on different CPU implementations... how bugs may cause instructions to be emulated, or how the alignment of memory accesses can affect timing, or how your instructions interact with virtual memory, caching, exception contexts, etc.
It's a complex multi-layered world out there.
-netchipguy
Computer prints you a receipt with a random number. Your vote is kept with your random number (electronically, plus internal paper roll in case electronic copy is FUBARed). You can check your vote, using the random number, on the web or via a bulletin board at the voting place the next day. Poll workers count the total number of voters at each site, which should "exactly" match the number of records on the web/bulletin board.
Can anyone think of a way to cheat THAT system?
It seems to be able to handle extra votes, dropped votes, and changed votes.
I've read a lot about encryption exploits and this has to be one of the simplest. No compute power, no tricky timing, nothing. I'm amazed it's taken this long for such a simple exploit to surface. To address most of the comments by class:
Why are the banks so stupid, they should encrypt end-to-end, use better protocols, etc
The system is 30 years old and evolved from different networks that were glued together over time. The fundamental assumption being that only the physically sealed HSM boxes handle decryption/encryption, and that any snooping/forging of data between HSMs is not a threat. Which has been proven wrong.
It would be easy to catch perps
Maybe in the West it would. But not so easy when someone is pulling cash from the Middle East or the ex-Soviet block countries for example. No encryption keys are assumed known. The actual ATM time required is only 100 transactions with incorrect pins and arbitrary account numbers. A fair number of HSM transactions are required, but this can be automated from an infected machine within a bank or waypoint. No HSM or encryption hacking itself is required.
The data is encrypted and so it's one in a billion to crack it
The encryption is never broken here. The point is that a very limited number of plaintexts are exploited (10,000) via attacking the least secure PIN transport format, in combination with a practically constant "transport" key, resulting in the ability to directly compare encrypted output against a table to determine the PIN that is within an arbitrary EPB that is reformatted to the insecure format (a standard operation for the HSM).
They can fix the protocol
Not without overhauling a lot of infrastructure that's been built up for 30 years, belonging to a lot of different entities in a lot of countries. Who's gonna pay for all that?
You never could trust dodgy ATMs, tellers, etc
True, but they also stand a much greater chance of being caught. They are the endpoints, which were always an issue. Now anyone with access to the data going in and out of an intermediate HSM can steal your pin, which is a much more anonymous situation.
The net effect of this is that you should watch your bank account for withdrawals you didn't make (duh). Especially if you are pulling money in foreign countries. The banks are going to need to roll out fixes to this, probably starting with more direct routes from ATMs to the host bank. We may see "trusted" ATMs popping up in the interim (i.e. "this ATM is certified, and has a direct link to Wells Fargo").
IMHO a technically inclined person can shave Linux down to the bare minimum services relatively easily. There are distributions that focus on rock-solid stability or security, and others that focus on being a Windows replacement.
I hate to be so blunt, but anyone debating this is an idiot. Code reuse has been with us a long time, and it's the only way that exponentially more complex systems will be built without exponentially larger teams.
If you are thinking "but I never cut and paste code" then ask yourself if you ever use a library, for example (standard template library, OpenGL, even stdio.h functions used to be coded by hand 30 years ago). Or if you code in a higher level language where useful functions are wrapped up for you (an entire web browser as an ActiveX control, anyone?).
Yes 90% of code is crap. But it is ridiculous to think that we shouldn't build on the 10% of good stuff that is, or can be, neatly encapsulated.
Formal Verification has become a staple of hardware design. It basically comes in two forms: equivalence checking (used a LOT to compare two similar designs) and model checking (which is slowly making inroads; used to compare a design against a set of rules, another model, etc).
I have often wondered why more formal techniques aren't deployed in the software world.
As has been mentioned here, the thing about formal is that you will often "stump it" and so you may need to "help it" in complex, real world designs. But it does find many silly mistakes, not necessarily (or even usually) design mistakes, but version mismatches, tool bugs/config errors, etc.
Equivalence Checking is VERY useful for checking last minute changes. For example, when adding an option to the design, it is quick and easy to prove that the design is unchanged when the option is not enabled. We also use it to check compiled (gates) versus source (RTL) versions of designs.
I could imagine both models being useful for software developers. For example, formal equivalency tools could help prove that the "golden version" of a function is functionally equivalent to the "performance tuned" version (hand-tuning the code, compiling it, etc.)
Formal Model Checking is harder because writing formal rules is a painstaking process. You'll never realize how incomplete "human" specifications are until you try to constrain a formal model checker. It will find a boatload of failure cases that are "obviously not going to happen" (so obvious that they weren't included, and need to be added, usually iteratively).
Model checking has seen an uptick lately through shipping tools with lots of default rules included (making it a form of "super LINT"). At which point adding your own rules/specifications is something you do at your leisure.
It's these kinds of point uses, versus a theoretical complete verification framework, that formal methods can deliver today.
One thing you guys need to understand is that memory latency is a secondary issue in PC architecture (much as AMD would love you to believe otherwise).
Fact 1: while CPUs have gone from 2GHz, commodity DRAM latency has gone from ~100ns to ~50ns. Clearly density, cost, and power are the priorities.
Fact 2: memory vendors could reduce latency drastically if there was a desire to. Take RLDRAM-2 from Micron... 20ns latency, slightly larger die. Current cost: 10X the price of DDR2 because the market is so much smaller. I have actually asked DDR2 program managers whether they would make the part 20% lower latency at 5% more cost and they replied "absolutely not".
Fact 3: Intel may have an off-chip memory controller, but in a four-socket AMD board, 75% of RAM is attached to an off-chip controller also. 8-way is worse.
Conclusion: Winning CPU architectures have been dealing with memory latency for ages. Architectures that work around memory latency, versus needing less of it, will scale better given facts #1 and #2.
AMD and Intel have just chosen different bus/cache solutions. They both deal with horrendous memory latencies. AMD added a bunch of pins to their CPU, Intel added a bunch of cache; both add cost. IMHO, AMD's N-way socket story (good due to HT) is hurt by the fact that most memory is now off-chip, while they may not have enough cache to deal with that.
Slashdot Mirror
Well put, sir.
It's an issue anywhere there is congestion. Which happens anywhere people don't like wasting money.
Buffering versus line utilization is an interesting relationship. You NEED buffering if you want to keep the line highly utilized because data comes in randomly from various places -- if you have small buffers, then the various TCPs will often collide, drop, and backoff even though the line isn't highly utilized. The "right" amount of buffering is a function of how much you want to pay, the utilization you want to achieve, the latency you are willing tolerate, and, assuming an adaptive protocol like TCP, the round trip time of from one endstation to the other (not just on your segment).
In the core, the lines are fast, but also very expensive. Providers want those things well utilized -- a 10Gb pipe which is only running at 20% isn't earning enough money. So the core tends to have deep buffering, lots of simultaneous flows, and hence runs at high utilization. It's not uncommon to have buffers on the order of several megabytes per port (providers often will measure it "milliseconds").
In a LAN, gigabit lines run everywhere, and the wires are short and cheap. They tend to be cheap switches, with shallow buffers. No one cares too much if packets are dropped, there is plenty of bandwidth to resend things. It's not uncommon to have 2-4 megabytes shared for the whole switch (24 ports or whatever).
In the first case, prioritizing helps avoid large latencies, since the core has deep buffers, and enough users to keep the buffers busy.
In the second case, prioritizing helps avoid packet drops, since the LAN has shallow buffers.
-netchipguy
It's not as simple as whether the ISP is running at 100% or not (i.e. your packet will get through, or not). Some apps are very sensitive to latency (voice, gaming, etc) while most are not.
The switches have buffering which gets emptier, fuller, emptier, fuller. When it runs out of buffering, i.e. your 100% situation, packets get dropped, and TCP "backs off" to try to avoid that happening again in the immediate future. In fact, Random Early Discard (RED) protocols will drop the odd random packet, with increasing probability as the buffer fills, to let TCP know to backoff.... before LOTS of packets start getting dropped. If you do get to 100%, it shouldn't last long.
However when your time sensitive packets are in the same queue as it gets emptier, fuller, emptier, fuller, then even if the buffers never fill, you still suffer from increased latency... and also latency variation (jitter), which can be even more problematic (when do you decide the packets never coming and you need to fill in the gap?). Furthermore, you'd like to avoid dropping these time-sensitive packets with RED (which of course would be another "non neutral behavior"). That's because these kinds of apps generally send a steady stream, they will sorely miss the data in that dropped packet, and anyway they won't backoff in the face of drops, defeating the whole purpose of RED.
Enterprises who use IP Telephony will usually put that traffic at a higher priority (and, for that priority, disable RED). Not because their gigabit LANs are at 100%... they do it because it makes the telephone calls almost as robust and low-latency as "fixed lines".
The whole Net Neutrality debate would perhaps get somewhere if people agreed on what they were talking about. There's too many very different ideas bundled into the same name. The version that makes it illegal to willfully delay/block/etc will get 90% support. The version where it's illegal to prioritize ANYTHING is much more debatable. Those who have actually rolled out services over shared medium (IP telephony, video conferencing, etc) will have a lot of information to share on the latter.
Simply throwing bandwidth at the problem is not (yet) a viable solution, since folks are still figuring out ways to use all the bandwidth they can get. It's like saying "I don't need background threads and foreground threads, just treat them all the same and make the CPUs faster". Sounds nice, in theory.
Think of a service like Skype. Assume we want that kind of innovative service to prosper. This absolutely requires that service providers don't block/delay Skype packets. Meanwhile, to hit the quality and reliability of "fixed lines", some way to mark that small number of packets as "important" would help A LOT.
-netchipguy
I don't "sell my software" at Best Buy. I sell "upgrades" to an appliance that you must already own. Your right to copy the software isn't based on whether I chose to build on commodity PC hardware, or design my boards or even chips.
Say I build an "email filter" which is actually a PC with two ethernet ports running my custom software. The hardware part is trivial, but obviously, I am spending effort writing the software, so I charge $2000 for the product.
Say I offer my customers annual upgrades to the software for $129, and I specify that it is to be used only on my hardware.
How can anyone even remotely consider arguing that another company can buy $500 PCs, buy my $129 UPGRADE CD, install it, and then go to market with this?
And, SERIOUSLY people, actually try to call me a monopolist when there are other people selling AND GIVING AWAY "email filter" software, that runs on the exact same hardware, and these other channels move way more copies of their software than I do my hardware?
Windows, Linux, etc... these are pieces of software that are meant to run on whatever x86 computer you have.
OS-X is a piece of software meant to run on an Apple-branded computer. Just because it also happens to be an operating system changes nothing. And frankly even if being an "OS" mattered, or being BSD based mattered, the OS-X install includes many applications, including some of which may have royalties associated (DVD Player? MP3 encoding?) which are accounted for during the sale of the original hardware.
Apple would IMHO be wrong if they were to sell OS-X for non-Apple machines with arbitrary approval of vendors. For example, if they let Dell, etc, sell OS-X, UNTIL the day Dell makes a really nice laptop, at which point they deny them the license. I would consider that anti-competitive. But honestly, depending on the details, it would still be easily arguable that they could sell to 3rd parties with strict control over exactly which vendors, and even which machines, are allowed to run OS-X. To preserve the experience. So Dell would have to prove that the denial was purely an anti-competitive move.
But this Pystar case should be open and shut. I am not a lawyer, I am a SANE PERSON who happens to understand the implications here.
-netchipguy
Reading most of these posts gives you a pretty clear idea of where most Slashdot readers have spent a good portion of their time (doing assembly or 1-2 levels up from it). The problem is that "programming" today is done at many different levels. At any level it's naturally helpful to know a bit about the couple of levels beneath you. Trained in EECS, I once enjoyed thinking that I understood "all levels" of computing systems, something that was possible when C was a "high level" language. I had written Windows apps in C, written Z80 assembler, designed a MIPS CPU at the RTL level, built a 4-bit CPU out of gates, and done transistor layout for logic cells. Those times are gone. There are many more higher layers ("programming" in Flash? Excel?) that it's not just not possible to for some people to have a good enough grasp of assembly to be worthwhile. Then there's the fact that for some people "assembly code" is pretty high level. Assuming you mean those complex macro instructions that break down into N actual hardware operations (including loops)? Even those who say "I'm glad I learned assembly" usually don't understand how instructions are broken down and scheduled differently on different CPU implementations... how bugs may cause instructions to be emulated, or how the alignment of memory accesses can affect timing, or how your instructions interact with virtual memory, caching, exception contexts, etc. It's a complex multi-layered world out there. -netchipguy
Computer prints you a receipt with a random number. Your vote is kept with your random number (electronically, plus internal paper roll in case electronic copy is FUBARed). You can check your vote, using the random number, on the web or via a bulletin board at the voting place the next day. Poll workers count the total number of voters at each site, which should "exactly" match the number of records on the web/bulletin board.
Can anyone think of a way to cheat THAT system?
It seems to be able to handle extra votes, dropped votes, and changed votes.
I've read a lot about encryption exploits and this has to be one of the simplest. No compute power, no tricky timing, nothing. I'm amazed it's taken this long for such a simple exploit to surface. To address most of the comments by class:
Why are the banks so stupid, they should encrypt end-to-end, use better protocols, etc
The system is 30 years old and evolved from different networks that were glued together over time. The fundamental assumption being that only the physically sealed HSM boxes handle decryption/encryption, and that any snooping/forging of data between HSMs is not a threat. Which has been proven wrong.
It would be easy to catch perps
Maybe in the West it would. But not so easy when someone is pulling cash from the Middle East or the ex-Soviet block countries for example. No encryption keys are assumed known. The actual ATM time required is only 100 transactions with incorrect pins and arbitrary account numbers. A fair number of HSM transactions are required, but this can be automated from an infected machine within a bank or waypoint. No HSM or encryption hacking itself is required.
The data is encrypted and so it's one in a billion to crack it
The encryption is never broken here. The point is that a very limited number of plaintexts are exploited (10,000) via attacking the least secure PIN transport format, in combination with a practically constant "transport" key, resulting in the ability to directly compare encrypted output against a table to determine the PIN that is within an arbitrary EPB that is reformatted to the insecure format (a standard operation for the HSM).
They can fix the protocol
Not without overhauling a lot of infrastructure that's been built up for 30 years, belonging to a lot of different entities in a lot of countries. Who's gonna pay for all that?
You never could trust dodgy ATMs, tellers, etc
True, but they also stand a much greater chance of being caught. They are the endpoints, which were always an issue. Now anyone with access to the data going in and out of an intermediate HSM can steal your pin, which is a much more anonymous situation.
The net effect of this is that you should watch your bank account for withdrawals you didn't make (duh). Especially if you are pulling money in foreign countries. The banks are going to need to roll out fixes to this, probably starting with more direct routes from ATMs to the host bank. We may see "trusted" ATMs popping up in the interim (i.e. "this ATM is certified, and has a direct link to Wells Fargo").
IMHO a technically inclined person can shave Linux down to the bare minimum services relatively easily. There are distributions that focus on rock-solid stability or security, and others that focus on being a Windows replacement.
I hate to be so blunt, but anyone debating this is an idiot. Code reuse has been with us a long time, and it's the only way that exponentially more complex systems will be built without exponentially larger teams. If you are thinking "but I never cut and paste code" then ask yourself if you ever use a library, for example (standard template library, OpenGL, even stdio.h functions used to be coded by hand 30 years ago). Or if you code in a higher level language where useful functions are wrapped up for you (an entire web browser as an ActiveX control, anyone?). Yes 90% of code is crap. But it is ridiculous to think that we shouldn't build on the 10% of good stuff that is, or can be, neatly encapsulated.
Formal Verification has become a staple of hardware design. It basically comes in two forms: equivalence checking (used a LOT to compare two similar designs) and model checking (which is slowly making inroads; used to compare a design against a set of rules, another model, etc).
I have often wondered why more formal techniques aren't deployed in the software world.
As has been mentioned here, the thing about formal is that you will often "stump it" and so you may need to "help it" in complex, real world designs. But it does find many silly mistakes, not necessarily (or even usually) design mistakes, but version mismatches, tool bugs/config errors, etc.
Equivalence Checking is VERY useful for checking last minute changes. For example, when adding an option to the design, it is quick and easy to prove that the design is unchanged when the option is not enabled. We also use it to check compiled (gates) versus source (RTL) versions of designs.
I could imagine both models being useful for software developers. For example, formal equivalency tools could help prove that the "golden version" of a function is functionally equivalent to the "performance tuned" version (hand-tuning the code, compiling it, etc.)
Formal Model Checking is harder because writing formal rules is a painstaking process. You'll never realize how incomplete "human" specifications are until you try to constrain a formal model checker. It will find a boatload of failure cases that are "obviously not going to happen" (so obvious that they weren't included, and need to be added, usually iteratively).
Model checking has seen an uptick lately through shipping tools with lots of default rules included (making it a form of "super LINT"). At which point adding your own rules/specifications is something you do at your leisure.
It's these kinds of point uses, versus a theoretical complete verification framework, that formal methods can deliver today.
-netchipguy
One thing you guys need to understand is that memory latency is a secondary issue in PC architecture (much as AMD would love you to believe otherwise). Fact 1: while CPUs have gone from 2GHz, commodity DRAM latency has gone from ~100ns to ~50ns. Clearly density, cost, and power are the priorities. Fact 2: memory vendors could reduce latency drastically if there was a desire to. Take RLDRAM-2 from Micron... 20ns latency, slightly larger die. Current cost: 10X the price of DDR2 because the market is so much smaller. I have actually asked DDR2 program managers whether they would make the part 20% lower latency at 5% more cost and they replied "absolutely not". Fact 3: Intel may have an off-chip memory controller, but in a four-socket AMD board, 75% of RAM is attached to an off-chip controller also. 8-way is worse. Conclusion: Winning CPU architectures have been dealing with memory latency for ages. Architectures that work around memory latency, versus needing less of it, will scale better given facts #1 and #2. AMD and Intel have just chosen different bus/cache solutions. They both deal with horrendous memory latencies. AMD added a bunch of pins to their CPU, Intel added a bunch of cache; both add cost. IMHO, AMD's N-way socket story (good due to HT) is hurt by the fact that most memory is now off-chip, while they may not have enough cache to deal with that.