On Tue, Mar 13, 2018 at 02:23:29PM -0700, Mike Larkin wrote:
> On Tue, Mar 13, 2018 at 08:27:49AM -0500, Brian Camp wrote:
> > On Tue, Mar 13, 2018 at 2:29 AM, Mike Larkin <[email protected]> wrote:
> > > On Sun, Mar 11, 2018 at 04:33:49PM -0500, Brian Camp wrote:
> > >> I have two systems running 6.2-stable with the meltdown syspatch
> > >> installed. I noticed that while one of them lists "MELTDOWN" in the
> > >> CPU flags, the other does not. The one that does not has a Celeron
> > >> J3455, which Intel lists as affected by meltdown.
> > >>
> > >> Does the absence of the MELTDOWN flag mean that the workaround isn't
> > >> functioning on this machine? Dmesg below.
> > >>
> > >>
> > >> Thanks
> > >>
> > >> -Brian
> > >>
> > >
> > > Odd. Two of us have looked at the detection code again and we can't see
> > > any
> > > issues. Can you please do the following to help diagnose?
> > >
> > > 1. install the "cpuid" port package?
> > >
> > > pkg_add cpuid
> > >
> > > 2. send the output of:
> > >
> > > cpuid 0x0
> > > cpuid 0x7
> > >
> > > On each of the two machines? (Make sure to say which is the working one
> > > and which is the one where meltdown isn't properly being detected).
> > >
> > > Thanks.
> > >
> > > -ml
> >
> > Sure thing.
> >
> > Working (i5-4690) -
> >
> > bcamp@z97x-sli:~ (OpenBSD 6.2)
> > $ cpuid 0x0
> > eax = 0x0000000d 13 "????"
> > ebx = 0x756e6547 1970169159 "Genu"
> > ecx = 0x6c65746e 1818588270 "ntel"
> > edx = 0x49656e69 1231384169 "ineI"
> > bcamp@z97x-sli:~ (OpenBSD 6.2)
> > $ cpuid 0x7
> > eax = 0x00000000 0 "????"
> > ebx = 0x000027ab 10155 "?'??"
> > ecx = 0x00000000 0 "????"
> > edx = 0x00000000 0 "????"
> > bcamp@z97x-sli:~ (OpenBSD 6.2)
> > $
> >
> > Non-working (Celeron J3455) -
> >
> > bcamp@nuc6cayh:~ (OpenBSD 6.2)
> > $ cpuid 0x0
> > eax = 0x00000015 21 "????"
> > ebx = 0x756e6547 1970169159 "Genu"
> > ecx = 0x6c65746e 1818588270 "ntel"
> > edx = 0x49656e69 1231384169 "ineI"
> > bcamp@nuc6cayh:~ (OpenBSD 6.2)
> > $ cpuid 0x7
> > eax = 0x00000000 0 "????"
> > ebx = 0x2294e283 580182659 "???""
> > ecx = 0x00000000 0 "????"
> > edx = 0x2c000000 738197504 "???,"
> > bcamp@nuc6cayh:~ (OpenBSD 6.2)
> > $
> >
> >
> > -Brian
> >
>
> As naddy@ pointed out in the earlier reply, this behaviour indicates that for
> some reason your CPU is saying it's not vulnerable. The 0x2c in edx for cpuid
> 0x7 in the J3455 case in your mail indicates the firmware (bios) says that
> the IA32_ARCH_CAPABILITIES MSR is available. We read that and if bit 1 is set,
Meant "bit 0" there.
-ml
> it means the CPU is not susceptible to "RDCL" (RDCL_NO = not susceptible to
> "Rogue Data Cache Load" ala Meltdown).
>
> Can you apply this diff and boot the J3455 machine and send the boot dmesg
> after applying it (apply to -current, please). This caches what answer we saw
> during boot and will tell us if the CPU is reporting garbage there.
>
> You don't need to run this on the other machine.
>
> -ml
>
> PS - you might also try looking for a newer BIOS, although this machine BIOS
> is
> listed as 08 Jan 2018, it's possible that was applied during that short
> period where Intel was releasing broken firmware updates. I'd appreciate it
> however if you booted with the diff below, first, before trying that.
>
> Index: amd64/identcpu.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> retrieving revision 1.95
> diff -u -p -a -u -r1.95 identcpu.c
> --- amd64/identcpu.c 21 Feb 2018 19:24:15 -0000 1.95
> +++ amd64/identcpu.c 13 Mar 2018 20:32:22 -0000
> @@ -456,7 +456,7 @@ identifycpu(struct cpu_info *ci)
> int i;
> char *brandstr_from, *brandstr_to;
> int skipspace;
> - extern uint32_t cpu_meltdown;
> + extern uint32_t cpu_meltdown, cpu_archcap;
>
> CPUID(1, ci->ci_signature, val, dummy, ci->ci_feature_flags);
> CPUID(0x80000000, ci->ci_pnfeatset, dummy, dummy, dummy);
> @@ -616,6 +616,9 @@ identifycpu(struct cpu_info *ci)
>
> if (cpu_meltdown)
> printf(",MELTDOWN");
> +
> + if (cpu_archcap)
> + printf("(arch cap=0x%x)", cpu_archcap);
>
> printf("\n");
>
> Index: amd64/locore.S
> ===================================================================
> RCS file: /cvs/src/sys/arch/amd64/amd64/locore.S,v
> retrieving revision 1.94
> diff -u -p -a -u -r1.94 locore.S
> --- amd64/locore.S 21 Feb 2018 19:24:15 -0000 1.94
> +++ amd64/locore.S 13 Mar 2018 20:28:15 -0000
> @@ -178,6 +178,7 @@ _C_LABEL(lapic_isr):
> .globl _C_LABEL(pg_nx)
> .globl _C_LABEL(pg_g_kern)
> .globl _C_LABEL(cpu_meltdown)
> + .globl _C_LABEL(cpu_archcap)
> _C_LABEL(cpu_id): .long 0 # saved from `cpuid' instruction
> _C_LABEL(cpu_feature): .long 0 # feature flags from 'cpuid'
> # instruction
> @@ -214,6 +215,7 @@ _C_LABEL(pg_g_kern): .quad 0 # 0x100 if
> # in kernel mappings, 0 otherwise (for
> # insecure CPUs)
> _C_LABEL(cpu_meltdown): .long 0 # 1 if this CPU has Meltdown
> +_C_LABEL(cpu_archcap): .long 0 # cached MSR
> IA32_ARCH_CAPABILITIES.eax
>
> #define _RELOC(x) ((x) - KERNBASE)
> #define RELOC(x) _RELOC(_C_LABEL(x))
> Index: amd64/locore0.S
> ===================================================================
> RCS file: /cvs/src/sys/arch/amd64/amd64/locore0.S,v
> retrieving revision 1.7
> diff -u -p -a -u -r1.7 locore0.S
> --- amd64/locore0.S 21 Feb 2018 19:24:15 -0000 1.7
> +++ amd64/locore0.S 13 Mar 2018 20:31:40 -0000
> @@ -238,6 +238,7 @@ bi_size_ok:
> /* IA32_ARCH_CAPABILITIES MSR avaialble, use it to check CPU security */
> movl $MSR_ARCH_CAPABILITIES, %ecx
> rdmsr
> + movl %eax, _RELOC(cpu_archcap)
> testl $ARCH_CAPABILITIES_RDCL_NO, %eax
> jz .Lcpu_check_finished
>
>
