Question regarding (kernel?) Priority and perl
Dear readers,
I have an openBSD just freshly updated to 7.3.
Amazing release, Thank you
I run ttyd on it, a tty over http small demon
and because i like log level i run a custom rc script
nothing fancy here :
daemon_user=support
rc_bg=YES
and in rc_start
su -fl -c ${daemon_class} -s /bin/sh ${daemon_user} -c "SHELL=/bin/ksh
${daemon} ${daemon_flags} 2>&1 | /usr/local/bin/ttyd.logger.pl"
Which i am updating with new pipe tools. (!| or |!) ;
ttyd.logger.pl is simple , read log put a level on it:
===
#!/usr/bin/perl
use Sys::Syslog qw(:standard :macros);
openlog("ttyd", "pid", "daemon");
while (my $l = <>) {
# [2020/10/20 09:58:39:7131] NOTICE:
$l =~ /\[[^]]+\]\s(\w+):/;
my $ll = $1 ? $1 : "info";
if ( $ll eq "ERR" ) {
$ll = "err";
} elsif ( $ll eq "WARN" ) {
$ll = "warning";
} elsif ( $ll eq "NOTICE") {
$ll = "info"; # ttyd is way to verbose
} elsif ( $ll eq "INFO") {
$ll = "info";
} elsif ( $ll eq "DEBUG") {
$ll = "debug";
} else {
$ll = "notice"; #notice unknown
}
syslog($ll, $l);
}
===
When looking at top, something surprise me ( this is the actual question ):
34172 support -60 4860K 8992K sleep/0 piperd0:00 0.78%
/usr/bin/perl /usr/local/bin//ttyd.logger.pl
*The priority is -6* (why , how)
First this is not nice ( ha ha ) and I am quite sure
this is completely controlled by the kernel.
# id support
uid=1001(support) gid=1001(support) groups=1001(support), 67(www)
How can a basic user get a -6 PRIO ? This feels very wrong.
I fear syslog in perl is doing something unexpected,
Please help and/or educate on this.
Re: Can't login after upgrading to 7.3
> On Apr 11, 2023, at 6:02 PM, Todd C. Miller wrote: > Sounds like you need to reboot into single user mode (-s at the > boot prompt) and change root's shell back to /bin/ksh ;-) That did it! I was able to change my root’s shell back to /bin/ksh (where it’s staying now.) I should be able to rebuild everything and get back to a solid state. Thanks all, you saved me from re-installing!
Re: Can't login after upgrading to 7.3
On Tue, 11 Apr 2023 17:55:52 -0600, Nathan Gilbert wrote: > I seem to stuck in a double bind, my wm needs to be recompiled, but also my s > hell (fish) is not in /etc/shells now and I can’t log in on the text console > either (I changed my root users shell to fish too.) > > I may have to chalk this up to a learning experience lol. Sounds like you need to reboot into single user mode (-s at the boot prompt) and change root's shell back to /bin/ksh ;-) - todd
Re: Can't login after upgrading to 7.3
> On Apr 11, 2023, at 5:54 PM, John Mettraux wrote > > I log in as root via the screen 1, 2, 3, or 4 (Ctrl-Alt-Fn-F1...) and edit > /etc/shells. > > Maybe you, for some reason, don't have access to your root account. I would > then just use an install stick and escape to shell when it asks if you want > to install, then mount the / disk partition and inspect/edit the shells file > from there, then unmount, remove the install stick and try again. > Thank you, I forgot you could access / using an install stick, I’ll give that a shot!
Re: Can't login after upgrading to 7.3
On Apr 11, 2023, at 5:49 PM, Lorenzo Torres wrote: > If I remember correcly LeftWM is written in Rust, the 7.3 update seems to > have broke some Rust binaries built for 7.2. You should probably try > re-compiling LeftWM using the updated rustc. Yes, it is written in rust. I’m just catching up on the other thread about that. I seem to stuck in a double bind, my wm needs to be recompiled, but also my shell (fish) is not in /etc/shells now and I can’t log in on the text console either (I changed my root users shell to fish too.) I may have to chalk this up to a learning experience lol. Thanks everyone for helping
Re: Can't login after upgrading to 7.3
On Tue, Apr 11, 2023 at 05:41:57PM -0600, Nathan Gilbert wrote: > > On Apr 11, 2023, at 5:40 PM, John Mettraux wrote: > > > > Could your account be using a shell not listed in /etc/shells ? > > > > I use fish and sometimes experience the same issue on upgrades. I solve it > > by > > re-adding /usr/local/bin/fish there. > > That’s probably it — I do use fish. How do you re-add it without logging in? I log in as root via the screen 1, 2, 3, or 4 (Ctrl-Alt-Fn-F1...) and edit /etc/shells. Maybe you, for some reason, don't have access to your root account. I would then just use an install stick and escape to shell when it asks if you want to install, then mount the / disk partition and inspect/edit the shells file from there, then unmount, remove the install stick and try again. Regards, John
Re: Can't login after upgrading to 7.3
On Tue, Apr 11, 2023 at 05:12:34PM -0600, Nathan Gilbert wrote:> Hi,> > I ran sysupgrade on a ThinkPad X1 Carbon running 7.2 and am unable to login afterwards. I’m unable to log in as my normal user in either the WM (LeftWM) or the terminal, I immediately get kicked back to login. I’m able to login with root to fvwm or cwm but can’t open a terminal. On the terminal, I get kicked back to login as well. This system reports that I am on 7.3 at boot.> > Is there any way to debug this issue? I’m at a loss.If I remember correcly LeftWM is written in Rust, the 7.3 update seems to have broke some Rust binaries built for 7.2. You should probably try re-compiling LeftWM using the updated rustc.Lorenzo Torres (https://sagittarius-a.org)
Re: Can't login after upgrading to 7.3
On Tue, Apr 11, 2023 at 05:12:34PM -0600, Nathan Gilbert wrote: > > I ran sysupgrade on a ThinkPad X1 Carbon running 7.2 and am unable to login > afterwards. I’m unable to log in as my normal user in either the WM > (LeftWM) or the terminal, I immediately get kicked back to login. I’m able > to login with root to fvwm or cwm but can’t open a terminal. On the > terminal, I get kicked back to login as well. This system reports that I am > on 7.3 at boot. Could your account be using a shell not listed in /etc/shells ? I use fish and sometimes experience the same issue on upgrades. I solve it by re-adding /usr/local/bin/fish there. Regards, John
Re: Can't login after upgrading to 7.3
On Tue, Apr 11, 2023 at 05:12:34PM -0600, Nathan Gilbert wrote: > Hi, > > I ran sysupgrade on a ThinkPad X1 Carbon running 7.2 and am unable to login > afterwards. I’m unable to log in as my normal user in either the WM (LeftWM) > or the terminal, I immediately get kicked back to login. I’m able to login > with root to fvwm or cwm but can’t open a terminal. On the terminal, I get > kicked back to login as well. This system reports that I am on 7.3 at boot. > > Is there any way to debug this issue? I’m at a loss. Going out on a limb here, but this sounds an awful lot like your window manager might error out and kick yo back to xenodm. I can't find LeftWM in the ports - is that a self-compiled window manager? Also can you specify what you mean by "the terminal". If you make it to the xenodm login manager, you should be able to switch to the text console with Ctrl+Alt+F1-F4. If that works, then you could log in there and examine ~/.xsession-errors after a failed xenodm login to see what error messages are produced. > > Thanks! >
groups update
0 C Slovenia P T Ljubljana F First Thursday of each month at 8:00PM O BSD users group Slovenia I Jan Prunk M janpr...@gmail.com U https://bsd.si N *BSD
Can't login after upgrading to 7.3
Hi, I ran sysupgrade on a ThinkPad X1 Carbon running 7.2 and am unable to login afterwards. I’m unable to log in as my normal user in either the WM (LeftWM) or the terminal, I immediately get kicked back to login. I’m able to login with root to fvwm or cwm but can’t open a terminal. On the terminal, I get kicked back to login as well. This system reports that I am on 7.3 at boot. Is there any way to debug this issue? I’m at a loss. Thanks!
groups new
0 C Slovenia P Ljubljana T Ljubljana F 1st Thursday, 8:00 PM O BSD users group Slovenia I Jan Prunk M janpr...@gmail.com U https://bsd.si N *BSD
groups new
0 C Slovenia P Ljubljana T Ljubljana F 1st Thursday, 8:00 PM O BSD users group Slovenia I Jan Prunk M janpr...@gmail.com U https://bsd.si N *BSD.
Re: IPv4 to IPv6 mapping
On Fri, 2023-04-07 at 10:30 +, Stuart Henderson wrote: > On 2023-04-04, Nicolas Goy wrote: > > > Looking at pf.conf(5) for syntax I just tried something fairly > obvious: > > pass in quick log proto tcp from any to $v4_address port 8383 af-to > inet6 from $dummy_v6_address to $listening_v6_address > Yeah, but as you said, you lose source address. I was trying to get the effect that the source address would be changed in a predictable way. For example, instead of dummy_v6_address, you give a /96 subnet, and the source ipv4 would be put in the last 32 bits. But af-to seems to be only able to do that with destination. -- Nicolas Goy Developer & Engineer https://kuon.ch https://goyman.com
simple measurement between 7.2 and 7.3
hi Just for fun i did between the upgrade from 7.2 to 7.3 a simple ipferf measurement to compare the speed diffrent. the machines are diffrent hardware see dmesg bellow. and i say "WOW" great job for you the OpenBSD Developer Team. THANK YOU. Holger on both machines i did: sysupgrade reboot fw_update pkg_add -ua reboot measure: measure path/config: iperf listen on vport100 on top of an veb device this include vlan100 this is coming from aggr0 . ( see config ) /etc 45>cat hostname.aggr0 mtu 1518 trunkport em2 trunkport em3 up /etc 46>cat hostname.vlan100 parent aggr0 vnetid 100 up /etc 47>cat hostname.veb100 add vlan100 add vport100 up /etc 48>cat hostname.vport100 group lan ( first machine ) inet 192.168.131.253 255.255.255.0 NONE ( second machine ) inet 192.168.131.252 255.255.255.0 NONE up First Machine : 7.2 RELEASE Patched x@acdc:~/Downloads$ iperf -c rod Client connecting to rod, TCP port 5001 TCP window size: 85.0 KByte (default) [ 1] local 192.168.131.110 port 58842 connected with 192.168.131.253 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.-10.0651 sec 416 MBytes 347 Mbits/sec 7.3 Release x@acdc:~/Downloads$ iperf -c rod Client connecting to rod, TCP port 5001 TCP window size: 85.0 KByte (default) [ 1] local 192.168.131.110 port 47782 connected with 192.168.131.253 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.-10.0765 sec 488 MBytes 406 Mbits/sec Second Machine: 7.2 Release + Patches xxx @acdc:~/Downloads$ iperf -c farin Client connecting to farin, TCP port 5001 TCP window size: 85.0 KByte (default) [ 1] local 192.168.131.110 port 36896 connected with 192.168.131.252 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.-10.0328 sec 971 MBytes 812 Mbits/sec 7.3 Release x@acdc:~/Downloads$ iperf -c farin Client connecting to farin, TCP port 5001 TCP window size: 85.0 KByte (default) [ 1] local 192.168.131.110 port 54030 connected with 192.168.131.252 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.-10.0214 sec 1.09 GBytes 935 Mbits/sec Hardware Info First Machine: /usr/local/ossec-hids 25>dmesg OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4262768640 (4065MB) avail mem = 4114173952 (3923MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f52 (53 entries) bios0: vendor American Megatrends Inc. version "5.6.5" date 02/06/2018 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP FPDT MCFG WDAT UEFI APIC BDAT HPET SSDT SPCR HEST BERT ERST EINJ acpi0: wakeup devices PS2K(S0) PS2M(S0) PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2400.04 MHz, 06-4d-08 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2400.11 MHz, 06-4d-08 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2400.15 MHz, 06-4d-08 cpu2:
lidaction on an M1 macbook
> o On arm64, add a machdep.lidaction sysctl(8) > for aplsmc(4) Apple Silicon laptops. Should that be mentioned in the arm64 examples/sysctl.conf as on other such architectures? Index: etc/etc.arm64/sysctl.conf === RCS file: /cvs/src/etc/etc.arm64/sysctl.conf,v retrieving revision 1.1 diff -u -p -r1.1 sysctl.conf --- etc.arm64/sysctl.conf 11 Jan 2017 22:57:34 - 1.1 +++ etc.arm64/sysctl.conf 11 Apr 2023 15:40:50 - @@ -0,0 +1 @@ +#machdep.lidaction=0 # 1=suspend, 2=hibernate laptop upon lid closing > aplsmc(4) provides support for the lid position sensor. Should that be mentioned in aplsmc(4)? Index: aplsmc.4 === RCS file: /cvs/src/share/man/man4/man4.arm64/aplsmc.4,v retrieving revision 1.2 diff -u -p -r1.2 aplsmc.4 --- aplsmc.410 Jan 2022 21:16:44 - 1.2 +++ aplsmc.411 Apr 2023 15:49:20 - @@ -28,7 +28,7 @@ The driver provides support for the System Management Controller (SMC) found on various Apple SoCs. The driver provides a collection of current, fan, power, temperature, -voltage and battery information sensors. +voltage, lid position and battery information sensors. .Pp Sensor values are made available through the .Xr sysctl 8 > > The arm64 default for the machdep.lidaction is 1, making the > > system suspend when the lid is closed. On this M1 macbook (dmesg below), I see no difference between lidaction=0 and lidaction=1; with both, closing and opening the lid does this: (lidaction=0) Apr 11 16:54:22 mb /bsd: uhub0 detached Apr 11 16:54:22 mb /bsd: uhub1 detached Apr 11 16:54:31 mb /bsd: wsdisplay_switch2: not switching Apr 11 16:54:31 mb /bsd: cpu0: 1 wakeup events Apr 11 16:54:31 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 16:54:31 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 16:54:31 mb /bsd: cpu7: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu4: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu6: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu5: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu1: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu3: 1 wakeup events Apr 11 16:54:31 mb /bsd: cp Apr 11 16:54:31 mb /bsd: u2: 1 wakeup events Apr 11 16:54:31 mb root: running /etc/apm/resume Apr 11 16:54:36 mb apmd: system resumed from sleep Apr 11 16:54:36 mb apmd: battery status: high. external power status: not connected. estimated battery life 99% (834 minutes life time estimate) (lidaction=1) Apr 11 17:05:12 mb /bsd: uhub0 detached Apr 11 17:05:12 mb /bsd: uhub1 detached Apr 11 17:05:20 mb /bsd: wsdisplay_switch2: not switching Apr 11 17:05:20 mb /bsd: cpu0: 1 wakeup events Apr 11 17:05:20 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 17:05:20 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 17:05:20 mb /bsd: cpu7: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu5: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu4: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu6: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu2: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu3: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu1: 1 wakeup events Apr 11 17:05:20 mb root: running /etc/apm/resume Apr 11 17:05:26 mb apmd: system resumed from sleep Apr 11 17:05:26 mb apmd: battery status: high. external power status: not connected. estimated battery life 98% (796 minutes life time estimate) So even with lidaction=0 it kind-of-suspends, and kind-of-resumes, running /etc/apm/resume. Is that expected? There also seems to be a difference between suspending with apm -z and suspending by closing the lid; namely, apm -z does call /etc/apm/suspend but the lid does not. Is that intended? (apm -z) Apr 11 16:55:30 mb apmd: system suspending ^^^ Apr 11 16:55:30 mb apmd: battery status: high. external power status: not connected. estimated battery life 99% (712 minutes life time estimate) Apr 11 16:55:30 mb root: running /etc/apm/suspend Apr 11 16:55:31 mb /bsd: uhub0 detached Apr 11 16:55:31 mb /bsd: uhub1 detached Apr 11 16:55:37 mb /bsd: wsdisplay_switch2: not switching Apr 11 16:55:37 mb /bsd: cpu0: 1 wakeup events Apr 11 16:55:37 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 16:55:37 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 16:55:37 mb /bsd: cpu7: 1 wakeup events Apr 11 16:55:37 mb /bsd: cpu4: 1 wakeup events Apr 11 16:55:37 mb /bsd: cpu5: 1 wakeup events Apr 11 16:55:37 mb /bsd: cpu6: 1 wakeup events Apr 11 16:55:37 mb /bsd: cpu2: 1 wakeup events Apr 11 16:55:37 mb /bsd: cp Apr 11 16:55:37 mb /bsd: u3: 1 wakeup events Apr 11
X11 not working after upgrade to 7.3
I've just upgraded a Windows 10 Hyper-V VM from 7.2 to 7.3 using sysupgrade, sysmerge (no changes) and pkg_add -u. Since the upgrade xenodm doesn't start. The error from Xorg.0.log is: [ 1599.318] (II) VESA(0): virtual address = 0xfe5219000, physical address = 0xf800, size = 4194304 [ 1599.666] (EE) Segmentation fault at address 0xfea707fd0 [ 1599.666] (EE) Fatal server error: [ 1599.666] (EE) Caught signal 11 (Segmentation fault). Server aborting For fun I ran ktrace, and I believe this is where it's failing: 55304 Xorg GIO fd 3 wrote 45 bytes "(II) VESA(0): VESA VBE OEM Software Rev: 0.0 " 55304 Xorg RET write 45/0x2d 55304 Xorg CALL kbind(0x705afca96bc8,24,0x930707b474004d54) 55304 Xorg RET kbind 0 55304 Xorg CALL kbind(0x705afca96b78,24,0x930707b474004d54) 55304 Xorg RET kbind 0 55304 Xorg CALL mmap(0,0x40,0x3,0x1,4,0x4000f800) 55304 Xorg RET mmap 4033631223808/0x3ab2728 55304 Xorg CALL kbind(0x705afca96b18,24,0x930707b474004d54) 55304 Xorg RET kbind 0 55304 Xorg CALL ioctl(4,MEMRANGE_SET,0x705afca96c00) 55304 Xorg RET ioctl -1 errno 22 Invalid argument 55304 Xorg CALL kbind(0x705afca96b18,24,0x930707b474004d54) 55304 Xorg RET kbind 0 55304 Xorg CALL kbind(0x705afca96b18,24,0x930707b474004d54) 55304 Xorg RET kbind 0 55304 Xorg CALL kbind(0x705afca96b18,24,0x930707b474004d54) 55304 Xorg RET kbind 0 55304 Xorg CALL write(2,0x705afca96330,0x32) 55304 Xorg GIO fd 2 wrote 50 bytes "mtrr set f800 40 failed: Invalid argument " 55304 Xorg RET write 50/0x32 The only thing really of note with this system is that it has Gnome installed (from packages) but I'm not using it. Is there anything new in 7.3 that I need to change? Thanks.
Re: OpenBSD 7.3 released
Thank you to all the developers for such a great release! Sysupgrade went
flawlessly on my cloud instances, router, and laptop host. Keep up the great
work!
On Mon, Apr 10, 2023, at 6:52 AM, Theo de Raadt wrote:
>
>
> - OpenBSD 7.3 RELEASED -
>
> April 10, 2023.
>
> We are pleased to announce the official release of OpenBSD 7.3.
> This is our 54th release. We remain proud of OpenBSD's record of more
> than twenty years with only two remote holes in the default install.
>
> As in our previous releases, 7.3 provides significant improvements,
> including new features, in nearly all areas of the system:
>
> - Various kernel improvements:
> o Added waitid(2), wait for process state change.
> o Added pinsyscall(2), specify the call stub for a specific system
> call.
> o Added getthrname(2) and setthrname(2), get or set thread name.
> o Added WTRAPPED option for waitid(2) to control whether CLD_TRAPPED
> state changes, i.e., ptrace(2) on a process, are reported.
> o Introduced clockintr(9), a machine-independent clock interrupt
> scheduler. Switched all architectures to use this new kernel
> subsystem.
> o Added a priority queue to clockintr(9).
> o Introduced a new kern.autoconf_serial sysctl(8) that can be used
> by userland to monitor state changes of the kernel device tree.
> o Fixed pmap(9) bugs involving entering an executable mapping for a
> page before synchronizing the data and instruction cache on arm64
> and riscv64.
> o Removed copystr(9) from public API.
> o Add getnsecruntime(9) to the kernel timecounting API. Together
> with getbinruntime(), it provides a fast, monotonic clock that
> only advances while the system is not suspended.
> o Add detection for Spectre-BHB Branch History Injection
> vulnerability related CLRBHB, ECBHB and CSV2_3/HCXT feature bits.
> o Prevent detaching ("bioctl -d detach") of a boot volume on a RAID
> managed by bioctl(8).
> o On arm64, avoid using 1GB mappings for the identity map in the
> early kernel bootstrap phase and when booting the secondary CPUs.
> This avoids accidentally mapping memory regions that should not be
> mapped (i.e. secure memory) as all mapped memory can be accessed
> speculatively.
> o Added arm64 detection of EPAN feature bit. Enhanced Privileged
> Access Never (EPAN) allows Privileged Access Never to be used with
> Execute-only mappings.
> o On arm64, add a machdep.lidaction sysctl(8) for aplsmc(4) Apple
> Silicon laptops.
> The arm64 default for the machdep.lidaction is 1, making the
> system suspend when the lid is closed. aplsmc(4) provides support
> for the lid position sensor.
> o Changed arm64 suspend idle loop from WFE to WFI, avoiding spurious
> wakeups while other CPUs are still active.
> o Added new dt(4) tracing ioctl DTIOCARGS to get the type of probe
> arguments.
>
> - SMP Improvements
> o Unlocked mmap(2), munmap(2), and mprotect(2).
> o Unlocked sched_yield(2).
> o Added support for per-cpu event counters, to be used for clock and
> IPI counters where the event counted occurs across all CPUs in the
> system.
> o Moved pf(4) purge tasks out from under the kernel lock.
> o Unlocked ioctl(2) SIOCGIFCONF, SIOCGIFGMEMB, SIOCGIFGATTR, and
> SIOCGIFGLIST.
> o Protected interface tables in pf(4) with PF_LOCK(), allowing
> removal of NET_LOCK() protection from the ioctl(2) code path in
> pf.
> o Unlocked getsockopt(2) and setsockopt(2).
> o Completed removing kernel lock from IPv6 read ioctls.
> o Unlocked minherit(2).
> o Made tun(4) and tap(4) event filters MP-safe.
> o Unlocked utrace(2).
> o Stopped holding the vm_map lock while flushing pages in msync(2)
> and madvise(2). Prevents a 3-thread deadlock between msync(2),
> page-fault and mmap(2).
> o Unlocked select(2), pselect(2), poll(2), and ppoll(2).
>
> - Direct Rendering Manager and graphics drivers
> o Updated drm(4) to Linux 6.1.15
> o amdgpu(4): Added support for Ryzen 7000 "Raphael", Ryzen 7020
> series "Mendocino", Ryzen 7045 series "Dragon Range", Radeon RX
> 7900 XT/XTX "Navi 31", Radeon RX 7600M (XT), 7700S, and 7600S
> "Navi 33."
> o Fixed frame buffer corruption and additional bugs after wakeup on
> Apple Silicon laptops and the Lenovo x13s.
> o Added support for the backlight connector property to amdgpu(4) as
> in inteldrm(4), making xbacklight(1) work when using the Xorg
> modesetting driver.
>
> - VMM/VMD improvements
> o Updated vmm(4) to allow guests to read MSR_HWCR and MSR_PSTATEDEF,
> which is necessary to determine the TSC frequency on AMD families
> 17h and 19h.
> o
Re: Setuid changed on /sbin/ping after installing patch 022_resolv
the man page says: o Check for changes in setuid/setgid files and devices. Those setuid binaries did change. They were replaced. The sizes are different also. That's because there is a libc.a change and these are static binaries. the security script is not not just reporting whether setuid bits are being turned on or off. tetrahe...@danwin1210.de wrote: > Hi all, > security(8) sent me an alert that Setuid changed on /sbin/ping and > /sbin/ping6: > > Running security(8): > > Setuid changes: > -r-sr-xr-x 2 root bin 347728 Sep 27 17:40:01 2022 /sbin/ping > -r-sr-xr-x 1 root bin 347776 Mar 11 19:42:17 2023 /sbin/ping > -r-sr-xr-x 2 root bin 347728 Sep 27 17:40:01 2022 /sbin/ping6 > -r-sr-xr-x 1 root bin 347776 Mar 11 19:42:17 2023 /sbin/ping6 > > > This happened after I installed syspatch 022_resolv (and made no other > changes to the system). > > I checked the source code of the 022_resolv patch and I don't see > anything that would affect the /sbin/ping binary. > > Did I miss something? Or is this setuid change potentially indicative of > a bigger problem? >
Setuid changed on /sbin/ping after installing patch 022_resolv
Hi all, security(8) sent me an alert that Setuid changed on /sbin/ping and /sbin/ping6: Running security(8): Setuid changes: -r-sr-xr-x 2 root bin 347728 Sep 27 17:40:01 2022 /sbin/ping -r-sr-xr-x 1 root bin 347776 Mar 11 19:42:17 2023 /sbin/ping -r-sr-xr-x 2 root bin 347728 Sep 27 17:40:01 2022 /sbin/ping6 -r-sr-xr-x 1 root bin 347776 Mar 11 19:42:17 2023 /sbin/ping6 This happened after I installed syspatch 022_resolv (and made no other changes to the system). I checked the source code of the 022_resolv patch and I don't see anything that would affect the /sbin/ping binary. Did I miss something? Or is this setuid change potentially indicative of a bigger problem?
Re: dns priority from different network connections - or disabling?
Kaya Saman wrote: > This somehow is overriding my resolv.conf file; another words the > information is *not* being used from resolv.conf and is instead being > used from the ipcp negotiation as part of the pppoe kernel module. then the pppoe code should submit a RTM_PROPOSAL route message ...
Re: fido2 hardware key with PIN in browsers
Greg Steuck wrote: > rsyk...@disroot.org writes: > > > Fabio Martins wrote: > >> About your question, I believe you need to do a tail -f /var/log/messages > > > > this is what I see after pluging the key in the computer: > > > > Apr 7 19:02:06 odin /bsd: uhidev1 at uhub0 port 1 configuration 1 > > interface 1 "GoTrust Idem Key" rev 2.00/1.11 addr 2 > > Apr 7 19:02:06 odin /bsd: uhidev1: iclass 3/0 > > Apr 7 19:02:06 odin /bsd: fido0 at uhidev1: input=64, output=64, feature=0 > > Apr 7 19:02:06 odin /bsd: uhidev2 at uhub0 port 1 configuration 1 > > interface 2 "GoTrust Idem Key" rev 2.00/1.11 addr 2 > > Apr 7 19:02:06 odin /bsd: uhidev2: iclass 3/1 > > Apr 7 19:02:06 odin /bsd: ukbd0 at uhidev2: 8 variable keys, 6 key codes > > Apr 7 19:02:06 odin /bsd: wskbd1 at ukbd0 mux 1 > > Apr 7 19:02:06 odin /bsd: wskbd1: connecting to wsdisplay0 > > Apr 7 19:02:06 odin /bsd: ugen0 at uhub0 port 1 configuration 1 "GoTrust > > Idem Key" rev 2.00/1.11 addr 2 > > This is a good start of debugging effort. We can tell that the kernel is > happy enough with your device. Now you can go one step further and see > if ssh can use it. > > If you are feeling ambitious about debugging this for chrome, try > running it with --enable-logging --v=1 and then look into > ~/.config/chromium/chrome_debug.log for anything matching "fido". > > You can then do the same on Linux and compare the outputs. > > How much do you care about having this extra pin protection? I have been > using a few older FIDO devices for years now, so we know this much > works. After upgrading to OpenBSD to 7.3 today, the operation started to work in chrome, so the key seems to be useable for me now. (I only encountered a minor difficulty to actually start chrome. It did not start the first time due to some trap, nor the second time, but then it finally started. This behaviour is daunting, but, in the end, the process succeeded.) I do not know why the use of the key did not work before the upgrade, but anyhow. Regarding the question about the PIN: To the extent I understand the PIN is a requirement by the security level to be used. I use the key to communicate with the state (public administration). There the condition is given that the PIN is to be used. Best regards, Ruda
Re: All my Rust programs stop working on OpenBSD 7.3
Oh shoot! Sorry I misunderstood the solution. I got rust-ring package installed and tried Laurie’s recipe. Now all errors are gone. Thanks a lot! > On Apr 11, 2023, at 17:06, Theo Buehler wrote: > > On Tue, Apr 11, 2023 at 04:43:04PM +0800, Siegfried Levin wrote: >> I checked the core dump again. There is still an error on Ring 0.16.20. > > Yes, that's expected. If you read my mail again, I told you to use the > patched source in /usr/local/share/ring-0.16.20 from the rust-ring > package, not simply ring 0.16.20. Once again: if Cargo.toml contains > > [dependencies] > ... > ring = "^0.16" > ... > > or similar, remove the ring line from [dependencies] and add a new section > > [dependencies.ring] > version = "^0.16" > path = "/usr/local/share/ring-0.16.20" > > Or you can follow Laurie Tratt's recpie. > >> Where can I know more about the protection introduced in 7.3 in case that I >> need to report this on GitHub? Thanks. > > I don't think it's going to be useful to report this on github. I will > try to upstream the patches when I will find time to do so. It's a bit > of a tricky patchset since ring uses assembly from BoringSSL and targets > various platforms I don't have easy access to, so I can't upstream the > patches as they currently are in the port. > >> Reading symbols from /usr/libexec/ld.so...Error while reading shared library >> symbols: >> Dwarf Error: wrong version in compilation unit header (is 4, should be 2) >> [in module /usr/libexec/ld.so] >> #0 GFp_sha512_block_data_order_avx () at >> /mnt/warehouse/home/git/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/sha512-x86_64-elf.S:1881 >> 1881 vpaddq -128(%rbp),%xmm0,%xmm8 > > Yes, as expected. > >> >>> On Apr 11, 2023, at 02:54, Theo Buehler wrote: >>> >>> Thanks. Actually that’s what I did. Rust package was updated by “pkg_add -u rust” and then “cargo build —release” rebuilds the projects. However, when I ran it, it crashed because of segment fault. It no longer passes the tests as well, “invalid memory reference” was returned. >>> >>> Without seeing a backtrace it is difficult to tell. >>> >>> Another issue could be that you use things depending on the ring crate >>> whose assembly isn't compatible with the new x-only protection on modern >>> amd64 machines. >>> >>> If so, you will need to >>> >>> # pkg_add rust-ring >>> >>> and replace lines like this >>> >>> ring = "^0.16" >>> >>> with something like this in Cargo.toml: >>> >>> [dependencies.ring] >>> version = "^0.16" >>> path = "/usr/local/share/ring-0.16.20"
Re: All my Rust programs stop working on OpenBSD 7.3
On Tue, Apr 11, 2023 at 04:43:04PM +0800, Siegfried Levin wrote: > I checked the core dump again. There is still an error on Ring 0.16.20. Yes, that's expected. If you read my mail again, I told you to use the patched source in /usr/local/share/ring-0.16.20 from the rust-ring package, not simply ring 0.16.20. Once again: if Cargo.toml contains [dependencies] ... ring = "^0.16" ... or similar, remove the ring line from [dependencies] and add a new section [dependencies.ring] version = "^0.16" path = "/usr/local/share/ring-0.16.20" Or you can follow Laurie Tratt's recpie. > Where can I know more about the protection introduced in 7.3 in case that I > need to report this on GitHub? Thanks. I don't think it's going to be useful to report this on github. I will try to upstream the patches when I will find time to do so. It's a bit of a tricky patchset since ring uses assembly from BoringSSL and targets various platforms I don't have easy access to, so I can't upstream the patches as they currently are in the port. > Reading symbols from /usr/libexec/ld.so...Error while reading shared library > symbols: > Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in > module /usr/libexec/ld.so] > #0 GFp_sha512_block_data_order_avx () at > /mnt/warehouse/home/git/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/sha512-x86_64-elf.S:1881 > 1881 vpaddq -128(%rbp),%xmm0,%xmm8 Yes, as expected. > > > On Apr 11, 2023, at 02:54, Theo Buehler wrote: > > > > > >> > >> Thanks. Actually that’s what I did. Rust package was updated by > >> “pkg_add -u rust” and then “cargo build —release” rebuilds the > >> projects. However, when I ran it, it crashed because of segment fault. > >> It no longer passes the tests as well, “invalid memory reference” was > >> returned. > > > > Without seeing a backtrace it is difficult to tell. > > > > Another issue could be that you use things depending on the ring crate > > whose assembly isn't compatible with the new x-only protection on modern > > amd64 machines. > > > > If so, you will need to > > > > # pkg_add rust-ring > > > > and replace lines like this > > > > ring = "^0.16" > > > > with something like this in Cargo.toml: > > > > [dependencies.ring] > > version = "^0.16" > > path = "/usr/local/share/ring-0.16.20"
Re: dns priority from different network connections - or disabling?
Thanks Stu, and everyone else who responded :-)
On 4/11/23 09:01, Stuart Henderson wrote:
On 2023-04-10, Kaya Saman wrote:
On 4/10/23 16:24, Daniele B. wrote:
Apr 10, 2023 12:52:22 Kaya Saman :
how do I override OpenBSD's
behavior to explicitly not use the dns servers obtained through ipcp but
instead use the ones form the resolv.conf file?
My solution both for security reasons (I'm using unbound)
for for practical reasons (as per your concerns) is to set immutable
resolv.conf by chflags.
Not the Solution but a very good workaround. Please investigate also
when you can take off the immutable flag too.
I take this time to wish you all an Happy Easter and obviously
lots of compliments for the 54th release of the ball fish system!
Do you mean setting resolv.conf as ReadOnly?
immutable is different, see chflags(1) schg. Used to be popular with
FreeBSD users to make it harder to change the kernel. Can only be
reset if sysctl kern.securelevel is at a low level (usually by booting
single user). I wouldn't recommend it here.
Oh ok... I'll check it out - I understood file permissions?
My resolv.conf file is fine and has the correct dns servers inside.
The issue is that pppoe negotiates the dns servers through ipcp. The dns
servers therefor do *not* get loaded into the resolv.conf file but
instead show up under: ifconfig pppoe0
This somehow is overriding my resolv.conf file; another words the
information is *not* being used from resolv.conf and is instead being
used from the ipcp negotiation as part of the pppoe kernel module.
The question is how to disable this behavior?
If resolvd is running (on by default) and unwind is running (off by
default), resolv.conf will point to 127.0.0.1 for unwind (with some
commented-out entries for other learned nameservers), and unwind
will normally learn forwarders from various sources including a pppoe
connection.
If resolvd is running and unwind is not running, resolvd will rewrite
resolvd.conf while it's running to include nameservers learnt from
pppoe etc.
The only place most of the rest of the system looks for resolvers
is in resolv.conf so what you describe ("rssolv.conf is fine") seems
unlikely. Double check what's actually in resolv.conf while pppoe is
connected?
To override learned nameservers, it depends whether you want to run
unwind on the system (used for resolution on localhost only) - if so,
use unwind.conf to set specific forwarders. If not, disable resolvd.
Check resolvd and unwind manpages for more info about what each does.
Perhaps I wasn't clear and confused everyone?
In the meantime I read both manpages of resolv.conf and unwind.
As far as I can understand unwind points to a remote resolver unless
something goes wrong where it then looks for one defined locally.
In my resolv.conf I have 3x local dns servers (same subnet I know I
know) defined:
x.x.x.1
x.x.x.2
x.x.x.3
*but* my system was using:
A.A.A.1
A.A.A.2
from my ISP which it acquired through ipcp from pppoe.
Possibly this behavior started while I messed with things and performed
a: sh /etc/netstart pppoe0
Nothing got written to resolv.conf but the system was using the isp
acquired servers.
I ran a quick test of unwind and popped: x.x.x.1 into it. Nothing seemed
to have changed as the resolution was still being carried out on the isp
dns machines.
Re-checking resolv.conf it seemed that the isp entries had actually been
written there in the end? Does unwind do this?
I just simply deleted them and now the system works as before using my
locally defined systems.
Strange issue and behavior but solved for now. Just reconfirmed using
nslookup right now on the obsd box and all is fine :-D
Many thanks.
Kaya
Re: All my Rust programs stop working on OpenBSD 7.3
I checked the core dump again. There is still an error on Ring 0.16.20. Where can I know more about the protection introduced in 7.3 in case that I need to report this on GitHub? Thanks. Reading symbols from /usr/libexec/ld.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] #0 GFp_sha512_block_data_order_avx () at /mnt/warehouse/home/git/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/sha512-x86_64-elf.S:1881 1881vpaddq -128(%rbp),%xmm0,%xmm8 > On Apr 11, 2023, at 02:54, Theo Buehler wrote: > > >> >> Thanks. Actually that’s what I did. Rust package was updated by >> “pkg_add -u rust” and then “cargo build —release” rebuilds the >> projects. However, when I ran it, it crashed because of segment fault. >> It no longer passes the tests as well, “invalid memory reference” was >> returned. > > Without seeing a backtrace it is difficult to tell. > > Another issue could be that you use things depending on the ring crate > whose assembly isn't compatible with the new x-only protection on modern > amd64 machines. > > If so, you will need to > > # pkg_add rust-ring > > and replace lines like this > > ring = "^0.16" > > with something like this in Cargo.toml: > > [dependencies.ring] > version = "^0.16" > path = "/usr/local/share/ring-0.16.20"
Re: All my Rust programs stop working on OpenBSD 7.3
On Mon, Apr 10, 2023 at 08:53:55PM +0200, Theo Buehler wrote:
Hello Theo,
> with something like this in Cargo.toml:
>
> [dependencies.ring]
> version = "^0.16"
> path = "/usr/local/share/ring-0.16.20"
In case it's useful to anyone else, one can set this globally in
~/.cargo/config.toml (and avoid tweaking multiple Cargo.toml's, which can be
a pain with dependencies) with:
[patch.crates-io]
ring = { path = "/usr/local/share/ring-0.16.20" }
However, there is one gotcha: this will cause your Cargo.lock to be altered,
so if you're working on a project with a checked-in Cargo.lock, you need to
be careful.
Laurie
Re: All my Rust programs stop working on OpenBSD 7.3
On 2023-04-10, Siegfried Levin wrote: > I fixed Cargo by “pkg_add -u rust” Ignoring the rust-specific bits which tb@ and semarie@ have commented on, you should always run straight "pkg_add -u" after an update - rust or not. OpenBSD does not give much consideration for compatibility with old binaries and it is very common that old binaries will not run on a new OpenBSD version. (On a related note, for software written in Go, as well as recompiling, it maybe necessary to update your projects to use a newer version of the golang.org/x/sys module, and if it uses some functions of modernc.org modules there's no solution yet).
Re: dns priority from different network connections - or disabling?
On 2023-04-10, Kaya Saman wrote:
>
> On 4/10/23 16:24, Daniele B. wrote:
>> Apr 10, 2023 12:52:22 Kaya Saman :
>>
> how do I override OpenBSD's
> behavior to explicitly not use the dns servers obtained through ipcp but
> instead use the ones form the resolv.conf file?
>> My solution both for security reasons (I'm using unbound)
>> for for practical reasons (as per your concerns) is to set immutable
>> resolv.conf by chflags.
>>
>> Not the Solution but a very good workaround. Please investigate also
>> when you can take off the immutable flag too.
>>
>> I take this time to wish you all an Happy Easter and obviously
>> lots of compliments for the 54th release of the ball fish system!
>>
>
> Do you mean setting resolv.conf as ReadOnly?
immutable is different, see chflags(1) schg. Used to be popular with
FreeBSD users to make it harder to change the kernel. Can only be
reset if sysctl kern.securelevel is at a low level (usually by booting
single user). I wouldn't recommend it here.
> My resolv.conf file is fine and has the correct dns servers inside.
>
> The issue is that pppoe negotiates the dns servers through ipcp. The dns
> servers therefor do *not* get loaded into the resolv.conf file but
> instead show up under: ifconfig pppoe0
>
> This somehow is overriding my resolv.conf file; another words the
> information is *not* being used from resolv.conf and is instead being
> used from the ipcp negotiation as part of the pppoe kernel module.
>
> The question is how to disable this behavior?
If resolvd is running (on by default) and unwind is running (off by
default), resolv.conf will point to 127.0.0.1 for unwind (with some
commented-out entries for other learned nameservers), and unwind
will normally learn forwarders from various sources including a pppoe
connection.
If resolvd is running and unwind is not running, resolvd will rewrite
resolvd.conf while it's running to include nameservers learnt from
pppoe etc.
The only place most of the rest of the system looks for resolvers
is in resolv.conf so what you describe ("rssolv.conf is fine") seems
unlikely. Double check what's actually in resolv.conf while pppoe is
connected?
To override learned nameservers, it depends whether you want to run
unwind on the system (used for resolution on localhost only) - if so,
use unwind.conf to set specific forwarders. If not, disable resolvd.
Check resolvd and unwind manpages for more info about what each does.
