An oldie, but a goodie.
So much quality software out there that is either open source, or written in a VM language, or both that it boggles the mind as to why we are still munching on this particular shit sandwich.
But what do I know?
A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
31–40 of 41 posts
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#32x86 has had a good run. But it's time for it to go. I'm hopeful for RISC-V.
I'm putting my bets on Mill winning the race eventually. Not only Mill, Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough). IMO these ISA's are the future, compilers and programming languages are nowadays smart enough to be able to figure out how to handle VLIW compilation (plus having learned from Itanium's failures).
>Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough).
VLIW isn't going anywhere. Generating code for VLIW isn't getting any easier anytime soon, and the complexity doesn't help the formal proofing that's become a must thanks to data protection requirements of the current world.
If we've learned anything in the past decades, it'd be that RISC is the only valid approach going forward.
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#33Earlier quoted context omitted.
"please don't spread misinformation" followed by confirming that all the mis-features I mentioned exist? (just that you disagree about them being mis-features) How can I run Linux on RISC-V portably without having to implement the SBI?
You said: > It has an SMM equivalent, It really doesn't. It has an open source layer under supervisor mode which works with the OS. This is very different from Intel SMM, a closed source blob that acts against the interests of the OS and the end user. > a separate hypervisor mode (instead of full orthogonality which lets you get away without one), As others pointed out also, this is plain wrong. > resident firmware c…
> This is very different from Intel SMM, a closed source blob that acts against the interests of the OS and the end user.
I'm not talking about implementations (there are open source SMM implementations that act against no-one's interest), but about the mechanism. The mere presence is enough that you'll see a closed source blob on RISC-V soon enough, and it won't be friendly.
The only way out is not to have that mechanism in the first place but by making it part of the architecture (instead of some vendor addition because they couldn't get the chip to work in any other way), it's guaranteed to stay.
> As others pointed out also, [getting away without hypervisor mode] is plain wrong.
Only if you want to deprive usermode from secondary page table capabilities. Instead of making it a separate mode, make it an optimized instruction and even "virtual hypervisor" would be relatively efficient (two invocations of that instruction, instead of one invocation plus a software implementation).
> As explained, it has an open source machine mode
And as explained, it doesn't matter that the early hackers have some open source code. If RISC-V ever takes off (and given how invested you seem to be in it, you probably want that?), it won't stay that way.
SiFive only had to give in this time because the market isn't mature yet. That will change.
>> without having to implement the SBI?
> Why would you want to?
Because I don't want anything to happen outside the OS' control. Why can't M mode be left for dead on systems that mostly run in supervisor/user mode? Jump in supervisor, returning into M mode incurs a cold reset or trap (ie. Don't Do It). No SBI.
One of those decisions that will come to haunt RISC-V.
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#34Earlier quoted context omitted.
I'm putting my bets on Mill winning the race eventually. Not only Mill, Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough). IMO these ISA's are the future, compilers and programming languages are nowadays smart enough to be able to figure out how to handle VLIW compilation (plus having learned from Itanium's failures).
>Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough). VLIW isn't going anywhere. Generating code for VLIW isn't getting any easier anytime soon, and the complexity doesn't help the formal proofing that's become a must thanks to data protection requirements of the current world. If we've learned anything in the past decades, it'd be that RISC is the only valid approach going forw…
There is a lot of research in VLIW even in the modern days and there is a lot of VLIW hardware out there (DSPs, Russian Hardware, Microcontrollers, etc.)
RISC is not the one-true-way and I don't think there is evidence for that. x86 is at this point an overburdened platform so any alternative that is fresh, so to speak, is viable.
RISC is maybe the way forward in the short term as it is more similar to CISC.
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#35Earlier quoted context omitted.
I believe you have to pay royalties for Arm while RISC-V is completely open source.
The royalties aren't generally a big deal, being something like 2%. It's other issues, like complexity or startup fees or flat out being unable to get a license.
This. The world would be different, and probably better, if Samsung, Apple and other third parties could make their own x86 processors.
What's the situation regarding this for Mill/VLIW?
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#36Earlier quoted context omitted.
The royalties aren't generally a big deal, being something like 2%. It's other issues, like complexity or startup fees or flat out being unable to get a license.
This. The world would be different, and probably better, if Samsung, Apple and other third parties could make their own x86 processors. What's the situation regarding this for Mill/VLIW?
VLIW in its pure form is old enough that anybody should be legally able to build an ISA based on that concept.
The Mill folks are heavily into patents for their tech: https://millcomputing.com/patents/. So besides Mill's general feasibility it depends on how they work those patents.
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#37Earlier quoted context omitted.
You said: > It has an SMM equivalent, It really doesn't. It has an open source layer under supervisor mode which works with the OS. This is very different from Intel SMM, a closed source blob that acts against the interests of the OS and the end user. > a separate hypervisor mode (instead of full orthogonality which lets you get away without one), As others pointed out also, this is plain wrong. > resident firmware c…
> This is very different from Intel SMM, a closed source blob that acts against the interests of the OS and the end user. I'm not talking about implementations (there are open source SMM implementations that act against no-one's interest), but about the mechanism. The mere presence is enough that you'll see a closed source blob on RISC-V soon enough, and it won't be friendly. The only way out is not to have that mech…
Companies using any ISA can add secret or closed extensions. That is simply outside the scope of an ISA specification.
If you want to ensure there is no secret stuff in your chip you'd better be prepared to create your own designs and manufacture them in your own foundry. RISC-V would still be an excellent starting point.
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#38Earlier quoted context omitted.
> This is very different from Intel SMM, a closed source blob that acts against the interests of the OS and the end user. I'm not talking about implementations (there are open source SMM implementations that act against no-one's interest), but about the mechanism. The mere presence is enough that you'll see a closed source blob on RISC-V soon enough, and it won't be friendly. The only way out is not to have that mech…
Companies using any ISA can add secret or closed extensions. That is simply outside the scope of an ISA specification. If you want to ensure there is no secret stuff in your chip you'd better be prepared to create your own designs and manufacture them in your own foundry. RISC-V would still be an excellent starting point.
Extensions are fair game, of course. As is not buying chips with closed extensions.
But designing the hooks for anti-user binary blobs into the ISA just encourages misbehavior as soon as they can get away with it.
RISC-V code in privileged and protected pockets of the systems is so much easier to design, maintain and update than ISA extensions that I consider that the bigger problem due to its future ubiquity.
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#39Earlier quoted context omitted.
Companies using any ISA can add secret or closed extensions. That is simply outside the scope of an ISA specification. If you want to ensure there is no secret stuff in your chip you'd better be prepared to create your own designs and manufacture them in your own foundry. RISC-V would still be an excellent starting point.
Extensions are fair game, of course. As is not buying chips with closed extensions. But designing the hooks for anti-user binary blobs into the ISA just encourages misbehavior as soon as they can get away with it. RISC-V code in privileged and protected pockets of the systems is so much easier to design, maintain and update than ISA extensions that I consider that the bigger problem due to its future ubiquity.
The machine mode is there for a very good reasons of microarchitecture design scalability, allowing the same machine model to be presented to the operating system with everything from tiny designs to everything-in-hardware. In all existing designs it is open source. It's quite reasonable to have this explicit layer, since in many other cases it has been hidden away (think: Transmeta, or many x86 emulators).
Re: A survey of attacks against Intel x86 over last 10 years (2015) [pdf]
#40Earlier quoted context omitted.
>Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough). VLIW isn't going anywhere. Generating code for VLIW isn't getting any easier anytime soon, and the complexity doesn't help the formal proofing that's become a must thanks to data protection requirements of the current world. If we've learned anything in the past decades, it'd be that RISC is the only valid approach going forw…
There is a lot of research in VLIW even in the modern days and there is a lot of VLIW hardware out there (DSPs, Russian Hardware, Microcontrollers, etc.) RISC is not the one-true-way and I don't think there is evidence for that. x86 is at this point an overburdened platform so any alternative that is fresh, so to speak, is viable. RISC is maybe the way forward in the short term as it is more similar to CISC.
For general purpose code (that is, not DSP's and the like), Intel, HP, and whoever else they managed to suck into their vortex of doom, made a zillion $$$ bet on VLIW, and ultimately it all belly-flopped. Not just some academic paper, but working high end silicon on a leading edge process, big investments in compilers, and whatnot.
Why would it be different the next time?