Re: Debian 12 Under VMM

[Dave Voutila]

04-psyche.tot...@icloud.com writes:

> Hi all,
>
> I am trying to run Debian 12 under VMM.
>
> I can see on the email from 2024-04-02 that Bruce managed to make it work, 
> but I don't know how.
>
> The crux of the issue is that the Debian ISO installer does not seem to work 
> under serial console.

You need to modify the kernel boot args to disable video and rely on
serial console. I can't recall whatever the graphics arg is to the linux
kernel, but you typically want something like vga=off and then set the
console arg. I recommend setting both that and io_delay:

 console=ttyS0,115200 io_delay=none

io_delay will make the kernel skip doing some pointless artificial
delays that don't matter with vmd.

>
> Here's what I did:
>
> /etc/vm.conf
>
> vm "vm1" {
> memory 1G
> disable
> cdrom "/isos/debian-12.5.0-amd64-netinst.iso"
> disk "/disks/disk_vm1.qcow2" format qcow2
> local interface
> }
>
> When I then start the vm, I am greeted with the message:
>
> "Press a key, otherwise speech synthesis will be started in 27 seconds..."
>
>
> and then after keypress
>
> "
> Undefined video mode number: 314
> Press  to see video modes available,  to continue, or wait 30 
> sec
> "
>
> and it then crashes.
>
> Can anyone (maybe Bruce) point me in the right direction?
>
> Thanks!
> Jake

Re: Does anyone know whether this hardware runs OpenBSD?

[Dave Voutila]

Steve Litt  writes:

> Does anyone know whether this hardware runs OpenBSD?
>
> https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669

Maybe... Looking at:

https://www.cnx-software.com/2022/06/03/mele-quieter3q-review-ultra-thin-fanless-mini-pc-tested-with-windows-11-ubuntu-22-04/

It seems to use components that should be supported. The wifi might work
with iwx(4). Not sure about the mmc controller, so whatever works with
that m.2 slot you might want to put in some storage that way.

For anyone curious, that link has a dmesg from Ubuntu 22.04 on the
machine in question.

>
> Thanks,
>
> SteveT
>
> Steve Litt
>
> Autumn 2023 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21

update to virtio_vmmci for linux 6.6 guests in vmd

[Dave Voutila]

Just cut a new release to fix building virtio_vmmci [1] on Linux
guests. This is my port of vmmci(4) to Linux to allow Linux guests in
vmd(8) safely shutdown when stopping vmd and also synchronize/update
their rtc's if you suspend/hibernate and then resume the host machine.

Not to be confused with vmm_clock [2], which is a port of pvclock(2) and
Linux's kvm-clock driver to provide paravirtualized clocksource.

If you run a Linux guest with a 6.6 or newer kernel, try out the latest
virtio_vmmci. If it doesn't compile, please ping me. Patches or PRs
appreciated as well...but I don't watch GH activity much so be sure to
ping me.

-dv

[1] https://github.com/voutilad/virtio_vmmci/releases/tag/0.6.0
[2] https://github.com/voutilad/vmm_clock

Re: vmd silently exits (after 7.4 upgrade)

[Dave Voutila]

Dave Voutila  writes:

> "Piotr K. Isajew"  writes:
>
>> Hello,
>>
>> I'm observing this on one of my machines (which I seldom use
>> nowadays) after upgrading it to 7.4. The machine had existing
>> vm.conf setup which worked for me in the past.
>>
>> Now "rcctl start vmd" reports:
>> vmd(ok)
>>
>> but just after that executing "vmctl status" gives:
>> vmctl: connect: /var/run/vmd.sock: Connection refused
>>
>> and there is no vmd process running.
>>
>> When I try to start vmd from command line, it generates some
>> output, but it is not really helpful in determining what could be
>> the problem:
>>
>> /usr/sbin/vmd  -d -v -v -v -v -v -v -v -v -v -v -v
>> vmd: startup
>> vmd: vm_register: registering vm 1
>> vmd: /etc/vm.conf:18: vm "lindev" registered (disabled)
>> vmd: vmd_configure: setting staggered start configuration to parallelism: 4 
>> and delay: 30
>> vmd: vmd_configure: starting vms in staggered fashion
>> vmd: start_vm_batch: starting batch of 4 vms
>> vmd: start_vm_batch: not starting vm lindev (disabled)
>> vmd: start_vm_batch: done starting vms
>> vmd: vmd: getgrnam
>
> Run sysmerge. You're missing the new _vmd group introduced in 7.4:
>
> $ grep vmd /etc/group
> _vmd:*:107:
>

err...also check the agentx group. That is probably the actual missing
group in this case:

$ grep agentx /etc/group
_agentx:*:92:

>> vmd: exiting
>> control: config_getconfig: control retrieving config
>> control: control exiting, pid 33268
>> # priv: config_getconfig: priv retrieving config
>> priv: priv exiting, pid 1161
>> vmm: config_getconfig: vmm retrieving config
>> vmm: vmm exiting, pid 48824
>>
>>
>> dmesg  excerpt
>> OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec  8 15:39:04 MST 2023
>> 
>> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> cpu0: Intel(R) Xeon(R) CPU E31225 @ 3.10GHz, 3093.12 MHz, 06-2a-07, patch 
>> 002f
>> 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,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>>
>> cpu0: using VERW MDS workaround (except on vmm entry)
>> vmm0 at mainbus0: VMX/EPT

Re: vmd silently exits (after 7.4 upgrade)

[Dave Voutila]

"Piotr K. Isajew"  writes:

> Hello,
>
> I'm observing this on one of my machines (which I seldom use
> nowadays) after upgrading it to 7.4. The machine had existing
> vm.conf setup which worked for me in the past.
>
> Now "rcctl start vmd" reports:
> vmd(ok)
>
> but just after that executing "vmctl status" gives:
> vmctl: connect: /var/run/vmd.sock: Connection refused
>
> and there is no vmd process running.
>
> When I try to start vmd from command line, it generates some
> output, but it is not really helpful in determining what could be
> the problem:
>
> /usr/sbin/vmd  -d -v -v -v -v -v -v -v -v -v -v -v
> vmd: startup
> vmd: vm_register: registering vm 1
> vmd: /etc/vm.conf:18: vm "lindev" registered (disabled)
> vmd: vmd_configure: setting staggered start configuration to parallelism: 4 
> and delay: 30
> vmd: vmd_configure: starting vms in staggered fashion
> vmd: start_vm_batch: starting batch of 4 vms
> vmd: start_vm_batch: not starting vm lindev (disabled)
> vmd: start_vm_batch: done starting vms
> vmd: vmd: getgrnam

Run sysmerge. You're missing the new _vmd group introduced in 7.4:

$ grep vmd /etc/group
_vmd:*:107:

> vmd: exiting
> control: config_getconfig: control retrieving config
> control: control exiting, pid 33268
> # priv: config_getconfig: priv retrieving config
> priv: priv exiting, pid 1161
> vmm: config_getconfig: vmm retrieving config
> vmm: vmm exiting, pid 48824
>
>
> dmesg  excerpt
> OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec  8 15:39:04 MST 2023
> 
> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> cpu0: Intel(R) Xeon(R) CPU E31225 @ 3.10GHz, 3093.12 MHz, 06-2a-07, patch 
> 002f
> 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,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>
> cpu0: using VERW MDS workaround (except on vmm entry)
> vmm0 at mainbus0: VMX/EPT

Re: Power usage in Dell XPS 17

[Dave Voutila]

Jag Talon  writes:

> I was wondering if I could get help with reducing power consumption on
> my laptop.
>
> I have a Dell XPS 17 9700 that's newly running 7.4 (dmesg in
> attachment) and previously it was running Fedora. Real-world usage
> seems to have gone from 4 hrs to about 40 mins so I was wondering if
> I'm missing anything:
>
> * I've tried using `apm -A`, `apm -L`, and `obsdfreqd` but any
>   improvement seems small.
>
> * I've tried lowering the resolution from 3840x2400 to 1680x1050,
>   which improved things a little bit, but not much. When `xenodm` or
>   `gdm` is not running it still gets pretty hot.
>
> * It still consumes a lot of power even when I'm not using it, so it
>   doesn't seem to be a CPU issue.
>
> Are there other things that I could try looking into? Does anyone have
> experience with this laptop?
>
> I get the feeling that it could perhaps be the Nvidia GPU running in
> the background even when it's unsupported? Is that possible?

Can you disable that in the uefi/bios settings? There may also be other
power settings in there to tweak. While OpenBSD doesn't have the
fanciest power management, the firmware can still do something to
throttle or change power states of systems.

Re: Clock stops working on OpenBSD qemu/kvm guest

[Dave Voutila]

Lévai, Dániel  writes:

> Turns out the clock stopped every night at the time when backups were
> running and thus the VM was paused (saved, or 'managedsaved' if
> someone uses libvirt) for a minute.
> Not sure why, though; while I was testing pause/resume the clock
> didn't stop, it just failed to get synced by ntpd(8). Maybe over time
> the drift was too much?

>From my experience, ntp daemons will try not to just jump the clock
forward or backwards by too great an amount and instead increase or
decrease time advancement to try to sync. It's indeed possible you
drifted too far for ntpd to handle through this method.

You might want to look into installing the Qemu guest agent in OpenBSD
vms:

 https://marc.info/?l=openbsd-ports=158936392710472=2

