no gawking in makesyscalls
I don't think we need to concern ourselves with cross awk compatibility here.
Despite the misleading comment, /usr/bin/awk supports toupper.
Index: makesyscalls.sh
===
RCS file: /home/cvs/src/sys/kern/makesyscalls.sh,v
retrieving revision 1.15
diff -u -p -r1.15 makesyscalls.sh
--- makesyscalls.sh 9 Dec 2021 00:26:10 - 1.15
+++ makesyscalls.sh 1 May 2022 04:45:49 -
@@ -70,28 +70,6 @@ sysent="sysent.switch"
trap "rm $sysdcl $sysprotos $sysent" 0
-# Awk program (must support nawk extensions)
-# Use "awk" at Berkeley, "nawk" or "gawk" elsewhere.
-awk=${AWK:-awk}
-
-# Does this awk have a "toupper" function? (i.e. is it GNU awk)
-isgawk=`$awk 'BEGIN { print toupper("true"); exit; }' 2>/dev/null`
-
-# If this awk does not define "toupper" then define our own.
-if [ "$isgawk" = TRUE ] ; then
- # GNU awk provides it.
- toupper=
-else
- # Provide our own toupper()
- toupper='
-function toupper(str) {
- _toupper_cmd = "echo "str" |tr a-z A-Z"
- _toupper_cmd | getline _toupper_str;
- close(_toupper_cmd);
- return _toupper_str;
-}'
-fi
-
# before handing it off to awk, make a few adjustments:
# (1) insert spaces around {, }, (, ), *, and commas.
# (2) get rid of any and all dollar signs (so that rcs id use safe)
@@ -111,8 +89,7 @@ s/\$//g
2,${
/^#/!s/\([{}()*,]\)/ \1 /g
}
-' < $2 | $awk "
-$toupper
+' < $2 | awk "
BEGIN {
# to allow nested #if/#else/#endif sets
savedepth = 0
Re: Potential NULL dereference id_entry
On Sat, Apr 30, 2022 at 07:54:12PM -0600, Ted Bullock wrote: > in radeondrm_attach_kms:508 could potentially fail and result in a NULL > dereference at line 510. Check this with KASSERT(). This can not happen. drm_pciprobe() uses drm_find_description() if it returned NULL the driver would not match. > > diff 5fbcee9a5968b225053e9e1b0363430e36326626 /usr/src > blob - 94f38e8769827e9c649147689a9ca6f889d1464f > file + sys/dev/pci/drm/radeon/radeon_kms.c > --- sys/dev/pci/drm/radeon/radeon_kms.c > +++ sys/dev/pci/drm/radeon/radeon_kms.c > @@ -507,6 +507,8 @@ radeondrm_attach_kms(struct device *parent, struct dev > > id_entry = drm_find_description(PCI_VENDOR(pa->pa_id), > PCI_PRODUCT(pa->pa_id), radeondrm_pciidlist); > + KASSERT(id_entry != NULL); > + > rdev->flags = id_entry->driver_data; > rdev->family = rdev->flags & RADEON_FAMILY_MASK; > rdev->pc = pa->pa_pc; > > > > -- > Ted Bullock > >
Potential NULL dereference id_entry
in radeondrm_attach_kms:508 could potentially fail and result in a NULL dereference at line 510. Check this with KASSERT(). diff 5fbcee9a5968b225053e9e1b0363430e36326626 /usr/src blob - 94f38e8769827e9c649147689a9ca6f889d1464f file + sys/dev/pci/drm/radeon/radeon_kms.c --- sys/dev/pci/drm/radeon/radeon_kms.c +++ sys/dev/pci/drm/radeon/radeon_kms.c @@ -507,6 +507,8 @@ radeondrm_attach_kms(struct device *parent, struct dev id_entry = drm_find_description(PCI_VENDOR(pa->pa_id), PCI_PRODUCT(pa->pa_id), radeondrm_pciidlist); + KASSERT(id_entry != NULL); + rdev->flags = id_entry->driver_data; rdev->family = rdev->flags & RADEON_FAMILY_MASK; rdev->pc = pa->pa_pc; -- Ted Bullock
remove duplicate fbnode declaration for sparc64
In sys/dev/pci/radeon/radeon_kms.c:505 The *fbnode* variable is defined for sparc64 and macppc, this is is a redefine on sparc64, as it is already defined at sys/arch/sparc64/include/fbvar.h:71 fbnode is an OFW artifact for the default framebuffer pci device. This variable is global on sparc64 and referenced extensively in the tree as a global variable. macppc doesn't have an equivalent header, although it is still global so leave the define for that platform. Tested on sparc64 with sun blade 100 and xvr-100 diff 57f95c2e462c430cf6aaccbcafd3f24106e89e55 5fbcee9a5968b225053e9e1b0363430e36326626 blob - d72d2ce7c6613036a0a10767c4d1d50a8fa026cf blob + 94f38e8769827e9c649147689a9ca6f889d1464f --- sys/dev/pci/drm/radeon/radeon_kms.c +++ sys/dev/pci/drm/radeon/radeon_kms.c @@ -501,7 +501,7 @@ radeondrm_attach_kms(struct device *parent, struct dev pcireg_t addr, mask; int s; -#if defined(__sparc64__) || defined(__macppc__) +#if defined(__macppc__) extern int fbnode; #endif -- Ted Bullock
Re: install btrace scripts
On Sat, Apr 30, 2022 at 02:03:28PM -0600, Theo de Raadt wrote: > >On 2022-04-30, Alexander Bluhm wrote: > >> Hi, > >> > >> Can we install the btrace scripts to /usr/share/btrace/ ? The > >> directory already exists, only the Makefile is not linked to the > >> build. > >> > >> And I would like to use #! to make them executable. > > > >It's weird to have exec files in share? > > yes, it is weird. i am not convinced that btrace is a natural > interpreter, nor that anyone would put this into your $PATH, at > which point you are using an absolute path, and it seems unlikely > anyone would even notice these are executable, so they would the > pattern: > > >I think it's not very hard to type "btrace script" vs script. Now without #! and with man page. Index: share/Makefile === RCS file: /data/mirror/openbsd/cvs/src/share/Makefile,v retrieving revision 1.18 diff -u -p -r1.18 Makefile --- share/Makefile 9 Oct 2014 03:46:15 - 1.18 +++ share/Makefile 30 Apr 2022 19:22:32 - @@ -1,5 +1,5 @@ # $OpenBSD: Makefile,v 1.18 2014/10/09 03:46:15 tedu Exp $ -SUBDIR=dict locale man misc mk snmp tabset termtypes zoneinfo +SUBDIR=btrace dict locale man misc mk snmp tabset termtypes zoneinfo .include Index: share/btrace/kprofile.bt === RCS file: /data/mirror/openbsd/cvs/src/share/btrace/kprofile.bt,v retrieving revision 1.1 diff -u -p -r1.1 kprofile.bt --- share/btrace/kprofile.bt23 Oct 2021 19:37:35 - 1.1 +++ share/btrace/kprofile.bt30 Apr 2022 21:32:03 - @@ -1,3 +1,5 @@ +/* $OpenBSD$ */ + /* * kprofile.bt Kernel profiling (stack sampling) at 100Hz. * Index: share/btrace/runqlat.bt === RCS file: /data/mirror/openbsd/cvs/src/share/btrace/runqlat.bt,v retrieving revision 1.2 diff -u -p -r1.2 runqlat.bt --- share/btrace/runqlat.bt 24 Oct 2021 08:42:38 - 1.2 +++ share/btrace/runqlat.bt 30 Apr 2022 21:32:06 - @@ -1,3 +1,5 @@ +/* $OpenBSD$ */ + /* * runqlat.bt Measure run queue latency (aka scheduler latency). OpenBSD. * Index: usr.sbin/btrace/btrace.8 === RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/btrace/btrace.8,v retrieving revision 1.6 diff -u -p -r1.6 btrace.8 --- usr.sbin/btrace/btrace.88 Sep 2021 13:29:51 - 1.6 +++ usr.sbin/btrace/btrace.830 Apr 2022 21:38:41 - @@ -59,6 +59,13 @@ Multiple options increase the verbosity. The maximum is 2. .El +.Sh FILES +.Bl -tag -width "/usr/share/btrace/" -compact +.It Pa /usr/share/btrace/* +collection of useful +.Nm +programs +.El .Sh EXIT STATUS .Ex -std .Sh SEE ALSO
Re: EVFILT_USER and kevent(2)
Am Sat, Apr 30, 2022 at 10:05:05PM +0100 schrieb Stuart Henderson: > On 2022/04/30 13:51, Visa Hankala wrote: > > I am in two minds about EVFILT_USER. On the one hand, having it on > > OpenBSD might help with ports. > > No opinion on the addition, but I don't think we ran into this in ports > so far. There is software in ports which can use it but it can all work > without too. (I know about zeek and asterisk's res_timing_kqueue, though > we typically don't use the latter at all anyway as it has a pluggable > timer implementation and the pthread timer seems more accurate). When this was discussed in NetBSD, the best example brought up was nginx and its thread pool, which supposedly is disabled otherwise. It's NetBSD's PR 55663, if anyone wants to follow that discussion. Joerg
Re: EVFILT_USER and kevent(2)
On 2022/04/30 13:51, Visa Hankala wrote: > I am in two minds about EVFILT_USER. On the one hand, having it on > OpenBSD might help with ports. No opinion on the addition, but I don't think we ran into this in ports so far. There is software in ports which can use it but it can all work without too. (I know about zeek and asterisk's res_timing_kqueue, though we typically don't use the latter at all anyway as it has a pluggable timer implementation and the pthread timer seems more accurate).
Re: EVFILT_USER and kevent(2)
On 2022-04-30, Visa Hankala wrote: > I am in two minds about EVFILT_USER. On the one hand, having it on > OpenBSD might help with ports. On the other hand, it makes the kernel > perform a task that userspace can already handle using existing > interfaces. I agree you could do this with just a pipe, but also it's a bit simpler and it's not so very much code. It already exists, and seems at least one project uses it. I think it's fine. I also notice that libevent offers the event_active() function, which would allow building a similar mechanism, so there's more precedent for directly triggered events. (This function is not mentioned in the man page, however.)
Re: install btrace scripts
>On 2022-04-30, Alexander Bluhm wrote: >> Hi, >> >> Can we install the btrace scripts to /usr/share/btrace/ ? The >> directory already exists, only the Makefile is not linked to the >> build. >> >> And I would like to use #! to make them executable. > >It's weird to have exec files in share? yes, it is weird. i am not convinced that btrace is a natural interpreter, nor that anyone would put this into your $PATH, at which point you are using an absolute path, and it seems unlikely anyone would even notice these are executable, so they would the pattern: >I think it's not very hard to type "btrace script" vs script.
Re: install btrace scripts
On 2022-04-30, Alexander Bluhm wrote: > Hi, > > Can we install the btrace scripts to /usr/share/btrace/ ? The > directory already exists, only the Makefile is not linked to the > build. > > And I would like to use #! to make them executable. It's weird to have exec files in share? I think it's not very hard to type "btrace script" vs script. Or have you added this directory to your PATH too? Either way, it would be helpful for the man page to mention this directory.
install btrace scripts
Hi,
Can we install the btrace scripts to /usr/share/btrace/ ? The
directory already exists, only the Makefile is not linked to the
build.
And I would like to use #! to make them executable.
ok?
bluhm
Index: share/Makefile
===
RCS file: /data/mirror/openbsd/cvs/src/share/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- share/Makefile 9 Oct 2014 03:46:15 - 1.18
+++ share/Makefile 30 Apr 2022 19:22:32 -
@@ -1,5 +1,5 @@
# $OpenBSD: Makefile,v 1.18 2014/10/09 03:46:15 tedu Exp $
-SUBDIR=dict locale man misc mk snmp tabset termtypes zoneinfo
+SUBDIR=btrace dict locale man misc mk snmp tabset termtypes zoneinfo
.include
Index: share/btrace/Makefile
===
RCS file: /data/mirror/openbsd/cvs/src/share/btrace/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- share/btrace/Makefile 23 Oct 2021 19:37:35 - 1.1
+++ share/btrace/Makefile 30 Apr 2022 19:18:25 -
@@ -4,7 +4,7 @@ FILES= kprofile.bt runqlat.bt
NOOBJ= noobj
install:
- ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m 444 ${FILES} \
+ ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m 555 ${FILES} \
${DESTDIR}${BINDIR}/btrace
.include
Index: share/btrace/kprofile.bt
===
RCS file: /data/mirror/openbsd/cvs/src/share/btrace/kprofile.bt,v
retrieving revision 1.1
diff -u -p -r1.1 kprofile.bt
--- share/btrace/kprofile.bt23 Oct 2021 19:37:35 - 1.1
+++ share/btrace/kprofile.bt30 Apr 2022 19:20:32 -
@@ -1,3 +1,6 @@
+#!/usr/sbin/btrace
+/* $OpenBSD$ */
+
/*
* kprofile.bt Kernel profiling (stack sampling) at 100Hz.
*
Index: share/btrace/runqlat.bt
===
RCS file: /data/mirror/openbsd/cvs/src/share/btrace/runqlat.bt,v
retrieving revision 1.2
diff -u -p -r1.2 runqlat.bt
--- share/btrace/runqlat.bt 24 Oct 2021 08:42:38 - 1.2
+++ share/btrace/runqlat.bt 30 Apr 2022 19:20:38 -
@@ -1,3 +1,6 @@
+#!/usr/sbin/btrace
+/* $OpenBSD$ */
+
/*
* runqlat.bt Measure run queue latency (aka scheduler latency). OpenBSD.
*
Re: pluart(4): fifo support
> Date: Sat, 30 Apr 2022 09:40:24 +0200
> From: Anton Lindqvist
>
> On Sun, Mar 13, 2022 at 04:17:07PM +0100, Mark Kettenis wrote:
> > > Date: Fri, 11 Mar 2022 07:53:13 +0100
> > > From: Anton Lindqvist
> > >
> > > On Tue, Mar 08, 2022 at 01:44:47PM +, Visa Hankala wrote:
> > > > On Tue, Mar 08, 2022 at 08:04:36AM +0100, Anton Lindqvist wrote:
> > > > > On Mon, Mar 07, 2022 at 07:36:35AM +, Visa Hankala wrote:
> > > > > > I still think that checking TXFF and using the same code for both
> > > > > > SBSA and true PL011 UARTs would be the best choice. This would avoid
> > > > > > fragmenting the code and improve robustness by relying on
> > > > > > functionality
> > > > > > that is common to the different controller variants.
> > > > >
> > > > > Fair enough, new diff.
> > > >
> > > > Maybe the comments should omit the FIFO space description and just
> > > > mention the lack of the level control register in the SBSA UART
> > > > register interface.
> > >
> > > I ended up tweaking the comments before committing. Thanks for all the
> > > feedback.
> > >
> >
> > Hi Anton,
> >
> > This diff seems to break things. When I boot my rpi4 it now prints:
> >
> > pluart0 at simplebus0: rev 0, 16 byte fifo
> > pluart0: console
> > bcmbsc0 at simplebus0
> > iic0 at bcmbsc0
> >
> > so it appears that a carriage return character is lost here.
> >
> > Later on output stops at:
> >
> > reordering libraries: done.
> >
> > and only when I reboot the machine the login prompt appears, but with
> > some wierd respawning:
> >
> > OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console)
> >
> > login: init: getty repeating too quickly on port /dev/console, sleeping
> > init: getty repeating too quickly on port /dev/console, sleeping
> >
> > OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console)
> >
> > login:
> > OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console)
> >
> > login:
> >
> > If you don't have a quick fix for this, may I suggest reverting the
> > commit? We're heading towards release and we don't want the serial
> > console on the rpi4 to be broken.
>
> Circling back to this: what happens is that no tx interrupt is raised
> when sending less data than the configured interrupt fifo level, causing
> the tty to end up in a forever busy state. Clearing the busy flag after
> a successful transmission of all queued data solves the problem.
>
> While here, the hardware revision in the optional arm,primecell-periphid
> fdt node have higher precedence.
>
> Testing would be much appreciated.
This fixes the issue I had with the previous diff.
> diff --git sys/dev/acpi/pluart_acpi.c sys/dev/acpi/pluart_acpi.c
> index e90e810e76f..284769d159e 100644
> --- sys/dev/acpi/pluart_acpi.c
> +++ sys/dev/acpi/pluart_acpi.c
> @@ -91,6 +91,8 @@ pluart_acpi_attach(struct device *parent, struct device
> *self, void *aux)
> return;
> }
>
> + sc->sc.sc_hwflags |= COM_HW_SBSA;
> +
> pluart_attach_common(>sc, pluart_acpi_is_console(sc));
> }
>
> diff --git sys/dev/fdt/pluart_fdt.c sys/dev/fdt/pluart_fdt.c
> index 7be34b37f19..a1d7e006f39 100644
> --- sys/dev/fdt/pluart_fdt.c
> +++ sys/dev/fdt/pluart_fdt.c
> @@ -63,12 +63,20 @@ pluart_fdt_attach(struct device *parent, struct device
> *self, void *aux)
> {
> struct fdt_attach_args *faa = aux;
> struct pluart_softc *sc = (struct pluart_softc *) self;
> + uint32_t periphid;
>
> if (faa->fa_nreg < 1) {
> printf(": no registers\n");
> return;
> }
>
> + if (OF_is_compatible(faa->fa_node, "arm,sbsa-uart"))
> + sc->sc_hwflags |= COM_HW_SBSA;
> +
> + periphid = OF_getpropint(faa->fa_node, "arm,primecell-periphid", 0);
> + if (periphid != 0)
> + sc->sc_hwrev = (periphid >> 20) & 0x0f;
> +
> sc->sc_irq = fdt_intr_establish(faa->fa_node, IPL_TTY, pluart_intr,
> sc, sc->sc_dev.dv_xname);
>
> diff --git sys/dev/ic/pluart.c sys/dev/ic/pluart.c
> index 8a2b512eaeb..69654426a34 100644
> --- sys/dev/ic/pluart.c
> +++ sys/dev/ic/pluart.c
> @@ -99,6 +99,13 @@
> #define UART_CR_CTSE (1 << 14) /* CTS hardware flow control
> enable */
> #define UART_CR_RTSE (1 << 15) /* RTS hardware flow control
> enable */
> #define UART_IFLS0x34/* Interrupt FIFO level select
> register */
> +#define UART_IFLS_RX_SHIFT 3 /* RX level in bits [5:3] */
> +#define UART_IFLS_TX_SHIFT 0 /* TX level in bits [2:0] */
> +#define UART_IFLS_1_80 /* FIFO 1/8 full */
> +#define UART_IFLS_1_41 /* FIFO 1/4 full */
> +#define UART_IFLS_1_22 /* FIFO 1/2 full */
> +#define UART_IFLS_3_43 /* FIFO 3/4 full */
> +#define UART_IFLS_7_84 /* FIFO 7/8 full */
> #define UART_IMSC0x38/*
EVFILT_USER and kevent(2)
It has been asked in the past if OpenBSD's kevent(2) should implement
user event filters, also known as EVFILT_USER. This filter type
originates from FreeBSD but is now available also on DragonFly BSD,
NetBSD, and macOS.
Below is an implementation of EVFILT_USER. The logic should be fairly
straightforward. However, the filter type needs a special case in
kqueue_register() to allow triggering a previously registered user
event without using EV_ADD.
The code limits the number of user events. Otherwise the user could
allocate copious amounts of kernel memory. The limit is per process
so that programs will not interfere with each other. The current limit
is arbitrary and might need adjusting later. Hopefully a sysctl knob
will not be necessary.
I am in two minds about EVFILT_USER. On the one hand, having it on
OpenBSD might help with ports. On the other hand, it makes the kernel
perform a task that userspace can already handle using existing
interfaces.
Index: lib/libc/sys/kqueue.2
===
RCS file: src/lib/libc/sys/kqueue.2,v
retrieving revision 1.46
diff -u -p -r1.46 kqueue.2
--- lib/libc/sys/kqueue.2 31 Mar 2022 17:27:16 - 1.46
+++ lib/libc/sys/kqueue.2 30 Apr 2022 13:33:10 -
@@ -487,6 +487,44 @@ A device change event has occurred, e.g.
On return,
.Fa fflags
contains the events which triggered the filter.
+.It Dv EVFILT_USER
+Establishes a user event identified by
+.Va ident
+which is not associated with any kernel mechanism but is triggered by
+user level code.
+The lower 24 bits of the
+.Va fflags
+may be used for user defined flags and manipulated using the following:
+.Bl -tag -width XXNOTE_FFLAGSMASK
+.It Dv NOTE_FFNOP
+Ignore the input
+.Va fflags .
+.It Dv NOTE_FFAND
+Bitwise AND
+.Va fflags .
+.It Dv NOTE_FFOR
+Bitwise OR
+.Va fflags .
+.It Dv NOTE_FFCOPY
+Copy
+.Va fflags .
+.It Dv NOTE_FFCTRLMASK
+Control mask for
+.Va fflags .
+.It Dv NOTE_FFLAGSMASK
+User defined flag mask for
+.Va fflags .
+.El
+.Pp
+A user event is triggered for output with the following:
+.Bl -tag -width XXNOTE_FFLAGSMASK
+.It Dv NOTE_TRIGGER
+Cause the event to be triggered.
+.El
+.Pp
+On return,
+.Va fflags
+contains the users defined flags in the lower 24 bits.
.El
.Sh RETURN VALUES
.Fn kqueue
Index: regress/sys/kern/kqueue/Makefile
===
RCS file: src/regress/sys/kern/kqueue/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Makefile
--- regress/sys/kern/kqueue/Makefile30 Mar 2022 05:11:52 - 1.31
+++ regress/sys/kern/kqueue/Makefile30 Apr 2022 13:33:12 -
@@ -4,7 +4,7 @@ PROG= kqueue-test
CFLAGS+=-Wall
SRCS= kqueue-pipe.c kqueue-fork.c main.c kqueue-process.c kqueue-random.c \
kqueue-pty.c kqueue-tun.c kqueue-signal.c kqueue-fdpass.c \
- kqueue-flock.c kqueue-timer.c kqueue-regress.c
+ kqueue-flock.c kqueue-timer.c kqueue-regress.c kqueue-user.c
LDADD= -levent -lutil
DPADD= ${LIBEVENT} ${LIBUTIL}
@@ -50,6 +50,8 @@ kq-regress-5: ${PROG}
./${PROG} -R5
kq-regress-6: ${PROG}
./${PROG} -R6
+kq-user: ${PROG}
+ ./${PROG} -u
TESTS+=kq-fdpass
TESTS+=kq-flock
@@ -70,6 +72,7 @@ TESTS+= kq-reset-timer
TESTS+=kq-signal
TESTS+=kq-timer
TESTS+=kq-tun
+TESTS+=kq-user
REGRESS_TARGETS=${TESTS}
REGRESS_ROOT_TARGETS=kq-pty-1
Index: regress/sys/kern/kqueue/kqueue-user.c
===
RCS file: regress/sys/kern/kqueue/kqueue-user.c
diff -N regress/sys/kern/kqueue/kqueue-user.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ regress/sys/kern/kqueue/kqueue-user.c 30 Apr 2022 13:33:12 -
@@ -0,0 +1,189 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2022 Visa Hankala
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "main.h"
+
+int
+do_user(void)
+{
+ const struct timespec ts = { 0, 1 };
+ struct kevent kev[2];
+ int dummy, dummy2, i, kq, n;
+
+ ASS((kq = kqueue()) >= 0,
+ warn("kqueue"));
+
+ /* Set up an event. */
+ EV_SET([0], 1, EVFILT_USER, EV_ADD, ~0U & ~NOTE_TRIGGER, 0,
Re: ssh-keygen(1): resident fido2 keys
On 2022-04-29 19:24 +01, Jason McIntyre wrote: > what we probably want is a simple overview of these devices in > DESCRIPTION. but that's not simple. the page is already a bruiser. i > mean, it discusses what constitues a good password/phrase! where to go > from there? > > i note that the other components using -O have their own sections > (CERTIFICATES/MODULE GENERATION). so what about this: > > - add a very small note to DESCRIPTION saying it can handle fido keys. > that seems warranted anyway because they seem now fairly common and are > somewhat different to traditional (software) keys. > > - move the -O stuff pertaining to fido keys to its own section. > > - tweak the new fido section to give a simple overview of these devices. > > i'm not able to offer a diff at this point, but maybe we could piece > something together if you agree? Sounds reasonable, this adds the FIDO section and moves the -O bits in. The wording is inspired by / copied from the 8.2 release notes and the CERTIFICATES section. Maybe you have text for DESCRIPTION? Not sure what to do about -K, maybe see .Sx FIDO for details. diff --git ssh-keygen.1 ssh-keygen.1 index 59b7f23a1fa..6dc71aa32bd 100644 --- ssh-keygen.1 +++ ssh-keygen.1 @@ -487,56 +487,9 @@ listed in the .Sx MODULI GENERATION section may be specified. .Pp -When generating a key that will be hosted on a FIDO authenticator, -this flag may be used to specify key-specific options. -Those supported at present are: -.Bl -tag -width Ds -.It Cm application -Override the default FIDO application/origin string of -.Dq ssh: . -This may be useful when generating host or domain-specific resident keys. -The specified application string must begin with -.Dq ssh: . -.It Cm challenge Ns = Ns Ar path -Specifies a path to a challenge string that will be passed to the -FIDO token during key generation. -The challenge string may be used as part of an out-of-band -protocol for key enrollment -(a random challenge is used by default). -.It Cm device -Explicitly specify a -.Xr fido 4 -device to use, rather than letting the token middleware select one. -.It Cm no-touch-required -Indicate that the generated private key should not require touch -events (user presence) when making signatures. -Note that -.Xr sshd 8 -will refuse such signatures by default, unless overridden via -an authorized_keys option. -.It Cm resident -Indicate that the key should be stored on the FIDO authenticator itself. -Resident keys may be supported on FIDO2 tokens and typically require that -a PIN be set on the token prior to generation. -Resident keys may be loaded off the token using -.Xr ssh-add 1 . -.It Cm user -A username to be associated with a resident key, -overriding the empty default username. -Specifying a username may be useful when generating multiple resident keys -for the same application name. -.It Cm verify-required -Indicate that this private key should require user verification for -each signature. -Not all FIDO tokens support this option. -Currently PIN authentication is the only supported verification method, -but other methods may be supported in the future. -.It Cm write-attestation Ns = Ns Ar path -May be used at key generation time to record the attestation data -returned from FIDO tokens during key generation. -This information is potentially sensitive. -By default, this information is discarded. -.El +When generating FIDO token-backed keys, the options listed in the +.Sx FIDO +section may be specified. .Pp When performing signature-related options using the .Fl Y @@ -1060,6 +1013,75 @@ public key must be trusted by or .Xr ssh 1 . Refer to those manual pages for details. +.Sh FIDO +.Nm +is able to to generate FIDO token-backed keys, after which they may +be used much like any other key type supported by OpenSSH, so long as +the hardware token is attached when the keys are used. +FIDO tokens generally require the user to explicitly authorise +operations by touching or tapping them. +FIDO keys consist of two parts: a key handle part stored in the +private key file on disk, and a per-device private key that is unique +to each FIDO token and that cannot be exported from the token +hardware. +These are combined by the hardware at authentication time to derive +the real key that is used to sign authentication challenges. +Supported key types are +.Cm ecdsa-sk +and +.Cm ed25519-sk . +.Pp +The options that are valid for FIDO keys are: +.Bl -tag -width Ds +.It Cm application +Override the default FIDO application/origin string of +.Dq ssh: . +This may be useful when generating host or domain-specific resident keys. +The specified application string must begin with +.Dq ssh: . +.It Cm challenge Ns = Ns Ar path +Specifies a path to a challenge string that will be passed to the +FIDO token during key generation. +The challenge string may be used as part of an out-of-band +protocol for key enrollment +(a random challenge is used by default). +.It Cm device +Explicitly
dhcpleased(8): be more lenient with host name and domain name options
As found by n18fuhtm AT tutanota.com there are dhcp servers that send a
domain name option with length 1 and a single \0.
We strip trailing \0 and then end up with length 0.
This is a protocol violation, the minimum length for domain name option
is 1, and we ignore the lease.
So we are not going to fix this server side, we might as well just
pretend that we didn't receive a domain name (or host name). We only
ever care about them in the installer anyway. Not getting a lease
because of this corner case is not nice.
OK?
diff --git engine.c engine.c
index ae3f467ac3a..64770567198 100644
--- engine.c
+++ engine.c
@@ -882,6 +882,8 @@ parse_dhcp(struct dhcpleased_iface *iface, struct imsg_dhcp
*dhcp)
memset(_mask, 0, sizeof(subnet_mask));
memset(, 0, sizeof(routes));
memset(, 0, sizeof(nameservers));
+ memset(hostname, 0, sizeof(hostname));
+ memset(domainname, 0, sizeof(domainname));
while (rem > 0 && dho != DHO_END) {
dho = *p;
@@ -1014,14 +1016,18 @@ parse_dhcp(struct dhcpleased_iface *iface, struct
imsg_dhcp *dhcp)
rem -= dho_len;
break;
case DHO_HOST_NAME:
- if (dho_len < 1)
- goto wrong_length;
+ if (dho_len < 1) {
+ /*
+* Protocol violation: minimum length is 1;
+* pretend the option is not there
+*/
+ break;
+ }
/* MUST delete trailing NUL, per RFC 2132 */
slen = dho_len;
while (slen > 0 && p[slen - 1] == '\0')
slen--;
- if (slen < 1)
- goto wrong_length;
+ /* slen might be 0 here, pretend option is not there. */
strvisx(hostname, p, slen, VIS_SAFE);
if (log_getverbose() > 1)
log_debug("DHO_HOST_NAME: %s", hostname);
@@ -1029,14 +1035,18 @@ parse_dhcp(struct dhcpleased_iface *iface, struct
imsg_dhcp *dhcp)
rem -= dho_len;
break;
case DHO_DOMAIN_NAME:
- if (dho_len < 1)
- goto wrong_length;
+ if (dho_len < 1) {
+ /*
+* Protocol violation: minimum length is 1;
+* pretend the option is not there
+*/
+ break;
+ }
/* MUST delete trailing NUL, per RFC 2132 */
slen = dho_len;
while (slen > 0 && p[slen - 1] == '\0')
slen--;
- if (slen < 1)
- goto wrong_length;
+ /* slen might be 0 here, pretend option is not there. */
strvisx(domainname, p, slen, VIS_SAFE);
if (log_getverbose() > 1)
log_debug("DHO_DOMAIN_NAME: %s", domainname);
--
I'm not entirely sure you are real.
Re: pluart(4): fifo support
On Sun, Mar 13, 2022 at 04:17:07PM +0100, Mark Kettenis wrote:
> > Date: Fri, 11 Mar 2022 07:53:13 +0100
> > From: Anton Lindqvist
> >
> > On Tue, Mar 08, 2022 at 01:44:47PM +, Visa Hankala wrote:
> > > On Tue, Mar 08, 2022 at 08:04:36AM +0100, Anton Lindqvist wrote:
> > > > On Mon, Mar 07, 2022 at 07:36:35AM +, Visa Hankala wrote:
> > > > > I still think that checking TXFF and using the same code for both
> > > > > SBSA and true PL011 UARTs would be the best choice. This would avoid
> > > > > fragmenting the code and improve robustness by relying on
> > > > > functionality
> > > > > that is common to the different controller variants.
> > > >
> > > > Fair enough, new diff.
> > >
> > > Maybe the comments should omit the FIFO space description and just
> > > mention the lack of the level control register in the SBSA UART
> > > register interface.
> >
> > I ended up tweaking the comments before committing. Thanks for all the
> > feedback.
> >
>
> Hi Anton,
>
> This diff seems to break things. When I boot my rpi4 it now prints:
>
> pluart0 at simplebus0: rev 0, 16 byte fifo
> pluart0: console
> bcmbsc0 at simplebus0
> iic0 at bcmbsc0
>
> so it appears that a carriage return character is lost here.
>
> Later on output stops at:
>
> reordering libraries: done.
>
> and only when I reboot the machine the login prompt appears, but with
> some wierd respawning:
>
> OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console)
>
> login: init: getty repeating too quickly on port /dev/console, sleeping
> init: getty repeating too quickly on port /dev/console, sleeping
>
> OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console)
>
> login:
> OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console)
>
> login:
>
> If you don't have a quick fix for this, may I suggest reverting the
> commit? We're heading towards release and we don't want the serial
> console on the rpi4 to be broken.
Circling back to this: what happens is that no tx interrupt is raised
when sending less data than the configured interrupt fifo level, causing
the tty to end up in a forever busy state. Clearing the busy flag after
a successful transmission of all queued data solves the problem.
While here, the hardware revision in the optional arm,primecell-periphid
fdt node have higher precedence.
Testing would be much appreciated.
diff --git sys/dev/acpi/pluart_acpi.c sys/dev/acpi/pluart_acpi.c
index e90e810e76f..284769d159e 100644
--- sys/dev/acpi/pluart_acpi.c
+++ sys/dev/acpi/pluart_acpi.c
@@ -91,6 +91,8 @@ pluart_acpi_attach(struct device *parent, struct device
*self, void *aux)
return;
}
+ sc->sc.sc_hwflags |= COM_HW_SBSA;
+
pluart_attach_common(>sc, pluart_acpi_is_console(sc));
}
diff --git sys/dev/fdt/pluart_fdt.c sys/dev/fdt/pluart_fdt.c
index 7be34b37f19..a1d7e006f39 100644
--- sys/dev/fdt/pluart_fdt.c
+++ sys/dev/fdt/pluart_fdt.c
@@ -63,12 +63,20 @@ pluart_fdt_attach(struct device *parent, struct device
*self, void *aux)
{
struct fdt_attach_args *faa = aux;
struct pluart_softc *sc = (struct pluart_softc *) self;
+ uint32_t periphid;
if (faa->fa_nreg < 1) {
printf(": no registers\n");
return;
}
+ if (OF_is_compatible(faa->fa_node, "arm,sbsa-uart"))
+ sc->sc_hwflags |= COM_HW_SBSA;
+
+ periphid = OF_getpropint(faa->fa_node, "arm,primecell-periphid", 0);
+ if (periphid != 0)
+ sc->sc_hwrev = (periphid >> 20) & 0x0f;
+
sc->sc_irq = fdt_intr_establish(faa->fa_node, IPL_TTY, pluart_intr,
sc, sc->sc_dev.dv_xname);
diff --git sys/dev/ic/pluart.c sys/dev/ic/pluart.c
index 8a2b512eaeb..69654426a34 100644
--- sys/dev/ic/pluart.c
+++ sys/dev/ic/pluart.c
@@ -99,6 +99,13 @@
#define UART_CR_CTSE (1 << 14) /* CTS hardware flow control
enable */
#define UART_CR_RTSE (1 << 15) /* RTS hardware flow control
enable */
#define UART_IFLS 0x34/* Interrupt FIFO level select
register */
+#define UART_IFLS_RX_SHIFT 3 /* RX level in bits [5:3] */
+#define UART_IFLS_TX_SHIFT 0 /* TX level in bits [2:0] */
+#define UART_IFLS_1_8 0 /* FIFO 1/8 full */
+#define UART_IFLS_1_4 1 /* FIFO 1/4 full */
+#define UART_IFLS_1_2 2 /* FIFO 1/2 full */
+#define UART_IFLS_3_4 3 /* FIFO 3/4 full */
+#define UART_IFLS_7_8 4 /* FIFO 7/8 full */
#define UART_IMSC 0x38/* Interrupt mask set/clear
register */
#define UART_IMSC_RIMIM(1 << 0)
#define UART_IMSC_CTSMIM (1 << 1)
@@ -115,8 +122,16 @@
#define UART_MIS 0x40/* Masked interrupt status
register */
#define UART_ICR 0x44/* Interrupt clear register */
#define UART_DMACR 0x48
