Re: Another kernel fault incident on a Vultr OpenBSD VM

[Philipp Buehler]

Am 16.04.2022 01:31 schrieb open...@maniaphobic.org:

the representative told me, "OpenBSD has very
special configurations that are required on our end to work properly
with our virtualization software". It lowers my confidence in Vultr as
a reliable OpenBSD host.


Crucial question (likely on behalf all of those looking):
* and WHAT configuration is that? *

regards,
--
pb

Another kernel fault incident on a Vultr OpenBSD VM

[openbsd]

Hi all,

I'm posting this for the benefit of OpenBSD community members hosting 
virtual machines on Vultr.


I encountered the same failure that Claus A. reported in December:


cd*.iso reboot loop (vultr, Skylake AVX MDS)
https://www.mail-archive.com/misc@openbsd.org/msg180415.html


To summarize, the VM halts with this kernel fault during boot, shortly 
before running fsck:



kernel: privileged instruction fault trap, code=0
Stopped at  mds_handler_skl_avx+0x33:  clflush 
__ALIGN_SIZE+0x500(%rid,%rax,8)



It then drops in to ddb.

As in Claus's case, the solution was to ask Vultr support to migrate the 
guest to another hypervisor. The representative assigned to my case was 
unable to explain the root cause.


This is the second incident in the past month that resulted in a lengthy 
service outage caused by a Vultr misconfiguration. In the previous 
incident, the representative told me, "OpenBSD has very special 
configurations that are required on our end to work properly with our 
virtualization software". It lowers my confidence in Vultr as a reliable 
OpenBSD host.

Re: Question about /etc/resolvd.conf and local resolver

[J Doe]

On 2022-04-13 02:42, Stuart Henderson wrote:


On 2022-04-13, J Doe  wrote:

For people reading this thread ...

/etc/resolv.conf is the traditional file for configuring the system
resolver(s) while /etc/resolvd.conf is the configuration file for the
resolvd *daemon*, which is also involved in the configuration of the
system resolver(s).


There is no resolvd.conf, resolvd configures itself automatically


Hi Stuart,

You're correct again - I really seem to have a fixation on confusing 
resolv.conf and resolvd functionality don't I, ha ha ?


Apologies list and thanks again Stuart,

- J

Re: Spamd as a proxy

[Stuart Henderson]

On 2022-04-15, alejan...@rogue-research.com  
wrote:
> Hi Mr Hansteen,
>
> Thanks for the reply, I started my journey with OpenBSD this week and I 
> decided to buy your book to help me understand its PF system, it's been 
> very helpful. I've been reading man pages from pf,spamd,opensmtpd and 
> sysctl, perhaps I just need more reading and time to fully understand 
> what is wrong with my setup.
>
> Since I am using 2 hosts (1 antispamer, 1 smtp server) on the same LAN, 
> I thought `rdr-to` would not work as stated on: 
>, under the section 
> "Redirection and Reflection" which is why I used `divert-to`. But 
> neither work, thus, I am left with no ideas as of how to forward the 
> emails from the antispam machine to the email server.
>
> What's different from all the docs and examples I've found is that I'm 
> trying to use two hosts, and everything I've seen seems to assume spamd 
> and the smtp server are on the same host. If `rdr-to` is not the way to 
> go, how must I overcome this challenge?

spamd expects to either be on the same host as the real SMTP service,
or on a router/firewall in front of that host. the only way to do proxy
like this on a host in a subnet alongside the smtp server (with another
firewall "in front") is to rdr *and* nat. but for obvious reasons you
really want the SMTP service to see the original source IP so nat isn't
much help...

Re: time drift in OpenBSD in proxmox (qemu-kvm) guest

[Stuart Henderson]

On 2022/04/15 22:02, Tom Smyth wrote:
> Hello Stuart,
> What is the EFI / BIOS  Power management / CPU power management
> Performance setting set to  ?
> if the CPU is throttled back (due to low usage) is that affecting the
> time keeping ?
> It might be worth trying OS Controlled or Performance (as a test)
> it may be set to power saving or balanced
> 
> I hope this helps,
> ( and thanks for your patience with my previous impulsive (albeit
> trying to help) replies earlier

Thanks for the suggestions - since the change I made in the last mail
("I've changed mine to acpihpet0 and it seems much happier", i.e. setting
the kern.timecounter.hardware sysctl to acpihpet0, based on Stefan's
pointer) the time has stayed in sync.

The machine is on what looks like the closest thing to "power saving"
(option in machine config is "best experience") - since I leave this
machine turned on, at around 0.30GBP/kWh power cost, and often with
only ~50% of power generation where I live being low carbon unless
it's particularly windy (https://www.carbonintensity.org.uk/#regional,
https://www.gridwatch.templar.co.uk/) I'd like to keep it like that
if possible :)