Usually these agents handle properly setting the rtc after a
suspend/resume cycle of the vm. (That's what the vmmci(4) driver does,
for instance, in OpenBSD guests running atop OpenBSD's vmd(8).)

>
> Anyway, the rather curious thing was ntpd(8) not syncing the clock
> properly after resume, so I ended up giving the 'trusted' option to
> the server I'm using here. Strangely, it still took quite some time
> [1], but in the end it managed to sync - so I guess this should work
> in the long run.
>
>
> [1]
> Jan 30 11:50:33  ntpd[83421]: peer 148.6.0.1 now valid
> Jan 30 11:54:37  ntpd[4758]: adjusting local clock by 23.831836s
> Jan 30 11:54:37  ntpd[83421]: clock is now synced
> Jan 30 11:54:37  ntpd[83421]: constraint reply from 9.9.9.9: offset 23.653130
> Jan 30 11:57:48  ntpd[4758]: adjusting local clock by 22.879877s
> Jan 30 11:57:48  ntpd[83421]: clock is now unsynced
> Jan 30 12:01:34  ntpd[4758]: adjusting local clock by 21.754396s
> Jan 30 12:04:51  ntpd[4758]: adjusting local clock by 20.774539s
> Jan 30 12:08:33  ntpd[4758]: adjusting local clock by 19.670413s
> Jan 30 12:12:43  ntpd[4758]: adjusting local clock by 18.426017s
> Jan 30 12:17:04  ntpd[4758]: adjusting local clock by 17.127167s
> Jan 30 12:21:19  ntpd[4758]: adjusting local clock by 15.857846s
> Jan 30 12:21:53  ntpd[4758]: adjusting local clock by 15.688043s
> Jan 30 12:25:30  ntpd[4758]: adjusting local clock by 14.613690s
> Jan 30 12:29:49  ntpd[4758]: adjusting local clock by 13.323883s
> Jan 30 12:33:32  ntpd[4758]: adjusting local clock by 12.204646s
> Jan 30 12:34:06  ntpd[4758]: adjusting local clock by 12.036162s
> Jan 30 12:35:10  ntpd[4758]: adjusting local clock by 11.712658s
> Jan 30 12:36:13  ntpd[4758]: adjusting local clock by 11.412870s
> Jan 30 12:39:55  ntpd[4758]: adjusting local clock by 10.308062s
> Jan 30 12:43:34  ntpd[4758]: adjusting local clock by 9.208613s
> Jan 30 12:44:07  ntpd[4758]: adjusting local clock by 9.048595s
> Jan 30 12:47:48  ntpd[4758]: adjusting local clock by 7.950845s
> Jan 30 12:49:27  ntpd[4758]: adjusting local clock by 7.460912s
> Jan 30 12:53:08  ntpd[4758]: adjusting local clock by 6.360250s
> Jan 30 12:56:22  ntpd[4758]: adjusting local clock by 5.385971s
> Jan 30 12:56:53  ntpd[4758]: adjusting local clock by 5.241883s
> Jan 30 13:01:13  ntpd[4758]: adjusting local clock by 3.951414s
> Jan 30 13:04:22  ntpd[4758]: adjusting local clock by 3.009970s
> Jan 30 13:07:05  ntpd[4758]: adjusting local clock by 2.201024s
> Jan 30 13:11:18  ntpd[4758]: adjusting local clock by 0.937320s
> Jan 30 13:12:22  ntpd[4758]: adjusting local clock by 0.613777s
> Jan 30 13:13:27  ntpd[4758]: adjusting local clock by 0.285335s
> Jan 30 13:14:32  ntpd[83421]: clock is now synced

Re: Clock stops working on OpenBSD qemu/kvm guest

[Dave Voutila]

Lévai, Dániel  writes:

> Hi all!
>
> I have this OpenBSD 7.4 qemu/kvm VM managed by libvirt on an Ubuntu 22.04 
> host.
>
> I started to notice this month that it started to act weird, it seems
> like the clock stops every night. I couldn't pinpoint exactly what
> caused the change in behavior, the host had two package updates that
> raised suspicion:
> 2024-01-11 06:51:04 upgrade linux-image-generic-hwe-22.04:amd64 
> 6.2.0.39.40~22.04.16 6.5.0.14.14~22.04.7
> 2024-01-12 09:10:36 upgrade libvirt-daemon:amd64 8.0.0-1ubuntu7.7 
> 8.0.0-1ubuntu7.8
>
> But none of the changelogs /seemed/ relevant.
>
> Anyway, the symptoms are funny, it always involves the clock stopping/not 
> working after some period of time.
>
> When this happens, I cannot login with SSH. The ssh client connects,
> it even asks for the private key, but after confirmation it times out.
>
> The really funny things happen when I log in on the console - that I can do:
>
> When I try to ping anything from the host, it stops after the first
> successful packets (echo/reply) and then hangs (I can CTRL+C).
> Interestingly I can ping the VM from the hypervisor host indefinitely,
> but running tcpdump on the guest doesn't show anything immediately. In
> fact, looking at tcpdump while doing *anything* network related on the
> VM or to the VM doesn't result in any output right away.
> That being said, after a couple of minutes, output from tcpdump starts
> to flood the screen but I cannot say exactly why or when, it just
> suddenly happens.
>
> Running `sleep 1` just hangs.
>
> When I run `date` consecutively it shows:
> Fri Jan 26 04:20:42 CET 2024
> Fri Jan 26 04:20:39 CET 2024
> Fri Jan 26 04:20:40 CET 2024
> Fri Jan 26 04:20:41 CET 2024
> Fri Jan 26 04:20:42 CET 2024
> Fri Jan 26 04:20:43 CET 2024
> Fri Jan 26 04:20:41 CET 2024
> Fri Jan 26 04:20:42 CET 2024

Definitely should not be seeing time moving backwards. That's not
good.

>
> It always works again after a reboot - forced reset, because it cannot shut 
> down gracefully.
>
> Originally I was using SP kernel but tried with MP recently too, just out of 
> curiosity - no luck.
>
> I found two old posts seemingly related:
> https://marc.info/?t=15294229612=1=2
> ^^ I don't have that sysctl on the host and that kernel is very old there.
>

What is your Linux kernel version?

> https://www.reddit.com/r/openbsd/comments/13c9nh1/clock_issue_with_vmm_guest_on_73/
> This is on an OpenBSD host, so I can't try that sysctl either.
>
> This has been set on the guest, though (defaults):
> kern.timecounter.tick=1
> kern.timecounter.timestepwarnings=0
> kern.timecounter.hardware=pvclock0
> kern.timecounter.choice=i8254(0) pvclock0(1500) acpitimer0(1000)
>
>

So pvclock should be relying on KVM to properly deal with TSC
paravirtualzation. Do you see this issue with Linux guests using
kvmclock? (Or do your Linux guests decide on a different clocksource?)

> Any clues would be appreciated,
> Daniel
>
>
> dmesg:
> OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 519929856 (495MB)
> avail mem = 484507648 (462MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5960 (10 entries)
> bios0: vendor SeaBIOS version "1.15.0-1" date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S5
> acpi0: tables DSDT FACP APIC 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: 12th Gen Intel(R) Core(TM) i7-12700K, 3609.77 MHz, 06-97-02
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 4MB
> 64b/line 16-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: 12th Gen Intel(R) Core(TM) i7-12700K, 3609.78 MHz, 06-97-02
> cpu1:
> 

Re: getpath from a file descriptor

[Dave Voutila]

bi...@iscarioth.org writes:

> Hello, dear OpenBSD's devs. I hope everything works well for you. I'm
> here to ask (maybe) a question that can displease you.
>
> Working on some projects, I saw a lot of them using fcntl(fd,
> F_GETPATH) like MacOs/NetBSD do, or proc  with a famous symlink to
> the file path (but procfs has been removed). Does OpenBSD have a
> syscall for receiving the path from a file descriptor ?

No. See this previous conversation from 2 years ago when this last came
up in the mailing lists. claudio@ sums it up:

https://marc.info/?l=openbsd-tech=164250539119078=2

>
> If not, how can I get them in a other way ?
> If not possible, do you planning to implements F_GETPATH, ?
>
> have a good days !
> Best Regards, Bilal.

Re: Run VM with 16G or more?

[Dave Voutila]

"Kirill A. Korinsky"  writes:

> [[PGP Signed Part:Undecided]]
>> On 2. Jan 2024, at 18:41, Dave Voutila  wrote:
>> "Kirill A. Korinsky"  writes:
>
>>> vmctl -v start... doesn't help a bit
>>
>> How much physicaly memory does the host machine have? We currently don't
>> allow oversubscribing memory with vmm/vmd. If the host only has 16GB
>> that could be the cause.
>
> hw.physmem=137257779200
> hw.usermem=133537726464
>
> and machine is used only for run VMs.
>
>> If that's not the case, can you run vmd in debug mode and get the log
>> output?
>
> Sure, I run /usr/sbin/vmd -vvv -d and the error is:
>
> vmd: config_setvm: vm 3 restarted after 9.757221 seconds, limit 0/3
> vmd: config_setvm: can't open tap tap

Ah, that.

> vmd: failed to start vm podman
> vmd: vm_stop: vmd config_setvm stopping vm 3
>
> This machine runs 4 more VM and this one (huge) should be 5th.

Try this:

# cd /dev && sh MAKEDEV tap4

By default I believe on amd64 we create tap[0-3]. You might need to
define additional special files to represent 4+ taps.

-dv

Re: Run VM with 16G or more?

[Dave Voutila]

"Kirill A. Korinsky"  writes:

>> On 2. Jan 2024, at 12:07, Kirill A. Korinsky  wrote:
>>
>> Confirmed that it is:
>>
>> island$ grep '^vmd:' -A 2 /etc/login.conf
>> vmd:\
>>  :datasize=16384M:\
>>  :tc=daemon:
>> island$
>
>
> Wel.. after that changes error has been changed to:
>
>> vmctl: start vm command failed: Unknown error: -1

yeah that error description sucks...should be changed

>
>
> vmctl -v start... doesn't help a bit

How much physicaly memory does the host machine have? We currently don't
allow oversubscribing memory with vmm/vmd. If the host only has 16GB
that could be the cause.

If that's not the case, can you run vmd in debug mode and get the log
output?

Re: man.openbsd.org failure?

[Dave Anderson]

“Server stopped responding” implies that it did provide some response before 
stopping. “Server did not respond” would be more accurate and less confusing.

Dave Anderson
d...@daveanderson.com

> On Dec 23, 2023, at 07:27, hahahahacker2...@airmail.cc wrote:
> 
> On 2023-12-22 10:39, Dave Anderson wrote:
>> Oops! I did see that message but forgot that it mentioned
>> man.openbsd.org. Apologies for the noise. (But that Safari error
>> message sucks!)
>> Dave Anderson
>> d...@daveanderson.com
>> > On Dec 21, 2023, at 21:55, Daniel Jakots  wrote:
>> >
>> > On Thu, 21 Dec 2023 21:22:49 -0500, Dave Anderson  wrote:
>> >
>> > > Safari isn=E2=80=99t providing much useful information, but starting 
>> > > today
>> > > I=E2=80=99m consistently getting a =E2=80=9Cserver stopped responding=E2=
>> > =80=9D error when
>> > > trying to access the online man pages at man.openbsd.org.
>> > > www.openbsd.org is working fine.
>> >
>> > Yes, it's a maintenance:
>> > https://marc.info/?l=3Dopenbsd-misc=3D170301839017559=3D
> The website is simply down. So it cannot just respond.
> 

Re: man.openbsd.org failure?

[Dave Anderson]

Oops! I did see that message but forgot that it mentioned man.openbsd.org. 
Apologies for the noise. (But that Safari error message sucks!)

Dave Anderson
d...@daveanderson.com

> On Dec 21, 2023, at 21:55, Daniel Jakots  wrote:
> 
> On Thu, 21 Dec 2023 21:22:49 -0500, Dave Anderson  wrote:
> 
>> Safari isn=E2=80=99t providing much useful information, but starting today
>> I=E2=80=99m consistently getting a =E2=80=9Cserver stopped responding=E2=
> =80=9D error when
>> trying to access the online man pages at man.openbsd.org.
>> www.openbsd.org is working fine.
> 
> Yes, it's a maintenance:
> https://marc.info/?l=3Dopenbsd-misc=3D170301839017559=3D

man.openbsd.org failure?

[Dave Anderson]

Safari isn’t providing much useful information, but starting today I’m 
consistently getting a “server stopped responding” error when trying to access 
the online man pages at man.openbsd.org. www.openbsd.org is working fine.

Dave Anderson
d...@daveanderson.com

Re: Appimage

[Dave Voutila]

Kevin Chadwick  writes:

> I'm not sure if this is a pipe dream but atleast I imagine the filesystem API 
> and /proc avoidance is likely possible.
>

Depends on what you're smoking in said pipe.

> "https://github.com/AppImage/AppImageKit/issues/98;

Re: VMs not rebooting

[Dave Voutila]

"Robert B. Carleton"  writes:

> I have a number virtual machines, and I've noticed that they power off
> instead of rebooting when using "shutdown -r now" on the guest. This is
> the general form for a configuration in the /etc/vm.conf:
>
> vm "batch2" {
> memory 2G
> enable
> cdrom /home/ISO/OpenBSD/7.4/install74.iso
> disk /home/vm/batch2/disk0.qcow2
> boot device disk

Stab in the dark, but try removing the "boot device disk" line as well
as the cdrom one. Does it still behave like that?

There's a sneaky edge case where we don't handle a reboot. claudio@
bugged me about it awhile back but I've been slow to dig into it.

> interface { switch "int_switch" }
> interface { switch "ext_switch" }
> }
>
> I also tried running vmd from the command line with "-d -vv". Here's the
> end of the logging when I tried to reboot the guest:
>
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vmmci_ack: vm 7 requested shutdown
> vm/batch2: virtio_shutdown: waiting on device pid 35337
> vm/batch2: virtio_dispatch_dev: pipe dead (EV_READ)
> vm/batch2: virtio_shutdown: device for pid 35337 is stopped
> vm/batch2: virtio_shutdown: waiting on device pid 64912
> vm/batch2: virtio_shutdown: device for pid 64912 is stopped
> vm/batch2: virtio_shutdown: waiting on device pid 34607
> vm/batch2: virtio_shutdown: device for pid 34607 is stopped
> vmm: vmm_sighdlr: handling signal 20
> vmm: vmm_sighdlr: terminated vm batch2 (id 1)
> vmm: vm_remove: vmm vmm_sighdlr removing vm 1 from running config
> vmm: vm_stop: vmm vmm_sighdlr stopping vm 1
> vmd: vm_stop: vmd vmd_dispatch_vmm stopping vm 1
>
> The three "vcpu_exit_eptviolation: fault already handled" lines seemed
> to happen continuously during run time for the guest.
>
> Is there some kind of configuration that I'm missing? I read the vmctl,
> and vm.conf man pages. I also looked at the examples in
> /etc/examples. Nothing stood out, so far.
>
> I'm running OpenBSD 7.4 on the hypervisor and guests. Any suggestions?
>
> PS: Overall, using vmm has been a good experience. I'm pretty happy with
> it.

Re: pine64-lts (aarch64) bsd.mp panics on boot

[Dave Vandervies]

Somebody claiming to be Dave Vandervies wrote:
> After upgrading to 7.4, my pine64-lts box failed to boot bsd.mp on
> two out of two tries, with an identical panic message both times:
> (see below for full (u-boot + kernel + ddb) boot log of the panic
> and dmesg from bsd.sp which does boot)

Ahh, here's some interesting additional information: If I turn off
the external USB disk I have attached to this box before booting,
and turn it back on once the boot finishes, bsd.mp also boots without
panicking.

Here's the dmesg from a succesful bsd.mp boot:

OpenBSD 7.4 (GENERIC.MP) #2273: Tue Oct 10 09:45:06 MDT 2023
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 2027782144 (1933MB)
avail mem = 1928839168 (1839MB)
random: good seed from bootblocks
mainbus0 at root: Pine64 LTS
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
efi0 at mainbus0: UEFI 2.8
efi0: Das U-Boot rev 0x20211000
smbios0 at efi0: SMBIOS 3.0
smbios0: vendor U-Boot version "2021.10" date 10/01/2021
smbios0: Unknown Unknown Product
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 512KB 64b/line 16-way L2 cache
cpu0: CRC32,SHA2,SHA1,AES+PMULL,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4
cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu1: 512KB 64b/line 16-way L2 cache
cpu1: CRC32,SHA2,SHA1,AES+PMULL,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4
cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu2: 512KB 64b/line 16-way L2 cache
cpu2: CRC32,SHA2,SHA1,AES+PMULL,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4
cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu3: 512KB 64b/line 16-way L2 cache
cpu3: CRC32,SHA2,SHA1,AES+PMULL,ASID16
apm0 at mainbus0
"display-engine" at mainbus0 not configured
"osc24M_clk" at mainbus0 not configured
"osc32k_clk" at mainbus0 not configured
"pmu" at mainbus0 not configured
simpleaudio0 at mainbus0
agtimer0 at mainbus0: 24000 kHz
simplebus0 at mainbus0: "soc"
sxisyscon0 at simplebus0
sxisid0 at simplebus0
sxiccmu0 at simplebus0
sxipio0 at simplebus0: 103 pins
ampintc0 at simplebus0 nirq 224, ncpu 4 ipi: 0, 1, 2: "interrupt-controller"
sxirtc0 at simplebus0
sxiccmu1 at simplebus0
sxipio1 at simplebus0: 13 pins
sxirsb0 at simplebus0
axppmic0 at sxirsb0 addr 0x3a3: AXP803
"bus" at simplebus0 not configured
"dma-controller" at simplebus0 not configured
"lcd-controller" at simplebus0 not configured
"lcd-controller" at simplebus0 not configured
"video-codec" at simplebus0 not configured
sximmc0 at simplebus0
sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
sximmc1 at simplebus0
sdmmc1 at sximmc1: 8-bit, sd high-speed, mmc high-speed, dma
"crypto" at simplebus0 not configured
"mailbox" at simplebus0 not configured
"usb" at simplebus0 not configured
"phy" at simplebus0 not configured
ehci0 at simplebus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 
addr 1
ohci0 at simplebus0: version 1.0
ehci1 at simplebus0
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 
addr 1
ohci1 at simplebus0: version 1.0
"timer" at simplebus0 not configured
sxidog0 at simplebus0
"dai" at simplebus0 not configured
"codec" at simplebus0 not configured
sxitemp0 at simplebus0
com0 at simplebus0: dw16550
com0: console
"spi" at simplebus0 not configured
dwxe0 at simplebus0: address 02:bc:b8:a1:ec:e9
rgephy0 at dwxe0 phy 1: RTL8169S/8110S/8211 PHY, rev. 5
"gpu" at simplebus0 not configured
"dram-controller" at simplebus0 not configured
"deinterlace" at simplebus0 not configured
"hdmi" at simplebus0 not configured
"hdmi-phy" at simplebus0 not configured
sxirintc0 at simplebus0
"codec-analog" at simplebus0 not configured
gpio0 at sxipio0: 32 pins
gpio1 at sxipio0: 32 pins
gpio2 at sxipio0: 32 pins
gpio3 at sxipio0: 32 pins
gpio4 at sxipio0: 32 pins
gpio5 at sxipio0: 32 pins
gpio6 at sxipio0: 32 pins
gpio7 at sxipio0: 32 pins
gpio8 at sxipio1: 32 pins
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Generic OHCI root hub" rev 1.00/1.00 
addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Generic OHCI root hub" rev 1.00/1.00 
addr 1
"opp_table0" at mainbus0 not configured
"hdmi-connector" at mainbus0 not configured
"vcc1v8" at mainbus0 not configured
gpioleds0 at mainbus0: no LEDs
simplefb0 at mainbus0: 1920x1080, 32bpp
wsdisplay0 at simplefb0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)
sdmmc0: can't enable c

pine64-lts (aarch64) bsd.mp panics on boot

[Dave Vandervies]

After upgrading to 7.4, my pine64-lts box failed to boot bsd.mp on
two out of two tries, with an identical panic message both times:
(see below for full (u-boot + kernel + ddb) boot log of the panic
and dmesg from bsd.sp which does boot)

panic: uvm_fault: fault on non-pageable map (0xff80012dbd48, 0xff8007f7
d000)
Stopped at  panic+0x164:cmp w21, #0x0
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
 459227  91515  0 0x14000  0x2003  update
*165810   5998  0 0x14000  0x2002K cleaner
   8700  14349  0 0x14000  0x2001  reaper
  0  0  0 0x1  0x2000  swapper
db_enter() at panic+0x160
panic() at uvm_fault_check+0x5e0
uvm_fault_check() at uvm_fault+0xd4
uvm_fault() at kdata_abort+0xd0
kdata_abort() at handle_el1h_sync+0x6c
handle_el1h_sync() at comopen+0x578
comopen() at proc_trampoline+0x4
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb{2}> trace
db_enter() at panic+0x160
panic() at uvm_fault_check+0x5e0
uvm_fault_check() at uvm_fault+0xd4
uvm_fault() at kdata_abort+0xd0
kdata_abort() at handle_el1h_sync+0x6c
handle_el1h_sync() at comopen+0x578
comopen() at proc_trampoline+0x4
ddb{2}> machine ddbcpu 0



ddb doesn't come back after I say 'machine ddbcpu 0', it just hung
there until I ran out of patience and power cycled (identical
behavior in both tries), which makes it impossible to collect traces
from the other CPUs as recommended by ddb.html.  The only differences
between the panic messages are the TID and PID values in the ps
listing;  the values in the panic message itself and the backtrace
match exactly.

The upgrade kernel, bsd.rd, and bsd.sp all boot without problems.

What other information is worth collecting here?  Anything I should
try to see if there's a way to fix it without a kernel patch?


Thanks,
dave


serial console log of the full boot + panic with bsd.mp:

U-Boot SPL 2021.10 (Apr 09 2022 - 20:52:48 -0600)
DRAM: 2048 MiB
Trying to boot from MMC2
NOTICE:  BL31: v2.5(debug):2.5
NOTICE:  BL31: Built : 16:26:47, Apr  9 2022
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x4097d10, model: Pine64 LTS
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
INFO:PMIC: Probing AXP803 on RSB
INFO:PMIC: dcdc1 voltage: 3.300V
INFO:PMIC: dcdc5 voltage: 1.200V
INFO:PMIC: dcdc6 voltage: 1.100V
INFO:PMIC: dldo1 voltage: 3.300V
INFO:PMIC: dldo2 voltage: 3.300V
INFO:PMIC: dldo4 voltage: 3.300V
INFO:PMIC: fldo1 voltage: 1.200V
INFO:PMIC: Enabling DC SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: cortex_a53: CPU workaround for 1530924 was applied
INFO:PSCI: Suspend is unavailable
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9


U-Boot 2021.10 (Apr 09 2022 - 20:52:48 -0600) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64 LTS
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc1:1... In:   
 serial
Out:   vidconsole
Err:   vidconsole
Net:   phy interface8
eth0: ethernet@1c3
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 5 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0 
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
28618 bytes read in 3 ms (9.1 MiB/s)
78Card did not respond to voltage select! : -110
Scanning disk m...@1c0f000.blk...
Disk m...@1c0f000.blk not ready
Scanning disk m...@1c11000.blk...
Scanning disk usb_mass_storage.lun0...
Disk usb_mass_storage.lun0 not ready
Found 3 disks
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi
219050 bytes read in 7 ms (29.8 MiB/s)
Booting /efi\boot\bootaa64.efi
disks: sd0*
>> OpenBSD/arm64 BOOTAA64 1.18
|/-\|/-\|/boot> 
-\|/-\|/-\booting sd0a:/b

Re: What could cause high CPU load averages (no actual CPU usage)?

[Dave Voutila]

Mike Fischer  writes:

> I have been observing occasional bouts of high load averages on
> several servers I administer and I am trying to find the cause. (I
> monitor these machines so that I can implement corrective measures in
> case of any malicious or abnormal activity. I think this is benign,
> but I’d still like to find the cause.)
>
> Once the high load average starts, only a reboot seems to (temporarily) 
> return the values to their normal levels.
>
> The actual CPU usage (as measured by vmstat) stays low even if the load 
> average is elevated.
>
> The servers are VMs running on a VMWare host (ESXi). This was seen with 
> OpenBSD 7.3 and 7.4 amd64.
>
> I can not determine anything inside the VM that causes this. There
> seems to be no correlation to pfstat(8) graphs, log entries, known
> events, or anything else I can determine. restarting all of the rc.d
> services never made any difference.
>
> Could this be caused by something on the VMWare host machine? (The
> host seems to be operating at limit regarding RAM for example. But the
> VM is only using the normal percentage of its allocated RAM — way
> below 100% and very constant usage, no swap.)
>
> How can I further debug this, keeping in mind that these are production 
> machines and experimentation is limited to benign things that don’t cause 
> outages.
>

Can you share a dmesg of one of the 7.4 vm? The output of `vmstat -iz`
might help narrow it down to a stuck interrupt. Also, try running
systat(1) and observe things as they happen.

Re: Lenovo Thinkpad T14 Gen3 very slow on MP kernel, faster on GENERIC

[Dave Voutila]

Stuart Henderson  writes:

> On 2023-10-17, Comète  wrote:
>> Hi,
>>
>> Wow ! you're absolutely right ! If I unplug, no lagg anymore.
>> So the solution should be to apply your patch and rebuild the kernel ?
>
> It's certainly worth trying. If you do, please report back here.
>

I have a particular Lenovo machine (AMD Ryzen-based, though) that
routinely suffers from some perf throttling I think (guessing) in the
bios or hardware itself. Usually a complete shutdown and plugging and
unplugging the power gets it to start working as expected. Until then
it's dog slow showing now reason why (pretty sure apm shows a normal cpu
frequency and there's no interrupt storm).

I would not be surprised if that's the same problem reported here.

It happens enough to be mildly annoying, but not enough (and it's not my
daily driver) that I have dug into it further beyond just the power
cycle. Is it kernel state? Bios? /shrug

Re: vmd and /dev/sd*

[Dave Voutila]

Manuel Giraud  writes:

> Mike Larkin  writes:
>
>> On Thu, Oct 12, 2023 at 09:24:33AM -0600, Theo de Raadt wrote:
>>> Manuel Giraud  wrote:
>>>
>>> > > Manuel Giraud  writes:
>>> > >
>>> > >> Hi,
>>> > >>
>>> > >> I can't find the information on this list (or elsewhere).  Is it
>>> > >> possible to have a vm that access a disk through its device?  The
>>> > >> following does not seem to work:
>>> > >>
>>> > >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm
>>> > >> vmctl: start vm command failed: Unknown error: -1
>>> > >
>>> > > No, passing file descriptors to devices over ipc sockets isn't currently
>>> > > allowed by the kernel. You'd need to use the raw character device, too,
>>> > > afaik if passing them were allowed.
>>> >
>>> > Ok, noted.  BTW I have the same error passing the raw character device.
>>>
>>>
>>>
>>> I made the decision to not allow passing of weird file descriptor types
>>> very intentionally.  I'm still very sure that is the right decision.
>>>
>>> Here's 1 program which wants to do it, but the other 1000 pledge'd programs
>>> are being protected from being passed an incorrect fd and then doing system
>>> calls upon it which behave "different".  By that, I mean seek, read, and
>>> write short-operation behaviours are subtly different outside of files and
>>> sockets, and it would also expose some ioctl (which is MOSTLY limited by
>>> pledge, but ioctl "request" values are just numbers, and they can overlap in
>>> surprising ways).
>>>
>>
>> I would like to make clear that vmd does not "want to do it", and that I 
>> agree
>> that the current design of not being able to pass these types of fds is
>> correct. It may be slightly inconvient for certain niche use cases, but not
>> worth weakening everything else or putting in hacks. Just dd the device you
>> want to a .raw file and use that.
>
> Thanks for making that clear.  I do not understand all the security
> implications but you do :)  Maybe to prevent future request, you could
> have a more explicit error message.

I agree reporting "Unknown error" is unhelpful. I don't think having
something specific to people trying to use devices instead of files is
worth the effort as none of the documentation should be implying that's
a feature.

Re: vmd and /dev/sd*

[Dave Voutila]

Manuel Giraud  writes:

> Hi,
>
> I can't find the information on this list (or elsewhere).  Is it
> possible to have a vm that access a disk through its device?  The
> following does not seem to work:
>
> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm
> vmctl: start vm command failed: Unknown error: -1

No, passing file descriptors to devices over ipc sockets isn't currently
allowed by the kernel. You'd need to use the raw character device, too,
afaik if passing them were allowed.

>
> What would be the alternatives?

None I know of.

Re: OpenBSD 7.3 found a process with PID 0

[Dave Voutila]

Alessandro Baggi  writes:

> Hi list,
> running this python3 script:
>
> #!/usr/bin/env python3
> import psutil
>
> pids = psutil.pids()
> for i in pids:
> p = psutil.Process(i)
> with p.oneshot():
> print(str(i) + " " + p.name())
>
> The result start with:
>
> 0 swapper
> 1 init
> 536 smtpd
> 868 ksh
> ...
>
> This process does not appear in ps, top and htop.

You need to display kernel threads.

$ ps -p 0 -H
  PID TID TT  STATTIME COMMAND
0  10 ??  DK   0:01.04 (swapper)

>
> How could be that there is a process with PID 0 before init?
> Probably I'm missing something about OpenBSD core.
>
> Can someone point me in the right direction?
>
> Thank you in advance.
>
> Alessandro.

Re: Panic during 7.3 installation on VM

[Dave Voutila]

Alessandro Baggi  writes:

> Hi list,
> I'm trying to install OpenBSD 7.3 on a VM (Linux KVM) but when it
> starts to install sets I got panic and "syncing disk... 8 8 8 8 ..."
> until it reboot automatically.

Can you share the panic and backtrace?

>
> This is a simple installation, no disk encryption, default OpenBSD layout...
>

Please share the exact settings or the dmesg from booting the vm.

> The VM has VNC Server as "graphic" instead of spice, disk is SATA and
> it has fixed allocation.
>
> Someone can put me in the right direction?
>
> Thank you in advance.

Re: desire for journaled filesystem

[Dave Voutila]

John Holland  writes:

> I just had a kernel panic when reloading a firefox tab pointed at
> facebook. After restarting, all the filesystems had errors but /home
> was particularly bad and caused the boot to stop and prompt if I
> wanted to enter a root shell.
>
>
> I eventually got fsck to mark the /home filesystem clean but it found
>>4000 lost files that it moved to lost I am not so experienced
> with this, running "file" on a few of them shows that they may be
> intact files but they have numeric names now.
>
>
> I've really been enjoying OpenBSD but I think it could really use a
> journaled filesystem. I believe I have the correct options in fstab
> for the best results:
>
> 1f08fbc2b303f0ef.k /home ffs rw,softdep,noatime,nodev,nosuid 1 2

You don't mention what version you're running, but I would say don't run
with softdep if you prefer data safety over "performance."

It's effectively a no-op in -current IIRC. So if you're on 7.3 or
earlier, ditch it.

>
>
> I was just thinking how much I was enjoying OpenBSD compared to some
> others when this happened.
>
>
> OpenZFS? License issues? Hammer? Anything?

Re: non-hardware 2fa options for openssh

[Dave Voutila]

Daniel Jakots  writes:

> On Tue, 29 Aug 2023 10:07:18 -0500, "myml...@gmx.com" 
> wrote:
>
>> Hi All,
>>
>> I want to secure an openssh server with two factor authentication and
>> have seen the hardware token methods, most recently i've been seeing
>> yubi/FIDO methods.
>>
>> Ideally I would like to avoid having to depend on a usb size device
>> that could easily be lost.
>
> Using something based on TOTP (Cf. rfc6238) is probably your best bet
> then.
>
>> I looked around and found mention of google authenticator as an
>> option, phones aren't much bigger than usb sticks but people protect
>> their phone as if it was their soul, but the newest mention I can
>> find is many years old.
>
> AFAIK, google authenticator is simply an app doing the math for TOTP.
> There are multiple basic opensource apps (on both Android and iphones)
> which can provide you with the right TOTP based on the seed/secret.
>
> And if you don't want to use a phone, you can use oathtool(1) from
> security/oath-toolkit.
> I think some password managers also are able to generate the TOTP.
>
>> My question is there any recent documentation / information on setting
>> up an openssh server with non-hardware based two factor
>> authentication? This does NOT have to be google authenticator, any
>> similar service will suffice.
>
> login_totp(8), login.conf(5), sshd_config(5), and maybe a couple of
> others.
>
> You can also want to look at sysutils/login_oath (which I've been using
> for years), but maybe for new setups, the login_totp from base makes
> more sense.
>

login_totp is in base?

Re: Immutable Page Protections

[Dave Voutila]

Justin Handville  writes:

