7 ms·

A survey of attacks against Intel x86 over last 10 years (2015) [pdf]

86 points by DoctorBit 8y ago

snvzz 8y ago
x86 has had a good run. But it's time for it to go. I'm hopeful for RISC-V.
- TomMarius 8y ago
  Why RISC-V and not e.g. Arm? Why is RISC-V better than x86 from AMD? Serious questions, I have no idea about these topics and would love to learn more.
  - NiLSPACE 8y ago
    I believe you have to pay royalties for Arm while RISC-V is completely open source.
    - Dylan16807 8y ago
      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.
      - tormeh 8y ago
        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?
        pgeorgi 8y ago
        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/ https://millcomputing.com/patents/. So besides Mill's general feasibility it depends on how they work those patents.
  - loup-vaillant 8y ago
    RISC-V is simpler, and easier to implement. Instruction density is very good with the compressed extension, and is applicable to many niches, from in-order low power embedded cores, to high performance out of order desktop CPUs. We can expect marginal improvements over x86 and ARM across the board. On the other hand, it is not finished. A number of extensions have yet to be frozen, and we're just beginning to see commercial processors (I mean, where the ISA is exposed to the end user. NVIDIA already uses RISC-V internally).
- pgeorgi 8y ago
  RISC-V inherited all the bad ideas of x86 by now. It has an SMM equivalent, a separate hypervisor mode (instead of full orthogonality which lets you get away without one), resident firmware code outside the OS' control, ...
  - cpeterso 8y ago
    Is there a different ISA that you would have preferred to see as the basis for an open hardware industry?
  - baobrien 8y ago
    > separate hypervisor mode RISC-V, without the hypervisor extension, meets the requirements for Popek-Goldberg virtualization, unlike x86. The problem is that classic virtualization requires shadow paging for memory virtualization, which can be slow. The hypervisor extension (not yet finalized) only adds two level nested paging, a few shadow CSRs, and IIRC a few more interrupt handling registers. The hypervisor extension itself is virtualizable (again, with shadow page tables).
    - pgeorgi 8y ago
      > a few shadow CSRs Right, I forgot about RISC-V's MSR equivalent - with a worse assembler implementation (though that's simple to fix without touching the ISA) since the standard assembly expects them to be names, not numbers (that can be #defined away to names). I had a (very emphatically not) fun time updating coreboot's toolchain and code base in lock step to ensure that risc-v code remained compilable when these changed.
  - rwmj 8y ago
    Please don't spread misinformation. RISC-V has a well-thought out machine layer which is open source in all existing implementations[1]. You can easily modify the M layer if it's interfering with the performance or security of your OS. The virtualization extension hasn't been finalized (but they are working with key KVM people), but it will perform a lot better than a theoretically pure self-virtualizable ISA. [1] https://github.com/riscv/riscv-pk https://github.com/riscv/riscv-pk
- zaarn 8y ago
  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).
  - AstralStorm 8y ago
    No they really cannot. Many of the optimizations CPU do on the fly are akin to JIT recompilers. (in microcode and schedule side) These cannot be effectively done ahead of time yet, at least not without an instruction accurate profiling. Not to mention VLIW wastes CPU instruction cache for instructions that aren't ran. It is no accident that CPUs and compilers gravitated towards RISC.
    - zaarn 8y ago
      Well, no, point of VLIW is that instead of doing it like a JIT recompiler you do it like a slow recompiler. This is almost always possible and can be done ahead of time. Proof: The CPU itself does it under time constraint, a compiler should be capable of the same minus time constraint. VLIW also doesn't really waste instruction cache if your compiler is being smart and aligns branches to an instruction word, though you still blow the pipeline on a branch if you miss but atleast in Microsofts case they include a way for the compiler to include a prediction which it is arguably in a better position to make. This goes double if you use profiling-guided optimization. If the claims of the Mill guys are true then even the "wasted CPU instruction cache" doesn't hurt performance. CPUs and compilers are gravitating towards lots of things. x86 and ARM aren't the only instruction set. VLIW is healthy and very alive on a lot of DSPs. There are Russian CPUs that use VLIWs in active use. AMD GPUs used VLIW for a while (and some variants still do). You can even get VLIW-based Microcontrollers for cheap. IMO compilers and CPUs may gravitate towards RISC in the shortterm as it is more similar to CISC in terms of complexity. VLIW needs compilers to be smart and languages to be smart too for optimal use. Rust for example would be capable of really taking advantage of VLIW but LLVM doesn't support that complexity (yet, though there is some work). In the long term, so my prediction, VLIW will dominate by nature of being simpler, faster and more efficient.
