A very small subset of programmers, working with formal verification tools. It's not that we don't know how to write correct code, it's that we don't know how to write correct code cheaply. The seL4 team estimates their development cost at around 30 times that of a state-of-the-art conventional software engineering team with full test coverage that isn't using formal methods. That's not a cost that people are willing to pay for all software, but it is a cost that's easily amortised when it's just for a relatively small set of things in the trusted computing base.
Add to that, a memory model where data races have undefined behaviour combined with a type system that makes it impossible to check for that aliased-xor-mutable property. Complex Go programs are going to end up with far more subtle and difficult to debug problems than C ones.
How come go is slower than java? It compiles to native code and is more low level
Compiling to native code isn't always an advantage. For a trivial example, consider a Java and a Go code fragment that calls the same method on objects of the same type in a loop. In the Go version, because of the AOT compilation model, this will always be a function call unless the compiler can statically prove that the object type is always the same for every possible invocation of the program. The Java version will collect profiling information as it runs, determine that the same method is called every time, and inline it with a cheap check. The JIT'd Java version will be faster.
This even happens within the same language. On Android, Java is first JIT'd and then AOT compiled over night. Most of the time, the AOT version is faster because the compiler can spent several minutes of time (and not worry about power consumption because it only does this when the device is plugged in). In some cases, it's slower because the JIT can optimise for what happens most of the time, wheres the AOT compiler most optimise for what can possibly happen.
I'd also dispute the idea that Go is more low-level than Java. Both are garbage collected, both have dynamic dispatch, both have roughly the same set of primitive types and of intraprocedural flow control constructs.
Network neutrality was the key differentiator between the early ISP and the incumbent OSPs. Services like AOL and CompuServe gave you access to a network and controlled what you could access, how much it cost, and so on. ISPs, in contrast, gave you unprejudiced access to a network that was not within their control. There was no need for network neutrality regulation because network neutrality was the key differentiator for ISPs. Then the OSPs died and the ISPs started wondering whether they could become more OSP-like and more profitable as a result. Network neutrality regulation only began in response to a relatively recent movement by ISPs away from a neutral network being the default stance.
Amazon provided the best price by dumping: they were mocked for 'making a loss on each sale but making it up in volume,' but that allowed them to become the go-to shop for entire categories of things for a lot of people. Now they're not always (or, in my experience, often) the best price, but they are the most convenient.
I bet Intel and AMD pay someone to decap the chips, take die photos and do competitive analysis.
With a modern process, trying to figure out exactly what is happening is incredibly difficult. AMD and Intel don't care what the other is doing, because they have cross-licensing agreements for most things. They care about companies that are making exact clones with stolen copies of the masks, but these are pretty easy to spot. Telling if a branch predictor includes a particular technique that you've patented from a gate-level layout (even if you can get an accurate gate-level description from the decap'd version) is basically impossible, especially when it's combined with other techniques. If you actually want to take them to court, you have to be able to convincingly argue that this happened. It's much easier to patent things that are visible at the ISA level, because then you can just run some code to check.
Proof of correctness is elusive, because it first requires that you specify what 'correctness' means. Processors vulnerable to this would have passed formal verification until recently, because processor vendors explicitly did not consider side channels to be easily exploitable. Now people are scrambling to add things like 'speculative execution must not change any observable aspects of microarchitectural state' to their specs. That's easy to write in English, but defining what 'observable aspects of microarchitectural state' are in a formal specification is really hard (particularly given that temporal aspects are really hard to talk about at all in most existing specification languages). That said, I'm collaborating with a group that is working on some of this.
seL4 (not L4) is actually a really good example. It was about 6 hours between the release of the formally verified microkernel and the first exploit being released. The implementation was correct with regard to the specification, but the specification didn't account for everything. It's worth remembering that Goedel's Incompleteness Theorem basically tells you that this kind of verification is impossible: a sufficiently detailed specification of what 'correct' means will, for any nontrivial system, be more complex than the implementation and must itself be correct for the proof to be useful.
May I assume this variant has exactly the same Meltdown/Spectre-type issues as Intel has with x86 ?
I believe that BOOM is vulnerable to at least some of the variants of Spectre, though I'm not 100% sure. If it doesn't allow speculative execution to fill cache lines (no idea if it does), then it will be harder to exploit. Meltdown specifically requires speculative execution across software interrupts / system calls and I don't know if BOOM does this.
In hindsight, the fact that this kind of speculative execution is a high-bandwidth side channel is not a surprise. A few years ago, I was talking to some of the Apple folk, who found that the new version of their ARM core was much slower on one of their hot paths. It turned out that the old version was speculatively executing the wrong path and causing some data to be faulted into L1 from main memory. The speculated instructions were then quickly cancelled, but the data was in L1 for when they did need it a couple of hundred cycles later. The new core improved the branch predictor, so they weren't taking a small penalty from the mispredicted branch and were instead taking a large penalty from the cache miss later on. Once they figured this out, they could insert a prefetch instruction, but the fact that performance of a later bit of code varied so much based on speculative execution should have been a clue that there were side channels here.
Then what is the advantage ?
Of RISC-V? That there are an increasing number of competing implementations and, because a lot of them are open source, they can cooperate on common components.
Yes, those arrogant Apple people, who write a web browser that, when submitting a form on a web site that contains the line , expect it to support UTF-8. Clearly they should know that forms on this page actually only support 7-bit ASCII plus some random codepage. Those idiots.
The open source version of Slashcode has been forked by Soylent News and is fully unicode compliant. It's the proprietary version that's developed in-house by whoever owns Slashdot this week that doesn't.
It's also more difficult for an open source design. CPU makers generally don't bother too much patenting microarchitectural features, because it's very expensive to stick a competitor's chip under an electron microscope and get enough evidence to convince a court that it's actually infringing. For an open source design, you have access at least to the RTL and so can see very easily and cheaply whether it's infringing. If you wait until your competitor has taped out before sending your C&D, you can maximise their costs.
They're often used for short hops between different Google campuses. A lot of employees come into work on the bus or train, so don't want to have to take a bike with them, but would cycle for short trips rather than drive if there's a convenient bike for them to use.
There's a company here that rents bikes that are just left lying around and are unlocked with a smartphone app. Apparently Google is considering deploying the same sort of thing, but it adds a little bit of overhead for each legitimate user. It's not clear whether adding 30 seconds to each bike trip by an employee is more expensive than replacing 50 bikes a month.
People mostly don't steal them in the sense of taking them home and locking them up or selling them, they steal them in the sense of just grabbing one, cycling where they need to go, and leaving them there. Why spend $50 and be responsible for securing the bike, they think, when there are bicycles everywhere and you can just grab a convenient one whenever you want one.
You can't compare OpenSPARC and RISC-V. OpenSPARC is an implementation of the SPARCv9 ISA. RISC-V is a specification. There are about a dozen open source RISC-V designs now, ranging from simple in-order 32-bit cores to out-of-order superscalar 64-bit cores.
OpenSPARC is the full Verilog implementation of T1 (Niagara) and T2. Unfortunately, both are written in the traditional disposable style of commercial CPU implementations: there are some reusable building blocks, but the general idea is that each CPU design is a complete from-scratch rewrite. Unlike software designs, there's no thought to long-term maintenance or making the designs easier to refactor. Such concerns are often at odds with getting the best possible performance from the current process (the next generation process may have completely different constraints).
In contrast, the reference RISC-V design, Rocket, is written in Chisel, a high-level Scala-derived HDL that can generate Verilog. It is designed to be used to be reusable and this was shown by the Berkeley Out-of-Order Machine (BOOM), which is an out-of-order superscalar design that reuses most of the Rocket core's execution units.
If you just want to send something to a fab now, the OpenSPARC cores are probably better, but if you want to make significant modifications then Rocket or BOOM is orders of magnitude easier to work with. In addition, the RISC-V ecosystem is growing, whereas the SPARC ecosystem is contracting or dead.
It's not the fab costs, it's the ecosystem costs. Getting an OS and a C compiler working with a new ISA is fairly expensive. Getting them working and optimised is more expensive. Now add in tools like debuggers, valgrind, and so on that all have large architecture-dependent aprts. Add in all of the other languages (Java, JavaScript, and so on) that people care about having high-performance JITs for and it's even more. The RISC-V team conservatively estimates the cost of recreating the ARM software ecosystem at $1bn (ARM estimates it at about double that, the reality is probably somewhere in the middle). You can design and fab a small run of chips for a few tens of millions, which is cheap in comparison.
No architecture is vulnerable to Spectre. It is a microarchitectural vulnerability. Any core that performs any speculative execution (i.e. anything pipelined that's not a DSP or GPU) is going to have some side channels related to speculative execution and anything with an out-of-order pipeline will likely be susceptible to Spectre / Meltdown-style attacks (they're not the first side-channel attacks on this kind of thing, but they're worrying because previous ones have let you extract a bit every few seconds, whereas these can run at around 0.5MB/s, making it feasible to scan all of physical memory in a fairly short amount of time).
Actually, it is. IC design is now pretty cheap. IC fabrication, on the other hand, is incredibly expensive, especially on a recent process and especially on low-volume runs.
The reference RISC-V designs are written in Chisel, which is a Scala-based high-level HDL. The Berkeley guys have taped our versions of it at over 1GHz, but only because they have really good deals with some fabs that want Berkeley graduates to go and recommend them to whatever company hires them. Most of the same pipelines are used by BOOM, which is an out-of-order implementation (and is probably vulnerable to Spectre).
There's got to be an energy cost associated with that since you're making it do a bunch of operations it doesn't need to do.
True, to an extent, but not entirely. The difference in power consumption between a CPU executing instructions and a CPU in a pipeline stall is fairly small. The difference between a CPU executing instructions and in a sleep state is a lot higher, so you get better power efficiency if you finish fast and go to sleep.
On wide out-of-order pipelines, you're using a lot of energy just to have the scheduler and register rename units powered. This is why the low-end ARM cores get better performance per Watt than the higher-end ones: they simply omit a large chunk of logic that the more complex cores need.
It's also a case of return on (power / complexity) investment. A simple single-pipeline in-order core may have 8 stages. If you hit a branch and have no branch predictor, then you stall for 8 cycles waiting for an instruction. The common heuristic is that you have a branch every 7 instructions on average, so now we're seeing the pipeline getting about 50% occupancy. That's pretty bad, so you want a branch predictor. Fortunately, a simple one gives you 90% hit rates, so now you're close to being able to dispatch one instruction per cycle. The difference between 90% and 95% is a lot of complexity in the predictor, for little gain. If you can't speculatively execute all instructions (for example, no speculative memory reads or writes) then that doesn't cost you much performance because you're still speculative executing side-effect-free instructions, and you can do that with simple forwarding rather than complex register renaming.
Now compare that with a large out-of-order pipeline, where you can have almost 200 instructions in flight (the authors of the Spectre paper found cases of over 180). With a branch every 7 instructions, you need to correctly predict 25 branches in a row to get full pipeline occupancy. That's a big incentive to spend a lot of transistors on clever branch predictors and speculative execution.
I wouldn't be surprised if we start to see more of a demand for massively multicore in-order processors. If Cavium has any sense, they'll be marketing the hell out of ThunderX to cloud providers this month. The ThunderX has a lot of very simple in-order cores that are unlikely to be vulnerable to this kind of attack, because they don't do much speculative execution. The same is true of the UltraSPARC Tx series: the earlier ones did no speculation, they simply ran another thread when the current one had nothing non-speculative to keep the pipelines fed (I think the later ones did some speculative execution). This kind of design is a lot more efficient in terms of computation per transistor or Watt, but only if your software has enough threads to keep the execution units full.
All out-of-order processors perform speculation. You can't fill an out-of-order pipeline usefully without it and the power, area, and complexity overheads of out-of-order designs are huge so no one is crazy enough to build an out-of-order design that throws away most of the benefit by not doing any speculation. A number of in-order processors do as well, because any pipelined processor that doesn't do some speculative execution is going to have pipeline bubbles and lose a good 20% of its maximum throughput.
The Raspberry Pi uses in-order cores. I don't remember much about the ancient ARM11 on the original, but the newer ones use A7 and A53 cores, which both have very similar pipeline designs. They do perform speculative execution (and they definitely do perform branch prediction - the only pipelined processors that don't are specialised things like DSPs and GPUs), but it appears that the in-flight instruction are cancelled sufficiently early that you never see different execution times depending on which speculative path way taken (only differences between wether speculative execution was correct not).
The core of the Spectre attacks is that you can have speculative execution that has data-dependent timings and then use the timing to tell which of the paths was executed and therefore what the data was. This is generally harder to exploit on in-order processors, because instructions are still executing in the correct order and you typically only have 7-8 cycles between starting to speculate and the instructions being cancelled. That's generally not long enough to satisfy an L1 miss, so it's fairly common to wait before doing an L2 fetch until you know that the instructions won't be cancelled.
Neither the A7 nor the A53 were listed (though the R7 was - I was very surprised to see two realtime cores on the list of things affected by a vulnerability that explicitly relies on nondeterministic execution time). The A8 and A9 were as well, which is also surprising as they're very similar to the A7 and are in-order dual-issue cores.
So your position is that you can't make money laying your own lines...like the company that did it previously.
Correct. A market like this has a huge first-mover advantage. Unless you have very deep pockets and investors that are willing to wait a very long time for a possible return, competing with an incumbent provider basically impossible. There are lots of markets where it's easy to make money as the first person to do something and almost impossible to make money as the second.
Get rid of the monopolies and THEN you can talk about Business models, investments, etc.
Did you miss the part where I'm talking about the UK, where we did that almost 30 years ago? In fact, take a look at pretty much anywhere in Europe and you'll struggle to find a single country where high speeds have come as a result of deregulation. The countries with the highest speeds have them because of government intervention in the markets.
Case in point...Power companies are researching sending signals over the power line. Regardless of where they are at, it's legally conceivable that they would be prevented from using that technology to offer services.
They've been researching it for decades and it's not going to be competitive any decade soon. Power lines are arranged in a bus topology, so any solution will need to allow speeds of at least a hundred times faster than the telcos to be able to provide the same speed to each endpoint, and being able to send signals through a line designed for sending power faster than you can send them over lines designed for sending signal is wishful thinking.
Other options, erecting local WiFi towers. There could be a perfectly viable business case there. But then again, if the Local government won't let it happen then there's no point to even trying.
Again, it is allowed here (well, not WiFi, but things like WiMAX, HSPA, and so on). It will never be competitive in dense areas (any signal encoding technology that lets you send data via a shared-bandwidth medium like broadcast RF will never let you run a signal faster than using the same technology over a direct point-to-point connection like a fibre or a copper wire). They are somewhat attractive in rural areas, where you're looking at a few thousand pounds or more per customer to upgrade the copper to something that will handle decent rates of ADSL (or to lay fibre), but it's hard even there to get the investment because you're looking at fairly small numbers of customers per tower, and those towers are expensive. You need to be able to build the towers for a few hundred pounds per customer to be able to recoup your investments in a reasonable amount of time (even ignoring operating costs).
Indeed. If you are allowing remote attackers to send instruction sequences that your CPU will execute directly, then you have far bigger problems than the f00f bug. Simply causing your computer to crash is probably the least malicious thing that they can do.
Slashdot Mirror
A very small subset of programmers, working with formal verification tools. It's not that we don't know how to write correct code, it's that we don't know how to write correct code cheaply. The seL4 team estimates their development cost at around 30 times that of a state-of-the-art conventional software engineering team with full test coverage that isn't using formal methods. That's not a cost that people are willing to pay for all software, but it is a cost that's easily amortised when it's just for a relatively small set of things in the trusted computing base.
Add to that, a memory model where data races have undefined behaviour combined with a type system that makes it impossible to check for that aliased-xor-mutable property. Complex Go programs are going to end up with far more subtle and difficult to debug problems than C ones.
How come go is slower than java? It compiles to native code and is more low level
Compiling to native code isn't always an advantage. For a trivial example, consider a Java and a Go code fragment that calls the same method on objects of the same type in a loop. In the Go version, because of the AOT compilation model, this will always be a function call unless the compiler can statically prove that the object type is always the same for every possible invocation of the program. The Java version will collect profiling information as it runs, determine that the same method is called every time, and inline it with a cheap check. The JIT'd Java version will be faster.
This even happens within the same language. On Android, Java is first JIT'd and then AOT compiled over night. Most of the time, the AOT version is faster because the compiler can spent several minutes of time (and not worry about power consumption because it only does this when the device is plugged in). In some cases, it's slower because the JIT can optimise for what happens most of the time, wheres the AOT compiler most optimise for what can possibly happen.
I'd also dispute the idea that Go is more low-level than Java. Both are garbage collected, both have dynamic dispatch, both have roughly the same set of primitive types and of intraprocedural flow control constructs.
Actually I think SQL injection probably accounts for a larger share than overflows
I don't have a more recent statistic, but an MSR study from 2012 found that around 70% of all exploited security vulnerabilities are buffer overflows.
Network neutrality was the key differentiator between the early ISP and the incumbent OSPs. Services like AOL and CompuServe gave you access to a network and controlled what you could access, how much it cost, and so on. ISPs, in contrast, gave you unprejudiced access to a network that was not within their control. There was no need for network neutrality regulation because network neutrality was the key differentiator for ISPs. Then the OSPs died and the ISPs started wondering whether they could become more OSP-like and more profitable as a result. Network neutrality regulation only began in response to a relatively recent movement by ISPs away from a neutral network being the default stance.
Amazon provided the best price by dumping: they were mocked for 'making a loss on each sale but making it up in volume,' but that allowed them to become the go-to shop for entire categories of things for a lot of people. Now they're not always (or, in my experience, often) the best price, but they are the most convenient.
I bet Intel and AMD pay someone to decap the chips, take die photos and do competitive analysis.
With a modern process, trying to figure out exactly what is happening is incredibly difficult. AMD and Intel don't care what the other is doing, because they have cross-licensing agreements for most things. They care about companies that are making exact clones with stolen copies of the masks, but these are pretty easy to spot. Telling if a branch predictor includes a particular technique that you've patented from a gate-level layout (even if you can get an accurate gate-level description from the decap'd version) is basically impossible, especially when it's combined with other techniques. If you actually want to take them to court, you have to be able to convincingly argue that this happened. It's much easier to patent things that are visible at the ISA level, because then you can just run some code to check.
Proof of correctness is elusive, because it first requires that you specify what 'correctness' means. Processors vulnerable to this would have passed formal verification until recently, because processor vendors explicitly did not consider side channels to be easily exploitable. Now people are scrambling to add things like 'speculative execution must not change any observable aspects of microarchitectural state' to their specs. That's easy to write in English, but defining what 'observable aspects of microarchitectural state' are in a formal specification is really hard (particularly given that temporal aspects are really hard to talk about at all in most existing specification languages). That said, I'm collaborating with a group that is working on some of this.
seL4 (not L4) is actually a really good example. It was about 6 hours between the release of the formally verified microkernel and the first exploit being released. The implementation was correct with regard to the specification, but the specification didn't account for everything. It's worth remembering that Goedel's Incompleteness Theorem basically tells you that this kind of verification is impossible: a sufficiently detailed specification of what 'correct' means will, for any nontrivial system, be more complex than the implementation and must itself be correct for the proof to be useful.
May I assume this variant has exactly the same Meltdown/Spectre-type issues as Intel has with x86 ?
I believe that BOOM is vulnerable to at least some of the variants of Spectre, though I'm not 100% sure. If it doesn't allow speculative execution to fill cache lines (no idea if it does), then it will be harder to exploit. Meltdown specifically requires speculative execution across software interrupts / system calls and I don't know if BOOM does this.
In hindsight, the fact that this kind of speculative execution is a high-bandwidth side channel is not a surprise. A few years ago, I was talking to some of the Apple folk, who found that the new version of their ARM core was much slower on one of their hot paths. It turned out that the old version was speculatively executing the wrong path and causing some data to be faulted into L1 from main memory. The speculated instructions were then quickly cancelled, but the data was in L1 for when they did need it a couple of hundred cycles later. The new core improved the branch predictor, so they weren't taking a small penalty from the mispredicted branch and were instead taking a large penalty from the cache miss later on. Once they figured this out, they could insert a prefetch instruction, but the fact that performance of a later bit of code varied so much based on speculative execution should have been a clue that there were side channels here.
Then what is the advantage ?
Of RISC-V? That there are an increasing number of competing implementations and, because a lot of them are open source, they can cooperate on common components.
Yes, those arrogant Apple people, who write a web browser that, when submitting a form on a web site that contains the line , expect it to support UTF-8. Clearly they should know that forms on this page actually only support 7-bit ASCII plus some random codepage. Those idiots.
The open source version of Slashcode has been forked by Soylent News and is fully unicode compliant. It's the proprietary version that's developed in-house by whoever owns Slashdot this week that doesn't.
It's also more difficult for an open source design. CPU makers generally don't bother too much patenting microarchitectural features, because it's very expensive to stick a competitor's chip under an electron microscope and get enough evidence to convince a court that it's actually infringing. For an open source design, you have access at least to the RTL and so can see very easily and cheaply whether it's infringing. If you wait until your competitor has taped out before sending your C&D, you can maximise their costs.
They're often used for short hops between different Google campuses. A lot of employees come into work on the bus or train, so don't want to have to take a bike with them, but would cycle for short trips rather than drive if there's a convenient bike for them to use.
There's a company here that rents bikes that are just left lying around and are unlocked with a smartphone app. Apparently Google is considering deploying the same sort of thing, but it adds a little bit of overhead for each legitimate user. It's not clear whether adding 30 seconds to each bike trip by an employee is more expensive than replacing 50 bikes a month.
People mostly don't steal them in the sense of taking them home and locking them up or selling them, they steal them in the sense of just grabbing one, cycling where they need to go, and leaving them there. Why spend $50 and be responsible for securing the bike, they think, when there are bicycles everywhere and you can just grab a convenient one whenever you want one.
OpenSPARC is the full Verilog implementation of T1 (Niagara) and T2. Unfortunately, both are written in the traditional disposable style of commercial CPU implementations: there are some reusable building blocks, but the general idea is that each CPU design is a complete from-scratch rewrite. Unlike software designs, there's no thought to long-term maintenance or making the designs easier to refactor. Such concerns are often at odds with getting the best possible performance from the current process (the next generation process may have completely different constraints).
In contrast, the reference RISC-V design, Rocket, is written in Chisel, a high-level Scala-derived HDL that can generate Verilog. It is designed to be used to be reusable and this was shown by the Berkeley Out-of-Order Machine (BOOM), which is an out-of-order superscalar design that reuses most of the Rocket core's execution units.
If you just want to send something to a fab now, the OpenSPARC cores are probably better, but if you want to make significant modifications then Rocket or BOOM is orders of magnitude easier to work with. In addition, the RISC-V ecosystem is growing, whereas the SPARC ecosystem is contracting or dead.
It's not the fab costs, it's the ecosystem costs. Getting an OS and a C compiler working with a new ISA is fairly expensive. Getting them working and optimised is more expensive. Now add in tools like debuggers, valgrind, and so on that all have large architecture-dependent aprts. Add in all of the other languages (Java, JavaScript, and so on) that people care about having high-performance JITs for and it's even more. The RISC-V team conservatively estimates the cost of recreating the ARM software ecosystem at $1bn (ARM estimates it at about double that, the reality is probably somewhere in the middle). You can design and fab a small run of chips for a few tens of millions, which is cheap in comparison.
No architecture is vulnerable to Spectre. It is a microarchitectural vulnerability. Any core that performs any speculative execution (i.e. anything pipelined that's not a DSP or GPU) is going to have some side channels related to speculative execution and anything with an out-of-order pipeline will likely be susceptible to Spectre / Meltdown-style attacks (they're not the first side-channel attacks on this kind of thing, but they're worrying because previous ones have let you extract a bit every few seconds, whereas these can run at around 0.5MB/s, making it feasible to scan all of physical memory in a fairly short amount of time).
Actually, it is. IC design is now pretty cheap. IC fabrication, on the other hand, is incredibly expensive, especially on a recent process and especially on low-volume runs.
The reference RISC-V designs are written in Chisel, which is a Scala-based high-level HDL. The Berkeley guys have taped our versions of it at over 1GHz, but only because they have really good deals with some fabs that want Berkeley graduates to go and recommend them to whatever company hires them. Most of the same pipelines are used by BOOM, which is an out-of-order implementation (and is probably vulnerable to Spectre).
There's got to be an energy cost associated with that since you're making it do a bunch of operations it doesn't need to do.
True, to an extent, but not entirely. The difference in power consumption between a CPU executing instructions and a CPU in a pipeline stall is fairly small. The difference between a CPU executing instructions and in a sleep state is a lot higher, so you get better power efficiency if you finish fast and go to sleep.
On wide out-of-order pipelines, you're using a lot of energy just to have the scheduler and register rename units powered. This is why the low-end ARM cores get better performance per Watt than the higher-end ones: they simply omit a large chunk of logic that the more complex cores need.
It's also a case of return on (power / complexity) investment. A simple single-pipeline in-order core may have 8 stages. If you hit a branch and have no branch predictor, then you stall for 8 cycles waiting for an instruction. The common heuristic is that you have a branch every 7 instructions on average, so now we're seeing the pipeline getting about 50% occupancy. That's pretty bad, so you want a branch predictor. Fortunately, a simple one gives you 90% hit rates, so now you're close to being able to dispatch one instruction per cycle. The difference between 90% and 95% is a lot of complexity in the predictor, for little gain. If you can't speculatively execute all instructions (for example, no speculative memory reads or writes) then that doesn't cost you much performance because you're still speculative executing side-effect-free instructions, and you can do that with simple forwarding rather than complex register renaming.
Now compare that with a large out-of-order pipeline, where you can have almost 200 instructions in flight (the authors of the Spectre paper found cases of over 180). With a branch every 7 instructions, you need to correctly predict 25 branches in a row to get full pipeline occupancy. That's a big incentive to spend a lot of transistors on clever branch predictors and speculative execution.
I wouldn't be surprised if we start to see more of a demand for massively multicore in-order processors. If Cavium has any sense, they'll be marketing the hell out of ThunderX to cloud providers this month. The ThunderX has a lot of very simple in-order cores that are unlikely to be vulnerable to this kind of attack, because they don't do much speculative execution. The same is true of the UltraSPARC Tx series: the earlier ones did no speculation, they simply ran another thread when the current one had nothing non-speculative to keep the pipelines fed (I think the later ones did some speculative execution). This kind of design is a lot more efficient in terms of computation per transistor or Watt, but only if your software has enough threads to keep the execution units full.
All out-of-order processors perform speculation. You can't fill an out-of-order pipeline usefully without it and the power, area, and complexity overheads of out-of-order designs are huge so no one is crazy enough to build an out-of-order design that throws away most of the benefit by not doing any speculation. A number of in-order processors do as well, because any pipelined processor that doesn't do some speculative execution is going to have pipeline bubbles and lose a good 20% of its maximum throughput.
The Raspberry Pi uses in-order cores. I don't remember much about the ancient ARM11 on the original, but the newer ones use A7 and A53 cores, which both have very similar pipeline designs. They do perform speculative execution (and they definitely do perform branch prediction - the only pipelined processors that don't are specialised things like DSPs and GPUs), but it appears that the in-flight instruction are cancelled sufficiently early that you never see different execution times depending on which speculative path way taken (only differences between wether speculative execution was correct not).
The core of the Spectre attacks is that you can have speculative execution that has data-dependent timings and then use the timing to tell which of the paths was executed and therefore what the data was. This is generally harder to exploit on in-order processors, because instructions are still executing in the correct order and you typically only have 7-8 cycles between starting to speculate and the instructions being cancelled. That's generally not long enough to satisfy an L1 miss, so it's fairly common to wait before doing an L2 fetch until you know that the instructions won't be cancelled.
Neither the A7 nor the A53 were listed (though the R7 was - I was very surprised to see two realtime cores on the list of things affected by a vulnerability that explicitly relies on nondeterministic execution time). The A8 and A9 were as well, which is also surprising as they're very similar to the A7 and are in-order dual-issue cores.
So your position is that you can't make money laying your own lines...like the company that did it previously.
Correct. A market like this has a huge first-mover advantage. Unless you have very deep pockets and investors that are willing to wait a very long time for a possible return, competing with an incumbent provider basically impossible. There are lots of markets where it's easy to make money as the first person to do something and almost impossible to make money as the second.
Get rid of the monopolies and THEN you can talk about Business models, investments, etc.
Did you miss the part where I'm talking about the UK, where we did that almost 30 years ago? In fact, take a look at pretty much anywhere in Europe and you'll struggle to find a single country where high speeds have come as a result of deregulation. The countries with the highest speeds have them because of government intervention in the markets.
Case in point...Power companies are researching sending signals over the power line. Regardless of where they are at, it's legally conceivable that they would be prevented from using that technology to offer services.
They've been researching it for decades and it's not going to be competitive any decade soon. Power lines are arranged in a bus topology, so any solution will need to allow speeds of at least a hundred times faster than the telcos to be able to provide the same speed to each endpoint, and being able to send signals through a line designed for sending power faster than you can send them over lines designed for sending signal is wishful thinking.
Other options, erecting local WiFi towers. There could be a perfectly viable business case there. But then again, if the Local government won't let it happen then there's no point to even trying.
Again, it is allowed here (well, not WiFi, but things like WiMAX, HSPA, and so on). It will never be competitive in dense areas (any signal encoding technology that lets you send data via a shared-bandwidth medium like broadcast RF will never let you run a signal faster than using the same technology over a direct point-to-point connection like a fibre or a copper wire). They are somewhat attractive in rural areas, where you're looking at a few thousand pounds or more per customer to upgrade the copper to something that will handle decent rates of ADSL (or to lay fibre), but it's hard even there to get the investment because you're looking at fairly small numbers of customers per tower, and those towers are expensive. You need to be able to build the towers for a few hundred pounds per customer to be able to recoup your investments in a reasonable amount of time (even ignoring operating costs).
Indeed. If you are allowing remote attackers to send instruction sequences that your CPU will execute directly, then you have far bigger problems than the f00f bug. Simply causing your computer to crash is probably the least malicious thing that they can do.