> I'm assuming that misc@ is probably the best place for this e-mail,
> although it gets a bit in the tech@ weeds.  I upgraded to 7.3 not so
> long ago, and I noticed that a daemon I had written was no longer
> working properly. For reasons that are probably too much to get into
> here, I statically link the daemon. It's a single binary that makes use
> of pledge / unveil, and privilege separation. This all works fine. It
> also has another trick, which unfortunately no longer works in 7.3.
>
> To reduce the code footprint of this daemon as well as the potential
> gadget attack surface, I have it drop any code that it will no longer
> execute. This happens after fork / exec on a child, and also after
> initialization code executes before the child process enters its steady
> state. This is trivially done by grouping functions into custom page
> aligned sections in the ELF binary, and running mprotect on these
> sections with PROT_NONE. I considered munmap as well as other tricks,
> but so far, this seems to be the most portable way to handle this trick
> that I could think of between BSD and Linux. I'm sure others are more
> clever.  It's a cheap defense in depth protection that simplifies my use
> case.

Have you considered a libexec approach instead? If the goal is to keep a
child process having only the executable pages it needs for operations,
why not split up the program design instead of mucking with ELF stuff?
That surely has to be even more portable.

>
> As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> trick no longer works. Given that my trick is a total hack, I'm not too
> broken up about it.  Of course, this change led me to doing some poking
> around.
>
> I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> Chrome to drop the write flag for a region for userland compatibility.
> That makes sense as a temporary measure. I'm wondering, however, if it
> might not make sense to think about this functionality differently.
> Instead of immutable memory regions, why can't we consider a more
> pledge-like ratcheting for memory regions, where bits can be removed,
> but never added back? How does this impact the gadget attack surface
> that led to the immutable flag being considered to begin with?
>
> For the time being, I extended the exception in uvm_map.c on my own
> OpenBSD systems to allow immutable regions to be stripped of all
> protection flags with a call to mprotect. So, in addition to allowing RW
> to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> option for patching for now.  Of course, this further breaks the
> definition of "immutable", but at least immutable regions can only have
> protection bits removed.
>
> My reason for mailing misc@ is just to bring up this data point from a
> single user. I'm certain that the OpenBSD developers have reasons for
> preferring a pure immutable flag, but having a mechanism for ratcheting
> down protections is useful at least for me, and is apparently useful
> enough in userland going from RW to R, that an exception was carved out
> for now. Of course, I'm more than happy to work with the developers to
> come up with a plan for upstreaming this feature if it's something
> useful. If not, I have no problem adding it to my personal list of
> patches I maintain that I doubt anyone else would want or need.
>
> - Justin

Re: Hibernation on Thinkpad Carbon X1 gen 7 - unhibernate failed

[Dave Voutila]

Chris Narkiewicz  writes:

> Hi,
>
> I got Thinkpad Carbon X1 gen7 and I tried to test hibernation (ZZZ).

Do you have a dmesg?

>
> When system is resumed, it took several minutes to load image.
> dmesg shows:
>
> unhibernate failed: original kernel changed
>
> and my iwm0 wifi card is not visible anymore.
>
> Is there someobdy with 7th gen X1 that could confirm?
> According to https://jcs.org/2019/08/14/x1c7 it should work.
>
> Thanks for any suggestions,
> Chris

Re: support of thinkpad arm

[Dave Voutila]

BESSOT Jean-Michel  writes:

> Hello
>
> I wish to know if the last thinkpad arm will be supported by openbsd
> before buying one.
>
> here the computer:
> https://www.lenovo.com/fr/fr/p/laptops/thinkpad/thinkpadx/thinkpad--x13s-(13-inch-snapdragon)/len101t0019
>
> what do you know about this ?
>

A few of us have them, including myself. It's fine if you're looking to
hack on arm64 stuff but probably not a great daily driver as we
currently lack support for wifi and accelerated graphics. You'd really
need to follow -current. If this isn't want you're looking for in a
system I would not recommend it currently.

-dv

Re: 7.3 vmm/vmd shutdown page flush behavior?

[Dave Voutila]

not jacinda ardern  writes:

> Perhaps it's just me, but upon upgrading to 7.3, I noticed that when VMs
> shut down, there appears to be a flurry of disk activity right after the
> VM OS shuts down, which seems like page flushing of mapped and/or cached
> pages.  I seem to also not recall as high a value for cached memory usage
> in 7.2, but perhaps I just never really looked before.

Pretty sure you mean -current and you're following snapshots, right? If
so, I just introduced changes to resolve this that may not be in the
latest snaps yet.

If you're seeing this on a 7.3-stable/release system, I'd be a bit
surprised.

-dv

Re: Issues booting alpine linux > 3.5 on vmm - openbsd7.2

[Dave Voutila]

Dave Voutila  writes:

> di...@santanas.co.za writes:
>
>> Hi OpenBSD friends,
>>
>> Just a report, not sure if it's helpful, but @voutilad requested [1] I
>> send the details to the mailing list.
>>
>> I have seen a few reports online[1][2], about some users not being able to
>> boot newer alpine linux versions (and other linux OS' in my
>> experience).  Specifically I've seen the last version that boots is
>> 3.5.3.
>>
>> My system is openbsd 7.2 on my hardware Lenovo ThinkPad E14 Gen 4
>> laptop.
>>
>> The issue, when the alpine linux VM boots, it kernel panics.
>>
>> [0.052602]local IPI:
>> [0.052602] invalid opcode:  [#1] SMP PTI
>> [0.052602] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.79-0-virt 
>> #1-Alpine
>> [0.052602] Hardware name: OpenBSD VMM, BIOS 1.14.0p0-OpenBSD-vmm 
>> 01/01/2011
>> [0.052602] RIP: 0010:delay_halt_tpause+0xd/0x20
>> [ 0.052602] Code: 75 fb 48 ff c8 31 c0 31 ff c3 cc cc cc cc 66 66 2e
> 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 8d 04 37 31 c9 48 89 c2 48 c1
> ea 20 <66> 0f ae f1 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc 53 48
> c7
>
> The key issue here is the invalid opcode error coming from the
> instruction starting with 66 0f ae, which is a TPAUSE
> instruction. Hence the RIP pointing to "delay_halt_tpause" in the Linux
> kernel.
>
> I don't think I have any newer Intel hardware that supports the "User
> Wait" instructions (aka WAITPKG). My Intel research says it premiered in
> Tremont, Alder Lake, Sapphire Rapids so I can't test locally, but the
> docs from Intel (SDM Vol. 2B 4-719) say:
>
>  Prior to executing the TPAUSE instruction, an operating system may
>  specify the maximum delay it allows the processor to suspend its
>  operation. It can do so by writing TSC-quanta value to the
>  following 32-bit MSR (IA32_UMWAIT_CONTROL at MSR index E1H)...
>
> We probably should be masking the CPUID value for TPAUSE in the values
> vmm(4) communicates via vmm_handle_cpuid.
>
>

The below diff defines the cpuid bit for detecting the WAITPKG
feature. It adds the value to vmm's cpuid mask and also updates the
i386/amd64 cpu identification info.

Can someone with a newer Intel system try this out?


diff refs/heads/master refs/heads/vmm-tsleep
commit - 515b7b0d87d9ff8cd5eae1449555f3d6e625fa49
commit + 6343cff9c1cfbbf9ba2cb06cfeca507caa06fc8c
blob - 001a437045be145322be30288c1f47d63fb07634
blob + 0bd908e273a1c0e6324e1bc9f8c8ca921555c86f
--- sys/arch/amd64/amd64/identcpu.c
+++ sys/arch/amd64/amd64/identcpu.c
@@ -208,6 +208,7 @@ const struct {
{ SEFF0ECX_AVX512VBMI,  "AVX512VBMI" },
{ SEFF0ECX_UMIP,"UMIP" },
{ SEFF0ECX_PKU, "PKU" },
+   { SEFF0ECX_WAITPKG, "WAITPKG" },
 }, cpu_seff0_edxfeatures[] = {
{ SEFF0EDX_AVX512_4FNNIW, "AVX512FNNIW" },
{ SEFF0EDX_AVX512_4FMAPS, "AVX512FMAPS" },
blob - cbde6cf9b02fc882a8ed17aa6adb5c43249e0302
blob + b26bd32e2d9ea7386b1f58960dea40b787d6a341
--- sys/arch/amd64/include/specialreg.h
+++ sys/arch/amd64/include/specialreg.h
@@ -201,6 +201,7 @@
 #define SEFF0ECX_AVX512VBMI0x0002 /* AVX-512 vector bit inst */
 #define SEFF0ECX_UMIP  0x0004 /* UMIP support */
 #define SEFF0ECX_PKU   0x0008 /* Page prot keys for user mode */
+#define SEFF0ECX_WAITPKG   0x0010 /* UMONITOR/UMWAIT/TPAUSE insns */
 /* SEFF EDX bits */
 #define SEFF0EDX_AVX512_4FNNIW 0x0004 /* AVX-512 neural network insns */
 #define SEFF0EDX_AVX512_4FMAPS 0x0008 /* AVX-512 mult accum single prec */
blob - 6b4802abf4b508495cdbc961bd799d3fa83b9c36
blob + bbe10bd4cfd7e778132eca1d97594e10513ac172
--- sys/arch/amd64/include/vmmvar.h
+++ sys/arch/amd64/include/vmmvar.h
@@ -672,7 +672,12 @@ struct vm_mprotect_ept_params {
 SEFF0EBX_AVX512IFMA | SEFF0EBX_AVX512PF | \
 SEFF0EBX_AVX512ER | SEFF0EBX_AVX512CD | \
 SEFF0EBX_AVX512BW | SEFF0EBX_AVX512VL)
-#define VMM_SEFF0ECX_MASK ~(SEFF0ECX_AVX512VBMI)
+/*
+ * Copy from host minus:
+ *  AVX-512 vector bit (SEFF0ECX_AVX512VBMI)
+ *  UMONITOR/UMWAIT/TPAUSE (SEFF0ECX_WAITPKG)
+ */
+#define VMM_SEFF0ECX_MASK ~(SEFF0ECX_AVX512VBMI | SEFF0ECX_WAITPKG)

 /* EDX mask contains the bits to include */
 #define VMM_SEFF0EDX_MASK (SEFF0EDX_MD_CLEAR)
blob - 310208ac4cdb262aaedfa9b78d869fd5911607b2
blob + ccf1164fd658a69dc383e1602ae0ce1f269de4e4
--- sys/arch/i386/i386/machdep.c
+++ sys/arch/i386/i386/machdep.c
@@ -1038,6 +1038,7 @@ const struct cpu_cpuid_feature cpu_seff0_ecxfeatures[]
{ SEFF0ECX_UMIP,"UMIP" },
{ SEFF0ECX_AVX512VBMI,  "AVX512VBMI" },
{ SEFF0ECX_PKU, "PKU" },
+   { SEFF0ECX_WAITPKG, "WAITPKG" },
 

Re: Issues booting alpine linux > 3.5 on vmm - openbsd7.2

[Dave Voutila]

di...@santanas.co.za writes:

> Hi OpenBSD friends,
>
> Just a report, not sure if it's helpful, but @voutilad requested [1] I
> send the details to the mailing list.
>
> I have seen a few reports online[1][2], about some users not being able to
> boot newer alpine linux versions (and other linux OS' in my
> experience).  Specifically I've seen the last version that boots is
> 3.5.3.
>
> My system is openbsd 7.2 on my hardware Lenovo ThinkPad E14 Gen 4
> laptop.
>
> The issue, when the alpine linux VM boots, it kernel panics.
>
> [0.052602]local IPI:
> [0.052602] invalid opcode:  [#1] SMP PTI
> [0.052602] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.79-0-virt 
> #1-Alpine
> [0.052602] Hardware name: OpenBSD VMM, BIOS 1.14.0p0-OpenBSD-vmm 
> 01/01/2011
> [0.052602] RIP: 0010:delay_halt_tpause+0xd/0x20
> [0.052602] Code: 75 fb 48 ff c8 31 c0 31 ff c3 cc cc cc cc 66 66 2e 0f 1f 
> 84 00 00 00 00 00 0f 1f 40 00 48 8d 04 37 31 c9 48 89 c2 48 c1 ea 20 <66> 0f 
> ae f1 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc 53 48 c7

The key issue here is the invalid opcode error coming from the
instruction starting with 66 0f ae, which is a TPAUSE
instruction. Hence the RIP pointing to "delay_halt_tpause" in the Linux
kernel.

I don't think I have any newer Intel hardware that supports the "User
Wait" instructions (aka WAITPKG). My Intel research says it premiered in
Tremont, Alder Lake, Sapphire Rapids so I can't test locally, but the
docs from Intel (SDM Vol. 2B 4-719) say:

 Prior to executing the TPAUSE instruction, an operating system may
 specify the maximum delay it allows the processor to suspend its
 operation. It can do so by writing TSC-quanta value to the
 following 32-bit MSR (IA32_UMWAIT_CONTROL at MSR index E1H)...

We probably should be masking the CPUID value for TPAUSE in the values
vmm(4) communicates via vmm_handle_cpuid.


> [0.052602] RSP: :abb88000be58 EFLAGS: 00010207
> [0.052602] RAX: 0400ed7bcebe RBX: 0400ed7bc48a RCX: 
> 
> [0.052602] RDX: 0400 RSI: 0a34 RDI: 
> 0400ed7bc48a
> [0.052602] RBP: 0a34 R08:  R09: 
> 
> [0.052602] R10:  R11:  R12: 
> 000f423f
> [0.052602] R13: 34f08bbb5552eaa2 R14: 7d508ff23393eff5 R15: 
> 49ec817d3937
> [0.052602] FS:  () GS:93e07e60() 
> knlGS:
> [0.052602] CS:  0010 DS:  ES:  CR0: 80050013
> [0.052602] CR2: 93e04c801000 CR3: 0c00a000 CR4: 
> 00150eb0
> [0.052602] Call Trace:
> [0.052602]  
> [0.052602]  delay_halt+0x36/0x60
> [0.052602]  test_nmi_ipi.constprop.0+0xce/0x147
> [0.052602]  dotest.constprop.0+0x1e/0xf2
> [0.052602]  nmi_selftest+0x9b/0x213
> [0.052602]  native_smp_cpus_done+0x4c/0x10e
> [0.052602]  kernel_init_freeable+0x1bd/0x369
> [0.052602]  ? rest_init+0xc0/0xc0
> [0.052602]  kernel_init+0x11/0x120
> [0.052602]  ret_from_fork+0x22/0x30
> [0.052602]  
> [0.052602] Modules linked in:
> [0.052618] ---[ end trace 710ae769548b59b6 ]---
> [0.054142] RIP: 0010:delay_halt_tpause+0xd/0x20
> [0.055698] Code: 75 fb 48 ff c8 31 c0 31 ff c3 cc cc cc cc 66 66 2e 0f 1f 
> 84 00 00 00 00 00 0f 1f 40 00 48 8d 04 37 31 c9 48 89 c2 48 c1 ea 20 <66> 0f 
> ae f1 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc 53 48 c7
> [0.061264] RSP: :abb88000be58 EFLAGS: 00010207
> [0.062602] RAX: 0400ed7bcebe RBX: 0400ed7bc48a RCX: 
> 
> [0.062602] RDX: 0400 RSI: 0a34 RDI: 
> 0400ed7bc48a
> [0.062614] RBP: 0a34 R08:  R09: 
> 
> [0.064880] R10:  R11:  R12: 
> 000f423f
> [0.067126] R13: 34f08bbb5552eaa2 R14: 7d508ff23393eff5 R15: 
> 49ec817d3937
> [0.069334] FS:  () GS:93e07e60() 
> knlGS:
> [0.071885] CS:  0010 DS:  ES:  CR0: 80050013
> [0.072602] CR2: 93e04c801000 CR3: 0c00a000 CR4: 
> 00150eb0
> [0.072602] Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x000b
> [0.072602] ---[ end Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x000b ]---
>
> my vm.conf
>
> vm "docker" {
> disable
> memory 1G
> cdrom "/home/ds/vms/alpine-virt-3.17.0-x86_64.iso"
> disk "/home/ds/vms/docker.img"
> local interface
> }
>
>
> My dmesg is below[3].
>
> I have attempted below actions, however they haven't made any difference:
> - try debian-11.6.0-amd64-netinst.iso.  It doesnt panic, that I can
>   see, but seems to freeze right at the beginning.
> - pass "console=/dev/ttyS0,115200" to the kernel command line arguments.
> - boot my system with default sysctl values.
>
> @voutilad 

Re: vmm(4)/vmd(8) trouble: vmd exits with proc_dispatch msgbuf_write error

[Dave Voutila]

"Theo de Raadt"  writes:

>> vmd: getgrnam
>> parent: proc_dispatch: msgbuf_write: Broken pipe
>
> Your /etc/group file is out of date.
>
> And this code in vm_agentx.c is very unreasonable:
>
> /*
>  * Make sure we can connect to /var/agentx/master with the correct
>  * group permissions.
>  */
> if ((grp = getgrnam(AGENTX_GROUP)) == NULL)
> fatal("getgrnam");
>
> It's crazy; people who are not using that stuff should not pay the price.

Agreed. If martijn@ isn't available to fix/relax this I'll write
something up later this week.

Re: vmm(4)/vmd(8) trouble: vmd exits with proc_dispatch msgbuf_write error

[Dave Voutila]

"matthew j weaver"  writes:

> Howdy, all.
>
> I'm at my wit's end and am hoping somebody can spot what I'm
> overlooking.
>
> I cannot get vmd to run on some hardware which seems like it should
> support virtualization. CPU is an Intel(R) Core(TM) i5-7200U (full dmesg
> is below my message).
>
> sietchtabr# dmesg|grep vmm
> cpu0: using VERW MDS workaround (except on vmm entry)
> vmm0 at mainbus0: VMX/EPT
>
>
> Here's my minimum representation -- I've worked backwards to no vm.conf
> in an attempt to make sure it's not my configuration which causes vmd to
> exit shortly after startup. I see the same behavior with various
> configuration files, including the one from /etc/exmaples:
>
> sietchtabr# dmesg | egrep '(VMX/EPT|SVM/RVI)'
> vmm0 at mainbus0: VMX/EPT
> vmm0 at mainbus0: VMX/EPT
> sietchtabr# doas fw_update
> fw_update: added none; updated none; kept athn,intel,inteldrm,vmm
> sietchtabr# doas syspatch
> sietchtabr# doas vmd -dvvv
> startup
> failed to open /etc/vm.conf: No such file or directory
> vmd_configure: setting staggered start configuration to parallelism: 2
> and delay: 30
> vmd_configure: starting vms in staggered fashion
> start_vm_batch: starting batch of 2 vms
> start_vm_batch: done starting vms
> vmd: getgrnam

This looks to be coming from vm_agentx.c. What does this look like on
your machine?

$ group info _agentx
name_agentx
passwd  *
gid 92
members

If that group is missing, how did you install or update to 7.2?

> parent: proc_dispatch: msgbuf_write: Broken pipe
> config_getconfig: control retrieving config
> control exiting, pid 61440
> priv exiting, pid 51297
> vmm exiting, pid 49736
> sietchtabr#
>
> What I am missing or what might be my next steps to investigate? I'm
> baffled.
>
> cheers
> weaver
>
> 
> OpenBSD 7.2 (GENERIC.MP) #0: Wed Oct 26 12:01:47 MDT 2022
> 
> r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 34256113664 (32669MB)
> avail mem = 33200508928 (31662MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8d317000 (86 entries)
> bios0: vendor American Megatrends Inc. version "5.12" date 07/08/2019
> bios0: Protectli FW6
> acpi0 at bios0: ACPI 6.1
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SSDT HPET SSDT SSDT UEFI 
> SSDT LPIT WSMT SSDT SSDT SSDT SSDT DBGP DBG2 DMAR ASF!
> acpi0: wakeup devices PS2K(S0) PS2M(S0) RP09(S0) PXSX(S0) RP10(S0) PXSX(S0) 
> RP11(S0) PXSX(S0) RP12(S0) PXSX(S0) RP13(S0) PXSX(S0) RP01(S0) PXSX(S0) 
> RP02(S0) PXSX(S0) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2394.42 MHz, 06-8e-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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
> 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2394.43 MHz, 06-8e-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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
> 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 2399 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG0)
> acpiprt2 at acpi0: bus -1 (PEG1)
> acpiprt3 at acpi0: bus -1 (PEG2)
> acpiprt4 at acpi0: bus -1 (RP09)
> acpiprt5 at acpi0: bus -1 (RP10)
> acpiprt6 at acpi0: bus -1 (RP11)
> acpiprt7 at acpi0: bus -1 (RP12)
> acpiprt8 at acpi0: bus -1 (RP13)
> acpiprt9 at acpi0: 

updated vmm support modules for older Linux guests

[Dave Voutila]

I finally got around to slapping more hacky #ifdef's onto my vmm_clock
[1] and virtio_vmmci [2] Linux kernel modules because I found older
Linux kernel versions (~3.10 era) didn't support compiling them.

If you host things like CentOS 7 guests under vmm(4)/vmd(8), I recommend
trying them out and opening a GitHub issue in the respective project if
there's something wrong. (PR's welcome.)

No idea what I'm talking about?

  * virtio_vmmci - Linux port of vmmci(4) that helps signal reboots/rtc
sync with Linux guests via vmctl(8) and vmd(8).

  * vmm_clock - duct-taped version of kvmclock to work with vmm(4)'s
pvclock(4) paravirtualized clock.

-dv

[1] https://github.com/voutilad/virtio_vmmci
[2] https://github.com/voutilad/vmm_clock

Re: VM(D) Interface Question

[Dave Voutila]

Holger Glaess  writes:

> Hi
>
>
> how many Interfaces can an single VM have ?
>
>
> With 3 Interface in my vm.conf the vm works, with 4 not i get "to many
> interfaces".
>

The maximum supported per vm is currently 4. Without your config or
invocation triggering the "too many interfaces" when you use 4, I cannot
explain any further. Debug output would also be helpful to make sure
it's the message coming from the config parsing as I suspect.

-dv

Re: whither struct __kvm?

[Dave Voutila]

"Lyndon Nerenberg (VE7TFX/VE6BBM)"  writes:

> The first declaration in  is:
>
>   typedef struct __kvm kvm_t;
>
> and yet 'grep -r __kvm /usr/include /sys' returns only the above
> line.  What am I missing?
>

Since you don't say what you're expecting to *see* I'm not sure how to
tell you what you aren't seeing. Let's assume you want to know about
where the struct comes from and what uses it...

man 3 kvm

Do you even have a source tree checked out to /usr/src? See
/usr/src/lib/libkvm.

-dv

Re: Lenovo IdeaPad 3 14ITL05 EST turbo mode

[Dave Voutila]

Mikhail  writes:

> Recently I've bought subject laptop, but it had an issue - when I was
> doing git clone of a any huge tree, like linux kernel, it shut down in
> the beginning of 'Resolving deltas' stage. I'd tested Debian 11 and
> OpenBSD (current) - Debian shut down almost immediately, OpenBSD was
> working randomly but about ~3 minutes.
>
> Service guys set up Windows 10 on it and git clone worked fine there,
> they also did AIDA64 stress testing for a day, and I'd tested latest
> Ubuntu 22.04.1 and it worked without the issue. I did some digging and
> came up with this commit:
>
> ---
> commit 086aa750ab8f1698a6c6eaafe1458279776ce66d
> from: tb 
> date: Wed Aug 11 18:15:50 2021 UTC
>
> Make hw.setperf percentages proportional to the enhanced speed step
> frequencies on intel processors. This way, the default hw.setperf=99
> corresponds to the maximum ordinary speed while setting it to 100
> enables turbo mode.
>
> Tested in snaps for a week, positive feedback from several.
>
> M  sys/arch/amd64/amd64/est.c
> ---
>
> Apparently setperf was set to 100, and if the CPU works in that "turbo
> mode" for long enough it overheats and shuts down (sensors shows
> temperature of ~100C while in 'Resolving deltas').
>
> Work around was to set:
> hw.perfpolicy=manual
> hw.setperf=99
>
> I was watching how Windows 10 behaves and noticed that when CPU
> intensive thing starts - it boosts CPU for 100% for about 5 seconds and
> then drops it to 85% and continue to work in this mode till the end of
> the task.
>
> My previous laptop is around 12 years old, so I don't follow how modern
> HW in this segment works, I was told that current laptops can work in
> high speed mode only for a while, and then they should back to normal
> speeds, otherwise behavior is unpredictable (as with this one).
>
> I'd like to know from your experience - is that shitty cooling design
> from Lenovo, or the OSes should be more careful about setting turbo
> mode? Since the commit is 1 year old and no one complained, I assume
> it's first, but would like to know opinion of the list.

Both, imo. My Surface Go3 exhibits this, so if I'm compiling a kernel or
running a high-cpu process for more than 30s or so I manualy setperf to
~45-55 otherwise it overheats and the firmware does a safety shutoff.

Some folks as well as myself have experimented with implementing more
"modern" HWP support but from my experience doing so it's not a silver
bullet in these thermal situations. Intel's SDM isn't very clear, to me,
on how much faith we can put into the cpu to self-regulate and it's
clear from looking at other OS's they have to use thermal sensors to do
some self-regulation. Diffs have floated around, but it's not a simple
problem to solve, unfortunately. And while Intel does it one way...AMD
has their own conventions.

We also don't generally have concensus on the actual problem we want to
solve. Some folks care about battery life. I care about thermal issues
and don't want something burning a hole through my lap and killing
itself in the process. This leads to too many knobs and dials in
everyone's proposed diffs.

so the tl;dr: any passively cooled mobile Intel chipsets these days
are really a gamble and the hw vendors are punting responsibility to os
developers to account for their lack of cooling.

-dv

Re: cpus spinning using three or more pipes in a chain

[Dave Voutila]

Stuart Henderson  writes:

> On 2022-08-15, gwes  wrote:
>> Unexpected behavior:
>>    When I try to chain three programs together with pipes moving lots
>> of data spin time goes up on most or all CPUs.
>> Is this known or expected?
>>
>> the chain [shortened] was
>>    find /someplace -maxdepth 2 -type f -name '*.flac' -exec \
>>   metaflac -list --block-type=VORBIS_COMMENT {} + | \
>>   awk '{mangle}' | \
>>   sed -e 's/foo/bar/' | \
>>   sort -o outfile
>>
>> On a slow (1.6GHz 8GB) system with an SSD the spin times went
>> as high as 50% on all cpus. When that happens the sys times
>> also go very high rendering the system effectively
>> unusable. Swap space used = 0.
>> That system is no longer available for testing.
>>
>> This is a simplified example on a Ryzen 3600G w/64MB ram & reasonable
>> rotating rust:
>> The test file is 3.6G
>> Under some test cases the spin times go as high as 20% on two or three CPUs
>> simultaneously. Those are transient and hard to capture.
>> I can rerun this using -CURRENT if that would give better information.
>>
>> Rsults have been more or less the same 6.9, 7.0, 7.1
>>
>> 11881$ cat m2abc.txz m2abc.txz m2abc.txz | cat | cat | cat > xx
>
> -current looks similar. (I catted /bsd a few times to make a test file,
> in this case the filesystem is on softraid crypto over nvme).
>
> CPU0:  0.0% user,  0.0% nice, 45.1% sys, 15.7% spin, 23.5% intr, 15.7% idle
> CPU1:  0.0% user,  0.0% nice, 33.3% sys, 41.2% spin,  0.0% intr, 25.5% idle
> CPU2:  2.0% user,  0.0% nice, 39.2% sys, 23.5% spin,  0.0% intr, 35.3% idle
> CPU3:  2.0% user,  0.0% nice, 29.4% sys, 27.5% spin,  0.0% intr, 41.2% idle
> Memory: Real: 5172M/15G act/tot Free: 654M Cache: 6685M Swap: 22M/2048M
>
> "yes | cat | cat | cat > xx" doesn't hit it.
>
> Don't know if it gives any clues but a flamegraph generated while
> running the multiple cat pipe on my laptop looks like
> https://junkpile.org/cat-spin-flame.svg

_kernel_lock() was in 24% of the samples. If you add up the spin you get
about 90%, which is ~24% of 400%...the max possible sum of spin across 4
cpus.

Comes from the dofilereadv() -> vn_read() -> _kernel_lock() chain.

I think that explains why your `yes | cat...` example doesn't hit
it. I'm not on/near a machine with btrace available to generate a
flamegraph for that example but curious what it looks like.

-dv

Multiuser security on OpenBSD

[Dave Levine]

Hello all,

I'm new to the mailing list so feel free to yell at me if I messed
something up here.

I currently use OpenBSD on my laptop for a number of reasons, mainly
performance and hardware support. However, I have been considering
setting up a multiuser POWER9 box for some Discord friends and I to
work on in a hobbyist setting (these things are expensive and I'm the
one who currently has the machine we want to work on), but need to
know if OpenBSD is a good option for that. As it apparently lacks
mitigations for multiple medium-risk hardware side channel attacks, I
think it is important to ask: What does OpenBSD do to stop an
unprivileged user with access to a compiler or shell from copy-pasting
a proof-of-concept exploit to siphon e.g. SSH private keys, root
passwords and the like, or are these more difficult to exploit than I
give them credit for with things like (K)ASLR enabled?

Thanks,
- Dave

Re: Mutt cannot sent mail in OpenBsd

[Dave Voutila]

wim  writes:

> Hi everybody,
>
> I have this weird issue.
> I can read the mails with mutt on openbsd but when I want to sent I
> get this message from the mutt log:
> [2022-07-08 14:33:16] mutt_send_message() Sending message...
> [2022-07-08 14:33:16] raw_socket_open() Looking up mail.thinkerwim.org...
> [2022-07-08 14:33:16] raw_socket_open() Connecting to
> mail.thinkerwim.org...
> [2022-07-08 14:33:16] ssl_negotiate() SSL failed:
> error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify
> failed
> [2022-07-08 14:33:16] smtp_open() Could not negotiate TLS connection
>
> From the OPENSMTPD maillog I find this
> Jul  8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp
> connected address=46.23.92.40 host=mail.thinkerwim.org
> Jul  8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp
> disconnected reason="io-error: handshake failed: error:1403F416:SSL
> routines:ACCEPT_SR_FINISHED:sslv3 alert certificate unknown"
>
>
> The weird thing is , if I run the same configuration of mutt on my
> linux machine everything works.
>

You might want to rethink your definition of "works" in this case.

> Any idea ?
>

You sure you've configured a certificate and TLS on your mailserver? I
don't see one. I a TLS listener on port :443 of mail.thinkerwim.org but
that cert is for www.thinkerwim.org.

$ openssl s_client -showcerts -servername mail.thinkerwim.org -connect 
mail.thinkerwim.org:587
CONNECTED(0003)
14696819295368:error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert 
protocol version:/usr/src/lib/libssl/tls13_lib.c:151:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 322 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.3
Cipher: 
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1657288016
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---

Re: Latest -current boots very slow in VM

[Dave Voutila]

Mischa  writes:

> Hi All,
>
> Just updated one of my -current test VMs to the snapshot of June 30.
> The boot process takes extremely long. As soon as it's booting:
>
> ###
> Using drive 0, partition 3.
> Loading..
> probing: pc0 com0 mem[638K 3838M 4352M a20=on]
> disk: hd0+
>>> OpenBSD/amd64 BOOT 3.53
> \
> com0: 115200 baud
> switching console to com0
>>> OpenBSD/amd64 BOOT 3.53
> boot>
> NOTE: random seed is being reused.
> booting hd0a:/bsd: 15590680+3761168+305600+0+1167360
> [1158148+128+1222128+926180]=0x1705860
> entry point at 0x81001000
> ###
>
> The above is all normal speed, and after this point all characters are
> printed at the speed of around 1 second per character.
> For example printing the below in the console:
>
> ###
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights
> reserved.
> Copyright (c) 1995-2022 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
>
> OpenBSD 7.1-current (GENERIC) #574: Thu Jun 30 12:08:08 MDT 2022
> ###
>
> Took around 4-5 minutes.
> After:
>
> ###
> cpu0: Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz, 3200.02 MHz, 06-3f-02
> ###
>
> It's speeding up a little.
>
> The host itself runs 7.1-stable, and there are 11 other VMs (running
> 7.1-stable).
> The previou release was an older -current without any issues.
> On hardware it boots normal. Anything obvious I am missing?
>

What does the guest vmd process look like? Is the cpu% in top showing
it's very busy?

Is it just serial console that's slow on the guest? (If you connect via
ssh, is it normal?)

