Re: Meltdown workaround enabled?
On 2018-03-13, Brian Camp wrote: > Thats actually the latest version. Even though this board is made by > Intel itself, they have yet to release a BIOS update with the patched > microcode that other OEMs are shipping. BTW, they're actually ECS boards. > re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H > (0x5400), msi, address 94:c6:91:19:ab:cb The clue is here ^^
Re: Meltdown workaround enabled?
On 2018-03-14, "Robert Paschedag" wrote: > Errdo I get it right, that a possibly vulnerable CPU > (from 2016) is still vulnerable to MELTDOWN but a newer > BIOS *fakes* the CPU flags so the MELTDOWN "detection code" > says, "this CPU is NOT vulnerable" > > Is that right? The newer BIOS includes new microcode. As reported by the cpuid 7 edx return, this microcode adds: - IBRS/IBPB speculation control - STIBP speculation control These can be used by the operating system to mitigate Spectre V2 vulnerabilities. - IA32_ARCH_CAPABILITIES model-specific register - RDCL_NO indicator This indicates that the CPU is not vulnerable to Meltdown (V3). The gracious assumption is that the CPU (Apollo Lake/Goldmont) either wasn't vulnerable to Meltdown in the first place or that it could be fixed by the new microcode. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Meltdown workaround enabled?
On Wed, Mar 14, 2018 at 05:38 Robert Paschedag wrote: > > > Gesendet: Mittwoch, 14. März 2018 um 06:13 Uhr > > Von: "Bob Beck" > > An: "Brian Camp" > > Cc: "Theo de Raadt" , misc@openbsd.org > > Betreff: Re: Meltdown workaround enabled? > > > > Intel make kitty scared... What a fuckmess. > > Errdo I get it right, that a possibly vulnerable CPU > (from 2016) is still vulnerable to MELTDOWN but a newer > BIOS *fakes* the CPU flags so the MELTDOWN "detection code" > says, "this CPU is NOT vulnerable" > > Is that right? > > Robert > Just consume the broken crap like a good citizen. Intel is too big to fail so thinking about these things is bad for society. Right? > > > > On Tue, Mar 13, 2018 at 22:57 Brian Camp wrote: > > > > > On Tue, Mar 13, 2018 at 10:39 PM, Theo de Raadt > > > wrote: > > > >> According to some sources, Intel and a handful of others have known > > > about the > > > >> issue since February 2017(!), so perhaps it has already been > patched in > > > the > > > >> 08Jan2018 BIOS. I too have doubts that to date any processor has > been > > > >> redesigned to avoid the flaws entirely, but then again... > > > > > > > > Sure. A BIOS can change the flag bits. > > > > > > > > Be nice to know. Did a BIOS change them? > > > > > > I downgraded the bios to try and figure this out. Going back just one > > > revision (1/8/2018 to 12/18/2017) causes it to lose the flag and > > > -current's MELTDOWN workaround to activate. > > > > > > Previous BIOS revision (12/18/2017): > > > bcamp@nuc6cayh:~ (OpenBSD 6.3) > > > $ cpuid 0x7 > > > eax = 0x 0"" > > > ebx = 0x2294e283 580182659"???"" > > > ecx = 0x 0"" > > > edx = 0x 0"" > > > > > > Newest BIOS revision (1/8/2018): > > > bcamp@nuc6cayh:~ (OpenBSD 6.3) > > > $ cpuid 0x7 > > > eax = 0x 0"" > > > ebx = 0x2294e283 580182659"???"" > > > ecx = 0x 0"" > > > edx = 0x2c00 738197504"???," > > > > > > > > > >
Re: Meltdown workaround enabled?
> Gesendet: Mittwoch, 14. März 2018 um 06:13 Uhr > Von: "Bob Beck" > An: "Brian Camp" > Cc: "Theo de Raadt" , misc@openbsd.org > Betreff: Re: Meltdown workaround enabled? > > Intel make kitty scared... What a fuckmess. Errdo I get it right, that a possibly vulnerable CPU (from 2016) is still vulnerable to MELTDOWN but a newer BIOS *fakes* the CPU flags so the MELTDOWN "detection code" says, "this CPU is NOT vulnerable" Is that right? Robert > > On Tue, Mar 13, 2018 at 22:57 Brian Camp wrote: > > > On Tue, Mar 13, 2018 at 10:39 PM, Theo de Raadt > > wrote: > > >> According to some sources, Intel and a handful of others have known > > about the > > >> issue since February 2017(!), so perhaps it has already been patched in > > the > > >> 08Jan2018 BIOS. I too have doubts that to date any processor has been > > >> redesigned to avoid the flaws entirely, but then again... > > > > > > Sure. A BIOS can change the flag bits. > > > > > > Be nice to know. Did a BIOS change them? > > > > I downgraded the bios to try and figure this out. Going back just one > > revision (1/8/2018 to 12/18/2017) causes it to lose the flag and > > -current's MELTDOWN workaround to activate. > > > > Previous BIOS revision (12/18/2017): > > bcamp@nuc6cayh:~ (OpenBSD 6.3) > > $ cpuid 0x7 > > eax = 0x 0"" > > ebx = 0x2294e283 580182659"???"" > > ecx = 0x 0"" > > edx = 0x 0"" > > > > Newest BIOS revision (1/8/2018): > > bcamp@nuc6cayh:~ (OpenBSD 6.3) > > $ cpuid 0x7 > > eax = 0x 0"" > > ebx = 0x2294e283 580182659"???"" > > ecx = 0x 0"" > > edx = 0x2c00 738197504"???," > > > > >
Re: Meltdown workaround enabled?
Intel make kitty scared... What a fuckmess. On Tue, Mar 13, 2018 at 22:57 Brian Camp wrote: > On Tue, Mar 13, 2018 at 10:39 PM, Theo de Raadt > wrote: > >> According to some sources, Intel and a handful of others have known > about the > >> issue since February 2017(!), so perhaps it has already been patched in > the > >> 08Jan2018 BIOS. I too have doubts that to date any processor has been > >> redesigned to avoid the flaws entirely, but then again... > > > > Sure. A BIOS can change the flag bits. > > > > Be nice to know. Did a BIOS change them? > > I downgraded the bios to try and figure this out. Going back just one > revision (1/8/2018 to 12/18/2017) causes it to lose the flag and > -current's MELTDOWN workaround to activate. > > Previous BIOS revision (12/18/2017): > bcamp@nuc6cayh:~ (OpenBSD 6.3) > $ cpuid 0x7 > eax = 0x 0"" > ebx = 0x2294e283 580182659"???"" > ecx = 0x 0"" > edx = 0x 0"" > > Newest BIOS revision (1/8/2018): > bcamp@nuc6cayh:~ (OpenBSD 6.3) > $ cpuid 0x7 > eax = 0x 0"" > ebx = 0x2294e283 580182659"???"" > ecx = 0x 0"" > edx = 0x2c00 738197504"???," > >
Re: Meltdown workaround enabled?
> On Tue, Mar 13, 2018 at 10:39 PM, Theo de Raadt wrote: > >> According to some sources, Intel and a handful of others have known about > >> the > >> issue since February 2017(!), so perhaps it has already been patched in the > >> 08Jan2018 BIOS. I too have doubts that to date any processor has been > >> redesigned to avoid the flaws entirely, but then again... > > > > Sure. A BIOS can change the flag bits. > > > > Be nice to know. Did a BIOS change them? > > I downgraded the bios to try and figure this out. Going back just one > revision (1/8/2018 to 12/18/2017) causes it to lose the flag and > -current's MELTDOWN workaround to activate. > > Previous BIOS revision (12/18/2017): > bcamp@nuc6cayh:~ (OpenBSD 6.3) > $ cpuid 0x7 > eax = 0x 0"" > ebx = 0x2294e283 580182659"???"" > ecx = 0x 0"" > edx = 0x 0"" > > Newest BIOS revision (1/8/2018): > bcamp@nuc6cayh:~ (OpenBSD 6.3) > $ cpuid 0x7 > eax = 0x 0"" > ebx = 0x2294e283 580182659"???"" > ecx = 0x 0"" > edx = 0x2c00 738197504"???," Fascinating isn't it?
Re: Meltdown workaround enabled?
On Tue, Mar 13, 2018 at 10:39 PM, Theo de Raadt wrote: >> According to some sources, Intel and a handful of others have known about the >> issue since February 2017(!), so perhaps it has already been patched in the >> 08Jan2018 BIOS. I too have doubts that to date any processor has been >> redesigned to avoid the flaws entirely, but then again... > > Sure. A BIOS can change the flag bits. > > Be nice to know. Did a BIOS change them? I downgraded the bios to try and figure this out. Going back just one revision (1/8/2018 to 12/18/2017) causes it to lose the flag and -current's MELTDOWN workaround to activate. Previous BIOS revision (12/18/2017): bcamp@nuc6cayh:~ (OpenBSD 6.3) $ cpuid 0x7 eax = 0x 0"" ebx = 0x2294e283 580182659"???"" ecx = 0x 0"" edx = 0x 0"" Newest BIOS revision (1/8/2018): bcamp@nuc6cayh:~ (OpenBSD 6.3) $ cpuid 0x7 eax = 0x 0"" ebx = 0x2294e283 580182659"???"" ecx = 0x 0"" edx = 0x2c00 738197504"???,"
Re: Meltdown workaround enabled?
> According to some sources, Intel and a handful of others have known about the > issue since February 2017(!), so perhaps it has already been patched in the > 08Jan2018 BIOS. I too have doubts that to date any processor has been > redesigned to avoid the flaws entirely, but then again... Sure. A BIOS can change the flag bits. Be nice to know. Did a BIOS change them?
Re: Meltdown workaround enabled?
> Running that PoC on the machine while in -current and even 6.1 (no > patches) returns that the system is not vulnerable to meltdown. This > processor was made in 2016 and everything I've read indicates that it > should be vulnerable. Such a low-grade processor may not have sufficient speculative prefetch to cause the problem, but it is very strange to see the bit set which indicates it is invulnerable. Did someone know ahead of time about this problem and a speculative-prefetch bit already existed and Intel did bravado to indicate it was the new checking mechanism? Or was the bit already there and reused to indicate this?
Re: Meltdown workaround enabled?
On 13 Mar 2018 at 16:57, Mike Larkin wrote: > On Tue, Mar 13, 2018 at 06:20:16PM -0500, Brian Camp wrote: > > On Tue, Mar 13, 2018 at 4:41 PM, Mike Larkin wrote: > > > 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 > > >> > 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 = 0x000d13"" > > >> > ebx = 0x756e65471970169159"Genu" > > >> > ecx = 0x6c65746e1818588270"ntel" > > >> > edx = 0x49656e691231384169"ineI" > > >> > bcamp@z97x-sli:~ (OpenBSD 6.2) > > >> > $ cpuid 0x7 > > >> > eax = 0x 0"" > > >> > ebx = 0x27ab 10155"?'??" > > >> > ecx = 0x 0"" > > >> > edx = 0x 0"" > > >> > bcamp@z97x-sli:~ (OpenBSD 6.2) > > >> > $ > > >> > > > >> > Non-working (Celeron J3455) - > > >> > > > >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) > > >> > $ cpuid 0x0 > > >> > eax = 0x001521"" > > >> > ebx = 0x756e65471970169159"Genu" > > >> > ecx = 0x6c65746e1818588270"ntel" > > >> > edx = 0x49656e691231384169"ineI" > > >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) > > >> > $ cpuid 0x7 > > >> > eax = 0x 0"" > > >> > ebx = 0x2294e283 580182659"???"" > > >> > ecx = 0x 0"" > > >> > edx = 0x2c00 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. > > > > Patch applied to -current and the resulting dmesg attached. > > > > >> > > >> 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. > > >> > > > > Thats actually the latest version. Even though this board is made by > > Intel itself, they have yet to release a BIOS update with the patched > > microcode that other OEMs are shipping. > > > > Thanks > > > > -Brian > > > > > > OpenBSD 6.3-beta (GENERIC.MP) #0: Tue Mar 13 18:01:15 CDT 2018 > > > > bc...@nuc6cayh.int.thecamps.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8411357184 (8021MB) > > avail mem = 8149372928 (7771MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x79aa1000 (51 entries) > > bios0: vendor Intel Corp. version "AYAPLCEL.86A.0047.2018.0108.1419" > > date 01/08/2018 > > bios0: Intel Corporation NUC6CAYH > > acpi0 at bios0: rev 2 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP FPDT
Re: Meltdown workaround enabled?
On Tue, Mar 13, 2018 at 7:18 PM, Chris Cappuccio wrote: > Mike Larkin [mlar...@azathoth.net] wrote: >> >> I'm not sure whether or not I believe what your machine is reporting, I was >> under the assumption that new hardware was needed to fix this. Shrug. >> > > There is a public PoC for meltdown and spectre on OpenBSD: > > https://github.com/genua/meltdown > > Here's what it looks like with the current meltdown work-around: > > danka# ./meltdown -qv > CPU has RDTSCP > CPU has TSX > Access time: memory 401, cache 121 -> threshold 261 > Using addr 0x818e4f30 for symbol '_version'. > ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? > matched 0% (0 of 10 bytes) > System is not vulnerable to meltdown > 53 70 65 63 69 ?? 6c 20 45 78 Speci?l Ex > matched 90% (9 of 10 bytes) > System is vulnerable to spectre > > here's a 6.1 system with no patches: > > meltdown# ./meltdown -qv > WARNING: CPU has no RDTSCP support! > CPU has no TSX support! > Access time: memory 347, cache 98 -> threshold 222 > Using addr 0x816bc1a0 for symbol '_version'. > 4f 70 65 6e 42 53 44 20 36 2e OpenBSD 6. > matched 100% (10 of 10 bytes) > System is vulnerable to meltdown > 53 70 65 63 69 61 6c 20 45 78 Special Ex > matched 100% (10 of 10 bytes) > Segmentation fault (core dumped) > Well, I'm thoroughly confused now. Running that PoC on the machine while in -current and even 6.1 (no patches) returns that the system is not vulnerable to meltdown. This processor was made in 2016 and everything I've read indicates that it should be vulnerable. -current (no MELTDOWN printf) - # ./meltdown -v CPU has RDTSCP CPU has no TSX support! Access time: memory 210, cache 91 -> threshold 150 Using addr 0x81a16230 for symbol '_version'. ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0010?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0020?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0030?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0040?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0050?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0060?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0070?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0080?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??? matched 0% (0 of 143 bytes) System is not vulnerable to meltdown 53 70 65 ?? 69 61 6c 20 45 78 65 63 75 74 69 76 Spe?ial Executiv 001065 ?? 66 6f 72 20 43 ?? 75 6e 74 65 72 ?? ?? 74 e?for C?unter??t 0020?? 6c 6c 69 67 65 ?? 63 65 2c 20 ?? 65 72 72 6f ?llige?ce, ?erro 003072 69 73 6d 2c 20 52 ?? 76 65 ?? 67 65 20 ?? 6e rism, R?ve?ge ?n 004064 20 45 78 74 6f 72 74 69 ?? 6e 2e d Extorti?n. matched 84% (64 of 76 bytes) System is vulnerable to spectre 6.1 release without any patches - # ./meltdown -v WARNING: CPU has no RDTSCP support! CPU has no TSX support! Access time: memory 193, cache 76 -> threshold 134 Using addr 0x816bb1a0 for symbol '_version'. ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0010?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0020?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0030?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0040?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0050?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0060?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0070?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0080?? ?? ?? ?? ??? matched 0% (0 of 133 bytes) System is not vulnerable to meltdown 53 70 65 63 69 ?? 6c 20 45 78 65 63 75 74 69 76 Speci?l Executiv 001065 20 66 6f 72 20 ?? 6f 75 6e 74 65 72 69 6e 74 e for ?ounterint 002065 ?? 6c 69 67 65 6e 63 65 ?? 20 54 65 ?? ?? ?? e?ligence? Te??? 003072 ?? 73 6d 2c ?? ?? ?? 76 65 6e 67 65 ?? 61 6e r?sm,???venge?an 004064 20 45 78 74 6f 72 74 69 6f 6e 2e d Extortion. matched 84% (64 of 76 bytes) Segmentation fault (core dumped)
Re: Meltdown workaround enabled?
Mike Larkin [mlar...@azathoth.net] wrote: > > I'm not sure whether or not I believe what your machine is reporting, I was > under the assumption that new hardware was needed to fix this. Shrug. > There is a public PoC for meltdown and spectre on OpenBSD: https://github.com/genua/meltdown Here's what it looks like with the current meltdown work-around: danka# ./meltdown -qv CPU has RDTSCP CPU has TSX Access time: memory 401, cache 121 -> threshold 261 Using addr 0x818e4f30 for symbol '_version'. ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? matched 0% (0 of 10 bytes) System is not vulnerable to meltdown 53 70 65 63 69 ?? 6c 20 45 78 Speci?l Ex matched 90% (9 of 10 bytes) System is vulnerable to spectre here's a 6.1 system with no patches: meltdown# ./meltdown -qv WARNING: CPU has no RDTSCP support! CPU has no TSX support! Access time: memory 347, cache 98 -> threshold 222 Using addr 0x816bc1a0 for symbol '_version'. 4f 70 65 6e 42 53 44 20 36 2e OpenBSD 6. matched 100% (10 of 10 bytes) System is vulnerable to meltdown 53 70 65 63 69 61 6c 20 45 78 Special Ex matched 100% (10 of 10 bytes) Segmentation fault (core dumped)
Re: Meltdown workaround enabled?
On Tue, Mar 13, 2018 at 06:20:16PM -0500, Brian Camp wrote: > On Tue, Mar 13, 2018 at 4:41 PM, Mike Larkin wrote: > > 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 > >> > 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 = 0x000d13"" > >> > ebx = 0x756e65471970169159"Genu" > >> > ecx = 0x6c65746e1818588270"ntel" > >> > edx = 0x49656e691231384169"ineI" > >> > bcamp@z97x-sli:~ (OpenBSD 6.2) > >> > $ cpuid 0x7 > >> > eax = 0x 0"" > >> > ebx = 0x27ab 10155"?'??" > >> > ecx = 0x 0"" > >> > edx = 0x 0"" > >> > bcamp@z97x-sli:~ (OpenBSD 6.2) > >> > $ > >> > > >> > Non-working (Celeron J3455) - > >> > > >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) > >> > $ cpuid 0x0 > >> > eax = 0x001521"" > >> > ebx = 0x756e65471970169159"Genu" > >> > ecx = 0x6c65746e1818588270"ntel" > >> > edx = 0x49656e691231384169"ineI" > >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) > >> > $ cpuid 0x7 > >> > eax = 0x 0"" > >> > ebx = 0x2294e283 580182659"???"" > >> > ecx = 0x 0"" > >> > edx = 0x2c00 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. > > Patch applied to -current and the resulting dmesg attached. > > >> > >> 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. > >> > > Thats actually the latest version. Even though this board is made by > Intel itself, they have yet to release a BIOS update with the patched > microcode that other OEMs are shipping. > > Thanks > > -Brian > > > OpenBSD 6.3-beta (GENERIC.MP) #0: Tue Mar 13 18:01:15 CDT 2018 > bc...@nuc6cayh.int.thecamps.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8411357184 (8021MB) > avail mem = 8149372928 (7771MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x79aa1000 (51 entries) > bios0: vendor Intel Corp. version "AYAPLCEL.86A.0047.2018.0108.1419" > date 01/08/2018 > bios0: Intel Corporation NUC6CAYH > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT > PRAM WSMT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI TPM2 SSDT DMAR WDAT > NHLT > acpi0: wakeup devices SIO1(S3) HDAS(S3) XHC_(S4) XDCI(S4) BRCM(S0) > PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) > RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at
Re: Meltdown workaround enabled?
On Tue, Mar 13, 2018 at 4:41 PM, Mike Larkin wrote: > 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 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 = 0x000d13"" >> > ebx = 0x756e65471970169159"Genu" >> > ecx = 0x6c65746e1818588270"ntel" >> > edx = 0x49656e691231384169"ineI" >> > bcamp@z97x-sli:~ (OpenBSD 6.2) >> > $ cpuid 0x7 >> > eax = 0x 0"" >> > ebx = 0x27ab 10155"?'??" >> > ecx = 0x 0"" >> > edx = 0x 0"" >> > bcamp@z97x-sli:~ (OpenBSD 6.2) >> > $ >> > >> > Non-working (Celeron J3455) - >> > >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) >> > $ cpuid 0x0 >> > eax = 0x001521"" >> > ebx = 0x756e65471970169159"Genu" >> > ecx = 0x6c65746e1818588270"ntel" >> > edx = 0x49656e691231384169"ineI" >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) >> > $ cpuid 0x7 >> > eax = 0x 0"" >> > ebx = 0x2294e283 580182659"???"" >> > ecx = 0x 0"" >> > edx = 0x2c00 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. Patch applied to -current and the resulting dmesg attached. >> >> 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. >> Thats actually the latest version. Even though this board is made by Intel itself, they have yet to release a BIOS update with the patched microcode that other OEMs are shipping. Thanks -Brian OpenBSD 6.3-beta (GENERIC.MP) #0: Tue Mar 13 18:01:15 CDT 2018 bc...@nuc6cayh.int.thecamps.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8411357184 (8021MB) avail mem = 8149372928 (7771MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x79aa1000 (51 entries) bios0: vendor Intel Corp. version "AYAPLCEL.86A.0047.2018.0108.1419" date 01/08/2018 bios0: Intel Corporation NUC6CAYH acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT PRAM WSMT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI TPM2 SSDT DMAR WDAT NHLT acpi0: wakeup devices SIO1(S3) HDAS(S3) XHC_(S4) XDCI(S4) BRCM(S0) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1497.12 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES6
Re: Meltdown workaround enabled?
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 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 = 0x000d13""
> > ebx = 0x756e65471970169159"Genu"
> > ecx = 0x6c65746e1818588270"ntel"
> > edx = 0x49656e691231384169"ineI"
> > bcamp@z97x-sli:~ (OpenBSD 6.2)
> > $ cpuid 0x7
> > eax = 0x 0""
> > ebx = 0x27ab 10155"?'??"
> > ecx = 0x 0""
> > edx = 0x 0""
> > bcamp@z97x-sli:~ (OpenBSD 6.2)
> > $
> >
> > Non-working (Celeron J3455) -
> >
> > bcamp@nuc6cayh:~ (OpenBSD 6.2)
> > $ cpuid 0x0
> > eax = 0x001521""
> > ebx = 0x756e65471970169159"Genu"
> > ecx = 0x6c65746e1818588270"ntel"
> > edx = 0x49656e691231384169"ineI"
> > bcamp@nuc6cayh:~ (OpenBSD 6.2)
> > $ cpuid 0x7
> > eax = 0x 0""
> > ebx = 0x2294e283 580182659"???""
> > ecx = 0x 0""
> > edx = 0x2c00 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 - 1.95
> +++ amd64/identcpu.c 13 Mar 2018 20:32:22 -
> @@ -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(0x8000, 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.S21 Feb 2018 19:24:15 - 1.94
> +++ amd64/locore.S13 Mar 2018 20:28:15 -
> @@ -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 f
Re: Meltdown workaround enabled?
On Tue, Mar 13, 2018 at 08:27:49AM -0500, Brian Camp wrote:
> On Tue, Mar 13, 2018 at 2:29 AM, Mike Larkin 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 = 0x000d13""
> ebx = 0x756e65471970169159"Genu"
> ecx = 0x6c65746e1818588270"ntel"
> edx = 0x49656e691231384169"ineI"
> bcamp@z97x-sli:~ (OpenBSD 6.2)
> $ cpuid 0x7
> eax = 0x 0""
> ebx = 0x27ab 10155"?'??"
> ecx = 0x 0""
> edx = 0x 0""
> bcamp@z97x-sli:~ (OpenBSD 6.2)
> $
>
> Non-working (Celeron J3455) -
>
> bcamp@nuc6cayh:~ (OpenBSD 6.2)
> $ cpuid 0x0
> eax = 0x001521""
> ebx = 0x756e65471970169159"Genu"
> ecx = 0x6c65746e1818588270"ntel"
> edx = 0x49656e691231384169"ineI"
> bcamp@nuc6cayh:~ (OpenBSD 6.2)
> $ cpuid 0x7
> eax = 0x 0""
> ebx = 0x2294e283 580182659"???""
> ecx = 0x 0""
> edx = 0x2c00 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,
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.c21 Feb 2018 19:24:15 - 1.95
+++ amd64/identcpu.c13 Mar 2018 20:32:22 -
@@ -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(0x8000, 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 - 1.94
+++ amd64/locore.S 13 Mar 2018 20:28:15 -
@@ -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
Re: Meltdown workaround enabled?
On 2018-03-13, Brian Camp wrote: > Non-working (Celeron J3455) - > > bcamp@nuc6cayh:~ (OpenBSD 6.2) > $ cpuid 0x0 > eax = 0x001521"" > ebx = 0x756e65471970169159"Genu" > ecx = 0x6c65746e1818588270"ntel" > edx = 0x49656e691231384169"ineI" > bcamp@nuc6cayh:~ (OpenBSD 6.2) > $ cpuid 0x7 > eax = 0x 0"" > ebx = 0x2294e283 580182659"???"" > ecx = 0x 0"" > edx = 0x2c00 738197504"???," ^ It appears the CPU explicitly claims that it is not vulnerable to Meltdown, i.e., it indicates that it has support for the IA32_ARCH_CAPABILITIES register and there the RDCL_NO bit must be set. I find this surprising. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Meltdown workaround enabled?
On Tue, Mar 13, 2018 at 2:29 AM, Mike Larkin 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 = 0x000d13"" ebx = 0x756e65471970169159"Genu" ecx = 0x6c65746e1818588270"ntel" edx = 0x49656e691231384169"ineI" bcamp@z97x-sli:~ (OpenBSD 6.2) $ cpuid 0x7 eax = 0x 0"" ebx = 0x27ab 10155"?'??" ecx = 0x 0"" edx = 0x 0"" bcamp@z97x-sli:~ (OpenBSD 6.2) $ Non-working (Celeron J3455) - bcamp@nuc6cayh:~ (OpenBSD 6.2) $ cpuid 0x0 eax = 0x001521"" ebx = 0x756e65471970169159"Genu" ecx = 0x6c65746e1818588270"ntel" edx = 0x49656e691231384169"ineI" bcamp@nuc6cayh:~ (OpenBSD 6.2) $ cpuid 0x7 eax = 0x 0"" ebx = 0x2294e283 580182659"???"" ecx = 0x 0"" edx = 0x2c00 738197504"???," bcamp@nuc6cayh:~ (OpenBSD 6.2) $ -Brian
Re: Meltdown workaround enabled?
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 > > > OpenBSD 6.2 (GENERIC.MP) #6: Wed Feb 28 21:13:02 CET 2018 > > r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8411357184 (8021MB) > avail mem = 8149352448 (7771MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x79aa1000 (51 entries) > bios0: vendor Intel Corp. version "AYAPLCEL.86A.0047.2018.0108.1419" > date 01/08/2018 > bios0: Intel Corporation NUC6CAYH > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT > PRAM WSMT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI TPM2 SSDT DMAR WDAT > NHLT > acpi0: wakeup devices SIO1(S3) HDAS(S3) XHC_(S4) XDCI(S4) BRCM(S0) > PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) > RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at acpi0 addr 0xe000, bus 0-255 > acpihpet0 at acpi0: 1920 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1497.60 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT > cpu0: 1MB 64b/line 16-way L2 cache > cpu0: TSC frequency 149760 Hz > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 19MHz > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1497.60 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT > cpu1: 1MB 64b/line 16-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1497.60 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT > cpu2: 1MB 64b/line 16-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1497.60 MHz > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT > cpu3: 1MB 64b/line 16-way L2 cache > cpu3: smt 0, core 3, package 0 > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (RP01) > acpiprt2 at acpi0: bus -1 (RP02) > acpiprt3 at acpi0: bus 1 (RP03) > acpiprt4 at acpi0: bus 2 (RP04) > acpiprt5 at acpi0: bus 3 (RP05) > acpiprt6 at acpi0: bus -1 (RP06) > acpiec0 at acpi0 > acpicpu0 at acpi0: C1(@1 halt!), PSS > acpicpu1 at acpi0: C1(@1 halt!), PSS > acpicpu2 at acpi0: C1(@1 halt!), PSS > acpicpu3 at acpi0: C1(@1 halt!), PSS > acpipwrres0 at acpi0: FN00, resource for FAN0 > acpitz0 at acpi0: critical temperature is 100 degC > "ITE8708" at acpi0 not configured > acpibtn0 at acpi0: PWRB > acpibtn1 at acpi0: SLPB > "INT3452" at acpi0 not configured > "INT3452"
