Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation
risc v is very new: https://wiki.debian.org/InstallingDebianOn/SiFive/HiFiveUnleashed
why no ethernet port per default? Freedom U540
From: David Woodhouse Date: Sun Jan 21 2018 - 15:28:51 EST
- Next message: ulrik . debie-os: „Re: [PATCH] Input: trackpoint – force 3 buttons if 0 button is reported“
- Previous message: David Lechner: „[PATCH] mmc: davinci: suppress error message on EPROBE_DEFER“
- In reply to: Andy Lutomirski: „Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation“
- Next in thread: Linus Torvalds: „Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation“
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote: > All of this is pure garbage. > > Is Intel really planning on making this shit architectural? Has > anybody talked to them and told them they are f*cking insane? > > Please, any Intel engineers here - talk to your managers.Â If the alternative was a two-decade product recall and giving everyone free CPUs, I'm not sure it was entirely insane. Certainly it's a nasty hack, but hey â the world was on fire and in the end we didn't have to just turn the datacentres off and go back to goat farming, so it's not all bad.
my comment: that is exactly what Intel OUGHT to do: recall all CPUs of the last 20 years.
IMHO the „motive“ of intel/AMD is pretty clear: „yes we admit our product is flawed – we try to give you a choice: flip the IBRS_ALL bit and get a 20% speed penalty but (probably) fix the security whole. Or leave the whole wide open because your infrastructure is physically shielded against intruders and NOT connected to the internet.“
Another possibility: fire their managers close down and start over under a new name with a new design and a hacking team that tries to constantly break things?
That would be the clean thing to do to save their economic asses uh i mean assets.
But that will not be enough: Intel / AMD / CPU and Hardware manufacturer: To avoid future mistakes follow the UNIX philosophy: 1. Simplify 2. Simplify 3. Simplify – everything.
if you don’t believe me, you might believe: McIlroy:
„We used to sit around in the Unix Room saying, ‚What can we throw out? Why is there this option?‘
It’s often because there is some deficiency in the basic design — you didn’t really hit the right design point.
Instead of adding an option, think about what was forcing you to add that option.“
Never the less errors will be made: If architectural / design errors surface that can not be fixed by software – there should be some kind of recall mechanism, but this is expensive for the producer, so what probably happens is: Make the customer / re-seller bear the risk: If you want to run a Intel based computer, you will have to agree to some disclaimer like on software:
„THIS CPU IS SOLD „AS IS“ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
You are solely responsible for determining the appropriateness of using or redistributing this CPU and assume any risks associated with Your exercise of permissions under this License.“
Means: We don’t know if we just sold you a bunch of crap technology with unfixable security wholes – because this product is so complex – we kind of lost control over it’s quality – so all risk is on YOU!
That is just how mankind is: Apes with complex technology and technology dependent lifestyles that could get out of hand if no learning curve existed: so simplify, simplify, simplify!
Let’s just hope your lifestyle has no unfixable security problems.
Even worse: The monetary system actually might „encourage“ to repeat mistakes such as war – because it is good money for the „hardware“ (weapons) manufacturers.
And that is exactly what Intel will do: Save it’s ass – despite the flood (32 and more) lawsuits.
So Intel tries to sell it’s fix as „security“ and will not compensate the damaged datacenter owners – which probably are forced to rebuy, rebuy, rebuy Intel’s new CPU or go to an alternative CPU manufacturer that does not have this trouble (is there still one? Apple gave up on that… MISTAKE! another reason why monoculture sucks – not only in farming and nature).
Look at traffic: You could go by train, by car or by bus or by airplane or bicycle or horse or elephant or soon: DroneTaxi or Elon’s HyperLoop or simply: walk.
There are basically completely different „methods“ of doing the same thing: travel distances and/or transport stuff.
And thus provide redundancy for the: travel/transport problem.
But redundancy costs money… repeating mistakes does too.
This could be THE CHANCE for alternative CPU manufactureres and maybe even: Open Hardware?
„The RISC-V Foundation says that no currently announced RISC-V CPU is vulnerable to Meltdown and Spectre“
„Until recently, RISC-V hadn’t seen much adoption in industry, but, in the past two years, Nvidia and Western Digital both announced that they would be adopting RISC-V CPUs. In light of the recent Meltdown/Spectre issue, the RISC-V foundation has released a statement on the vulnerabilities’ impact on RISC-V development.“
„As CISC raises too many verification problems, and a closed-source chip design cannot be trusted, the only solution is open-source RISC:“
OpenSPARC T1 is the open source version of the UltraSPARC T1 processor, a multi-core, 64-bit multiprocessor. The UltraSPARC T1 processor with CoolThreads technology was the highest-throughput and most eco-responsible processor ever created when it became available in the UltraSPARC T1 system. It was a breakthrough discovery for reducing data center energy consumption, while dramatically increasing throughput. Its 32 simultaneous processing threads, drawing about as much power as a light bulb, gave customers the best performance per watt of any processor available.
OpenSPARC T1 source components are covered under multiple open source licenses. The majority of OpenSPARC T1 source code is released under the GNU General Public License. GNU General Public License Source based on existing open source projects will continue to be available under their current licenses. Binary programs are released under a binary Software License Agreement.
Is Open Source RISC-V Ready to Take on Intel, AMD, and ARM in the Data Center?
LinuxGizmos.com:“Aside from being open source and customizable, one of the main benefits of RISC-V is that it is fully modern, purpose built, and unburdened with legacy code.“
… but only if we (can) buy it.
Debian supported CPU architectures:
Motorola 680x0: | m68k - Atari | - atari - Amiga | - amiga - 68k Macintosh | - mac - VME | - bvme6000 | - mvme147 | - mvme16x | DEC Alpha | alpha | - generic | - jensen | - nautilus | Sun SPARC | sparc | - sun4cdm | - sun4u The UltraSPARC class systems fall under the sun4u identifier, and are supported using the sun4u set of install images. | ARM and StrongARM | arm | - netwinder | - riscpc | - shark | - lart | IBM/Motorola PowerPC | powerpc - CHRP | - chrp - PowerMac | - powermac, new-powermac - PReP | - prep - APUS | - apus | HP PA-RISC | hppa - PA-RISC 1.1 | - 32 - PA-RISC 2.0 | - 64 | Intel ia64-based | ia64 | MIPS (big endian) | mips - SGI Indy/I2 | - r4k-ip22 | MIPS (little endian) | mipsel - DEC Decstation | - r4k-kn04 | - r3k-kn02 | IBM S/390 | s390 | - tape | - vmrdr
… the mail continues:
As a hack for existing CPUs, it's just about tolerable â as long as it can die entirely by the next generation. So the part is I think is odd is the IBRS_ALL feature, where a future CPU will advertise "I am able to be not broken" and then you have to set the IBRS bit once at boot time to *ask* it not to be broken. That part is weird, because it ought to have been treated like the RDCL_NO bit â just "you don't have to worry any more, it got better". https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
We do need the IBPB feature to complete the protection that retpoline gives us â it's that or rebuild all of userspace with retpoline. We'll also want to expose IBRS to VM guests, since Windows uses it. I think we could probably live without the IBRS frobbing in our own syscall/interrupt paths, as long as we're prepared to live with the very hypothetical holes that still exist on Skylake. Because I like IBRS more... no, let me rephrase... I hate IBRS less than I hate the 'deepstack' and other stuff that was being proposed to make Skylake almost safe with retpoline.
„As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow.“
Damn this guy is a philosopher.