-dv

apm(4) ioctls

[Dave Vandervies]

On amd64 and aarch64 (the two architectures I have access to to
check), the man page for apm(4) documents APM_IOC_NEXTEVENT, which
doesn't appear in .
(grep tells me that it also appears in the man pages for i386 and
macppc and does not appear in any src/sys/arch/*/include/apmvar.h.)

It looks like apmd uses kqueue to get this information; that interface
doesn't appear in any documentation I've found.

Am I looking in the wrong places, or is the documentation wrong
here?  Is the way apmd does it meant to be a supported interface?


Thanks,
dave

-- 
Dave Vandervies
dj3va...@terse.ca

Plan your future!  Make God laugh!

Re: Framework laptop fails to enter sleep/suspend/hibernate

[Dave Voutila]

Andrew W  writes:

> Not sure what else to try but I can't seem to get sleep/suspend to work on
> my frame.work laptop. I've tried OpenBSD 7.0 and 7.1 now, running off a 1TB
> USB drive.

S4/Hibernation is not supported when swap is on a USB disk. I haven't
read the suspend code paths lately, but I wouldn't be susprised if this
is a problem as well.

>
> Running apm -S or apm -z the screen goes blank and the keyboard remains
> backlit, eventually the fan starts spinning faster. I need to long press
> the power button to force shutdown the machine. Hibernate says it's not
> supported, which is a bit less of a concern to me but having one of them
> working would be very helpful.
>
> I've tried w/o X running, same results. I don't see any failures related to
> the TPM in dmesg but also I've tried w/ it set to "hidden" in the bios,
> same result.
>
> I'm new to OpenBSD so maybe I'm missing something important to get this
> working but I haven't seen much in the way of configuration related to this
> functionality?

Can you try with your root and swap partitions on your nvme disk and not
on USB? Barring that, capturing all your machine details with sendbug(1)
would be helpful.

-dv

Re: reordering libraries: fdcresult: overrun

[Dave Voutila]

rtw0 dtw0  writes:

> Hi,
> When my OpenBSD vm boots I receive the following message:
>
> *reordering libraries: fdcresult: overrun*
>

Vm version, host version, etc. etc. Not enough info here.

There was an issue address in vmm(4) that caused noise from the fdc(4)
driver, but that was fixed in November and will be in 7.1 once
released.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/vmm.c?rev=1.295=text/x-cvsweb-markup

-dv

Re: Thinkpad T480 high cpu after zzz

[Dave Voutila]

el 100 Series PCIE" rev 0xf1: msi
> pci8 at ppb7 bus 61
> nvme0 at pci8 dev 0 function 0 "Intel NVMe" rev 0x03: msix, NVMe 1.3
> nvme0: INTEL SSDPEKKF256G8L, firmware L15P, serial PHHH8520066K256B
> scsibus1 at nvme0: 2 targets, initiator 0
> sd0 at scsibus1 targ 1 lun 0: 
> sd0: 244198MB, 512 bytes/sector, 500118192 sectors
> pcib0 at pci0 dev 31 function 0 "Intel 200 Series LPC" rev 0x21
> "Intel 100 Series PMC" rev 0x21 at pci0 dev 31 function 2 not configured
> azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x21: msi
> azalia0: codecs: Realtek ALC257, Intel/0x280b, using Realtek ALC257
> audio0 at azalia0
> ichiic0 at pci0 dev 31 function 4 "Intel 100 Series SMBus" rev 0x21:
> apic 2 int 16
> iic0 at ichiic0
> em0 at pci0 dev 31 function 6 "Intel I219-V" rev 0x21: msi, address
> e8:6a:64:f6:3b:a9
> isa0 at pcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> wsmouse1 at pms0 mux 0
> pms0: Synaptics clickpad, firmware 8.16, 0x1e2b1 0x940300 0x33cc40
> 0xf016a3 0x12e800
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> vmm0 at mainbus0: VMX/EPT
> efifb at mainbus0 not configured
> uhub0: port 3, set config 0 at addr 2 failed
> uhub0: device problem, disabling port 3
> ugen0 at uhub0 port 7 "Intel Bluetooth" rev 2.00/0.10 addr 2
> uvideo0 at uhub0 port 8 configuration 1 interface 0 "Azurewave
> Integrated Camera" rev 2.01/17.11 addr 3
> video0 at uvideo0
> ugen1 at uhub0 port 9 "Synaptics product 0x009a" rev 2.00/1.64 addr 4
> umass0 at uhub0 port 15 configuration 1 interface 0 "Generic
> USB3.0-CRW" rev 3.00/2.04 addr 5
> umass0: using SCSI over Bulk-Only
> scsibus2 at umass0: 2 targets, initiator 0
> sd1 at scsibus2 targ 1 lun 0:  removable
> serial.0bda031650103090
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> root on sd0a (139b9fe31154e28e.a) swap on sd0b dump on sd0b
> inteldrm0: 1920x1080, 32bpp
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> iwm0: hw rev 0x230, fw ver 36.ca7b901d.0, address 48:89:e7:99:be:25
>
>
>  tail -f /var/log/messages & zzz
>
> Mar 14 18:28:23 ashen apmd: system suspending
> Mar 14 18:28:23 ashen apmd: battery status: high. external power
> status: connected. estimated battery life 100%
> Mar 14 18:28:25 ashen /bsd: ugen0 detached
> Mar 14 18:28:26 ashen /bsd: video0 detached
> Mar 14 18:28:26 ashen /bsd: uvideo0 detached
> Mar 14 18:28:27 ashen /bsd: ugen1 detached
> Mar 14 18:28:28 ashen /bsd: sd1 detached
> Mar 14 18:28:28 ashen /bsd: scsibus2 detached
> Mar 14 18:28:29 ashen /bsd: umass0 detached
> Mar 14 18:28:35 ashen /bsd: uhub0 detached
> Mar 14 18:28:35 ashen /bsd: uhub1 detached
> Mar 14 18:28:35 ashen /bsd: uhub0 at usb0 configuration 1 interface 0
> "Intel xHCI root hub" rev 3.00/1.00 addr 1
> Mar 14 18:28:35 ashen /bsd: uhub1 at usb1 configuration 1 interface 0
> "Intel xHCI root hub" rev 3.00/1.00 addr 1
> Mar 14 18:28:35 ashen /bsd: ugen0 at uhub0 port 3 "Generic EMV
> Smartcard Reader" rev 2.01/1.20 addr 2
> Mar 14 18:28:46 ashen /bsd: ugen0: setting configuration index 0 failed
> Mar 14 18:28:46 ashen /bsd: ugen1 at uhub0 port 7 "Intel Bluetooth"
> rev 2.00/0.10 addr 3
> Mar 14 18:28:47 ashen /bsd:
> drm:pid91513:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm]
> [ENCODER:94:DDI \M-j/PHY h] is disabled/in DSI mode with an ungated
> DDI clock, gate it
> Mar 14 18:28:47 ashen /bsd:
> drm:pid91513:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm]
> [ENCODER:102:DDI \M-j/PHY h] is disabled/in DSI mode with an ungated
> DDI clock, gate it
> Mar 14 18:28:47 ashen /bsd:
> drm:pid91513:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm]
> [ENCODER:116:DDI \M-j/PHY h] is disabled/in DSI mode with an ungated
> DDI clock, gate it
> Mar 14 18:28:47 ashen apmd: system resumed from sleep
> Mar 14 18:28:47 ashen apmd: battery status: high. external power
> status: connected. estimated battery life 100%
> Mar 14 18:28:48 ashen /bsd: uvideo0 at uhub0 port 8 configuration 1
> interface 0 "Azurewave Integrated Camera" rev 2.01/17.11 addr 4
> Mar 14 18:28:48 ashen /bsd: video0 at uvideo0
> Mar 14 18:28:49 ashen /bsd: ugen2 at uhub0 port 9 "Synaptics product
> 0x009a" rev 2.00/1.64 addr 5
> Mar 14 18:28:50 ashen /bsd: umass0 at uhub0 port 15 configuration 1
> interface 0 "Generic USB3.0-CRW" rev 3.00/2.04 addr 6
> Mar 14 18:28:50 ashen /bsd: umass0: using SCSI over Bulk-Only
> Mar 14 18:28:50 ashen /bsd: scsibus2 at umass0: 2 targets, initiator 0
> Mar 14 18:28:50 ashen /bsd: sd1 at scsibus2 targ 1 lun 0:  SD/MMC, 1.00> removable serial.0bda031650103090


--
-Dave Voutila

Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM

[Dave Voutila]

"Ted Unangst"  writes:

> On 2022-02-25, Robert Nagy wrote:
>> Maybe we need a default vmd class? What do you guys think?
>
> Regardless of what the limit is, this seems like a daemon where people
> will bump into the limit. Perhaps a reminder is in order too?
>

The reminder is good, but we still need to fix the problem that the vmm
process can abort given the child dies so quickly. On my machine, the
call to read(2) results in a zero byte read, tripping the existing fatal
path.


diff ff838b72f50de699ee43d3dac58ff7e8435669ee /usr/src
blob - 4c6c99f1133cec7cb1e38dfd22e595e4d2023842
file + usr.sbin/vmd/vm.c
--- usr.sbin/vmd/vm.c
+++ usr.sbin/vmd/vm.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
ret = alloc_guest_mem(vcp);

if (ret) {
+   struct rlimit lim;
+   const char *msg = "could not allocate guest memory - exiting";
+   if (getrlimit(RLIMIT_DATA, ) == 0)
+   msg = "could not allocate guest memory (data limit is 
%llu) - exiting";
errno = ret;
-   fatal("could not allocate guest memory - exiting");
+   fatal(msg, lim.rlim_cur);
}

ret = vmm_create_vm(vcp);
blob - eb75b4c587884ec43704420ef4172386a5b39bd9
file + usr.sbin/vmd/vmm.c
--- usr.sbin/vmd/vmm.c
+++ usr.sbin/vmd/vmm.c
@@ -616,6 +616,7 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *p
int  ret = EINVAL;
int  fds[2];
size_t   i, j;
+   ssize_t  sz;

if ((vm = vm_getbyvmid(imsg->hdr.peerid)) == NULL) {
log_warnx("%s: can't find vm", __func__);
@@ -674,9 +675,13 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *p
}

/* Read back the kernel-generated vm id from the child */
-   if (read(fds[0], >vcp_id, sizeof(vcp->vcp_id)) !=
-   sizeof(vcp->vcp_id))
+   sz = read(fds[0], >vcp_id, sizeof(vcp->vcp_id));
+   if (sz < 0)
fatal("read vcp id");
+   else if (sz != sizeof(vcp->vcp_id)) {
+   log_warn("failed to read vcp id");
+   goto err;
+   }

if (vcp->vcp_id == 0)
goto err;

Syncing users between two OpenBSD systems

[Dave Wilson]

Hi all,

I am setting up a pair of OpenBSD jump boxes, to be a pair of bastion hosts
of a large network.
I would like to have a primary and backup, with the same set of users on
each one.
I do not want to use YP or any other form of authentication server, because
part of the use case for these machines is that they are the jumping off
point for fixing everything else when things are broken.

I am aware that OpenBSD goes to some length to ensure the integrity of the
files /etc/passwd, master.passwd, group et al, providing various utilities
to manipulate them and even vipw for those rare occasions when you want to
edit the raw files, so I am very reluctant to just rsync files from the
primary to the backup, bypassing these protections.

Is there a clean way to do this sort of user synchronisation? I can write a
script which will run useradd (or userdel etc) on one machine and then the
other, but if there is a "correct" way to do such a thing, I would rather
do that than reinvent the wheel.

Cheers,

Dave W

Re: acpi0: sleep states S0 S3 S5, was: S0 S3 S4 S5

[Dave Voutila]

Try the next snap. I believe a diff slipped in temporarily.

-dv

> On Feb 18, 2022, at 11:38, Marcus MERIGHI  wrote:
> 
> Hello!
> 
> I'm not sure this should go to bugs@.
> 
> On three machines that I upgraded to the latest snapshot 
> yesterday, "S4" vanished:
> 
> -acpi0: sleep states S0 S3 S4 S5
> +acpi0: sleep states S0 S3 S5
> 
> These are all amd64.
> 
> Dmesgs below, seperated by "-".
> 
> Marcus
> 
> - Shuttle Inc. DS57U
> 
> OpenBSD 7.0-current (GENERIC.MP) #361: Thu Feb 17 01:50:24 MST 2022
>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16031678464 (15289MB)
> avail mem = 15528607744 (14809MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec2f0 (82 entries)
> bios0: vendor American Megatrends Inc. version "1.06" date 03/04/2015
> bios0: Shuttle Inc. DS57U
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF!
> SLIC SSDT SSDT SSDT DMAR
> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4)
> PEGP(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, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.65 MHz, 06-3d-04
> 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,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.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.23 MHz, 06-3d-04
> 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> acpimadt0: bogus nmi for apid 0
> acpimadt0: bogus nmi for apid 2
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG0)
> acpiprt2 at acpi0: bus -1 (PEG1)
> acpiprt3 at acpi0: bus -1 (PEG2)
> acpiprt4 at acpi0: bus 1 (RP01)
> acpiprt5 at acpi0: bus -1 (RP02)
> acpiprt6 at acpi0: bus 2 (RP03)
> acpiprt7 at acpi0: bus 3 (RP04)
> acpiprt8 at acpi0: bus -1 (RP05)
> acpiprt9 at acpi0: bus -1 (RP06)
> acpiprt10 at acpi0: bus -1 (RP07)
> acpiprt11 at acpi0: bus -1 (RP08)
> acpiec0 at acpi0: not present
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 3: ns16550a, 16 byte fifo
> com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 4: ns16550a, 16 byte fifo
> acpicmos0 at acpi0
> acpibtn0 at acpi0: SLPB
> acpibtn1 at acpi0: PWRB
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> acpicpu0 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PG00, resource for PEG0
> acpipwrres1 at acpi0: PG01, resource for PEG1
> acpipwrres2 at acpi0: PG02, resource for PEG2
> acpipwrres3 at acpi0: FN00, resource for FAN0
> acpipwrres4 at acpi0: FN01, resource for FAN1
> acpipwrres5 at acpi0: FN02, resource for FAN2
> acpipwrres6 at acpi0: FN03, resource for FAN3
> acpipwrres7 at acpi0: FN04, resource for FAN4
> acpitz0 at acpi0: critical temperature is 105 degC
> acpitz1 at acpi0: critical temperature is 105 degC
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD1F
> cpu0: using VERW MDS workaround (except on vmm entry)
> cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2201, 2200, 2100, 2000, 1800,
> 1700, 1600, 1500, 1300, 1200, 1100, 1000, 900, 700, 600, 500 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09
> inteldrm0 at pci0 dev 2 function 0 "Intel HD 

Re: Suspend/hibernate broken [upgrade: 6.9 to 7.0] (solution)

[Dave Voutila]

Clint Pachl  writes:

> This is how I got suspend and hibernate working again on my Huawei
> Matebook after upgrading to 7.0 release. I thought I'd share here in
> case it helps someone else.
>
>
> SYNOPSIS:
>
> Initiating a "sleep" state blanks the screen and illuminates the
> keyboard (indicating sleep is immenent); but the laptop would never go
> to sleep. It would also never wake up. However, pressing the power
> button cleanly shutdown the system.
>
> After comparing the 7.0 dmesg with an older version (6.6), I noticed
> this difference:
>
> tpm0 at acpi0 TPM_ addr 0xfed40040/0x1000: timed out waiting for
> validity
>
> acpi(4) confirmed that the TPM does connect to the ACPI driver. The
> kernel error message above is a good hint that the TPM could be
> preventing suspend and hibernate.

Quite possible.

>
>
> SOLUTION #1:
>
> I disabled TPM in the kernel at the boot prompt (i.e., boot -c). Within
> UKC, "tpm" matched another device. I disabled TPM specifying the device
> number (devno) of the tpm0 device.
>
>   UKC> list tpm
>   UKC> disable 433
>
> If this is the solution for you, make it permanent using the kernel
> configuration file, bsd.re-config(5).
>
>
> SOLUTION #2:
>
> There is a "TCM/TPM" setting in BIOS; I disabled it. Booting the
> base 7.0 kernel (TPM enabled) also fixed "sleep" modes.
>
> This is the solution I decided to use.
>

This is the best approach.

>
> REQUEST FOR COMMENT:
>
> I'm not sure if disabling TPM like this creates a security issue.
> Please let me know if there are negative repercussions.
>

The tpm driver exists only to assist suspend/hibernate. It's not used
for anything involving "security."

> Also, is this a bug that should be reported to bugs@?
>

Any chance you can try -current? Or maybe provide a copy of
/var/db/acpi/TPM.*? You can either disassemble it with iasl from the
acpica port, provide an inline hex dump via hexdump(1), or the
binary. It can tell me what the TPM start method is that your hardware
wants the OS to use.

I recently added support to -current for a start method seen in some TPM
2.0 devices, but it doesn't support all known methods. It might allow
you to avoid disabling in the BIOS.

A full dmesg would also be appreciated.

>
> ACPI from 7.0 DMESG:
>
> "ELAN2201" at acpi0 not configured
> "INT0E0C" at acpi0 not configured
> "INT33A1" at acpi0 not configured
> "INT3400" at acpi0 not configured
> "INT3403" at acpi0 not configured
> "INT3403" at acpi0 not configured
> "INT3403" at acpi0 not configured
> "INT3403" at acpi0 not configured
> "INT3403" at acpi0 not configured
> "INT344B" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "WDT0001" at acpi0 not configured
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP UEFI UEFI ECDT SSDT MSDM SSDT SSDT TPM2 SSDT
> SSDT SSDT ASPT BOOT HPET APIC MCFG SSDT WSMT SSDT DBGP DBG2 SSDT SSDT
> DMAR NHLT FPDT BGRT acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4)
> HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
> PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...] acpiac0 at acpi0: AC
> unit online acpials0 at acpi0: ALSD acpibat0 at acpi0: BAT0 model
> "BASE-BAT" serial 123456789 type Li oem "Kollur" acpibtn0 at acpi0:
> LID_ acpibtn1 at acpi0: PWRB acpicmos0 at acpi0
> acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60),
> C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0:
> C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1
> mwait.1), PSS acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (RP01)
> acpiprt10 at acpi0: bus -1 (RP10)
> acpiprt11 at acpi0: bus -1 (RP11)
> acpiprt12 at acpi0: bus -1 (RP12)
> acpiprt13 at acpi0: bus -1 (RP13)
> acpiprt14 at acpi0: bus -1 (RP14)
> acpiprt15 at acpi0: bus -1 (RP15)
> acpiprt16 at acpi0: bus -1 (RP16)
> acpiprt17 at acpi0: bus -1 (RP17)
> acpiprt18 at acpi0: bus -1 (RP18)
> acpiprt19 at acpi0: bus -1 (RP19)
> acpiprt2 at acpi0: bus -1 (RP02)
> acpiprt20 at acpi0: bus -1 (RP20)
> acpiprt21 at acpi0: bus -1 (RP21)
> acpiprt22 at acpi0: bus -1 (RP22)
> acpiprt23 at acpi0: bus -1 (RP23)
> acpiprt24 at acpi0: bus -1 (RP24)
> acpiprt3 at acpi0: bus -1 (RP03)
> acpiprt4 at acpi0: bus -1 (RP04)
> acpiprt5 at acpi0: bus -1 (RP05)
> acpiprt6 at acpi0: bus -1 (RP06)
> acpiprt7 at acpi0: bus 1 (RP07)
> acpiprt8 at acpi0: bus -1 (RP08)
> acpiprt9 at acpi0: bus 2 (RP09)
> acpipwrres0 at acpi0: WRST
> acpipwrres1 at acpi0: WRST
> acpipwrres10 at acpi0: WRST
> acpipwrres11 at acpi0: WRST
> 

