Re: fix uchcom(4) handling of parity and character size config
On Wed, Oct 27, 2021 at 06:46:38AM +1000, David Gwynne wrote: Hi David, > this ports the functionality to support configuring parity and char size > masks from netbsd src/sys/dev/usb/uchcom.c r1.26. part of that change > including tweaks to uchcom_reset_chip, which was then changed in r1.28 > back to what we already have, so i left that chunk out. > > ive tested this talking to a device at 19200 with cs8 and even > parity. more tests would be appreciated to make sure i haven't > broken existing use functionality. I use uchcom(4) to connect with 115200 to the pinebook pro. I see no regressions with your diff, works fine. felix
demystify vport(4) in vport(4) and ifconfigt(8)
I tried to figure out how to use veb interfaces but the man page wasn't obvious in regards to the "vport" thing. It turns out it's a kind of interface that can be created with ifconfig. I think we should make this clearer. Because ifconfig(8) mentions many type of interfaces I've searched for "vport" without success while "most" types are referenced in the man page. Like I added veb(4) recently, the diff adds vport(4) and missing mpip(4) so a search would give a clue it's related to ifconfig. in veb(4), I think we should add vport in the synposis because the man page is shared for veb and vport interfaces but at first look it seems only veb is a type of interface. And finally, I added a mention that vport can be created with ifconfig(8) so it's really obvious. Maybe it's too much and can be removed. comments? ok? Index: share/man/man4//veb.4 === RCS file: /home/reposync/src/share/man/man4/veb.4,v retrieving revision 1.2 diff -u -p -r1.2 veb.4 --- share/man/man4//veb.4 23 Feb 2021 11:43:41 - 1.2 +++ share/man/man4//veb.4 26 Oct 2021 19:10:17 - @@ -23,6 +23,7 @@ .Nd Virtual Ethernet Bridge network device .Sh SYNOPSIS .Cd "pseudo-device veb" +.Cd "pseudo-device vport" .Sh DESCRIPTION The .Nm veb @@ -37,7 +38,9 @@ by .Nm veb by creating a .Nm vport -interface and attaching it as a port to the bridge. +interface using +.Xr ifconfig 8 +and attaching it as a port to the bridge. From the perspective of the host network stack, a .Nm vport interface acts as a normal interface connected to an Ethernet Index: sbin/ifconfig//ifconfig.8 === RCS file: /home/reposync/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.375 diff -u -p -r1.375 ifconfig.8 --- sbin/ifconfig//ifconfig.8 18 Aug 2021 18:10:33 - 1.375 +++ sbin/ifconfig//ifconfig.8 26 Oct 2021 19:13:27 - @@ -192,6 +192,7 @@ At least the following devices can be cr .Xr lo 4 , .Xr mgre 4 , .Xr mpe 4 , +.Xr mpip 4 , .Xr mpw 4 , .Xr nvgre 4 , .Xr pair 4 , @@ -209,6 +210,7 @@ At least the following devices can be cr .Xr veb 4 , .Xr vether 4 , .Xr vlan 4 , +.Xr vport 4 , .Xr vxlan 4 , .Xr wg 4 .It Cm debug
Re: demystify vport(4) in vport(4) and ifconfigt(8)
On Tue, Oct 26, 2021 at 09:18:30PM +0200, Solene Rapenne wrote: > I tried to figure out how to use veb interfaces but the man page > wasn't obvious in regards to the "vport" thing. It turns out it's > a kind of interface that can be created with ifconfig. > > I think we should make this clearer. agreed. the man page for veb/vport is definitely not... rigorous. > Because ifconfig(8) mentions many type of interfaces I've searched > for "vport" without success while "most" types are referenced in > the man page. Like I added veb(4) recently, the diff adds vport(4) > and missing mpip(4) so a search would give a clue it's related to > ifconfig. I'm ok with the ifconfig chunk. > in veb(4), I think we should add vport in the synposis because the > man page is shared for veb and vport interfaces but at first look > it seems only veb is a type of interface. The synopsis shows what you put into a kernel config file (eg src/sys/conf/GENERIC) to enable the driver, but "pseudo-device vport" is not valid kernel config. You enable the veb driver and that one driver provides both veb and vport interfaces. Another example of this is the gre driver which provides gre, egre, mgre, nvgre, and eoip interfaces. > And finally, I added a mention that vport can be created with > ifconfig(8) so it's really obvious. Maybe it's too much and can be > removed. It should definitely be said. The other man pages for clonable interfaces generally have a paragraph like this: .Nm gre , .Nm mgre , .Nm egre , and .Nm nvgre interfaces can be created at runtime using the .Ic ifconfig iface Ns Ar N Ic create command or by setting up a .Xr hostname.if 5 configuration file for .Xr netstart 8 . I just noticed vether.4 is also missing a paragraph like that too :( > comments? ok? Apart from it not being obvious where vport interfaces come from, is there anything else not obvious about veb? > Index: share/man/man4//veb.4 > === > RCS file: /home/reposync/src/share/man/man4/veb.4,v > retrieving revision 1.2 > diff -u -p -r1.2 veb.4 > --- share/man/man4//veb.4 23 Feb 2021 11:43:41 - 1.2 > +++ share/man/man4//veb.4 26 Oct 2021 19:10:17 - > @@ -23,6 +23,7 @@ > .Nd Virtual Ethernet Bridge network device > .Sh SYNOPSIS > .Cd "pseudo-device veb" > +.Cd "pseudo-device vport" > .Sh DESCRIPTION > The > .Nm veb > @@ -37,7 +38,9 @@ by > .Nm veb > by creating a > .Nm vport > -interface and attaching it as a port to the bridge. > +interface using > +.Xr ifconfig 8 > +and attaching it as a port to the bridge. > From the perspective of the host network stack, a > .Nm vport > interface acts as a normal interface connected to an Ethernet > Index: sbin/ifconfig//ifconfig.8 > === > RCS file: /home/reposync/src/sbin/ifconfig/ifconfig.8,v > retrieving revision 1.375 > diff -u -p -r1.375 ifconfig.8 > --- sbin/ifconfig//ifconfig.8 18 Aug 2021 18:10:33 - 1.375 > +++ sbin/ifconfig//ifconfig.8 26 Oct 2021 19:13:27 - > @@ -192,6 +192,7 @@ At least the following devices can be cr > .Xr lo 4 , > .Xr mgre 4 , > .Xr mpe 4 , > +.Xr mpip 4 , > .Xr mpw 4 , > .Xr nvgre 4 , > .Xr pair 4 , > @@ -209,6 +210,7 @@ At least the following devices can be cr > .Xr veb 4 , > .Xr vether 4 , > .Xr vlan 4 , > +.Xr vport 4 , > .Xr vxlan 4 , > .Xr wg 4 > .It Cm debug >
diff: improve legibility of structs in several manpages
Hello,
This diff harmonises the indentation of struct members and comments in
several manpages. Also fixes line wraps of comments on 80 column
terminals. General uses tabs for general indentation and 4 spaces on
tight spots. Also uses extra space to align pointers and non-pointers
as we do this on certain places in our source.
OK?
bye,
Jan
Index: sys/kbind.2
===
RCS file: /cvs/src/lib/libc/sys/kbind.2,v
retrieving revision 1.3
diff -u -p -r1.3 kbind.2
--- sys/kbind.2 1 Sep 2016 10:08:03 - 1.3
+++ sys/kbind.2 26 Oct 2021 14:15:37 -
@@ -25,7 +25,7 @@
.Bd -literal
struct __kbind {
void*kb_addr;
-size_t kb_size;
+size_t kb_size;
};
#define KBIND_BLOCK_MAX 2 /* powerpc and sparc64 need 2 blocks */
#define KBIND_DATA_MAX 24 /* sparc64 needs 6, four-byte words */
Index: sys/kqueue.2
===
RCS file: /cvs/src/lib/libc/sys/kqueue.2,v
retrieving revision 1.44
diff -u -p -r1.44 kqueue.2
--- sys/kqueue.222 Apr 2021 15:30:12 - 1.44
+++ sys/kqueue.226 Oct 2021 14:16:16 -
@@ -141,11 +141,11 @@ The
structure is defined as:
.Bd -literal
struct kevent {
- uintptr_t ident; /* identifier for this event */
- short filter; /* filter for event */
- u_shortflags; /* action flags for kqueue */
- u_int fflags; /* filter flag value */
- int64_tdata;/* filter data value */
+ uintptr_t ident; /* identifier for this event */
+ short filter; /* filter for event */
+ u_short flags; /* action flags for kqueue */
+ u_int fflags; /* filter flag value */
+ int64_t data; /* filter data value */
void *udata; /* opaque user data identifier */
};
.Ed
Index: sys/ktrace.2
===
RCS file: /cvs/src/lib/libc/sys/ktrace.2,v
retrieving revision 1.38
diff -u -p -r1.38 ktrace.2
--- sys/ktrace.21 Sep 2021 15:51:45 - 1.38
+++ sys/ktrace.226 Oct 2021 14:17:20 -
@@ -136,12 +136,12 @@ followed by a trace point specific struc
The generic header is:
.Bd -literal
struct ktr_header {
- uintktr_type; /* trace record type */
- pid_t ktr_pid;/* process id */
- pid_t ktr_tid;/* thread id */
- struct timespec ktr_time; /* timestamp */
- charktr_comm[MAXCOMLEN+1]; /* command name */
- size_t ktr_len;/* length of buf */
+ uintktr_type; /* trace record type */
+ pid_t ktr_pid;/* process id */
+ pid_t ktr_tid;/* thread id */
+ struct timespec ktr_time; /* timestamp */
+ charktr_comm[MAXCOMLEN+1]; /* command name */
+ size_t ktr_len;/* length of buf */
};
.Ed
.Pp
Index: sys/nfssvc.2
===
RCS file: /cvs/src/lib/libc/sys/nfssvc.2,v
retrieving revision 1.23
diff -u -p -r1.23 nfssvc.2
--- sys/nfssvc.231 May 2015 23:54:25 - 1.23
+++ sys/nfssvc.226 Oct 2021 15:54:29 -
@@ -63,16 +63,16 @@ is called with the flag
and a pointer to a structure:
.Bd -literal
struct nfsd_srvargs {
-struct nfsd *nsd_nfsd; /* Pointer to in kernel nfsd struct */
-uid_t nsd_uid;/* Effective uid mapped to cred */
-u_int32_t nsd_haddr; /* IP address of client */
-struct xucred nsd_cr; /* Cred. uid maps to */
-int nsd_authlen;/* Length of auth string (ret) */
-u_char *nsd_authstr; /* Auth string (ret) */
-int nsd_verflen;/* and the verifier */
-u_char *nsd_verfstr;
-struct timeval nsd_timestamp; /* timestamp from verifier */
-u_int32_t nsd_ttl;/* credential ttl (sec) */
+struct nfsd*nsd_nfsd; /* Pointer to in kernel nfsd struct */
+uid_t nsd_uid; /* Effective uid mapped to cred */
+u_int32_t nsd_haddr; /* IP address of client */
+struct xucred nsd_cr; /* Cred. uid maps to */
+intnsd_authlen; /* Length of auth string (ret) */
+u_char*nsd_authstr; /* Auth string (ret) */
+intnsd_verflen; /* and the verifier */
+u_char*nsd_verfstr;
+struct timeval nsd_timestamp; /* timestamp from verifier */
+u_int32_t nsd_ttl; /* credential ttl (sec) */
};
.Ed
.Pp
@@ -87,9 +87,9 @@ with the flag
and a pointer to a structure:
.Bd -literal
struct nfsd_args {
-int sock; /* Socket to serve */
-caddr_t name;
soqinsque(): replace 'DIAGNOSTIC' block by KASSERT(9)
Just for consistency with the rest of kern/uipc_socket2.c
Index: sys/kern/uipc_socket2.c
===
RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.113
diff -u -p -r1.113 uipc_socket2.c
--- sys/kern/uipc_socket2.c 26 Jul 2021 05:51:13 - 1.113
+++ sys/kern/uipc_socket2.c 26 Oct 2021 20:49:51 -
@@ -212,10 +212,7 @@ soqinsque(struct socket *head, struct so
{
soassertlocked(head);
-#ifdef DIAGNOSTIC
- if (so->so_onq != NULL)
- panic("soqinsque");
-#endif
+ KASSERT(so->so_onq == NULL);
so->so_head = head;
if (q == 0) {
fix uchcom(4) handling of parity and character size config
i bought some random usb to rs485 serial adapters so i can talk
modbus to a thing, but then discovered i can't talk to the modbus
thing because uchcom doesn't support configuring parity.
this ports the functionality to support configuring parity and char size
masks from netbsd src/sys/dev/usb/uchcom.c r1.26. part of that change
including tweaks to uchcom_reset_chip, which was then changed in r1.28
back to what we already have, so i left that chunk out.
ive tested this talking to a device at 19200 with cs8 and even
parity. more tests would be appreciated to make sure i haven't
broken existing use functionality.
Index: uchcom.c
===
RCS file: /cvs/src/sys/dev/usb/uchcom.c,v
retrieving revision 1.28
diff -u -p -r1.28 uchcom.c
--- uchcom.c31 Jul 2020 10:49:33 - 1.28
+++ uchcom.c26 Oct 2021 20:33:36 -
@@ -72,9 +72,8 @@ int uchcomdebug = 0;
#define UCHCOM_REG_BPS_DIV 0x13
#define UCHCOM_REG_BPS_MOD 0x14
#define UCHCOM_REG_BPS_PAD 0x0F
-#define UCHCOM_REG_BREAK1 0x05
-#define UCHCOM_REG_BREAK2 0x18
-#define UCHCOM_REG_LCR10x18
+#define UCHCOM_REG_BREAK 0x05
+#define UCHCOM_REG_LCR 0x18
#define UCHCOM_REG_LCR20x25
#define UCHCOM_VER_20 0x20
@@ -83,11 +82,25 @@ int uchcomdebug = 0;
#define UCHCOM_BPS_MOD_BASE2000
#define UCHCOM_BPS_MOD_BASE_OFS1100
+#define UCHCOM_BPS_PRE_IMM 0x80/* CH341: immediate RX forwarding */
+
#define UCHCOM_DTR_MASK0x20
#define UCHCOM_RTS_MASK0x40
-#define UCHCOM_BRK1_MASK 0x01
-#define UCHCOM_BRK2_MASK 0x40
+#define UCHCOM_BREAK_MASK 0x01
+
+#define UCHCOM_LCR_CS5 0x00
+#define UCHCOM_LCR_CS6 0x01
+#define UCHCOM_LCR_CS7 0x02
+#define UCHCOM_LCR_CS8 0x03
+#define UCHCOM_LCR_STOPB 0x04
+#define UCHCOM_LCR_PARENB 0x08
+#define UCHCOM_LCR_PARODD 0x00
+#define UCHCOM_LCR_PAREVEN 0x10
+#define UCHCOM_LCR_PARMARK 0x20
+#define UCHCOM_LCR_PARSPACE0x30
+#define UCHCOM_LCR_TXE 0x40
+#define UCHCOM_LCR_RXE 0x80
#define UCHCOM_INTR_STAT1 0x02
#define UCHCOM_INTR_STAT2 0x03
@@ -577,23 +590,21 @@ int
uchcom_set_break(struct uchcom_softc *sc, int onoff)
{
usbd_status err;
- uint8_t brk1, brk2;
+ uint8_t brk, lcr;
- err = uchcom_read_reg(sc, UCHCOM_REG_BREAK1, , UCHCOM_REG_BREAK2,
- );
+ err = uchcom_read_reg(sc, UCHCOM_REG_BREAK, , UCHCOM_REG_LCR, );
if (err)
return EIO;
if (onoff) {
/* on - clear bits */
- brk1 &= ~UCHCOM_BRK1_MASK;
- brk2 &= ~UCHCOM_BRK2_MASK;
+ brk &= ~UCHCOM_BREAK_MASK;
+ lcr &= ~UCHCOM_LCR_TXE;
} else {
/* off - set bits */
- brk1 |= UCHCOM_BRK1_MASK;
- brk2 |= UCHCOM_BRK2_MASK;
+ brk |= UCHCOM_BREAK_MASK;
+ lcr |= UCHCOM_LCR_TXE;
}
- err = uchcom_write_reg(sc, UCHCOM_REG_BREAK1, brk1, UCHCOM_REG_BREAK2,
- brk2);
+ err = uchcom_write_reg(sc, UCHCOM_REG_BREAK, brk, UCHCOM_REG_LCR, lcr);
if (err)
return EIO;
@@ -665,23 +676,50 @@ uchcom_set_dte_rate(struct uchcom_softc
int
uchcom_set_line_control(struct uchcom_softc *sc, tcflag_t cflag)
{
- /*
-* XXX: it is difficult to handle the line control appropriately:
-* work as chip default - CS8, no parity, !CSTOPB
-* other modes are not supported.
-*/
+ usbd_status err;
+ uint8_t lcr = 0, lcr2 = 0;
+
+ err = uchcom_read_reg(sc, UCHCOM_REG_LCR, ,
+ UCHCOM_REG_LCR2, );
+ if (err) {
+ printf("%s: cannot get LCR: %s\n",
+ sc->sc_dev.dv_xname, usbd_errstr(err));
+ return EIO;
+ }
+
+ lcr = UCHCOM_LCR_RXE | UCHCOM_LCR_TXE;
switch (ISSET(cflag, CSIZE)) {
case CS5:
+ lcr |= UCHCOM_LCR_CS5;
+ break;
case CS6:
+ lcr |= UCHCOM_LCR_CS6;
+ break;
case CS7:
- return EINVAL;
+ lcr |= UCHCOM_LCR_CS7;
+ break;
case CS8:
+ lcr |= UCHCOM_LCR_CS8;
break;
}
- if (ISSET(cflag, PARENB) || ISSET(cflag, CSTOPB))
- return EINVAL;
+ if (ISSET(cflag, PARENB)) {
+ lcr |= UCHCOM_LCR_PARENB;
+ if (!ISSET(cflag, PARODD))
+ lcr |= UCHCOM_LCR_PAREVEN;
+ }
+
+ if (ISSET(cflag, CSTOPB)) {
+ lcr |= UCHCOM_LCR_STOPB;
+ }
+
+ err = uchcom_write_reg(sc, UCHCOM_REG_LCR, lcr, UCHCOM_REG_LCR2, lcr2);
+ if (err) {
+ printf("%s: cannot set LCR: %s\n",
+ sc->sc_dev.dv_xname, usbd_errstr(err));
+
Re: demystify vport(4) in vport(4) and ifconfigt(8)
Solene Rapenne(sol...@perso.pw) on 2021.10.26 21:18:30 +0200: > I tried to figure out how to use veb interfaces but the man page > wasn't obvious in regards to the "vport" thing. It turns out it's > a kind of interface that can be created with ifconfig. > > I think we should make this clearer. > > Because ifconfig(8) mentions many type of interfaces I've searched > for "vport" without success while "most" types are referenced in > the man page. Like I added veb(4) recently, the diff adds vport(4) > and missing mpip(4) so a search would give a clue it's related to > ifconfig. > > in veb(4), I think we should add vport in the synposis because the > man page is shared for veb and vport interfaces but at first look > it seems only veb is a type of interface. > > And finally, I added a mention that vport can be created with > ifconfig(8) so it's really obvious. Maybe it's too much and can be > removed. > > comments? ok? ok i think this can be expanded more. vether(4) has a similar function for bridge(4). Maybe some text of vether(4) can be adapted and added to veb(4). /Benno > Index: share/man/man4//veb.4 > === > RCS file: /home/reposync/src/share/man/man4/veb.4,v > retrieving revision 1.2 > diff -u -p -r1.2 veb.4 > --- share/man/man4//veb.4 23 Feb 2021 11:43:41 - 1.2 > +++ share/man/man4//veb.4 26 Oct 2021 19:10:17 - > @@ -23,6 +23,7 @@ > .Nd Virtual Ethernet Bridge network device > .Sh SYNOPSIS > .Cd "pseudo-device veb" > +.Cd "pseudo-device vport" > .Sh DESCRIPTION > The > .Nm veb > @@ -37,7 +38,9 @@ by > .Nm veb > by creating a > .Nm vport > -interface and attaching it as a port to the bridge. > +interface using > +.Xr ifconfig 8 > +and attaching it as a port to the bridge. > From the perspective of the host network stack, a > .Nm vport > interface acts as a normal interface connected to an Ethernet > Index: sbin/ifconfig//ifconfig.8 > === > RCS file: /home/reposync/src/sbin/ifconfig/ifconfig.8,v > retrieving revision 1.375 > diff -u -p -r1.375 ifconfig.8 > --- sbin/ifconfig//ifconfig.8 18 Aug 2021 18:10:33 - 1.375 > +++ sbin/ifconfig//ifconfig.8 26 Oct 2021 19:13:27 - > @@ -192,6 +192,7 @@ At least the following devices can be cr > .Xr lo 4 , > .Xr mgre 4 , > .Xr mpe 4 , > +.Xr mpip 4 , > .Xr mpw 4 , > .Xr nvgre 4 , > .Xr pair 4 , > @@ -209,6 +210,7 @@ At least the following devices can be cr > .Xr veb 4 , > .Xr vether 4 , > .Xr vlan 4 , > +.Xr vport 4 , > .Xr vxlan 4 , > .Xr wg 4 > .It Cm debug >
Re: route.8: nameserver command is not resolvd(8) specific
Klemens Nanni(k...@openbsd.org) on 2021.10.26 15:30:17 +: > On Tue, Oct 26, 2021 at 04:06:20PM +0100, Jason McIntyre wrote: > > On Tue, Oct 26, 2021 at 08:57:40AM -0600, Theo de Raadt wrote: > > > Jason McIntyre wrote: > > > > > > > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote: > > > > > While designed to populate resolv.conf(5), there is nothing resolvd(8) > > > > > specific about the route message route(8) sends. > > > > > > > > > > At least unwind(8) consumes and acts upon it; there might as well be > > > > > other programs in ports that do such things, so describe it > > > > > generically > > > > > while going into required detail for our selected base daemons. > > > > > > > > > > OK? > > > > > > > > > > NB: I'll fix unwind.conf(5) wrt. `route nameserver' separately. > > > > > > > > > > > > > hi. > > > > > > > > i think it sounds weird to talk about sending things without saying > > > > where they're going. maybe there is a better word than send? maybe this > > > > command is just recording, or specifying, or ...? i don;t have a good > > > > grasp of the process here. > > > > > > "to the route socket" > > > > > > Maybe rather than 'send', does it explain things better to say > > > 'broadcast', > > > > > > > i think either saying to the route socket or broadcast are clear and > > would read better. > > The latter is great, thanks. > > OK? yes, this is good. I don't think we should hide how all these tools work together. After all we want users to understand how to use it. And while it is build to work out of the box, there are certainly situations where one needs to know more. Thanks. > > > Index: route.8 > === > RCS file: /cvs/src/sbin/route/route.8,v > retrieving revision 1.101 > diff -u -p -r1.101 route.8 > --- route.8 22 Oct 2021 18:31:12 - 1.101 > +++ route.8 26 Oct 2021 15:30:04 - > @@ -169,11 +169,16 @@ only changes in that routing table will > .Ar interface > .Op Ar address ... > .Xc > -Send a list of up to five nameserver address proposals to > -.Xr resolvd 8 . > +Broadcast a list of up to five nameserver address proposals. > +.Pp > +.Xr unwind 8 > +will learn them and act according to > +.Xr unwind.conf 5 . > +.Pp > .Xr resolvd 8 > will replace all existing nameservers for the given interface in > .Xr resolv.conf 5 . > +.Pp > If no > .Ar address > argument is given, a request to remove the nameservers previously entered for >
Re: upd(4) page fault since 7.0
On Tue, Oct 26, 2021 at 05:58:12PM +0200, Damien Couderc wrote:
> Le 26/10/2021 à 16:11, Anton Lindqvist a écrit :
> > On Tue, Oct 26, 2021 at 09:50:41AM +0200, Damien Couderc wrote:
> > > Le 24/10/2021 à 21:45, Anton Lindqvist a écrit :
> > > > On Sun, Oct 24, 2021 at 03:03:01PM +0200, Damien Couderc wrote:
> > > > > Hi,
> > > > > I got a page fault with upd(4) since 7.0.
> > > > >
> > > > > The problem began with the last revision of upd.c (1.30):
> > > > >
> > > > > ===
> > > > > RCS file: /cvs/src/sys/dev/usb/upd.c,v
> > > > > retrieving revision 1.29
> > > > > retrieving revision 1.30
> > > > > diff -u -r1.29 -r1.30
> > > > > --- src/sys/dev/usb/upd.c 2021/03/08 14:35:57 1.29
> > > > > +++ src/sys/dev/usb/upd.c 2021/08/06 17:46:45 1.30
> > > > > @@ -1,4 +1,4 @@
> > > > > -/* $OpenBSD: upd.c,v 1.29 2021/03/08 14:35:57 jcs Exp $ */
> > > > > +/* $OpenBSD: upd.c,v 1.30 2021/08/06 17:46:45 abieber Exp $ */
> > > > >
> > > > >/*
> > > > > * Copyright (c) 2015 David Higgs
> > > > > @@ -167,7 +167,7 @@
> > > > > if (upd_lookup_usage_entry(desc, size,
> > > > > upd_usage_roots + i, )) {
> > > > > ret = UMATCH_VENDOR_PRODUCT;
> > > > > - break;
> > > > > + uha->claimed[item.report_ID] = 1;
> > > > > }
> > > > >
> > > > > return (ret);
> > > > >
> > > > > ===
> > > > >
> > > > > The uha.claimed array is allocated using uha.nreports as its size
> > > > > while
> > > > > upd_match() is looping through the number of items of upd_usage_roots.
> > > > >
> > > > > In my case uha.nreports is equal to zero so uha.claimed is null, hence
> > > > > setting uha->claimed[n] is failing.
> > > > >
> > > > > As I'm not familiar with the HID code I did not yet understood the
> > > > > relation between upd_usage_roots and the claimed array but as we're
> > > > > talking about UPS attached computers I though the issue would sensible
> > > > > enough to make a quick reporting.
> > > > >
> > > > > You'll find a dmesg with options UPD_DEBUG and UHIDEV_DEBUG set and
> > > > > the
> > > > > following patch applied to circumvent the page fault and provide some
> > > > > debug:
> > > > Could you try the following diff, looks like an unsigned wrap around.
> > > >
> > > > Index: dev/usb/uhidev.h
> > > > ===
> > > > RCS file: /cvs/src/sys/dev/usb/uhidev.h,v
> > > > retrieving revision 1.32
> > > > diff -u -p -r1.32 uhidev.h
> > > > --- dev/usb/uhidev.h12 Sep 2021 06:58:08 - 1.32
> > > > +++ dev/usb/uhidev.h24 Oct 2021 19:44:52 -
> > > > @@ -82,7 +82,7 @@ struct uhidev_attach_arg {
> > > > struct uhidev_softc *parent;
> > > > uint8_t reportid;
> > > >#define UHIDEV_CLAIM_MULTIPLE_REPORTID 255
> > > > - uint8_t nreports;
> > > > + u_intnreports;
> > > > uint8_t *claimed;
> > > >};
> > > >
> > > Hello Anton,
> > >
> > > I made a quick test and nreports is now set with 256 but I still get the
> > > page fault.
> > >
> > > I'll check the details ASAP.
> >
> > Do you have a backtrace?
> >
>
> I only have screenshots of ddb.
>
> With the default kernel :
> http://cromagnon.petrocore.eu/ss_upd_ddb_default.jpg
>
> With a custom kernel for a bit more data :
> http://cromagnon.petrocore.eu/ss_upd_ddb_custom.jpg
Looks like a NULL deref. My guess would be item.report_ID going out of
bounds on uha->claimed. Inspecting item.report_ID could provide some
hints. This in turn could be caused by uhidev_maxrepid() looking for
hid_none items whereas upd_lookup_usage_entry() uses hid_feature.
Also, it would be interesting to see the descriptor of this device. If
you make upd_match() unconditionally return 0 it should hopefully^W
attach as uhid device; making it possible to extract the report using
usbhidctl replacing X with the attached device:
# usbhidctl -R -f /dev/uhidX
Re: ixl(4): add rx/tx checksum offloading
On Tue, Oct 26, 2021 at 05:17:55PM +1000, Jonathan Matthew wrote:
> First of all, thanks for looking at this, I forgot we hadn't done offloads
> for ixl(4) yet.
You're welcome.
> In the case of ixl(4), the driver has to tell the nic the length of each of
> the
> packet headers, so it should also be tested with vlan interfaces.
>
> I think ixl_tx_setup_offload() needs to account for outgoing vlan-tagged
> packets.
Yes, it should. I just want to keep this diff small for now. I plan to
implement handling of vlan tags in a later diff. The code just stops
processing the offload and returns, if the stack tries to send out a
vlan taged ethernet frame in the switch-statement at the beginning.
So, with vlan tags we just don't offload checksumming at the moment.
I also tested this scenario.
> It currently assumes the ethernet header is ETHER_HDR_LEN bytes long, which
> isn't
> always true. See ixgbe_tx_ctx_setup() (sys/dev/pci/if_ix.c) for an example of
> a driver that takes this into account.
I already looked at this code and will adapt vlan tagging later, if this
is OK for you?
Thanks,
Jan
> > Index: dev/pci/if_ixl.c
> > ===
> > RCS file: /mount/openbsd/cvs/src/sys/dev/pci/if_ixl.c,v
> > retrieving revision 1.75
> > diff -u -p -r1.75 if_ixl.c
> > --- dev/pci/if_ixl.c23 Jul 2021 00:29:14 - 1.75
> > +++ dev/pci/if_ixl.c25 Oct 2021 15:11:46 -
> > @@ -82,6 +82,10 @@
> > #endif
> >
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> > #include
> >
> > #include
> > @@ -1388,6 +1392,7 @@ static intixl_rxeof(struct ixl_softc *,
> > static voidixl_rxfill(struct ixl_softc *, struct ixl_rx_ring *);
> > static voidixl_rxrefill(void *);
> > static int ixl_rxrinfo(struct ixl_softc *, struct if_rxrinfo *);
> > +static voidixl_rx_checksum(struct mbuf *, uint64_t);
> >
> > #if NKSTAT > 0
> > static voidixl_kstat_attach(struct ixl_softc *);
> > @@ -1942,9 +1947,9 @@ ixl_attach(struct device *parent, struct
> > ifp->if_capabilities = IFCAP_VLAN_MTU;
> > #if 0
> > ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING;
> > - ifp->if_capabilities |= IFCAP_CSUM_IPv4 | IFCAP_CSUM_TCPv4 |
> > - IFCAP_CSUM_UDPv4;
> > #endif
> > + ifp->if_capabilities |= IFCAP_CSUM_IPv4 | IFCAP_CSUM_TCPv4 |
> > + IFCAP_CSUM_UDPv4 | IFCAP_CSUM_TCPv6 | IFCAP_CSUM_UDPv6;
> >
> > ifmedia_init(>sc_media, 0, ixl_media_change, ixl_media_status);
> >
> > @@ -2772,6 +2777,69 @@ ixl_load_mbuf(bus_dma_tag_t dmat, bus_dm
> > }
> >
> > static void
> > +ixl_tx_setup_offload(struct mbuf *mp, uint64_t *cmd)
> > +{
> > + uint64_t ip_hdr_len;
> > + int ipoff = ETHER_HDR_LEN;
> > + uint8_t ipproto;
> > + struct ip *ip;
> > +#ifdef INET6
> > + struct ip6_hdr *ip6;
> > +#endif
> > + struct tcphdr *th;
> > + struct mbuf *m;
> > +
> > + switch (ntohs(mtod(mp, struct ether_header *)->ether_type)) {
> > + case ETHERTYPE_IP:
> > + if (mp->m_pkthdr.len < ETHER_HDR_LEN + sizeof(*ip))
> > + return;
> > + m = m_getptr(mp, ETHER_HDR_LEN, );
> > + KASSERT(m != NULL && m->m_len - ipoff >= sizeof(*ip));
> > + ip = (struct ip *)(m->m_data + ipoff);
> > +
> > + if (mp->m_pkthdr.csum_flags & M_IPV4_CSUM_OUT)
> > + *cmd |= IXL_TX_DESC_CMD_IIPT_IPV4_CSUM;
> > + else
> > + *cmd |= IXL_TX_DESC_CMD_IIPT_IPV4;
> > +
> > + ip_hdr_len = ip->ip_hl << 2;
> > + ipproto = ip->ip_p;
> > + break;
> > +#ifdef INET6
> > + case ETHERTYPE_IPV6:
> > + if (mp->m_pkthdr.len < ETHER_HDR_LEN + sizeof(*ip6))
> > + return;
> > + m = m_getptr(mp, ETHER_HDR_LEN, );
> > + KASSERT(m != NULL && m->m_len - ipoff >= sizeof(*ip6));
> > + ip6 = (struct ip6_hdr *)(m->m_data + ipoff);
> > +
> > + *cmd |= IXL_TX_DESC_CMD_IIPT_IPV6;
> > +
> > + ip_hdr_len = sizeof(*ip6);
> > + ipproto = ip6->ip6_nxt;
> > + break;
> > +#endif
> > + default:
> > + return;
> > + }
> > +
> > + *cmd |= (ETHER_HDR_LEN >> 1) << IXL_TX_DESC_MACLEN_SHIFT;
> > + *cmd |= (ip_hdr_len >> 2) << IXL_TX_DESC_IPLEN_SHIFT;
> > +
> > + if (ipproto == IPPROTO_TCP && m->m_pkthdr.csum_flags & M_TCP_CSUM_OUT) {
> > + th = (struct tcphdr *)(m->m_data + ipoff + ip_hdr_len);
> > +
> > + *cmd |= IXL_TX_DESC_CMD_L4T_EOFT_TCP;
> > + *cmd |= (uint64_t)th->th_off << IXL_TX_DESC_L4LEN_SHIFT;
> > + }
> > +
> > + if (ipproto == IPPROTO_UDP && m->m_pkthdr.csum_flags & M_UDP_CSUM_OUT) {
> > + *cmd |= IXL_TX_DESC_CMD_L4T_EOFT_UDP;
> > + *cmd |= (sizeof(struct udphdr) >> 2) << IXL_TX_DESC_L4LEN_SHIFT;
> > + }
> > +}
> > +
> > +static void
> > ixl_start(struct ifqueue *ifq)
> > {
> > struct
ipsec tdb walk lock order
Hi,
There is an lock ordering problem with the new tdb_sadb_mtx mutex.
panic: acquiring blockable sleep lock with spinlock or critical section h
eld (kernel_lock) _lock
Stopped at db_enter+0x4: popl%ebp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*270299 46739 0 0x3 0 22 ipsecctl
355250 66710 0 0x14000 0x42000 softclock
db_enter() at db_enter+0x4
panic(d0be7299) at panic+0x7a
witness_checkorder(d0e96df0,9,0) at witness_checkorder+0x94e
__mp_lock(d0e96ce8) at __mp_lock+0x4a
_kernel_lock() at _kernel_lock+0x3a
ah_zeroize(dc1bd978) at ah_zeroize+0x4a
tdb_free(dc1bd978) at tdb_free+0x47
pfkeyv2_sa_flush(dc1bd978,d9783e23,0) at pfkeyv2_sa_flush+0x27
tdb_walk(0,d0990270,d9783e23) at tdb_walk+0x79
pfkeyv2_send(d7edd990,d9783e20,10) at pfkeyv2_send+0x411
pfkeyv2_output(d9897700,d7edd990,0,0) at pfkeyv2_output+0x61
pfkeyv2_usrreq(d7edd990,9,d9897700,0,0,d7df61b4) at pfkeyv2_usrreq+0x15a
sosend(d7edd990,0,f5ad9d60,d9897700,0,0) at sosend+0x2e3
soo_write(d7fec9a0,f5ad9d60,0) at soo_write+0x21
Currently the crypto layer needs kernel lock. As tdb_walk() does
not know whether walker() needs it, grab it in advance.
ok?
bluhm
Index: netinet/ip_ipsp.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_ipsp.c,v
retrieving revision 1.248
diff -u -p -r1.248 ip_ipsp.c
--- netinet/ip_ipsp.c 25 Oct 2021 18:25:01 - 1.248
+++ netinet/ip_ipsp.c 26 Oct 2021 16:34:49 -
@@ -540,6 +540,11 @@ tdb_walk(u_int rdomain, int (*walker)(st
int i, rval = 0;
struct tdb *tdbp, *next;
+ /*
+* The walker may aquire the kernel lock. Grab it here to keep
+* the lock order.
+*/
+ KERNEL_LOCK();
mtx_enter(_sadb_mtx);
for (i = 0; i <= tdb_hashmask; i++) {
for (tdbp = tdbh[i]; rval == 0 && tdbp != NULL; tdbp = next) {
@@ -555,6 +560,7 @@ tdb_walk(u_int rdomain, int (*walker)(st
}
}
mtx_leave(_sadb_mtx);
+ KERNEL_UNLOCK();
return rval;
}
Re: rpki-client adjust tal parse to the BIO free world
OK job@
On Tue, Oct 26, 2021 at 05:43:32PM +0200, Claudio Jeker wrote:
> This is part 3 of the BIO removal. Switch tal_parse to pass a file buffer
> like all other callers. The parent process can now just use load_file()
> and pass that buffer to the parser. From there on the magic just happens.
>
> --
> :wq Claudio
>
> Index: encoding.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/encoding.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 encoding.c
> --- encoding.c11 Oct 2021 16:06:36 - 1.4
> +++ encoding.c26 Oct 2021 14:40:47 -
> @@ -29,11 +29,11 @@
> * Returns 0 on success or -1 for any errors.
> */
> int
> -base64_decode(const unsigned char *in, unsigned char **out, size_t *outlen)
> +base64_decode(const unsigned char *in, size_t inlen,
> +unsigned char **out, size_t *outlen)
> {
> static EVP_ENCODE_CTX *ctx;
> unsigned char *to;
> - size_t inlen;
> int tolen;
>
> if (ctx == NULL && (ctx = EVP_ENCODE_CTX_new()) == NULL)
> @@ -42,7 +42,6 @@ base64_decode(const unsigned char *in, u
> *out = NULL;
> *outlen = 0;
>
> - inlen = strlen(in);
> if (inlen >= INT_MAX - 3)
> return -1;
> tolen = ((inlen + 3) / 4) * 3 + 1;
> Index: extern.h
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
> retrieving revision 1.79
> diff -u -p -r1.79 extern.h
> --- extern.h 26 Oct 2021 13:31:05 - 1.79
> +++ extern.h 26 Oct 2021 14:40:37 -
> @@ -337,12 +337,12 @@ enum publish_type {
> * and parsed.
> */
> struct entity {
> - enum rtype type; /* type of entity (not RTYPE_EOF) */
> - char*file; /* local path to file */
> - int has_pkey; /* whether pkey/sz is specified */
> - unsigned char *pkey; /* public key (optional) */
> - size_t pkeysz; /* public key length (optional) */
> - char*descr; /* tal description */
> + enum rtype type; /* type of entity (not RTYPE_EOF) */
> + char*file; /* local path to file */
> + int has_data; /* whether data blob is specified */
> + unsigned char *data; /* optional data blob */
> + size_t datasz;/* length of optional data blob */
> + char*descr; /* tal description */
> TAILQ_ENTRY(entity) entries;
> };
> TAILQ_HEAD(entityq, entity);
> @@ -397,8 +397,7 @@ extern int verbose;
>
> void tal_buffer(struct ibuf *, const struct tal *);
> void tal_free(struct tal *);
> -struct tal *tal_parse(const char *, char *);
> -char *tal_read_file(const char *);
> +struct tal *tal_parse(const char *, char *, size_t);
> struct tal *tal_read(struct ibuf *);
>
> void cert_buffer(struct ibuf *, const struct cert *);
> @@ -534,8 +533,8 @@ void cryptoerrx(const char *, ...)
>
> /* Encoding functions for hex and base64. */
>
> -int base64_decode(const unsigned char *, unsigned char **,
> - size_t *);
> +int base64_decode(const unsigned char *, size_t,
> + unsigned char **, size_t *);
> int base64_encode(const unsigned char *, size_t, char **);
> char *hex_encode(const unsigned char *, size_t);
>
> @@ -595,8 +594,9 @@ intoutput_csv(FILE *, struct vrp_tree
> int output_json(FILE *, struct vrp_tree *, struct brk_tree *,
> struct stats *);
>
> -void logx(const char *fmt, ...)
> +void logx(const char *fmt, ...)
> __attribute__((format(printf, 1, 2)));
> +unsigned char*load_file(const char *, size_t *);
>
> int mkpath(const char *);
>
> Index: main.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
> retrieving revision 1.154
> diff -u -p -r1.154 main.c
> --- main.c24 Oct 2021 21:24:19 - 1.154
> +++ main.c26 Oct 2021 14:38:40 -
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -82,13 +83,46 @@ logx(const char *fmt, ...)
> }
> }
>
> +unsigned char *
> +load_file(const char *name, size_t *len)
> +{
> + unsigned char *buf = NULL;
> + struct stat st;
> + ssize_t n;
> + size_t size;
> + int fd;
> +
> + *len = 0;
> +
> + if ((fd = open(name, O_RDONLY)) == -1)
> + return NULL;
> + if (fstat(fd, ) != 0)
> + goto err;
> + if (st.st_size < 0)
> + goto err;
> + size = (size_t)st.st_size;
> + if ((buf = malloc(size)) == NULL)
> + goto err;
> + n = read(fd, buf, size);
> + if (n < 0 || (size_t)n != size)
> + goto err;
> + close(fd);
> + *len = size;
>
Re: upd(4) page fault since 7.0
Le 26/10/2021 à 16:11, Anton Lindqvist a écrit :
On Tue, Oct 26, 2021 at 09:50:41AM +0200, Damien Couderc wrote:
Le 24/10/2021 à 21:45, Anton Lindqvist a écrit :
On Sun, Oct 24, 2021 at 03:03:01PM +0200, Damien Couderc wrote:
Hi,
I got a page fault with upd(4) since 7.0.
The problem began with the last revision of upd.c (1.30):
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- src/sys/dev/usb/upd.c 2021/03/08 14:35:57 1.29
+++ src/sys/dev/usb/upd.c 2021/08/06 17:46:45 1.30
@@ -1,4 +1,4 @@
-/* $OpenBSD: upd.c,v 1.29 2021/03/08 14:35:57 jcs Exp $ */
+/* $OpenBSD: upd.c,v 1.30 2021/08/06 17:46:45 abieber Exp $ */
/*
* Copyright (c) 2015 David Higgs
@@ -167,7 +167,7 @@
if (upd_lookup_usage_entry(desc, size,
upd_usage_roots + i, )) {
ret = UMATCH_VENDOR_PRODUCT;
- break;
+ uha->claimed[item.report_ID] = 1;
}
return (ret);
===
The uha.claimed array is allocated using uha.nreports as its size while
upd_match() is looping through the number of items of upd_usage_roots.
In my case uha.nreports is equal to zero so uha.claimed is null, hence
setting uha->claimed[n] is failing.
As I'm not familiar with the HID code I did not yet understood the
relation between upd_usage_roots and the claimed array but as we're
talking about UPS attached computers I though the issue would sensible
enough to make a quick reporting.
You'll find a dmesg with options UPD_DEBUG and UHIDEV_DEBUG set and the
following patch applied to circumvent the page fault and provide some debug:
Could you try the following diff, looks like an unsigned wrap around.
Index: dev/usb/uhidev.h
===
RCS file: /cvs/src/sys/dev/usb/uhidev.h,v
retrieving revision 1.32
diff -u -p -r1.32 uhidev.h
--- dev/usb/uhidev.h12 Sep 2021 06:58:08 - 1.32
+++ dev/usb/uhidev.h24 Oct 2021 19:44:52 -
@@ -82,7 +82,7 @@ struct uhidev_attach_arg {
struct uhidev_softc *parent;
uint8_t reportid;
#define UHIDEV_CLAIM_MULTIPLE_REPORTID 255
- uint8_t nreports;
+ u_intnreports;
uint8_t *claimed;
};
Hello Anton,
I made a quick test and nreports is now set with 256 but I still get the
page fault.
I'll check the details ASAP.
Do you have a backtrace?
I only have screenshots of ddb.
With the default kernel :
http://cromagnon.petrocore.eu/ss_upd_ddb_default.jpg
With a custom kernel for a bit more data :
http://cromagnon.petrocore.eu/ss_upd_ddb_custom.jpg
With luck I'll have some time to go deeper this evening.
Thanks,
Damien
Re: route.8: nameserver command is not resolvd(8) specific
certainly ok by me. jmc On 26 October 2021 16:30:17 BST, Klemens Nanni wrote: >On Tue, Oct 26, 2021 at 04:06:20PM +0100, Jason McIntyre wrote: >> On Tue, Oct 26, 2021 at 08:57:40AM -0600, Theo de Raadt wrote: >> > Jason McIntyre wrote: >> > >> > > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote: >> > > > While designed to populate resolv.conf(5), there is nothing resolvd(8) >> > > > specific about the route message route(8) sends. >> > > > >> > > > At least unwind(8) consumes and acts upon it; there might as well be >> > > > other programs in ports that do such things, so describe it generically >> > > > while going into required detail for our selected base daemons. >> > > > >> > > > OK? >> > > > >> > > > NB: I'll fix unwind.conf(5) wrt. `route nameserver' separately. >> > > > >> > > >> > > hi. >> > > >> > > i think it sounds weird to talk about sending things without saying >> > > where they're going. maybe there is a better word than send? maybe this >> > > command is just recording, or specifying, or ...? i don;t have a good >> > > grasp of the process here. >> > >> > "to the route socket" >> > >> > Maybe rather than 'send', does it explain things better to say 'broadcast', >> > >> >> i think either saying to the route socket or broadcast are clear and >> would read better. > >The latter is great, thanks. > >OK? > > >Index: route.8 >=== >RCS file: /cvs/src/sbin/route/route.8,v >retrieving revision 1.101 >diff -u -p -r1.101 route.8 >--- route.822 Oct 2021 18:31:12 - 1.101 >+++ route.826 Oct 2021 15:30:04 - >@@ -169,11 +169,16 @@ only changes in that routing table will > .Ar interface > .Op Ar address ... > .Xc >-Send a list of up to five nameserver address proposals to >-.Xr resolvd 8 . >+Broadcast a list of up to five nameserver address proposals. >+.Pp >+.Xr unwind 8 >+will learn them and act according to >+.Xr unwind.conf 5 . >+.Pp > .Xr resolvd 8 > will replace all existing nameservers for the given interface in > .Xr resolv.conf 5 . >+.Pp > If no > .Ar address > argument is given, a request to remove the nameservers previously entered for >
rpki-client adjust tal parse to the BIO free world
This is part 3 of the BIO removal. Switch tal_parse to pass a file buffer
like all other callers. The parent process can now just use load_file()
and pass that buffer to the parser. From there on the magic just happens.
--
:wq Claudio
Index: encoding.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/encoding.c,v
retrieving revision 1.4
diff -u -p -r1.4 encoding.c
--- encoding.c 11 Oct 2021 16:06:36 - 1.4
+++ encoding.c 26 Oct 2021 14:40:47 -
@@ -29,11 +29,11 @@
* Returns 0 on success or -1 for any errors.
*/
int
-base64_decode(const unsigned char *in, unsigned char **out, size_t *outlen)
+base64_decode(const unsigned char *in, size_t inlen,
+unsigned char **out, size_t *outlen)
{
static EVP_ENCODE_CTX *ctx;
unsigned char *to;
- size_t inlen;
int tolen;
if (ctx == NULL && (ctx = EVP_ENCODE_CTX_new()) == NULL)
@@ -42,7 +42,6 @@ base64_decode(const unsigned char *in, u
*out = NULL;
*outlen = 0;
- inlen = strlen(in);
if (inlen >= INT_MAX - 3)
return -1;
tolen = ((inlen + 3) / 4) * 3 + 1;
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.79
diff -u -p -r1.79 extern.h
--- extern.h26 Oct 2021 13:31:05 - 1.79
+++ extern.h26 Oct 2021 14:40:37 -
@@ -337,12 +337,12 @@ enum publish_type {
* and parsed.
*/
struct entity {
- enum rtype type; /* type of entity (not RTYPE_EOF) */
- char*file; /* local path to file */
- int has_pkey; /* whether pkey/sz is specified */
- unsigned char *pkey; /* public key (optional) */
- size_t pkeysz; /* public key length (optional) */
- char*descr; /* tal description */
+ enum rtype type; /* type of entity (not RTYPE_EOF) */
+ char*file; /* local path to file */
+ int has_data; /* whether data blob is specified */
+ unsigned char *data; /* optional data blob */
+ size_t datasz;/* length of optional data blob */
+ char*descr; /* tal description */
TAILQ_ENTRY(entity) entries;
};
TAILQ_HEAD(entityq, entity);
@@ -397,8 +397,7 @@ extern int verbose;
voidtal_buffer(struct ibuf *, const struct tal *);
voidtal_free(struct tal *);
-struct tal *tal_parse(const char *, char *);
-char *tal_read_file(const char *);
+struct tal *tal_parse(const char *, char *, size_t);
struct tal *tal_read(struct ibuf *);
voidcert_buffer(struct ibuf *, const struct cert *);
@@ -534,8 +533,8 @@ void cryptoerrx(const char *, ...)
/* Encoding functions for hex and base64. */
-int base64_decode(const unsigned char *, unsigned char **,
- size_t *);
+int base64_decode(const unsigned char *, size_t,
+ unsigned char **, size_t *);
int base64_encode(const unsigned char *, size_t, char **);
char *hex_encode(const unsigned char *, size_t);
@@ -595,8 +594,9 @@ int output_csv(FILE *, struct vrp_tree
int output_json(FILE *, struct vrp_tree *, struct brk_tree *,
struct stats *);
-void logx(const char *fmt, ...)
+void logx(const char *fmt, ...)
__attribute__((format(printf, 1, 2)));
+unsigned char *load_file(const char *, size_t *);
intmkpath(const char *);
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.154
diff -u -p -r1.154 main.c
--- main.c 24 Oct 2021 21:24:19 - 1.154
+++ main.c 26 Oct 2021 14:38:40 -
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -82,13 +83,46 @@ logx(const char *fmt, ...)
}
}
+unsigned char *
+load_file(const char *name, size_t *len)
+{
+ unsigned char *buf = NULL;
+ struct stat st;
+ ssize_t n;
+ size_t size;
+ int fd;
+
+ *len = 0;
+
+ if ((fd = open(name, O_RDONLY)) == -1)
+ return NULL;
+ if (fstat(fd, ) != 0)
+ goto err;
+ if (st.st_size < 0)
+ goto err;
+ size = (size_t)st.st_size;
+ if ((buf = malloc(size)) == NULL)
+ goto err;
+ n = read(fd, buf, size);
+ if (n < 0 || (size_t)n != size)
+ goto err;
+ close(fd);
+ *len = size;
+ return buf;
+
+err:
+ close(fd);
+ free(buf);
+ return NULL;
+}
+
void
entity_free(struct entity *ent)
{
if (ent == NULL)
return;
- free(ent->pkey);
+ free(ent->data);
Re: route.8: nameserver command is not resolvd(8) specific
On Tue, 26 Oct 2021 15:30:17 -, Klemens Nanni wrote: > > i think either saying to the route socket or broadcast are clear and > > would read better. > > The latter is great, thanks. OK millert@ - todd
Re: route.8: nameserver command is not resolvd(8) specific
On Tue, Oct 26, 2021 at 04:06:20PM +0100, Jason McIntyre wrote: > On Tue, Oct 26, 2021 at 08:57:40AM -0600, Theo de Raadt wrote: > > Jason McIntyre wrote: > > > > > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote: > > > > While designed to populate resolv.conf(5), there is nothing resolvd(8) > > > > specific about the route message route(8) sends. > > > > > > > > At least unwind(8) consumes and acts upon it; there might as well be > > > > other programs in ports that do such things, so describe it generically > > > > while going into required detail for our selected base daemons. > > > > > > > > OK? > > > > > > > > NB: I'll fix unwind.conf(5) wrt. `route nameserver' separately. > > > > > > > > > > hi. > > > > > > i think it sounds weird to talk about sending things without saying > > > where they're going. maybe there is a better word than send? maybe this > > > command is just recording, or specifying, or ...? i don;t have a good > > > grasp of the process here. > > > > "to the route socket" > > > > Maybe rather than 'send', does it explain things better to say 'broadcast', > > > > i think either saying to the route socket or broadcast are clear and > would read better. The latter is great, thanks. OK? Index: route.8 === RCS file: /cvs/src/sbin/route/route.8,v retrieving revision 1.101 diff -u -p -r1.101 route.8 --- route.8 22 Oct 2021 18:31:12 - 1.101 +++ route.8 26 Oct 2021 15:30:04 - @@ -169,11 +169,16 @@ only changes in that routing table will .Ar interface .Op Ar address ... .Xc -Send a list of up to five nameserver address proposals to -.Xr resolvd 8 . +Broadcast a list of up to five nameserver address proposals. +.Pp +.Xr unwind 8 +will learn them and act according to +.Xr unwind.conf 5 . +.Pp .Xr resolvd 8 will replace all existing nameservers for the given interface in .Xr resolv.conf 5 . +.Pp If no .Ar address argument is given, a request to remove the nameservers previously entered for
Re: route.8: nameserver command is not resolvd(8) specific
On Tue, Oct 26, 2021 at 08:57:40AM -0600, Theo de Raadt wrote: > Jason McIntyre wrote: > > > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote: > > > While designed to populate resolv.conf(5), there is nothing resolvd(8) > > > specific about the route message route(8) sends. > > > > > > At least unwind(8) consumes and acts upon it; there might as well be > > > other programs in ports that do such things, so describe it generically > > > while going into required detail for our selected base daemons. > > > > > > OK? > > > > > > NB: I'll fix unwind.conf(5) wrt. `route nameserver' separately. > > > > > > > hi. > > > > i think it sounds weird to talk about sending things without saying > > where they're going. maybe there is a better word than send? maybe this > > command is just recording, or specifying, or ...? i don;t have a good > > grasp of the process here. > > "to the route socket" > > Maybe rather than 'send', does it explain things better to say 'broadcast', > i think either saying to the route socket or broadcast are clear and would read better. jmc > > > > Index: route.8 > > > === > > > RCS file: /cvs/src/sbin/route/route.8,v > > > retrieving revision 1.101 > > > diff -u -p -r1.101 route.8 > > > --- route.8 22 Oct 2021 18:31:12 - 1.101 > > > +++ route.8 26 Oct 2021 12:18:31 - > > > @@ -169,11 +169,16 @@ only changes in that routing table will > > > .Ar interface > > > .Op Ar address ... > > > .Xc > > > -Send a list of up to five nameserver address proposals to > > > -.Xr resolvd 8 . > > > +Send a list of up to five nameserver address proposals. > > > +.Pp > > > +.Xr unwind 8 > > > +will learn them and act according to > > > +.Xr unwind.conf 5 . > > > +.Pp > > > .Xr resolvd 8 > > > will replace all existing nameservers for the given interface in > > > .Xr resolv.conf 5 . > > > +.Pp > > > If no > > > .Ar address > > > argument is given, a request to remove the nameservers previously > > > entered for > > > > > >
Re: route.8: nameserver command is not resolvd(8) specific
Jason McIntyre wrote: > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote: > > While designed to populate resolv.conf(5), there is nothing resolvd(8) > > specific about the route message route(8) sends. > > > > At least unwind(8) consumes and acts upon it; there might as well be > > other programs in ports that do such things, so describe it generically > > while going into required detail for our selected base daemons. > > > > OK? > > > > NB: I'll fix unwind.conf(5) wrt. `route nameserver' separately. > > > > hi. > > i think it sounds weird to talk about sending things without saying > where they're going. maybe there is a better word than send? maybe this > command is just recording, or specifying, or ...? i don;t have a good > grasp of the process here. "to the route socket" Maybe rather than 'send', does it explain things better to say 'broadcast', > > Index: route.8 > > === > > RCS file: /cvs/src/sbin/route/route.8,v > > retrieving revision 1.101 > > diff -u -p -r1.101 route.8 > > --- route.8 22 Oct 2021 18:31:12 - 1.101 > > +++ route.8 26 Oct 2021 12:18:31 - > > @@ -169,11 +169,16 @@ only changes in that routing table will > > .Ar interface > > .Op Ar address ... > > .Xc > > -Send a list of up to five nameserver address proposals to > > -.Xr resolvd 8 . > > +Send a list of up to five nameserver address proposals. > > +.Pp > > +.Xr unwind 8 > > +will learn them and act according to > > +.Xr unwind.conf 5 . > > +.Pp > > .Xr resolvd 8 > > will replace all existing nameservers for the given interface in > > .Xr resolv.conf 5 . > > +.Pp > > If no > > .Ar address > > argument is given, a request to remove the nameservers previously entered > > for > > >
Re: route.8: nameserver command is not resolvd(8) specific
On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote: > While designed to populate resolv.conf(5), there is nothing resolvd(8) > specific about the route message route(8) sends. > > At least unwind(8) consumes and acts upon it; there might as well be > other programs in ports that do such things, so describe it generically > while going into required detail for our selected base daemons. > > OK? > > NB: I'll fix unwind.conf(5) wrt. `route nameserver' separately. > hi. i think it sounds weird to talk about sending things without saying where they're going. maybe there is a better word than send? maybe this command is just recording, or specifying, or ...? i don;t have a good grasp of the process here. jmc > Index: route.8 > === > RCS file: /cvs/src/sbin/route/route.8,v > retrieving revision 1.101 > diff -u -p -r1.101 route.8 > --- route.8 22 Oct 2021 18:31:12 - 1.101 > +++ route.8 26 Oct 2021 12:18:31 - > @@ -169,11 +169,16 @@ only changes in that routing table will > .Ar interface > .Op Ar address ... > .Xc > -Send a list of up to five nameserver address proposals to > -.Xr resolvd 8 . > +Send a list of up to five nameserver address proposals. > +.Pp > +.Xr unwind 8 > +will learn them and act according to > +.Xr unwind.conf 5 . > +.Pp > .Xr resolvd 8 > will replace all existing nameservers for the given interface in > .Xr resolv.conf 5 . > +.Pp > If no > .Ar address > argument is given, a request to remove the nameservers previously entered for >
packages-specs(7): minor typos
Two little fixes in packages-specs(7). diff --git share/man/man7/packages-specs.7 share/man/man7/packages-specs.7 index 8154206c7..9b3d7b5e7 100644 --- share/man/man7/packages-specs.7 +++ share/man/man7/packages-specs.7 @@ -71,7 +71,7 @@ In case there are substantial changes in the package, a patch level marker should be appended, e.g., .Sq p0 , .Sq p1 ... -For example, assuming that the screen package for release 2.8 was +For example, assuming that the screen package for release 2.9.8 was named .Qq screen-2.9.8 and that an important security patch led to a newer package, @@ -267,7 +267,7 @@ characters trigger the transform. .Pp If the flavor specification is left blank, any flavor will do. Note that most default package names don't contain flavor specification, -which means that any flavor will do +which means that any flavor will do. For instance, in .Bd -literal -offset indent LIB_DEPENDS = graphics/aalib
Re: upd(4) page fault since 7.0
On Tue, Oct 26, 2021 at 09:50:41AM +0200, Damien Couderc wrote:
> Le 24/10/2021 à 21:45, Anton Lindqvist a écrit :
> > On Sun, Oct 24, 2021 at 03:03:01PM +0200, Damien Couderc wrote:
> > > Hi,
> > > I got a page fault with upd(4) since 7.0.
> > >
> > > The problem began with the last revision of upd.c (1.30):
> > >
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/upd.c,v
> > > retrieving revision 1.29
> > > retrieving revision 1.30
> > > diff -u -r1.29 -r1.30
> > > --- src/sys/dev/usb/upd.c 2021/03/08 14:35:57 1.29
> > > +++ src/sys/dev/usb/upd.c 2021/08/06 17:46:45 1.30
> > > @@ -1,4 +1,4 @@
> > > -/* $OpenBSD: upd.c,v 1.29 2021/03/08 14:35:57 jcs Exp $ */
> > > +/* $OpenBSD: upd.c,v 1.30 2021/08/06 17:46:45 abieber Exp $ */
> > >
> > > /*
> > >* Copyright (c) 2015 David Higgs
> > > @@ -167,7 +167,7 @@
> > > if (upd_lookup_usage_entry(desc, size,
> > > upd_usage_roots + i, )) {
> > > ret = UMATCH_VENDOR_PRODUCT;
> > > - break;
> > > + uha->claimed[item.report_ID] = 1;
> > > }
> > >
> > > return (ret);
> > >
> > > ===
> > >
> > > The uha.claimed array is allocated using uha.nreports as its size while
> > > upd_match() is looping through the number of items of upd_usage_roots.
> > >
> > > In my case uha.nreports is equal to zero so uha.claimed is null, hence
> > > setting uha->claimed[n] is failing.
> > >
> > > As I'm not familiar with the HID code I did not yet understood the
> > > relation between upd_usage_roots and the claimed array but as we're
> > > talking about UPS attached computers I though the issue would sensible
> > > enough to make a quick reporting.
> > >
> > > You'll find a dmesg with options UPD_DEBUG and UHIDEV_DEBUG set and the
> > > following patch applied to circumvent the page fault and provide some
> > > debug:
> > Could you try the following diff, looks like an unsigned wrap around.
> >
> > Index: dev/usb/uhidev.h
> > ===
> > RCS file: /cvs/src/sys/dev/usb/uhidev.h,v
> > retrieving revision 1.32
> > diff -u -p -r1.32 uhidev.h
> > --- dev/usb/uhidev.h12 Sep 2021 06:58:08 - 1.32
> > +++ dev/usb/uhidev.h24 Oct 2021 19:44:52 -
> > @@ -82,7 +82,7 @@ struct uhidev_attach_arg {
> > struct uhidev_softc *parent;
> > uint8_t reportid;
> > #define UHIDEV_CLAIM_MULTIPLE_REPORTID 255
> > - uint8_t nreports;
> > + u_intnreports;
> > uint8_t *claimed;
> > };
> >
> Hello Anton,
>
> I made a quick test and nreports is now set with 256 but I still get the
> page fault.
>
> I'll check the details ASAP.
Do you have a backtrace?
unwind.conf.5: Zap duplicate bits, mention route nameserver
Mentioning `route nameserver' relevance made it obvious that the
`preference' block duplicates lots of information and I despise adding
to that.
So rearrange the list of types such that conceptually related ones are
subsequent and can reference each user to not repeat things.
This looks like this:
preference {type ...}
A list of DNS name server types to specify the order in which
name servers are picked when measured round-trip time medians are
equal. Additionally, the first mentioned type gets a time bonus.
Validating name servers are always picked over non-validating
name servers. DNS name server types are:
autoconfName servers learned via DHCP, SLAAC or route
nameserver.
oDoT-autoconf autoconf with opportunistic DNS over TLS.
stubautoconf via libc functions. See asr_run(3).
Will never validate. Useful when running behind
broken middle boxes that do not like edns0. DNS
answers from stub name servers are not cached.
forwarder Name servers configured in unwind.conf.
DoT forwarder with DNS over TLS.
oDoT-forwarder Opportunistic DoT.
recursorRecursively resolve names.
Emphasize "edns0" while here and simplify "unwind does X" to just "X".
Fist I tried listing types in the default order such that the sentence
afterwards is obsoleted by the self-documenting manner, but that
conflicts with the logical order I picked above.
Feedback? Objections? OK?
Index: unwind.conf.5
===
RCS file: /cvs/src/sbin/unwind/unwind.conf.5,v
retrieving revision 1.31
diff -u -p -r1.31 unwind.conf.5
--- unwind.conf.5 24 Oct 2021 15:57:17 - 1.31
+++ unwind.conf.5 26 Oct 2021 13:17:56 -
@@ -93,33 +93,32 @@ Validating name servers are always picke
DNS name server types are:
.Pp
.Bl -tag -width "oDoT-forwarder" -compact
+.It Ic autoconf
+Name servers learned via DHCP, SLAAC or
+.Cm route nameserver .
+.It Ic oDoT-autoconf
+.Ic autoconf
+with opportunistic DNS over TLS.
.It Ic stub
-Name servers learned via DHCP or SLAAC, queried using the libc functions.
+.Ic autoconf
+via libc functions.
See
.Xr asr_run 3 .
Will never validate.
-Useful when running behind broken middle boxes that do not like edns0.
+Useful when running behind broken middle boxes that do not like
+.Cm edns0 .
DNS answers from stub name servers are not cached.
-.It Ic autoconf
-Name servers learned via DHCP or SLAAC.
-.It Ic oDoT-autoconf
-Name servers learned via DHCP or SLAAC.
-.Nm unwind
-tries to opportunistically use DNS over TLS.
-.It Ic DoT
-DNS over TLS name servers configured in
-.Nm .
.It Ic forwarder
Name servers configured in
.Nm .
+.It Ic DoT
+.Ic forwarder
+with DNS over TLS.
.It Ic oDoT-forwarder
-Name servers configured in
-.Nm .
-.Nm unwind
-tries to opportunistically use DNS over TLS.
+Opportunistic
+.Ic DoT .
.It Ic recursor
-.Nm unwind
-itself recursively resolves names.
+Recursively resolve names.
.El
.Pp
The default preference is
Fwd: futex(2) not working in inherited mmap'd anon memory
-- Forwarded message -
From: Thomas Munro
Date: Tue, Oct 26, 2021 at 5:36 AM
Subject: futex(2) not working in inherited mmap'd anon memory
To:
Hello,
When I do mmap(MAP_ANONYMOUS | MAP_SHARED) and then fork(), it seems
that futex(2) wakeups are not delivered between child and parent in
that memory. It does work as expected if I instead use
shmget(IPC_PRIVATE).
Below is a standalone test program. I tested it with the four OSes
mentioned, and the two shmem types depending on that #if, and all
worked as expected except the OpenBSD/mmap case, which hangs.
Is it a bug?
$ uname -a
OpenBSD openbsd6.localdomain 6.9 GENERIC.MP#473 amd64
Thanks,
=== 8< ===
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#if defined(__linux__)
#include
#include
#elif defined(__OpenBSD__)
#include
#include
#elif defined(__FreeBSD__)
#include
#include
#elif defined(__APPLE__)
#define UL_COMPARE_AND_WAIT_SHARED 3
#define ULF_WAKE_ALL 0x0100
extern int __ulock_wait(uint32_t operation, void *addr, uint64_t
value, uint32_t timeout);
extern int __ulock_wake(uint32_t operation, void *addr, uint64_t wake_value);
#endif
static int
my_futex_wait_u32(void *fut, uint32_t value, struct timespec *timeout)
{
#if defined(__linux__)
if (syscall(SYS_futex, fut, FUTEX_WAIT, value, timeout, 0, 0) == 0)
return 0;
#elif defined(__OpenBSD__)
if ((errno = futex(fut, FUTEX_WAIT, (int) value, timeout, NULL)) == 0)
return 0;
if (errno == ECANCELED)
errno = EINTR;
#elif defined(__FreeBSD__)
if (_umtx_op(fut, UMTX_OP_WAIT_UINT, value, 0, timeout) == 0)
return 0;
#elif defined (__APPLE__)
if (__ulock_wait(UL_COMPARE_AND_WAIT_SHARED, (void *) fut,
value, timeout ? timeout->tv_sec * 100 + timeout->tv_nsec / 1000 :
0) >
= 0)
return 0;
#else
errno = ENOSYS;
#endif
return -1;
}
static int
my_futex_wake(void *fut, int nwaiters)
{
#if defined(__linux__)
if (syscall(SYS_futex, fut, FUTEX_WAKE, nwaiters, NULL, 0, 0) >= 0)
return 0;
#elif defined(__OpenBSD__)
if (futex(fut, FUTEX_WAKE, nwaiters, NULL, NULL) >= 0)
return 0;
#elif defined(__FreeBSD__)
if (_umtx_op(fut, UMTX_OP_WAKE, nwaiters, 0, 0) == 0)
return 0;
#elif defined (__APPLE__)
if (__ulock_wake(UL_COMPARE_AND_WAIT_SHARED | (nwaiters > 1 ?
ULF_WAKE_ALL : 0), (void *) fut, 0) >= 0)
return 0;
if (errno == ENOENT)
return 0;
#else
errno = ENOSYS;
#endif
return -1;
}
int
main(int argc, char *argv[])
{
pid_t pid;
uint32_t *memory;
int status;
#if 1
memory = mmap(NULL, sizeof(uint32_t), PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_SHARED, -1, 0);
if (memory == MAP_FAILED) {
perror("mmap");
return EXIT_FAILURE;
}
#else
int shm_id;
shm_id = shmget(IPC_PRIVATE, sizeof(uint32_t), IPC_CREAT | 0666);
if (shm_id < 0) {
perror("shmget");
return EXIT_FAILURE;
}
memory = shmat(shm_id, NULL, 0);
if ((intptr_t) memory == -1) {
perror("shmat");
return EXIT_FAILURE;
}
#endif
*memory = 42;
pid = fork();
if (pid == -1) {
perror("fork");
return EXIT_FAILURE;
} else if (pid > 0) {
printf("hello from parent, will wait for futex...\n");
if (my_futex_wait_u32(memory, 42, NULL) < 0) {
perror("futex_wait");
wait();
return EXIT_FAILURE;
}
wait();
return EXIT_SUCCESS;
} else {
printf("hello from child, will wake futex...\n");
sleep(1);
if (my_futex_wake(memory, INT_MAX) < 0) {
perror("futex_wake");
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
}
route.8: nameserver command is not resolvd(8) specific
While designed to populate resolv.conf(5), there is nothing resolvd(8) specific about the route message route(8) sends. At least unwind(8) consumes and acts upon it; there might as well be other programs in ports that do such things, so describe it generically while going into required detail for our selected base daemons. OK? NB: I'll fix unwind.conf(5) wrt. `route nameserver' separately. Index: route.8 === RCS file: /cvs/src/sbin/route/route.8,v retrieving revision 1.101 diff -u -p -r1.101 route.8 --- route.8 22 Oct 2021 18:31:12 - 1.101 +++ route.8 26 Oct 2021 12:18:31 - @@ -169,11 +169,16 @@ only changes in that routing table will .Ar interface .Op Ar address ... .Xc -Send a list of up to five nameserver address proposals to -.Xr resolvd 8 . +Send a list of up to five nameserver address proposals. +.Pp +.Xr unwind 8 +will learn them and act according to +.Xr unwind.conf 5 . +.Pp .Xr resolvd 8 will replace all existing nameservers for the given interface in .Xr resolv.conf 5 . +.Pp If no .Ar address argument is given, a request to remove the nameservers previously entered for
remove more BIO from rpki-client part 2
This switches the cert parser to use d2i_X509 instead of the BIO versions.
--
:wq Claudio
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.40
diff -u -p -r1.40 cert.c
--- cert.c 23 Oct 2021 16:06:04 - 1.40
+++ cert.c 26 Oct 2021 11:32:12 -
@@ -976,7 +976,8 @@ out:
* is also dereferenced.
*/
static struct cert *
-cert_parse_inner(X509 **xp, const char *fn, int ta)
+cert_parse_inner(X509 **xp, const char *fn, const unsigned char *der,
+size_t len, int ta)
{
int rc = 0, extsz, c;
int sia_present = 0;
@@ -985,28 +986,19 @@ cert_parse_inner(X509 **xp, const char *
X509_EXTENSION *ext = NULL;
ASN1_OBJECT *obj;
struct parse p;
- BIO *bio = NULL;
- FILE*f;
*xp = NULL;
- if ((f = fopen(fn, "rb")) == NULL) {
- warn("%s", fn);
+ /* just fail for empty buffers, the warning was printed elsewhere */
+ if (der == NULL)
return NULL;
- }
-
- if ((bio = BIO_new_fp(f, BIO_CLOSE)) == NULL) {
- if (verbose > 0)
- cryptowarnx("%s: BIO_new_file", fn);
- return NULL;
- }
memset(, 0, sizeof(struct parse));
p.fn = fn;
if ((p.res = calloc(1, sizeof(struct cert))) == NULL)
err(1, NULL);
- if ((x = *xp = d2i_X509_bio(bio, NULL)) == NULL) {
+ if ((x = *xp = d2i_X509(NULL, , len)) == NULL) {
cryptowarnx("%s: d2i_X509_bio", p.fn);
goto out;
}
@@ -1144,7 +1136,6 @@ cert_parse_inner(X509 **xp, const char *
rc = 1;
out:
- BIO_free_all(bio);
if (rc == 0) {
cert_free(p.res);
X509_free(x);
@@ -1154,19 +1145,20 @@ out:
}
struct cert *
-cert_parse(X509 **xp, const char *fn)
+cert_parse(X509 **xp, const char *fn, const unsigned char *der, size_t len)
{
- return cert_parse_inner(xp, fn, 0);
+ return cert_parse_inner(xp, fn, der, len, 0);
}
struct cert *
-ta_parse(X509 **xp, const char *fn, const unsigned char *pkey, size_t pkeysz)
+ta_parse(X509 **xp, const char *fn, const unsigned char *der, size_t len,
+const unsigned char *pkey, size_t pkeysz)
{
EVP_PKEY*pk = NULL, *opk = NULL;
struct cert *p;
int rc = 0;
- if ((p = cert_parse_inner(xp, fn, 1)) == NULL)
+ if ((p = cert_parse_inner(xp, fn, der, len, 1)) == NULL)
return NULL;
if (pkey != NULL) {
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.78
diff -u -p -r1.78 extern.h
--- extern.h26 Oct 2021 10:52:49 - 1.78
+++ extern.h26 Oct 2021 10:58:44 -
@@ -403,8 +403,10 @@ struct tal *tal_read(struct ibuf *);
voidcert_buffer(struct ibuf *, const struct cert *);
voidcert_free(struct cert *);
-struct cert*cert_parse(X509 **, const char *);
-struct cert*ta_parse(X509 **, const char *, const unsigned char *, size_t);
+struct cert*cert_parse(X509 **, const char *, const unsigned char *,
+ size_t);
+struct cert*ta_parse(X509 **, const char *, const unsigned char *, size_t,
+ const unsigned char *, size_t);
struct cert*cert_read(struct ibuf *);
voidcert_insert_brks(struct brk_tree *, struct cert *);
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
retrieving revision 1.18
diff -u -p -r1.18 parser.c
--- parser.c26 Oct 2021 10:52:50 - 1.18
+++ parser.c26 Oct 2021 10:59:06 -
@@ -191,7 +191,8 @@ proc_parser_mft(struct entity *entp, con
* parse failure.
*/
static struct cert *
-proc_parser_cert(const struct entity *entp)
+proc_parser_cert(const struct entity *entp, const unsigned char *der,
+size_t len)
{
struct cert *cert;
X509*x509;
@@ -204,7 +205,7 @@ proc_parser_cert(const struct entity *en
/* Extract certificate data and X509. */
- cert = cert_parse(, entp->file);
+ cert = cert_parse(, entp->file, der, len);
if (cert == NULL)
return NULL;
@@ -282,7 +283,8 @@ proc_parser_cert(const struct entity *en
* parse failure.
*/
static struct cert *
-proc_parser_root_cert(const struct entity *entp)
+proc_parser_root_cert(const struct entity *entp, const unsigned char *der,
+size_t len)
{
charsubject[256];
ASN1_TIME *notBefore, *notAfter;
@@ -296,7 +298,7 @@ proc_parser_root_cert(const struct entit
/* Extract certificate data and X509. */
- cert = ta_parse(, entp->file,
UNIX sockets: use vnode(9) lock to protect `v_socket' dereference
Another step to make UNIX sockets locking fine grained.
The listening socket has the references from file descriptors layer and
from the vnode(9) layer. This means when we close(2)'ing such socket it
still referenced by concurrent thread through connect(2) path.
When we bind(2) UNIX socket we link it to vnode(9) by assigning
`v_socket'. When we connect(2)'ing socket to the socket we previously
bind(2)'ed we finding it by namei(9) and obtain it's reference through
`v_socket'. This socket has no extra reference in file descriptor
layer and could be closed by concurrent thread.
This time we have `unp_lock' rwlock(9) which protects the whole layer
and the dereference of `v_socket' is safe. But with the fine grained
locking the `v_socket' will not be protected by global lock. When we
obtain the vnode(9) by namei(9) in connect(9) or bind(9) paths it is
already exclusively locked by vlode(9) lock. But in unp_detach() which
is called on the close(2)'ing socket we assume `unp_lock' protects
`v_socket'.
I propose to use exclusive vnode(9) lock to protect `v_socket'. With the
fine grained locking, the `v_socket' dereference in unp_bind() or
unp_connect() threads will be safe because unp_detach() thread will wait
the vnode(9) lock release. The vnode referenced by `unp_vnod' has
reference counter bumped so it's dereference is also safe without
`unp_lock' held.
The `i_lock' should be take before `unp_lock' and unp_detach() should
release solock(). To prevent connections on this socket the
'SO_ACCEPTCONN' bit cleared in soclose().
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.265
diff -u -p -r1.265 uipc_socket.c
--- sys/kern/uipc_socket.c 14 Oct 2021 23:05:10 - 1.265
+++ sys/kern/uipc_socket.c 26 Oct 2021 11:05:59 -
@@ -315,6 +315,8 @@ soclose(struct socket *so, int flags)
/* Revoke async IO early. There is a final revocation in sofree(). */
sigio_free(>so_sigio);
if (so->so_options & SO_ACCEPTCONN) {
+ so->so_options &= ~SO_ACCEPTCONN;
+
while ((so2 = TAILQ_FIRST(>so_q0)) != NULL) {
(void) soqremque(so2, 0);
(void) soabort(so2);
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.150
diff -u -p -r1.150 uipc_usrreq.c
--- sys/kern/uipc_usrreq.c 21 Oct 2021 22:11:07 - 1.150
+++ sys/kern/uipc_usrreq.c 26 Oct 2021 11:05:59 -
@@ -474,20 +474,30 @@ void
unp_detach(struct unpcb *unp)
{
struct socket *so = unp->unp_socket;
- struct vnode *vp = NULL;
+ struct vnode *vp = unp->unp_vnode;
rw_assert_wrlock(_lock);
LIST_REMOVE(unp, unp_link);
- if (unp->unp_vnode) {
+
+ if (vp) {
+ unp->unp_vnode = NULL;
+
/*
-* `v_socket' is only read in unp_connect and
-* unplock prevents concurrent access.
+* Enforce `i_lock' -> `unp_lock' because fifo
+* subsystem requires it.
*/
- unp->unp_vnode->v_socket = NULL;
- vp = unp->unp_vnode;
- unp->unp_vnode = NULL;
+ sounlock(so, SL_LOCKED);
+
+ VOP_LOCK(vp, LK_EXCLUSIVE);
+ vp->v_socket = NULL;
+
+ KERNEL_LOCK();
+ vput(vp);
+ KERNEL_UNLOCK();
+
+ solock(so);
}
if (unp->unp_conn)
@@ -500,21 +510,6 @@ unp_detach(struct unpcb *unp)
pool_put(_pool, unp);
if (unp_rights)
task_add(systqmp, _gc_task);
-
- if (vp != NULL) {
- /*
-* Enforce `i_lock' -> `unplock' because fifo subsystem
-* requires it. The socket can't be closed concurrently
-* because the file descriptor reference is
-* still hold.
-*/
-
- sounlock(so, SL_LOCKED);
- KERNEL_LOCK();
- vrele(vp);
- KERNEL_UNLOCK();
- solock(so);
- }
}
int
libutil/ber: Bump BER_MAX_OID_LEN one last time
Last time when this value was bumped because I ran into SNMP problems
walking net-snmp because of string based indices in USM.
This time I want to bump them one more time because I found the
definition of the upper bound RFC 2578 section 7.1.3. This makes it
easier to parse agentx messages, which also have their upper bound
on 128.
I see no risk of fallout, since the previous bump only broke agentx
support in snmpd, which has since been removed. Nothing in ports is
using this code as far I know.
Memory footprint of snmpd only increases by a few 100KB, claudio@
only found on stack use of ber_oid in ldapd, so memory impact is
manageable.
Already discussed with claudio@
Iff OK tb@ promised to commit it at the same time as the libcrypto
bump to keep churn to a minimum.
OK?
martijn@
Index: ber.h
===
RCS file: /cvs/src/lib/libutil/ber.h,v
retrieving revision 1.4
diff -u -p -r1.4 ber.h
--- ber.h 29 Aug 2021 13:27:11 - 1.4
+++ ber.h 26 Oct 2021 10:14:26 -
@@ -80,8 +80,8 @@ struct ber {
#define BER_CLASS_MASK 0x3
/* common definitions */
-#define BER_MIN_OID_LEN2 /* OBJECT */
-#define BER_MAX_OID_LEN64 /* OBJECT */
+#define BER_MIN_OID_LEN2 /* X.690 section 8.19.5
*/
+#define BER_MAX_OID_LEN128 /* RFC 2578 section
7.1.3 */
#define BER_MAX_SEQ_ELEMENTS USHRT_MAX /* 65535 */
struct ber_oid {
Index: shlib_version
===
RCS file: /cvs/src/lib/libutil/shlib_version,v
retrieving revision 1.33
diff -u -p -r1.33 shlib_version
--- shlib_version 29 Aug 2021 13:27:11 - 1.33
+++ shlib_version 26 Oct 2021 10:14:26 -
@@ -1,2 +1,2 @@
-major=15
-minor=1
+major=16
+minor=0
remove more BIO from rpki-client
I want to be able to pass a buffer to the various parser functions instead
of a filename. This is in preparation for supporting rpki-client -f somefile
This diff switches CMS and CRL to their regular d2i versions. The cert
files will follow in the next diff.
--
:wq Claudio
Index: cms.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cms.c,v
retrieving revision 1.10
diff -u -p -r1.10 cms.c
--- cms.c 9 Sep 2021 14:15:49 - 1.10
+++ cms.c 26 Oct 2021 09:43:10 -
@@ -35,14 +35,12 @@
* Return the eContent as a string and set "rsz" to be its length.
*/
unsigned char *
-cms_parse_validate(X509 **xp, const char *fn, const ASN1_OBJECT *oid,
-size_t *rsz)
+cms_parse_validate(X509 **xp, const char *fn, const unsigned char *der,
+size_t derlen, const ASN1_OBJECT *oid, size_t *rsz)
{
const ASN1_OBJECT *obj;
ASN1_OCTET_STRING **os = NULL;
- BIO *bio = NULL;
CMS_ContentInfo *cms;
- FILE*f;
int rc = 0;
STACK_OF(X509) *certs = NULL;
unsigned char *res = NULL;
@@ -50,21 +48,11 @@ cms_parse_validate(X509 **xp, const char
*rsz = 0;
*xp = NULL;
- /*
-* This is usually fopen() failure, so let it pass through to
-* the handler, which will in turn ignore the entity.
-*/
- if ((f = fopen(fn, "rb")) == NULL) {
- warn("%s", fn);
- return NULL;
- }
-
- if ((bio = BIO_new_fp(f, BIO_CLOSE)) == NULL) {
- cryptowarnx("%s: BIO_new_fp", fn);
+ /* just fail for empty buffers, the warning was printed elsewhere */
+ if (der == NULL)
return NULL;
- }
- if ((cms = d2i_CMS_bio(bio, NULL)) == NULL) {
+ if ((cms = d2i_CMS_ContentInfo(NULL, , derlen)) == NULL) {
cryptowarnx("%s: RFC 6488: failed CMS parse", fn);
goto out;
}
@@ -74,8 +62,8 @@ cms_parse_validate(X509 **xp, const char
* Verify that the self-signage is correct.
*/
- if (!CMS_verify(cms, NULL, NULL,
- NULL, NULL, CMS_NO_SIGNER_CERT_VERIFY)) {
+ if (!CMS_verify(cms, NULL, NULL, NULL, NULL,
+ CMS_NO_SIGNER_CERT_VERIFY)) {
cryptowarnx("%s: RFC 6488: CMS not self-signed", fn);
goto out;
}
@@ -134,7 +122,6 @@ cms_parse_validate(X509 **xp, const char
rc = 1;
out:
- BIO_free_all(bio);
sk_X509_free(certs);
CMS_ContentInfo_free(cms);
Index: crl.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/crl.c,v
retrieving revision 1.10
diff -u -p -r1.10 crl.c
--- crl.c 29 Jan 2021 10:13:16 - 1.10
+++ crl.c 26 Oct 2021 09:43:18 -
@@ -29,32 +29,22 @@
#include "extern.h"
X509_CRL *
-crl_parse(const char *fn)
+crl_parse(const char *fn, const unsigned char *der, size_t len)
{
int rc = 0;
X509_CRL*x = NULL;
- BIO *bio = NULL;
- FILE*f;
- if ((f = fopen(fn, "rb")) == NULL) {
- warn("%s", fn);
+ /* just fail for empty buffers, the warning was printed elsewhere */
+ if (der == NULL)
return NULL;
- }
-
- if ((bio = BIO_new_fp(f, BIO_CLOSE)) == NULL) {
- if (verbose > 0)
- cryptowarnx("%s: BIO_new_file", fn);
- return NULL;
- }
- if ((x = d2i_X509_CRL_bio(bio, NULL)) == NULL) {
- cryptowarnx("%s: d2i_X509_CRL_bio", fn);
+ if ((x = d2i_X509_CRL(NULL, , len)) == NULL) {
+ cryptowarnx("%s: d2i_X509_CRL", fn);
goto out;
}
rc = 1;
out:
- BIO_free_all(bio);
if (rc == 0) {
X509_CRL_free(x);
x = NULL;
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.77
diff -u -p -r1.77 extern.h
--- extern.h24 Oct 2021 17:53:07 - 1.77
+++ extern.h25 Oct 2021 18:42:49 -
@@ -410,22 +410,25 @@ void cert_insert_brks(struct brk_tree
voidmft_buffer(struct ibuf *, const struct mft *);
voidmft_free(struct mft *);
-struct mft *mft_parse(X509 **, const char *);
+struct mft *mft_parse(X509 **, const char *, const unsigned char *,
+ size_t);
int mft_check(const char *, struct mft *);
struct mft *mft_read(struct ibuf *);
voidroa_buffer(struct ibuf *, const struct roa *);
voidroa_free(struct roa *);
-struct roa *roa_parse(X509 **, const char *);
+struct roa *roa_parse(X509 **, const char *, const unsigned char *,
+
Re: upd(4) page fault since 7.0
Le 24/10/2021 à 21:45, Anton Lindqvist a écrit :
On Sun, Oct 24, 2021 at 03:03:01PM +0200, Damien Couderc wrote:
Hi,
I got a page fault with upd(4) since 7.0.
The problem began with the last revision of upd.c (1.30):
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- src/sys/dev/usb/upd.c 2021/03/08 14:35:57 1.29
+++ src/sys/dev/usb/upd.c 2021/08/06 17:46:45 1.30
@@ -1,4 +1,4 @@
-/* $OpenBSD: upd.c,v 1.29 2021/03/08 14:35:57 jcs Exp $ */
+/* $OpenBSD: upd.c,v 1.30 2021/08/06 17:46:45 abieber Exp $ */
/*
* Copyright (c) 2015 David Higgs
@@ -167,7 +167,7 @@
if (upd_lookup_usage_entry(desc, size,
upd_usage_roots + i, )) {
ret = UMATCH_VENDOR_PRODUCT;
- break;
+ uha->claimed[item.report_ID] = 1;
}
return (ret);
===
The uha.claimed array is allocated using uha.nreports as its size while
upd_match() is looping through the number of items of upd_usage_roots.
In my case uha.nreports is equal to zero so uha.claimed is null, hence
setting uha->claimed[n] is failing.
As I'm not familiar with the HID code I did not yet understood the
relation between upd_usage_roots and the claimed array but as we're
talking about UPS attached computers I though the issue would sensible
enough to make a quick reporting.
You'll find a dmesg with options UPD_DEBUG and UHIDEV_DEBUG set and the
following patch applied to circumvent the page fault and provide some debug:
Could you try the following diff, looks like an unsigned wrap around.
Index: dev/usb/uhidev.h
===
RCS file: /cvs/src/sys/dev/usb/uhidev.h,v
retrieving revision 1.32
diff -u -p -r1.32 uhidev.h
--- dev/usb/uhidev.h12 Sep 2021 06:58:08 - 1.32
+++ dev/usb/uhidev.h24 Oct 2021 19:44:52 -
@@ -82,7 +82,7 @@ struct uhidev_attach_arg {
struct uhidev_softc *parent;
uint8_t reportid;
#define UHIDEV_CLAIM_MULTIPLE_REPORTID 255
- uint8_t nreports;
+ u_intnreports;
uint8_t *claimed;
};
Hello Anton,
I made a quick test and nreports is now set with 256 but I still get the
page fault.
I'll check the details ASAP.
Thank you,
Damien
Re: ixl(4): add rx/tx checksum offloading
Hi Jan,
First of all, thanks for looking at this, I forgot we hadn't done offloads
for ixl(4) yet.
On Mon, Oct 25, 2021 at 05:27:28PM +0200, Jan Klemkow wrote:
> On Fri, Oct 22, 2021 at 03:39:01PM +0200, Hrvoje Popovski wrote:
> > On 22.10.2021. 13:39, Jan Klemkow wrote:
> > > Thats because, you only see this flags, if the checksum offloading is
> > > enabled for "sending". I'm still working/debugging on the sending side.
> > > Thus, I just send a diff with the receiving part for now.
> > >
> > > You can see if its working for your card with the netstat(8) statistics.
> > >
> > > # netstat -s | grep software-checksummed
> > >
> > > These counters should not raise much on the receive side if you put some
> > > traffic over the interface.
> >
> > Thank you for explanation...
> >
> > I'm sending 8 tcp streams with iperf3 from some box to openbsd ixl box
> > and here are results:
> >
> > without diff
> > smc24# netstat -s | grep software-checksummed
> > 5039250 input datagrams software-checksummed
> > 2592718 output datagrams software-checksummed
> > 2592709 packets software-checksummed
> > 5039250 packets software-checksummed
> > 0 input packets software-checksummed
> > 0 output packets software-checksummed
> >
> > cca 6.12 Gbits/sec
> >
> >
> >
> > with diff
> > smc24# netstat -s | grep software-checksummed
> > 0 input datagrams software-checksummed
> > 2956546 output datagrams software-checksummed
> > 2956537 packets software-checksummed
> > 0 packets software-checksummed
> > 0 input packets software-checksummed
> > 0 output packets software-checksummed
> >
> > cca 6.70 Gbits/sec
> >
> > are result like those expected?
> >
> > is forwarding testing any good for checksum offload diffs?
>
> Hi Hrvoje,
>
> Thanks a lot for you big testing efforts!
>
> In case of forwarding the forwarding box just checks the IPv4 header
> checksum and ignores the UDP/TCP header. Your setup from one Box to
> another is fine.
>
> Here is a new diff, which also includes send checksum offloading.
> Thus, all software-checksummed numbers should stay low in both
> directions.
>
> Could you test this diff with your ospf{6}d and NFS tests?
> If you see IPv4 fragments in the ospf and NFS traffic within tcpdump(8),
> your test should find the bugs pointed out by deraadt@ and claudio@.
In the case of ixl(4), the driver has to tell the nic the length of each of the
packet headers, so it should also be tested with vlan interfaces.
I think ixl_tx_setup_offload() needs to account for outgoing vlan-tagged
packets.
It currently assumes the ethernet header is ETHER_HDR_LEN bytes long, which
isn't
always true. See ixgbe_tx_ctx_setup() (sys/dev/pci/if_ix.c) for an example of
a driver that takes this into account.
>
> You can provoke large NFS packets with the following options on your NFS
> mount point.
>
> server:/export /mnt nfs ro,intr,-r65536,-w65536
>
> Thanks,
> Jan
>
> Index: dev/pci/if_ixl.c
> ===
> RCS file: /mount/openbsd/cvs/src/sys/dev/pci/if_ixl.c,v
> retrieving revision 1.75
> diff -u -p -r1.75 if_ixl.c
> --- dev/pci/if_ixl.c 23 Jul 2021 00:29:14 - 1.75
> +++ dev/pci/if_ixl.c 25 Oct 2021 15:11:46 -
> @@ -82,6 +82,10 @@
> #endif
>
> #include
> +#include
> +#include
> +#include
> +#include
> #include
>
> #include
> @@ -1388,6 +1392,7 @@ static int ixl_rxeof(struct ixl_softc *,
> static void ixl_rxfill(struct ixl_softc *, struct ixl_rx_ring *);
> static void ixl_rxrefill(void *);
> static int ixl_rxrinfo(struct ixl_softc *, struct if_rxrinfo *);
> +static void ixl_rx_checksum(struct mbuf *, uint64_t);
>
> #if NKSTAT > 0
> static void ixl_kstat_attach(struct ixl_softc *);
> @@ -1942,9 +1947,9 @@ ixl_attach(struct device *parent, struct
> ifp->if_capabilities = IFCAP_VLAN_MTU;
> #if 0
> ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING;
> - ifp->if_capabilities |= IFCAP_CSUM_IPv4 | IFCAP_CSUM_TCPv4 |
> - IFCAP_CSUM_UDPv4;
> #endif
> + ifp->if_capabilities |= IFCAP_CSUM_IPv4 | IFCAP_CSUM_TCPv4 |
> + IFCAP_CSUM_UDPv4 | IFCAP_CSUM_TCPv6 | IFCAP_CSUM_UDPv6;
>
> ifmedia_init(>sc_media, 0, ixl_media_change, ixl_media_status);
>
> @@ -2772,6 +2777,69 @@ ixl_load_mbuf(bus_dma_tag_t dmat, bus_dm
> }
>
> static void
> +ixl_tx_setup_offload(struct mbuf *mp, uint64_t *cmd)
> +{
> + uint64_t ip_hdr_len;
> + int ipoff = ETHER_HDR_LEN;
> + uint8_t ipproto;
> + struct ip *ip;
> +#ifdef INET6
> + struct ip6_hdr *ip6;
> +#endif
> + struct tcphdr *th;
> + struct mbuf *m;
> +
> + switch (ntohs(mtod(mp, struct ether_header *)->ether_type)) {
> + case ETHERTYPE_IP:
> + if (mp->m_pkthdr.len < ETHER_HDR_LEN + sizeof(*ip))
> + return;
> +
