Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
Good morning Why don’t you add https://www.pcengines.ch/wle200nx.htm as your wifi card to your apu? It is supported by the athn driver and from experience, I know it works. This reduces your need for the bridge construct. > Am 25.01.2019 um 04:54 schrieb William Ahern : > > 4
Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
On Thu, Jan 24, 2019 at 04:55:50PM -0600, John Page wrote: > This is my first attempt at a router. Liberally borrowing from tutorials > and reading Absolute OpenBSD, 2nd Edition and Building Linux and OpenBSD > Firewalls, I decided on installing OpenBSD 6.4 on a PC Engines apu4. I > had previously been using an Asus RT-86U as both my router and wireless > access point. The apu4 can have wireless capability, but OpenBSD does > not support 802.11ac while the Asus does. So I decided to connect the > Asus to em3 of the apu4 so my wireless Windows 10 computers (both of > which have .ac) and Android phones could connect to the Asus instead of > the apu4 main router. Below is my stab at a network diagram (borrowed > and adapted) and the contents of my configuration files (again, borrowed > and adapted). > > My question is: OK, I understand that people more knowledgeable than I > am say that commercially available consumer-grade routers are not > secure. However, will I still have security risks associated with using > the Asus router when it is behind the OpenBSD/apu4 router? > > Also, any suggestions or comments would be appreciated. WiFi chip firmware is notoriously buggy and exploitable. I chose a Google WiFi router (OnHub AC1900) specifically because it uses TPM-enforced secure boot (like a Chromebook) so rootkits can't survive a reboot--at least theoretically, but the track record is pretty good so far. And just as importantly it automatically updates itself. I don't trust Google not to spy on me, but I do trust them to earnestly keep any wardriving competition at bay by regularly fixing issues and pushing firmware updates. Secure boot and automatic updates means the WiFi security is *reliable* (regardless of whatever that security means), and one less thing to worry about. Keeping the router in bridge mode and running your own DHCP and DNS services, as you're doing, are obviously important. (Like you I have my WiFi router bridged to an APU.) I'm not so cynical to believe Google would implement DPI on their routers, but I find it hard to believe that they could resist, always and forever, capturing DNS metrics. If you're more paranoid than lazy you can setup IPSec tunnels from devices to the gateway. It's ridiculously easy on OpenBSD using isakmpd (L2TP/IPSec) or, especially, iked (IPSec/IKEv2 dynamic addressing). I've been using L2TP/IPSec tunnels when traveling for many years, but haven't bothered at home. IKEv2 dynamic address assignment does away with the need for L2TP (npppd(8)), but I haven't cared to spend the time to reconfigure my existing devices--desktop, personal/family laptops, work laptop, phone. Two caveats: 1) I don't know if it's possible to configure macOS or Windows (and almost certainly not Android or iPhone) to automatically establish a tunnel on your LAN but not elsewhere, so you'd have to remember to explicitly enable it regularly; and 2) while I think macOS (and iPhone?) finally got solid IKEv2 support in the past couple of years, I think Android might still only support IKEv1 and L2TP/IPSec VPNs. Rant: Android and Linux people seem to be going crazy about Wireguard, but Wireguard completely avoids the most difficult and complex aspect of running VPNs--key management and routing. Of *course* Wireguard is clean and simple; it avoids attempting to solve the dirty part, the most criticial part, the part that cries out for automation. What you see are people throwing together horrendous, ad hoc scripts for managing PKI and dynamic addressing and routing issues which hopelessly poor imitations of IKE if perhaps a step up from OpenVPN. Those hacks will only keep getting worse and more complex over time, recapitulating all the same mistakes, whereas IKE has reached the point where some of the complexity can be pared back. I won't be surprised when an IKE extension is published for establishing dynamic Wireguard flows. In the meantime there'll be (and already is!) a flood of proprietary, incompatible policy management daemons, just like with SSL VPNs. Next thing you know some big corporation will foist a TCP replacement upon everybody because TCP is too old and hoary, and who doesn't want to run an entire networking stack in each and every process that uses the network, completely divorced from the entire stack of existing network management (including non-invasive management) software and protocols. Also because of security, except let's gratuitously toss in an easily abused, totally insecure RTT feature to mitigate horrendous request latencies induced by the very same [ad] company complaining about performance.
Re: i386 release build machines
There's an image in the bottom left of the OpenBSD website that shows the server rack where all releases and ports are built. It was taken in 2009, so it's probably changed a bit since then, but you'll get a good idea of what is used. I've toyed with the idea of using an old, heat-belching computer to build snapshots over and over again, and use a fan to push out the resulting heat. Not sure how it would go with heating a room, but it would certainly use less energy than a standard space heater, albeit probably a bit noisier. If it weren't for the fact that it sounds like a 747 on take off, that's what I'd do with my SunFire V210. Also, you might want to check your SPF records - GMail is complaining about not being able to verify its authenticity. On Fri, Jan 25, 2019 at 6:45 AM Luis Coronado wrote: > > What machines (brand/model/specs) do you guys > use to create the releases/snapshots for i386? I am curious to find out if > possible as I would think that the bigger boxes out there even though could > have more than 4G of RAM the extra would go unused. > > I recently got a few old 32 bit servers and thought about building my own > snapshots just because is cool to do that. Not that matters exactly what > the project uses but I am sure you guys expect to have a build ready in a > reasonable time. > > Thanks > > -luis -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
This is my first attempt at a router. Liberally borrowing from tutorials
and reading Absolute OpenBSD, 2nd Edition and Building Linux and OpenBSD
Firewalls, I decided on installing OpenBSD 6.4 on a PC Engines apu4. I
had previously been using an Asus RT-86U as both my router and wireless
access point. The apu4 can have wireless capability, but OpenBSD does
not support 802.11ac while the Asus does. So I decided to connect the
Asus to em3 of the apu4 so my wireless Windows 10 computers (both of
which have .ac) and Android phones could connect to the Asus instead of
the apu4 main router. Below is my stab at a network diagram (borrowed
and adapted) and the contents of my configuration files (again, borrowed
and adapted).
My question is: OK, I understand that people more knowledgeable than I
am say that commercially available consumer-grade routers are not
secure. However, will I still have security risks associated with using
the Asus router when it is behind the OpenBSD/apu4 router?
Also, any suggestions or comments would be appreciated.
Thanks
John
apu4 router (running OpenBSD 6.4 -stable)
--→
the internal interface
.-.---.
| | em3 | -→ Asus router -→ Windows 10 and
| bridge0 | (no ip) |(RT-AC86U) Android clients
| '---'
| | em2 | static (fixed) via MAC address
'--. | (no ip) | -→ 192.168.1.3 OpenBSD only
| vether0| '---'
|dhcpd | | em1 | static (fixed) via MAC address
| 192.168.1.1 | | (no ip) | -→ 192.168.1.2 OpenBSD only
'---^--'--'---'
|
v
em0
dhcp
^
|
Arris Surfboard SB8200
Cable Modem DOCSIS 3.1
(external interface)
|
v
.-,( ),-.
-( )-.
( Internet )
'-( ).-'
'--.( ).'
_/etc_/hostname.bridge0
add vether0
add em1
add em2
add em3
blocknonip vether0
blocknonip em1
blocknonip em2
blocknonip em3
up
_/etc_/hostname.vether0
inet 192.168.1.1 255.255.255.0 192.168.1.255
_/etc/dhcpd.conf_
option domain-names-servers 192.168.1.1;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
range 192.168.1.4 192.168.1.254;
host x1carbon {
fixed-address 192.168.1.2;
hardware ethernet xx:xx:xx:xx:xx:xx;
}
host optiplex790 {
fixed-address 192.168.1.3;
hardware ethernet xx:xx:xx:xx:xx:xx;
}
}
_/var/unbound/etc/unbound.conf_
server:
interface: 192.168.1.1
interface: 127.0.0.1
do-ip6: no
access-control: 192.168.1.0/24 allow
do-not-query-localhost: no
hide-identity: yes
hide-version: yes
forward-zone:
name: "."
forward-addr: 127.0.0.1@40
_/etc/rc.conf.local_
dhcpd_flags="vether0"
unbound_flags=""
dnscrypt_proxy
dnscrypt_proxy_flags="-l /_dev/_null -R dnscrypt.ca-1 -a 127.0.0.1:40"
sndiod_flags=NO
apmd_flags="-A"
_/etc/dhclient.conf_
ignore domain-name-servers
/etc/fstab (this is the only change from the default)
/dev/sd0a / ffs rw,noatime,softdep 1 1
_/etc/pf.conf_
int_if="{ vether0 em1 em2 em3 }"
broken="224.0.0.22 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 \
10.0.0.0/8 169.254.0.0/16 192.0.2.0/24 \
198.51.100.0/25, 203.0,113.0/24, \
169.254,0.0/16 0.0.0.0/8 240.0.0.0/4 255.255.255.255/32"
set block-policy drop
set loginterface egress
set skip on lo0
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
antispoof quick for (egress)
block in quick on egress from { $broken no-route urpf-failed } to any
block in quick inet6 all
block return out quick inet6 all
block return out quick log on egress proto { tcp udp } from any to any
port 53
block return out quick log on egress from any to { no-route $broken }
block in all
pass out quick inet keep state
pass in on $int_if inet
pass in on $int_if inet proto { tcp udp | from any to ! 192.168.1.1 port
53 rdr-to 192.168.1.1
pass in on egress inet proto tcp to (egress) port 222 rdr-to 192.168.1.2
pass in on egress inet proto tcp from any to (egress) port
Re: Live iso with 6.4
See the FuguIta Project: http://fuguita.org/?FuguIta 6.4 on amd64, i386 and arm64! On 1/24/19 7:15 PM, Flipchan wrote: > Has anyone been able to create a live iso of 6.4? > > Cant seem to find any scripts/documentation about it > > > > > Cheers > -- ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<< Stephane HUC as PengouinBSD or CIOTBSD b...@stephane-huc.net signature.asc Description: OpenPGP digital signature
Re: iMacPro and OpenBSD, kernel panicking
> Wiadomość napisana przez Mike Larkin w dniu > 24.01.2019, o godz. 17:39: > > On Thu, Jan 24, 2019 at 03:35:01AM +0100, Krystian Lewandowski wrote: >> >>> Wiadomość napisana przez Mike Larkin w dniu >>> 24.01.2019, o godz. 00:15: >>> >>> On Tue, Jan 22, 2019 at 11:31:08AM +0100, Krystian Lewandowski wrote: > Wiadomość napisana przez Mike Larkin w dniu > 22.01.2019, o godz. 04:35: > > On Mon, Jan 21, 2019 at 07:29:40PM -0800, Mike Larkin wrote: >> On Tue, Jan 22, 2019 at 03:14:13AM +0100, Krystian Lewandowski wrote: >>> Hello misc@, >>> >>> I’m trying to boot OpenBSD (current) on iMac Pro (iMacPro1,1). >>> It’s Apple’s Xeon-W based PC with ECC memory. >>> >>> This machine is very picky when it comes to OS support. Obviously macOS >>> is well >>> supported and I don’t have problems with it, MS Windows on an >>> external USB drive is stable as well. >>> I tried whole BSD family, multiple Linux based distros and Illumos. The >>> only >>> Linux distribution I was able to boot and install was Clear Linux* - >>> ended up with kernel >>> panicking randomly, and regarding BSDs - I was able to install and boot >>> FreeBSD >>> but it randomly fails with a Machine Check Exceptions. >>> >>> The other interesting thing is infamous T2 chip in which iMac Pro is >>> equipped - >>> almost every crash ends up with BridgeOS crash report. >>> >>> I would consider OpenBSD assertion failures and FreeBSD MCA errors >>> "UNCORR PCC GCACHE L2 ERR error" as valid if it wasn’t for rock stable >>> macOS and >>> MS Windows (and on both it’s pushed hard at times, for a few hours >>> straight, incl. VMs). >>> And my understanding is that this iMac Pro is no exception - other >>> iMacs present >>> similar behaviour (ending up with similar T2 chip Bridge OS crash >>> reports). >>> >>> I tried to do my homework and installed OpenBSD on an external USB >>> drive via >>> VMWare Fusion and built kernel with DEBUG flag. >>> External USB drive is the only option because of T2 chip. >>> >>> Tried to boot .SP kernel, tried to disable some devices - though >>> probably >>> doesn’t matter because I assume it’s crashing before autoconf is even >>> involved. >>> I also, tried to update microcode at boot on FreeBSD - someone >>> suggested that >>> via Twitter - didn’t help for at runtime MCA faults (CPU had most >>> recent microcode). >>> >>> OpenBSD snapshot fails with: >>> "fatal machine check in supervisor mode" >>> "panic: trap type 18, code=0, pc=…" >>> https://www.dropbox.com/s/birtxskxayjvxht/OpenBSD%20default%20kernel.jpeg?dl=0 >>> >> >> This may be related to a set of recent changes I made. Can you try >> 6.4-RELEASE >> and see if that still panics? >> >> -ml >> > > Sorry, didn't see the other captures. The most recent crash may still be > due to > the recent changes though. The MCEs, well, that's another thing. > > Can you send me the output of "machine memory" from the boot> prompt > please? > > -ml > Sure, please find machine memory output here: https://www.dropbox.com/s/sbgq7av9m0sre14/machine_memory.jpeg?dl=0 Krystian >>> >>> Does shrinking the amount of memory get any further? >>> >>> boot> mach mem =16G >>> >>> ... something like that? >>> >>> -ml >>> >> >> I think, I could say yes, a bit (compared to my most recent attempts). Now >> I can >> see mpath0 and scsibus0 being logged before the crash. Tried a few times on >> default >> kernel and DEBUG kernel, very similar in all tries. >> >> https://www.dropbox.com/s/z9xnheqhy274z8z/mem%2016G.jpeg?dl=0 >> https://www.dropbox.com/s/ozqlhsch0yz4ibr/16G%20default%20kernel.jpeg?dl=0 >> https://www.dropbox.com/s/hbzbf1aa2u0a9h4/16G%20debug%20kernel.jpeg?dl=0 >> >> And after that, macOS welcomed me with "x86 CPU CATERR detected report. >> >> Krystian > > You selected mach mem =16G and yet the kernel thought all 64GB was available? Yes, I think values at boot menu were OK (first screenshot), later it went back to 64G. > > Odd. Either your machine is totally hosed or there is some other problem. Probably Apple was just „thinking different”. > > In any case, "show registers" at ddb> after the panic might show more. But I'm > at a bit of a loss to explain what is going on here. I'm not sure if that's possible. This is AIO PC, the only way to attach something is via USB. When DDB is presented keyboard doesnt work. And it reboots a few seconds after. I don't think there is an easy way to attach a console. I just even tried to install MS Windows via Bootcamp, modify EFI partition from there (bcdedit) and boot OpenBSD directly, but results are the same. I also tried to boot OpenBSD using rEFInd boot man
i386 release build machines
What machines (brand/model/specs) do you guys use to create the releases/snapshots for i386? I am curious to find out if possible as I would think that the bigger boxes out there even though could have more than 4G of RAM the extra would go unused. I recently got a few old 32 bit servers and thought about building my own snapshots just because is cool to do that. Not that matters exactly what the project uses but I am sure you guys expect to have a build ready in a reasonable time. Thanks -luis
Re: Problems trying to format currency with python
Il giorno Dom 20 Gen 2019 16:00 Ingo Schwarze ha scritto: [...] > > OpenBSD intentionally does not implement any LC_MONETARY or strfmon(3) > functionality because we believe that such functionality does not > belong in the C library but should instead be implemented in > specialized support libraries for user interface design. > Hi Ingo, I suspected that while reading locale (1). Just wanted to make sure, thank you, Luca
Live iso with 6.4
Has anyone been able to create a live iso of 6.4? Cant seem to find any scripts/documentation about it Cheers -- Sincerely flipchan
Re: 100% intr CPU state in OpenBSD 6.4 VM
‐‐‐ Original Message ‐‐‐ On Thursday, January 24, 2019 5:35 PM, Mike Larkin wrote: > I believe this to be an accounting error and has been discussed on the lists > several times. > Sorry about that, now that you mention I remember also reading something on the list about that but could not find anything on ddg search. I have an issue where my VM temporary loses network connection for a few seconds to a few minutes so I was wondering if it might have been related to the high amount of interrupts but in that case it is not. I will look in other directions...
Re: iMacPro and OpenBSD, kernel panicking
On Thu, Jan 24, 2019 at 03:35:01AM +0100, Krystian Lewandowski wrote: > > > Wiadomość napisana przez Mike Larkin w dniu > > 24.01.2019, o godz. 00:15: > > > > On Tue, Jan 22, 2019 at 11:31:08AM +0100, Krystian Lewandowski wrote: > >> > >>> Wiadomość napisana przez Mike Larkin w dniu > >>> 22.01.2019, o godz. 04:35: > >>> > >>> On Mon, Jan 21, 2019 at 07:29:40PM -0800, Mike Larkin wrote: > On Tue, Jan 22, 2019 at 03:14:13AM +0100, Krystian Lewandowski wrote: > > Hello misc@, > > > > I’m trying to boot OpenBSD (current) on iMac Pro (iMacPro1,1). > > It’s Apple’s Xeon-W based PC with ECC memory. > > > > This machine is very picky when it comes to OS support. Obviously macOS > > is well > > supported and I don’t have problems with it, MS Windows on an > > external USB drive is stable as well. > > I tried whole BSD family, multiple Linux based distros and Illumos. The > > only > > Linux distribution I was able to boot and install was Clear Linux* - > > ended up with kernel > > panicking randomly, and regarding BSDs - I was able to install and boot > > FreeBSD > > but it randomly fails with a Machine Check Exceptions. > > > > The other interesting thing is infamous T2 chip in which iMac Pro is > > equipped - > > almost every crash ends up with BridgeOS crash report. > > > > I would consider OpenBSD assertion failures and FreeBSD MCA errors > > "UNCORR PCC GCACHE L2 ERR error" as valid if it wasn’t for rock stable > > macOS and > > MS Windows (and on both it’s pushed hard at times, for a few hours > > straight, incl. VMs). > > And my understanding is that this iMac Pro is no exception - other > > iMacs present > > similar behaviour (ending up with similar T2 chip Bridge OS crash > > reports). > > > > I tried to do my homework and installed OpenBSD on an external USB > > drive via > > VMWare Fusion and built kernel with DEBUG flag. > > External USB drive is the only option because of T2 chip. > > > > Tried to boot .SP kernel, tried to disable some devices - though > > probably > > doesn’t matter because I assume it’s crashing before autoconf is even > > involved. > > I also, tried to update microcode at boot on FreeBSD - someone > > suggested that > > via Twitter - didn’t help for at runtime MCA faults (CPU had most > > recent microcode). > > > > OpenBSD snapshot fails with: > > "fatal machine check in supervisor mode" > > "panic: trap type 18, code=0, pc=…" > > https://www.dropbox.com/s/birtxskxayjvxht/OpenBSD%20default%20kernel.jpeg?dl=0 > > > > This may be related to a set of recent changes I made. Can you try > 6.4-RELEASE > and see if that still panics? > > -ml > > >>> > >>> Sorry, didn't see the other captures. The most recent crash may still be > >>> due to > >>> the recent changes though. The MCEs, well, that's another thing. > >>> > >>> Can you send me the output of "machine memory" from the boot> prompt > >>> please? > >>> > >>> -ml > >>> > >> > >> Sure, > >> please find machine memory output here: > >> https://www.dropbox.com/s/sbgq7av9m0sre14/machine_memory.jpeg?dl=0 > >> > >> Krystian > >> > > > > Does shrinking the amount of memory get any further? > > > > boot> mach mem =16G > > > > ... something like that? > > > > -ml > > > > I think, I could say yes, a bit (compared to my most recent attempts). Now I > can > see mpath0 and scsibus0 being logged before the crash. Tried a few times on > default > kernel and DEBUG kernel, very similar in all tries. > > https://www.dropbox.com/s/z9xnheqhy274z8z/mem%2016G.jpeg?dl=0 > https://www.dropbox.com/s/ozqlhsch0yz4ibr/16G%20default%20kernel.jpeg?dl=0 > https://www.dropbox.com/s/hbzbf1aa2u0a9h4/16G%20debug%20kernel.jpeg?dl=0 > > And after that, macOS welcomed me with "x86 CPU CATERR detected report. > > Krystian You selected mach mem =16G and yet the kernel thought all 64GB was available? Odd. Either your machine is totally hosed or there is some other problem. In any case, "show registers" at ddb> after the panic might show more. But I'm at a bit of a loss to explain what is going on here. -ml
Re: 100% intr CPU state in OpenBSD 6.4 VM
On Thu, Jan 24, 2019 at 01:17:01PM +, mabi wrote: > Hi, > > I am testing VMM/VMD on an OpenBSD 6.4 host with an OpenBSD 6.4 as guest OS > and noticed that on a fresh installation the CPU seems to be all the time > 100% busy dealing with interrupts. Here is the relevant line from "top": > > CPU states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 100% intr, 0.0% > idle > > And the output of "vmstat" looks like this: > vmstat 1 > procsmemory pagedisk traps cpu > r s avm fre flt re pi po fr sr sd0 int sys cs us sy id > 1 32 15M668M4 0 0 0 0 0 0 10212 14 0 99 1 > 0 33 15M668M 12 0 0 0 0 0 0 21041 41 0 98 2 > 0 33 15M668M7 0 0 0 0 0 0 20736 33 0 99 1 > 0 33 15M668M7 0 0 0 0 0 0 21037 36 0 98 2 > 0 33 15M668M7 0 0 0 0 0 0 20937 36 0 100 0 > > The "Interrupts" column in the output of "systat" looks like this: > > Interrupts > 276 total > virtio0 > virtio1 > 15 virtio2 > com0 > 133 clock > 128 rtc > > This VM has nothing running yet, the only thing I did is to disable sndiod > and change this kernel parameter so that the time in the VM is more accurate: > > kern.timecounter.hardware=tsc > > So my question here would be if this 100% interrupt usage is normal under an > OpenBSD VM? or is there something I might be doing wrong? > > Below I pasted the "dmesg" output of my VM. Let me know if more details are > required. > > Regards, > Mabi > > > OpenBSD 6.4 (GENERIC) #3: Thu Dec 20 18:31:57 CET 2018 > r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1056956416 (1007MB) > avail mem = 1015816192 (968MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1950 (10 entries) > bios0: vendor SeaBIOS version "1.11.0p0-OpenBSD-vmm" date 01/01/2011 > bios0: OpenBSD VMM > acpi at bios0 not configured > cpu0 at mainbus0: (uniprocessor) > cpu0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2396.03 MHz, 06-2c-02 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,PAGE1GB,LONG,LAHF,ITSC,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > pvbus0 at mainbus0: OpenBSD > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00 > virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00 > viornd0 at virtio0 > virtio0: irq 3 > virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00 > vioblk0 at virtio1 > scsibus1 at vioblk0: 2 targets > sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed > sd0: 51200MB, 512 bytes/sector, 104857600 sectors > virtio1: irq 5 > virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 > vio0 at virtio2: address fe:e1:bb:ff:ff:ff > virtio2: irq 6 > virtio3 at pci0 dev 4 function 0 "OpenBSD VMM Control" rev 0x00 > vmmci0 at virtio3 > virtio3: irq 7 > isa0 at mainbus0 > isadma0 at isa0 > com0 at isa0 port 0x3f8/8 irq 4: ns16450, no fifo > com0: console > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > root on sd0a (2c1a48e720407786.a) swap on sd0b dump on sd0b > > I believe this to be an accounting error and has been discussed on the lists several times. -ml
100% intr CPU state in OpenBSD 6.4 VM
Hi, I am testing VMM/VMD on an OpenBSD 6.4 host with an OpenBSD 6.4 as guest OS and noticed that on a fresh installation the CPU seems to be all the time 100% busy dealing with interrupts. Here is the relevant line from "top": CPU states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 100% intr, 0.0% idle And the output of "vmstat" looks like this: vmstat 1 procsmemory pagedisk traps cpu r s avm fre flt re pi po fr sr sd0 int sys cs us sy id 1 32 15M668M4 0 0 0 0 0 0 10212 14 0 99 1 0 33 15M668M 12 0 0 0 0 0 0 21041 41 0 98 2 0 33 15M668M7 0 0 0 0 0 0 20736 33 0 99 1 0 33 15M668M7 0 0 0 0 0 0 21037 36 0 98 2 0 33 15M668M7 0 0 0 0 0 0 20937 36 0 100 0 The "Interrupts" column in the output of "systat" looks like this: Interrupts 276 total virtio0 virtio1 15 virtio2 com0 133 clock 128 rtc This VM has nothing running yet, the only thing I did is to disable sndiod and change this kernel parameter so that the time in the VM is more accurate: kern.timecounter.hardware=tsc So my question here would be if this 100% interrupt usage is normal under an OpenBSD VM? or is there something I might be doing wrong? Below I pasted the "dmesg" output of my VM. Let me know if more details are required. Regards, Mabi OpenBSD 6.4 (GENERIC) #3: Thu Dec 20 18:31:57 CET 2018 r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1056956416 (1007MB) avail mem = 1015816192 (968MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1950 (10 entries) bios0: vendor SeaBIOS version "1.11.0p0-OpenBSD-vmm" date 01/01/2011 bios0: OpenBSD VMM acpi at bios0 not configured cpu0 at mainbus0: (uniprocessor) cpu0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2396.03 MHz, 06-2c-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,PAGE1GB,LONG,LAHF,ITSC,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 pvbus0 at mainbus0: OpenBSD pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00 virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00 viornd0 at virtio0 virtio0: irq 3 virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk0 at virtio1 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 51200MB, 512 bytes/sector, 104857600 sectors virtio1: irq 5 virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio2: address fe:e1:bb:ff:ff:ff virtio2: irq 6 virtio3 at pci0 dev 4 function 0 "OpenBSD VMM Control" rev 0x00 vmmci0 at virtio3 virtio3: irq 7 isa0 at mainbus0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16450, no fifo com0: console vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (2c1a48e720407786.a) swap on sd0b dump on sd0b