Re: DNS lookup fails and iwm0 fatal firmware errors using OpenBSD 7.0

[Dave Turner]

On Tue, 14 Dec 2021 15:38:08 +0100
Stefan Sperling  wrote:

> On Tue, Dec 14, 2021 at 12:49:14PM +0000, Dave Turner wrote:
> > I have searched the web and tried various things but so far nothing
> > fixes it.  
> 
> This should help:
> https://marc.info/?l=openbsd-bugs=163459084214897=2

Stefan,
Thanks, 
mv /etc/firmware/iwm-7265D-29 /etc/firmware/iwm-7265D-29.orig
cp /etc/firmware/iwm-7265-17 /etc/firmware/iwm-7265D-29
and a reboot has improved things considerably!

The odd DNS timeout still gets logged but for all I know it always did
that running OpenBSD 6.n, it worked well so there was never any reason
to look.

Looking forward to 7.1!

DaveT

DNS lookup fails and iwm0 fatal firmware errors using OpenBSD 7.0

[Dave Turner]

My Asus UX305F laptop has been running OpenBSD 6.5 to 6.9 quite happily.
Did a clean install of 7.0 because of the changed partition size
requirements. The internet works for a while and then suddenly can't
find the server it was connected to.

The WiFi using iwm0 has the problems, axe0 the Ethernet via USB has not
failed so far. 
I turn off iwm0 using 
doas ifconfig iwm0 down 
and then use an external USB to ethernet connector.

I have searched the web and tried various things but so far nothing
fixes it.

The release notes for 7.0 show both DNS and iwm0 have been changed.
Is there a problem with the updated iwm0?

logs and various .conf files shown below.
Any ideas?

DaveT


ux305f$ uname -a
OpenBSD ux305f.lan 7.0 GENERIC.MP#2 amd64
syspatch is up to date.
pkg_add -u is up to date.

from dmesg
iwm0 at pci2 dev 0 function 0 "Intel AC 7265" rev 0x59, msi


/var/log/messages has repeated entries like this:-
Nov 28 09:22:17 ux305f ntpd[98379]: DNS lookup tempfail
Dec 13 13:21:14 ux305f unwind[40036]: bad packet: too short
Dec 13 13:21:45 ux305f last message repeated 4 times
Dec 13 13:23:40 ux305f last message repeated 11 times
Dec 13 13:29:45 ux305f last message repeated 33 times
Dec 13 13:29:55 ux305f ntpd[90670]: DNS lookup tempfail
Dec 13 13:29:55 ux305f ntpd[90670]: DNS lookup tempfail
Dec 13 13:30:00 ux305f unwind[40036]: bad packet: too short
Dec 13 13:30:46 ux305f last message repeated 6 times

Sometimes it also logs this:-
Dec  5 11:36:36 ux305f /bsd: iwm0: fatal firmware error
Dec  5 11:36:37 ux305f /bsd: iwm0: could not remove MAC context (error
35)


I have tried various things to try and make it work properly.
Killing ntpd didn't help.
Editing resolv.conf to add the 208.67.222.222 Open DNS server didn't
help because resolvd adds nameserver 192.168.1.254 as the first line.
So I made resolv.conf read-only. 
And still resolvd added nameserver 127.0.0.1 as the first line.

I didn't have a /etc/dhclient.conf so I created one with the single
line 
supersede domain-name-servers 1.1.1.1 
so it uses Cloudflare as recommended by openbsdhandbook.com.
That didn't help either.

my /etc/hostname.iwm0 file is:-
join MY-HOUSE wpakey my-password
join FRIENDS-HOUSE wpakey friends-password
dhcp
inet autoconf
up

until 5th December inet autoconf was inet6 autoconf.
That change didn't help either.

cat /etc/resolv.conf
nameserver 192.168.1.254 # resolvd: iwm0
nameserver 208.67.222.222 # Open DNS
nameserver 208.67.220.220 # Open DNS

cat /etc/unwind.conf  
forwarder 208.67.222.222

cat ntpd.conf
# $OpenBSD: ntpd.conf,v 1.16 2019/11/06 19:04:12 deraadt Exp $
#
# See ntpd.conf(5) and /etc/examples/ntpd.conf

servers pool.ntp.org
server time.apple.com
server 1.uk.pool.ntp.org
server 2.uk.pool.ntp.org
server 3.uk.pool.ntp.org
server time.cloudflare.com
sensor *

constraint from "9.9.9.9"  # quad9 v4 without DNS
constraint from "2620:fe::fe"  # quad9 v6 without DNS
constraints from "www.google.com"  # intentionally not 8.8.8.8



cat /etc/hostname.axe0
autoconf
inet6 autoconf

cat /etc/resolv.conf 
nameserver 127.0.0.1 # resolvd: unwind
#nameserver 192.168.1.254 # resolvd: axe0
nameserver 208.67.222.222 # Open DNS
nameserver 208.67.220.220 # Open DNS

ifconfig
ux305f$ ifconfig 
lo0: flags=8049 mtu 32768
index 3 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
iwm0:
flags=a48802
mtu 1500 lladdr 5c:e0:c5:69:07:3a index 1 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS0 mode 11n)
status: no network
ieee80211: join MY-WIFI wpakey wpaprotos wpa2 wpaakms psk
wpaciphers ccmp wpagroupcipher ccmp inet6 fe80::5ee0:c5ff:fe69:73a%iwm0
prefixlen 64 scopeid 0x1 inet 192.168.1.66 netmask 0xff00 broadcast
192.168.1.255 enc0: flags=0<>
index 2 priority 0 llprio 3
groups: enc
status: active
axe0:
flags=a48843
mtu 1500 lladdr 38:4b:76:f0:5e:72 index 4 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::3a4b:76ff:fef0:5e72%axe0 prefixlen 64 scopeid 0x4
inet 192.168.1.68 netmask 0xff00 broadcast 192.168.1.255
pflog0: flags=141 mtu 33136
index 5 priority 0 llprio 3
groups: pflog
ux305f$ 

Re: unable to send external mail with smtpd

[Dave Voutila]

freddiebub...@countermail.com writes:

> Hi, I'm new to openbsd having just set it up on my x200 and loving it
> (running so much better than my old distro). after reading through
> c0ffee's laptop set up guide and the afterboot man page i'm struggling
> to work out why i can't send mail through my mail account w smtpd. i
> have asked my provider for support about the issues i saw other people
> having (port 25 not being open) but they said that wasn't it and they
> were unsure about the problem. below i have linked to a paste of my
> smtpd.conf and my maillog. Personally i'm struggling to work out whats
> wrong from the log but i'm assuming i've not set something up right...
>
> maillog: http://ix.io/3ChF

I looked at your log messages and the only thing I can think of is this
mail provider requires some auth approach smtpd doesn't support
(CRAM-Md5). It seems they're more interested in supporting mail clients
and not a relaying connection from an MTA is my guess.

See: https://support.countermail.com/kb/faq.php?id=90

In that case, don't use smptd and configure whatever mail client you use
to connect directly to their service. (...or get a new service provider
that doesn't require CRAM-MD5)

Unless something's changed in 7-8 years I don't think OpenSMTPD is going
to support CRAM-MD5. See this old GH exchange with Gilles for some
background on why:

https://github.com/OpenSMTPD/OpenSMTPD/issues/430

-dv

Re: Alpine Linux guest running slow after upgraded to OpenBSD 7.0

[Dave Voutila]

Siegfried Levin  writes:

> An Alpine Linux 3.10 guest VM is running quite slow after I upgraded
> the host to 7.0. It takes quite long to get a response. Other OpenBSD
> guests seems ok. Is anyone having the same issue? Thanks.

You'll need to share a bit more detail for any constructive help; "quite
long" and "a response" are too vague. A lot changed in 7.0 outside just
vmm(4)/vmd(8).

-dv

Re: xterm not opening on latest snapshot?

[Dave Voutila]

henkjan gersen  writes:

> On this mornings snapshot that I just upgraded to I can no longer open
> an xterm window. Based on the .xsession-error this must be related to
> the unveil capabilities that got added last week as I see "xterm:
> unveil" appearing in that file.
>
> Can someone give a hint on what I'm missing to be able to open an
> xterm window again?

Can you try again with this diff? It should add logging and specify
which unveil is failing.


Index: app/xterm/main.c
===
RCS file: /cvs/xenocara/app/xterm/main.c,v
retrieving revision 1.50
diff -u -p -r1.50 main.c
--- app/xterm/main.c2 Sep 2021 09:31:38 -   1.50
+++ app/xterm/main.c5 Sep 2021 13:58:13 -
@@ -2911,18 +2911,18 @@ main(int argc, char *argv[]ENVP_ARG)

 snprintf(homefile, sizeof homefile, "%s/.fonts", env);
 if (unveil(homefile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", homefile);
 exit(1);
 }
 snprintf(homefile, sizeof homefile, "%s/.cache/fontconfig",
  env);
 if (unveil(homefile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", homefile);
 exit(1);
 }
 snprintf(homefile, sizeof homefile, "%s/.icons", env);
 if (unveil(homefile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", homefile);
 exit(1);
 }
 }
@@ -2931,12 +2931,12 @@ main(int argc, char *argv[]ENVP_ARG)

 snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
 if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
 exit(1);
 }
 snprintf(xdgfile, sizeof xdgfile, "%s/icons", env);
 if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
 exit(1);
 }
 }
@@ -2945,12 +2945,12 @@ main(int argc, char *argv[]ENVP_ARG)

 snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
 if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
 exit(1);
 }
 snprintf(xdgfile, sizeof xdgfile, "%s/icons", env);
 if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
 exit(1);
 }
 }
@@ -2959,7 +2959,7 @@ main(int argc, char *argv[]ENVP_ARG)

 snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
 if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
 exit(1);
 }
 }
@@ -2970,7 +2970,7 @@ main(int argc, char *argv[]ENVP_ARG)
 (unveil("/usr/local/lib/X11/icons", "r") == -1) ||
 (unveil(etc_utmp, "w") == -1) ||
 (unveil(etc_wtmp, "w") == -1)) {
-xtermWarning("unveil\n");
+xtermWarning("unveil many, %s, %s\n", etc_utmp, etc_wtmp);
 exit(1);
 }

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Dave Voutila]

Theo de Raadt writes:

> Dave Voutila  wrote:
>
>> Theo de Raadt writes:
>>
>> >> I think the easiest path here is to incorporate the new upstream into a
>> >> port, unless someone is familiar with zlib and can cherrypick out the
>> >> commit(s) that resolve the issue. (I didn't find zlib in ports already.)
>> >
>> > That is completely impossible.  It must be in base.  There are 3 copies
>> > in base -- userland, kernel, and bootblocks.  They must be kept in sync.
>>
>> Not saying to replace what's in base, but have a different version in
>> ports available for ports. I was thinking along the lines of egcc or
>> eopenssl in that the port co-exists with base and ports that need them
>> need tweaking to use them.
>
> You've got to be kidding.  In what world does it help to require -I and
> -l lines all over the place, or else everything breaks.

I'm in 100% agreement it sucks and it's something I believe is already
done for ports that require OpenSSL. /shrug. My thinking was instead of
having to test all of base across all archs with any potential fix, we
could isolate the change to maybe the R port if other R packages or
whatever have run into this.

But I'm not volunteering to do either so I'll stop beating this horse
now before it never walks again.

-dv

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Dave Voutila]