> On Fri, 15 Apr 2022 at 11:12, Stuart Henderson
>  wrote:
> >
> > On 2022-04-14, Stefan Sperling  wrote:
> > > On Thu, Apr 14, 2022 at 09:26:41PM -, Stuart Henderson wrote:
> > >> I have some OpenBSD guests in Proxmox VE 7.1-7 (pve-qemu-kvm_6.1.0) and
> > >> seeing pretty bad clock drift (50 seconds in ~7h uptime). ntpd can't cope
> > >> with it. From boot:
> > >>
> > >> 2022-04-14T13:58:19.844Z  ntpd[26996]: adjusting local clock by 1.745061s
> > >> 2022-04-14T13:59:24.070Z  ntpd[26996]: adjusting local clock by 1.504470s
> > >> 2022-04-14T14:03:51.176Z  ntpd[26996]: adjusting local clock by 2.430486s
> > >> 2022-04-14T14:07:40.299Z  ntpd[26996]: adjusting local clock by 2.48s
> > >> 2022-04-14T14:11:51.540Z  ntpd[26996]: adjusting local clock by 3.173884s
> > >> 2022-04-14T14:15:03.534Z  ntpd[26996]: adjusting local clock by 3.109722s
> > >> 2022-04-14T14:16:04.848Z  ntpd[26996]: adjusting local clock by 3.185755s
> > >> 2022-04-14T14:17:40.286Z  ntpd[26996]: adjusting local clock by 3.575126s
> > >> 2022-04-14T14:18:45.582Z  ntpd[26996]: adjusting local clock by 4.231518s
> > >> 2022-04-14T14:22:27.618Z  ntpd[26996]: adjusting local clock by 4.231999s
> > >> 2022-04-14T14:25:41.618Z  ntpd[26996]: adjusting local clock by 4.844904s
> > >> 2022-04-14T14:29:58.888Z  ntpd[26996]: adjusting local clock by 4.451876s
> > >> 2022-04-14T14:32:41.628Z  ntpd[26996]: adjusting local clock by 5.250357s
> > >>
> > >> etc. No difference whether qemu-ga is used or not. No difference between
> > >> passing through the real cpu type (i.e. cpu=host, Ryzen 5650G in this 
> > >> case)
> > >> and passing through as "common KVM processor". The guest does detect and
> > >> use pvclock(4).
> > >>
> > >> $ sysctl kern.timecounter
> > >> kern.timecounter.tick=1
> > >> kern.timecounter.timestepwarnings=0
> > >> kern.timecounter.hardware=pvclock0
> > >> kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) 
> > >> acpitimer0(1000)
> > >>
> > >> Anyone have ideas of things I could try that are less wrong than
> > >> running rdate from cron? Thanks.
> > >
> > > I have a -current built-a-week-ago guest on stock Debian KVM, no problems
> > > with time-keeping. It picks acpihpet as timecounter instead of pvclock:
> > >
> > > $ sysctl kern.timecounter
> > > kern.timecounter.tick=1
> > > kern.timecounter.timestepwarnings=0
> > > kern.timecounter.hardware=acpihpet0
> > > kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) 
> > > acpitimer0(1000)
> >
> > Interesting - I would have expected the opposite. I've changed mine to
> > acpihpet0 and it seems much happier. Your value of 500 indicates that the
> > PVCLOCK_TSC_STABLE flag wasn't set by the host, I guess that's dependent
> > on host cpu features.
> >
> > Summarising other responses:
> >
> > - Q35 vs i440FX emulated hw setting: no difference
> > - AMD EPYC performance tuning guide: cpu load is pretty low, I think this
> > is unlikely to be relevant
> > - kvm_intel/parameters/preemption_timer: seems Intel-only and reports are
> > that it's not needed for newer KVM
> >
> >
> 
> 
> -- 
> Kindest regards,
> Tom Smyth.

Re: Spamd as a proxy

[alejandro]

Hi Mr Hansteen,

Thanks for the reply, I started my journey with OpenBSD this week and I 
decided to buy your book to help me understand its PF system, it's been 
very helpful. I've been reading man pages from pf,spamd,opensmtpd and 
sysctl, perhaps I just need more reading and time to fully understand 
what is wrong with my setup.


