Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2023-07-25, Kevin  wrote:
> > Regarding the Zenbleed vulnerability itself, none of our AMD hosts are
> > known to be vulnerable at this time as they are all running Milan and
> > later CPUs.
> 
> rather than going with "none are known to be vulnerable" they should
> probably run the PoC program themselves and see whether strings from
> other VMs show up

Since they are emulating the behaviour of the DE_CFG register, they should
allow (and ignore) setting that bit, because other operating systems are
going to assume the same.

Hypervisors gotta do stuff like that.
 



Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Theo de Raadt
Kevin  wrote:

> Would this be worth putting a ticket into Vultr to get them to make 
> appropriate
> updates on their side?

You are the customer.



Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Stuart Henderson
On 2023-07-25, Kevin  wrote:
> Regarding the Zenbleed vulnerability itself, none of our AMD hosts are
> known to be vulnerable at this time as they are all running Milan and
> later CPUs.

rather than going with "none are known to be vulnerable" they should
probably run the PoC program themselves and see whether strings from
other VMs show up




Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Kevin
>
> > Just applied the fix to the first affected AMD machine and all is well
> > again.
> >
> > Would this be worth putting a ticket into Vultr to get them to make
> > appropriate updates on their side?
>
> Yes (but I see you already did)
>

Here's the reply I got from Vultr about this:



Thank you for contacting us. We are aware of OpenBSD instances
dropping to ddb upon boot after the initial zenbleed patches went out.
This was fixed as of the 015 patch that was released today:
https://ftp.openbsd.org/pub/OpenBSD/patches/7.3/common/015_hvamdcpu.patch.sig

If you have an OpenBSD instance that is still stuck at ddb and
therefore cannot apply the 015 patch, please let us know, as there is
a manual workaround we can do to get it to boot. After that, you can
run syspatch again which should install that newest patch, and you
should have no issues.

Regarding the Zenbleed vulnerability itself, none of our AMD hosts are
known to be vulnerable at this time as they are all running Milan and
later CPUs. The CPU config provided to guests will say Rome, but that
is provided for compatibility purposes and is not related to the
actual host node CPU.

We are continuing to monitor this vulnerability, and will be taking
appropriate steps to mitigate it once the full impact has been
determined.



Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Mike Larkin
On Tue, Jul 25, 2023 at 10:42:25AM -0700, Kevin wrote:
> On Tue, Jul 25, 2023 at 7:42 AM Theo de Raadt  wrote:
>
> > It seems some of the smaller hypervisor companies didn't get the memo,
> > and they are blocking the msr write to to set the chicken bit.
> >
> > They block it by raising an exception.
> > They should IGNORE that bit if they allow setting it.
> >
> > I also have a strong suspicion some of them do not have the firmware
> > fixes, and that the chickenbit-off state we read is true.
> >
> > Anyways, a brand new errata to skip setting the chickenbit on such
> > hypervisors is going out the door right now.
> >
>
>
> I just fucking love you guys.
>
> Thank you.
>
> Just applied the fix to the first affected AMD machine and all is well
> again.
>
> Would this be worth putting a ticket into Vultr to get them to make
> appropriate updates on their side?

Yes (but I see you already did)



Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Jag Talon

I made a ticket with Vultr I believe they already know about it!

I just fucking love you guys.

Thank you.

Just applied the fix to the first affected AMD machine and all is well
again.

Would this be worth putting a ticket into Vultr to get them to make
appropriate updates on their side?




Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Kevin
On Tue, Jul 25, 2023 at 7:42 AM Theo de Raadt  wrote:

> It seems some of the smaller hypervisor companies didn't get the memo,
> and they are blocking the msr write to to set the chicken bit.
>
> They block it by raising an exception.
> They should IGNORE that bit if they allow setting it.
>
> I also have a strong suspicion some of them do not have the firmware
> fixes, and that the chickenbit-off state we read is true.
>
> Anyways, a brand new errata to skip setting the chickenbit on such
> hypervisors is going out the door right now.
>


I just fucking love you guys.

Thank you.

Just applied the fix to the first affected AMD machine and all is well
again.

Would this be worth putting a ticket into Vultr to get them to make
appropriate updates on their side?


Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Jag Talon