Theo de Raadt writes:

>> I think the easiest path here is to incorporate the new upstream into a
>> port, unless someone is familiar with zlib and can cherrypick out the
>> commit(s) that resolve the issue. (I didn't find zlib in ports already.)
>
> That is completely impossible.  It must be in base.  There are 3 copies
> in base -- userland, kernel, and bootblocks.  They must be kept in sync.

Not saying to replace what's in base, but have a different version in
ports available for ports. I was thinking along the lines of egcc or
eopenssl in that the port co-exists with base and ports that need them
need tweaking to use them.

>
> It gets updated when things matter.  I wasn't aware a change had happened
> which matters.  The thread makes me unenthusiastic, because I cannot tell
> what changed that matters.  Updating it is not a trivial effort, because
> every bootblock needs testing.  I've done it twice...

I figured and want to be clear I am *not* volunteering for that
exercise! I don't see a change that matters for base.

-dv

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Dave Voutila]

Matt Dowle writes:

> Hi,
>
> Is it intentional or is there any good reason that OpenBSD 6.9 released May
> 2021 uses a 16 year old version of zlib (v1.2.3; July 2005)?  The latest
> version v1.2.11 (Jan 2017) is 4 years old.
>
> Background here: https://github.com/Rdatatable/data.table/pull/5049

Had a chat with Matt off-list and took a very terse look at zlib's
current status w.r.t. building just on amd64 -current.

I think the easiest path here is to incorporate the new upstream into a
port, unless someone is familiar with zlib and can cherrypick out the
commit(s) that resolve the issue. (I didn't find zlib in ports already.)

To be honest, the extend of my effort was:

1. clone zlib master branch from https://github.com/madler/zlib
2. try building with clang on amd64 -current...which fails.
3. try building with GCC 8.4 from ports...which "just works" (didn't
even need gmake).

To be clear: I didn't test if this actually fixed any issues.

Then any ports that need the newer zlib and can't use the one in base
can use the port.

For folks that maintain ports...does this sound feasible or am I
dreaming? (Assuming someone writes and maintains the port.)

-dv

Re: Machine age and OpenBSD - Thinkpad R51e

[Dave Voutila]

Thomas Vetere writes:

> Hello everyone,
>
> I was looking to get a laptop to run OpenBSD. The one I am looking at in
> particular is the Thinkpad R51e (2005). I like this particular model
> because it does not come with any extra hardware that OpenBSD does not
> support in the first place (bluetooth, camera, etc.) My main concern is the
> longevity that this model would have going forward. I already have a '94
> Thinkpad that cannot run the latest OpenBSD well because hardware support
> was gradually dropped during code cleanups, etc (i.e. newer versions of X11
> removed support for my ancient graphics chip because it just wasn't worth
> the time to maintain the code). Does anyone know, given the age of that
> model, how many years I might get out of it with OpenBSD and its packaged
> software before hardware support starts to drop? What is a good rule of
> thumb for selecting a machine to run OpenBSD with respect to its age?
>
> Thank you for your help!

I think that machine (R51e) is 32-bit only, so it doesn't have much
runway if you're looking to keep up with Xenocara/X11 changes. I'd
recommend looking for at least a slightly more recent Intel-based
machine that's 64-bit. I know the x230's are popular and fairly user
serviceable.

Re: use tablet interface under vm running linux / pressure on wacom

[Dave Voutila]

Rudolf Sykora  writes:

> I just want to check if, perhaps, there is something new about the
> possibility of the mentioned 'device passthrough' in vmd.

Nope. I recommend either finding a device that works as required with
OpenBSD or improving the existing driver to make your device work.

-dv

Re: Best practices mirroring large file-system hierarchies?

[Dave Voutila]

sackholelimit=32768
> net.inet.tcp.always_keepalive=0
> net.inet.tcp.synuselimit=10
> net.inet.tcp.rootonly=2049
> net.inet.tcp.synhashsize=293
> net.inet.udp.checksum=1
> net.inet.udp.baddynamic=7,9,13,18,19,22,37,39,49,53,67,68,69,70,80,88,105,107,109,110,111,123,129,135,137,138,139,143,161,162,163,164,177,178,179,191,194,199,201,202,204,206,210,213,220,372,389,427,444,445,464,468,500,512,513,514,517,518,520,525,533,546,547,548,554,587,623,631,636,646,664,706,749,750,751,853,993,995,1433,1434,1524,1525,1645,1646,1701,1723,1812,1813,1900,2049,2401,3031,3517,3689,3784,3785,4190,,4500,4559,4754,4755,4789,5002,5060,5298,5353,5354,5432,7000,7001,7002,7003,7004,7005,7006,7007,7008,7009,7784,8025,8067,9418,10050,10051,16992,16993,16994,16995,20005,26740
> net.inet.udp.recvspace=41600
> net.inet.udp.sendspace=9216
> net.inet.udp.rootonly=2049
> net.inet.gre.allow=0
> net.inet.gre.wccp=0
> net.inet.esp.enable=1
> net.inet.esp.udpencap=1
> net.inet.esp.udpencap_port=4500
> net.inet.ah.enable=1
> net.inet.etherip.allow=0
> net.inet.ipcomp.enable=0
> net.inet.carp.allow=1
> net.inet.carp.preempt=0
> net.inet.carp.log=2
> net.inet.divert.recvspace=65636
> net.inet.divert.sendspace=65636
> net.inet6.ip6.forwarding=0
> net.inet6.ip6.redirect=1
> net.inet6.ip6.hlim=64
> net.inet6.ip6.mrtproto=0
> net.inet6.ip6.maxfragpackets=200
> net.inet6.ip6.log_interval=5
> net.inet6.ip6.hdrnestlimit=10
> net.inet6.ip6.dad_count=1
> net.inet6.ip6.auto_flowlabel=1
> net.inet6.ip6.defmcasthlim=1
> net.inet6.ip6.use_deprecated=1
> net.inet6.ip6.maxfrags=200
> net.inet6.ip6.mforwarding=0
> net.inet6.ip6.multipath=0
> net.inet6.ip6.multicast_mtudisc=0
> net.inet6.ip6.neighborgcthresh=2048
> net.inet6.ip6.maxdynroutes=4096
> net.inet6.ip6.dad_pending=0
> net.inet6.ip6.mtudisctimeout=600
> net.inet6.icmp6.redirtimeout=600
> net.inet6.icmp6.nd6_delay=5
> net.inet6.icmp6.nd6_umaxtries=3
> net.inet6.icmp6.nd6_mmaxtries=3
> net.inet6.icmp6.errppslimit=100
> net.inet6.icmp6.nd6_maxnudhint=0
> net.inet6.icmp6.mtudisc_hiwat=1280
> net.inet6.icmp6.mtudisc_lowat=256
> net.inet6.icmp6.nd6_debug=0
> net.inet6.divert.recvspace=65636
> net.inet6.divert.sendspace=65636
> net.bpf.bufsize=32768
> net.bpf.maxbufsize=2097152
> net.mpls.ttl=255
> net.mpls.mapttl_ip=1
> net.mpls.mapttl_ip6=0
> net.pipex.enable=0
> hw.machine=amd64
> hw.model=AMD Opteron(TM) Processor 6276
> hw.ncpu=16
> hw.byteorder=1234
> hw.pagesize=4096
> hw.disknames=sd0:48d117fdb8bf80d1,sd1:59a3ee4ba41ddb29,sd2:36ab3ca77b9c2e6f,sd3:362548917ef7bfba,sd4:ceb3422dc4d34ab5,sd5:5bc682b7aa33d82f,sd6:da46565a96a9a13a,sd7:43b4ba0f34af8d17,sd8:168427c044825975
> hw.diskcount=9
> hw.sensors.sdtemp0.temp0=53.25 degC
> hw.sensors.sdtemp1.temp0=55.50 degC
> hw.sensors.sdtemp2.temp0=55.75 degC
> hw.sensors.sdtemp3.temp0=55.25 degC
> hw.sensors.sdtemp4.temp0=55.25 degC
> hw.sensors.sdtemp5.temp0=55.00 degC
> hw.sensors.sdtemp6.temp0=55.25 degC
> hw.sensors.sdtemp7.temp0=53.00 degC
> hw.sensors.nvt0.temp1=62.75 degC
> hw.sensors.nvt0.temp4=80.50 degC
> hw.sensors.nvt0.fan0=164 RPM
> hw.sensors.nvt0.fan1=767 RPM
> hw.sensors.nvt0.fan2=164 RPM
> hw.sensors.nvt0.fan3=453 RPM
> hw.sensors.nvt0.fan4=164 RPM
> hw.sensors.nvt0.fan5=164 RPM
> hw.sensors.nvt0.volt0=8.00 VDC
> hw.sensors.nvt0.volt2=7.28 VDC
> hw.sensors.nvt0.volt6=7.79 VDC
> hw.sensors.nvt0.volt7=6.28 VDC
> hw.sensors.nvt0.volt8=7.49 VDC
> hw.sensors.nvt0.volt9=6.30 VDC
> hw.sensors.nvt0.volt10=7.12 VDC
> hw.sensors.nvt0.volt11=7.63 VDC (VTT)
> hw.sensors.nvt0.volt12=3.46 VDC (3VDD)
> hw.sensors.nvt0.volt13=3.46 VDC (3VSB)
> hw.sensors.nvt0.volt14=4.19 VDC (VBat)
> hw.sensors.km0.temp0=42.38 degC
> hw.sensors.km1.temp0=42.00 degC
> hw.cpuspeed=2300
> hw.vendor=Supermicro
> hw.product=H8SGL
> hw.version=1234567890
> hw.serialno=1234567890
> hw.uuid=534d4349-0002-337a-c40c-337ac40cb061
> hw.physmem=68701257728
> hw.usermem=68701241344
> hw.ncpufound=16
> hw.allowpowerdown=1
> hw.smt=0
> hw.ncpuonline=8
> machdep.console_device=ttyC0
> machdep.bios.diskinfo.128=bootdev = 0xa204, cylinders = 1024,
> heads = 255, sectors = 63
> machdep.bios.diskinfo.129=bootdev = 0xa0020204, cylinders = 1024,
> heads = 255, sectors = 63
> machdep.bios.diskinfo.130=bootdev = 0xa0030204, cylinders = 1024,
> heads = 255, sectors = 63
> machdep.bios.diskinfo.131=bootdev = 0xa0040204, cylinders = 1024,
> heads = 255, sectors = 63
> machdep.bios.diskinfo.132=bootdev = 0xa0050204, cylinders = 1024,
> heads = 255, sectors = 63
> machdep.bios.diskinfo.133=bootdev = 0xa0060204, cylinders = 1024,
> heads = 255, sectors = 63
> machdep.bios.diskinfo.134=bootdev = 0xa0080204, cylinders = 1024,
> heads = 255, sectors = 63
> machdep.bios.diskinfo.135=bootdev = 0xa0070204, cylinders = 1024,
> heads = 255, sectors = 63
> machdep.bios.cksumlen=2
> machdep.allowaperture=0
> machdep.cpuvendor=AuthenticAMD
> machdep.cpuid=0x600f12
> machdep.cpufeature=0x179bfbff
> machdep.kbdreset=0
> machdep.xcrypt=0
> machdep.lidaction=1
> machdep.forceukbd=0
> machdep.tscfreq=236969
> machdep.invarianttsc=1
> machdep.pwraction=1
> ddb.radix=16
> ddb.max_width=80
> ddb.max_line=25
> ddb.tab_stop_width=8
> ddb.panic=1
> ddb.console=0
> ddb.log=1
> ddb.trigger=0
> vfs.mounts.ffs has 16 mounted instances
> vfs.mounts.mfs has 2 mounted instances
> vfs.ffs.max_softdeps=23704
> vfs.ffs.sd_tickdelay=2
> vfs.ffs.sd_worklist_push=0
> vfs.ffs.sd_blk_limit_push=0
> vfs.ffs.sd_ino_limit_push=0
> vfs.ffs.sd_blk_limit_hit=0
> vfs.ffs.sd_ino_limit_hit=0
> vfs.ffs.sd_sync_limit_hit=0
> vfs.ffs.sd_indir_blk_ptrs=1618
> vfs.ffs.sd_inode_bitmap=4201
> vfs.ffs.sd_direct_blk_ptrs=14680
> vfs.ffs.sd_dir_entry=8615
> vfs.ffs.dirhash_dirsize=2560
> vfs.ffs.dirhash_maxmem=5242880
> vfs.ffs.dirhash_mem=5184849
> vfs.nfs.iothreads=-1
> vfs.fuse.fusefs_open_devices=0
> vfs.fuse.fusefs_fbufs_in=0
> vfs.fuse.fusefs_fbufs_wait=0
> vfs.fuse.fusefs_pool_pages=0


--
-Dave Voutila

Re: pf questions

[Dave Anderson]

> On Jun 1, 2021, at 16:50, Stuart Henderson  wrote:
> 
> On 2021-05-30, Dave Anderson  wrote:
>> I’m setting up on 6.9-release a (for now) IPv4-only firewall with multiple 
>> public addresses and multiple subnets behind it, and have a couple of 
>> questions related to connections originating from the firewall itself to 
>> which I haven’t found definitive answers.
>> 
>> When not overridden (for example, by ‘ftp-proxy -a ’) which of the 
>> public addresses will be chosen as the source address for connections to the 
>> Internet originating on the firewall? It would make sense to me for the one 
>> address not declared as an alias to always be chosen, but I haven’t found 
>> anything that states this to be true. I want to (for example) keep traffic 
>> from systems I control separate from that from the WiFi subnet (which I’ll 
>> NAT to a different public address).
> 
> The interface address associated with the route used to reach the
> destination. See "if address" in "route -n get $IP".
> 
>> I plan to use tags to control policy, initially tagging each new connection 
>> based mostly (but not entirely) on which interface it arrives through. But, 
>> unless I’m missing something, connections originating on the firewall can’t 
>> be tagged this way since they don’t arrive through any interface. Which also 
>> seems to mean that all policy decisions must be made outbound, since that’s 
>> the only time that connections originating on the firewall will pass through 
>> an interface. And I haven’t found any way of filtering on untagged 
>> connections (something like ‘! tagged any’ would be nice). I’m sure that my 
>> setup isn’t unique, so there must be a good way of dealing with this, but 
>> I’ve no idea what it might be. Suggestions, please!
> 
> You might find "!received-on any" useful to allow a rule to match only
> locally originated connections. I guess you could do something like
> "match !received-on any tag local" if you want to attach a tag to those.

I should have noticed that; evidently I was too fixated on tags. Once I’ve 
identified the local connections I can NAT them to the address I want, so which 
source address is used by default doesn’t matter. Thanks!

pf questions

[Dave Anderson]

I’m setting up on 6.9-release a (for now) IPv4-only firewall with multiple 
public addresses and multiple subnets behind it, and have a couple of questions 
related to connections originating from the firewall itself to which I haven’t 
found definitive answers.

When not overridden (for example, by ‘ftp-proxy -a ’) which of the public 
addresses will be chosen as the source address for connections to the Internet 
originating on the firewall? It would make sense to me for the one address not 
declared as an alias to always be chosen, but I haven’t found anything that 
states this to be true. I want to (for example) keep traffic from systems I 
control separate from that from the WiFi subnet (which I’ll NAT to a different 
public address).

I plan to use tags to control policy, initially tagging each new connection 
based mostly (but not entirely) on which interface it arrives through. But, 
unless I’m missing something, connections originating on the firewall can’t be 
tagged this way since they don’t arrive through any interface. Which also seems 
to mean that all policy decisions must be made outbound, since that’s the only 
time that connections originating on the firewall will pass through an 
interface. And I haven’t found any way of filtering on untagged connections 
(something like ‘! tagged any’ would be nice). I’m sure that my setup isn’t 
unique, so there must be a good way of dealing with this, but I’ve no idea what 
it might be. Suggestions, please!

-- 
Dave Anderson
d...@daveanderson.com

Re: vmctl start: vm command failed: Operation already in progress (no one VM run in the same time)

[Dave Voutila]

Martin  writes:

> Try to start VM from previously (<6.9) working command as below:
>
> $ doas /usr/sbin/vmctl start -m 8G -c -n vmlan -d /path/to/vm.qcow2 vm
>
> Now I have trouble with it on 6.9amd64 with 1-5 patches installed.
>
> $ doas rcctl status vmd
> vmd(ok)
>
> command above returns:
> vmctl start: vm command failed: Operation already in progress

Common cause of this is having the vm already defined in vm.conf. Run
vmd with verbose logging, ideally in the foreground, and please share
the output.

>
> Even if "$ vmctl check" shows ALL machines are stopped
>
> if I stopped vmd I see proper error with non active vmd.sock
> $ doas rcctl stop vmd
> vmd(ok)
>
> vmctl: connect: /var/run/vmd.sock: connection refused
>

Re: VMM 6.9amd64 host video acceleration

[Dave Voutila]

Martin writes:

> Hi list,
>
> Just wonder how to enable video acceleration on VMM guest's side (Debian) if 
> it was possible. Maybe PCIe passthru should be present for that purpose?

There is nothing to accelerate: vmd(8) doesn't emulate a display or
video device. vmm(4) doesn't support pass-through to host hardware
either.

-dv

Re: Unable to boot 6.9 bsd.rd on 6.8 vmd host

[Dave Voutila]

Mischa writes:

> Hi All,
>
> I have a couple of machines running on 6.8 still, will upgrade soon. :)
> For some reason when I am trying to boot a 6.9 bsd.rd nothing is happening.

6.9 bsd.rd's for amd64 are gzip'd. For 6.9, vmd was taught how to boot
compressed kernels/ramdisks.

>
> It's only showing:
> Connected to /dev/ttypq (speed 115200)
>
> Nothing else appears.
> Booting from a 6.8 bsd.rd works normally.
>
> Equally booting from 6.9 bsd.rd on a 6.9 host works as expected as well.
>
> Something I can do to make this work?

gunzip the ramdisk and a 6.8 vmd instance should be able to boot it.

Once you have a guest updated and it's using seabios it will be booting
off the disk image and it shouldn't matter at that point.

-dv

Re: vmm error mesg since upgrade to 6.9

[Dave Voutila]

Dave Voutila writes:
>
> I've managed to reproduce it on my end using vmd(8) from 6.9 and a
> config similar to what you and Holger are using. I have a few hunches
> and looking into it.
>

An errata for 6.9 was released addressing the underlying issue. As this
is specific to vmd(8), this only affects users on amd64 using vmd(8).

See https://www.openbsd.org/errata69.html

Should be available via syspatch(8) now that it's had time to replicate
out to mirrors.

Thanks Holger and Mischa for reporting the issue and helping me
troubleshoot!

-dv

Re: vmm error mesg since upgrade to 6.9

[Dave Voutila]

Mischa Peters writes:

