Spectre & Meltdown patched but still vulnerable

Support for security such as Firewalls and securing linux
Post Reply
Posts: 5
Joined: 2018/01/12 09:41:48

Spectre & Meltdown patched but still vulnerable

Post by mcneillchris9 » 2018/01/12 10:16:18

Hi Guys,

This is similar to viewtopic.php?f=51&t=65693 but I wanted to provide more detail and check that it is actually the same issue/cause.

I'm running a CentOS 7 instance within Amazon's EC2 environment, I have run yum update successfully.

After completing the update, I can see that the expected patches are applied (output at bottom of this post for ref.), however when running the meltdown checker again (output again below), it's failing Spectre Variant 2 because IBRS isn't enabled. I'm not sure if this is something in my control which I can enable? or if this is related to the microcode updates that I believe are required (Note that I have run the check for microcode updates and it doesn't show anything available). According to Amazon https://aws.amazon.com/security/securit ... -2018-013/ all their hardware has been updated, and recommend a software update (as I've now already done)

So in summary, I suppose my question is: Is there something I need to do to 'enable' IBRS since the checker report shows support exists? Or am I maybe missing something entirely different?

Many thanks in advance.

Console output / more info included below for completeness

Code: Select all

$ cat /etc/*release
CentOS Linux release 7.4.1708 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID_LIKE="rhel fedora"
PRETTY_NAME="CentOS Linux 7 (Core)"


CentOS Linux release 7.4.1708 (Core)
CentOS Linux release 7.4.1708 (Core)

Code: Select all

$ dmesg | grep microcode
[    2.309797] microcode: CPU0 sig=0x306f2, pf=0x1, revision=0x3b
[    2.319746] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Code: Select all

$ sudo sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.26

Checking for vulnerabilities against live running kernel Linux 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 01:06:37 UTC 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  YES
> STATUS:  NOT VULNERABLE  (106 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  YES
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

Code: Select all

$ sudo rpm -q --changelog kernel | egrep 'CVE-2017-5715|CVE-2017-5753|CVE-2017-5754'
- [x86] spec_ctrl: Eliminate redundant FEATURE Not Present messages (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] mm/kaiser: init_tss is supposed to go in the PAGE_ALIGNED per-cpu section (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: svm: spec_ctrl at vmexit needs per-cpu areas functional (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] kaiser/mm: skip IBRS/CR3 restore when paranoid exception returns to userland (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] kaiser/mm: consider the init_mm.pgd a kaiser pgd (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: Prevent unwanted speculation without IBRS (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] entry: Remove trampoline check from paranoid entry path (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] entry: Fix paranoid_exit() trampoline clobber (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] entry: Simplify trampoline stack restore code (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] spec_ctrl: remove SPEC_CTRL_DEBUG code (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: add noibrs noibpb boot options (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] entry: Use retpoline for syscall's indirect calls (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] syscall: Clear unused extra registers on 32-bit compatible syscall entrance (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: cleanup unnecessary ptregscall_common function (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: CLEAR_EXTRA_REGS and extra regs save/restore (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] syscall: Clear unused extra registers on syscall entrance (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: rescan cpuid after a late microcode update (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: add debugfs ibrs_enabled ibpb_enabled (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: consolidate the spec control boot detection (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] KVM/spec_ctrl: allow IBRS to stay enabled in host userland (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: add debug aid to test the entry code without microcode (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: move stuff_RSB in spec_ctrl.h (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] entry: Stuff RSB for entry to kernel for non-SMEP platform (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] mm: Only set IBPB when the new thread cannot ptrace current thread (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] mm: Set IBPB upon context switch (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] idle: Disable IBRS when offlining cpu and re-enable on wakeup (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] idle: Disable IBRS entering idle and enable it on wakeup (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: implement spec ctrl C methods (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: save IBRS MSR value in save_paranoid for NMI (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] enter: Use IBRS on syscall and interrupts (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: swap rdx with rsi for nmi nesting detection (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: spec_ctrl_pcp and kaiser_enabled_pcp in same cachline (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: use per-cpu knob instead of ALTERNATIVES for ibpb and ibrs (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] enter: MACROS to set/clear IBRS and set IBPB (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] x86: add SPEC_CTRL to MSR and CPUID lists (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] svm: add MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] svm: Set IBPB when running a different VCPU (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] vmx: add MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] vmx: Set IBPB when running a different VCPU (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] x86: clear registers on VM exit (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] kvm: pad RSB on VM transition (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] cpu/AMD: Control indirect branch predictor when SPEC_CTRL not available (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] feature: Report presence of IBPB and IBRS control (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] feature: Enable the x86 feature to control Speculation (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [tools] objtool: Don't print 'call dest' warnings for ignored functions (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [misc] locking/barriers: prevent speculative execution based on Coverity scan results (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [fs] udf: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [fs] prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [kernel] userns: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [scsi] qla2xxx: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [netdrv] p54: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [netdrv] carl9170: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [media] uvcvideo: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [x86] cpu/AMD: Remove now unused definition of MFENCE_RDTSC feature (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [x86] cpu/AMD: Make the LFENCE instruction serialized (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [misc] locking/barriers: introduce new memory barrier gmb() (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [x86] mm/kaiser: Replace kaiser with kpti to sync with upstream (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add "kaiser" and "nokaiser" boot options (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map the trace idt tables in userland shadow pgd (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: fix RESTORE_CR3 crash in kaiser_stop_machine (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use stop_machine for enable/disable knob (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use atomic ops to poison/unpoison user pagetables (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use invpcid to flush the two kaiser PCID AISD (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use two PCID ASIDs optimize the TLB during enter/exit kernel (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: stop patching flush_tlb_single (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use PCID feature to make user and kernel switches faster (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: If INVPCID is available, use it to flush global mappings (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/64: Fix reboot interaction with CR4.PCIDE (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/64: Initialize CR4.PCIDE early (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: Add a 'noinvpcid' boot option to turn off INVPCID (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: Add the 'nopcid' boot option to turn off PCID (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: validate trampoline stack (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] entry: Move SYSENTER_stack to the beginning of struct tss_struct (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: isolate the user mapped per cpu areas (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: enable kaiser in build (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: selective boot time defaults (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: handle call to xen_pv_domain() on PREEMPT_RT (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser/xen: Dynamically disable KAISER when running under Xen PV (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add Kconfig (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: avoid false positives during non-kaiser pgd updates (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: Respect disabled CPU features (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: trampoline stack comments (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: stack trampoline (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: remove paravirt clock warning (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: re-enable vsyscalls (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: allow to build KAISER with KASRL (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: allow KAISER to be enabled/disabled at runtime (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: un-poison PGDs at runtime (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add a function to check for KAISER being enabled (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add debugfs file to turn KAISER on/off at runtime (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: disable native VSYSCALL (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map virtually-addressed performance monitoring buffers (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map debug IDT tables (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add kprobes text section (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map trace interrupt entry (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map entry stack per-cpu areas (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map dynamically-allocated LDTs (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: make sure static PGDs are 8k in size (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: allow NX poison to be set in p4d/pgd (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: unmap kernel from userspace page tables (core patch) (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: mark per-cpu data structures required for entry/exit (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: introduce user-mapped per-cpu areas (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add cr3 switches to entry code (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: remove scratch registers (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: prepare assembly for entry/exit CR3 switching (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: Disable global pages by default with KAISER (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: Document X86_CR4_PGE toggling behavior (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/tlb: Make CR4-based TLB flushes more robust (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: Do not set _PAGE_USER for init_mm page tables (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] increase robusteness of bad_iret fixup handler (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [perf] x86/intel/uncore: Fix memory leaks on allocation failures (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [mm] userfaultfd: hugetlbfs: prevent UFFDIO_COPY to fill beyond the end of i_size (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [fs] userfaultfd: non-cooperative: fix fork use after free (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [mm] userfaultfd: hugetlbfs: remove superfluous page unlock in VM_SHARED case (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [mm] fix bad rss-counter if remap_file_pages raced migration (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}

User avatar
Retired Moderator
Posts: 3046
Joined: 2010/12/01 19:25:52
Location: Helsinki, Finland

Re: Spectre & Meltdown patched but still vulnerable

Post by avij » 2018/01/12 10:27:18

Please run cat /sys/kernel/debug/x86/ibrs_enabled and report back the results. There are apparently some scripts that check if that value is 0 or 1, but get confused if that value is 2.

Posts: 5
Joined: 2018/01/12 09:41:48

Re: Spectre & Meltdown patched but still vulnerable

Post by mcneillchris9 » 2018/01/12 10:51:51

Thanks Avij, output below:

Code: Select all

$ sudo cat /sys/kernel/debug/x86/ibrs_enabled
Edit, I also run a check for ibpb_enabled in case that's helpful

Code: Select all

$ sudo cat /sys/kernel/debug/x86/ibpb_enabled

Posts: 5
Joined: 2018/01/12 09:41:48

Re: Spectre & Meltdown patched but still vulnerable

Post by mcneillchris9 » 2018/01/12 11:22:38

Hi avij,

reading the link you provided, am I correct in assuming these values are expected, since I've no microcode update available? However this then doesn't resolve #2 ?
Intel Defaults:

pti 1 ibrs 1 ibpb 1 -> fix variant#1 #2 #3
pti 1 ibrs 0 ibpb 0 -> fix variant#1 #3 (for older Intel systems with no microcode update available)

Posts: 1
Joined: 2018/01/15 13:20:32

Re: Spectre & Meltdown patched but still vulnerable

Post by ksiraj786@gmail.com » 2018/01/15 13:24:03

I'm facing the exact same issue in centos 7, in aws. Any fix?

User avatar
Site Admin
Posts: 33048
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Spectre & Meltdown patched but still vulnerable

Post by TrevorH » 2018/01/15 16:57:25

IBRS requires a microcode update to fix it. Virtual machines are unlikely to have fixed "microcode" available.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Posts: 5
Joined: 2018/01/12 09:41:48

Re: Spectre & Meltdown patched but still vulnerable

Post by mcneillchris9 » 2018/01/15 17:00:41

@TervorH does this mean that its not possible to fully patch virtual machines, and resolution to #1 and #3 is the best we can do for now?


Posts: 776
Joined: 2013/12/08 19:44:49

Re: Spectre & Meltdown patched but still vulnerable

Post by chemal » 2018/01/15 19:59:16

The microcode update gives you two additional CPU flags: spec_ctrl and ibpb_support, cf. cat /proc/cpuinfo. That's what the kernel checks before activating the workarounds that depend on these new CPU features. If you want to see these flags in a VM, the hypervisor has to pass them through. It seems that so far no hypervisor does this. Perhaps it isn't necessary. Not sure.

EDIT: For KVM they have started to implement this: https://patchwork.kernel.org/patch/10151873/

Posts: 5
Joined: 2018/01/12 09:41:48

Re: Spectre & Meltdown patched but still vulnerable

Post by mcneillchris9 » 2018/01/24 09:27:23

Hi Guys,

I noticed AWS were referencing back to this post on their article https://aws.amazon.com/speculative-exec ... s-updates/ and due to some things appearing as assumptions on this (or at least it seemed that way from my reading) I asked their support team for clarification etc. Below is the question and response from them in the hope it might help clarify for others and/or provide any extra useful information.


whilst reading through the documentation for patching the Meltdown/Spectre variations, I've applied the system updates but according to checker scripts my instance is still vulnerable to CVE-2017-5715 (variant 2).

Reading through document updates, I've come across document https://aws.amazon.com/speculative-exec ... s-updates/ which links further to a centOS forum post viewtopic.php?f=51&t=65703

The forum post that's referenced - was actually initiated by me (so the details supplied in it apply to this case if needed), with the hope to get a resolution to CVE-2017-5715. As the issue is still unresolved on the forum post, I wonder if you can provide any clarification on the current state from an AWS/EC2 perspective.

Clarification would be useful on the following

Statement/Assumption 1:
due to hypervisor not passing though CPU flags (spec_ctrl and ibpb_support ...) that I would be unable to activate the workarounds on my instance
- Is this correct? Is there any plan to have these passed through and available for EC2 instances?

Statement/Assumption 2:
"Perhaps this isn't necessary" - referring to the need to set the above flags on virtual instances
-- again, is this correct? Is the patching of CVE-2017-5715 not necessary on virtual (EC2) instances due to the host-level patches in place.

It sounds like you are using a particular third-party checker script to report whether the instances are still vulnerable.

As the newest post on your centos forum thread mentions, this type 2 checker looks for the new CPU Flags (MSRs), which are introduced by the new microcode (installed inside the CPU, not a thing your VM is allowed to do).

These new CPU Flags need to be allowed to be passed "up" to the VMs so that they can read them, otherwise they don't exist in the guest. The fact that the checker reports the flag missing as the same as the flag existing but vulnerable, and is saying its vulnerable, is not actually an indicator of vulnerability.

Simply, without the flag, the checker cannot know if new microcode is installed or not, and returns vulnerable. This checker does not attempt the #2 attack type.

Statement 1: Correct. C5/M5's new hypervisor exposes them, Xen currently does not, see reason below. On Xen, because the flags are not exposed, your kernel cannot enable type 2 mitigation - from attacks originating inside your instance. As stated in the security bulletin [1], "All instances across the Amazon EC2 fleet are protected from all known instance-to-instance concerns of CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754." since 2018-01-04.

Statement 2: No-one is suggesting that patching for type 2 is unnecessary in virtualization (you still need it or retpoline for attacks from inside your instance), but that you can't control whether the CPU microcode is patched or not, and the Xen hypervisors aren't indicating to the clients if they are or aren't. However, all of AWS hosts are protected from instance-to-instance, and have been for all three types.

More details in our AWS Forum post about how these checkers work, and why the flags aren't exposed in Xen currently: "Operating systems can utilize these MSRs as one mitigation for Variant 2, and Microsoft has issued an update that uses them. Hypervisors must be updated and configured to provide virtual machines access to the MSRs, as you have seen in the documentation for Hyper-V. Similar documentation for VMware is found here: https://kb.vmware.com/s/article/52085

At this time the Nitro hypervisor used for C5 and M5 instances has been updated and configured to provide access to the MSRs, but the Xen-based hypervisor used for most EC2 instances has not. Intel has recently informed its customers and ecosystem partners that issues can be caused in some cases when the MSRs are used on some of their processors, therefore AWS cannot make these MSRs available to EC2 instances until an additional microcode update is provided. See https://kb.vmware.com/s/article/52345 for VMware's article covering this issue, though keep in mind that documentation for other hypervisors does not always apply to the hypervisors that EC2 uses for virtualized instances." [2]

[1] https://aws.amazon.com/security/securit ... -2018-013/
[2] https://forums.aws.amazon.com/thread.js ... 5&tstart=0

Post Reply