Re: dhcpleased invalid IMSG_REQUEST_REBOOT
On Sun, Sep 01, 2024 at 08:25:07PM +0200, qwer...@tuta.io wrote:
> Hi,
>
> since a few days running current on arm64 (snapshots),
> i get following error:
> fatal in engine: engine_dispatch_frontend: invalid IMSG_REQUEST_REBOOT
> fatal in main: msgbuf_write: Broken pipe
>
This should fix it.
Index: control.c
===
RCS file: /cvs/src/sbin/dhcpleased/control.c,v
diff -u -p -r1.5 control.c
--- control.c 25 Aug 2024 09:53:53 - 1.5
+++ control.c 1 Sep 2024 18:40:58 -
@@ -291,7 +291,7 @@ control_dispatch_imsg(int fd, short even
c->iev.ibuf.pid = pid;
frontend_imsg_compose_engine(IMSG_REQUEST_REBOOT, 0,
- pid, &if_index, sizeof(&if_index));
+ pid, &if_index, sizeof(if_index));
break;
default:
log_debug("%s: error handling imsg %d", __func__, type);
Re: [ksh?] quote missing exit error message
> /home/user/bin/archivemedia[421]: syntax error: `)' unexpected This smells like the quoting bug mentioned in BUGS of ksh. It's not meant to be like this...
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
Thanks for the remote hands. I have committed the upstream fix developed in parallel to the ports tree.
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On Sun, Aug 18, 2024 at 02:07:43PM +0200, Peter N. M. Hansteen wrote:
> After upgrading my mail server to the latest snapshot, exim consistently
> crashes on incoming TLS, making it unable to receive among other
> openbsd.org mail.
pdkim.c:671:12: warning: call to undeclared function 'strchrnul'; ISO C99 and
later do not support implicit function declarations
[-Wimplicit-function-declaration]
end = US strchrnul(CS ele, ';');
^
pdkim.c:671:9: warning: cast to 'unsigned char *' from smaller integer type
'int' [-Wint-to-pointer-cast]
Please try this diff.
The problem is that strchrnul has no prototype, hence it is assumed
that it returns an int, hence the 64-bit pointer it returns is truncated
to 32 bits and hence invalid.
The fix for upstream probably is to add this to src/osfunctions.h
#ifndef strchrnul
extern char *strchrnul(const char * s, int c);
#endif
but I couldn't bring myself to do that.
Index: Makefile
===
RCS file: /cvs/ports/mail/exim/Makefile,v
diff -u -p -r1.149 Makefile
--- Makefile30 Jul 2024 21:10:05 - 1.149
+++ Makefile20 Aug 2024 16:41:49 -
@@ -7,6 +7,8 @@ PKGNAME-main = exim-${VERSION}
FULLPKGNAME-eximon = exim-eximon-${VERSION}
FULLPKGPATH-eximon = ${PKGPATH},-eximon
+REVISION = 0
+
CATEGORIES = mail
HOMEPAGE = https://www.exim.org/
Index: patches/patch-Local_Makefile
===
RCS file: /cvs/ports/mail/exim/patches/patch-Local_Makefile,v
diff -u -p -r1.10 patch-Local_Makefile
--- patches/patch-Local_Makefile15 Nov 2023 10:15:29 - 1.10
+++ patches/patch-Local_Makefile20 Aug 2024 16:41:22 -
@@ -1,7 +1,7 @@
Index: Local/Makefile
--- Local/Makefile.orig
+++ Local/Makefile
-@@ -101,7 +101,7 @@
+@@ -103,7 +103,7 @@
# /usr/local/sbin. The installation script will try to create this directory,
# and any superior directories, if they do not exist.
@@ -10,7 +10,7 @@ Index: Local/Makefile
#--
-@@ -117,7 +117,7 @@ BIN_DIRECTORY=/usr/exim/bin
+@@ -119,7 +119,7 @@ BIN_DIRECTORY=/usr/exim/bin
# don't exist. It will also install a default runtime configuration if this
# file does not exist.
@@ -19,7 +19,7 @@ Index: Local/Makefile
# It is possible to specify a colon-separated list of files for
CONFIGURE_FILE.
# In this case, Exim will use the first of them that exists when it is run.
-@@ -134,7 +134,7 @@ CONFIGURE_FILE=/usr/exim/configure
+@@ -136,7 +136,7 @@ CONFIGURE_FILE=/usr/exim/configure
# deliveries. (Local deliveries run as various non-root users, typically as
the
# owner of a local mailbox.) Specifying these values as root is not supported.
@@ -28,7 +28,7 @@ Index: Local/Makefile
# If you specify EXIM_USER as a name, this is looked up at build time, and the
# uid number is built into the binary. However, you can specify that this
-@@ -212,11 +212,11 @@ SPOOL_DIRECTORY=/var/spool/exim
+@@ -214,11 +214,11 @@ SPOOL_DIRECTORY=/var/spool/exim
# If you are building with TLS, the library configuration must be done:
# Uncomment this if you are using OpenSSL
@@ -42,7 +42,7 @@ Index: Local/Makefile
# TLS_LIBS=-L/usr/local/openssl/lib -lssl -lcrypto
# Uncomment this if you are using GnuTLS
-@@ -342,7 +342,7 @@ TRANSPORT_SMTP=yes
+@@ -344,7 +344,7 @@ TRANSPORT_SMTP=yes
# This one is special-purpose, and commonly not required, so it is not
# included by default.
@@ -51,7 +51,7 @@ Index: Local/Makefile
#--
-@@ -351,9 +351,9 @@ TRANSPORT_SMTP=yes
+@@ -353,9 +353,9 @@ TRANSPORT_SMTP=yes
# MBX, is included only when requested. If you do not know what this is about,
# leave these settings commented out.
@@ -64,7 +64,7 @@ Index: Local/Makefile
#--
-@@ -411,8 +411,8 @@ LOOKUP_DBM=yes
+@@ -413,8 +413,8 @@ LOOKUP_DBM=yes
LOOKUP_LSEARCH=yes
LOOKUP_DNSDB=yes
@@ -75,7 +75,7 @@ Index: Local/Makefile
# LOOKUP_IBASE=yes
# LOOKUP_JSON=yes
# LOOKUP_LDAP=yes
-@@ -420,10 +420,10 @@ LOOKUP_DNSDB=yes
+@@ -422,10 +422,10 @@ LOOKUP_DNSDB=yes
# LOOKUP_MYSQL=yes
# LOOKUP_MYSQL_PC=mariadb
@@ -88,7 +88,7 @@ Index: Local/Makefile
# LOOKUP_PGSQL=yes
# LOOKUP_REDIS=yes
# LOOKUP_SQLITE=yes
-@@ -523,7 +523,7 @@ SUPPORT_DANE=yes
+@@ -525,7 +525,7 @@ SUPPORT_DANE=yes
# and the MIME ACL. Please read the documentation to learn more about these
# features.
@@ -97,7 +97,7 @@ Index: Local/Makefile
# If you have content scanning you may wish to only include some of the
scanner
# interfaces. Uncomment any of these lines to remove that code.
-@@ -564,7 +564,7 @@ DISABLE_MAL_MKS=yes
+@@ -566,7 +566,7 @@ DISABLE_MAL_MKS=yes
# from Exim. Note it
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On Mon, Aug 19, 2024 at 02:57:28PM +0200, Renaud Allard wrote: > > > On 8/19/24 12:04 PM, Peter Nicolai Mathias Hansteen wrote: > > > > So quite odd, the whole thing. > > > > That's indeed quite odd if connecting with openssl s_client works. > I really think you should try out asking exim devs. It would be helpful to have a reproducer or a backtrace. It is impossible to gather much info from this discussion. While it is impossible to be sure where exactly the bug lies, it sure looks as if exim had another pretty bad bug in a release. The diff doesn't show much information since it's mostly pointless churn. I think it is about time to seriously consider removing exim from the ports tree for good.
Re: exim SIGSEGV on TLS connections on latest amd64 snapshot
On Sun, Aug 18, 2024 at 01:58:31PM +0100, Stuart Henderson wrote: > On 2024/08/18 13:57, Stuart Henderson wrote: > > Original message didn't show up. > > Ah it showed up now. > > : >Fix: > : To be determined. Likely abi mismatch between exim and libressl > > that's unlikely. yes. >> 2024-08-18 13:20:39 1sfdxf-6KQ-0Em4 SIGSEGV (fault address: >> 0x5e2f61b7) >> 2024-08-18 13:20:39 1sfdxf-6KQ-0Em4 SIGSEGV (maybe attempt to write >> to immutable memory) These strings aren't in a current source tree. Can you try running a kernel that you built yourself? It looks like something was in snaps but that diff seems to have been pulled. There haven't been recent changes in libssl or libcrypto that would explain this change of behavior.
Re: Idle single core CPU load at 100%
> > Description: > On some boots / unhibernates (lets say, about 75% of them), CPU0 > of my Lenovo Thinkpad X280 is at 100% load, checked with `htop`. > This happens with no user load as both `htop` and `top` only show > user processes with at most 1% load. On those 'hot boots', this > load does not mitigate itself by decreasing over time. `systat` > shows that there are about 3000 interrupts in total, 2300 coming > from `acpi0`, with 500 from `clock`. Battery drains really quickly > as expected. System performance is very much impacted. The cooling > fan spins at full speed. On my x280 this issue went away when I disabled thunderbolt in the BIOS. btw, top has -S (or the S toggle in interactive mode) to show kernel processes.
Re: strmode should take a mode_t instead of int.
These are the ports using strmode. archivers/libarchive archivers/libtar editors/emacs games/gemrb math/octave misc/findutils net/lftp security/ssh-ldap-helper shells/ksh93 sysutils/bfs sysutils/colorls sysutils/coreutils sysutils/lnav sysutils/tarsnap Given the short list and the nature of the change, I don't think it's necessary to run a bulk, but inspecting a few of them would be good, especially libarchive and coreutils are depended upon by a lot of ports. And there's emacs in this list.
Re: Pressing certain keys causes Nyx to crash
On Tue, Jun 11, 2024 at 04:18:55AM +, Bywater wrote:
> Hi Theo,
>
> Yes that worked! I was able to apply the patches and now nyx-2.1.0p6
> is running fine on my system.
Great, thanks for testing.
> Please let me know if there is anything else you need from me. (This
> is my first time submitting a bug and using the ports system.) Thank
> you so much!
Nothing more required from your side. I forgot to Cc the port's
maintainer in my previous mail, which I've now done. I'll give pascal
a bit of time to reply and will then commit the fix.
>
> Best,
>
> Nathan
>
> On Sunday, June 9th, 2024 at 5:19 PM, Theo Buehler
> wrote:
>
> >
> >
> > On Sun, Jun 09, 2024 at 04:55:32PM +, Bywater wrote:
> >
> > > > Synopsis: Certain key presses cause nyx-2.1.0p5 to crash
> > > > Category: user, aarch64
> > > > Environment:
> > > > System : OpenBSD 7.5
> > > > Details : OpenBSD 7.5-current (GENERIC.MP) #64: Fri Jun 7 00:47:53 MDT
> > > > 2024
> > > > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> > >
> > > Architecture: OpenBSD.arm64
> > > Machine : arm64
> > >
> > > > Description:
> > >
> > > Running a Tor bridge using tor-0.4.8.11, with nyx-2.1.0p5 to monitor it.
> > > Nyx is a command-line tool kind of like htop -- you can scroll up and
> > > down with the arrow keys or mouse to look through logs, config file,
> > > connections, etc. I had been using OpenBSD 7.5 stable with
> > > tor-0.4.8.10p0, nyx-2.1.0p4, and python-3.10.14, and everything worked
> > > fine. Now, after upgrading to current, pressing certain keys will cause
> > > nyx to exit back to the command line. Not every key, only certain keys.
> > > They are:
> >
> >
> >
> > > if inspect.getargspec(self._action).args == ['key']:
> > > ^^
> > > AttributeError: module 'inspect' has no attribute 'getargspec'. Did you
> > > mean: 'getargs'?
> > > $
> >
> >
> > getargspec() was deprecated for a while, still present in python 3.10
> > and removed from python 3.11. Using getfullargspec() instead should work.
> >
> > Can you try this patch?
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/net/nyx/Makefile,v
> > diff -u -p -r1.11 Makefile
> > --- Makefile 6 May 2024 12:23:47 - 1.11
> > +++ Makefile 9 Jun 2024 17:12:53 -
> > @@ -2,7 +2,7 @@ COMMENT = terminal status monitor for T
> >
> > MODPY_EGG_VERSION = 2.1.0
> > DISTNAME = nyx-${MODPY_EGG_VERSION}
> > -REVISION = 5
> > +REVISION = 6
> >
> > CATEGORIES = net
> >
> > Index: patches/patch-nyx_panel___init___py
> > ===
> > RCS file: patches/patch-nyx_panel___init___py
> > diff -N patches/patch-nyx_panel___init___py
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-nyx_panel___init___py 9 Jun 2024 17:12:53 -
> > @@ -0,0 +1,12 @@
> > +Index: nyx/panel/init.py
> > +--- nyx/panel/init.py.orig
> > nyx/panel/init.py
> > +@@ -78,7 +78,7 @@ class KeyHandler(collections.namedtuple('Help', ['key'
> > + is_match = self._key_func(key) if self._key_func else key.match(self.key)
> > +
> > + if is_match:
> > +- if inspect.getargspec(self._action).args == ['key']:
> > ++ if inspect.getfullargspec(self._action).args == ['key']:
> > + self._action(key)
> > + else:
> > + self._action()
> > Index: patches/patch-test___init___py
> > ===
> > RCS file: patches/patch-test___init___py
> > diff -N patches/patch-test___init___py
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-test___init___py 9 Jun 2024 17:12:53 -
> > @@ -0,0 +1,12 @@
> > +Index: test/init.py
> > +--- test/init.py.orig
> > test/init.py
> > +@@ -94,7 +94,7 @@ def render(func, *args, **kwargs):
> > + nyx.curses.CURSES_SCREEN.erase()
> > + start_time = time.time()
> > +
> > +- func_args = inspect.getargspec(func).args
> > ++ func_args = inspect.getfullargspec(func).args
> > +
> > + if func_args[:1] == ['subwindow'] or func_args[:2] == ['self',
> > 'subwindow']:
> > + def _draw(subwindow):
Re: Pressing certain keys causes Nyx to crash
On Sun, Jun 09, 2024 at 04:55:32PM +, Bywater wrote:
> >Synopsis: Certain key presses cause nyx-2.1.0p5 to crash
> >Category: user, aarch64
> >Environment:
> System : OpenBSD 7.5
> Details : OpenBSD 7.5-current (GENERIC.MP) #64: Fri Jun 7 00:47:53 MDT 2024
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
>
> Running a Tor bridge using tor-0.4.8.11, with nyx-2.1.0p5 to monitor it. Nyx
> is a command-line tool kind of like htop -- you can scroll up and down with
> the arrow keys or mouse to look through logs, config file, connections, etc.
> I had been using OpenBSD 7.5 stable with tor-0.4.8.10p0, nyx-2.1.0p4, and
> python-3.10.14, and everything worked fine. Now, after upgrading to current,
> pressing certain keys will cause nyx to exit back to the command line. Not
> every key, only certain keys. They are:
> if inspect.getargspec(self._action).args == ['key']:
> ^^
> AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean:
> 'getargs'?
> $
getargspec() was deprecated for a while, still present in python 3.10
and removed from python 3.11. Using getfullargspec() instead should work.
Can you try this patch?
Index: Makefile
===
RCS file: /cvs/ports/net/nyx/Makefile,v
diff -u -p -r1.11 Makefile
--- Makefile6 May 2024 12:23:47 - 1.11
+++ Makefile9 Jun 2024 17:12:53 -
@@ -2,7 +2,7 @@ COMMENT = terminal status monitor for T
MODPY_EGG_VERSION =2.1.0
DISTNAME = nyx-${MODPY_EGG_VERSION}
-REVISION = 5
+REVISION = 6
CATEGORIES = net
Index: patches/patch-nyx_panel___init___py
===
RCS file: patches/patch-nyx_panel___init___py
diff -N patches/patch-nyx_panel___init___py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-nyx_panel___init___py 9 Jun 2024 17:12:53 -
@@ -0,0 +1,12 @@
+Index: nyx/panel/__init__.py
+--- nyx/panel/__init__.py.orig
nyx/panel/__init__.py
+@@ -78,7 +78,7 @@ class KeyHandler(collections.namedtuple('Help', ['key'
+ is_match = self._key_func(key) if self._key_func else
key.match(self.key)
+
+ if is_match:
+-if inspect.getargspec(self._action).args == ['key']:
++if inspect.getfullargspec(self._action).args == ['key']:
+ self._action(key)
+ else:
+ self._action()
Index: patches/patch-test___init___py
===
RCS file: patches/patch-test___init___py
diff -N patches/patch-test___init___py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-test___init___py 9 Jun 2024 17:12:53 -
@@ -0,0 +1,12 @@
+Index: test/__init__.py
+--- test/__init__.py.orig
test/__init__.py
+@@ -94,7 +94,7 @@ def render(func, *args, **kwargs):
+ nyx.curses.CURSES_SCREEN.erase()
+ start_time = time.time()
+
+-func_args = inspect.getargspec(func).args
++func_args = inspect.getfullargspec(func).args
+
+ if func_args[:1] == ['subwindow'] or func_args[:2] == ['self',
'subwindow']:
+ def _draw(subwindow):
Re: fatal error: 'ufshci.h' file not found
On Wed, Jun 05, 2024 at 07:00:05PM +0100, kir...@korins.ky wrote: > >Synopsis:fatal error: 'ufshci.h' file not found > >Category:kernel > >Environment: > System : OpenBSD 7.5 > Details : OpenBSD 7.5-current (GENERIC.MP) #112: Tue Jun 4 > 21:00:07 MDT 2024 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > Can't compile the current snapshot from github > (741b0d5fc4bbf8da0904ac7b3c0d9f4a5f93) due to missed ufshci.h > Thus, I can't find this file via cvsweb.openbsd.org as well. It's a generated file. try again after 'make clean && make config' from GENERIC.MP/
Re: Memory Leak on 7.4 (Stable) with nginx 1.24.0 related to TLS1.3
This should be fixed with https://cvsweb.openbsd.org/src/lib/libssl/tls13_legacy.c#rev1.43 which you should be able to backport to 7.4 without issues if you don't want to use current. The short version is that it is an unfortunate interaction between nginx fiddling with internal state of the library (which it should not be able to but is) and the SSL_shutdown() implementation for the TLSv1.3 stack not reacting as expected.
Re: pthread_main_np(3) randomly fails
On Fri, Dec 08, 2023 at 03:25:21PM +, Miod Vallat wrote:
> How about that diff.
Should the tib_tid also be initialized?
>
> Index: include/tib.h
> ===
> RCS file: /OpenBSD/src/include/tib.h,v
> retrieving revision 1.9
> diff -u -p -r1.9 tib.h
> --- include/tib.h 27 Dec 2022 07:44:56 - 1.9
> +++ include/tib.h 8 Dec 2023 15:24:49 -
> @@ -216,6 +216,7 @@ struct tib {
> (tib)->tib_canceled = 0;\
> (tib)->tib_dtv = (dtv);\
> (tib)->tib_errno= 0;\
> + (tib)->tib_thread_flags = 0;\
> _TIB_PREP(tib); \
> } while (0)
>
>
Re: Is gprof not working? (maybe syscall)
On Thu, Nov 23, 2023 at 06:04:42AM -0700, j...@bitminer.ca wrote:
> SYNOPSIS: using -pg with cc results in segfault
> CATEGORY: system
> ENVIRONMENT:
> System : OpenBSD 7.4
> Details : OpenBSD 7.4-current (GENERIC) #1399: Wed Nov 22
> 08:12:44 MST 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> DESCRIPTION:
> Is gprof and related compiler switches expected to work?
>
> Or, in reading the backtrace, is there an issue with issetugid?
>
> Or, is this some syscall issue (see end of dmesg)?
>
> HOW-TO-REPEAT:
>
> $ cat m.c
> #include
> #include
>
> int
> main() {
> printf("m.c PI is %f\n", M_PI);
> }
> $ cc -o m.x m.c -lm
> $ ./m.x
> m.c PI is 3.141593
> $ cc -o m.x -pg m.c -lm
I forget what the explanation was that you run into the issetugid()
in ld.so, but the workaround is to link statically.
> $ ./m.x
> Segmentation fault
Re: NextHop address bug in bgpd with network connected
On Mon, Oct 09, 2023 at 08:58:25AM +0200, Claudio Jeker wrote:
> On Sun, Oct 08, 2023 at 04:14:33AM +, Asa Yeamans wrote:
> > Hey all,
> >
> > I recently stumbled across a bug in bgpd where when announcing connected
> > routes (i.e. network $AF connected) for IPv6 routes over IPv4 TCP BGP
> > connections, bgpd was announcing the IPv6 routes with a next hop of ::1,
> > the localhost address.
> >
> > I traced this down in the bgpd code to get_alternate_addr in session.c
> > incorrectly calling sa_cmp.
> >
> > sa_cmp in util.c compares two sockaddr structures and true (non-zero) if
> > they are equal and false (zero) if they are different. However,
> > get_alternate_addr treats the sa_cmp call as if it behaved like memcmp
> > (zero if equal, non-zero if different). This leads to get_alternate_addr
> > behaving incorrectly.
> >
> > The fix is to change the comparison (sa_cmp(sa, match->ifa_addr) == 0) from
> > == to !=.
> >
> > After implementing the change and running the patched version locally, I
> > have confirmed that it properly selects and reports nexthops when the route
> > AF is different from the BGP TCP connection AF.
> >
>
> Thanks for the report, this is indeed wrong.
>
> The below diff should fix this. I renamed sa_cmp() to sa_equal() to make
> it more obvious that a true return value means the two sa are equal.
Makes sense. You could unwrap the line if you want.
ok tb
>
> --
> :wq Claudio
>
> Index: session.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
> retrieving revision 1.447
> diff -u -p -r1.447 session.c
> --- session.c 4 Aug 2023 09:20:12 - 1.447
> +++ session.c 9 Oct 2023 06:56:05 -
> @@ -1204,7 +1204,7 @@ session_setup_socket(struct peer *p)
>
> /* compare two sockaddrs by converting them into bgpd_addr */
> static int
> -sa_cmp(struct sockaddr *a, struct sockaddr *b)
> +sa_equal(struct sockaddr *a, struct sockaddr *b)
> {
> struct bgpd_addr ba, bb;
>
> @@ -1224,7 +1224,7 @@ get_alternate_addr(struct sockaddr *sa,
>
> for (match = ifap; match != NULL; match = match->ifa_next)
> if (match->ifa_addr != NULL &&
> - sa_cmp(sa, match->ifa_addr) == 0)
> + sa_equal(sa, match->ifa_addr))
> break;
>
> if (match == NULL) {
Re: libressl on OpenBSD7.3 - x509_extensions crlDistributionPoints being ignored
> I have a config file for SSL certificates that declares to use the > x509_extensions crlDistributionPoints with this syntax: > crlDistributionPoints = URI:http://192.168.1.5/crl/root.crl This now works in current as of this commit: https://marc.info/?l=openbsd-cvs&m=169600269021154&w=2 Thanks for the report.
Re: libressl on OpenBSD7.3 - x509_extensions crlDistributionPoints being ignored
On Wed, Sep 27, 2023 at 09:06:58AM +0900, stephane Tranchemer wrote: > Hello, > > > > How-To-Repeat: > > > Create a config file for SSL certificates that declares to use the > > > x509_extensions crlDistributionPoints with a RUL target. > > > > > > Generate a certificate against this config, there should be the CRL > > > options > > > declared. > > As far as I can see, the problem is this: your crldp URI contains an IP > > address and you run into a check that the host component is not an IP > > address: > > > > https://github.com/openbsd/src/blob/master/lib/libcrypto/x509/x509_constraints.c#L52 > > That's right, I tried with a FQDN and it was much more happier. > Quite nasty that a behavior not supposed to work did work until one day > someone finally fixes it, quite confusing. Well. Arguably there is a bug. I'm not sure. > Another trouble I found, maybe it's my conf again(?) is that I am unable to > use a section to call out to define common options for x509extensions. > Example, this does not work: > > [ ca ] default_ca = Domain-CA [ Domain-CA ] ... x509_extensions = > common_options > > [ common_options ] crlDistributionPoints = > URI:http://my_machine_fqdn/crl/root.crl nsComment = "Generated Certificate > for Company" subjectKeyIdentifier = hash authorityKeyIdentifier = > keyid,issuer Please work this into an example explaining in detail what you expect to see and what you do see and what commands you run.
Re: libressl on OpenBSD7.3 - x509_extensions crlDistributionPoints being ignored
> >Description: > I have a config file for SSL certificates that declares to use the > x509_extensions crlDistributionPoints with this syntax: > crlDistributionPoints = URI:http://192.168.1.5/crl/root.crl > > however when generation the certificate against this config a check of the > generated certificate shows that the CRL definition is not present. What command do you actually run? The ones I tried did not generate a cert without CRL. They gave errors clearly pointing at your config: Error Loading extension section default 8235954348040:error:22FFF077:X509 V3 routines:CRYPTO_internal:bad object:/usr/src/lib/libcrypto/x509/x509_alt.c:697:name=URI value='http://192.168.1.5/crl/root.crl' 8235954348040:error:22FFF080:X509 V3 routines:CRYPTO_internal:error in extension:/usr/src/lib/libcrypto/x509/x509_conf.c:102:name=crlDistributionPoints, value=URI:http://192.168.1.5/crl/root.crl > This same config file was fine from around OpenBSD 6.7 up to 7.2. > > >How-To-Repeat: > Create a config file for SSL certificates that declares to use the > x509_extensions crlDistributionPoints with a RUL target. > > Generate a certificate against this config, there should be the CRL options > declared. As far as I can see, the problem is this: your crldp URI contains an IP address and you run into a check that the host component is not an IP address: https://github.com/openbsd/src/blob/master/lib/libcrypto/x509/x509_constraints.c#L52 reached via the GEN_URI case in the v2i_GENERAL_NAME() call from v2i_crld(). This check as it is now was introduced with the start of the CBS rewrite of the name constraints code: https://github.com/openbsd/src/commit/f06436f8f89ac0f304ac1a32314f2adbb2ea3b22 However, such a check was already there with the first version of x509_constraints(). It had a bug due to passing the entire 192.168.1.5/crl/root.crl to inet_pton() instead of only the IP address. That's why your config worked prior to 7.3. My understanding is that the v2i_GENERAL_NAME() was modified with the intention of making SAN checking stricter. I am not convinced these stricter checks should apply to all callers of v2i_GENERAL_NAME*(), in particular SIA, AIA and crlDP. An unrelated bug in the vicinity: cbs_is_ip_address() fails open when CBS_strdup() fails: return value 0 is good, 1 is bad.
Re: Sparc64 rthreads Instablilty
On Sat, Sep 02, 2023 at 11:52:28AM +0100, Martin Pieuchot wrote:
> On 13/08/23(Sun) 22:59, Kurt Miller wrote:
> > I’ve been hunting an intermittent jdk crash on sparc64 for some time now.
> > Since egdb has not been up to the task, I created a small c program which
> > reproduces the problem. This partially mimics the jdk startup where a number
> > of detached threads are created. When each thread is created the main thread
> > waits for it to start and change state. In my test program I then have the
> > detached thread wait for a condition that will not happen (parked waiting
> > on a condition var).
> >
> > When the intermittent crash occurs, one of two things happen; a segfault or
> > the process has been killed by the kernel. The segfault cores are similar to
> > what I see with the jdk crashes. It looks like the stack of the thread
> > creating
> > the threads is corrupted. In this case it is the primordial thread. In the
> > jdk
> > it is a different thread but its the thread that called pthread_create that
> > has it stack wiped out.
>
> I have seen similar symptoms on x86 with go & rust when unlocking the
> fault handler. I wonder if grabbing the KERNEL_LOCK() around uvm_fault()
> in sparc64/trap.c makes the problem disappear...
It does not. I ran the test program with the diff below and I still see
both symptoms of this instability.
Index: sys/arch/sparc64/sparc64/trap.c
===
RCS file: /cvs/src/sys/arch/sparc64/sparc64/trap.c,v
retrieving revision 1.115
diff -u -p -r1.115 trap.c
--- sys/arch/sparc64/sparc64/trap.c 11 Feb 2023 23:07:28 - 1.115
+++ sys/arch/sparc64/sparc64/trap.c 2 Sep 2023 12:16:09 -
@@ -957,7 +957,9 @@ text_access_fault(struct trapframe *tf,
uvm_map_inentry_sp, p->p_vmspace->vm_map.sserial))
goto out;
+ KERNEL_LOCK();
error = uvm_fault(&p->p_vmspace->vm_map, va, 0, access_type);
+ KERNEL_UNLOCK();
/*
* If this was a stack access we keep track of the maximum
@@ -1051,7 +1053,9 @@ text_access_error(struct trapframe *tf,
uvm_map_inentry_sp, p->p_vmspace->vm_map.sserial))
goto out;
+ KERNEL_LOCK();
error = uvm_fault(&p->p_vmspace->vm_map, va, 0, access_type);
+ KERNEL_UNLOCK();
/*
* If this was a stack access we keep track of the maximum
@@ -1261,7 +1265,9 @@ copyinsn(struct proc *p, vaddr_t uva, in
do {
if (pmap_copyinsn(map->pmap, uva, (uint32_t *)insn) == 0)
break;
+ KERNEL_LOCK();
error = uvm_fault(map, trunc_page(uva), 0, PROT_EXEC);
+ KERNEL_UNLOCK();
} while (error == 0);
return error;
Re: Sparc64 rthreads Instablilty
On Mon, Aug 14, 2023 at 08:47:22PM +, Miod Vallat wrote: > For what it's worth, I couldn't get your test to fail on a dual-cpu > sun4u. Either it's a sun4v-specific issue or it needs many more cpus to > trigger. I can reproduce the segfault, but seemingly not the killed process on 16-cpu LDOM ona T4-2: cpu0 at mainbus0: SPARC-T4 (rev 0.0) @ 2847.862 MHz Segmentation fault (core dumped) 93 Segmentation fault (core dumped) 1616 Segmentation fault (core dumped) 4185 etc. I don't seem to be able to reproduce on a 4-cpu M3000 cpu0 at core0: FJSV,SPARC64-VII (rev 10.1) @ 2750 MHz cpu0: physical 64K instruction (64 b/l), 64K data (64 b/l), 5120K external (256 b/l)
Re: patch crash related to remove_special_lines
On Tue, Jul 11, 2023 at 08:35:31PM +0200, Theo Buehler wrote:
> On Tue, Jul 11, 2023 at 02:32:48PM +0200, Theo Buehler wrote:
> > On Tue, Jul 11, 2023 at 11:48:57AM +0100, Stuart Henderson wrote:
> > > I ran into a segfault with patch(1) in a port, here's a test case with a
> > > minimal reproducer.
> > >
> > > $ echo foo > test
> > > $ perl -e 'print "--- test.orig\n+++ test\n@@ -1,1 +1,2 @@\n foo\n+" .
> > > 'x' x 32768 . "\n\\ No newline at end of file\n"' > test.patch
> >
> > patch maintains the line lengths in an array of shorts p_len[] and
> > doesn't check for overflows. This long line overflows the length, so
> > you get a bad buffer underrun when doing 's[p_len[filldst - 1]] = 0;'
>
> The below appears to fix this and passes regress. It won't be able to
> apply the binary patch, but it should no longer segfault.
More complete diff, thanks otto
Index: patch.c
===
RCS file: /cvs/src/usr.bin/patch/patch.c,v
retrieving revision 1.71
diff -u -p -r1.71 patch.c
--- patch.c 3 Aug 2022 07:30:37 - 1.71
+++ patch.c 11 Jul 2023 19:10:55 -
@@ -99,7 +99,7 @@ static void copy_till(LINENUM, bool);
static voidspew_output(void);
static voiddump_line(LINENUM, bool);
static boolpatch_match(LINENUM, LINENUM, LINENUM);
-static boolsimilar(const char *, const char *, int);
+static boolsimilar(const char *, const char *, ssize_t);
static __dead void usage(void);
/* true if -E was specified on command line. */
@@ -1012,7 +1012,7 @@ patch_match(LINENUM base, LINENUM offset
LINENUM pat_lines = pch_ptrn_lines() - fuzz;
const char *ilineptr;
const char *plineptr;
- short plinelen;
+ ssize_t plinelen;
for (iline = base + offset + fuzz; pline <= pat_lines; pline++,
iline++) {
ilineptr = ifetch(iline, offset >= 0);
@@ -1048,7 +1048,7 @@ patch_match(LINENUM base, LINENUM offset
* Do two lines match with canonicalized white space?
*/
static bool
-similar(const char *a, const char *b, int len)
+similar(const char *a, const char *b, ssize_t len)
{
while (len) {
if (isspace((unsigned char)*b)) { /* whitespace (or \n) to
match? */
Index: pch.c
===
RCS file: /cvs/src/usr.bin/patch/pch.c,v
retrieving revision 1.63
diff -u -p -r1.63 pch.c
--- pch.c 26 Dec 2022 19:16:02 - 1.63
+++ pch.c 11 Jul 2023 19:08:06 -
@@ -56,7 +56,7 @@ static LINENUMp_end = -1; /* last line
static LINENUM p_max; /* max allowed value of p_end */
static LINENUM p_context = 3; /* # of context lines */
static char**p_line = NULL;/* the text of the hunk */
-static short *p_len = NULL; /* length of each line */
+static ssize_t *p_len = NULL; /* length of each line */
static char*p_char = NULL; /* +, -, and ! */
static int hunkmax = INITHUNKMAX; /* size of above arrays to begin with */
static int p_indent; /* indent to patch */
@@ -127,7 +127,7 @@ set_hunkmax(void)
if (p_line == NULL)
p_line = calloc((size_t) hunkmax, sizeof(char *));
if (p_len == NULL)
- p_len = calloc((size_t) hunkmax, sizeof(short));
+ p_len = calloc((size_t) hunkmax, sizeof(ssize_t));
if (p_char == NULL)
p_char = calloc((size_t) hunkmax, sizeof(char));
}
@@ -140,7 +140,7 @@ grow_hunkmax(void)
{
int new_hunkmax;
char**new_p_line;
- short *new_p_len;
+ ssize_t *new_p_len;
char*new_p_char;
new_hunkmax = hunkmax * 2;
@@ -152,7 +152,7 @@ grow_hunkmax(void)
if (new_p_line == NULL)
free(p_line);
- new_p_len = reallocarray(p_len, new_hunkmax, sizeof(short));
+ new_p_len = reallocarray(p_len, new_hunkmax, sizeof(ssize_t));
if (new_p_len == NULL)
free(p_len);
@@ -1192,7 +1192,7 @@ bool
pch_swap(void)
{
char**tp_line; /* the text of the hunk */
- short *tp_len;/* length of each line */
+ ssize_t *tp_len;/* length of each line */
char*tp_char; /* +, -, and ! */
LINENUM i;
LINENUM n;
@@ -1349,7 +1349,7 @@ pch_context(void)
/*
* Return the length of a particular patch line.
*/
-short
+ssize_t
pch_line_len(LINENUM line)
{
return p_len[line];
Index: pch.h
===
RCS file: /cvs/src/usr.bin/patch/pch.h,v
retrieving revision 1.13
diff -u -p -r1.13 pch.h
--- pch.h 11 Dec 2019 20:10:17 - 1.13
+++ pch.h 11 Jul 2023 19:07:57 -
@@ -53,
Re: patch crash related to remove_special_lines
On Tue, Jul 11, 2023 at 02:32:48PM +0200, Theo Buehler wrote:
> On Tue, Jul 11, 2023 at 11:48:57AM +0100, Stuart Henderson wrote:
> > I ran into a segfault with patch(1) in a port, here's a test case with a
> > minimal reproducer.
> >
> > $ echo foo > test
> > $ perl -e 'print "--- test.orig\n+++ test\n@@ -1,1 +1,2 @@\n foo\n+" . 'x'
> > x 32768 . "\n\\ No newline at end of file\n"' > test.patch
>
> patch maintains the line lengths in an array of shorts p_len[] and
> doesn't check for overflows. This long line overflows the length, so
> you get a bad buffer underrun when doing 's[p_len[filldst - 1]] = 0;'
The below appears to fix this and passes regress. It won't be able to
apply the binary patch, but it should no longer segfault.
Index: pch.c
===
RCS file: /cvs/src/usr.bin/patch/pch.c,v
retrieving revision 1.63
diff -u -p -r1.63 pch.c
--- pch.c 26 Dec 2022 19:16:02 - 1.63
+++ pch.c 11 Jul 2023 18:34:29 -
@@ -56,7 +56,7 @@ static LINENUMp_end = -1; /* last line
static LINENUM p_max; /* max allowed value of p_end */
static LINENUM p_context = 3; /* # of context lines */
static char**p_line = NULL;/* the text of the hunk */
-static short *p_len = NULL; /* length of each line */
+static ssize_t *p_len = NULL; /* length of each line */
static char*p_char = NULL; /* +, -, and ! */
static int hunkmax = INITHUNKMAX; /* size of above arrays to begin with */
static int p_indent; /* indent to patch */
@@ -127,7 +127,7 @@ set_hunkmax(void)
if (p_line == NULL)
p_line = calloc((size_t) hunkmax, sizeof(char *));
if (p_len == NULL)
- p_len = calloc((size_t) hunkmax, sizeof(short));
+ p_len = calloc((size_t) hunkmax, sizeof(ssize_t));
if (p_char == NULL)
p_char = calloc((size_t) hunkmax, sizeof(char));
}
@@ -140,7 +140,7 @@ grow_hunkmax(void)
{
int new_hunkmax;
char**new_p_line;
- short *new_p_len;
+ ssize_t *new_p_len;
char*new_p_char;
new_hunkmax = hunkmax * 2;
@@ -152,7 +152,7 @@ grow_hunkmax(void)
if (new_p_line == NULL)
free(p_line);
- new_p_len = reallocarray(p_len, new_hunkmax, sizeof(short));
+ new_p_len = reallocarray(p_len, new_hunkmax, sizeof(ssize_t));
if (new_p_len == NULL)
free(p_len);
@@ -1192,7 +1192,7 @@ bool
pch_swap(void)
{
char**tp_line; /* the text of the hunk */
- short *tp_len;/* length of each line */
+ ssize_t *tp_len;/* length of each line */
char*tp_char; /* +, -, and ! */
LINENUM i;
LINENUM n;
Re: patch crash related to remove_special_lines
On Tue, Jul 11, 2023 at 11:48:57AM +0100, Stuart Henderson wrote: > I ran into a segfault with patch(1) in a port, here's a test case with a > minimal reproducer. > > $ echo foo > test > $ perl -e 'print "--- test.orig\n+++ test\n@@ -1,1 +1,2 @@\n foo\n+" . 'x' x > 32768 . "\n\\ No newline at end of file\n"' > test.patch patch maintains the line lengths in an array of shorts p_len[] and doesn't check for overflows. This long line overflows the length, so you get a bad buffer underrun when doing 's[p_len[filldst - 1]] = 0;'
Re: ftp(1) will never attempt to set the modification date of any file retrieved by http[s]
> Good catch. It's the only header where we forget to skip leading
> blanks.
This was overlooked in fetch.c r1.209
ok tb
>
> I can reproduce and confirm that this does indeed fix the parsing and
> make ftp set the mtime accordingly to Last-Modified.
>
> > diff --git i/usr.bin/ftp/fetch.c w/usr.bin/ftp/fetch.c
> > index 0ba7ad4d099..b6d6f4d775a 100644
> > --- i/usr.bin/ftp/fetch.c
> > +++ w/usr.bin/ftp/fetch.c
> > @@ -984,6 +984,7 @@ noslash:
> > } else if (strncasecmp(cp, LAST_MODIFIED,
> > sizeof(LAST_MODIFIED) - 1) == 0) {
> > cp += sizeof(LAST_MODIFIED) - 1;
> > + cp += strspn(cp, " \t");
> > cp[strcspn(cp, "\t")] = '\0';
> > if (strptime(cp, "%a, %d %h %Y %T %Z", &lmt) == NULL)
> > server_timestamps = 0;
>
>
Re: bgpd is dying on 7.3
On Sun, May 07, 2023 at 07:11:50PM +0200, Claudio Jeker wrote: > Please give the following diff a try and report back if it fixes your > issue. When copying the output filters the refcnt for your > match out to XYZ set nexthop BLA rule is not properly increased and when a > peer flaps the counts are off and probably trigger both the crash and > especially the fatal message. This makes sense and looks good to me. I'm not sure how much testing you want to see, but it might be better to land this. ok tb > > -- > :wq Claudio > > Index: rde_filter.c > === > RCS file: /cvs/src/usr.sbin/bgpd/rde_filter.c,v > retrieving revision 1.135 > diff -u -p -r1.135 rde_filter.c > --- rde_filter.c 19 Apr 2023 13:23:33 - 1.135 > +++ rde_filter.c 7 May 2023 16:48:44 - > @@ -583,6 +583,12 @@ filterset_copy(struct filter_set_head *s > if ((t = malloc(sizeof(struct filter_set))) == NULL) > fatal(NULL); > memcpy(t, s, sizeof(struct filter_set)); > + if (t->type == ACTION_RTLABEL_ID) > + rtlabel_ref(t->action.id); > + else if (t->type == ACTION_PFTABLE_ID) > + pftable_ref(t->action.id); > + else if (t->type == ACTION_SET_NEXTHOP_REF) > + nexthop_ref(t->action.nh_ref); > TAILQ_INSERT_TAIL(dest, t, entry); > } > } >
Re: unwind ignores 'force' directive for zone home.arpa
On Tue, Feb 07, 2023 at 01:00:04PM +0100, Florian Obser wrote:
> On 2023-02-06 14:33 -05, Ryan Kavanagh wrote:
> >>Synopsis: unwind ignores 'force' directive for home.arpa
> >>Category: system
> >>Environment:
> > System : OpenBSD 7.2
> > Details : OpenBSD 7.2-current (GENERIC.MP) #1015: Thu Feb 2
> > 06:25:57 MST 2023
> >
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> >>Description:
> > Nameserver 10.0.1.1 provides the zone home.arpa on my network, and I
> > would like unwind to forward requests for home.arpa and its
> > subdomains
> > to 10.0.1.1.
> >
> > unwind.conf(5) claims in its last example that I can force
> > unwind(8) to
> > use this forwarder to resolve home.arpa and its subdomains using a
> > stanza 'force forwarder { home.arpa }'. Unexpectedly, unwind serves
> > libunbound's default static, empty home.arpa zone instead of
> > forwarding
> > the request to the name server. Adding the 'bogus' keyword does not
> > change this behaviour.
>
> Please try this:
>
> diff --git resolver.c resolver.c
> index 93ec7b77a98..6131c7ccb95 100644
> --- resolver.c
> +++ resolver.c
> @@ -232,7 +232,7 @@ struct val_neg_cache *unified_neg_cache;
> int dns64_present;
> int available_afs = HAVE_IPV4 | HAVE_IPV6;
>
> -static const char * const as112_zones[] = {
> +static const char * const forward_transparent_zones[] = {
> /* RFC1918 */
> "10.in-addr.arpa. transparent",
> "16.172.in-addr.arpa. transparent",
> @@ -328,6 +328,9 @@ static const char * const as112_zones[] = {
>
> /* RFC3849 */
> "8.B.D.0.1.0.0.2.ip6.arpa. transparent"
Surely the previous line needs a comma.
> +
> + /* RFC 8375 */
All other comments do not have a space after RFC
> + "home.arpa. transparent"
> };
>
> const charbogus_past[] = "validation failure <. NS IN>: signature "
Re: Bug in awk script...
On Mon, Dec 26, 2022 at 06:03:42AM +0800, wuwow...@gmail.com wrote:
> Sad... Not working...
> OpenBSD 7.1
>
> #!/usr/bin/awk -f
> BEGIN {
> d = "/tmp/test/";
> system("mkdir -p " d);
> i = -1;
> while (++i < 1000) {
> f = d i;
> printf("") > f;
This opens f and leaves it open. You should close(f) if you no longer
need it.
> }
> }
>
> awk: can't open file /tmp/wow/125
Since you didn't close f, you ran into a limit of open files.
>
> It' seems that "one true awk" is buggy...
>
I would argue your script is buggy. It happens to work in GNU awk since
that has some file reuse logic.
Re: acme-client canary corrupted issue
> Try this
ok tb
>
> Index: revokeproc.c
> ===
> RCS file: /home/cvs/src/usr.sbin/acme-client/revokeproc.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 revokeproc.c
> --- revokeproc.c 22 Nov 2021 08:26:08 - 1.19
> +++ revokeproc.c 14 Dec 2022 14:16:46 -
> @@ -239,6 +239,7 @@ revokeproc(int fd, const char *certfile,
> goto out;
> }
> force = 2;
> + continue;
> }
> if (found[j]++) {
> if (revocate) {
>
Re: Possible bug with ix(4) in -current
On Sat, Nov 26, 2022 at 12:07:33PM +, li...@h3artbl33d.nl wrote: > Hi, > > I think I may have stumbled upon a bug in relation with ix(4) in -current. If > I boot this particular machine with any snapshot more recent than "OpenBSD > 7.2-current (GENERIC.MP) #827: Thu Nov 10 13:46:36 MST 2022" it stops in the > boot process at "starting network". The machine hasn't frozen, but it doesn't > seem to respond to any interrupts (like ^C). This should be fixed by the backout "revert pf.c r1.1152 again: move pf_purge out from under the kernel lock" https://marc.info/?l=openbsd-cvs&m=166940767311680&w=2 The bug was also discussed here: https://marc.info/?l=openbsd-bugs&m=166905853605995&w=2 The latest amd64 snapshot should already contain the backout, if not wait for the next one or compile a kernel containing pf.c 1.1156.
Re: tmux crashes on C-b :, C-b ,, C-b $, ...
> >How-To-Repeat: > In tmux with default keybindins, type C-b :, C-b ,, or C-b $. In the PR the option was called status-prompt-line. It was renamed to message-line, but one instance was missed, which results in a fatalx since it doesn't exist. Index: status.c === RCS file: /cvs/src/usr.bin/tmux/status.c,v retrieving revision 1.235 diff -u -p -r1.235 status.c --- status.c9 Sep 2022 11:02:23 - 1.235 +++ status.c10 Sep 2022 16:17:16 - @@ -271,7 +271,7 @@ status_prompt_line_at(struct client *c) if (c->flags & (CLIENT_STATUSOFF|CLIENT_CONTROL)) return (1); - return (options_get_number(s->options, "status-prompt-line")); + return (options_get_number(s->options, "message-line")); } /* Get window at window list position. */
Re: macppc panic: vref used where vget required
> Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same > assert. Here's an rebased diff for the bug discussed in this thread, > could you try again and let us know? Thanks! This seems to be stable now. It's been running for nearly 5 days. Without gnezdo's fix it would blow up within at most 2 days.
Re: macppc panic: vref used where vget required
On Mon, Jul 11, 2022 at 01:05:19PM +0200, Martin Pieuchot wrote:
> On 11/07/22(Mon) 07:50, Theo Buehler wrote:
> > On Fri, Jun 03, 2022 at 03:02:36PM +0200, Theo Buehler wrote:
> > > > Please do note that this change can introduce/expose other issues.
> > >
> > > It seems that this diff causes occasional hangs when building snapshots
> > > on my mac M1 mini. This happened twice in 10 builds, both times in
> > > xenocara. Unfortunately, both times the machine became entirely
> > > unresponsive and as I don't have serial console, that's all the info I
> > > have...
> > >
> > > This machine has been very reliable and built >50 snaps without any hang
> > > over the last 2.5 months. I'm now trying snap builds in a loop without
> > > the diff to make sure the machine doesn't hang due to another recent
> > > kernel change.
> > >
> >
> > A little bit of info on this. The first three lines were a bit garbled on
> > the screen:
> >
> > panic: kernel diagnostic assertion "uvn->_oppa jai c: ke r el
> > d iag no tic a s rt n " map ==UL L | | rw wr
> > k
> > ite held(amap->amap_lock)" failed: file "/ss/uvm/uvm_fault.c", line 846.
> > ernel diagnostic assertion "!_kernel_lock_held
> > Stopped at panic+0160: cmp w21, #0x0 ailed: file "/sys/kern/
> > TIDPID UID PRFLAGS PFLAGS CPU COMMAND
> > 411910 44540 210x11 0 3 make
> > *436444 84241 210x13 0 6 sh
> > 227952 53498 210x13 0 5 sh
> > 258925 15765 210x101005 0 0 make
> > 128459 9649 210x13 0 1 tradcpp
> > 287213 64216 210x130x8 7 make
> > 173587 461710000x10 0 2 tmux
> > 126511 69919 0 0x14000 0x200 4 softnet
> > db_enter() at panic+0x15c
> > panic() at __assert+0x24
> > uvm_fault() at uvm_fault_upper_lookup+0x258
> > uvm_fault_upper() at uvm_fault+0xec
> > uvm_fault() at udata_abort+0x128
> > udata_abort() at do_el0_sync+0xdc
> > do_el0_sync() at handle_el0_sync+0x74
> > 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{6}> show panic
> > *cpu0: kernel diagnostic assertion "uvn->u_obj.uo_refs == 0" failed: file
> > "/sys/kern/uvn_vnode.c", line 231.
> > cpu6: kernel diagnostic assertion "amap == NULL ||
> > rw_write_held(amap->am_lock)" failed: file "/sys/uvm/uvm_fault", line 846.
> > cpu3: kernel diagnostic assertion "!_kernel_lock_held()" failed: file
> > "/sys/kern/kern_fork.c", line 678
> > ddb{6}> mach ddbcpu 0
> >
> > After pressing enter here, the machine locked up completely.
>
> It's hard for me to tell what's going on. I believe the interesting
> trace is the one from cpu0 that we don't have. Can you easily reproduce
> this? I'm trying on amd64 without luck. I'd glad if you could gather
> more infos.
Sorry for the delay. I was only at home intermittently. I hit this three
times:
panic: kernel diagnostic assertion "uvn->u_obj.uo_refs == 0" failed: file
"/sys/uvm/uvm_vnode.c", line 231
panic+0x160:cmp w21, #0x0
TID PIDUIDPRFLAGS PFLAGS CPU COMMAND
66455 64425 210x11 07 make
*501659 83050 210x101005 02Kmake
226254 83437 210x11 00 sh
325842 29705 210x13 05 gzip
450503 79436 210x13 01 bdftopcf
223429 90969 210x13 03 make
25518 23526 10000x13 06 tee
482494 33196 0 0x14000 0x2004 reaper
db_enter() at panic+0x15c
panic() at __assert+0x24
panic() at uvn_attach+0x2ac
uvm_vnp_terminate() at vmcmd_map_pagedvn+0x58
vmcmd_map_pagedvn() at exec_process_vmcmds+0x80
exec_process_vmcmds() at sys_execve+0x5ac
sys_execve() at svc_handler+0x2bc
ddb{2}> bt
db_enter() at panic+0x15c
panic() at __assert+0x24
panic() at uvn_attach+0x2ac
uvm_vnp_terminate() at vmcmd_map_pagedvn+0x58
vmcmd_map_pagedvn() at exec_process_vmcmds+0x80
exec_process_vmcmds() at sys_execve+0x5ac
sys_execve() at svc_handler+0x2bc
svc_handler() at do_el0_sync+0xa0
do_el0_sync() at handle_el0_sync+0x74
address 0x7ea988 is invalid
--- trap ---
ddb{2}>
Apart from uvm_vnp_terminate(), the trace seems straightforward:
sys_execve()
exec_process_vmcmds()
vmcmd_map_pagedvn()
uvn_attach()
KASSERT(uvn->u_obj.uo_refs == 0)
I do not see how uvm_vnp_terminate() comes in. It showed up in all the
traces I saw. vmcmd_map_pagedvn + 0x58 is the call to uvn_attach() in
exec_subr.c:190.
Re: patch to ksh to show current rdomain
On Tue, Jul 26, 2022 at 11:49:09AM +0100, Stuart Henderson wrote: > On 2022/07/25 23:41, mgra...@brainfat.net wrote: > > >Description: > > This change adds the \% argument to the ksh process of the prompt. This > > will > > cause the current rdomain of the shell to be displayed in the prompt. This > > can be quite helpful when bouncing around between different rdomains. > > I'm not convinced that stacking more non-standard features in shell > prompt handling to show the rtable (note, not rdomain) is the best idea. > And I don't think it's going to change during the lifetime of a shell is > it? > > Could your profile/kshrc set up the prompt based on the current > rtable at the time PS1 is set instead? It's not entirely straightforward, > but these chicken scratches will show the table used by the current shell: > > ps -o rtable= -p $$ id -R
Re: macppc panic: vref used where vget required
> It's hard for me to tell what's going on. I believe the interesting > trace is the one from cpu0 that we don't have. Can you easily reproduce > this? I'm trying on amd64 without luck. I'd glad if you could gather > more infos. It is not hard to reproduce on my m1 mini, but it takes time - between 1-3 days of 'base + xenocara builds in a loop. Once it lands in the debugger, the machine tends to lock up after 2 or 3 ddb commands. I'll try to gather more info.
Re: macppc panic: vref used where vget required
On Fri, Jun 03, 2022 at 03:02:36PM +0200, Theo Buehler wrote:
> > Please do note that this change can introduce/expose other issues.
>
> It seems that this diff causes occasional hangs when building snapshots
> on my mac M1 mini. This happened twice in 10 builds, both times in
> xenocara. Unfortunately, both times the machine became entirely
> unresponsive and as I don't have serial console, that's all the info I
> have...
>
> This machine has been very reliable and built >50 snaps without any hang
> over the last 2.5 months. I'm now trying snap builds in a loop without
> the diff to make sure the machine doesn't hang due to another recent
> kernel change.
>
A little bit of info on this. The first three lines were a bit garbled on
the screen:
panic: kernel diagnostic assertion "uvn->_oppa jai c: ke r el d
iag no tic a s rt n " map ==UL L | | rw wr k
ite held(amap->amap_lock)" failed: file "/ss/uvm/uvm_fault.c", line 846.
ernel diagnostic assertion "!_kernel_lock_held
Stopped at panic+0160: cmp w21, #0x0 ailed: file "/sys/kern/
TIDPID UID PRFLAGS PFLAGS CPU COMMAND
411910 44540 210x11 0 3 make
*436444 84241 210x13 0 6 sh
227952 53498 210x13 0 5 sh
258925 15765 210x101005 0 0 make
128459 9649 210x13 0 1 tradcpp
287213 64216 210x130x8 7 make
173587 461710000x10 0 2 tmux
126511 69919 0 0x14000 0x200 4 softnet
db_enter() at panic+0x15c
panic() at __assert+0x24
uvm_fault() at uvm_fault_upper_lookup+0x258
uvm_fault_upper() at uvm_fault+0xec
uvm_fault() at udata_abort+0x128
udata_abort() at do_el0_sync+0xdc
do_el0_sync() at handle_el0_sync+0x74
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{6}> show panic
*cpu0: kernel diagnostic assertion "uvn->u_obj.uo_refs == 0" failed: file
"/sys/kern/uvn_vnode.c", line 231.
cpu6: kernel diagnostic assertion "amap == NULL ||
rw_write_held(amap->am_lock)" failed: file "/sys/uvm/uvm_fault", line 846.
cpu3: kernel diagnostic assertion "!_kernel_lock_held()" failed: file
"/sys/kern/kern_fork.c", line 678
ddb{6}> mach ddbcpu 0
After pressing enter here, the machine locked up completely.
Re: Unchecked tls_config_new() in relayd
> diff --git a/src/usr.sbin/relayd/hce.c b/src/usr.sbin/relayd/hce.c
> index 5233e2c..4a1bf1c 100644
> --- a/src/usr.sbin/relayd/hce.c
> +++ b/src/usr.sbin/relayd/hce.c
> @@ -94,6 +94,9 @@ hce_setup_events(void)
> table->tls_cfg != NULL)
> continue;
> table->tls_cfg = tls_config_new();
> + if (table->tls_cfg == NULL) {
> + fatalx("%s: tls_config_new", __func__);
> + }
I have applied a version of this diff. Thanks!
Re: macppc panic: vref used where vget required
> Please do note that this change can introduce/expose other issues. It seems that this diff causes occasional hangs when building snapshots on my mac M1 mini. This happened twice in 10 builds, both times in xenocara. Unfortunately, both times the machine became entirely unresponsive and as I don't have serial console, that's all the info I have... This machine has been very reliable and built >50 snaps without any hang over the last 2.5 months. I'm now trying snap builds in a loop without the diff to make sure the machine doesn't hang due to another recent kernel change.
Re: Unchecked tls_config_new() in relayd
> I'm not sure if there is much value in percolating the error upwards through > tls_init() into a careful termination provides a huge amount of value because > the error cannot be resolved without proper build & library support. Maybe not, but tls_config_new() can fail for many reasons, so its return value should be checked.
Re: syspatch fails on 7.1 due to wrong directory name on the mirrors
On Sat, Apr 23, 2022 at 10:08:12AM +0200, Clemens Gößnitzer wrote: > syspatch fails on 7.1 due to a wrong directory naming on the mirrors: >From https://www.openbsd.org/errata71.html Notice: A mistake was made in generating the syspatch(8) binary patch syspatch71-001_wifi for this errata. This causes problems installing future syspatches and reverting the syspatch. Because of this, the syspatch has been retracted until the issue is resolved. The actual source patch is not affected from this (and can be applied as described) and the syspatch itself works fine as well. If you already have installed syspatch71-001_wifi you can continue running with it until we publish instructions on how to recover in this place. Also: https://marc.info/?l=openbsd-misc&m=165068240031373&w=2 https://marc.info/?l=openbsd-announce&m=165070343704059&w=2
Re: ldap(1) search doesn't seem to working properly
On Wed, Mar 30, 2022 at 05:00:19PM +0200, Martijn van Duren wrote: > On Tue, 2022-03-29 at 20:43 +0100, Raf Czlonka wrote: > > > Synopsis: ldap(1) search doesn't seem to working properly > > > Category: system > > > Environment: > > System : OpenBSD 7.1 > > Details : OpenBSD 7.1-beta (GENERIC.MP) #444: Sun Mar 27 11:33:24 > > MDT 2022 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > > Description: > > ldap(1) search seems broken - doesn't show the attribute > > which has been explicitly requested > > > How-To-Repeat: > > $ ldap search -b 'ou=users,dc=debian,dc=org' -H db.debian.org -Z uid | > > grep ^uid | wc -l > >0 > > > > Only dn is shown, not uid, as expected. > > > Fix: > > This has been reported last year on misc@[0]; then martijn@ > > moved it to tech@[1] and sent a diff, with a follow-up > > January[2]. > > > > After a very quick test - essentially the same command as > > above - it seems like the proposed diff fixes the issue: > > > > $ /usr/obj/usr.bin/ldap/ldap search -b 'ou=users,dc=debian,dc=org' -H > > db.debian.org -Z uid | grep ^uid | wc -l > > 2240 > > > > [0] https://marc.info/?l=openbsd-misc&m=163618291218790&w=2 > > [1] https://marc.info/?l=openbsd-tech&m=163636158613557&w=2 > > [2] https://marc.info/?l=openbsd-tech&m=164121477527625&w=2 > > > > Regards, > > > > Raf > > > > Anyone willing to OK this before release? > As stated in my original mail, this should also be applied to > libexec/login_ldap and usr.sbin/ypldap ok tb (to commit this to all three patients)
Re: snmpd exits upon query by manager on 7.0-current octeon
On Tue, Feb 22, 2022 at 01:46:52PM +0100, Martijn van Duren wrote:
> Took me a while to dig up my octeon machine.
>
> The problem is that requestid is an int32, not a long long.
> Diff below fixes this for me.
>
> OK?
ok tb
>
> martijn@
>
> On Wed, 2022-02-09 at 15:01 +0100, Sebastian Oswald wrote:
> > > Synopsis: snmpd exits upon query by manager
> > > Category: system
> > > Environment:
> > System : OpenBSD 7.0
> > Details : OpenBSD 7.0-current (GENERIC.MP) #843: Tue Feb 8
> > 18:55:35 MST 2022
> >
> > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.octeon
> > Machine : octeon
> >
> > > Description:
> > after recent updates/upgrade via 'syspugrade -s' and 'pkg_add -u' snmpd
> > exits upon the first poll by a manager.
> > no errors are logged, but when spawning snmpd in foreground with extensive
> > verbosity the following is shown:
> >
> > [...]
> > USM: engineid '', engine boots 0, engine time 0, user ''
> > snmpe_parse: 172.25.50.99:161: unknown engine id
> > USM: engineid
> > '800075cb8192181e2bdb5065b50b43f6c3def2b40fd8a21228809b0ee452cc88', engine
> > boots 0, engine time 1644411792, user 'zabbix'
> > snmpe_parse: 172.25.50.99:161: SNMPv3 pdutype GetBulkRequest, flags 0x7,
> > secmodel 3, user 'zabbix', ctx-engine
> > 800075cb8192181e2bdb5065b50b43f6c3def2b40fd8a21228809b0ee452cc88, ctx-name
> > '', request
> > 1116207041
> > 78566 parent exiting
> >
> >
> > when trying to use protocol version 2c:
> > [...]
> > snmpe_parse: 172.25.50.99:161: SNMPv2 'test' pdutype GetBulkRequest request
> > 1825123407
> > 94220 parent exiting
> >
> >
> >
> > snmpd.conf contents:
> > listen_address="172.25.50.1"
> > listen on $listen_address
> > system description "OpenBSD gateway"
> > system location "home"
> > system services 74
> > system oid 1.3.6.1.4.1.30155.23.1
> > seclevel enc
> > user "zabbix" authkey "secret" auth "hmac-md5" enckey "secret" enc "aes"
> >
> >
> >
> > > How-To-Repeat:
> >
> > Steps to reproduce:
> > - start snmpd (via rcctl or with "snmpd -dv" for verbose output)
> > - poll agent from another host
> > - snmpd exits
> >
> Index: application.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/application.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 application.c
> --- application.c 30 Jan 2022 13:27:39 - 1.2
> +++ application.c 22 Feb 2022 12:45:43 -
> @@ -610,7 +610,7 @@ appl_processpdu(struct snmp_message *sta
> size_t i, varbindlen = 0, repeaterlen;
>
> /* pdu must be ASN.1 validated in snmpe.c */
> - (void) ober_scanf_elements(pdu, "{iiie", &requestid, &nonrepeaters,
> + (void) ober_scanf_elements(pdu, "{diie", &requestid, &nonrepeaters,
> &maxrepetitions, &varbindlist);
>
> /* RFC 3413, section 3.2, processPDU, item 5, final bullet */
>
Re: LibreSSL: crash creating a CA cert
As discussed with Volker off-list, the fact that the name constraint
'permitted;IP.0=10.0.0.0/255.0.0.0' from the config isn't accepted is
yet another bug from that diff. As far as I can see from a quick scan
of the spec and the code that's the only thing that needs special casing
for name constraints.
The syntax of iPAddress MUST be as described in Section 4.2.1.6 with
the following additions specifically for name constraints. For IPv4
addresses, the iPAddress field of GeneralName MUST contain eight (8)
octets, encoded in the style of RFC 4632 (CIDR) to represent an
address range [RFC4632]. For IPv6 addresses, the iPAddress field
MUST contain 32 octets similarly encoded. For example, a name
constraint for "class C" subnet 192.0.2.0 is represented as the
octets C0 00 02 00 FF FF FF 00, representing the CIDR notation
192.0.2.0/24 (mask 255.255.255.0).
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10
So for name constraints the length checks for IP addresses are incorrect.
The following addresses this and works for me.
So, to sum up the first hunk is a missing error check to fix the
segfault from
permitted;IP.0=10.0.0.0/8
The second hunk is to fix the length check for name constraints and the
third hunk avoids the double free this report was initially about.
Hopefully that's all...
Index: x509/x509_alt.c
===
RCS file: /cvs/src/lib/libcrypto/x509/x509_alt.c,v
retrieving revision 1.5
diff -u -p -r1.5 x509_alt.c
--- x509/x509_alt.c 28 Oct 2021 10:58:23 - 1.5
+++ x509/x509_alt.c 9 Feb 2022 18:32:20 -
@@ -649,6 +649,8 @@ v2i_GENERAL_NAME_ex(GENERAL_NAME *out, c
}
ret = a2i_GENERAL_NAME(out, method, ctx, type, value, is_nc);
+ if (ret == NULL)
+ return NULL;
/* Validate what we have for sanity */
type = x509_constraints_general_to_bytes(ret, &bytes, &len);
@@ -675,7 +677,8 @@ v2i_GENERAL_NAME_ex(GENERAL_NAME *out, c
}
break;
case GEN_IPADD:
- if (len != 4 && len != 16) {
+ if ((!is_nc && len != 4 && len != 16) ||
+ (is_nc && len != 8 && len != 32)) {
X509V3error(X509V3_R_BAD_IP_ADDRESS);
ERR_asprintf_error_data("name=%s len=%zu", name, len);
goto err;
@@ -686,7 +689,8 @@ v2i_GENERAL_NAME_ex(GENERAL_NAME *out, c
}
return ret;
err:
- GENERAL_NAME_free(ret);
+ if (out == NULL)
+ GENERAL_NAME_free(ret);
return NULL;
}
Re: LibreSSL: crash creating a CA cert
Many thanks for the additional detailas, that was very helpful. > openssl(9323) in free(): chunk is already free 0x3cb3a6a9780 > Abort trap That's a nasty double free originally introduced in -r1.3 of x509/x509_alt.c - a2i_GENERAL_NAME(out, ...) does not necessarily return something new: it will modify and return out if out != NULL. Accordingly, so we must free the return value if and only if out == NULL. > The issue seems to be actually with the line > > permitted;IP.0=10.0.0.0/255.0.0.0 > > Not sure if that's illegal, too, but at least according to > > https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html > > it should work. > > I changed it to > > permitted;IP.0=10.0.0.0/8 > > just to see what would happen. That gives me a Segfault ... And that's a missing error check introduced in the same commit... > > Well, the name constraints with .personal.lan aren't legal, that's why > > they are rejected. OpenSSL will let you write things in there that will > > then fail to interoperate. > > Rejecting illegal constraints is wonderful, but they shouldn't cause > crashes, no? Leaving aside the question whether we should accept some of this, here's a patch that avoids both bugs you ran into. Can you get openssl req to crash after rebuilding libcrypto with the below? Index: x509/x509_alt.c === RCS file: /cvs/src/lib/libcrypto/x509/x509_alt.c,v retrieving revision 1.5 diff -u -p -r1.5 x509_alt.c --- x509/x509_alt.c 28 Oct 2021 10:58:23 - 1.5 +++ x509/x509_alt.c 9 Feb 2022 15:30:03 - @@ -649,6 +649,8 @@ v2i_GENERAL_NAME_ex(GENERAL_NAME *out, c } ret = a2i_GENERAL_NAME(out, method, ctx, type, value, is_nc); + if (ret == NULL) + return NULL; /* Validate what we have for sanity */ type = x509_constraints_general_to_bytes(ret, &bytes, &len); @@ -686,7 +688,8 @@ v2i_GENERAL_NAME_ex(GENERAL_NAME *out, c } return ret; err: - GENERAL_NAME_free(ret); + if (out == NULL) + GENERAL_NAME_free(ret); return NULL; }
Re: LibreSSL: crash creating a CA cert
On Wed, Feb 09, 2022 at 09:17:26AM +0100, Volker Schlecht wrote: > Environment: -current, snapshot downloaded Feb 8th 2022 > Architecture: amd64 > > The following command crashes > > # openssl req -key -config -new -x509 -days 365 > -sha256 -extensions v3_ca -out > openssl(59343) in free(): chunk is already free 0xa32e41b9310 > Abort trap Could you please provide full commands and a config file that lead to this crash? We have scripts to create ca certs in our regress tests and they do not crash like that, so this must be something specific to what you have in there. > Passing the same command to eopenssl11 from ports works without issue. > > Note: > My config file contains a nameConstraints section, and if I pass in > > permitted;DNS.0=.personal.lan > permitted;URI.0=.personal.lan > > I additionally get > > 9107967210144:error:22FFF077:X509 V3 > routines:func(4095):reason(119):/usr/src/lib/libcrypto/x509/x509_alt.c:658:name=DNS.1 > value='.personal.lan' > > Changing the constraints to > > permitted;DNS.0=personal.lan > permitted;URI.0=personal.lan > > removes that error but still crashes. > > OpenSSL 1.1.1m accepts both nameConstraints. > Well, the name constraints with .personal.lan aren't legal, that's why they are rejected. OpenSSL will let you write things in there that will then fail to interoperate.
Re: NFS /usr partition unavailable during boot
On Fri, Jan 21, 2022 at 10:30:08AM +, dennis.nues...@posteo.net wrote: > While I’m trying to boot a diskless client, I am running in the issue, which > I described here in detail: > https://marc.info/?l=openbsd-misc&m=164228426116738&w=2 which contains this error: /etc/netstart: sed: not found /etc/netstart uses sed in one place: on encountering a "!command" line in a hostname.if file. This won't work if sed isn't available. This way of parsing lines has been present for nearly 5 years, so nobody else seems to be using this in a diskless environment. I suspect you will need to find a different solution for said command line.
Re: shell script started by rcctl stops immediately
> /usr/local/bin/mixsvr.sh: > + > #!/bin/sh -eu Try switching this to /bin/ksh
Re: OpenBSD 7.0 installer bug
On Sun, Oct 24, 2021 at 12:37:47PM +, Klemens Nanni wrote: > On Thu, Oct 21, 2021 at 10:29:02AM +, Klemens Nanni wrote: > > On Thu, Oct 21, 2021 at 04:06:53AM -0600, Theo de Raadt wrote: > > > Can people handle typing these passwords blindly? I suspect yes. > > > > > > Then this seems like a reasonable solution. > > > > Other systems do the redacted typing thing, so you see instead of > > what you actually typed; I think we're used to that and blindly typing > > is not much different... prompts like doas(1) do it as well. > > > > I didn't test autoinstall(8) and thought that was a problem since this > > diff changes the WEP/WPA passphrase questions from one to two answers if > > you will, but now I remembered that this obviously isn't a problem for > > the user password question either. > > > > Anyone willing to test this for me or even OK it? > > I can't do wifi installations here/now but am pretty confident that this > > does the right thing. > > New diff against -CURRENT. > > I'll commit this diff once I get positive feedback/an OK or tested it > myself. I'm not a fan. WiFi passwords tend to be on the longer side and nontrivial to type (they're also not things you tend to know by heart). I would not expect to be able to type my WiFi password blindly.
Re: kernel: page fault trap in rw_status
On Mon, Aug 30, 2021 at 10:45:47AM +0200, Martin Pieuchot wrote:
> On 06/08/21(Fri) 08:08, Theo Buehler wrote:
> > > The diff below fixes this by setting the "source" amap lock to the newly
> > > allocated one. This is not strictly necessary on OpenBSD since the amap
> > > is only inserted on the global list at the end of amap copy, but this
> > > satisfies the locking requirement of amap_wipeout() and is IMHO the
> > > simplest solution. This has also the advantage of reducing the
> > > differences with NetBSD.
> >
> > This diff causes a reproducible hang with mount_mfs(8) on my laptop. I
> > use an mfs noperm partition as described in
> > https://www.openbsd.org/faq/faq5.html#Release
> >
> > $ tail -1 /etc/fstab
> > swap /dest mfs rw,nosuid,noperm,-P/var/dest,-s1.5G,noauto 0 0
> >
> > If I run 'top -S -s.1' on an otherwise idle system and do 'mount /dest',
> > I see two mount_mfs(8) processes spin in fltamap and the pagedaemon is
> > spinning in pgdaemon before the system locks up completely (this takes
> > something between 1 and 20 seconds to happen).
>
> I couldn't reproduce this hang here. Do you also see it with the
> smaller fix below?
This appears to work fine. I can't reproduce the problem with this diff
across a few reboots.
The issue remains perfectly reproducible with the first version of the
diff, so if you want to poke at it, we can...
>
> Index: uvm/uvm_amap.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 uvm_amap.c
> --- uvm/uvm_amap.c26 Mar 2021 13:40:05 - 1.89
> +++ uvm/uvm_amap.c30 Aug 2021 08:31:21 -
> @@ -618,6 +618,13 @@ amap_copy(struct vm_map *map, struct vm_
> return;
> srcamap = entry->aref.ar_amap;
>
> + /*
> + * Make the new amap share the source amap's lock, and then lock
> + * both.
> + */
> + amap->am_lock = srcamap->am_lock;
> + rw_obj_hold(amap->am_lock);
> +
> amap_lock(srcamap);
>
> /*
> @@ -655,7 +662,7 @@ amap_copy(struct vm_map *map, struct vm_
>
> chunk = amap_chunk_get(amap, lcv, 1, PR_NOWAIT);
> if (chunk == NULL) {
> - amap_unlock(srcamap);
> + /* amap_wipeout() releases the lock. */
> amap->am_ref = 0;
> amap_wipeout(amap);
> return;
> @@ -695,10 +702,10 @@ amap_copy(struct vm_map *map, struct vm_
>* If we referenced any anons, then share the source amap's lock.
>* Otherwise, we have nothing in common, so allocate a new one.
>*/
> - KASSERT(amap->am_lock == NULL);
> - if (amap->am_nused != 0) {
> - amap->am_lock = srcamap->am_lock;
> - rw_obj_hold(amap->am_lock);
> + KASSERT(amap->am_lock == srcamap->am_lock);
> + if (amap->am_nused == 0) {
> + rw_obj_free(amap->am_lock);
> + amap->am_lock = NULL;
> }
> amap_unlock(srcamap);
>
Re: x260 suspend
On Thu, Aug 12, 2021 at 01:59:41PM +0200, Marcus MERIGHI wrote: > Hello! > > s...@spacehopper.org (Stuart Henderson), 2021.08.10 (Tue) 23:10 (CEST): > > On 2021/08/10 21:43, Theo Buehler wrote: > > > On Tue, Aug 10, 2021 at 11:38:11AM +0100, Stuart Henderson wrote: > > > > Something appears to have broken x260 suspend; zzz results in it > > > > sitting with > > > > screen off, the light flashing, and seemingly no way out other than > > > > forcibly > > > > powering down. > > > > > > I don't have much to add. I see the same on my x280. I noticed that > > > when I was playing a video during suspend, the sound of the video kept > > > playing until I force rebooted the unresponsive machine. > > > > > > The other observation is that on my machine I can't reproduce it > > > reliably. I saw it four times today, but now that I wanted to have a go > > > at bisecting it, I haven't been able to reproduce it. Unsure if it > > > depends on having a bad kernel link or if it's something I need to do > > > during runtime. > > > > I thought I was reproducing it quite reliably, but same here now I'm > > actually trying to bisect I'm not hitting it... > > Same here, on a T460s (dmesg below). After the first occasion of > not-suspending I started to unmount my big softraid crypt slice before > suspending, to save it from corruption. Of course it did suspend > correctly, then. The commit that was most likely responsible for this regression was backed out: https://marc.info/?l=openbsd-cvs&m=162869845616930&w=2 If you still encounter issues after upgrading to -current, please let us know.
Re: x260 suspend
On Tue, Aug 10, 2021 at 11:38:11AM +0100, Stuart Henderson wrote: > Something appears to have broken x260 suspend; zzz results in it sitting with > screen off, the light flashing, and seemingly no way out other than forcibly > powering down. I don't have much to add. I see the same on my x280. I noticed that when I was playing a video during suspend, the sound of the video kept playing until I force rebooted the unresponsive machine. The other observation is that on my machine I can't reproduce it reliably. I saw it four times today, but now that I wanted to have a go at bisecting it, I haven't been able to reproduce it. Unsure if it depends on having a bad kernel link or if it's something I need to do during runtime. As far as commits go, nothing really stands out since beginning of August, except perhaps commit 2bb569e6635011dfd3c529013e7697994a48b787 Author: jsg Date: Sat Aug 7 06:23:34 2021 + use taskq_del_barrier() instead of taskq_barrier() when flushing work
Re: kernel: page fault trap in rw_status
> The diff below fixes this by setting the "source" amap lock to the newly > allocated one. This is not strictly necessary on OpenBSD since the amap > is only inserted on the global list at the end of amap copy, but this > satisfies the locking requirement of amap_wipeout() and is IMHO the > simplest solution. This has also the advantage of reducing the > differences with NetBSD. This diff causes a reproducible hang with mount_mfs(8) on my laptop. I use an mfs noperm partition as described in https://www.openbsd.org/faq/faq5.html#Release $ tail -1 /etc/fstab swap /dest mfs rw,nosuid,noperm,-P/var/dest,-s1.5G,noauto 0 0 If I run 'top -S -s.1' on an otherwise idle system and do 'mount /dest', I see two mount_mfs(8) processes spin in fltamap and the pagedaemon is spinning in pgdaemon before the system locks up completely (this takes something between 1 and 20 seconds to happen).
Re: jot(1) randomness with larger numbers
On Thu, Jul 29, 2021 at 11:23:30AM -0600, Todd C. Miller wrote:
> On Thu, 29 Jul 2021 07:11:26 -0600, "Theo de Raadt" wrote:
>
> > I'm not sure about the tradeoff in this approach.
> >
> > Won't the lack of precision in double eventually lead to non-uniformity?
> >
> > The way jot is written, I expect higher ranges to have lots of
> > non-uniformity unless a substantial rewrite is undertaken, but I am
> > worry your approach creates non-uniformity within the 32-bit range.
>
> I don't think it really makes a difference since the result of
> "pow10 * (ender - begin)" will be a double regardless of whether
> it is stored in a uint32_t or double.
Also, doubles can precisely represent all uint32_t's, so I don't think
it would have any effect on uniformity (uintx is only fed into
arc4random_uniform()).
> Changing the type of uintx to uint64_t will also fix the problem.
> Perhaps that is more palatable?
I think we should keep uintx as an uint32_t since that's what the
arc4random() family expects. I'd argue that the check is wrong in that
it should be done before assigning the double to an uint32_t.
I'd suggest this diff:
Index: jot.c
===
RCS file: /cvs/src/usr.bin/jot/jot.c,v
retrieving revision 1.49
diff -u -p -r1.49 jot.c
--- jot.c 27 Jun 2019 18:03:36 - 1.49
+++ jot.c 29 Jul 2021 13:20:24 -
@@ -244,7 +244,7 @@ main(int argc, char *argv[])
if (putdata(x, reps == i && !infinity))
errx(1, "range error in conversion: %f", x);
} else { /* Random output: use defaults for omitted values. */
- booluse_unif;
+ booluse_unif = 0;
uint32_tpow10 = 1;
uint32_tuintx = 0; /* Initialized to make gcc happy. */
@@ -261,18 +261,19 @@ main(int argc, char *argv[])
if (prec == 0 && (fmod(ender, 1) != 0 || fmod(begin, 1) != 0))
use_unif = 0;
else {
+ double range;
+
while (prec-- > 0)
pow10 *= 10;
- /*
-* If pow10 * (ender - begin) is an integer, use
-* arc4random_uniform().
-*/
- use_unif = fmod(pow10 * (ender - begin), 1) == 0;
- if (use_unif) {
- uintx = pow10 * (ender - begin);
- if (uintx >= UINT32_MAX)
+
+ range = pow10 * (ender - begin);
+
+ /* If range is an integer, use arc4random_uniform(). */
+ if (fmod(range, 1) == 0) {
+ if (range >= UINT32_MAX)
errx(1, "requested range too large");
- uintx++;
+ use_unif = 1;
+ uintx = range + 1;
}
}
Re: LibreSSL: default ECDHE curves don't include P-521
On Mon, Jun 28, 2021 at 11:43:51PM -0400, Johnny Cast wrote: > Hi OpenBSD, > A few days ago I learned that LibreSSL's libtls does not include P-521 > in its list of default ECDHE curves. Is there any reason for this, and > would you be willing to consider adding it? It was speculated that > leaving P-521 out may have been a mistake. Here is a link to what > appears to be the commit that this was introduced in: > https://github.com/openbsd/src/commit/4896de1e4badc3cc28e3046a4145c94570c197d2 This is deliberate. The main reason is that P-521 is very expensive. This means that an attacker needs to feed you fewer key shares to keep a single server core busy than with the other curves, so it increases the risk of a DoS. The default curves are plenty secure and match BoringSSL: https://boringssl.googlesource.com/boringssl/+/e9fc3e547e557492316932b62881c3386973ceb2 That said, we had to include P-521 by default client side in libssl for interop with a popular VPN service that only supports this curve: https://cvsweb.openbsd.org/src/lib/libssl/t1_lib.c#rev1.169 What is your use case?
Re: Apache (built from the ports) is not woking with TLS 1.3 and LibreSSL 3.3.2
On Wed, Jun 23, 2021 at 04:10:13PM +, C. G. wrote: > Hi, > > I'm running 6.9 GENERIC#464 amd64 on a VirtualBox 6.1 VM, and I can't get > Apache to work with TLS 1.3. > > It's the release install. > > I've installed Apache from the ports with the FLAVOR=ldap, Apache version is > (output from apachectl -v) : > Server version: Apache/2.4.46 (Unix) This is expected. While LibreSSL 3.3.2 supports TLSv1.3, it does not yet support the OpenSSL TLSv1.3 API that is necessary for Apache to enable its TLSv1.3 codepaths. Hopefully this API will lan in -current soon so that this will become available in OpenBSD 7.0.
Re: panic: aml_die aml_rwgsb:2549
On Mon, Mar 29, 2021 at 09:25:04PM +0200, Mark Kettenis wrote:
> > Date: Thu, 25 Mar 2021 08:00:56 +0100
> > From: Theo Buehler
> >
> > On Wed, Mar 24, 2021 at 05:11:52PM +0100, Mark Kettenis wrote:
> > > > Date: Wed, 24 Mar 2021 09:47:56 +0100
> > > > From: Theo Buehler
> > > >
> > > > On Tue, Mar 23, 2021 at 08:29:29PM +0100, Mark Kettenis wrote:
> > > > > > Date: Tue, 23 Mar 2021 17:39:45 +0100
> > > > > > From: Theo Buehler
> > > > > >
> > > > > > On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote:
> > > > > > > > Date: Tue, 23 Mar 2021 16:56:33 +0100
> > > > > > > > From: Theo Buehler
> > > > > > > >
> > > > > > > > On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > > > > > > > > > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > > > > > > > > > From: Theo Buehler
> > > > > > > > >
> > > > > > > > > It would help if you could try and boot a kernel that adds
> > > > > > > > > some debug
> > > > > > > > > prints instead of calling aml_die(). Probably need to know
> > > > > > > > > the values
> > > > > > > > > of alen, bpos, blen, mode and flag for starters.
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605
> > > > > > > >
> > > > > > > > So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03
> > > > > > > > == 0
> > > > > > > > and the aml_die("Invalid GenericSerialBus access") is hit
> > > > > > > > because blen
> > > > > > > > is twice as long as it should be according to the conditional
> > > > > > > > preceding
> > > > > > > > it:
> > > > > > > >
> > > > > > > > if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC ||
> > > > > > > > bpos & 0x3 || blen != 8)
> > > > > > >
> > > > > > > Right, we need to figure out what this actually means. The ACPI
> > > > > > > standard isn't exactly clear on this...
> > > > > > >
> > > > > > > > If I skip the aml_die("Invalid GenericSerialBus access"), it
> > > > > > > > hits the
> > > > > > > > next aml_die("Could not find GenericSerialBus controller");
> > > > > > > > because
> > > > > > > > node->i2c == NULL.
> > > > > > >
> > > > > > > If I'm reading the AML and FreeBSD dmesg correctly this is an i2c
> > > > > > > controller that attaches to PCI. I suspect that it is dwiic(4).
> > > > > > > D
> > > > > > > you see dwiic(4) attach?
> > > > > >
> > > > > > Two of them:
> > > > > >
> > > > > > dwiic0 at pci0 dev 21 function 0 "Intel 400 Series I2C" rev 0x00:
> > > > > > apic 2 int 22
> > > > > > iic0 at dwiic0
> > > > > > dwiic1 at pci0 dev 21 function 1 "Intel 400 Series I2C" rev 0x00:
> > > > > > apic 2 int 23
> > > > > > iic1 at dwiic1
> > > > > >
> > > > > > > If so, the problem is that we dont't call acpi_register_gsb() for
> > > > > > > dwiic(4) instances that attach to PCI. I'll see if I can come up
> > > > > > > with
> > > > > > > a diff for that.
> > > > > >
> > > > > > Thanks a lot!
> > > > >
> > > > > Can you try the diff below?
> > > >
> > > > I tried to install a release built with this. With miniroot69.img I
> > > > still hit the reboot loop described in my first mail:
> > > >
> > > > ...
> > > > wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
> > > > aml_rwgen: unregistered RegionSpace 0x9
> > > > Could not convert 0 to 3
> > > >
> >
Re: panic: aml_die aml_rwgsb:2549
On Thu, Mar 25, 2021 at 08:00:57AM +0100, Theo Buehler wrote:
> On Wed, Mar 24, 2021 at 05:11:52PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 24 Mar 2021 09:47:56 +0100
> > > From: Theo Buehler
> > >
> > > On Tue, Mar 23, 2021 at 08:29:29PM +0100, Mark Kettenis wrote:
> > > > > Date: Tue, 23 Mar 2021 17:39:45 +0100
> > > > > From: Theo Buehler
> > > > >
> > > > > On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote:
> > > > > > > Date: Tue, 23 Mar 2021 16:56:33 +0100
> > > > > > > From: Theo Buehler
> > > > > > >
> > > > > > > On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > > > > > > > > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > > > > > > > > From: Theo Buehler
> > > > > > > >
> > > > > > > > It would help if you could try and boot a kernel that adds some
> > > > > > > > debug
> > > > > > > > prints instead of calling aml_die(). Probably need to know the
> > > > > > > > values
> > > > > > > > of alen, bpos, blen, mode and flag for starters.
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605
> > > > > > >
> > > > > > > So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03
> > > > > > > == 0
> > > > > > > and the aml_die("Invalid GenericSerialBus access") is hit because
> > > > > > > blen
> > > > > > > is twice as long as it should be according to the conditional
> > > > > > > preceding
> > > > > > > it:
> > > > > > >
> > > > > > > if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC ||
> > > > > > > bpos & 0x3 || blen != 8)
> > > > > >
> > > > > > Right, we need to figure out what this actually means. The ACPI
> > > > > > standard isn't exactly clear on this...
> > > > > >
> > > > > > > If I skip the aml_die("Invalid GenericSerialBus access"), it hits
> > > > > > > the
> > > > > > > next aml_die("Could not find GenericSerialBus controller");
> > > > > > > because
> > > > > > > node->i2c == NULL.
> > > > > >
> > > > > > If I'm reading the AML and FreeBSD dmesg correctly this is an i2c
> > > > > > controller that attaches to PCI. I suspect that it is dwiic(4). D
> > > > > > you see dwiic(4) attach?
> > > > >
> > > > > Two of them:
> > > > >
> > > > > dwiic0 at pci0 dev 21 function 0 "Intel 400 Series I2C" rev 0x00:
> > > > > apic 2 int 22
> > > > > iic0 at dwiic0
> > > > > dwiic1 at pci0 dev 21 function 1 "Intel 400 Series I2C" rev 0x00:
> > > > > apic 2 int 23
> > > > > iic1 at dwiic1
> > > > >
> > > > > > If so, the problem is that we dont't call acpi_register_gsb() for
> > > > > > dwiic(4) instances that attach to PCI. I'll see if I can come up
> > > > > > with
> > > > > > a diff for that.
> > > > >
> > > > > Thanks a lot!
> > > >
> > > > Can you try the diff below?
> > >
> > > I tried to install a release built with this. With miniroot69.img I
> > > still hit the reboot loop described in my first mail:
> > >
> > > ...
> > > wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
> > > aml_rwgen: unregistered RegionSpace 0x9
> > > Could not convert 0 to 3
> > >
> > > panic: aml_die aml_convert: 2095
> > > syncing disks...uvmfault(0x818e5d78, 0xbc8, 0, 1) -> e
> > > fatal page fault in supervisor mode
> > > trap type 6 code 0 rip 810e216b cs 8 rflags 10286 cr2 bc8 cpl 0
> > > rsp 80001f76f120
> > > gsbase 0x818d0ff0 kgsbase 0x0
> > > panic trap type 6, code=0, pc=810e216b
> > >
> > > dump to dev 17,1 not possible
> > > rebooting...
> > >
&g
Re: panic: aml_die aml_rwgsb:2549
On Wed, Mar 24, 2021 at 05:11:52PM +0100, Mark Kettenis wrote:
> > Date: Wed, 24 Mar 2021 09:47:56 +0100
> > From: Theo Buehler
> >
> > On Tue, Mar 23, 2021 at 08:29:29PM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 23 Mar 2021 17:39:45 +0100
> > > > From: Theo Buehler
> > > >
> > > > On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote:
> > > > > > Date: Tue, 23 Mar 2021 16:56:33 +0100
> > > > > > From: Theo Buehler
> > > > > >
> > > > > > On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > > > > > > > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > > > > > > > From: Theo Buehler
> > > > > > >
> > > > > > > It would help if you could try and boot a kernel that adds some
> > > > > > > debug
> > > > > > > prints instead of calling aml_die(). Probably need to know the
> > > > > > > values
> > > > > > > of alen, bpos, blen, mode and flag for starters.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605
> > > > > >
> > > > > > So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03 == 0
> > > > > > and the aml_die("Invalid GenericSerialBus access") is hit because
> > > > > > blen
> > > > > > is twice as long as it should be according to the conditional
> > > > > > preceding
> > > > > > it:
> > > > > >
> > > > > > if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC ||
> > > > > > bpos & 0x3 || blen != 8)
> > > > >
> > > > > Right, we need to figure out what this actually means. The ACPI
> > > > > standard isn't exactly clear on this...
> > > > >
> > > > > > If I skip the aml_die("Invalid GenericSerialBus access"), it hits
> > > > > > the
> > > > > > next aml_die("Could not find GenericSerialBus controller"); because
> > > > > > node->i2c == NULL.
> > > > >
> > > > > If I'm reading the AML and FreeBSD dmesg correctly this is an i2c
> > > > > controller that attaches to PCI. I suspect that it is dwiic(4). D
> > > > > you see dwiic(4) attach?
> > > >
> > > > Two of them:
> > > >
> > > > dwiic0 at pci0 dev 21 function 0 "Intel 400 Series I2C" rev 0x00: apic
> > > > 2 int 22
> > > > iic0 at dwiic0
> > > > dwiic1 at pci0 dev 21 function 1 "Intel 400 Series I2C" rev 0x00: apic
> > > > 2 int 23
> > > > iic1 at dwiic1
> > > >
> > > > > If so, the problem is that we dont't call acpi_register_gsb() for
> > > > > dwiic(4) instances that attach to PCI. I'll see if I can come up with
> > > > > a diff for that.
> > > >
> > > > Thanks a lot!
> > >
> > > Can you try the diff below?
> >
> > I tried to install a release built with this. With miniroot69.img I
> > still hit the reboot loop described in my first mail:
> >
> > ...
> > wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
> > aml_rwgen: unregistered RegionSpace 0x9
> > Could not convert 0 to 3
> >
> > panic: aml_die aml_convert: 2095
> > syncing disks...uvmfault(0x818e5d78, 0xbc8, 0, 1) -> e
> > fatal page fault in supervisor mode
> > trap type 6 code 0 rip 810e216b cs 8 rflags 10286 cr2 bc8 cpl 0 rsp
> > 80001f76f120
> > gsbase 0x818d0ff0 kgsbase 0x0
> > panic trap type 6, code=0, pc=810e216b
> >
> > dump to dev 17,1 not possible
> > rebooting...
> >
> > I tried to move acpi_register_gsb() and the call to it in dwiic_pci.c
> > out of SMALL_KERNEL, but that didn't help.
> >
> > What info would be useful to debug this further?
>
> SMALL_KERNEL deliberately doesn't GenericSerialBus support as this
> requires the presence of a whole set of I2C drivers that we have no
> space for on the install media.
>
> This machine violates the ACPI spec, since the AML should check that
> the i2c bus is actually available before using it. But pointing this
> out to Dell is probably not
Re: panic: aml_die aml_rwgsb:2549
On Tue, Mar 23, 2021 at 08:29:29PM +0100, Mark Kettenis wrote:
> > Date: Tue, 23 Mar 2021 17:39:45 +0100
> > From: Theo Buehler
> >
> > On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 23 Mar 2021 16:56:33 +0100
> > > > From: Theo Buehler
> > > >
> > > > On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > > > > > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > > > > > From: Theo Buehler
> > > > >
> > > > > It would help if you could try and boot a kernel that adds some debug
> > > > > prints instead of calling aml_die(). Probably need to know the values
> > > > > of alen, bpos, blen, mode and flag for starters.
> > > >
> > > > Thanks.
> > > >
> > > > alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605
> > > >
> > > > So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03 == 0
> > > > and the aml_die("Invalid GenericSerialBus access") is hit because blen
> > > > is twice as long as it should be according to the conditional preceding
> > > > it:
> > > >
> > > > if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC ||
> > > > bpos & 0x3 || blen != 8)
> > >
> > > Right, we need to figure out what this actually means. The ACPI
> > > standard isn't exactly clear on this...
> > >
> > > > If I skip the aml_die("Invalid GenericSerialBus access"), it hits the
> > > > next aml_die("Could not find GenericSerialBus controller"); because
> > > > node->i2c == NULL.
> > >
> > > If I'm reading the AML and FreeBSD dmesg correctly this is an i2c
> > > controller that attaches to PCI. I suspect that it is dwiic(4). D
> > > you see dwiic(4) attach?
> >
> > Two of them:
> >
> > dwiic0 at pci0 dev 21 function 0 "Intel 400 Series I2C" rev 0x00: apic 2
> > int 22
> > iic0 at dwiic0
> > dwiic1 at pci0 dev 21 function 1 "Intel 400 Series I2C" rev 0x00: apic 2
> > int 23
> > iic1 at dwiic1
> >
> > > If so, the problem is that we dont't call acpi_register_gsb() for
> > > dwiic(4) instances that attach to PCI. I'll see if I can come up with
> > > a diff for that.
> >
> > Thanks a lot!
>
> Can you try the diff below?
I tried to install a release built with this. With miniroot69.img I
still hit the reboot loop described in my first mail:
...
wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
aml_rwgen: unregistered RegionSpace 0x9
Could not convert 0 to 3
panic: aml_die aml_convert: 2095
syncing disks...uvmfault(0x818e5d78, 0xbc8, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 810e216b cs 8 rflags 10286 cr2 bc8 cpl 0 rsp
80001f76f120
gsbase 0x818d0ff0 kgsbase 0x0
panic trap type 6, code=0, pc=810e216b
dump to dev 17,1 not possible
rebooting...
I tried to move acpi_register_gsb() and the call to it in dwiic_pci.c
out of SMALL_KERNEL, but that didn't help.
What info would be useful to debug this further?
Re: panic: aml_die aml_rwgsb:2549
On Tue, Mar 23, 2021 at 08:29:29PM +0100, Mark Kettenis wrote:
> > Date: Tue, 23 Mar 2021 17:39:45 +0100
> > From: Theo Buehler
> >
> > On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 23 Mar 2021 16:56:33 +0100
> > > > From: Theo Buehler
> > > >
> > > > On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > > > > > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > > > > > From: Theo Buehler
> > > > >
> > > > > It would help if you could try and boot a kernel that adds some debug
> > > > > prints instead of calling aml_die(). Probably need to know the values
> > > > > of alen, bpos, blen, mode and flag for starters.
> > > >
> > > > Thanks.
> > > >
> > > > alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605
> > > >
> > > > So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03 == 0
> > > > and the aml_die("Invalid GenericSerialBus access") is hit because blen
> > > > is twice as long as it should be according to the conditional preceding
> > > > it:
> > > >
> > > > if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC ||
> > > > bpos & 0x3 || blen != 8)
> > >
> > > Right, we need to figure out what this actually means. The ACPI
> > > standard isn't exactly clear on this...
> > >
> > > > If I skip the aml_die("Invalid GenericSerialBus access"), it hits the
> > > > next aml_die("Could not find GenericSerialBus controller"); because
> > > > node->i2c == NULL.
> > >
> > > If I'm reading the AML and FreeBSD dmesg correctly this is an i2c
> > > controller that attaches to PCI. I suspect that it is dwiic(4). D
> > > you see dwiic(4) attach?
> >
> > Two of them:
> >
> > dwiic0 at pci0 dev 21 function 0 "Intel 400 Series I2C" rev 0x00: apic 2
> > int 22
> > iic0 at dwiic0
> > dwiic1 at pci0 dev 21 function 1 "Intel 400 Series I2C" rev 0x00: apic 2
> > int 23
> > iic1 at dwiic1
> >
> > > If so, the problem is that we dont't call acpi_register_gsb() for
> > > dwiic(4) instances that attach to PCI. I'll see if I can come up with
> > > a diff for that.
> >
> > Thanks a lot!
>
> Can you try the diff below?
This works. Awesome. Many thanks!
OpenBSD 6.9-beta (GENERIC.MP) #32: Tue Mar 23 20:32:41 CET 2021
t...@mimine.theobuehler.org:/sys/arch/amd64/compile/GENERIC.MP
real mem = 34003664896 (32428MB)
avail mem = 32957722624 (31430MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe (107 entries)
bios0: vendor Dell Inc. version "1.4.3" date 01/05/2021
bios0: Dell Inc. Precision 3640 Tower
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MCFG SSDT SSDT FIDT BOOT SSDT SSDT HPET SSDT SSDT NHLT
LPIT SSDT SSDT DBGP DBG2 SSDT MSDM SLIC DMAR BGRT ASF! APIC EINJ ERST BERT HEST
FPDT
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
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, 3694.83 MHz, 06-a5-05
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,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,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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 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) i7-10700K CPU @ 3.80GHz, 3691.40 MHz, 06-a5-05
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCN
Re: panic: aml_die aml_rwgsb:2549
On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote:
> > Date: Tue, 23 Mar 2021 16:56:33 +0100
> > From: Theo Buehler
> >
> > On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > > > From: Theo Buehler
> > >
> > > It would help if you could try and boot a kernel that adds some debug
> > > prints instead of calling aml_die(). Probably need to know the values
> > > of alen, bpos, blen, mode and flag for starters.
> >
> > Thanks.
> >
> > alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605
> >
> > So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03 == 0
> > and the aml_die("Invalid GenericSerialBus access") is hit because blen
> > is twice as long as it should be according to the conditional preceding
> > it:
> >
> > if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC ||
> > bpos & 0x3 || blen != 8)
>
> Right, we need to figure out what this actually means. The ACPI
> standard isn't exactly clear on this...
>
> > If I skip the aml_die("Invalid GenericSerialBus access"), it hits the
> > next aml_die("Could not find GenericSerialBus controller"); because
> > node->i2c == NULL.
>
> If I'm reading the AML and FreeBSD dmesg correctly this is an i2c
> controller that attaches to PCI. I suspect that it is dwiic(4). D
> you see dwiic(4) attach?
Two of them:
dwiic0 at pci0 dev 21 function 0 "Intel 400 Series I2C" rev 0x00: apic 2 int 22
iic0 at dwiic0
dwiic1 at pci0 dev 21 function 1 "Intel 400 Series I2C" rev 0x00: apic 2 int 23
iic1 at dwiic1
> If so, the problem is that we dont't call acpi_register_gsb() for
> dwiic(4) instances that attach to PCI. I'll see if I can come up with
> a diff for that.
Thanks a lot!
Re: panic: aml_die aml_rwgsb:2549
On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > From: Theo Buehler
>
> It would help if you could try and boot a kernel that adds some debug
> prints instead of calling aml_die(). Probably need to know the values
> of alen, bpos, blen, mode and flag for starters.
Thanks.
alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605
So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03 == 0
and the aml_die("Invalid GenericSerialBus access") is hit because blen
is twice as long as it should be according to the conditional preceding
it:
if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC ||
bpos & 0x3 || blen != 8)
If I skip the aml_die("Invalid GenericSerialBus access"), it hits the
next aml_die("Could not find GenericSerialBus controller"); because
node->i2c == NULL.
Re: Q: pkg_add fails with: TLS handshake failure: ocsp verify failed: Undefined error ...
On Fri, Mar 19, 2021 at 04:56:11PM +, Stuart Henderson wrote: > In gmane.os.openbsd.misc, li...@y42.org wrote: > > > > Hi All, > > > > What would cause pkg_add -u to report this error? > >> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: TLS handshake > >> failure: ocsp verify failed: Undefined error: 0 > >> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: empty > >> Couldn't find updates for ... a long list of (all?) installed packages ... > > > > Error 0? > > There is some problem doing OCSP validation. It validates OK with openssl > 1.0.2u and 1.1.1j but not with libressl. DFN run their own PKI and OCSP > responder so it might hit some edge case that isn't seen with other > responders. I missed a typo in tobhe's diff. This fixes it for me. Index: x509/x509_purp.c === RCS file: /cvs/src/lib/libcrypto/x509/x509_purp.c,v retrieving revision 1.3 diff -u -p -r1.3 x509_purp.c --- x509/x509_purp.c13 Mar 2021 23:01:49 - 1.3 +++ x509/x509_purp.c19 Mar 2021 17:21:29 - @@ -571,7 +571,7 @@ x509v3_cache_extensions(X509 *x) if (x->skid == NULL && i != -1) x->ex_flags |= EXFLAG_INVALID; x->akid = X509_get_ext_d2i(x, NID_authority_key_identifier, &i, NULL); - if (x->skid == NULL && i != -1) + if (x->akid == NULL && i != -1) x->ex_flags |= EXFLAG_INVALID; /* Does subject name match issuer? */
Re: vmm/vmd fails to boot bsd.rd
On Thu, Mar 11, 2021 at 10:32:08AM -0500, Dave Voutila wrote:
>
> Josh Rickmar writes:
>
> > On Wed, Mar 10, 2021 at 04:56:03PM -0500, Dave Voutila wrote:
> >>
> >> Josh Rickmar writes:
> >>
> >> > On Wed, Mar 10, 2021 at 01:11:30PM -0500, Josh Rickmar wrote:
> >> >> On Tue, Mar 09, 2021 at 09:36:49PM -0800, Mike Larkin wrote:
> >> >> > On Mon, Mar 08, 2021 at 05:10:27PM -0500, Josh Rickmar wrote:
> >> >> > > On Mon, Mar 08, 2021 at 11:03:10PM +0100, Klemens Nanni wrote:
> >> >> > > > On Mon, Mar 08, 2021 at 04:50:53PM -0500, Josh Rickmar wrote:
> >> >> > > > > >Synopsis: vmm/vmd fails to boot bsd.rd
> >> >> > > > > >Category: vmm
> >> >> > > > > >Environment:
> >> >> > > > > System : OpenBSD 6.9
> >> >> > > > > Details : OpenBSD 6.9-beta (GENERIC.MP) #385: Mon
> >> >> > > > > Mar 8 12:57:12 MST 2021
> >> >> > > > >
> >> >> > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >> >> > > > >
> >> >> > > > > Architecture: OpenBSD.amd64
> >> >> > > > > Machine : amd64
> >> >> > > > > >Description:
> >> >> > > > >
> >> >> > > > > vmm/vmd fails to boot /bsd.rd from a recent snapshot, however,
> >> >> > > > > bsd.sp
> >> >> > > > > is able to be booted in this manner.
> >> >> > > > This is most likely due to the recent switch to compressed bsd.rd;
> >> >> > > > dry a gzcat(1)ed copy of bsd.rd instead.
> >> >> > >
> >> >> > > Ah, yes this works.
> >> >> > >
> >> >> > > Is this expected behavior or should vmd be taught how to read the
> >> >> > > compressed kernel?
> >> >> > >
> >> >> >
> >> >> > Sure. A diff would be welcome (libz is already in the tree and ready
> >> >> > to use for
> >> >> > this).
> >> >>
> >> >> I expect this may need some cleanup, but with this patch I am able to
> >> >> boot the compressed bsd.rd.
> >> >>
> >> >> It replaces passing the kernel image around as a FILE* to a wrapper
> >> >> struct that may represent either a FILE* or gzFile. The struct points
> >> >> to a function pointer to dispatch to the correct read or seek
> >> >> functions.
> >> >>
> >> >> This isn't wrapping gztell, which is used to discover the size of the
> >> >> bios firmware image, and so that will continue to error if you try to
> >> >> load a compressed bios. I don't think we would want to wrap that,
> >> >> since seeking to the end to discover the size would result in
> >> >> decompressing everything twice.
> >> >
> >> > Hmm, let's rename "stdio" to "stream" for the regular uncompressed
> >> > files. Otherwise this diff is the same as before.
> >>
> >> I believe you can simplify this and assume the file is gzip compressed
> >> and wrap the file descriptor with a call to gzdopen(3) to create a
> >> gzFile. The gz{read,write,tell,etc.}(3) calls should operate on both
> >> gzip compressed and non-compressed files (in "transparent mode").
> >>
> >> That's at least my experience using gzdopen(3) and gzread(3).
> >
> > Thanks for the tip, I missed that transparent mode existed. Here's an
> > updated diff. I've tested this booting OpenBSD/amd64 both from
> > compressed and uncompressed kernels, and booting OpenBSD and Linux
> > from a disk installation and BIOS, but there are some problems
> > introduced by this approach.
> >
> > I am sure that the codepath in vmboot_open where an OpenBSD kernel is
> > found in a disk image is not correct anymore. fmemopen creates a
> > FILE* with no file descriptor for fileno to return for gzdopen, but we
> > want to return a gzFile. I wasn't able to hit this codepath while
> > testing though; kernel_fd was never -1 even with vmctl start -B disk.
>
> mlarkin: Is the ability to extract a boot.conf and kernel image from a
> UFS disk image needed anymore? I dug up the commit from 4 years ago (26
> Nov 2016) and I believe it predates booting with seabios being the
> default.
>
> The commit message from reyk@:
>
> ---
> Implement basic support for boot.conf(8) on the disk image.
>
> Like the real boot loader, load and parse hd0a:/etc/boot.conf from the
> first disk and fall back to /bsd. Not all boot loader options are
> supported, but it at least does set device, set image, and boot -acds
> (eg. for booting single-user).
>
> For example, it can now boot install60.fs that includes a boot.conf
> with "set image /6.0/amd64/bsd.rd":
> vmctl start install -c -d install60.fs -d OpenBSD.img
>
> This pseudo-bootloader is only needed without BIOS and could
> potentially be replaced in the future.
>
> OK mlarkin@
> ---
>
> What reyk@ was doing isn't possible anymore as vmd(8) by default will
> try to load the bios from /etc/firmware/vmm-bios before trying to boot
> from the provided disk image. If that's the case, Josh can simplify his
> diff and we can potentially remove the ufs handling logic and file(s)
> from vmd(8).
It is still possible to bypass seabios using -b disk -d disk. This would
need updating to ufs2 however. I sent out a diff doing that, but got no
feed
Re: systat memory leak
On Sat, Feb 06, 2021 at 03:20:20AM +, Anindya Mukherjee wrote:
> Hi, there seems to be a memory leak in systat where the help text buffer
> is not freed under some circumstances. As a result, repeatedly pressing,
> for example, 'h' and 'space' keys will cause it to leak memory. Also
> entering command mode with an active help text will leak the text. The
> following diff fixes it.
Thanks for the diff, I committed it. I had to re-do it since your mailer
used some MIME encoding, the result is visible here:
https://marc.info/?l=openbsd-bugs&m=161258168001057&q=mbox
While using bugs@ is perfectly fine, I would probably rather send such
a fix to tech@.
>
> Index: engine.c
> ===
> RCS file: /cvs/src/usr.bin/systat/engine.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 engine.c
> --- engine.c9 Jan 2021 12:49:09 - 1.26
> +++ engine.c6 Feb 2021 03:07:37 -
> @@ -1139,7 +1139,7 @@ command_set(struct command *cmd, const c
> cmdbuf[0] = 0;
> }
> }
> - curr_message = NULL;
> + message_set(NULL);
> curr_cmd = cmd;
> need_update = 1;
> return prev;
> @@ -1235,7 +1235,7 @@ keyboard(void)
>
> if (curr_message != NULL) {
> if (ch > 0) {
> - curr_message = NULL;
> + message_set(NULL);
> need_update = 1;
> }
> }
>
> ok?
>
> Regards,
> Anindya
>
Re: Net::LDAPS certificate verification fails in 6.8
On Mon, Feb 01, 2021 at 09:44:07AM +, Stuart Henderson wrote: > On 2021/02/01 08:44, Helmut Kiessling wrote: > > Hi, > > > > Seems I have issues receiving emails into my private email so can you > > kindly resend it to my work email instead? Original email below: > > > > I hope you can point me correct direction with this strange behaviour in > > OpenBSD 6.8. So my script is using Perl library NET::LDAPS like below: > > Row 85: my $ldap = Net::LDAPS->new(localhost, port => 636, version => 3, > > verify => 'require', capath => /etc/openldap/certs ) > > > > When running the script it gives the following error: > > # SSL connect attempt failed error:1404B418:SSL routines:ST_CONNECT:tlsv1 > > alert unknown ca error:14FFF086:SSL > > routines:(UNKNOWN)SSL_internal:certificate verify failed at update.pl line > > 85, line 960 > > > > And sure if I change verify => 'none' then it works but would be nice to > > get certs verified too. > > > > Note, this same script works ok in OpenBSD 6.7. > > > > Net::LDAPS version is 0.06 (I also have these installed Net::SSLeay 1.88 > > and IO::Socket::SSL 2.068 in case they are related) > > > > Do you have any ideas? > > Cert validation is broken in some cases in 6.8 (false failures, not > false positives). Depending on exactly which bug you run into, changing > your program from using capath to cafile might do the trick. Otherwise > the simplest workaround in most cases is to run -current where this is > likely to work. > We will release a syspatch for 6.8 that will likely fix this in the next few days.
Re: inet_net_pton() buffer overflow
On Mon, Jan 18, 2021 at 10:59:36AM +0100, Florian Obser wrote:
> On Thu, Jan 14, 2021 at 09:34:49AM -0500, Brad House wrote:
> > While working on debugging an issue reported in c-ares, I noticed some test
> > case failures in inet_net_pton(). I haven't evaluated most of them, however
> > one stood out:
> >
> > ../test/ares-test-internal.cc:150: Failure
> > Expected: -1
> > To be equal to: inet_net_pton(24,"12:34::ff",&a6,sizeof(a6) - 1)
> > Which is: 128
> >
> > This test expects inet_net_pton() to fail because the buffer provided was of
> > insufficient size.
> >
> > I'm not all that familiar with OpenBSD itself, a quick google search turned
> > up this as the possible source:
> > https://github.com/libressl-portable/openbsd/blob/master/src/lib/libc/net/inet_net_pton.c
> >
> > The 'size' parameter to inet_net_pton_ipv6() is *never* used:
> > https://github.com/libressl-portable/openbsd/blob/master/src/lib/libc/net/inet_net_pton.c#L206
> >
> > I believe this failure ends up later causing other test failures due to
> > memory corruption in the c-ares test cases.
> >
> >
>
> Thanks for the report, this is a potential fix:
I would have expected others to chime in, but since that didn't happen:
ok tb
>
> diff --git lib/libc/net/inet_net_pton.c lib/libc/net/inet_net_pton.c
> index 2aaeac4048a..d7cc75e0092 100644
> --- lib/libc/net/inet_net_pton.c
> +++ lib/libc/net/inet_net_pton.c
> @@ -205,9 +205,10 @@ inet_net_pton_ipv4(const char *src, u_char *dst, size_t
> size)
> static int
> inet_net_pton_ipv6(const char *src, u_char *dst, size_t size)
> {
> - int ret;
> - int bits;
> - char
> buf[sizeof("::::::255:255:255:255/128")];
> + struct in6_addr in6;
> + int ret;
> + int bits;
> + char buf[INET6_ADDRSTRLEN + sizeof("/128")];
> char*sep;
> const char *errstr;
>
> @@ -220,18 +221,24 @@ inet_net_pton_ipv6(const char *src, u_char *dst, size_t
> size)
> if (sep != NULL)
> *sep++ = '\0';
>
> - ret = inet_pton(AF_INET6, buf, dst);
> + ret = inet_pton(AF_INET6, buf, &in6);
> if (ret != 1)
> return (-1);
>
> if (sep == NULL)
> - return 128;
> + bits = 128;
> + else {
> + bits = strtonum(sep, 0, 128, &errstr);
> + if (errstr) {
> + errno = EINVAL;
> + return (-1);
> + }
> + }
>
> - bits = strtonum(sep, 0, 128, &errstr);
> - if (errstr) {
> - errno = EINVAL;
> + if ((bits + 7) / 8 > size) {
> + errno = EMSGSIZE;
> return (-1);
> }
> -
> - return bits;
> + memcpy(dst, &in6.s6_addr, size);
> + return (bits);
> }
>
>
> --
> I'm not entirely sure you are real.
>
Re: unbound on 6.8-current segfaults during network issues
On Sun, Jan 10, 2021 at 09:04:05AM +, Mikolaj Kucharski wrote: > On Sun, Jan 10, 2021 at 10:00:50AM +0100, Theo Buehler wrote: > > > > To get coredump and backtrace in such a situation, read up on > > > > kern.nouidcoredump=3 in sysctl(8) > > > > > > I imagine this is a typo and you meant kern.nosuidcoredump in > > > sysctl(2). Anyway, thanks, that is helpful for the future. > > > > Not really (see right before SEE ALSO in sysctl(8)), but sysctl(2) > > works, too :) > > Right. I mean missing letter `s` in your string. Oh that. Of course. > > kern.nouidcoredump != kern.nosuidcoredump > > -- > Regards, > Mikolaj
Re: unbound on 6.8-current segfaults during network issues
> > To get coredump and backtrace in such a situation, read up on > > kern.nouidcoredump=3 in sysctl(8) > > I imagine this is a typo and you meant kern.nosuidcoredump in > sysctl(2). Anyway, thanks, that is helpful for the future. Not really (see right before SEE ALSO in sysctl(8)), but sysctl(2) works, too :)
Re: unbound on 6.8-current segfaults during network issues
This is very likely to be fixed in -current by this commit: https://marc.info/?l=openbsd-cvs&m=160993335615698&w=2 diff here: https://marc.info/?l=openbsd-tech&m=160992433912265&w=2 To get coredump and backtrace in such a situation, read up on kern.nouidcoredump=3 in sysctl(8)
Re: Memory leak with getaddrinfo()
On Sun, Dec 27, 2020 at 08:44:52PM +0100, Otto Moerbeek wrote: > Hi, > > So here the diff that just fixes the mem leak on thread exit. It does > not contains the TLS init part, I'd like to do that differently than > what I did in the version I posted earlier. > > As stated before, this makes the getaddrino(3) test program run in > constant memory. > > ok? Please wrap this line at ,void: > -_thread_tag_storage(void **tag, void *storage, size_t sz, void *err) > +_thread_tag_storage(void **tag, void *storage, size_t sz, void (*dt)(void > *),void *err) This diff made firefox 84.0.1 crash frequently on my main laptop (about once every 10-15 minutes) while iridium was still stable and I could not observe any other fallout. The backtrace always looked like this: #0 thrkill () at /tmp/-:3 #1 0x00ae9eab90ee in nsProfileLock::FatalSignalHandler (signo=11, info=0xae12f05420, context=0xae12f05330) at /usr/obj/ports/firefox-84.0.1/firefox-84.0.1/toolkit/profile/nsProfileLock.cpp:168 #2 0x00ae9f5aada7 in WasmTrapHandler (signum=11, info=0xae12f05420, context=0xae12f05330) at /usr/obj/ports/firefox-84.0.1/firefox-84.0.1/js/src/wasm/WasmSignalHandlers.cpp:980 #3 #4 _asr_ctx_unref (ac=0xdfdfdfdfdfdfdfdf) at /usr/src/lib/libc/asr/asr.c:401 #5 _asr_resolver_done_tp (arg=0xadc8b2eec0) at /usr/src/lib/libc/asr/asr.c:141 #6 0x00ae5f6d0025 in _rthread_tls_destructors (thread=0xae81077440) at /usr/src/lib/libc/thread/rthread_tls.c:182 #7 0x00ae5f65ec13 in _libc_pthread_exit (retval=) at /usr/src/lib/libc/thread/rthread.c:150 #8 0x00ae39f038d9 in _rthread_start (v=) at /usr/src/lib/librthread/rthread.c:97 #9 0x00ae5f6e1c8a in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 (gdb)
Re: Memory leak with getaddrinfo()
On Sat, Dec 26, 2020 at 01:39:55PM +0100, Otto Moerbeek wrote:
> On Sat, Dec 26, 2020 at 11:31:32AM +0100, Otto Moerbeek wrote:
>
> > On Sat, Dec 26, 2020 at 11:07:00AM +0100, Otto Moerbeek wrote:
> >
> > > On Fri, Dec 25, 2020 at 02:04:03PM +0100, Otto Moerbeek wrote:
> > >
> > > > On Fri, Dec 25, 2020 at 12:59:10PM +0100, Otto Moerbeek wrote:
> > > >
> > > > > On Fri, Dec 25, 2020 at 12:35:57PM +0100, Mark Kettenis wrote:
> > > > >
> > > > > > > Date: Fri, 25 Dec 2020 11:34:47 +0100
> > > > > > > From: Otto Moerbeek
> > > > > > >
> > > > > > > On Thu, Dec 24, 2020 at 01:29:28PM +0100, Uli Schlachter wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > due to that other thread, it occurred to me that getaddrinfo()
> > > > > > > > also has
> > > > > > > > another bug: It leaks memory. _asr_use_resolver() allocates
> > > > > > > > memory
> > > > > > > > per-thread (via _asr_resolver()) and saves it via
> > > > > > > > _THREAD_PRIVATE() in
> > > > > > > > _asr, but nothing frees that memory. A reproducer follows
> > > > > > > > bellow. On
> > > > > > > > Debian, no memory leak is observed (= RES in top stays constant
> > > > > > > > over time).
> > > > > > > >
> > > > > > > > I have no good suggestion for how to fix this leak, but I feel
> > > > > > > > like this
> > > > > > > > might also be helpful in fixing the thread unsafety from "that
> > > > > > > > other
> > > > > > > > thread". Both bugs originate from storing a pointer to an
> > > > > > > > allocation via
> > > > > > > > _THREAD_PRIVATE(), which is something that does not really work
> > > > > > > > with
> > > > > > > > that API.
> > > > > > > >
> > > > > > > > IMHO this internal API needs to change. At this point, one can
> > > > > > > > also fix
> > > > > > > > the other problem by having an API that guarantees that each
> > > > > > > > thread gets
> > > > > > > > zeroed per-thread data instead of memcpy()ing from a global
> > > > > > > > default.
> > > > > > > >
> > > > > > > > Other users of _THREAD_PRIVATE() instead seem to only store
> > > > > > > > buffers,
> > > > > > > > e.g. strerror_l() or localtime(). These buffers do not need
> > > > > > > > extra cleanup.
> > > > > > > >
> > > > > > > > Reproducer (sorry for the line wrapping; this is basically just
> > > > > > > > the
> > > > > > > > previous example, but without calling getaddrinfo() on the main
> > > > > > > > thread:
> > > > > > > > lots of threads are started and each thread calls getaddrinfo()
> > > > > > > > once):
> > > > > > > >
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > >
> > > > > > > > #define NUM_THREADS 50
> > > > > > > >
> > > > > > > > static void do_lookup(const char *host)
> > > > > > > > {
> > > > > > > > int s;
> > > > > > > > struct addrinfo hints;
> > > > > > > > struct addrinfo *result;
> > > > > > > >
> > > > > > > > memset(&hints, 0, sizeof(hints));
> > > > > > > > hints.ai_family = AF_UNSPEC;
> > > > > > > > hints.ai_socktype = SOCK_STREAM;
> > > > > > > > hints.ai_flags = AI_ADDRCONFIG;
> > > > > > > > hints.ai_protocol = IPPROTO_TCP;
> > > > > > > >
> > > > > > > > s = getaddrinfo(host, NULL, &hints, &result);
> > > > > > > > if (s != 0) {
> > > > > > > > fprintf(stderr, "Lookup error for %s: %s\n",
> > > > > > > > host, gai_strerror(s));
> > > > > > > > } else {
> > > > > > > > freeaddrinfo(result);
> > > > > > > > }
> > > > > > > > }
> > > > > > > >
> > > > > > > > static void *
> > > > > > > > do_things(void *arg)
> > > > > > > > {
> > > > > > > > (void) arg;
> > > > > > > > do_lookup("ipv4.google.com");
> > > > > > > > return NULL;
> > > > > > > > }
> > > > > > > >
> > > > > > > > int main()
> > > > > > > > {
> > > > > > > > pthread_t threads[NUM_THREADS];
> > > > > > > > int i;
> > > > > > > > int s;
> > > > > > > >
> > > > > > > > for (;;) {
> > > > > > > > for (i = 0; i < NUM_THREADS; i++) {
> > > > > > > > s = pthread_create(&threads[i], NULL,
> > > > > > > > do_things, NULL);
> > > > > > > > if (s != 0)
> > > > > > > > fprintf(stderr, "Error creating
> > > > > > > > thread");
> > > > > > > > }
> > > > > > > > for (i = 0; i < NUM_THREADS; i++) {
> > > > > > > > pthread_join(threads[i], NULL);
> > > > > > > > }
> > > > > > > > }
> > > > > > > > return 0;
> > > > > > > > }
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Uli
> > > > > > > > --
> > > > > > > > This can be a, a little complicated. Listen, my advice is... ask
> > > > > > > > somebody else for advice, at least someone who's... got mor
Re: getaddrinfo() is not thread-safe in 6.8
> Hi, getaddrinfo() crashes when multiple threads run getaddrinfo() > concurrently. This didn't happen in 6.7. Just to avoid confusion: I see similar crashes on 6.7, 6.6 and 6.4.
Re: Fwd: Re: ssh_config(5) ProxyJump option not working in the latest snapshot
On Mon, Dec 21, 2020 at 10:15:33AM +0100, Theo Buehler wrote:
> On Mon, Dec 21, 2020 at 08:10:59PM +1100, Damien Miller wrote:
> > Sorry, this snuck back in along with another commit.
> >
> > Does this fix it?
>
> Yes. I was hesitating doing something equivalent to this, but went for
> the plain revert in my proposed diff.
>
> ok tb
Sorry, I did not look carefully enough at the second part of the diff.
This bit should have been removed as in the first bit:
Index: readconf.c
===
RCS file: /cvs/src/usr.bin/ssh/readconf.c,v
retrieving revision 1.345
diff -u -p -r1.345 readconf.c
--- readconf.c 21 Dec 2020 09:19:53 - 1.345
+++ readconf.c 21 Dec 2020 10:36:24 -
@@ -2784,9 +2784,6 @@ parse_jump(const char *s, Options *o, in
goto out;
} else {
/* Subsequent argument or inactive configuration */
- if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 &&
- parse_user_host_port(cp, NULL, NULL, NULL) != 0)
- goto out;
r = parse_ssh_uri(cp, NULL, NULL, NULL);
if (r == -1 || (r == 1 &&
parse_user_host_port(cp, NULL, NULL, NULL) != 0))
Re: Fwd: Re: ssh_config(5) ProxyJump option not working in the latest snapshot
On Mon, Dec 21, 2020 at 08:10:59PM +1100, Damien Miller wrote:
> Sorry, this snuck back in along with another commit.
>
> Does this fix it?
Yes. I was hesitating doing something equivalent to this, but went for
the plain revert in my proposed diff.
ok tb
>
> diff --git a/readconf.c b/readconf.c
> index cec6844..85e8c6f 100644
> --- a/readconf.c
> +++ b/readconf.c
> @@ -2769,7 +2769,7 @@ parse_jump(const char *s, Options *o, int active)
> {
> char *orig, *sdup, *cp;
> char *host = NULL, *user = NULL;
> - int ret = -1, port = -1, first;
> + int r, ret = -1, port = -1, first;
>
> active &= o->proxy_command == NULL && o->jump_host == NULL;
>
> @@ -2785,14 +2785,19 @@ parse_jump(const char *s, Options *o, int active)
>
> if (first) {
> /* First argument and configuration is active */
> - if (parse_ssh_uri(cp, &user, &host, &port) == -1 &&
> - parse_user_host_port(cp, &user, &host, &port) != 0)
> + r = parse_ssh_uri(cp, &user, &host, &port);
> + if (r == -1 || (r == 1 &&
> + parse_user_host_port(cp, &user, &host, &port) != 0))
> goto out;
> } else {
> /* Subsequent argument or inactive configuration */
> if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 &&
> parse_user_host_port(cp, NULL, NULL, NULL) != 0)
> goto out;
> + r = parse_ssh_uri(cp, NULL, NULL, NULL);
> + if (r == -1 || (r == 1 &&
> + parse_user_host_port(cp, NULL, NULL, NULL) != 0))
> + goto out;
> }
> first = 0; /* only check syntax for subsequent hosts */
> } while (cp != sdup);
>
> On Mon, 21 Dec 2020, Theo Buehler wrote:
>
> > Not sure if you saw that. Seems to be a logic error due to the fact that
> > parse_ssh_uri() has three possible return values (-1, 0, 1), not 2.
> > Full original report is here:
> >
> > https://marc.info/?l=openbsd-bugs&m=160844761615469&w=2
> >
> > - Forwarded message from Theo Buehler -
> >
> > Date: Sun, 20 Dec 2020 14:18:02 +0100
> > From: Theo Buehler
> > To: Raf Czlonka
> > Cc: bugs@openbsd.org
> > Subject: Re: ssh_config(5) ProxyJump option not working in the latest
> > snapshot
> >
> > > I can see that there's been a number of changes committed to OpenSSH
> > > recently[0] so, unless there's a snapshot-only change, this is most
> > > likely related.
> >
> > Reverting this part of the change in readconf.c r1.344 "fixes" it for me.
> > The issue I run into with 'ssh -J host1 host2' is that parse_ssh_uri()
> > returns 1, in which case there no longer is a fallback to
> > parse_user_host_port(), so options->jump_host remains unset and the
> > "Setting implicit ProxyCommand from ProxyJump" path is no longer taken
> > in main().
> >
> > Index: readconf.c
> > ===
> > RCS file: /cvs/src/usr.bin/ssh/readconf.c,v
> > retrieving revision 1.344
> > diff -u -p -r1.344 readconf.c
> > --- readconf.c 17 Dec 2020 23:10:27 - 1.344
> > +++ readconf.c 20 Dec 2020 11:49:16 -
> > @@ -2778,12 +2778,12 @@ parse_jump(const char *s, Options *o, in
> >
> > if (first) {
> > /* First argument and configuration is active */
> > - if (parse_ssh_uri(cp, &user, &host, &port) == -1 &&
> > + if (parse_ssh_uri(cp, &user, &host, &port) == -1 ||
> > parse_user_host_port(cp, &user, &host, &port) != 0)
> > goto out;
> > } else {
> > /* Subsequent argument or inactive configuration */
> > - if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 &&
> > + if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 ||
> > parse_user_host_port(cp, NULL, NULL, NULL) != 0)
> > goto out;
> > }
> >
> >
> > - End forwarded message -
> >
Re: ssh_config(5) ProxyJump option not working in the latest snapshot
> I can see that there's been a number of changes committed to OpenSSH
> recently[0] so, unless there's a snapshot-only change, this is most
> likely related.
Reverting this part of the change in readconf.c r1.344 "fixes" it for me.
The issue I run into with 'ssh -J host1 host2' is that parse_ssh_uri()
returns 1, in which case there no longer is a fallback to
parse_user_host_port(), so options->jump_host remains unset and the
"Setting implicit ProxyCommand from ProxyJump" path is no longer taken
in main().
Index: readconf.c
===
RCS file: /cvs/src/usr.bin/ssh/readconf.c,v
retrieving revision 1.344
diff -u -p -r1.344 readconf.c
--- readconf.c 17 Dec 2020 23:10:27 - 1.344
+++ readconf.c 20 Dec 2020 11:49:16 -
@@ -2778,12 +2778,12 @@ parse_jump(const char *s, Options *o, in
if (first) {
/* First argument and configuration is active */
- if (parse_ssh_uri(cp, &user, &host, &port) == -1 &&
+ if (parse_ssh_uri(cp, &user, &host, &port) == -1 ||
parse_user_host_port(cp, &user, &host, &port) != 0)
goto out;
} else {
/* Subsequent argument or inactive configuration */
- if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 &&
+ if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 ||
parse_user_host_port(cp, NULL, NULL, NULL) != 0)
goto out;
}
Re: bug in ASN1_time_parse(3)
On Thu, Dec 10, 2020 at 09:51:49PM +0100, Olivier Taïbi wrote:
> I think there is a bug in ASN1_time_parse(3): if tm is not NULL then it
> is not zero'd before parsing and the year value is added instead of set.
Thanks!
While your observation is correct, your proposed fix will break parsing
GeneralizedTimes: The GENTIME_LENGTH case falls through to the
UTCTIME_LENGTH case, and your diff will end up zeroing the centuries
that were set for GeneralizedTimes.
Probably better to do the zeroing unconditionally to be on the safe side.
Fortunately, most callers that do not initialize the tm they pass in
use the V_ASN1_GENERALIZED_TIME mode which must take the GENTIME_LENGTH
branch of the switch (or they would error out), so it should not be a
big problem.
The only exception I found is ASN1_UTCTIME_cmp_time_t() which is
practically unused.
> diff --git a/lib/libcrypto/asn1/a_time_tm.c b/lib/libcrypto/asn1/a_time_tm.c
> index b6e22cbd27b..a841f32a856 100644
> --- a/lib/libcrypto/asn1/a_time_tm.c
> +++ b/lib/libcrypto/asn1/a_time_tm.c
> @@ -196,7 +196,7 @@ ASN1_time_parse(const char *bytes, size_t len, struct tm
> *tm, int mode)
> return (-1);
> type = V_ASN1_UTCTIME;
> }
> - lt->tm_year += ATOI2(p);/* yy */
> + lt->tm_year = ATOI2(p); /* yy */
> if (type == V_ASN1_UTCTIME) {
> if (lt->tm_year < 50)
> lt->tm_year += 100;
>
Index: asn1/a_time_tm.c
===
RCS file: /cvs/src/lib/libcrypto/asn1/a_time_tm.c,v
retrieving revision 1.15
diff -u -p -r1.15 a_time_tm.c
--- asn1/a_time_tm.c25 Apr 2018 11:48:21 - 1.15
+++ asn1/a_time_tm.c10 Dec 2020 21:26:07 -
@@ -163,10 +163,9 @@ ASN1_time_parse(const char *bytes, size_
return (-1);
lt = tm;
- if (lt == NULL) {
- memset(
Re: nginx on current implicitly enables TLS 1.3 (with only "ssl_protocols TLSv1.2; " in nginx.conf config)
On Tue, Dec 01, 2020 at 12:31:19PM +0100, Andreas Bartelt wrote: > Hi, > > I think I've found a bug in current (snapshot from today) with regard to > nginx from ports, LibreSSL and TLS 1.3 which is implicitly enabled even if > configured otherwise. > > From nginx.conf: > ssl_protocols TLSv1.2; > Expected behavior: only enables TLS 1.2 > Observed behavior on current: enables TLS 1.2 and TLS 1.3 > > See also my bug report at nginx mailing list: > https://marc.info/?t=16066620793&r=1&w=2 > > Is there something wrong or missing on the LibreSSL side which triggers this > bug? I think this is the consequence of this change to the ports Makefile https://cvsweb.openbsd.org/ports/www/nginx/Makefile#rev1.146 It added -DTLS1_3_VERSION=0x0304 to CFLAGS to work around the fact that LibreSSL deliberately does not expose that yet. This way, 1.3 is enabled and used. Removing that change would again disable 1.3 entirely. An alternative would be to add -DSSL_OP_NO_TLSv1_3=0x2000L to CFLAGS which I would expect to make your config to work as desired. Adding TLS1_3_VERSION results in nginx setting the max_proto_version to TLSv1.3 and without SSL_OP_NO_TLSv1_3, I think it's no longer possible to disable TLSv1.3. Out of curiosity: why do you want to enable TLSv1.2 only? > > Best regards > Andreas >
Re: apu4 fatal protection fault in supervisor mode [Was: apu4 kernel panic]
On Sun, Nov 29, 2020 at 11:22:06AM +, Stuart Henderson wrote: > I have now seen mine crash with just the base "on by default" daemons, > one incoming ssh connection, top, and dhclient running. > > I'm going to try bisecting old kernels to see if I can figure out when > it was introduced. > > It might also be interesting to try GENERIC rather than GENERIC.MP. > Thanks for digging into this. Your APU seems much worse off than mine, which takes a few weeks before crashing these days, so it's not much use for bisecting. Just a few data points that may help, assuming we see the same thing. I had been running the firwmare 4.10.0.3 for more than a year with seemingly no issues, but I updated to 4.12.0.6 early November. My snapshot updates prior to running into crashes were Jul 7 -> Aug 21 -> Sep 21. The first crash I had was with the Sep 21 snapshot after a bit more than a week uptime. With early October snapshots it got particularly bad with crashes almost daily, that's when I reported. The first snap I saw crashing when going back and forth was from Sep 5. Assuming you see the same thing as me, this would likely make the window for bisecting into Jul 7 <-> Sep 5. I always ran GENERIC.MP.
Re: apu2: kernel protection fault trap, code=0
Just happened again. This time without sshd involvement. Any ideas what
I could try or should do to narrow this down? Otherwise I'll downgrade
to a snap before k2k20 to see whether that makes the machine stabler.
ddb{0}> bt
mi_switch() at mi_switch+0x26f
uvm_pagezero_thread(800093c8) at uvm_pagezero_thread+0x68
end trace frame: 0x0, count: -2
ddb{0}> mach ddbcpu 1
Stopped at x86_ipi_db+0x12:leave
ddb{1}> bt
x86_ipi_db(80001fa78ff0) 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+0x11f
sched_idle(80001fa78ff0) at sched_idle+0x27e
end trace frame: 0x0, count: -5
ddb{1}> mach ddbcpu 2
Stopped at x86_ipi_db+0x12:leave
ddb{2}> bt
x86_ipi_db(80001fa81ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
__mp_lock(8219da64) at __mp_lock+0x72
wakeup_n(8219d60c,) at wakeup_n+0x2d
uvm_pmr_freepages(fd800395fa80,1) at uvm_pmr_freepages+0x1f4
pmap_do_remove(fd8077577708,e4d53ec000,e4d53ed000,0) at pmap_do_remove+0x41
3
uvm_unmap_remove(fd8060a79cd0,e4d53ec000,e4d53ed000,80001fd37cd8,0,1) a
t uvm_unmap_remove+0x22b
sys_munmap(80001fca82a0,80001fd37d40,80001fd37da0) at sys_munmap+0x
ff
syscall(80001fd37e10) at syscall+0x389
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7e51d0, count: -11
ddb{2}> mach ddbcpu 3
Stopped at x86_ipi_db+0x12:leave
ddb{3}> bt
x86_ipi_db(80001fa8aff0) 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+0x11f
sched_idle(80001fa8aff0) at sched_idle+0x27e
end trace frame: 0x0, count: -5
ddb{3}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
2110 402557 69465 0 7 0x2sshd
54617 34903 77233 1001 30x90 selectsshd
77233 448945 69465 0 30x92 poll sshd
45851 338514 1 0 30x100083 ttyin getty
88994 13624 1 0 30x100098 poll cron
83154 480943 1 0 30x80 kqreadapmd
37544 150086 88351 95 30x100092 kqreadsmtpd
16250 510079 88351103 30x100092 kqreadsmtpd
10620 431313 88351 95 30x100092 kqreadsmtpd
99695 239522 88351 95 30x100092 kqreadsmtpd
2672 223243 88351 95 30x100092 kqreadsmtpd
98858 407878 88351 95 30x100092 kqreadsmtpd
88351 501 1 0 30x100080 kqreadsmtpd
3874 281143 1 77 30x100090 poll dhcpd
69465 402905 1 0 30x80 selectsshd
53975 211675 1 0 30x100080 poll ntpd
34811 343278 65264 83 30x100092 poll ntpd
65264 294362 1 83 30x100092 poll ntpd
76552 347729 1 53 30x90 kqreadunbound
20270 495567 77850 74 30x100092 bpf pflogd
77850 322700 1 0 30x80 netio pflogd
42902 13995 9120 73 30x100090 kqreadsyslogd
9120 384777 1 0 30x100082 netio syslogd
63653 414020 1 77 30x100090 poll dhclient
15130 233569 1 0 30x80 poll dhclient
39265 122806 26444115 30x100092 kqreadslaacd
71937 438037 26444115 30x100092 kqreadslaacd
26444 127118 1 0 30x100080 kqreadslaacd
27598 371963 0 0 3 0x14200 bored smr
53953 323249 0 0 7 0x14200zerothread
2955 520496 0 0 3 0x14200 aiodoned aiodoned
59963 311164 0 0 3 0x14200 syncerupdate
78206 49265 0 0 3 0x14200 cleaner cleaner
26063 461537 0 0 3 0x14200 reaperreaper
2963 150166 0 0 3 0x14200 pgdaemon pagedaemon
38882 92867 0 0 3 0x14200 bored crynlk
16443 512417 0 0 3 0x14200 bored crypto
63884 223587 0 0 3 0x14200 bored sensors
52209 152850 0 0 3 0x14200 mmctsksdmmc0
76525 379022 0 0 3 0x14200 usbtskusbtask
31703 337384 0 0 3 0x14200 usbatsk usbatsk
89586 431518 0 0 3 0x40014200 acpi0 acpi0
*55880 44355 0 0 7 0x40014200idle3
8698 467962 0 0 3 0x40014200idle2
899543892 0 0 7 0x40014200idle1
87616 511496 0 0 3 0x14200 bored softnet
9968 159402 0 0 3 0x14200 bored systqmp
55879 267484 0 0 3
Re: sysupgrade after upgrade shuts down VM
On Thu, Sep 24, 2020 at 09:15:20AM +0200, Florian Obser wrote: > Hi Mischa, > > On Thu, Sep 24, 2020 at 08:52:55AM +0200, Mischa wrote: > > Hi All, > > > > With the last couple of -current updates I noticed a VM doesn’t come back > > after running sysupgrade, which it used to do. > > it's very unlikely that this is a sysupgrade problem. > More likely something in the kernel changed (vm or hypervisor). > FWIW: I cannot reproduce this on a kernel built from source on Mon 21 and the latest vmd (with agentx support backed out). I upgraded a fully patched 6.7-stable VM to the following snapshots https://ftp.hostserver.de/archive/2020-09-01-0105/ https://ftp.hostserver.de/archive/2020-09-07-0105/ https://ftp.hostserver.de/archive/2020-09-14-0105/ https://ftp.hostserver.de/archive/2020-09-19-0105/ https://ftp.hostserver.de/archive/2020-09-23-0105/ https://ftp.hostserver.de/archive/2020-09-24-0105/ using sysupgrade -s and they all rebooted as expected. OpenBSD 6.8-beta (GENERIC.MP) #54: Mon Sep 21 12:31:09 CEST 2020 t...@hiro.theobuehler.org:/sys/arch/amd64/compile/GENERIC.MP real mem = 16806064128 (16027MB) avail mem = 16281649152 (15527MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xba6dd000 (63 entries) bios0: vendor LENOVO version "N20ET55W (1.40 )" date 06/01/2020 bios0: LENOVO 20KF001HMZ acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.83 MHz, 06-8e-0a 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: 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 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) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a 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: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,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 cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,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 cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcf
Re: bug report: ksh: incorrect "$@" handling with null (empty) IFS
On Sat, Sep 12, 2020 at 06:58:47AM +, avih wrote:
> Note: originally posted to misc@ and was requested by Rafael Possamai
> to post to bugs@ ( https://marc.info/?l=openbsd-misc&m=159986950219082&w=4 )
>
> Note: I'm not following this list, nor using OpenBSD regularly.
> Please CC me for any comment.
>
>
> uname -a (running inside virtual box):
> OpenBSD foo.my.domain 6.7 GENERIC.MP#182 amd64
>
>
> Run the following command:
> /bin/sh -c 'IFS=; args() { printf "[%s]" "$@"; }; args 1 2 3'
>
> Expected result:
> [1][2][3]
>
> Actual result:
> [1 2 3]
>
>
> It seems that "$@" in [k]sh with IFS as null combines the arguments
> as if it was "$*" when IFS is unset or begins with space, while in
> fact the main difference between (quoted) "$@" and $* is that the
> former should retain the individual arguments regardless of IFS,
> while $* combines them with the first char of IFS (or space if IFS
> is unset).
Thanks for the report. This is known and a patch by Martijn Dekker from
2016 exists, but it never made it into the tree despite being tested in
snapshots for a while. I don't know/remember the reason - I think it
just stalled.
Below is the final version of the patch, rebased against -current.
Here's Martijn's original email
(https://marc.info/?l=openbsd-tech&m=145704771329065&w=2)
> Hi all,
>
> I'm new here and posting at Theo de Raadt's request. I'm developing a
> general-purpose cross-platform library for the POSIX shell language and
> in the process I encounter lots of bugs in various shells. I will be
> posting here a few times with some patches and bug reports against
> OpenBSD ksh. Here is the first.
>
> One uncommon but useful way of writing shell scripts is to start off by
> disabling field/word splitting (IFS='') and pathname expansion/globbing
> (set -f), re-enabling either or both only for the commands that need
> them, e.g. within a subshell. This helps avoid a lot of snags with field
> splitting and globbing if you forget to quote a variable somewhere,
> adding to the general robustness of a script. (In fact it eliminates
> much of the need to quote variable/parameter expansions, with empty
> removal remaining as the only issue.)
>
> Unfortunately OpenBSD ksh (like all pdksh variants except mksh) has a
> POSIX compliance bug that is a show stopper for this approach: "$@" does
> not generate words (arguments) if IFS is empty. As a result, the
> separate command arguments represented by "$@" become a single argument.
> So passing on an intact set of positional parameters to a command or
> function is impossible with field splitting disabled.
>
> Of course this is illogical: the quoted special parameter "$@" generates
> zero or more words, it doesn't split any words, so the contents of IFS
> (or lack thereof) should be neither here nor there. It's old ksh88
> behaviour copied by the original pdksh, but it violates POSIX and it has
> been fixed many years ago in ksh93 and all other POSIX shells.
>
> As I mentioned, mksh fixed it too. I seem to have successfully
> backported the mksh fix to OpenBSD ksh. The fix is not too complicated,
> but not trivial either, so the MirOS licence would have applied, which I
> understand may not be acceptable here.
>
> So I emailed the author, Thorsten Glaser, explaining the situation.
> After some amicable discussion, he granted me a personal licence for
> this particular patch, authorising me to sublicence it in whatever way I
> please. (Proof is available on request.)
>
> Under that authorisation, I hereby dedicate the attached patch to the
> public domain. In localities where that is not valid, I hereby grant
> unlimited permission to use, copy, modify and distribute it, to the
> extent permitted by law.
>
> So this patch makes quoted "$@" act according to the standard even when
> IFS is empty. Quoted "$*" is unchanged. For the unspecified (not
> standardised) cases of unquoted $@ and $*, this patch makes ksh act like
> AT&T ksh93, bash, zsh and (d)ash, which seems safest from a
> compatibility point of view.
>
> The patch is against the OpenBSD 5.8-RELEASE sources. I hope that's ok.
> I also added an update for the relevant regression test.
>
> Thanks,
>
> - M.
Index: bin/ksh/eval.c
===
RCS file: /var/cvs/src/bin/ksh/eval.c,v
retrieving revision 1.65
diff -u -p -r1.65 eval.c
--- bin/ksh/eval.c 28 Jun 2019 13:34:59 - 1.65
+++ bin/ksh/eval.c 12 Sep 2020 08:29:56 -
@@ -47,6 +47,8 @@ typedef struct Expand {
#define IFS_WORD 0 /* word has chars (or quotes) */
#define IFS_WS 1 /* have seen IFS white-space */
#define IFS_NWS2 /* have seen IFS non-white-space */
+#define IFS_IWS3 /* beginning of word, ignore IFS
white-space */
+#define IFS_QUOTE 4 /* beg.w/quote, becomes IFS_WORD unless "$@" */
static int varsub(Expand *, char *, char *, int *, int *);
static int
Re: LibreSSL errors with 'ST_CONNECT:length mismatch' and 'ST_CONNECT:tlsv1 alert decode error'
On Sun, Aug 09, 2020 at 07:12:11PM +, Mikolaj Kucharski wrote: > On Mon, Aug 03, 2020 at 12:47:22PM +0200, Theo Buehler wrote: > > > > I will commit a cleaned-up version of that diff soon. > > Thanks. It works now with: > > OpenBSD 6.7-current (GENERIC.MP) #13: Sat Aug 8 01:11:49 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Oh, yes, I forgot to notify you. Specifically, it was this commit that fixed this problem: https://cvsweb.openbsd.org/src/lib/libssl/ssl_tlsext.c#rev1.79
Re: LibreSSL errors with 'ST_CONNECT:length mismatch' and 'ST_CONNECT:tlsv1 alert decode error'
On Mon, Aug 03, 2020 at 10:33:40AM +, Mikolaj Kucharski wrote: > Hi, > > I'm unable to openssl s_client, wget, curl or ftp the domain > k8sapi.prod.chorus1.net. Here is example session with ftp command: > > $ ftp -o /dev/null https://k8sapi.prod.chorus1.net/ > Trying 34.102.178.128... > TLS handshake failure: handshake failed: error:1404B09F:SSL > routines:ST_CONNECT:length mismatch > > When I use Firefox, Chromium or gnutls-cli I'm able fetch content behind > the url (JSON with an error, which is expected). Also using eopenssl > and eopenssl11 works with mentioned domain. Thanks for the report. This is the same issue as discussed here: https://marc.info/?l=libressl&m=159320344528945&w=2 <<< TLS 1.3 Handshake [length 0069], CertificateRequest 0d 00 00 65 00 00 62 00 05 00 00 00 12 00 00 00 0d 00 1a 00 18 08 04 04 03 08 07 08 05 08 06 04 01 05 01 06 01 05 03 06 03 02 01 02 03 00 2f 00 38 00 36 00 17 30 15 31 13 30 11 06 03 55 04 03 13 0a 6b 75 62 65 72 6e 65 74 65 73 00 1b 30 19 31 17 30 15 06 03 55 04 03 13 0e 66 72 6f 6e 74 2d 70 72 6f 78 79 2d 63 61 TLS client extension "status request" (id=5), len=0 This diff should fix the problem: https://marc.info/?l=libressl&m=159601181028142&w=2 I will commit a cleaned-up version of that diff soon.
Re: mg: segmentation fault when using query-replace-regexp
> Thanks very much for your review. What you point out above is certainly
> true, but
> then it is consistent with the current behaviour when searching for the
> beginning-of-line ('^') anchor and the point at the beginning of a
> non-empty line. In that case, the point does not move.
This sounds like a convincing argument for my first version to me, so I
have committed that. Thanks a lot to both of you.
Re: mg: segmentation fault when using query-replace-regexp
> Hmm. I get neither a seg fault nor a loop on my amd64 Lenove E595. The
> cursor moves to different spots in X/i3 xterm vs console and in either
> case doesn't do any replacement.
I can reproduce both behaviors reliably as follows both on console and
in xterm.
$ echo 'a\n\n\nb' > /tmp/test
$ mg /tmp/test
Don't move the cursor, just do the following (what is between quotation
marks is what you are supposed to type, the other bits are prompts):
"M-x query-replace-regexp"
RE Query replace: "^"
Query replace ^ with: "a"
Query replacing ^ with a: ""
replace, [.] rep-end, don't, [!] repl rest quit "!"
After hitting "!" here, it will enter a loop and eventually print
panic: Out of memory in undo code (record)
and exit.
If I do the exact same dance after moving the cursor to the second
(empty) line, it will segfault.
With the diff below (which is what I understood to be Hiltjo's
suggestion), I get more or less what I would expect. I think it should
not replace the empty line after the last newline...
So I think both diffs are not quite right :)
Index: line.c
===
RCS file: /var/cvs/src/usr.bin/mg/line.c,v
retrieving revision 1.61
diff -u -p -r1.61 line.c
--- line.c 29 Aug 2018 07:50:16 - 1.61
+++ line.c 21 Jul 2020 14:58:49 -
@@ -556,6 +556,8 @@ lreplace(RSIZE plen, char *st)
goto done;
lp = curwp->w_dotp;
+ if (ltext(lp) == NULL)
+ goto done;
doto = curwp->w_doto;
n = plen;
Index: re_search.c
===
RCS file: /var/cvs/src/usr.bin/mg/re_search.c,v
retrieving revision 1.34
diff -u -p -r1.34 re_search.c
--- re_search.c 9 Jul 2020 10:42:24 - 1.34
+++ re_search.c 21 Jul 2020 15:00:08 -
@@ -308,7 +308,7 @@ re_doreplace(RSIZE plen, char *st)
static int
re_forwsrch(void)
{
- int tbo, tdotline, error;
+ int re_flags, tbo, tdotline, error;
struct line *clp;
clp = curwp->w_dotp;
@@ -330,10 +330,13 @@ re_forwsrch(void)
* always makes the last line empty so this is good.
*/
while (clp != (curbp->b_headp)) {
+ re_flags = REG_STARTEND;
+ if (tbo != 0)
+ re_flags |= REG_NOTBOL;
regex_match[0].rm_so = tbo;
regex_match[0].rm_eo = llength(clp);
error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
- RE_NMATCH, regex_match, REG_STARTEND);
+ RE_NMATCH, regex_match, re_flags);
if (error != 0) {
clp = lforw(clp);
tdotline++;
Re: mg: segmentation fault when using query-replace-regexp
On Mon, Jul 13, 2020 at 03:47:13PM +0100, Mark Willson wrote:
> Folks,
>
> The segmentation fault occurs when the string to replace is just the
> "^" anchor (beginning-of-line) and the point is on an empty line.
> Issue occurs on a -current system dated July 11th. (dmesg below).
>
> The following patch prevents the segmentation fault:
Nice. Thanks for the patches and the analysis. I'd suggest the following
variant (only stylistic changes). I'm willing to commit this, but I
will need at least some positive feedback from mg users.
Index: line.c
===
RCS file: /var/cvs/src/usr.bin/mg/line.c,v
retrieving revision 1.61
diff -u -p -r1.61 line.c
--- line.c 29 Aug 2018 07:50:16 - 1.61
+++ line.c 13 Jul 2020 16:00:52 -
@@ -556,6 +556,8 @@ lreplace(RSIZE plen, char *st)
goto done;
lp = curwp->w_dotp;
+ if (ltext(lp) == NULL)
+ goto done;
doto = curwp->w_doto;
n = plen;
Index: re_search.c
===
RCS file: /var/cvs/src/usr.bin/mg/re_search.c,v
retrieving revision 1.34
diff -u -p -r1.34 re_search.c
--- re_search.c 9 Jul 2020 10:42:24 - 1.34
+++ re_search.c 13 Jul 2020 16:17:07 -
@@ -308,7 +308,7 @@ re_doreplace(RSIZE plen, char *st)
static int
re_forwsrch(void)
{
- int tbo, tdotline, error;
+ int re_flags, tbo, tdotline, error;
struct line *clp;
clp = curwp->w_dotp;
@@ -318,9 +318,10 @@ re_forwsrch(void)
if (tbo == clp->l_used)
/*
* Don't start matching past end of line -- must move to
-* beginning of next line, unless at end of file.
+* beginning of next line, unless line is empty or at
+* end of file.
*/
- if (clp != curbp->b_headp) {
+ if (clp != curbp->b_headp && llength(clp) != 0) {
clp = lforw(clp);
tdotline++;
tbo = 0;
@@ -330,10 +331,13 @@ re_forwsrch(void)
* always makes the last line empty so this is good.
*/
while (clp != (curbp->b_headp)) {
+ re_flags = REG_STARTEND;
+ if (tbo != 0)
+ re_flags |= REG_NOTBOL;
regex_match[0].rm_so = tbo;
regex_match[0].rm_eo = llength(clp);
error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
- RE_NMATCH, regex_match, REG_STARTEND);
+ RE_NMATCH, regex_match, re_flags);
if (error != 0) {
clp = lforw(clp);
tdotline++;
Re: kernel panic when invoking cu
On Mon, Jul 20, 2020 at 09:08:15AM +0200, Peter J. Philipp wrote: > Hi, > > I have a screenshot of a kernel panic when I typed cu in a snapshot that > I just downloaded. > > The panic string is: > > panic: kernel diagnositc assertion "p->p_wchan == NULL" failed: file > "/usr/src/sys/kern/kern_sched.c", line 353 > > Unfortunately I don't have very much time today so that's all I'm going to > type out. Here is the screenshot: > > https://centroid.eu/private/kernel-panic20200720.jpg Thanks. No need to transcribe more. jcs reported the same problem: https://marc.info/?l=openbsd-bugs&m=159518346507098&w=2 A fix is under discussion.
Re: 100% reproducible panic on wg-quick up wg0 unless pf is disabled
> login: panic: kernel diagnostic assertion "m->m_pkthdr.pf.statekey == NULL" > failed: file "/usr/src/sys/net/pf.c", line 7455 Ran into this as well. Should be fixed in the next snap. https://marc.info/?l=openbsd-tech&m=159462210226639&w=2 Index: if_wg.c === RCS file: /var/cvs/src/sys/net/if_wg.c,v retrieving revision 1.10 retrieving revision 1.11 diff -u -p -r1.10 -r1.11 --- if_wg.c 12 Jul 2020 18:54:23 - 1.10 +++ if_wg.c 13 Jul 2020 08:29:34 - 1.11 @@ -1,4 +1,4 @@ -/* $OpenBSD: if_wg.c,v 1.10 2020/07/12 18:54:23 kn Exp $ */ +/* $OpenBSD: if_wg.c,v 1.11 2020/07/13 08:29:34 tb Exp $ */ /* * Copyright (C) 2015-2020 Jason A. Donenfeld . All Rights Reserved. @@ -18,6 +18,7 @@ */ #include "bpfilter.h" +#include "pf.h" #include #include
Re: mg: crash on re-search with a file containing an empty line
> Can this patch get committed in the current form?
I don't mind committing either version of the patch.
Unless I hear objections, I'm going to commit the patch below soon.
Index: re_search.c
===
RCS file: /var/cvs/src/usr.bin/mg/re_search.c,v
retrieving revision 1.33
diff -u -p -r1.33 re_search.c
--- re_search.c 6 Aug 2017 04:39:45 - 1.33
+++ re_search.c 8 Jul 2020 13:00:40 -
@@ -332,8 +332,8 @@ re_forwsrch(void)
while (clp != (curbp->b_headp)) {
regex_match[0].rm_so = tbo;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
if (error != 0) {
clp = lforw(clp);
tdotline++;
@@ -389,8 +389,9 @@ re_backsrch(void)
* do this character-by-character after the first match since
* POSIX regexps don't give you a way to do reverse matches.
*/
- while (!regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND) && regex_match[0].rm_so < tbo) {
+ while (!regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND) &&
+ regex_match[0].rm_so <= tbo) {
memcpy(&lastmatch, ®ex_match[0], sizeof(regmatch_t));
regex_match[0].rm_so++;
regex_match[0].rm_eo = llength(clp);
@@ -538,8 +539,8 @@ killmatches(int cond)
/* see if line matches */
regex_match[0].rm_so = 0;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
/* Delete line when appropriate */
if ((cond == FALSE && error) || (cond == TRUE && !error)) {
@@ -613,8 +614,8 @@ countmatches(int cond)
/* see if line matches */
regex_match[0].rm_so = 0;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
/* Count line when appropriate */
if ((cond == FALSE && error) || (cond == TRUE && !error))
Re: mg: crash on re-search with a file containing an empty line
On Mon, Jun 29, 2020 at 01:17:56PM +0200, Hiltjo Posthuma wrote:
> Hi,
>
> Thanks for looking into it, it looks better.
>
> With this patch I noticed re_backsrch() does not work fully correct yet.
>
> I think the line:
>
> > + regex_match[0].rm_so < tbo) {
>
> should be:
>
> > + regex_match[0].rm_so <= tbo) {
>
> because tbo is already adjusted at the top of the function re_backsrch().
>
> With this line change searching backwards with "^$" finds a result.
Indeed, thank you. I must have messed up my testing...
However, changing < to <= changes the behavior of all backward regex
searches.
Type "aaa" on a line and leave the cursor after the third a on the same
line. If you re-search-backward for "a" on -current, the cursor is
placed on the middle "a" (different from emacs which places the cursor
on the third a). If you then re-search-backward for "aa", the search
fails (as it does on emacs also).
With your suggested change (as in the diff below), the cursor is placed
on the third "a" as in emacs. However, with the cursor on the middle a
re-search-backward for "aa" now succeeds (different from emacs).
I'm not sure this is desirable. I'm no user of either emacs or mg, so I
think more thought and care is needed but this will have to be done by
someone else...
Index: re_search.c
===
RCS file: /var/cvs/src/usr.bin/mg/re_search.c,v
retrieving revision 1.33
diff -u -p -r1.33 re_search.c
--- re_search.c 6 Aug 2017 04:39:45 - 1.33
+++ re_search.c 29 Jun 2020 11:26:07 -
@@ -332,8 +332,8 @@ re_forwsrch(void)
while (clp != (curbp->b_headp)) {
regex_match[0].rm_so = tbo;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
if (error != 0) {
clp = lforw(clp);
tdotline++;
@@ -389,8 +389,9 @@ re_backsrch(void)
* do this character-by-character after the first match since
* POSIX regexps don't give you a way to do reverse matches.
*/
- while (!regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND) && regex_match[0].rm_so < tbo) {
+ while (!regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND) &&
+ regex_match[0].rm_so <= tbo) {
memcpy(&lastmatch, ®ex_match[0], sizeof(regmatch_t));
regex_match[0].rm_so++;
regex_match[0].rm_eo = llength(clp);
@@ -538,8 +539,8 @@ killmatches(int cond)
/* see if line matches */
regex_match[0].rm_so = 0;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
/* Delete line when appropriate */
if ((cond == FALSE && error) || (cond == TRUE && !error)) {
@@ -613,8 +614,8 @@ countmatches(int cond)
/* see if line matches */
regex_match[0].rm_so = 0;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
/* Count line when appropriate */
if ((cond == FALSE && error) || (cond == TRUE && !error))
Re: mg: crash on re-search with a file containing an empty line
On Sun, Jun 28, 2020 at 06:58:22PM +0200, Hiltjo Posthuma wrote:
> Hi,
>
> I noticed a bug in mg with regex search.
>
> A way to reproduce the issue:
>
> * Create a file with atleast one empty line, for example:
>
> "a
>
> b"
>
> * Move the cursor after "a".
> * M-x re-search-forward, use a term like "^$".
>
> Result: Segmentation fault (core dumped)
>
> Reproduced on -current on amd64.
That's because regexec() doesn't like to be passed NULL for its string
argument. This happens for an empty line as ltext(clp) is NULL in that
case.
Diff below is a quick workaround for this problem and marks the places
where similar crashes can be produced. Perhaps it would be better to
check for llength(clp) instead of ltext(clp)?
Index: re_search.c
===
RCS file: /var/cvs/src/usr.bin/mg/re_search.c,v
retrieving revision 1.33
diff -u -p -r1.33 re_search.c
--- re_search.c 6 Aug 2017 04:39:45 - 1.33
+++ re_search.c 28 Jun 2020 18:05:00 -
@@ -332,8 +332,8 @@ re_forwsrch(void)
while (clp != (curbp->b_headp)) {
regex_match[0].rm_so = tbo;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
if (error != 0) {
clp = lforw(clp);
tdotline++;
@@ -389,8 +389,9 @@ re_backsrch(void)
* do this character-by-character after the first match since
* POSIX regexps don't give you a way to do reverse matches.
*/
- while (!regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND) && regex_match[0].rm_so < tbo) {
+ while (!regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND) &&
+ regex_match[0].rm_so < tbo) {
memcpy(&lastmatch, ®ex_match[0], sizeof(regmatch_t));
regex_match[0].rm_so++;
regex_match[0].rm_eo = llength(clp);
@@ -538,8 +539,8 @@ killmatches(int cond)
/* see if line matches */
regex_match[0].rm_so = 0;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
/* Delete line when appropriate */
if ((cond == FALSE && error) || (cond == TRUE && !error)) {
@@ -613,8 +614,8 @@ countmatches(int cond)
/* see if line matches */
regex_match[0].rm_so = 0;
regex_match[0].rm_eo = llength(clp);
- error = regexec(®ex_buff, ltext(clp), RE_NMATCH, regex_match,
- REG_STARTEND);
+ error = regexec(®ex_buff, ltext(clp) ? ltext(clp) : "",
+ RE_NMATCH, regex_match, REG_STARTEND);
/* Count line when appropriate */
if ((cond == FALSE && error) || (cond == TRUE && !error))
Re: iwm: Intel wireless AC 7265 fails to connect to specific AP ("association failed (status 10)"; worked in 6.7-current #196)
On Tue, May 19, 2020 at 09:12:29PM -0400, Demi M. Obenour wrote: > On 2020-05-19 16:30, Theo Buehler wrote: > > Hi, > > > > Thanks for the detailed report. > > > >>iwm0: sending assoc_req to 18:e8:29:11:2b:2f on channel 6 mode 11g > >>iwm0: association failed (status 10) for 18:e8:29:11:2b:2f > >>iwm0: association timed out for 18:e8:29:11:2b:2f > > > > I saw the same problem on my access point. This is fixed in -current: > > https://cvsweb.openbsd.org/src/sys/net80211/ieee80211_output.c#rev1.131 > > > > > Would it be possible to get an errata patch for this, so that -stable > users can get it fixed? No, it's not possible since the breakage was 6.7-current only :) Look at the link and the commit message: you can see that it reverts a commit from ~10 hours earlier.
Re: iwm: Intel wireless AC 7265 fails to connect to specific AP ("association failed (status 10)"; worked in 6.7-current #196)
Hi, Thanks for the detailed report. > iwm0: sending assoc_req to 18:e8:29:11:2b:2f on channel 6 mode 11g > iwm0: association failed (status 10) for 18:e8:29:11:2b:2f > iwm0: association timed out for 18:e8:29:11:2b:2f I saw the same problem on my access point. This is fixed in -current: https://cvsweb.openbsd.org/src/sys/net80211/ieee80211_output.c#rev1.131
Re: security and umask
On Mon, May 04, 2020 at 04:23:44PM +0100, Stuart Henderson wrote: > On 2020/05/04 15:01, Doug Moss wrote: > > For OpenBSD 6.6, amd64 > > in the daily script to check security: > > /usr/libexec/security > > > > at line 248 for checking if the umask is set: > > my @list = qw(/etc/profile /root/.profile); > > > > shouldn't that be instead: > > my @list = qw(/.profile /root/.profile); > > > > I think /etc/profile does not exist, and /.profile is the default one. > > > > I'm not sure in which situations /.profile would be used, but /etc/profile > is definitely used if it exists. > > ksh documentation says $HOME/.profile and /etc/profile. > Single user mode uses /.profile for shell initialization. init(8) spawns a login shell by prepending '-' to the basename and HOME is unset.
Re: npppd hangs (under load)?
On Wed, Mar 25, 2020 at 01:05:51PM +0100, Marko Cupać wrote: > On 2020-03-24 16:02, Marko Cupać wrote: > > Hi, > > > > I wrote already on @misc, but as I had kernel panic I am reporting it > > here as well. > > > > Recently my npppd server got an increase from ~20 to ~200 concurrent > > PPTP users. It worked fine with same configuration on various hardware > > for 7 years (right now on HPE ProLiant 360 gen9). > > > > Last few days it is very unstable, meaning it works fine for a few > > hours, taking just a fraction of a percent of CPU, but then it quits > > taking new connections and takes 100% of single CPU core. > > Sorry for garbled dmesg output, I have just now noticed it, sending again, > hopefully it will be ok now. > > I'm experimenting with disabling pipex, will report how it goes. Supposedly fixed by this patch (already committed): https://marc.info/?l=openbsd-tech&m=158513109409692&w=2
Re: Errors in X - Build Date Mar 14 2020 01:48:26 UTC
On Sat, Mar 14, 2020 at 02:01:23PM +, Tom Murphy wrote: > Hi, > > I've narrowed it down. > Further testing shows it's not kernel, but Xenocara. If I > install xbase66.tgz from 12th March, it's fine. If I use the > newest snapshot xbase66.tgz, X crashes. There was only one xenocara commit in that window: https://marc.info/?l=openbsd-cvs&m=158413257531932&w=2 I managed to reproduce a cwm crash once while playing around with the set-title option in tmux, but have trouble doing so now. > > Thanks, > Tom >
Re: pkg_add fails with error "TLS connect failure: failed to set session"
On Sat, Feb 08, 2020 at 12:51:24PM +0100, Sven Wolf wrote: > Hi, > > the pkg_add problem with an https installurl is solved (tested with snapshot > #639/2020-02-07). Thanks for letting us know. This issue was first resolved by disabling the TLSv1.3 client last Saturday. A workaround was committed in revision 1.12 of ssl_methods.c: https://cvsweb.openbsd.org/src/lib/libssl/ssl_methods.c The client has since been re-enabled.
Re: execve -1 errno 12 Cannot allocate memory
On Thu, Nov 07, 2019 at 03:10:45PM -0800, Philip Guenther wrote: > On Thu, 7 Nov 2019, Theo Buehler wrote: > > On Thu, Nov 07, 2019 at 03:32:48PM -0700, Theo de Raadt wrote: > > > > kern.version=OpenBSD 6.6-current (GENERIC.MP) #433: Thu Nov 7 10:41:08 > > > > MST 2019 > > > > > > That is too old and does not contain the solution. > > > > I obtained a different binary with the latest sets, but still see the > > same problem. The new binary is available under > > The change is to the C compiler, not the linker. Did you rebuild all the > .o files with an up-to-date clang? Yes. However, I must have confused myself somehow... I downloaded the latest snaps, OpenBSD 6.6-current (GENERIC.MP) #436: Thu Nov 7 14:52:31 MST 2019 with this clang: SHA256 (/usr/bin/clang) = afa90a194296b48c64f01c5547994f774ca18a73503651ca6c33a495e59509c5 The binary (rebuilt with make clean && make DEBUG='-g -O0') can be executed: $ ../bin/lean && echo $? 0 and other tests run as expected. It has a more decently sized random section: OPENBSD_RANDOM 0x01185000 0x01185000 0x01185000 0x7d28 0x7d28 RW 8 It's the same binary I uploaded previously... $ sha256 ../bin/lean SHA256 (../bin/lean) = 9120c128c71e03b9fc560f96277f71ecd0fa7ab8d86874fd85f4bfc95e7e6faf
Re: execve -1 errno 12 Cannot allocate memory
On Thu, Nov 07, 2019 at 03:32:48PM -0700, Theo de Raadt wrote: > > kern.version=OpenBSD 6.6-current (GENERIC.MP) #433: Thu Nov 7 10:41:08 MST > > 2019 > > That is too old and does not contain the solution. > I obtained a different binary with the latest sets, but still see the same problem. The new binary is available under ~tb/lean/lean-new
Re: execve -1 errno 12 Cannot allocate memory
On Thu, Nov 07, 2019 at 11:46:56PM +0200, Theo Buehler wrote: > > Unfortunately, the binary is stripped so there are no symbols for the > > .openbsd.randomdata segment so we can't confirm the cause. > > Sorry about that. A non-stripped binary should be available under > > cvs:~tb/lean/lean-nonstripped > I was told that snaps contain a potential fix for this. Using clang the most recent snapshot (installed via sysupgrade) kern.version=OpenBSD 6.6-current (GENERIC.MP) #433: Thu Nov 7 10:41:08 MST 2019 I get the exact same binary when compiling with -g -O0 cvs$ sha256 lean/lean-new lean/lean-nonstripped SHA256 (lean/lean-new) = 7a8113fd2f480b4b46c530547e86a97ed0b687f9347d81d2f5b0d188bfd92010 SHA256 (lean/lean-nonstripped) = 7a8113fd2f480b4b46c530547e86a97ed0b687f9347d81d2f5b0d188bfd92010 It's getting late here in OTP, I'll happily run further experiments tomorrow.
