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 <mlar...@azathoth.net> 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
>  
> 

Reply via email to