Since I am using 2 hosts (1 antispamer, 1 smtp server) on the same LAN, 
I thought `rdr-to` would not work as stated on: 
, under the section 
"Redirection and Reflection" which is why I used `divert-to`. But 
neither work, thus, I am left with no ideas as of how to forward the 
emails from the antispam machine to the email server.


What's different from all the docs and examples I've found is that I'm 
trying to use two hosts, and everything I've seen seems to assume spamd 
and the smtp server are on the same host. If `rdr-to` is not the way to 
go, how must I overcome this challenge?




On 2022-04-15 14:11, Peter Nicolai Mathias Hansteen wrote:

15. apr. 2022 kl. 19:56 skrev alejan...@rogue-research.com:

Greetings everyone,
First time posting here and so bear with me please :)
I have a mail server I don't want to touch; I want to set up another 
machine in front of it running spamd.
I have tried using `rdr-to` instead of `divert-to` but neither seem to 
work

This is what my pf rules look like in "/etc/pf.conf"
```
table  persist
table  persist file "/etc/mail/nospamd"

# Incoming connections that are whitelisted/nospamd go directly to the 
smtp server
pass in quick log (all, to pflog0) on egress proto tcp from { 
  } \

to any port smtp divert-to mailserver.domain.com port smtp


No. Please read the man page. You do not need divert-to here. If you
do need it, your network design is wrong.

Try looking up http://home.nuug.no/~peter/pftutorial/#52
 (or better yet for me, buy
the book :))

All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: time drift in OpenBSD in proxmox (qemu-kvm) guest

[Tom Smyth]

Hello Stuart,
What is the EFI / BIOS  Power management / CPU power management
Performance setting set to  ?
if the CPU is throttled back (due to low usage) is that affecting the
time keeping ?
It might be worth trying OS Controlled or Performance (as a test)
it may be set to power saving or balanced

I hope this helps,
( and thanks for your patience with my previous impulsive (albeit
trying to help) replies earlier

Tom Smyth

On Fri, 15 Apr 2022 at 11:12, Stuart Henderson
 wrote:
>
> On 2022-04-14, Stefan Sperling  wrote:
> > On Thu, Apr 14, 2022 at 09:26:41PM -, Stuart Henderson wrote:
> >> I have some OpenBSD guests in Proxmox VE 7.1-7 (pve-qemu-kvm_6.1.0) and
> >> seeing pretty bad clock drift (50 seconds in ~7h uptime). ntpd can't cope
> >> with it. From boot:
> >>
> >> 2022-04-14T13:58:19.844Z  ntpd[26996]: adjusting local clock by 1.745061s
> >> 2022-04-14T13:59:24.070Z  ntpd[26996]: adjusting local clock by 1.504470s
> >> 2022-04-14T14:03:51.176Z  ntpd[26996]: adjusting local clock by 2.430486s
> >> 2022-04-14T14:07:40.299Z  ntpd[26996]: adjusting local clock by 2.48s
> >> 2022-04-14T14:11:51.540Z  ntpd[26996]: adjusting local clock by 3.173884s
> >> 2022-04-14T14:15:03.534Z  ntpd[26996]: adjusting local clock by 3.109722s
> >> 2022-04-14T14:16:04.848Z  ntpd[26996]: adjusting local clock by 3.185755s
> >> 2022-04-14T14:17:40.286Z  ntpd[26996]: adjusting local clock by 3.575126s
> >> 2022-04-14T14:18:45.582Z  ntpd[26996]: adjusting local clock by 4.231518s
> >> 2022-04-14T14:22:27.618Z  ntpd[26996]: adjusting local clock by 4.231999s
> >> 2022-04-14T14:25:41.618Z  ntpd[26996]: adjusting local clock by 4.844904s
> >> 2022-04-14T14:29:58.888Z  ntpd[26996]: adjusting local clock by 4.451876s
> >> 2022-04-14T14:32:41.628Z  ntpd[26996]: adjusting local clock by 5.250357s
> >>
> >> etc. No difference whether qemu-ga is used or not. No difference between
> >> passing through the real cpu type (i.e. cpu=host, Ryzen 5650G in this case)
> >> and passing through as "common KVM processor". The guest does detect and
> >> use pvclock(4).
> >>
> >> $ sysctl kern.timecounter
> >> kern.timecounter.tick=1
> >> kern.timecounter.timestepwarnings=0
> >> kern.timecounter.hardware=pvclock0
> >> kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) 
> >> acpitimer0(1000)
> >>
> >> Anyone have ideas of things I could try that are less wrong than
> >> running rdate from cron? Thanks.
> >
> > I have a -current built-a-week-ago guest on stock Debian KVM, no problems
> > with time-keeping. It picks acpihpet as timecounter instead of pvclock:
> >
> > $ sysctl kern.timecounter
> > kern.timecounter.tick=1
> > kern.timecounter.timestepwarnings=0
> > kern.timecounter.hardware=acpihpet0
> > kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) 
> > acpitimer0(1000)
>
> Interesting - I would have expected the opposite. I've changed mine to
> acpihpet0 and it seems much happier. Your value of 500 indicates that the
> PVCLOCK_TSC_STABLE flag wasn't set by the host, I guess that's dependent
> on host cpu features.
>
> Summarising other responses:
>
> - Q35 vs i440FX emulated hw setting: no difference
> - AMD EPYC performance tuning guide: cpu load is pretty low, I think this
> is unlikely to be relevant
> - kvm_intel/parameters/preemption_timer: seems Intel-only and reports are
> that it's not needed for newer KVM
>
>


-- 
Kindest regards,
Tom Smyth.

Spamd as a proxy

[alejandro]

Greetings everyone,
First time posting here and so bear with me please :)
I have a mail server I don't want to touch; I want to set up another 
machine in front of it running spamd.
I have tried using `rdr-to` instead of `divert-to` but neither seem to 
work

This is what my pf rules look like in "/etc/pf.conf"
```
table  persist
table  persist file "/etc/mail/nospamd"