- PDoyle 8y ago
  Nice, I hadn't looked at RISC-V before. The operation of FENCE.I scares me a little: > FENCE.I does not ensure that other RISC-V harts’ instruction fetches will observe the local hart’s stores in a multiprocessor system. To make a store to instruction memory visible to all RISC-V harts, the writing hart has to execute a data FENCE before requesting that all remote RISC-V harts execute a FENCE.I Yikes. That sounds cumbersome for multithreaded code patching systems, like modern JIT compilers. (A "hart" here is a hardware thread.) Sounds like all threads must poll periodically to check whether they should run a FENCE.I, and when they do so, they report that they've done it. Doesn't sound like a lot of fun to implement, though maybe better in software than hardware?
  - rwmj 8y ago
    I don't know enough to say if this is accurate or not. However there are working groups reviewing the memory model[1] (also implementing fast ISRs[2]) so if there are performance problems in this area then they're being looked at. [1] https://content.riscv.org/wp-content/uploads/2018/05/14.25-15.00-RISCVMemoryModelTutorial.pdf https://content.riscv.org/wp-content/uploads/2018/05/14.25-1... https://content.riscv.org/wp-content/uploads/2018/05/10.40-10.55-Daniel-Lustig.pdf https://content.riscv.org/wp-content/uploads/2018/05/10.40-1... [2] https://content.riscv.org/wp-content/uploads/2018/05/08.45-09.10-RISCV-20180509-FastInts.pdf https://content.riscv.org/wp-content/uploads/2018/05/08.45-0...
lioeters 8y ago
[PDF] (2015) - Probably better without the URL hash. Still relevant..
okket 8y ago
Previous discussion from 3 years ago: https://news.ycombinator.com/item?id=10458318 https://news.ycombinator.com/item?id=10458318 (169 comments)
vages 8y ago
Be courteous and add a (2015) to the title.
stakhanov 8y ago
...if I have to endure one more abuse of the "considered harmful" idiom, I'm going to puke.
- kuroguro 8y ago
  Puking is considered harmful.
- earenndil 8y ago
  You'll like this, then https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
- nailer 8y ago
  I feel that - normally it's hyperbole - but a full Minix OS with an IP stack we don't have control over on all our servers is actually pretty harmful.
jhoechtl 8y ago
Words are not enough to express my deep and profound disgust of all those morons abusing "... considered harmful". It's somewhat ok, if it was brought up years ago and counts as legacy. But for any new abuse all I find are the words of Honeybunny https://genius.com/Tim-roth-pumpkin-and-honey-bunny-annotated https://genius.com/Tim-roth-pumpkin-and-honey-bunny-annotate...
jstewartmobile 8y ago
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?

86 points by DoctorBit 8y ago

snvzz 8y ago

x86 has had a good run. But it's time for it to go. I'm hopeful for RISC-V.

TomMarius 8y ago
Why RISC-V and not e.g. Arm? Why is RISC-V better than x86 from AMD? Serious questions, I have no idea about these topics and would love to learn more.
- NiLSPACE 8y ago
  I believe you have to pay royalties for Arm while RISC-V is completely open source.
  - Dylan16807 8y ago
    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.
    - tormeh 8y ago
      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?
      - pgeorgi 8y ago
        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/ https://millcomputing.com/patents/. So besides Mill's general feasibility it depends on how they work those patents.
- loup-vaillant 8y ago
  RISC-V is simpler, and easier to implement. Instruction density is very good with the compressed extension, and is applicable to many niches, from in-order low power embedded cores, to high performance out of order desktop CPUs. We can expect marginal improvements over x86 and ARM across the board. On the other hand, it is not finished. A number of extensions have yet to be frozen, and we're just beginning to see commercial processors (I mean, where the ISA is exposed to the end user. NVIDIA already uses RISC-V internally).
pgeorgi 8y ago
RISC-V inherited all the bad ideas of x86 by now. It has an SMM equivalent, a separate hypervisor mode (instead of full orthogonality which lets you get away without one), resident firmware code outside the OS' control, ...
- cpeterso 8y ago
  Is there a different ISA that you would have preferred to see as the basis for an open hardware industry?
