Meltdown and Spectre will have made second hand machines completely worthless unless there is a clear path to a fixed CPU. Sure you would stick with the one you have with a performance cut, but you are not going to spend real money on a system you know is duff if you can hang on and see how this mess pans out.
While Intel are compensating us, they can compensate us for killing the second hand value too.
In words of one syllable: NO. Brick is not a synonym for break in English (except maybe in your house), and most definitely not in relation to computer systems.
if you have to press a key during the boot process to bring up a boot menu and select the previous kernel, then it's bricked.
No. That is trashed, but not bricked. Bricked is when it is not recoverable by means available to members of the general public - not just "stupid Lusers". Bricked is not just when it won't boot a bootable image, but when it does not even appear to try.
I want a pet Unicorn too, but I don't expect they will be free.
All my Intel processors are out of warranty, and that must be true for a humongous number of people. Since my processors are out of warranty, I don't expect a free replacement - I expect a low cost replacement. The cost to me of replacing the machines would be huge, so I am happy to pay (say $50) for a plug in replacement that ups the performance to what can be achieved in the same socket with today's technology. There is no point in forcing Intel to re-engineer old architectures - that benefits no one.
If Intel are not going to supply paid replacements at reasonable cost, then I expect them to be forced to supply for free all necessary info to anyone else who wishes to make and sell replacements to me on pain of jailing every single shareholder.
If they are not willing to co-operate with their customers in producing an equitable fix, the whole lot of them are guilty of unjust enrichment, obtaining pecuniary advantage by deception, fraud, conspiracy to defraud, and anything else a bunch of greedy corporate lawyers can invent.
If Intel goes bust as a result of this, we can expect the official receiver to sell off the patents to someone who will sell us cheaper and more reliable processors (probably not Cyrix).
Intel need to be wetting their knickers at the very least.
If your recollection is correct it wouldn't matter. You could take a nap and awake later to find Yggdrasil installed, rebooted and waiting for you to login.
^^^ This.
Yggdrasil worked on all the kit I tried it on. Most other distros failed in some incomprehensible manner.
OTOH the various BSDs all worked just the same way they had on the VAX at work, although I seem to recall OpenBSD needing rather less RAM than the others, but lacking some tool I wanted, so I switched to FreeBSD, and have been using it ever since (about 1988, I would think).
if you ask the janitor or your kid to click the install button, you're technically in the clear.
However, in order not to infringe the janitor's human rights, you might wish to employ a team of cats trained in keyboard skills. (check Youtube for details).
In a cat vs Nvidia lawsuit, I would expect that cat to land on its feet.
Future generations of hardware and software will need a fundamentally different approach to design and verification.
No - mostly we need illegal accesses to kernel mode memory to hare the result substituted with a value like 0xf00l like used to be done in the old days, and for a hardware signal to purge all speculative results during the "retire" instead of a allowing them to hang around.
I suspect that careful investigation will result in a few more cache refreshes, and pipeline flushing than we have now - but it won't cost more than 1% of performance, and will be a permanent fix for these problems.
Hopefully, people have learned that you need to check for security breaches even when you think the change is "more of the same".
I have never used an SGI machine at all, and only used MIPS in embedded machines. However, someone needs to tell Lenovo that the present situation is opening the way for massive sales of a MIPS based Thinkpad and they have the leverage to get a new iteration of Loongson and sell it in the volume needed to be profitable - hopefully by putting it in a T5xx case with a great screen.
Loongson has targeted cheap - now is the opportunity to go up market by the targeting secure and open source markets.
MIPS is basically a good architecture, and Lenovo has a good grip on how to do volume and quality.
Secure, Open source, Volume and Quality markets: they surely should get volume from that while Intel is out of the running - and even when Intel do produce a CPU that is slightly secure, they still have the ME and trust issues! It might be a big window of opportunity - And Lenovo buying Chinese and selling in the west should be politically supported and cheap.
We have to hope that they understand NOT to go cheap on this - the cheap market won't care about quality, and
will want spyware^H^H^H^H^HWindows. I normally use OpenBSD, but would try Octane if it was available - I know other people who like it.
Loongson produce a MIPS (open source) based CPU with an open source BIOS, and laptops are available. They just need a new iteration to get the performance up to near western standards, and make a ton of them. There are laptops available too! (Just not in the West).
DECUS would have a lot different view about DEC and open source. DEC actively encouraged open source in the form it took in the PDP11 days. I don't know about later.
I give you that Ken Olsen said "Unix is snake oil" but that was not because it was open source - it wasn't then.
And he refused to port VMS to the 486 - which would not have been that difficult technically, but that has nothing to do with open source either.
Sun, OTOH has behaved disgracefully, and all I can say in their defence is they were not as bad as Oracle - but then it is arguable whether Satan is as bad as Oracle.
The fact is that they could probably charge for the replacements if they enhance the performance of the old system. I would be happy to pay $30 to replace my core2duos with a plug compatible something that offered twice the performance. Give the size of the market, that should be very profitable for Intel.
"You MUST by my chip, it will cost you $30" is a business even Al Capone could be happy with.
I'm guessing you don't work on this stuff do you...
Well your guess is partly right. I am retired now. However, I did work designing CPUs, and I was specifically employed to debug pipelining snafus, so yes, I do know something about the subject. (I did not work for Intel).
The "training on other threads' data" is not in itself a very serious security issue, but it is certainly an information leak between threads, and would probably be acceptable if the data leaked was the value of a random byte, as it might have been 20 years ago.
The problem here is serious because this situation allows deliberate (mis-)training of performance in the other guy's thread! - That is not what is being complained about in Meltdown or Spectre and is not necessarily a security risk, but it is not good news if some-one else's C library calls can screw the performance of my thread. Meltdown specifically describes shared C libraries as a source of predictable data to screw with.
In the present situation, where the CPU speculatively executes hundreds of instructions at a time, it gives a massive surface of attack which simply should not be there.
I give you "designers working in isolation" is going to lead to trouble, as is too much focus on schedule, but re-using vhdl blocks you don't understand counts as idiot behaviour in my books - although re-using blocks you know are "a bit iffy" is possibly worse: people must have known that kernel memory could be accessed speculatively. I would not have knowingly bought a processor that allowed that for cloud type uses. There is a risk of billion dollar law suits involved.
As I have said elsewhere, I would expect reading the pipeline contents for speculative execution that is abandoned to be restricted to (a) kernel mode, AND (b) only when in a debug mode. There simply should not be a way for user mode threads to see this data at all in normal operation - it is only needed to debug the speculative execution engine. I would not expect the data to be able to leave the CPU in normal operation. In fact, I would expect to need jtag to read it. The car analogy is driving your van away with the back doors open. Sure, the parcels might not fall out! (Just because its still your thread does not mean you want an information leak: this is the browser risk).
Slashdot Mirror
What does that mean? its not English, so you can't blame the spelling corrector, and bulky my be true, but is not relevant here.
While Intel are compensating us, they can compensate us for killing the second hand value too.
- so not much use at all!
10% wasting in electricity means the data centre will pay 10% more on electricity cash each year.
10% extra cost to the data centre means you will pay 20% more cash each year.
Turn it off? Surely this is a case for nuking from high orbit!
YMMV
No. That is trashed, but not bricked. Bricked is when it is not recoverable by means available to members of the general public - not just "stupid Lusers". Bricked is not just when it won't boot a bootable image, but when it does not even appear to try.
No: it would appear the standard alternative to a best effort is to make a fairly pathetic, half-assed effort.
No spin needed - if MS says its screwed, you should probably bet your shirt on it!
All my Intel processors are out of warranty, and that must be true for a humongous number of people. Since my processors are out of warranty, I don't expect a free replacement - I expect a low cost replacement. The cost to me of replacing the machines would be huge, so I am happy to pay (say $50) for a plug in replacement that ups the performance to what can be achieved in the same socket with today's technology. There is no point in forcing Intel to re-engineer old architectures - that benefits no one.
If Intel are not going to supply paid replacements at reasonable cost, then I expect them to be forced to supply for free all necessary info to anyone else who wishes to make and sell replacements to me on pain of jailing every single shareholder.
If they are not willing to co-operate with their customers in producing an equitable fix, the whole lot of them are guilty of unjust enrichment, obtaining pecuniary advantage by deception, fraud, conspiracy to defraud, and anything else a bunch of greedy corporate lawyers can invent.
If Intel goes bust as a result of this, we can expect the official receiver to sell off the patents to someone who will sell us cheaper and more reliable processors (probably not Cyrix).
Intel need to be wetting their knickers at the very least.
^^^ This.
Yggdrasil worked on all the kit I tried it on. Most other distros failed in some incomprehensible manner.
OTOH the various BSDs all worked just the same way they had on the VAX at work, although I seem to recall OpenBSD needing rather less RAM than the others, but lacking some tool I wanted, so I switched to FreeBSD, and have been using it ever since (about 1988, I would think).
The OP is probably planning to write a TCP/IP stack in Javascript, but they will use Agile, so pay no attention.
Because it is not American.
FTFY
Because you like being spied on?
However, in order not to infringe the janitor's human rights, you might wish to employ a team of cats trained in keyboard skills. (check Youtube for details).
In a cat vs Nvidia lawsuit, I would expect that cat to land on its feet.
No - mostly we need illegal accesses to kernel mode memory to hare the result substituted with a value like 0xf00l like used to be done in the old days, and for a hardware signal to purge all speculative results during the "retire" instead of a allowing them to hang around.
I suspect that careful investigation will result in a few more cache refreshes, and pipeline flushing than we have now - but it won't cost more than 1% of performance, and will be a permanent fix for these problems.
Hopefully, people have learned that you need to check for security breaches even when you think the change is "more of the same".
Loongson has targeted cheap - now is the opportunity to go up market by the targeting secure and open source markets.
MIPS is basically a good architecture, and Lenovo has a good grip on how to do volume and quality.
Secure, Open source, Volume and Quality markets: they surely should get volume from that while Intel is out of the running - and even when Intel do produce a CPU that is slightly secure, they still have the ME and trust issues! It might be a big window of opportunity - And Lenovo buying Chinese and selling in the west should be politically supported and cheap.
We have to hope that they understand NOT to go cheap on this - the cheap market won't care about quality, and will want spyware^H^H^H^H^HWindows. I normally use OpenBSD, but would try Octane if it was available - I know other people who like it.
Isn't this the ARM that is susceptible to both Meltdown AND Spectre?
Loongson produce a MIPS (open source) based CPU with an open source BIOS, and laptops are available. They just need a new iteration to get the performance up to near western standards, and make a ton of them. There are laptops available too! (Just not in the West).
You might want to read all the stuff about Meltdown!
The MMU is supposed to keep each thread's data private
I give you that Ken Olsen said "Unix is snake oil" but that was not because it was open source - it wasn't then. And he refused to port VMS to the 486 - which would not have been that difficult technically, but that has nothing to do with open source either.
Sun, OTOH has behaved disgracefully, and all I can say in their defence is they were not as bad as Oracle - but then it is arguable whether Satan is as bad as Oracle.
Yes - that is what Javascript is!
"You MUST by my chip, it will cost you $30" is a business even Al Capone could be happy with.
Well your guess is partly right. I am retired now. However, I did work designing CPUs, and I was specifically employed to debug pipelining snafus, so yes, I do know something about the subject. (I did not work for Intel).
The "training on other threads' data" is not in itself a very serious security issue, but it is certainly an information leak between threads, and would probably be acceptable if the data leaked was the value of a random byte, as it might have been 20 years ago.
The problem here is serious because this situation allows deliberate (mis-)training of performance in the other guy's thread! - That is not what is being complained about in Meltdown or Spectre and is not necessarily a security risk, but it is not good news if some-one else's C library calls can screw the performance of my thread. Meltdown specifically describes shared C libraries as a source of predictable data to screw with.
In the present situation, where the CPU speculatively executes hundreds of instructions at a time, it gives a massive surface of attack which simply should not be there.
I give you "designers working in isolation" is going to lead to trouble, as is too much focus on schedule, but re-using vhdl blocks you don't understand counts as idiot behaviour in my books - although re-using blocks you know are "a bit iffy" is possibly worse: people must have known that kernel memory could be accessed speculatively. I would not have knowingly bought a processor that allowed that for cloud type uses. There is a risk of billion dollar law suits involved.
As I have said elsewhere, I would expect reading the pipeline contents for speculative execution that is abandoned to be restricted to (a) kernel mode, AND (b) only when in a debug mode. There simply should not be a way for user mode threads to see this data at all in normal operation - it is only needed to debug the speculative execution engine. I would not expect the data to be able to leave the CPU in normal operation. In fact, I would expect to need jtag to read it. The car analogy is driving your van away with the back doors open. Sure, the parcels might not fall out! (Just because its still your thread does not mean you want an information leak: this is the browser risk).