Everything is working after the newest patch! Thank you all!

On 7/25/23 11:18 AM, Jag Talon wrote:
I ran into the same issue with the "2048.00 MB AMD High Performance, 2 
vCPU" on my end. Fortunately I had a snapshot and I was able to roll 
back.


Here's my dmesg output if that's helpful:

OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2130558976 (2031MB)
avail mem = 2046648320 (1951MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b70 (9 entries)
bios0: vendor Vultr
bios0: Vultr VHP
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC-Rome Processor, 1996.53 MHz, 17-31-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache

cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD EPYC-Rome Processor, 1996.51 MHz, 17-31-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache

cpu1: smt 1, core 0, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xb000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
acpicmos0 at acpi0
"ACPI0010" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: KVM
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00
vga1 at pci0 dev 1 function 0 "Bochs VGA" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci1 at ppb0 bus 1
virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01
vio0 at virtio0: address 56:00:04:81:d8:d4
virtio0: msix shared
ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci2 at ppb1 bus 2
ppb2 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000e 
rev 0x00

pci3 at ppb2 bus 3
"Intel 6300ESB WDT" rev 0x00 at pci3 dev 1 function 0 not configured
ppb3 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci4 at ppb3 bus 4
xhci0 at pci4 dev 0 function 0 vendor "Red Hat", unknown product 
0x000d rev 0x01: apic 0 int 22, xHCI 0.0

usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev 
3.00/1.00 addr 1
ppb4 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci5 at ppb4 bus 5
virtio1 at pci5 dev 0 function 0 "Qumranet Virtio 1.x Storage" rev 0x01
vioblk0 at virtio1
scsibus1 at vioblk0: 1 targets
sd0 at scsibus1 targ 0 lun 0: 
sd0: 61440MB, 512 bytes/sector, 125829120 sectors
virtio1: msix per-VQ
ppb5 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci6 at ppb5 bus 6
virtio2 at pci6 dev 0 function 0 vendor "Qumranet", unknown product 
0x1045 rev 0x01

viomb0 at virtio2
virtio2: apic 0 int 22
ppb6 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci7 at ppb6 bus 7
virtio3 at pci7 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01
viornd0 at virtio3
virtio3: msix shared
ppb7 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci8 at ppb7 bus 8
ppb8 at pci0 dev 2 function 7 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci9 at 

Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Maksym Sheremet
On Mon, Jul 24, 2023 at 11:37:12PM -0700, Kevin wrote:
> After applying today's zenbleed patches and running fw_update and
> installboot -v sd0, ALL of our AMD servers running 7.3 at Vultr that
> were--as part of the patch process--rebooted are now dead in the water and
> won't boot.
> 

I experienced the same issue with Hetzner VPS. Booting previous kernel
did the trick for me.

OpenBSD 7.3 (GENERIC.MP) #2: Mon Jul 24 13:01:48 MDT 2023

r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4177379328 (3983MB)
avail mem = 4031373312 (3844MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5ab0 (11 entries)
bios0: vendor Hetzner version "2017" date 11/11/2017
bios0: Hetzner vServer
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC Processor, 2445.68 MHz, 17-31-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache,
512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
kernel: protection fault trap, code=0
Stopped at  cpu_fix_msrs+0x1a4: wrmsr   
ddb{0}> rebooting...
OpenBSD 7.3 (GENERIC.MP) #0: Wed Jul 12 05:09:49 MDT 2023

r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4177379328 (3983MB)
avail mem = 4031361024 (3844MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5ab0 (11 entries)
bios0: vendor Hetzner version "2017" date 11/11/2017
bios0: Hetzner vServer
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC Processor, 2445.62 MHz, 17-31-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD EPYC Processor, 2446.02 MHz, 17-31-00
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD EPYC Processor, 2445.66 MHz, 17-31-00
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xb000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
acpicmos0 at acpi0
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured

Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Jag Talon
I ran into the same issue with the "2048.00 MB AMD High Performance, 2 
vCPU" on my end. Fortunately I had a snapshot and I was able to roll back.


Here's my dmesg output if that's helpful:

OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2130558976 (2031MB)
avail mem = 2046648320 (1951MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b70 (9 entries)
bios0: vendor Vultr
bios0: Vultr VHP
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC-Rome Processor, 1996.53 MHz, 17-31-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache

cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD EPYC-Rome Processor, 1996.51 MHz, 17-31-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache

cpu1: smt 1, core 0, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xb000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
acpicmos0 at acpi0
"ACPI0010" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: KVM
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00
vga1 at pci0 dev 1 function 0 "Bochs VGA" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci1 at ppb0 bus 1
virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01
vio0 at virtio0: address 56:00:04:81:d8:d4
virtio0: msix shared
ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci2 at ppb1 bus 2
ppb2 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000e 
rev 0x00

pci3 at ppb2 bus 3
"Intel 6300ESB WDT" rev 0x00 at pci3 dev 1 function 0 not configured
ppb3 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci4 at ppb3 bus 4
xhci0 at pci4 dev 0 function 0 vendor "Red Hat", unknown product 0x000d 
rev 0x01: apic 0 int 22, xHCI 0.0

usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev 
3.00/1.00 addr 1
ppb4 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci5 at ppb4 bus 5
virtio1 at pci5 dev 0 function 0 "Qumranet Virtio 1.x Storage" rev 0x01
vioblk0 at virtio1
scsibus1 at vioblk0: 1 targets
sd0 at scsibus1 targ 0 lun 0: 
sd0: 61440MB, 512 bytes/sector, 125829120 sectors
virtio1: msix per-VQ
ppb5 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci6 at ppb5 bus 6
virtio2 at pci6 dev 0 function 0 vendor "Qumranet", unknown product 
0x1045 rev 0x01

viomb0 at virtio2
virtio2: apic 0 int 22
ppb6 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci7 at ppb6 bus 7
virtio3 at pci7 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01
viornd0 at virtio3
virtio3: msix shared
ppb7 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci8 at ppb7 bus 8
ppb8 at pci0 dev 2 function 7 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 22

pci9 at ppb8 bus 9
ppb9 at pci0 dev 3 function 0 vendor "Red Hat", unknown product 0x000c 
rev 0x00: apic 0 int 

Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Theo de Raadt
Snapshots got that diff about 8 hours earlier.

> For what it’s worth, my Vultr VPS machine is running snapshots and updated
> without issue.
> 
> Hope this helps as a clue!
> 
> On Tue, Jul 25, 2023 at 10:45 AM Theo de Raadt  wrote:
> 
> > It seems some of the smaller hypervisor companies didn't get the memo,
> > and they are blocking the msr write to to set the chicken bit.
> >
> > They block it by raising an exception.
> > They should IGNORE that bit if they allow setting it.
> >
> > I also have a strong suspicion some of them do not have the firmware
> > fixes, and that the chickenbit-off state we read is true.
> >
> > Anyways, a brand new errata to skip setting the chickenbit on such
> > hypervisors is going out the door right now.
> >
> >
> > --
> RD



Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Ronald Dahlgren
For what it’s worth, my Vultr VPS machine is running snapshots and updated
without issue.

Hope this helps as a clue!

On Tue, Jul 25, 2023 at 10:45 AM Theo de Raadt  wrote:

> It seems some of the smaller hypervisor companies didn't get the memo,
> and they are blocking the msr write to to set the chicken bit.
>
> They block it by raising an exception.
> They should IGNORE that bit if they allow setting it.
>
> I also have a strong suspicion some of them do not have the firmware
> fixes, and that the chickenbit-off state we read is true.
>
> Anyways, a brand new errata to skip setting the chickenbit on such
> hypervisors is going out the door right now.
>
>
> --
RD


Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

2023-07-25 Thread Theo de Raadt
It seems some of the smaller hypervisor companies didn't get the memo,
and they are blocking the msr write to to set the chicken bit.

They block it by raising an exception.
They should IGNORE that bit if they allow setting it.

I also have a strong suspicion some of them do not have the firmware
fixes, and that the chickenbit-off state we read is true.

Anyways, a brand new errata to skip setting the chickenbit on such
hypervisors is going out the door right now.