- baobrien 8y ago
  > separate hypervisor mode RISC-V, without the hypervisor extension, meets the requirements for Popek-Goldberg virtualization, unlike x86. The problem is that classic virtualization requires shadow paging for memory virtualization, which can be slow. The hypervisor extension (not yet finalized) only adds two level nested paging, a few shadow CSRs, and IIRC a few more interrupt handling registers. The hypervisor extension itself is virtualizable (again, with shadow page tables).
  - pgeorgi 8y ago
    > a few shadow CSRs Right, I forgot about RISC-V's MSR equivalent - with a worse assembler implementation (though that's simple to fix without touching the ISA) since the standard assembly expects them to be names, not numbers (that can be #defined away to names). I had a (very emphatically not) fun time updating coreboot's toolchain and code base in lock step to ensure that risc-v code remained compilable when these changed.
- rwmj 8y ago
  Please don't spread misinformation. RISC-V has a well-thought out machine layer which is open source in all existing implementations[1]. You can easily modify the M layer if it's interfering with the performance or security of your OS. The virtualization extension hasn't been finalized (but they are working with key KVM people), but it will perform a lot better than a theoretically pure self-virtualizable ISA. [1] https://github.com/riscv/riscv-pk https://github.com/riscv/riscv-pk
zaarn 8y ago
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).
- AstralStorm 8y ago
  No they really cannot. Many of the optimizations CPU do on the fly are akin to JIT recompilers. (in microcode and schedule side) These cannot be effectively done ahead of time yet, at least not without an instruction accurate profiling. Not to mention VLIW wastes CPU instruction cache for instructions that aren't ran. It is no accident that CPUs and compilers gravitated towards RISC.
  - zaarn 8y ago
    Well, no, point of VLIW is that instead of doing it like a JIT recompiler you do it like a slow recompiler. This is almost always possible and can be done ahead of time. Proof: The CPU itself does it under time constraint, a compiler should be capable of the same minus time constraint. VLIW also doesn't really waste instruction cache if your compiler is being smart and aligns branches to an instruction word, though you still blow the pipeline on a branch if you miss but atleast in Microsofts case they include a way for the compiler to include a prediction which it is arguably in a better position to make. This goes double if you use profiling-guided optimization. If the claims of the Mill guys are true then even the "wasted CPU instruction cache" doesn't hurt performance. CPUs and compilers are gravitating towards lots of things. x86 and ARM aren't the only instruction set. VLIW is healthy and very alive on a lot of DSPs. There are Russian CPUs that use VLIWs in active use. AMD GPUs used VLIW for a while (and some variants still do). You can even get VLIW-based Microcontrollers for cheap. IMO compilers and CPUs may gravitate towards RISC in the shortterm as it is more similar to CISC in terms of complexity. VLIW needs compilers to be smart and languages to be smart too for optimal use. Rust for example would be capable of really taking advantage of VLIW but LLVM doesn't support that complexity (yet, though there is some work). In the long term, so my prediction, VLIW will dominate by nature of being simpler, faster and more efficient.
PDoyle 8y ago
Nice, I hadn't looked at RISC-V before. The operation of FENCE.I scares me a little: > FENCE.I does not ensure that other RISC-V harts’ instruction fetches will observe the local hart’s stores in a multiprocessor system. To make a store to instruction memory visible to all RISC-V harts, the writing hart has to execute a data FENCE before requesting that all remote RISC-V harts execute a FENCE.I Yikes. That sounds cumbersome for multithreaded code patching systems, like modern JIT compilers. (A "hart" here is a hardware thread.) Sounds like all threads must poll periodically to check whether they should run a FENCE.I, and when they do so, they report that they've done it. Doesn't sound like a lot of fun to implement, though maybe better in software than hardware?
- rwmj 8y ago
  I don't know enough to say if this is accurate or not. However there are working groups reviewing the memory model[1] (also implementing fast ISRs[2]) so if there are performance problems in this area then they're being looked at. [1] https://content.riscv.org/wp-content/uploads/2018/05/14.25-15.00-RISCVMemoryModelTutorial.pdf https://content.riscv.org/wp-content/uploads/2018/05/14.25-1... https://content.riscv.org/wp-content/uploads/2018/05/10.40-10.55-Daniel-Lustig.pdf https://content.riscv.org/wp-content/uploads/2018/05/10.40-1... [2] https://content.riscv.org/wp-content/uploads/2018/05/08.45-09.10-RISCV-20180509-FastInts.pdf https://content.riscv.org/wp-content/uploads/2018/05/08.45-0...

lioeters 8y ago

[PDF] (2015) - Probably better without the URL hash. Still relevant..

okket 8y ago

Previous discussion from 3 years ago: https://news.ycombinator.com/item?id=10458318 https://news.ycombinator.com/item?id=10458318 (169 comments)

vages 8y ago

Be courteous and add a (2015) to the title.

stakhanov 8y ago

...if I have to endure one more abuse of the "considered harmful" idiom, I'm going to puke.

kuroguro 8y ago
Puking is considered harmful.
earenndil 8y ago
You'll like this, then https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
nailer 8y ago
I feel that - normally it's hyperbole - but a full Minix OS with an IP stack we don't have control over on all our servers is actually pretty harmful.

jhoechtl 8y ago

Words are not enough to express my deep and profound disgust of all those morons abusing "... considered harmful". It's somewhat ok, if it was brought up years ago and counts as legacy. But for any new abuse all I find are the words of Honeybunny https://genius.com/Tim-roth-pumpkin-and-honey-bunny-annotated https://genius.com/Tim-roth-pumpkin-and-honey-bunny-annotate...

jstewartmobile 8y ago

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?