# Incoming connections that are whitelisted/nospamd go directly to the 
smtp server
pass in quick log (all, to pflog0) on egress proto tcp from {  
 } \

to any port smtp divert-to mailserver.domain.com port smtp

# Divert unknown tcp connections with destination port 25 to spamd
pass in quick log (all, to pflog0) on egress proto tcp from any to any 
port smtp divert-to 127.0.0.1 port spamd

```
I have enabled packet forwarding with `doas sysctl 
net.inet.ip.forwarding: 0 -> 1`


I am using `nc` to test my connection with the real smtp server through 
the antispam server but I am getting connection timeout every time.
When I check the logs, I can see the client sends a first SYN packets to 
the antispam and from there the packets get forwarded to the smtp 
server, but I don’t see any replies from the smtp server. There are no 
rules on the smtp server blocking the connections from my client and 
this is all done locally.

Can anyone help me? Any ideas as of why my set up is not working?

Re: time drift in OpenBSD in proxmox (qemu-kvm) guest

[Stuart Henderson]

On 2022-04-14, Stefan Sperling  wrote:
> On Thu, Apr 14, 2022 at 09:26:41PM -, Stuart Henderson wrote:
>> I have some OpenBSD guests in Proxmox VE 7.1-7 (pve-qemu-kvm_6.1.0) and
>> seeing pretty bad clock drift (50 seconds in ~7h uptime). ntpd can't cope
>> with it. From boot:
>> 
>> 2022-04-14T13:58:19.844Z  ntpd[26996]: adjusting local clock by 1.745061s
>> 2022-04-14T13:59:24.070Z  ntpd[26996]: adjusting local clock by 1.504470s
>> 2022-04-14T14:03:51.176Z  ntpd[26996]: adjusting local clock by 2.430486s
>> 2022-04-14T14:07:40.299Z  ntpd[26996]: adjusting local clock by 2.48s
>> 2022-04-14T14:11:51.540Z  ntpd[26996]: adjusting local clock by 3.173884s
>> 2022-04-14T14:15:03.534Z  ntpd[26996]: adjusting local clock by 3.109722s
>> 2022-04-14T14:16:04.848Z  ntpd[26996]: adjusting local clock by 3.185755s
>> 2022-04-14T14:17:40.286Z  ntpd[26996]: adjusting local clock by 3.575126s
>> 2022-04-14T14:18:45.582Z  ntpd[26996]: adjusting local clock by 4.231518s
>> 2022-04-14T14:22:27.618Z  ntpd[26996]: adjusting local clock by 4.231999s
>> 2022-04-14T14:25:41.618Z  ntpd[26996]: adjusting local clock by 4.844904s
>> 2022-04-14T14:29:58.888Z  ntpd[26996]: adjusting local clock by 4.451876s
>> 2022-04-14T14:32:41.628Z  ntpd[26996]: adjusting local clock by 5.250357s
>> 
>> etc. No difference whether qemu-ga is used or not. No difference between
>> passing through the real cpu type (i.e. cpu=host, Ryzen 5650G in this case)
>> and passing through as "common KVM processor". The guest does detect and
>> use pvclock(4).
>> 
>> $ sysctl kern.timecounter
>> kern.timecounter.tick=1
>> kern.timecounter.timestepwarnings=0
>> kern.timecounter.hardware=pvclock0
>> kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) 
>> acpitimer0(1000)
>> 
>> Anyone have ideas of things I could try that are less wrong than
>> running rdate from cron? Thanks.
>
> I have a -current built-a-week-ago guest on stock Debian KVM, no problems
> with time-keeping. It picks acpihpet as timecounter instead of pvclock:
>
> $ sysctl kern.timecounter 
> kern.timecounter.tick=1
> kern.timecounter.timestepwarnings=0
> kern.timecounter.hardware=acpihpet0
> kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) 
> acpitimer0(1000)

Interesting - I would have expected the opposite. I've changed mine to
acpihpet0 and it seems much happier. Your value of 500 indicates that the
PVCLOCK_TSC_STABLE flag wasn't set by the host, I guess that's dependent
on host cpu features.

Summarising other responses:

- Q35 vs i440FX emulated hw setting: no difference
- AMD EPYC performance tuning guide: cpu load is pretty low, I think this
is unlikely to be relevant
- kvm_intel/parameters/preemption_timer: seems Intel-only and reports are
that it's not needed for newer KVM
 

Re: IKEV2 two devices can connect but only one can make traffic

[Stuart Henderson]

On 2022-04-12, Łukasz Moskała  wrote:
> I remember talking with network engineer at one company I used to work at.
> We used fortigate firewalls, and I asked why are we using SSLVPN instead of 
> ipsec-based vpn, as both were supported.
>
> He said something along the lines of "ipsec does not work when there are two 
> devices connecting from the same IP so this would be issue for us when two 
> admins were on the same public wifi, or lived together"
>
> I don't know if this is specific to fortinet's implementation, or if it's 
> issue with ipsec itself, as I never used ipsec in anything else than 
> site-to-site connection.

This is not the case with IPsec with NAT-T.


-- 
Please keep replies on the mailing list.

Re: Thinkpad T530 touchpad 3-taps word-wise selection not working

[Ulf Brosziewski]

There is a bug in the tapping mechanism of the input driver, which affects
exactly this type of input (the sequence of two taps and a third touch
for dragging).  It generates a button-up event too early.  I'm preparing
a patch.

On 4/13/22 16:46, u...@mailo.com wrote:
> Mouse/touchpad text selection modes:
> character-wise
>   1 button press, then drag
>   2 taps, then drag
> word-wise
>   2 button presses, then drag
>   3 taps, then drag
> line-wise
>   3 button presses, then drag
>   4 taps, then drag
> 
> With touchpad physical buttons, all modes work fine,
> whereas when tapping:
> character-wise and line-wise work fine
> but word-wise doesn't - only the first word gets selected,
> the following moves of the finger across the touchpad have no effect.
> 
> Also asked to no avail here:
> https://www.unitedbsd.com/d/657-touchpad-3-tap-continuous-selection-not-working
> 
> 
> cat /var/run/dmesg.boot
> OpenBSD 7.0 (GENERIC.MP) #5: Mon Jan 31 09:09:02 MST 2022
> 
> r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16845557760 (16065MB)
> avail mem = 16318992384 (15563MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (66 entries)
> bios0: vendor LENOVO version "G4ETB7WW (2.77 )" date 09/09/2019
> bios0: LENOVO 2392APU
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT ASF! HPET APIC MCFG ECDT 
> FPDT UEFI UEFI POAT SSDT SSDT UEFI DBG2
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) 
> EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.50 MHz, 06-3a-09
> 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.29 MHz, 06-3a-09
> 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.29 MHz, 06-3a-09
> 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.29 MHz, 06-3a-09
> 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpiec0 at acpi0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG_)
> acpiprt2 at acpi0: bus 2 (EXP1)
> acpiprt3 at acpi0: bus 3 (EXP2)
> acpiprt4 at acpi0: bus 4 (EXP3)
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpicmos0 at acpi0
> acpibat0 at acpi0: BAT0 not present
> acpiac0 at acpi0: AC unit online
> "LEN0078" at acpi0 not configured
> acpithinkpad0 at acpi0: version 1.0
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> acpicpu0 at acpi0: C2(350@80 mwait.1@0x20),