>> On 2 May 2021, at 14:25, Dave Voutila  wrote:
>>
>> 
>> Mischa writes:
>>
>>>
>>> Interestingly I am seeing the same on my 6.9 hosts, except the host running 
>>> -current.
>>
>> Hmm. -current has some small changes to virtio emulation, specifically
>> fixing some bad casts I found [1]. That might explain the difference
>> with -current.
>>
>>> The hosts are similar in regards to configuration.
>>> I have migrated from bridge/vether to veb/vport.
>>>
>>> May  2 13:14:38 r2 vmd[59033]: vionet_enq_rx: descriptor too small for 
>>> packet data
>>> May  2 13:15:12 r2 last message repeated 11 times
>>> May  2 13:17:13 r2 last message repeated 34 times
>>>
>>> # vmctl show | grep 59033
>>>   6 59033 14.0G1.8G   ttyp5 root  running images
>>>
>>> # vm.conf
>>> switch "uplink_vlan880" {
>>>interface veb880
>>> }
>>> vm "images" {
>>>memory 4G
>>>disk "/var/vmm/images.qcow2"
>>>disk "/var/vmm/images_extra.qcow2"
>>>interface tap { switch "uplink_vlan880" }
>>> }
>>>
>>> # cat /etc/hostname.em0
>>> up
>>> # cat /etc/hostname.veb880
>>> add vlan880
>>> add vport880
>>> up
>>> # cat /etc/hostname.vlan880
>>> vnetid 880 parent em0
>>> up
>>> # cat /etc/hostname.vport880
>>> inet 46.23.xx.xx 255.255.255.0
>>> inet6 2a03:6000:xxx::xx
>>> up
>>>
>>> I am using a combination of dhcp and static IP config on both hosts to 
>>> provision the VMs.
>>
>> Are you running dhcpd(8) on the host? Or using vmd(8)'s built-in dhcp
>> service?
>
> Only using dhcpd on the host.
>
>>> What else can be relevant?
>>
>> Logging into my obsd.ams host (that I haven't updated yet to 6.9) it's
>> using "dhcp" in /etc/hostname.vio0. Do you see this same issue with
>> *guests* running 6.8? Or only 6.9?
>
> The host running -current only has 6.8 VMs. The hosts where I see the 
> messages are 6.9 VMs on 6.9 hosts.
>
> Let me spin a 6.9 -release host and run a bunch of 6.8 VMs. And or a mix.
>

I've managed to reproduce it on my end using vmd(8) from 6.9 and a
config similar to what you and Holger are using. I have a few hunches
and looking into it.

-dv

Re: vmm error mesg since upgrade to 6.9

[Dave Voutila]

Mischa writes:

>
> Interestingly I am seeing the same on my 6.9 hosts, except the host running 
> -current.

Hmm. -current has some small changes to virtio emulation, specifically
fixing some bad casts I found [1]. That might explain the difference
with -current.

> The hosts are similar in regards to configuration.
> I have migrated from bridge/vether to veb/vport.
>
> May  2 13:14:38 r2 vmd[59033]: vionet_enq_rx: descriptor too small for packet 
> data
> May  2 13:15:12 r2 last message repeated 11 times
> May  2 13:17:13 r2 last message repeated 34 times
>
> # vmctl show | grep 59033
>6 59033 14.0G1.8G   ttyp5 root  running images
>
> # vm.conf
> switch "uplink_vlan880" {
> interface veb880
> }
> vm "images" {
> memory 4G
> disk "/var/vmm/images.qcow2"
> disk "/var/vmm/images_extra.qcow2"
> interface tap { switch "uplink_vlan880" }
> }
>
> # cat /etc/hostname.em0
> up
> # cat /etc/hostname.veb880
> add vlan880
> add vport880
> up
> # cat /etc/hostname.vlan880
> vnetid 880 parent em0
> up
> # cat /etc/hostname.vport880
> inet 46.23.xx.xx 255.255.255.0
> inet6 2a03:6000:xxx::xx
> up
>
> I am using a combination of dhcp and static IP config on both hosts to 
> provision the VMs.

Are you running dhcpd(8) on the host? Or using vmd(8)'s built-in dhcp
service?

>
> What else can be relevant?

Logging into my obsd.ams host (that I haven't updated yet to 6.9) it's
using "dhcp" in /etc/hostname.vio0. Do you see this same issue with
*guests* running 6.8? Or only 6.9?

-dv

[1] 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/vmd/virtio.c.diff?r1=1.84=1.85_with_tag=MAIN

Re: vmm error mesg since upgrade to 6.9

[Dave Voutila]

Holger Glaess writes:

> hi
>
>
> i did the upgrade von 6.8 to 6.9 .
>
>
> after reboot i get in my messages log
>
>
> vmd[56]: vionet_enq_rx: descriptor too small for packet data
>
>
> i run only one vm on my box, this is also upgraded to 6.9.
>
>
> how can i fix this ?
>
>

Can you share some more details? Does networking work? How do you start
this vm (what are the networking arguments)? Need more info to reproduce
what you're seeing.

There were minimal changes in the virtio emulation between 6.8 and
6.9. One of the few changes involved dhcp/bootp packet intercept, so I'm
curious what your guest is doing.

-dv

Re: X11 Freeze and Crash on Lenovo Thinkpad T14 AMD GEN1

[Dave Voutila]

niamkik writes:

> Hi,
>
> Just got the same issue, this time, my connection was still present. Here the 
> message from dmesg after going into single-user mode by killing init process.
>
> [drm] *ERROR* ring sdma0 timeout, signaled seq=30079, emitted seq=30079
> [drm] *ERROR* Process information: process pid 0 thread pid 0
>
> Xorg process was a zombie at this time. This behavior seems to be generated 
> when the screen is going blank, in my case, when xautolock is executed or 
> screensaver is set. My first crash was on 2nd April, just after using the 
> last current version at this time.

It seems a user with a T14s with similar hardware reported issues with
hibernate. [1] Does your system properly suspend/resume and
hibernate/resume?

I'm sadly no eXpert on X or drm...but if you're getting a segfault, it
might be helpful to get the core dump and see what the stack was via
gdb.

-Dave

[1] https://marc.info/?l=openbsd-bugs=161654860102192=2

Re: vmm page fault with VM upgraded from Ubuntu 18LTS to 20LTS

[Dave Voutila]

Noah writes:

> vmm crashes during boot after upgrading a VM from Ubuntu 18 to Ubuntu 20.
> Host is running 6.8 with all syspatches
>
> vmd -dvvv output provides a log entry of:
> vcpu_run_loop: vm 7 / vcpu 0 run ioctl failed: Bad address
>
> and this coincides with a kernel message:
> vmx_fault_page: uvm_fault returns 14, GPA=0xfe001818, rip=0xb98a31b4

It's a known issue. Newer Ubuntu kernels are built with an Intel PMC
driver that probes mmio registers on (IIRC) Intel Skylake and newer
systems. vmm(4) and vmd(8) do not support mmio like this at the moment.

There's no way to disable the probing as it's not a kernel module, so no
combination of linux boot args will help.

There are some hacky patches that would work if you were on -current,
but unless you want to stay on bleeding edge, it's probably a bigger
hastle than it's worth. This is in my backlog, however...I have a Kaby
Lake system impacted by this.

-Dave

Re: Keeping xlock on top in cwm

[Dave Voutila]

tetrahe...@danwin1210.me writes:

> On Tue, Mar 16, 2021 at 06:11:09PM +, tetrahe...@danwin1210.me wrote:
>> In cwm, is there a way to keep a particular window (in this case,
>> xclock) "always on top"?
>>
>>I don't see anything in the man page, but maybe I missed something:
>>https://man.openbsd.org/cwmrc
>
> I worked out how to set a "gap" so that maximized windows won't
> obscure the xclock line at the bottom. That helped. Unfortunately,
> it's not enough. By default `xconsole` is sized and positioned so, if
> brought forward, `xconsole` obscures `xclock`. That invariably happens
> if cycling through windows...

You can change or remove xconsole from starting by modifying
/etc/X11/xenodm/Xsetup_0

Re: vmm/vmd disk issue

[Dave Voutila]

Jan Johansson writes:

> Mike Larkin  wrote:
>> On Tue, Mar 09, 2021 at 09:38:57AM -0500, Ian Darwin wrote:
>> > On Tue, Mar 09, 2021 at 09:52:03AM +0100, Jan Johansson wrote:
>> > > If I try to cp or dd the disk image on the host it fails
>> > >
>> > > dd if=disk.raw.old of=disk.raw.bak bs=1m
>> > > dd: disk.raw.old: Input/output error
>> > > 8858+0 records in
>> > > 8858+0 records out
>> > > 9288286208 bytes transferred in 102.048 secs (91018010 bytes/sec)
>> > >
>> > > The host show no other signs of failing hardware.
>> > >
>> > > Is this a software or a hardware error?
>> >
>> > Given that it gives an error outside the VM, it's likely hardware.
>> >
>>
>> Agreed. Sorta hard to fault vmd(8) if it's not even running.
>
> Since these are sparse files, could the vioblk(4) somehow write
> incorrect data that later will make it unreadable such as a
> pointer pointing into nothingness?
>
> The messages
>
> vmd[39543]: vioblk write error: Input/output error
> vmd[39543]: wr vioblk: disk write error
>
> was produced and 01:30 when all the 4 guests and the host all run
> the daily script (which makes backup and other maintenance tasks)
> if that could have any impact.
>
> Should there not be anything on the host logging errors to
> dmesg/syslog such as sd(4) or ahci(4)?
>
> (If it is not obvious my understanding of how the virtio/vioblk
> stuff hooks in to the disk stack is very limited)
>

vmd(8) reads/writes to the disk image files (both raw and qcow2) using
pread(2)/pwrite(2) calls. The qcow2 handling is a bit more complex, but
they're still just calling pread/pwrite as far as I'm aware.

Have you run fsck(8) on your host?

> This drive was installed in august 2020 and if I recall correctly
> it was because of this issue. So I am thinkig cable or
> motherboard.
>
> If I decide to replace would it make sense to make this a
> softraid mirror (RAID1) to avoid or get better indication of this
> kind of problems in the future or would only add more parts that
> can break?
>
> I'am currently trying to provoke the drive from the host with
>
> dd if=/dev/random of=test.raw bs=1m count=17000
>
> then cp/dd and cmp to see if I can make it break for real.

I'd say maybe make sure you have backups of anything important first if
you're purposely going to break things. :-)

--
-Dave Voutila

Re: -current tmux not handling some terminal ID strings

[Dave Vandervies]

Somebody claiming to be Nicholas Marriott wrote:
> Does this fix it?

Yes, this fixes it.


Thanks,
dave

> 
> Index: tty-keys.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/tty-keys.c,v
> retrieving revision 1.140
> diff -u -p -r1.140 tty-keys.c
> --- tty-keys.c6 Jul 2020 07:27:39 -   1.140
> +++ tty-keys.c23 Aug 2020 20:22:28 -
> @@ -1192,7 +1192,10 @@ tty_keys_device_attributes(struct tty *t
>   if (tty->flags & TTY_HAVEDA)
>   return (-1);
>  
> - /* First three bytes are always \033[?. */
> + /*
> +  * First three bytes are always \033[>. Some older Terminal.app
> +  * versions respond as for DA (\033[?) so accept and ignore that.
> +  */
>   if (buf[0] != '\033')
>   return (-1);
>   if (len == 1)
> @@ -1201,7 +1204,7 @@ tty_keys_device_attributes(struct tty *t
>   return (-1);
>   if (len == 2)
>   return (1);
> - if (buf[2] != '>')
> + if (buf[2] != '>' && buf[2] != '?')
>   return (-1);
>   if (len == 3)
>   return (1);
> @@ -1218,6 +1221,10 @@ tty_keys_device_attributes(struct tty *t
>   return (-1);
>   tmp[i] = '\0';
>   *size = 4 + i;
> +
> + /* Ignore DA response. */
> +     if (buf[2] == '?')
> + return (0);
>  
>   /* Convert all arguments to numbers. */
>   cp = tmp;
> 
> 

-- 
Dave Vandervies
dj3va...@terse.ca

Plan your future!  Make God laugh!

Re: tmux occasionally crashing on attach

[Dave Vandervies]

Somebody claiming to be Nicholas Marriott wrote:
> Thanks. How about this instead?

This also fixes the problem.
No comments on style differences, it's not my bikeshed.


Thanks,
dave

> 
> Index: tty-term.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/tty-term.c,v
> retrieving revision 1.82
> diff -u -p -r1.82 tty-term.c
> --- tty-term.c5 Jun 2020 09:32:15 -   1.82
> +++ tty-term.c23 Aug 2020 20:14:19 -
> @@ -302,6 +302,8 @@ tty_term_strip(const char *s)
>   ptr++;
>   if (*ptr == '>')
>   ptr++;
> + if (*ptr == '\0')
> + break;
>   }
>  
>   buf[len++] = *ptr;
> 

-- 
Dave Vandervies
dj3va...@terse.ca

Plan your future!  Make God laugh!

-current tmux not handling some terminal ID strings

[Dave Vandervies]

In a remote session from an old MacOS terminal (MacOS 10.10.5, I
don't have anything newer to try with), when I start a tmux client,
the terminal sends (apparently in response to a query from tmux)
'[?1;2c', which is treated as input into whatever it connects
to.
On 6.7 I can work around this by running with TERM=vt100, but on
-current that workaround no longer works.


dave

-- 
Dave Vandervies
dj3va...@terse.ca

Plan your future!  Make God laugh!

tmux occasionally crashing on attach

[Dave Vandervies]

Since upgrading to 6.7 I've occasionally seen the tmux server crash
when a client connects to a session.
(I can't say for sure that it never happened pre-6.7, since it's
occasional and my usage patterns have drifted over time.)

Today it annoyed me enough to track it down, and it looks like a
loop index management bug in the terminal escape code handling;
there's a loop that scans through a string and discards some
substrings, and the body of the loop can leave the pointer pointing
at the '\0' byte that terminates the string.  When this happens,
the loop control advances the pointer again, past the terminator
byte, so it keeps examining whatever comes next.

Index: tty-term.c
===
RCS file: /cvs/src/usr.bin/tmux/tty-term.c,v
retrieving revision 1.76
diff -u -p -r1.76 tty-term.c
--- tty-term.c  23 Apr 2020 10:22:53 -  1.76
+++ tty-term.c  23 Aug 2020 00:05:09 -
@@ -295,7 +295,7 @@ tty_term_strip(const char *s)
}
 
buf[len++] = *ptr;
-   if (len == (sizeof buf) - 1)
+   if (len == (sizeof buf) - 1 || *ptr == '\0')
break;
}
buf[len] = '\0';

Re: Alpine-virt vmd guest tsc directive

[Dave Voutila]

On Mon, Jun 29, 2020 at 4:46 PM Martin  wrote:
>
> According to man vmctl for both: -current and 6.7 -b should be used for base 
> images. -b works just before kernel+vmm+vmctl -current update.

Re-read it. You're mixing the `vmctl start` and `vmctl create`
commands. They reuse options but the -b options have nothing to do
with each other and even with `vmctl start` it's a flag for a kernel
or custom bios...not an iso.

>
> Please check https://man.openbsd.org/vmctl.8
>
> Can it be a bug?
No.

-Dave

Re: Alpine-virt vmd guest tsc directive

[Dave Voutila]

On Mon, Jun 29, 2020 at 4:05 PM Martin  wrote:
> After build kernel+vmd+vmctl sources from -current I have an issue with 
> installing a system from *.iso images.
> The command below works fine before update, but not now
>
> $ doas vmctl start -m 1G -c -n vmlan -b /home/iso/install67.iso -d 
> /home/vmm/guest.qcow2 guest

I don't believe that syntax was ever correct for vmctl(8). Check your use of -b.

Re: Alpine-virt vmd guest tsc directive

[Dave Voutila]

On Mon, Jun 29, 2020 at 10:57 AM Martin  wrote:
>
> Hi Dave,
>
> Alpine kernel 5.4.43-1-virt guest openbsd 6.7 stable host. Try to compile vmd 
> from -current to improve linux guests stability.

Are you also running a -current kernel? vmm(4) is in the OpenBSD
kernel...vmd(8) is in base.

>
> set clocksource=tsc in /etc/update-extlinux.conf
> run update-extlinux to install boot loader.
>
> Next boot getting this in dmesg:
>
> ...
> [Frimware Bug]: TSC doesn't count with P0 frequency!
> tsc: Fast TSC calibration failed
> tsc: Unable to calibrate against PIT
> tsc: No referece (HPET/PMTIMER) available
> tsc: Marking TSC unstable due to could not calculate TSC khz
> ...

Honestly, chasing Linux tsc issues will waste your time. If you're
using a -current snapshot, build https://github.com/voutilad/vmm_clock
and load it as a Linux kernel module and give up chasing tsc
calibration issues for now unless you want to get intimately familiar
with the Linux kernel.

> Dave, I've never asked about qcow2 or raw disks in any of my previous email.

Apologies...saw another Martin (mar...@sukany.cz) reply to the same
subject and thought you were the same Martin :-)

-Dave

Re: Alpine-virt vmd guest tsc directive

[Dave Voutila]

On Mon, Jun 29, 2020 at 7:23 AM Martin  wrote:
>
> Hi list,
>
> I'm using Alpine-virt linux (headless linux with 40Mb initial *.iso size) 
> which has tsc issues. Alpine uses syslinux lightweight boot loader by 
> default. In order to enable tsc I've added tsc=reliable tsc=noirqtime to 
> /etc/update-extlinux.conf before console=ttyS0,115200 and updated it 
> accordingly.

You don't mention which Alpine and kernel version you're using. Also,
you don't mention which OpenBSD version...-current or 6.7? Some major
fixes just went into -current and look like they were in last night's
amd64 snapshots.

>
> It seems no changes in tsc usage prior to /dev/rtc0 as boot log shows:
> ...
> * Setting system clock using the hardware clock [UTC] ...hwclock: select() to 
> /dev/rtc0 to wait for clock tick timed out
> * Failed to set the system clock

/dev/rtc0 has nothing to do with the tsc or clocksource. This looks
like a separate issue and your guest isn't properly using the emulated
mc146818 device. I'm guessing there are bigger issues here.

> ...
>
> Does somebody know some way how set tsc as default clock source in Alpine 
> 5.4.43-1-virt guest?
>

Add the linux boot arg: clocksource=tsc

But in all honesty, if you want better Linux guest stability, you'll
need to use a -current snapshot.

Regarding your comment about disks in your other email...what you saw
with qcow2 vs raw probably has nothing to do with the emulated disks
and everything to do with the stability improvements now in -current.

-Dave

Re: OpenBSD alternatives to Pi-Hole

[Dave Voutila]

George writes:

> Hi guys,
>
> I am trying to setup a Pi-Hole service, i.e. add blocking based on
> empty DNS records zones files, for my local LAN and would like to ask
> what people are using on OpenBSD in this role?
>
> Thanks in advance,
>
> George

See unbound(8). I believe it's also used by the pi-hole distribution to
provide the caching dns resolver. There are numerous blog posts online
about how to configure unbound(8) for this, including on OpenBSD.

--
-Dave Voutila

Re: VMM Debian guest serial setup help needed

[Dave Voutila]

George writes:

> Hi guys,
>
> I apologize if this maybe out of topic even though it is truly related
> to VMM than Debian.
>
> I am trying to setup a VMM Debian based guest but I'm not able to get
> it to work. I found some description on the web about which settings
> to edit in grub.cfg to enable the serial console and created a VM with
> 10.3 in qcow2 disk format in KVM. Now I am trying to start the same on
> OpenBSD 6.7 but keep getting the connected message and then just
> "Rebooting " after I hit some keyboard keys seems like baud rate issue
> but not sure.

Not baudrate related, but there are some known issues in OpenBSD 6.7
related to the emulated uart device in vmd(8). (I have a patch if you
follow -current[1] that fixes stability issues.)

My advice is to install using vmm(4)/vmd(8) and not migrate an image
from KVM. I believe Debian started including the virtio cdrom drivers
finally...but, if not, google for some guides on adding those to the
iso.

Make sure you install OpenSSH and rely on ssh(1) connections to the guest.

As soon as you can, modify the grub defaults in /etc/default/grub and
set the GRUB_CMDLINE_LINUX_DEFAULT to include:

  tsc=reliable tsc=noirqtime console=ttyS0,115200

Make sure to run update-grub afterwards.

You'll probably have a bad time with your clock, though Debian use a 4.x
kernel, so it won't be too bad and may manage using tsc as a
clocksource. Otherwise expect refined-jiffies as the clocksource and it
may run at a rate of 50% of host time.

I recommend you also build and install my Linux clone of vmmci(4)[2]
within the Debian guest if you want safe guest shutdowns.

>
> After messing with it for a while now I am getting a new error:
>
> vmctl: could not open disk image(s)
>
> even thought the disk is there and readable to the user I have setup
> in vm.conf in fact I have another VM with the same configuration and
> disk with the same permissions and in the same location that works (it
> is OpenBSD based).

Use top(1) showing threads and command line args: top -C -g vmd

Chances are you have a lingering vmd(8) process for the Debian guest
using the disk. Kill -9 the one with the vm name.

>
> I would greatly appreciate it if someone has gone this path and can
> share some config info with me.
>
> Cheers and thanks in advance,
>
> George

[1] https://sisu.io/patches/vmd-thread-safety-07062020-v1.patch
[2] https://github.com/voutilad/virtio_vmmci

-Dave

Re: Running Windows inside vmm/vmd VM.

[Dave Voutila]

On Sat, Nov 23, 2019 at 12:18 AM Jordan Geoghegan  wrote:
>
> However the timekeeping situation for my Linux VMs is bleak. On both
> Void and Alpine, no clocks are even detected. In the dmesg it complains
> about the TSC clock source being unstable. Ultimately, we're left with
> only jiffies as a clock source option:

Anecdotally, I've found distros using Linux kernels in the 4.9-4.14
range do ok in letting you force tsc even if it says it's unstable.
Newer kernels often have a myriad of issues booting. (Might not be
kernel related so much as just all the other stuff that changes around
it.)

If you experience either slight, chronic drift or drift related to the
OpenBSD host suspending/resuming after long periods of time, I wrote a
Linux kernel driver that mimics OpenBSD's vmmci(4) that may help:
https://github.com/voutilad/virtio_vmmci

The driver listens for notifications from vmd about clock drift events
and use kernel api calls to adjust as needed, properly triggering
anything scheduled. An added nicety is it'll also listen for
shutdown/reboot events as well and try to cleanly reboot or halt the
system via whatever init system the Linux guest uses, meaning services
should have a chance to stop themselves.

-Dave

Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230

[Dave Trudgian]

On Tue, 2019-11-19 at 12:54 -0600, Dave Trudgian wrote:
> On Tue, 2019-11-19 at 19:06 +0100, Josh wrote:
> > Have you tried on 6.5?
> > 
> > My X1rev6 did not like the upgrade to 6.6. heavy cpu consumption,
> > super hot, laggy when browsing and fan spinning consistently.
> > 
> > I've reinstalled 6.5 and been using the same settings as yours.
> > everything is back to normal. I guess I will wait for 6.7...
> 
> I guess I should try this with relation to the other thread I posted
> about power draw on my T430. I'm not seeing heavy CPU or much lag -
> but
> it is unexpectly thirsty and the fan does go all the time. I'll try
> 6.5
> this evening if I get a chance.

Sorry for the noise decided to try quickly over lunch on my T430.

With 6.6 I was seeing a power draw of ~15W sitting at an idle GUI
session. Fan runs slowly, but constantly.

With 6.5 I see a power draw of ~10.5W sitting at an idle GUI session.
Fan does not run.

The 6.5 figure compares fairly well to ~8W on Linux with everything
powertop can tune there.

Going to stay at 6.5 for a while on this machine given the above... but
I have 2 drives in this laptop, so I can relatively easily try things
out on 6.6 if there are any pointers to try, or useful diagnostic
information I can obtain.

DT

Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230

[Dave Trudgian]

On Tue, 2019-11-19 at 19:06 +0100, Josh wrote:
> Have you tried on 6.5?
> 
> My X1rev6 did not like the upgrade to 6.6. heavy cpu consumption,
> super hot, laggy when browsing and fan spinning consistently.
> 
> I've reinstalled 6.5 and been using the same settings as yours.
> everything is back to normal. I guess I will wait for 6.7...

I guess I should try this with relation to the other thread I posted
about power draw on my T430. I'm not seeing heavy CPU or much lag - but
it is unexpectly thirsty and the fan does go all the time. I'll try 6.5
this evening if I get a chance.

Thanks,

DT

T430 power draw unexpectedly high

[Dave Trudgian]

Hello,

I've been using OpenBSD 6.6, and now latest snapshot, for a couple of
weeks on a Thinkpad T430. Performance and stability is fine and am very
much enjoying using this setup, but the battery life is unexpectedly
bad, vs what I'd expect having read around OpenBSD supporting c-states
and throttling.

Under OpenBSD with the system sitting idle at a GUI, WiFi active, 50%
brightness I see ~15W power draw from the battery. This is with `apmd
-A` and the output of `apm` showing that it is throttled to 1200MHz.
The CPU fan is running at a constant low speed.

Under Linux, I see an idle power draw sitting in the GUI, WiFi active,
50% brightness of ~8W. The CPU fan is mostly idle.

>From reading around I was expecting more in the range of 70-80% of the
Linux battery life, rather than ~50%. I understand several people may
be using T430 machines with OpenBSD. Would be grateful for any info
r.e. is this power draw typical, or any hints for other things I can
look into?

Many thanks,

Dave Trudgian

Re: What is you motivational to use OpenBSD

[Dave Anderson]

On Wed, 28 Aug 2019, Mohamed salah wrote:

>I wanna put something in discussion, what's your motivational to use
>OPENBSD what not other bsd's what not gnu/Linux, if something doesn't work
>fine on openbsd and you love this os so much what will do?

The emphasis on security and correctness.

-- 
Dave Anderson

Re: serial console images for installing on vmd based guests

[Dave Voutila]

On Wed, Mar 13, 2019 at 4:08 AM Claudio Jeker  wrote:
>
> On Tue, Mar 12, 2019 at 11:48:01PM -0700, Mike Larkin wrote:
> > On Tue, Mar 12, 2019 at 05:37:04PM -0700, Chris Cappuccio wrote:
> > > Is there any archive of serial console bootable images (w/virtio support)
> > > for Linux or other OSes to boot under vmd?
> > >
> >
> > You mean installer images? Like things you would install from? Tons.
> >
> > If you're talking about pre-installed full OSes, it's unlikely.
> >
>
> Debian still does not manage to ship an install media that has virtio
> support. While it is possible to install via serial console it fails to
> detect disks and net.

There's a nice guide to adding virtio to a Debian install image for
those that don't want to go the qemu route in bootstrapping a disk
image:
http://www.netzbasis.de/openbsd/vmd-debian/index.html

-Dave

Re: clocksource tsc sometimes not available within debian vm on OpenBSD 6.4

[Dave Voutila]

On Fri, Mar 8, 2019 at 1:55 PM Joe M  wrote:
>
> I have the same issue and have been using this driver. It sets the
> correct time every 5 seconds. For this purpose, this solution is a
> hack, but, I could not figure out a better solution.
>
> https://github.com/voutilad/virtio_vmmci/issues/1

As the author of the driver, let me clarify that the behavior now
mimics the native vmmci(4) behavior in that it only syncs the clock
when told to by the host system, which corresponds to the virtual
mc146818 detected its own clock drift (see vmd(8) source code). In
practice, this usually happens when the host system comes out of
suspension/hibernation.

The driver is not meant to resolve major issues like chronic clock
drift that even ntp can't fix.

>
> Also, I noticed that vm clock would be very slow. It loses 28 minutes
> for every 30 minutes.
>
> Another thing, watch out regarding tsc=unreliable kernel command line
> option, the vm is getting unresponsive with it after an hour or so.
>

-Dave

Re: A (partial) vmmci(4) Linux implementation

[Dave Voutila]

> On Feb 25, 2019, at 7:29 PM, Mike Larkin  wrote:
> 
> On Sun, Feb 24, 2019 at 12:21:24PM -0500, Dave Voutila wrote:
>> I've been experimenting with implementing something like vmmci(4) for
>> Linux guests. It's started to prove useful to myself so maybe others
>> will benefit, even though there are currently some caveats[1].
>> 
>>  https://github.com/voutilad/virtio_vmmci
>> 
>> My primary use case is keeping some Linux guests constantly running in
>> the background under the vmm(4) hypervisor on my laptop that sees quite
>> a few suspend (zzz)/resume cycles throughout my day.
>> 
>> It currently consists of 2 Linux kernel modules, one representing a
>> virtio_pci implementation handling the quirks[2] of how vmd(8) exposes
>> the vmm control device and the other module is the actual virtio driver
>> implementation.
>> 
>> I've tested it with a stock Ubuntu 18.0.4 install as well as with a
>> newer v4.20.12 tweaked Linux kernel[3] and so far seems to build and
>> work just fine using an OpenBSD snapshot from Monday 18 Feb as the host.
>> 
>> It doesn't yet catch shutdown or restart events, but that's my next goal
>> since I'd like to make sure I get clean shutdowns via `vmctl stop`.
>> 
>> -Dave
>> 
>> [1]: https://github.com/voutilad/virtio_vmmci#current-state--known-caveats
>> [2]: https://github.com/voutilad/virtio_vmmci#learnings-from-virtio-hacking
>> [3]: https://github.com/voutilad/linux
>> 
> 
> Looks like a good start!
> 
> For what it's worth, we should probably allocate a real virtio device number
> from Redhat or whoever controls that. I have an old email in my inbox with a
> few contact names, but I never got around to following up. That would fix the
> problem of the "stolen" virtio ID.
> 
> We chose to implement what looks like a PCI hostbridge but used a fake PCI
> VID/PID for this. The reason for doing it this way is that if you say you are
> a host bridge that is well-known, you have to implement all the bug-for-bug
> compatibility that comes with that.
> 
> I'll take a look at the register read/write thing, I'm not sure I entirely
> understand the issue you saw.
> 
> -ml

I'll try to avoid too much Linux detail since this is misc@openbsd,
but it seems to be a difference related to the underlying Linux virtio
pci functions used for reading based on if your device is picked up as
a "modern" or "legacy" device.:

- virtio_pci_modern[1]: uses a similar approach to how
  OpenBSD's virtio pci implementation works for reading config
  registers where there are different routines for reading different
  amounts of data.
- virtio_pci_legacy[2]: reads a byte using Linux's ioread8 from
  the given register address, then reads a byte from address+1,
  etc. until it reads up to the amount of data requested.

Given how vmd/virtio.c:vmmci_io [3] is implemented it expects a
read/write to specific register addresses, with logical gaps between
them based on the size of the data returned:

...
int
vmmci_io(int dir, uint16_t reg, uint32_t *data, uint8_t *intr,
void *unused, uint8_t sz)
{
*intr = 0xFF;

if (dir == 0) {
switch (reg) {
case VIRTIO_CONFIG_DEVICE_FEATURES:
case VIRTIO_CONFIG_QUEUE_SIZE:
case VIRTIO_CONFIG_ISR_STATUS:
log_warnx("%s: illegal write %x to %s",
__progname, *data, virtio_reg_name(reg));
break;
...

I had to change my driver to use the "modern" behavior even though
all OpenBSD virtio devices appear as "legacy" to the Linux virtio pci
framework. (So far writes using the legacy method are fine.)

I'm not convinced this warrants changes to vmd/virtio.c since this is
like fringe use case after fringe use case and all the other virtio
devices vmd(8) implements work. The VMM Control device is a bit of the
oddball because it's not using virtio queues to communicate and
instead relies on interrupts to notify the driver to go check the
config registers.

Which brings me to my last part: getting interrupts to work on my
driver. I figured it out this morning after ripping out MSI/MSI-X and
virtio queue stuff and have something working now and my driver picks
up the events listened for by vmmci(4). Shouldn't be too far now from
having a nice, clean shutdown or restart via `vmctl stop ubuntu`. Will
share when it’s ready if systemd doesn’t prematurely end my sanity
first.

-dv

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/virtio/virtio_pci_modern.c#n193
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/virtio/virtio_pci_legacy.c#n50
[3]: https://github.com/openbsd/src/blob/master/usr.sbin/vmd/virtio.c#L1667

A (partial) vmmci(4) Linux implementation

[Dave Voutila]

I've been experimenting with implementing something like vmmci(4) for
Linux guests. It's started to prove useful to myself so maybe others
will benefit, even though there are currently some caveats[1].

  https://github.com/voutilad/virtio_vmmci

My primary use case is keeping some Linux guests constantly running in
the background under the vmm(4) hypervisor on my laptop that sees quite
a few suspend (zzz)/resume cycles throughout my day.

It currently consists of 2 Linux kernel modules, one representing a
virtio_pci implementation handling the quirks[2] of how vmd(8) exposes
the vmm control device and the other module is the actual virtio driver
implementation.

I've tested it with a stock Ubuntu 18.0.4 install as well as with a
newer v4.20.12 tweaked Linux kernel[3] and so far seems to build and
work just fine using an OpenBSD snapshot from Monday 18 Feb as the host.

It doesn't yet catch shutdown or restart events, but that's my next goal
since I'd like to make sure I get clean shutdowns via `vmctl stop`.

-Dave

[1]: https://github.com/voutilad/virtio_vmmci#current-state--known-caveats
[2]: https://github.com/voutilad/virtio_vmmci#learnings-from-virtio-hacking
[3]: https://github.com/voutilad/linux

Re: Remiss on my personal and server security practices, offering server usage to outsiders

[Hoelzer, Dave]

There are people still serving server side Perl scripts?  That might be your 
problem right there.

On 9/19/18, 10:06 AM, "owner-m...@openbsd.org on behalf of Chris Bennett" 
 wrote:

 httpd should not have it's Perl scripts

Re: SGI O2 on 6.3 - Keyboard/Mouse issues

[Hoelzer, Dave]

That's interesting.  Within Irix, I've never seen or experienced a problem with 
the keyboard or the mouse.

>From what you are saying, it sounds as though the driver needs some reworking. 
> It seems as though the correct solution is to fix the driver rather than 
>install PCI cards, especially when the PCI real estate is so limited on these 
>systems.

I'll wait for more responses; if this is the issue, however, I think I'll just 
fix the driver and submit a pull request.

On 9/16/18, 6:32 AM, "Peter Kay"  wrote:

The keyboard issue on an O2 is supposedly because it uses the PS/2 command 
set 3 rather than the more widely used 2. Even in Irix the keyboard handling 
isn't perfect.

NetBSD is just as bad. I took the pragmatic approach of putting a keyboard 
faker on the PS/2 port and installing a USB PCI card, with a PS/2 to USB 
converter.

Xorg is pretty slow on the O2 as it's unaccelerated. NetBSD is a lot faster 
in X but their port is 32 bit.

SGI O2 on 6.3 - Keyboard/Mouse issues

[Hoelzer, Dave]

Good morning!

I’ve recently installed 6.3 onto an SGI o2..  Yes, the hardware is all working 
properly; it was running Irix very happily until immediately before I installed 
OpenBSD.

I’ve hunted around and can’t seem to find an explanation of these two issues:


  1.  The keyboard is wacky most of the time – whichever key you hit last, 
repeats.  So, if your username is “sam” and you type it fairly briskly and hit 
enter, you will successfully enter “sam”… and then the enter key will repeat 
until you tap some other key… If you hesitate after typing “sam”, the ‘m’ will 
repeat, etc.  Needless to say, this makes the console challenging to use.  
There was no evidence of this behavior during installation.
  2.  When starting X (startx), the mouse is unresponsive.  This lead me to 
dmesg, where I found this:  (I’ve trimmed irrelevant entries)


mkbc0 at macebus0 base 0x0032 irq 5

pckbd0 at mkbc0 (kbd slot)

wskbd0 at pckbd0: console keyboard

pms0 at mkbc0 (mouse slot)

wsmouse0 at pms0 mux 0

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

pms0: disable error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

pms0: disable error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

pms0: disable error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

pms0: disable error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

mkbc_poll_cmd: send error

pms0: disable error

This seems to explain why X doesn’t see the mouse, but gives me no insight into 
why the mouse is failing.  I did find one reference somewhere from around ’08 
that indicated a cold boot could assist with something to do with the PS2 
driver….  Cold booting makes no difference.

Any insights?

Re: Best Practices python virtualenv

[Dave Voutila]

Ken MacKenzie  writes:

> Is there a recommended best practice when setting up an environment with
> python
> virtualenv with regards to wxallowed.

AFAIK nothing official.

>
> My typical workflow is under my home directory I have a
> dev/language/project/.venv type structure. I guess the simple solution is to
> mount /home as wxallowed in /etc/fstab, but is that truly the preferred way.
> Seems to make a new attack surface for anything in home.
>

Turning off any default mitigations is probably the opposite of "preferred".

> The other option I am thinking is to create a dev-username location in
> /usr/local somewhere and then ln -s that into my home structure accordingly.
>
> Since I am new to OpenBSD I figured I would ask first and did not find much
> on
> this topic other than third parties that seem to want to casually just add
> home
> to wxallowed.
>

I've been too lazy to dig into and "fix" this in the py{2,3}-virtualenv
port. The main issue is it copies the binary for the target python
executable and doesn't symlink it. It's really not a bug and more an
adaptation issue so I've not been inclined.

However, symbolic links to /usr/local/bin/python work fine if they're
located on partitions that aren't mounted wxallowed. I'd imagine if
virtualenv created a symlink things would "just work."

So what I do, instead of teaching virtualenv to symlink instead of copy,
is just confine my virtualenvs to /usr/local/venv (owned by root:wsrc).

I then just activate via the usual means of the activate script:

  kogelvis$ . /usr/local/venv/my-project/bin/activate

Typically, on other systems, I'd locate it in ~/.venv but for my
personal machine it's not an issue.

I do set an environment variable:

  WORKON_HOME=/usr/local/venv

in .profile so I can configure tools like emacs major modes to point to
where I want them to create/find virtual environments.

> Thanks in advance for any guidance,
>
> Ken

Re: With the latest snapshot there are some issues in Xfce, please help!

[Dave Voutila]

Zsolt Kantor  writes:

> Hello to all.
> I installed the latest snapshot with Xfce. But there are some issues whit 
> Xfce. I found 3 problems.
>
> 1. The terminal size is very expanded, it is not 80x..., its 145x..., but if 
> I check the terminal properties the width setting is 80. Very strange.
>

The XFCE terminal? Might want to check ports@. No idea if this is an
upstream change or in the port itself.

> 2. There are some dependency problems when I try to install chromium
> or firefox. For instance the colord package can not be found in the
> snapshot packages repository, and other package dependency problems
> are also displayed. So I can't install Chromium or Firefox.

The snapshots are a moving target given the impending release of 6.3. 

Are you using `pkg_add -Dsnap firefox`? 

You might also need to grab the most recent build of -current if 
libraries were bumped. A dmesg would tell people if you're up to date
or not.

>
> 3. My synaptic touchpad is not fully functional. In Xfce the touchpad
> tab is missing from the mouse and touchpad configuration window. This
> is not the case of 6.2. In OpenBSD 6.2 it was there.
>

See note from 2017/12/05: https://www.openbsd.org/faq/current.html

You probably need a custom Xorg config, but if there is regression in
functionality I'm sure reporting the delta and a dmesg would be
helpful. Personally I've seen some improvements, but there were initial
regressions that were reported and I believe resolved or worked
around.

> Will these issues corrected until the release? Or should I send an e-mail to 
> the bug's mailing list?
>
> Thanks!

Re: vmd - Unable to reboot Alpine guest

[Dave Voutila]

"Aham Brahmasmi" <aham.brahma...@gmx.com> writes:

>> On Sun, Feb 18, 2018 at 04:23:39PM +0100, Aham Brahmasmi wrote:
>> > I am unable to reboot an Alpine Linux 3.7.0 guest.

I can confirm that on 6.2-current, you can reboot an Alpine 3.7.0 guest
without errors.

>> > 
>> > Tailing the /var/log/messages lists the following error messages:
>> > 
>> > /bsd: vmx_fault_page: uvm_fault returns 14, GPA=0xa148, rip=0xf7d8a
>> > vmd: vcpu_run_loop: vm 1 / vcpu 0 run ioctl failed: Bad address
>> > 

Here's what I see on 6.2-current when doing a `sudo reboot` inside the
Alpine VM via SSH very shortly after startup (timestamps trimmed for brevity):

kogelvis vmd[26727]: alpine: started vm 1 successfully, tty /dev/ttyp5
kogelvis vmd[93002]: vcpu_process_com_data: guest reading com1 when not ready
kogelvis last message repeated 2 times
kogelvis vmd[93002]: rtc_update_rega: set non-32KHz timebase not supported
kogelvis vmd[93002]: rtc_update_rega: set non-32KHz timebase not supported
kogelvis vmd[26727]: alpine: started vm 1 successfully, tty /dev/ttyp5
kogelvis vmd[49571]: vcpu_process_com_data: guest reading com1 when not ready
kogelvis last message repeated 2 times

> From what I understand, I first need to upgrade to the latest snapshot.
> From there, I need to use source build instructions at
> https://www.openbsd.org/faq/faq5.html#Bld to reach -current.

AFAIK, You shouldn't need to build anything from source, just do the upgrade
from a recent bsd.rd and then make sure to upgrade packages and clean
out old dependencies. Depending on how you've configured certain
software you might need to update some configs by hand, but you
shouldn't have to compile anything other than software you've had to
compile yourself to install under 6.1.

(Aham, sorry if my reply is a bit mangled...for some reason I can't get your
original post to reply to and had to grab your reply to Carlos.)

-Dave

Re: macpro boot openbsd 6.2 , but ,,,

[Dave Voutila]

Have you tried using rEFInd for dual or triple-booting?

http://www.rodsbooks.com/refind/index.html

I use it to dual-boot macOS and OpenBSD on multiple systems. The order
I follow during upgrades or installs:

1) Install or upgrade macOS first because it will overwrite rEFInd if present
2) Boot into macOS Recovery Mode and install rEFInd
3) Boot OpenBSD installation media using rEFInd and perform install or upgrade
4) Reboot and OpenBSD should be selectable in rEFInd (you can
customize to make it have an icon, etc. see rEFInd docs.)

That's basically it at a high level. I won't go into detail about disk
partitions because that's a thoroughly documented topic.

On Thu, Oct 19, 2017 at 10:16 AM, Tuyosi T  wrote:
> sorry correction
>
> (wrong)
> any way the previous openbsd is 6.1 .
> i use legacy PC and CD(install62.fs ) and install OpenBSD area .
> [ don’t touch msdos aea (wd0i)]
>
> (right)
> any way the previous openbsd is 6.1 .
> i use legacy PC and CD(install62.iso ) and install OpenBSD area .
> [ don’t touch msdos aea (wd0i)]
>
>
> and the interesting is the following
>
> http://blog.goo.ne.jp/kazuhirospd/e/a5cc783017c1ff2a699fce129fc72921
> says that
> 
> The screen got dark, and  SSD began to access .
> What began?
>  I was watching the display ...,
>  scared out of one's wits .
> It came out on the screen with a light blue Windows flag.
> It is the start screen of Windows 8.1.
> By the way, this SSD was what I used on the main PC until this time.
> i thought  it stopped with an error on the way .
> but   it  washed up as it was.
> Windows was running natively on MacPRO !
> MacOSX could not be installed with my all efforts.
> but MacPRO run  Windows 8.1  with no problem .
> what a sarcasm it was !
> ---
> but this is not the case for openbsd .
>
>
> and
> https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html
> says that
> --
> Intel Core 2 Duo and Xeon processors are 64-bit. However, based on reader
> reports received, as well as hands-on observation, it is believed that all
> Macs with 64-bit processors released in 2006 only have a 32-bit EFI, and
> consequently, only are capable of booting in 32-bit mode. This is of
> particular disappointment to owners of the first Mac Pro, which despite
> having a powerful 64-bit processor no doubt has had its "working life" cut
> short by a 32-bit EFI.
> -
>
>
> ---
> regards