8 ms·

So just to be clear, I'd need to install the OS patch as well as the OEM update (to BIOS? Processor?) in order to mitigate both Meltdown and Spectre. Additiona

So just to be clear, I'd need to install the OS patch as well as the OEM update (to BIOS? Processor?) in order to mitigate both Meltdown and Spectre. Additionally, how does this interact with VMs? It makes the most sense to me that I'd need to microcode patch the hosts, but what about the guests?

tomxor 9y ago
> Additionally, how does this interact with VMs? It makes the most sense to me that I'd need to microcode patch the hosts, but what about the guests? microcode is for the physical CPU, it is ultimately stored in on die volatile memory in CPU. microcode can be delivered to the CPU on boot by the BIOS/UEFI (stored in it's firmware) and/or by the host OS on boot (doesn't even matter what the OS is, windows, linux etc), this is secure because microcode is cryptographically signed. As for software, the OS kernel and hypervisor patches for VMs... From everything that has been said so far, it sounds like these bugs can't be solved entirely in microcode, so software patches are needed as well i believe. [amended for correctness as per child comments]
- bayindirh 9y ago
  IIRC uCode updates are volatile. You re-install them to CPU on every boot. OS actually does this for you.
  - burnte 9y ago
    You are correct. uCode is installed by the BIOS, and then again later by the OS if there's more recently updated code.
    - tomxor 9y ago
      Out of interest, do you know if the process of uploading the microcode via the OS independent of the BIOS? ... e.g on something with an unusual boot ROM like a mac or a Pi (pretend it had an x86) would the kernel not care? i.e it's just a CPU instruction?
      - burnte 9y ago
        Yes, it is. OSes protect that ability to prevent malicious microcode, too. The update mechanism is published by Intel, too. Section 9.11 (not page 9.11) https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
        tomxor 9y ago
        I always assumed that the CPU itself would have an internal signature verification mechanism built in. But after searching it seems the OS or BIOS is responsible for quite a lot... I haven't found anything clearly stating if and where cryptographic signatures are verified. Once source at least suggested that it's only present on >2013 CPUs ! [edit] This is an interesting old paper on x86 microcode security: https://www.dcddcc.com/docs/2014_paper_microcode.pdf https://www.dcddcc.com/docs/2014_paper_microcode.pdf
      - AnssiH 9y ago
        It should be independent, the Linux x86 microcode code ( https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/microcode/intel.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... and /amd.c) seems to write to MSR (model-specific register) 0x79 on Intel and MSR 0xc0010020 on AMD.
    - mjevans 9y ago
      For Linux this is typically handled as an extra 'initrd' that the bootloading process hands off to before giving control over to the next (and real) initrd... https://wiki.archlinux.org/index.php/microcode#Enabling_Intel_microcode_updates https://wiki.archlinux.org/index.php/microcode#Enabling_Inte...
  - tomxor 9y ago
    Ah, you are correct, I got confused watching some video of someone hacking away at the built in ROM on a de-caped chip... suffice to say, overwriting the permanent internal copy of the microcode does not normally happen. The advantage of updating the ROM this crazy way is purely to defeat the verification of the signature.
    - bayindirh 9y ago
      Care to share the URL of the video? It sounds pretty fun.
      - tomxor 9y ago
        It was a hacker news post actually: the presenter's delivery is a bit dry... but his project is impressive: https://media.ccc.de/v/34c3-9058-everything_you_want_to_know_about_x86_microcode_but_might_have_been_afraid_to_ask#t=2467 https://media.ccc.de/v/34c3-9058-everything_you_want_to_know... The SEM shots of the internal RAM/ROM starts around 24:00, I thought it was pretty cool. The whole purpose of what they are doing is to try and reverse engineer the microcode to write their own.
        bayindirh 9y ago
        Thanks, I'll take a look tomorrow. For more uCode work, there's http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ which contains some interesting bits.
        tomxor 9y ago
        Thanks, I do find microarchitecture stuff really interesting but it's a bit out of my depth if i'm honest.
        bayindirh 9y ago
        I find CPUs fascinating to be honest. While they are complex, they are not impenetrable. Playing with small assembly snippets and simulators helped me a lot to understand them. Also, other architectures such as MIPS and M68K have simpler to understand ISAs which accelerate the process of understanding these small wonders.
wlll 9y ago
My understanding of this situation is this: Meltdown: Easier to exploit, fixable in software but perhaps up to a 30% performance hit for some operations. Spectre: Harder to exploit, not fixable in software, needs new hardware. See these two links for more detail: https://twitter.com/nicoleperlroth/status/948684376249962496 https://twitter.com/nicoleperlroth/status/948684376249962496 https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.co.uk/2018/01/reading-pri...
- shagie 9y ago
  I was under the impression that the changes for Clang with retropipe was for specter. Mitigation of it then can be done by recompiling... everything. > Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..
  - tyfon 9y ago
    Can't you just compile your own code without the mitigations inside the vm?
    - mort96 9y ago
      Yes, but then you'd just end up with having a vulnerable application running inside of the VM. The mitigations in the compilers are for making programs compiled by those compilers immune(ish?) to Spectre, not to make it impossible for those programs to use Spectre to attack other processes.
    - noselasd 9y ago
      You can, but spectre only affects your own process, and if you can compile/run your program, it's unlikely that exploiting anything to read the memory of your own process is any danger.
thisacctforreal 9y ago
Update host software to (partially?) mitigate guest applications extracting host memory contents. Update guest software to (partially?) mitigate guest applications extracting guest memory contents.

tomxor 9y ago

> Additionally, how does this interact with VMs? It makes the most sense to me that I'd need to microcode patch the hosts, but what about the guests? microcode is for the physical CPU, it is ultimately stored in on die volatile memory in CPU. microcode can be delivered to the CPU on boot by the BIOS/UEFI (stored in it's firmware) and/or by the host OS on boot (doesn't even matter what the OS is, windows, linux etc), this is secure because microcode is cryptographically signed. As for software, the OS kernel and hypervisor patches for VMs... From everything that has been said so far, it sounds like these bugs can't be solved entirely in microcode, so software patches are needed as well i believe. [amended for correctness as per child comments]

bayindirh 9y ago
IIRC uCode updates are volatile. You re-install them to CPU on every boot. OS actually does this for you.
- burnte 9y ago
  You are correct. uCode is installed by the BIOS, and then again later by the OS if there's more recently updated code.
  - tomxor 9y ago
    Out of interest, do you know if the process of uploading the microcode via the OS independent of the BIOS? ... e.g on something with an unusual boot ROM like a mac or a Pi (pretend it had an x86) would the kernel not care? i.e it's just a CPU instruction?
    - burnte 9y ago
      Yes, it is. OSes protect that ability to prevent malicious microcode, too. The update mechanism is published by Intel, too. Section 9.11 (not page 9.11) https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
      - tomxor 9y ago
        I always assumed that the CPU itself would have an internal signature verification mechanism built in. But after searching it seems the OS or BIOS is responsible for quite a lot... I haven't found anything clearly stating if and where cryptographic signatures are verified. Once source at least suggested that it's only present on >2013 CPUs ! [edit] This is an interesting old paper on x86 microcode security: https://www.dcddcc.com/docs/2014_paper_microcode.pdf https://www.dcddcc.com/docs/2014_paper_microcode.pdf
    - AnssiH 9y ago
      It should be independent, the Linux x86 microcode code ( https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/microcode/intel.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... and /amd.c) seems to write to MSR (model-specific register) 0x79 on Intel and MSR 0xc0010020 on AMD.
  - mjevans 9y ago
    For Linux this is typically handled as an extra 'initrd' that the bootloading process hands off to before giving control over to the next (and real) initrd... https://wiki.archlinux.org/index.php/microcode#Enabling_Intel_microcode_updates https://wiki.archlinux.org/index.php/microcode#Enabling_Inte...
- tomxor 9y ago
  Ah, you are correct, I got confused watching some video of someone hacking away at the built in ROM on a de-caped chip... suffice to say, overwriting the permanent internal copy of the microcode does not normally happen. The advantage of updating the ROM this crazy way is purely to defeat the verification of the signature.
  - bayindirh 9y ago
    Care to share the URL of the video? It sounds pretty fun.
    - tomxor 9y ago
      It was a hacker news post actually: the presenter's delivery is a bit dry... but his project is impressive: https://media.ccc.de/v/34c3-9058-everything_you_want_to_know_about_x86_microcode_but_might_have_been_afraid_to_ask#t=2467 https://media.ccc.de/v/34c3-9058-everything_you_want_to_know... The SEM shots of the internal RAM/ROM starts around 24:00, I thought it was pretty cool. The whole purpose of what they are doing is to try and reverse engineer the microcode to write their own.
      - bayindirh 9y ago
        Thanks, I'll take a look tomorrow. For more uCode work, there's http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ which contains some interesting bits.
        tomxor 9y ago
        Thanks, I do find microarchitecture stuff really interesting but it's a bit out of my depth if i'm honest.
        bayindirh 9y ago
        I find CPUs fascinating to be honest. While they are complex, they are not impenetrable. Playing with small assembly snippets and simulators helped me a lot to understand them. Also, other architectures such as MIPS and M68K have simpler to understand ISAs which accelerate the process of understanding these small wonders.

wlll 9y ago

My understanding of this situation is this: Meltdown: Easier to exploit, fixable in software but perhaps up to a 30% performance hit for some operations. Spectre: Harder to exploit, not fixable in software, needs new hardware. See these two links for more detail: https://twitter.com/nicoleperlroth/status/948684376249962496 https://twitter.com/nicoleperlroth/status/948684376249962496 https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.co.uk/2018/01/reading-pri...

shagie 9y ago
I was under the impression that the changes for Clang with retropipe was for specter. Mitigation of it then can be done by recompiling... everything. > Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..
- tyfon 9y ago
  Can't you just compile your own code without the mitigations inside the vm?
  - mort96 9y ago
    Yes, but then you'd just end up with having a vulnerable application running inside of the VM. The mitigations in the compilers are for making programs compiled by those compilers immune(ish?) to Spectre, not to make it impossible for those programs to use Spectre to attack other processes.
  - noselasd 9y ago
    You can, but spectre only affects your own process, and if you can compile/run your program, it's unlikely that exploiting anything to read the memory of your own process is any danger.

thisacctforreal 9y ago

Update host software to (partially?) mitigate guest applications extracting host memory contents. Update guest software to (partially?) mitigate guest applications extracting guest memory contents.