kernel fault after 7.1
hello everybody. after upgrading to 7.1 my router started to panic very
often :(( about twice a day.
This is the information from the screen:
kernel: protection fault trap, code=0
Stopped at ipsp_ids_gc+0xb4 cmpl $0,0x64(%r14)
ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
ipsp_ids_gc(0) at ipsp_ids_gc+0xb4
softclock_thread(800022baf260) at softclock_thread+0x13b
and trace frame: 0x0, count: -2
ddb{0}> machine ddbcpu 1
Stopped at x86_ipi_db+0x12: leave
ddb{1}> trace
x86_ipi_db(800022909ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x203
sched_idle(800022909ff0) at sched_idle+0x280
end trace frame: 0x0, count -5
Re: Sprurios errors from syspatch -c
Richard Narron wrote: > On Fri, 22 Apr 2022, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > > After the 7.1 update syspatch -c started throwing errors due to a > > missing signatures file: > > > > Patch check: > > syspatch: Error retrieving > > http://ftp.openbsd.org/pub/OpenBSD/syspatch/7.1/amd64/SHA256.sig: 404 Not > > Found > > > > The error is valid. To suppress this message it would make sense to drop > > an empty place holder SHA256.sig file whenever a new release comes out. > > > > The error is caused by the wrong directory name. > > The syspatch/7.1 directory was renamed to syspatch/7.1-no > > Rumor has it that the source patch is good but the syspatch is bad, so > someone renamed the syspatch 7.1 directory to prevent its use. > > Has anyone heard anything "official" about this? The syspatch was accidentally built from the wrong branch, so upon relinking, it results in a kernel which says it is "7.1-stable". To prevent application of syspatches to the wrong type of system, syspatch(8) inspects 'sysctl kern.version'. It checks you have a normal release system (ie. 7.0 or 7.1). Since this patch renamed the system to "7.1-stable", syspatch(8) will refuse to install future patches. And of course the way this check is coded, it won't let you backout the patch which took the system to 7.1-stable.. Simple instructions for getting over this trouble will be coming along before there is a new syspatch 001_wifi is made available. I estimate a week. People who already installed the 001_wifi syspatch aren't harmed by the fix otherwise, but I have stopped distribution of the file to reduce the number of people in this crossed-over state. (Other than this issue, the syspatch itself was good, it fixes wifi association problems on a number of devices, so people who already have it shouldn't take special measures to get rid of it yet, wait for our advice in a week or so). And of course, the syspatch testing procedures will get another step or two to make sure this doesn't happen again So just wait.
Re: Sprurios errors from syspatch -c
On Fri, 22 Apr 2022, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > After the 7.1 update syspatch -c started throwing errors due to a > missing signatures file: > > Patch check: > syspatch: Error retrieving > http://ftp.openbsd.org/pub/OpenBSD/syspatch/7.1/amd64/SHA256.sig: 404 Not > Found > > The error is valid. To suppress this message it would make sense to drop > an empty place holder SHA256.sig file whenever a new release comes out. > The error is caused by the wrong directory name. The syspatch/7.1 directory was renamed to syspatch/7.1-no Rumor has it that the source patch is good but the syspatch is bad, so someone renamed the syspatch 7.1 directory to prevent its use. Has anyone heard anything "official" about this? Richard Narron
Re: rc.daily missing diff markers
Ingo Schwarze writes: > That's not new, it has been like that for at least 14 years and likely > much longer: Heh :-) Filing a bug report about my horrible memory seems wrong. > I don't think adding the more characters to each line would be a good idea. > It would cause line wrapping in mail even more often than the long lines > already do now. Besides, there is no real ambiguity because the file > name in the last column makes the pairing obvious and the dates right > in front of that show the direction of the change. Sure. It just caught my attention today because this is probably the first time I've seen such a large batch of changes in one email like that. Which has no doubt happened endless times in the past, but I never noticed it until today for some reason. Mostly this jars my OCD by having some of it in diff format, and some not. I'll get over it. --lyndon
Small go clone of httpd
If anyone is interested have a small go clone of the httpd web server here: https://github.com/aaronriekenberg/go-httpd Not nearly as complete as the real httpd but has enough features to roughly handle a config similar to /etc/examples/httpd.conf Sample config file: https://github.com/aaronriekenberg/go-httpd/blob/main/configfiles/gohttpd.json Some things that work: * Supports HTTP 1.1 and HTTP 2.0 via builtin go http server * Uses JSON for simple config file parsing * Uses chroot and setgid/setuid to drop privileges at startup after creating server sockets and reading tls files. * Configurable list of locations for each server that are matched in order for each request * For now only matching locations by URL path prefix but could easily use go regexp package * Configurable Cache-Control headers for file server locations * Fastcgi support using github.com/yookoala/gofast library * Request logging with file rotation * Small amount of code using builtin go http server and handlers
Re: rc.daily missing diff markers
Hi Lyndon, Lyndon Nerenberg wrote on Fri, Apr 22, 2022 at 09:33:57AM -0700: > In the output from the daily insecurity report run, the sections on > setuid and block device changes are missing any diff markup. The > remaining sections are fine. > > From this morning's post-7.1-upgrade run: > > Setuid changes: > -r-sr-xr-x 2 root bin 355952 Sep 30 13:01:03 2021 /sbin/ping > -r-sr-xr-x 2 root bin 358736 Apr 11 16:46:17 2022 /sbin/ping > -r-sr-xr-x 2 root bin 355952 Sep 30 13:01:03 2021 /sbin/ping6 > -r-sr-xr-x 2 root bin 358736 Apr 11 16:46:17 2022 /sbin/ping6 > -r-sr-x--- 1 root operator 274936 Sep 30 13:01:04 2021 /sbin/shutdown > -r-sr-x--- 1 root operator 277592 Apr 11 16:46:17 2022 /sbin/shutdown > [...] > > > Block device changes: > brw-r- 1 root operator 6, 0 Mar 4 14:48:06 2022 /dev/cd0a > brw-r- 1 root operator 6, 0 Apr 21 12:19:45 2022 /dev/cd0a > brw-r- 1 root operator 6, 2 Mar 4 14:48:06 2022 /dev/cd0c > brw-r- 1 root operator 6, 2 Apr 21 12:19:45 2022 /dev/cd0c > brw-r- 1 root operator 6, 16 Mar 4 14:48:01 2022 /dev/cd1a > brw-r- 1 root operator 6, 16 Apr 21 12:19:40 2022 /dev/cd1a > [...] That's not new, it has been like that for at least 14 years and likely much longer: From: Charlie Root Date: Sun, 27 Apr 2008 01:31:15 +0200 To: r...@usta.de Subject: hera.usta.de daily insecurity output [...] Setuid changes: -r-sr-xr-x 1 root bin 157408 Feb 11 00:00:58 2008 /sbin/ping -r-sr-xr-x 1 root bin 157440 Apr 21 02:58:12 2008 /sbin/ping -r-sr-xr-x 1 root bin 180896 Apr 21 02:58:12 2008 /sbin/ping6 -r-sr-xr-x 1 root bin 181024 Feb 11 00:00:58 2008 /sbin/ping6 [...] Block device changes: brw-r- 1 root operator 16, 0 Apr 26 21:21:20 2008 /dev/ccd0a brw-r- 1 root operator 16, 0 Feb 16 18:24:18 2008 /dev/ccd0a brw-r- 1 root operator 16, 1 Apr 26 21:21:20 2008 /dev/ccd0b brw-r- 1 root operator 16, 1 Feb 16 18:24:18 2008 /dev/ccd0b [...] Which means my 2011 rewrite of the utility (together with afresh1@) merely preserved the traditional format. These lines do not come from diff(1); see the functions check_filelist() and adjust_columns() for details. I don't think adding the more characters to each line would be a good idea. It would cause line wrapping in mail even more often than the long lines already do now. Besides, there is no real ambiguity because the file name in the last column makes the pairing obvious and the dates right in front of that show the direction of the change. Yours, Ingo
Should FUSE mounts be considered local?
I had an SMB network share mounted on a directory under my $HOME (via FUSE using usmb package), and overnight security(8) tried to check it for setuid/setgid files. That did not go well. I see that I could have set the SUIDSKIP environment variable but I didn't think about that in advance and even if I had, I probably would have assumed that such a mount was not considered local. $ mount [...] fusefs on /home/astreib/sav type fuse (local) Is this a problem with the usmb package, that it did not indicate that this was a network mount, or is that distinction just not possible with FUSE mounts? I.e. wondering if this is potentially fixable or if I need to remember to exclude any FUSE mounts via SUIDSKIP? Running OpenBSD 7.1 amd64 release. Allan
Re: 7.1 & nsd - failed writing to tcp: Permission denied
Laura, for a first step I would look at pflog(4). As Peter hinted, if you have an obscure pf rule blocking things after the connection sets up, this will point it out. (Make sure you have all the appropriate pflog bits enabled, of course.) If that doesn't work your next step is to fire up tcpdump and see what's actually happening on the wire. Look for a post-connection RST and work back from that. --lyndon
Re: 7.1 & nsd - failed writing to tcp: Permission denied
On Fri, Apr 22, 2022 at 04:03:17PM +, Laura Smith wrote: > Hi, > Am seeing some odd nsd log entries crop up in /var/log/messages.?? Any cause > for concern ? Anyone else seen these ? > > Apr 22 15:08:46 nsd[99760]: failed writing to tcp: Permission denied > > No problems with IPv4 or IPv6 connectivity on this host, I can access the > internet fine both directly on this host and through it (it doubles up as a > firewall). > > Laura Hi Laura, I took a look at the code and it is a writev() or a write() they do on tcp writes. Then I checked the manpage for send because write() on a TCP socket is the same as send() afaik. The manpage says this about your error: [EACCES] The connection was blocked by pf(4), or SO_BROADCAST is not set on the socket and a broadcast address was given as the destination. TCP doesn't do any broadcasting so it was blocked by p(4). So that's weird becuase the 3-way handshake must have completed for nsd to reply a query. Meaning there was SYN's and ACK's being exchanged but perhaps a PUSH+ACK may not succeed through the pf rules? Don't post your firewall rules to the list, but study them :-) and correct them. Best Regards, -peter
rc.daily missing diff markers
In the output from the daily insecurity report run, the sections on setuid and block device changes are missing any diff markup. The remaining sections are fine. >From this morning's post-7.1-upgrade run: Setuid changes: -r-sr-xr-x 2 root bin 355952 Sep 30 13:01:03 2021 /sbin/ping -r-sr-xr-x 2 root bin 358736 Apr 11 16:46:17 2022 /sbin/ping -r-sr-xr-x 2 root bin 355952 Sep 30 13:01:03 2021 /sbin/ping6 -r-sr-xr-x 2 root bin 358736 Apr 11 16:46:17 2022 /sbin/ping6 -r-sr-x--- 1 root operator 274936 Sep 30 13:01:04 2021 /sbin/shutdown -r-sr-x--- 1 root operator 277592 Apr 11 16:46:17 2022 /sbin/shutdown [...] Block device changes: brw-r- 1 root operator 6, 0 Mar 4 14:48:06 2022 /dev/cd0a brw-r- 1 root operator 6, 0 Apr 21 12:19:45 2022 /dev/cd0a brw-r- 1 root operator 6, 2 Mar 4 14:48:06 2022 /dev/cd0c brw-r- 1 root operator 6, 2 Apr 21 12:19:45 2022 /dev/cd0c brw-r- 1 root operator 6, 16 Mar 4 14:48:01 2022 /dev/cd1a brw-r- 1 root operator 6, 16 Apr 21 12:19:40 2022 /dev/cd1a [...]
Sprurios errors from syspatch -c
After the 7.1 update syspatch -c started throwing errors due to a missing signatures file: Patch check: syspatch: Error retrieving http://ftp.openbsd.org/pub/OpenBSD/syspatch/7.1/amd64/SHA256.sig: 404 Not Found The error is valid. To suppress this message it would make sense to drop an empty place holder SHA256.sig file whenever a new release comes out. --lyndon
Re: No valid root disk found when upgrading
On 2022-04-21, Stuart Henderson wrote: >> upgrade# cd /dev; sh MAKEDEV sd0 >> upgrade# mount -t ffs -r /dev/sd0a /mnt >> upgrade# ls /mnt >> .cshrc bsd dev sbin >> .profilebsd.booted etc sys >> altroot bsd.rd hometmp >> auto_upgrade.conf bsd.sp mailwrapper.coreusr >> bin bsd.upgrade rootvar >> upgrade# df -h >> Filesystem SizeUsed Avail Capacity Mounted on >> /dev/rd0a 3.5M3.0M451K87%/ >> /dev/sd0a 3.9G677M3.0G18%/mnt >> >>> it's worth seeing what "sysctl hw.disknames" says too >> upgrade# sysctl hw.disknames >> hw.disknames=sd0:dc999ef6267325df,rd0:a8c7c8e3bbaa0da7 > > That looks sane too.. Oh I didn't look close enough. You are missing /mnt. mkdir it and that shoukd fix the problem.
