ixl(4): add missing pci dev id for X710 10GBase-T

2021-02-26 Thread Jan Klemkow
Hi,

The diff below adds a missing PCI device ID for an X710 10GBase NIC into
the ixl(4) driver.  The interfaces attach and run properly with this
diff.

ixl0 at pci11 dev 0 function 0 "Intel X710 10GBaseT" rev 0x02: port 0, FW 
8.1.63299 API 1.12, msix, 8 queues, address 3c:ec:ef:1f:c3:ba
ixl1 at pci11 dev 0 function 1 "Intel X710 10GBaseT" rev 0x02: port 2, FW 
8.1.63299 API 1.12, msix, 8 queues, address 3c:ec:ef:1f:c3:bb

# ifconfig ixl
ixl0: flags=8843 mtu 1500
lladdr 3c:ec:ef:1f:c3:ba
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.123.1 netmask 0xff00 broadcast 192.168.123.255
ixl1: flags=8843 mtu 1500
lladdr 3c:ec:ef:1f:c3:bb
index 2 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.124.1 netmask 0xff00 broadcast 192.168.124.255

OK?

bye,
Jan

Index: dev/pci/if_ixl.c
===
RCS file: /cvs/src/sys/dev/pci/if_ixl.c,v
retrieving revision 1.72
diff -u -p -r1.72 if_ixl.c
--- dev/pci/if_ixl.c25 Jan 2021 11:11:22 -  1.72
+++ dev/pci/if_ixl.c26 Feb 2021 09:51:56 -
@@ -1622,6 +1622,7 @@ static const struct ixl_device ixl_devic
{ _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_T4_10G },
{ _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_XXV710_25G_BP },
{ _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_XXV710_25G_SFP28, },
+   { _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_10G_T, },
{ _722, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X722_10G_KX },
{ _722, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X722_10G_QSFP },
{ _722, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X722_10G_SFP_1 },
Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1956
diff -u -p -r1.1956 pcidevs
--- dev/pci/pcidevs 22 Feb 2021 01:17:23 -  1.1956
+++ dev/pci/pcidevs 26 Feb 2021 09:49:01 -
@@ -3962,6 +3962,7 @@ product INTEL I219_V140x15fa  I219-V
 product INTEL I219_LM130x15fb  I219-LM
 product INTEL I219_V13 0x15fc  I219-V
 product INTEL I225_BLANK_NVM   0x15fd  I225
+product INTEL X710_10G_T   0x15ff  X710 10GBaseT
 product INTEL CORE5G_H_PCIE_X160x1601  Core 5G PCIE
 product INTEL CORE5G_M_GT1_1   0x1602  HD Graphics
 product INTEL CORE5G_THERM 0x1603  Core 5G Thermal
Index: dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1949
diff -u -p -r1.1949 pcidevs.h
--- dev/pci/pcidevs.h   22 Feb 2021 01:18:01 -  1.1949
+++ dev/pci/pcidevs.h   26 Feb 2021 09:49:05 -
@@ -3967,6 +3967,7 @@
 #definePCI_PRODUCT_INTEL_I219_LM13 0x15fb  /* I219-LM */
 #definePCI_PRODUCT_INTEL_I219_V13  0x15fc  /* I219-V */
 #definePCI_PRODUCT_INTEL_I225_BLANK_NVM0x15fd  /* I225 
*/
+#definePCI_PRODUCT_INTEL_X710_10G_T0x15ff  /* X710 
10GBaseT */
 #definePCI_PRODUCT_INTEL_CORE5G_H_PCIE_X16 0x1601  /* Core 
5G PCIE */
 #definePCI_PRODUCT_INTEL_CORE5G_M_GT1_10x1602  /* HD 
Graphics */
 #definePCI_PRODUCT_INTEL_CORE5G_THERM  0x1603  /* Core 5G 
Thermal */
Index: dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1944
diff -u -p -r1.1944 pcidevs_data.h
--- dev/pci/pcidevs_data.h  22 Feb 2021 01:18:01 -  1.1944
+++ dev/pci/pcidevs_data.h  26 Feb 2021 09:49:05 -
@@ -13292,6 +13292,10 @@ static const struct pci_known_product pc
"I225",
},
{
+   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_10G_T,
+   "X710 10GBaseT",
+   },
+   {
PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_CORE5G_H_PCIE_X16,
"Core 5G PCIE",
},



Re: LibreSSL legacy verifier regression

2021-02-25 Thread Jan Klemkow
On Wed, Feb 24, 2021 at 09:21:56PM +0100, Theo Buehler wrote:
> On Wed, Feb 24, 2021 at 09:00:05PM +0100, Theo Buehler wrote:
> > On Wed, Feb 24, 2021 at 06:47:00AM +0100, Jan Klemkow wrote:
> > > another co-worker of mine has found an other regress in the LibreSSL
> > > legacy verifier.  I took his diff and made a test for our regression
> > > framework.
> > > 
> > > The legacy verifier seems not to check the certificate if no root CA was
> > > given.  The following test creates an expired certificate and tries to
> > > verify it.  In one case it found the expected error in another, it does
> > > not.
> > 
> > Thanks for the report and the test case, that's very helpful. The diff
> > at the end addresses this.
> > 
> > The verifier does not find the expected error because it now bails out
> > earlier.  This is a consequence of a refactoring of X509_verify_cert()
> > (x509_vfy.c r1.75) that was done to integrate the new verifier.
> > 
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c.diff?r1=1.74=1.75
> > 
> > What happens is that x509_legacy_verify_build_chain() returns ok == 0 in
> > your test case. The safety net at the end of x509_verify_cert_legacy()
> > sets ctx->error to X509_V_ERR_UNSPECIFIED (so the unchecked call to
> > X509_verify_cert() in your regress test actually indicates verification
> > failure).
> > 
> > 
> > The diff below restores the previous behavior and fixes a bug.
> > 
> > Prior to the the refactoring, each 'goto end' in the code that is now in
> > x509_legacy_verify_build_chain() would stop validation, while in other
> > cases validation would have carried on. So indicate this via the return
> > value and return ok via a pointer.
> > 
> > The bug is that the return value check of x509_legacy_verify_build_chain()
> > should have been if (ok <= 0), not if (!ok).
> > 
> > Regarding your regress diff: I don't think we want to land it as it is.

Ok.

> > The verifier lives in libcrypto/x509, so the regress test belongs in
> > there.

You are right, its the better place.  At least I want to send you a bug
report with concrete code to test.

> > We really need to come up with an extensible design that can check a
> > number of such cases (and ideally includes the bulk of your openssl/x509
> > regress tests). I don't want to add a directory for every bug in the
> > verifier or legacy verifier. As jsing already mentioned, I expect that
> > we want to commit the test certs so we don't need perl modules from
> > ports to run the regress. Then we want to add generating scripts and a
> > README that gives instructions on how to regenerate the certs if needed.
> > 
> > I would like to have one C program that runs all tests in a loop (or
> > perhaps one C program per family of regressions). It would be nice if
> > this C program could also be compiled against OpenSSL 1.1.1 so we can
> > easily check for differences of behavior (see x509/bettertls/Makefile
> > for an example that does this).  For your test program this just means:
> > don't access csc->blah, but use X509_STORE_CTX_get_blah(csc) instead.
> > 
> > Why does the test set TRUSTED_FIRST?

I just forget to remove the this line, from the original version.

> > The code also needs a bit of cleaning. There are a number of unchecked
> > return values, for example strdup and sk_*_push, and csc is leaked
> > after X509_verify_cert().
> > 
> > It would also be nice to run this test against the new verifier.

The test passes with the new verifier in current, but not in 6.8.

> Missed an obvious simplification.

The diff looks fine to me and it fixes our regressions.
I would give you an OK jan, fwiw.

Thanks,
Jan

> Index: x509/x509_vfy.c
> ===
> RCS file: /cvs/src/lib/libcrypto/x509/x509_vfy.c,v
> retrieving revision 1.85
> diff -u -p -r1.85 x509_vfy.c
> --- x509/x509_vfy.c   11 Feb 2021 04:56:43 -  1.85
> +++ x509/x509_vfy.c   24 Feb 2021 20:19:34 -
> @@ -240,12 +240,13 @@ x509_vfy_check_id(X509_STORE_CTX *ctx) {
>   * Oooh..
>   */
>  static int
> -X509_verify_cert_legacy_build_chain(X509_STORE_CTX *ctx, int *bad)
> +X509_verify_cert_legacy_build_chain(X509_STORE_CTX *ctx, int *bad, int 
> *out_ok)
>  {
>   X509 *x, *xtmp, *xtmp2, *chain_ss = NULL;
>   int bad_chain = 0;
>   X509_VERIFY_PARAM *param = ctx->param;
> - int depth, i, ok = 0;
> + int ok = 0, ret = 0;
> + int depth, i;
>   int num, j, retry, trust;
>   int (*cb) (int xok, X509

fix nvme(4): NULL deref. and empty device attachments

2021-02-24 Thread Jan Klemkow
Hi,

While attaching the following disks, the nvme driver runs into a NULL
dereference in nvme_scsi_capacity16() and nvme_scsi_capacity().

nvme0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 0x00: 
msix, NVMe 1.2
nvme0: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ0413002P4P0DGN
scsibus1 at nvme0: 129 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: 
sd0: 3815447MB, 512 bytes/sector, 7814037168 sectors
sd1 at scsibus1 targ 2 lun 0: 
uvm_fault(0x821d00e8, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  nvme_scsi_capacity16+0x39:  movq0(%rax),%rcx
ddb{0}>

"ns" in both functions will be NULL, if "identify" is not allocated in
nvme_scsi_probe().  Thus, its better to just not attach this empty
disks/LUNs.

nvme0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 0x00: 
msix, NVMe 1.2
nvme0: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ0413002P4P0DGN
scsibus1 at nvme0: 129 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: 
sd0: 3815447MB, 512 bytes/sector, 7814037168 sectors
ppb1 at pci0 dev 3 function 2 "AMD 17h PCIE" rev 0x00: msi
pci2 at ppb1 bus 98
nvme1 at pci2 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 0x00: 
msix, NVMe 1.2
nvme1: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ041500C34P0DGN
scsibus2 at nvme1: 129 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: 
sd1: 3815447MB, 512 bytes/sector, 7814037168 sectors
ppb2 at pci0 dev 3 function 3 "AMD 17h PCIE" rev 0x00: msi
pci3 at ppb2 bus 99
nvme2 at pci3 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 0x00: 
msix, NVMe 1.2
nvme2: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ041402Z64P0DGN
scsibus3 at nvme2: 129 targets, initiator 0
sd2 at scsibus3 targ 1 lun 0: 
sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors
ppb3 at pci0 dev 3 function 4 "AMD 17h PCIE" rev 0x00: msi
pci4 at ppb3 bus 100
nvme3 at pci4 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 0x00: 
msix, NVMe 1.2
nvme3: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ041403134P0DGN
scsibus4 at nvme3: 129 targets, initiator 0
sd3 at scsibus4 targ 1 lun 0: 
sd3: 3815447MB, 512 bytes/sector, 7814037168 sectors

The following diff signals an error for the upper probing function in
the SCSI layer to prevents further function calls in nvme(4) which would
just leads to the upper described error and hundreds of not configured
devices.

OK?

bye,
Jan

Index: dev/ic/nvme.c
===
RCS file: /cvs//src/sys/dev/ic/nvme.c,v
retrieving revision 1.90
diff -u -p -r1.90 nvme.c
--- dev/ic/nvme.c   9 Feb 2021 01:50:10 -   1.90
+++ dev/ic/nvme.c   24 Feb 2021 16:01:48 -
@@ -463,11 +463,16 @@ nvme_scsi_probe(struct scsi_link *link)
scsi_io_put(>sc_iopool, ccb);
 
identify = NVME_DMA_KVA(mem);
-   if (rv == 0 && lemtoh64(>nsze) > 0) {
-   /* Commit namespace if it has a size greater than zero. */
-   identify = malloc(sizeof(*identify), M_DEVBUF, M_WAITOK);
-   memcpy(identify, NVME_DMA_KVA(mem), sizeof(*identify));
-   sc->sc_namespaces[link->target].ident = identify;
+   if (rv == 0) {
+   if (lemtoh64(>nsze) > 0) {
+   /* Commit namespace if it has a size greater than zero. 
*/
+   identify = malloc(sizeof(*identify), M_DEVBUF, 
M_WAITOK);
+   memcpy(identify, NVME_DMA_KVA(mem), sizeof(*identify));
+   sc->sc_namespaces[link->target].ident = identify;
+   } else {
+   /* Don't attach a namespace if its size is zero. */
+   rv = ENXIO;
+   }
}
 
nvme_dmamem_free(sc, mem);



LibreSSL legacy verifier regression

2021-02-24 Thread Jan Klemkow
Hi,

another co-worker of mine has found an other regress in the LibreSSL
legacy verifier.  I took his diff and made a test for our regression
framework.

The legacy verifier seems not to check the certificate if no root CA was
given.  The following test creates an expired certificate and tries to
verify it.  In one case it found the expected error in another, it does
not.

OK?

bye,
Jan

Index: lib/libcrypto/Makefile
===
RCS file: /cvs/src/regress/lib/libcrypto/Makefile,v
retrieving revision 1.41
diff -u -p -r1.41 Makefile
--- lib/libcrypto/Makefile  26 Dec 2020 00:48:56 -  1.41
+++ lib/libcrypto/Makefile  24 Feb 2021 05:29:51 -
@@ -23,6 +23,7 @@ SUBDIR += ecdsa
 SUBDIR += engine
 SUBDIR += evp
 SUBDIR += exp
+SUBDIR += expcert
 SUBDIR += free
 SUBDIR += gcm128
 SUBDIR += gost
Index: lib/libcrypto/expcert/Makefile
===
RCS file: lib/libcrypto/expcert/Makefile
diff -N lib/libcrypto/expcert/Makefile
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lib/libcrypto/expcert/Makefile  24 Feb 2021 05:39:38 -
@@ -0,0 +1,29 @@
+# $OpenBSD$
+
+LDFLAGS += -lcrypto
+
+PROG = expcrt
+
+PKG_REQUIRE != pkg_info -e 'p5-IO-Socket-SSL-*'
+.if empty (PKG_REQUIRE)
+regress:
+   @echo "missing package p5-IO-Socket-SSL"
+   @echo SKIPPED
+.endif
+
+REGRESS_TARGETS =  test-chain-with-root-CA
+REGRESS_TARGETS += test-chain-without-root-CA
+REGRESS_SETUP_ONCE =   create-certs
+
+REGRESS_EXPECTED_FAILURES = test-chain-without-root-CA
+
+create-certs: create-certs.pl ${PROG}
+   perl ${.CURDIR}/create-certs.pl
+
+test-chain-with-root-CA:
+   ./expcrt -e 10 -r
+
+test-chain-without-root-CA:
+   ./expcrt -e 10
+
+.include 
Index: lib/libcrypto/expcert/create-certs.pl
===
RCS file: lib/libcrypto/expcert/create-certs.pl
diff -N lib/libcrypto/expcert/create-certs.pl
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lib/libcrypto/expcert/create-certs.pl   24 Feb 2021 05:27:46 -
@@ -0,0 +1,46 @@
+#!/usr/bin/perl
+
+# Copyright (c) 2021 Anton Borowka 
+#
+# 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.
+
+use strict;
+use warnings;
+
+use IO::Socket::SSL::Utils;
+
+my %certs;
+
+@{$certs{root}}{qw/cert key/} = CERT_create(
+CA => 1,
+not_after => time() + 31536,
+subject => { commonName => 'Root CA' },
+);
+
+@{$certs{intermediate}}{qw/cert key/} = CERT_create(
+CA => 1,
+issuer => [@{$certs{root}}{qw/cert key/}],
+not_after => time() + 31536,
+subject => { commonName => 'Intermediate CA' },
+);
+
+@{$certs{expired}}{qw/cert key/} = CERT_create(
+issuer => [@{$certs{intermediate}}{qw/cert key/}],
+not_before => time() - 7200,
+not_after => time() - 3600,
+subject => { commonName => 'Expired' },
+);
+
+for (sort keys %certs) {
+PEM_cert2file($certs{$_}{cert}, "$_.crt");
+}
Index: lib/libcrypto/expcert/expcrt.c
===
RCS file: lib/libcrypto/expcert/expcrt.c
diff -N lib/libcrypto/expcert/expcrt.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lib/libcrypto/expcert/expcrt.c  24 Feb 2021 05:27:46 -
@@ -0,0 +1,218 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2021 Jan Klemkow 
+ * Copyright (c) 2021 Anton Borowka 
+ *
+ * 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 
+#

Re: LibreSSL regressions

2021-02-16 Thread Jan Klemkow
On Tue, Feb 16, 2021 at 04:36:59AM +1100, Joel Sing wrote:
> On 21-02-15 14:49:46, Jan Klemkow wrote:
> > On Sat, Feb 13, 2021 at 03:53:48PM +0100, Theo Buehler wrote:
> > > On Sat, Feb 13, 2021 at 11:58:04AM +0100, Jan Klemkow wrote:
> > > > A coworker of mine has made tests with LibreSSL [1] and found some
> > > > regressions.  I took his test descriptions and created the following
> > > > automated regression test.  In the repository he described his findings
> > > > in detail.  I kept the numbers of the files and subtests in the target
> > > > names for now.  So, its easier to match it with his files.
> > > > 
> > > > I don't know how to handle the result of "test-01-ssl".  Thats why its
> > > > just a comment.  Someone may have an idea to handle this properly.
> > > > 
> > > > Any comments, wishes or OK's?
> > > > 
> > > > [1]: https://github.com/noxxi/libressl-tests
> > > 
> > > First of all thanks for the effort!
> > > 
> > > The perl script and probably also the Makefile should have a license.
> > > 
> > > Please add a check that tests whether the required perl modules are
> > > installed (p5-IO-Socket-SSL and p5-Net-SSLeay) and otherwise prints
> > > SKIPPED and their names, so I can install them if they're not present.
> > > I never remember their exact capitalization and hyphenation...
> > > 
> > > Various comments inline, and a patch for openssl(1) at the end that may
> > > simplify some things.
> > 
> > This is an updated version of the test including comments and wishes
> > from tb@ and bluhm@.
> > 
> > OK?
> 
> This currently drives openssl(1) for tests, which means that it is
> testing openssl(1), libssl and libcrypto, when what you're really
> wanting to test is libcrypto's verifier. While this works, the
> problem is that a change or breakage in libssl or openssl(1) results
> in a regress failure for libcrypto. If this is to land in its
> current form it really should be in regress/usr.bin/openssl -
> alternatively, it could be reworked to explicitly test libcrypto's
> APIs and remain here.
> 
> Some additional comments inline.

So, the following diff should hit all needs.

OK?

Thanks,
Jan

Index: usr.bin/openssl/Makefile
===
RCS file: /cvs/src/regress/usr.bin/openssl/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- usr.bin/openssl/Makefile19 Mar 2018 03:41:40 -  1.6
+++ usr.bin/openssl/Makefile15 Feb 2021 20:37:11 -
@@ -1,6 +1,6 @@
 #  $OpenBSD: Makefile,v 1.6 2018/03/19 03:41:40 beck Exp $
 
-SUBDIR= options
+SUBDIR= options x509
 
 CLEANFILES+= testdsa.key testdsa.pem rsakey.pem rsacert.pem dsa512.pem
 CLEANFILES+= appstest_dir
Index: usr.bin/openssl/x509/Makefile
===
RCS file: usr.bin/openssl/x509/Makefile
diff -N usr.bin/openssl/x509/Makefile
--- /dev/null   1 Jan 1970 00:00:00 -
+++ usr.bin/openssl/x509/Makefile   16 Feb 2021 12:06:10 -
@@ -0,0 +1,129 @@
+# $OpenBSD$
+
+# Copyright (c) 2021 Jan Klemkow 
+#
+# 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.
+
+# This regression test is based on manual test descriptions from:
+# https://github.com/noxxi/libressl-tests
+
+# The following port must be installed for the regression tests:
+# p5-IO-Socket-SSL perl interface to SSL sockets
+
+PERL = perl
+OPENSSL ?= openssl
+
+PKG_REQUIRE != pkg_info -e 'p5-IO-Socket-SSL-*'
+.if empty (PKG_REQUIRE)
+regress:
+   @echo "missing package p5-IO-Socket-SSL"
+   @echo SKIPPED
+.endif
+
+REGRESS_TARGETS += test-inlabel-wildcard-cert-no-CA-client
+REGRESS_TARGETS += test-inlabel-wildcard-cert-CA-client
+REGRESS_TARGETS += test-common-wildcard-cert-no-CA-client
+REGRESS_TARGETS += test-common-wildcard-cert-CA-client
+REGRESS_TARGETS += test-verify-unusual-wildcard-cert
+REGRESS_TARGETS += test-openssl-verify-common-wildcard-cert
+REGRESS_TARGETS += t

Re: LibreSSL regressions

2021-02-15 Thread Jan Klemkow
On Tue, Feb 16, 2021 at 04:36:59AM +1100, Joel Sing wrote:
> On 21-02-15 14:49:46, Jan Klemkow wrote:
> > +create-libressl-test-certs: create-libressl-test-certs.pl
> > +   ${PERL} ${.CURDIR}/$@.pl
> 
> We can see how this goes, however we may end up wanting to generate
> the certificates and commit them rather than regenerating on each
> run. The other advantage is that p5-IO-Socket-SSL would only be
> needed to regenerate the certificates and not actually run the
> tests.

What should I do?  Just commit the generated files and remove the Perl
script?

> > Index: regress/lib/libcrypto/validate/create-libressl-test-certs.pl
> > ===
> > RCS file: regress/lib/libcrypto/validate/create-libressl-test-certs.pl
> > diff -N regress/lib/libcrypto/validate/create-libressl-test-certs.pl
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ regress/lib/libcrypto/validate/create-libressl-test-certs.pl15 Feb 
> > 2021 12:54:58 -
> > @@ -0,0 +1,111 @@
> > +#!/usr/bin/perl
> > +
> > +# Copyright (c) 2021 Steffen Ullrich 
> > +# Public Domain
> > +
> > +use strict;
> > +use warnings;
> > +use IO::Socket::SSL::Utils;
> > +
> > +# primitive CA - ROOT
> > +my @ca = cert(
> > +CA => 1,
> > +subject => { CN => 'ROOT' }
> > +);
> > +out('caR.pem', pem(crt => $ca[0]));
> > +out('caR.key', pem(key => $ca[1]));
> > +
> > +# server certificate where SAN contains in-label wildcards which are 
> > allowed by
> > +# RFC 6125
> 
> It is worth noting that per the RFC, a client MAY allow in-label
> wildcards (this is not a MUST or even a SHOULD). Additionally,
> various software does not allow or support this (for example, libtls
> and hence ftp(1)).

What should I do here?

Thanks,
Jan



Re: LibreSSL regressions

2021-02-15 Thread Jan Klemkow
On Sat, Feb 13, 2021 at 03:53:48PM +0100, Theo Buehler wrote:
> On Sat, Feb 13, 2021 at 11:58:04AM +0100, Jan Klemkow wrote:
> > A coworker of mine has made tests with LibreSSL [1] and found some
> > regressions.  I took his test descriptions and created the following
> > automated regression test.  In the repository he described his findings
> > in detail.  I kept the numbers of the files and subtests in the target
> > names for now.  So, its easier to match it with his files.
> > 
> > I don't know how to handle the result of "test-01-ssl".  Thats why its
> > just a comment.  Someone may have an idea to handle this properly.
> > 
> > Any comments, wishes or OK's?
> > 
> > [1]: https://github.com/noxxi/libressl-tests
> 
> First of all thanks for the effort!
> 
> The perl script and probably also the Makefile should have a license.
> 
> Please add a check that tests whether the required perl modules are
> installed (p5-IO-Socket-SSL and p5-Net-SSLeay) and otherwise prints
> SKIPPED and their names, so I can install them if they're not present.
> I never remember their exact capitalization and hyphenation...
> 
> Various comments inline, and a patch for openssl(1) at the end that may
> simplify some things.

This is an updated version of the test including comments and wishes
from tb@ and bluhm@.

OK?

Thanks,
Jan

Index: regress/lib/libcrypto/validate/Makefile
===
RCS file: regress/lib/libcrypto/validate/Makefile
diff -N regress/lib/libcrypto/validate/Makefile
--- /dev/null   1 Jan 1970 00:00:00 -
+++ regress/lib/libcrypto/validate/Makefile 15 Feb 2021 13:38:22 -
@@ -0,0 +1,133 @@
+# $OpenBSD$
+
+# Copyright (c) 2021 Jan Klemkow 
+#
+# 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.
+
+# This regression test is based on manual test descriptions from:
+# https://github.com/noxxi/libressl-tests
+
+# The following port must be installed for the regression tests:
+# p5-IO-Socket-SSL perl interface to SSL sockets
+
+PERL = perl
+OPENSSL ?= openssl
+
+PERL_REQUIRE !=perl -Mstrict -Mwarnings -e ' \
+eval { require IO::Socket::SSL } or print $@; \
+'
+.if ! empty (PERL_REQUIRE)
+regress:
+   @echo "${PERL_REQUIRE}"
+   @echo install these perl packages for additional tests
+   @echo SKIPPED
+.endif
+
+REGRESS_TARGETS += test-unusual-wildcard-cert-no-CA-client
+REGRESS_TARGETS += test-unusual-wildcard-cert-CA-client
+REGRESS_TARGETS += test-common-wildcard-cert-no-CA-client
+REGRESS_TARGETS += test-common wildcard-cert-CA-client
+REGRESS_TARGETS += test-verify-unusual-wildcard-cert
+REGRESS_TARGETS += test-openssl-verify-common-wildcard-cert
+REGRESS_TARGETS += test-chain-certificates-s_server
+REGRESS_TARGETS += test-alternative-chain
+REGRESS_CLEANUP =  cleanup-ssl
+REGRESS_SETUP_ONCE =   create-libressl-test-certs
+
+REGRESS_EXPECTED_FAILURES +=   test-unusual-wildcard-cert-no-CA-client
+REGRESS_EXPECTED_FAILURES +=   test-common-wildcard-cert-no-CA-client
+REGRESS_EXPECTED_FAILURES +=   test-common wildcard-cert-CA-client
+REGRESS_EXPECTED_FAILURES +=   test-verify-unusual-wildcard-cert
+REGRESS_EXPECTED_FAILURES +=   test-alternative-chain
+
+create-libressl-test-certs: create-libressl-test-certs.pl
+   ${PERL} ${.CURDIR}/$@.pl
+
+cleanup-ssl:
+   rm *.pem *.key
+
+test-unusual-wildcard-cert-no-CA-client:
+   # unusual wildcard cert, no CA given to client
+   # start client
+   ${OPENSSL} s_server -cert server-unusual-wildcard.pem \
+   -key server-unusual-wildcard.pem & \
+   timeout=$$(($$(date +%s) + 5)); \
+   while fstat -p $$! | ! grep -q 'tcp .* \*:4433$$'; \
+   do test $$(date +%s) -lt $$timeout || exit 1; done
+   # start client
+   echo "Q" | ${OPENSSL} s_client -verify_return_error \
+   | grep "Verify return code: 21"
+
+test-unusual-wildcard-cert-CA-client:
+   # unusual wildcard cert, CA given to client
+   # start server
+   ${OPENSSL} s_server -cert server-unusual-wildcard.pem \
+   -key server-unusual-wildcard.pem & \
+ 

LibreSSL regressions

2021-02-13 Thread Jan Klemkow
Hi,

A coworker of mine has made tests with LibreSSL [1] and found some
regressions.  I took his test descriptions and created the following
automated regression test.  In the repository he described his findings
in detail.  I kept the numbers of the files and subtests in the target
names for now.  So, its easier to match it with his files.

I don't know how to handle the result of "test-01-ssl".  Thats why its
just a comment.  Someone may have an idea to handle this properly.

Any comments, wishes or OK's?

bye,
Jan

[1]: https://github.com/noxxi/libressl-tests

Index: regress/lib/libssl/Makefile
===
RCS file: /cvs/src/regress/lib/libssl/Makefile,v
retrieving revision 1.42
diff -u -p -r1.42 Makefile
--- regress/lib/libssl/Makefile 14 Oct 2020 15:53:22 -  1.42
+++ regress/lib/libssl/Makefile 12 Feb 2021 19:42:56 -
@@ -16,6 +16,7 @@ SUBDIR += tlsext
 SUBDIR += tlslegacy
 SUBDIR += key_schedule
 SUBDIR += unit
+SUBDIR += validate
 
 # Things that take a long time should go below here. 
 SUBDIR += tlsfuzzer
Index: regress/lib/libssl/validate/Makefile
===
RCS file: regress/lib/libssl/validate/Makefile
diff -N regress/lib/libssl/validate/Makefile
--- /dev/null   1 Jan 1970 00:00:00 -
+++ regress/lib/libssl/validate/Makefile13 Feb 2021 10:50:30 -
@@ -0,0 +1,104 @@
+# Tests from: https://github.com/noxxi/libressl-tests
+
+PERL=perl
+
+REGRESS_TARGETS =  test-00-01-ssl
+REGRESS_TARGETS += test-00-02-ssl
+REGRESS_TARGETS += test-00-03-ssl
+REGRESS_TARGETS += test-00-04-ssl
+REGRESS_TARGETS += test-00-05-ssl
+REGRESS_TARGETS += test-00-06-ssl
+REGRESS_TARGETS += test-01-ssl
+REGRESS_TARGETS += test-02-ssl
+REGRESS_ROOT_TARGETS = ${REGRESS_TARGETS}
+REGRESS_CLEANUP =  cleanup-ssl
+REGRESS_SETUP =create-libressl-test-certs
+
+create-libressl-test-certs: create-libressl-test-certs.pl
+   ${PERL} ${.CURDIR}/$@.pl
+
+cleanup-ssl:
+   pkill openssl || true
+   rm *.pem *.key
+
+test-00-01-ssl:
+   # unusual wildcard cert, no CA given to client
+   # cleanup
+   pkill openssl || true
+   sleep 2
+   # start client
+   ${KTRACE} openssl s_server -cert server-unusual-wildcard.pem \
+   -key server-unusual-wildcard.pem -www & \
+   timeout=$$(($$(date +%s) + 5)); \
+   while fstat -p $$! | ! grep -q 'tcp .* \*:4433$$'; \
+   do test $$(date +%s) -lt $$timeout || exit 1; done
+   # start client
+   echo "data" | openssl s_client -verify_return_error -connect 
127.0.0.1:4433 \
+   | grep "Verify return code: 21"
+
+test-00-02-ssl:
+   # unusual wildcard cert, CA given to client
+   # cleanup
+   pkill openssl || true
+   sleep 2
+   # start server
+   ${KTRACE} openssl s_server -cert server-unusual-wildcard.pem \
+   -key server-unusual-wildcard.pem -www & \
+   timeout=$$(($$(date +%s) + 5)); \
+   while fstat -p $$! | ! grep -q 'tcp .* \*:4433$$'; \
+   do test $$(date +%s) -lt $$timeout || exit 1; done
+   # start client
+   echo "data" | openssl s_client -connect 127.0.0.1:4433 -CAfile caR.pem \
+   | grep "Verify return code: 0"
+
+test-00-03-ssl:
+   # common wildcard cert, no CA given to client
+   # cleanup
+   pkill openssl || true
+   sleep 2
+   # start server
+   ${KTRACE} openssl s_server -cert server-common-wildcard.pem \
+   -key server-common-wildcard.pem -www & \
+   timeout=$$(($$(date +%s) + 5)); \
+   while fstat -p $$! | ! grep -q 'tcp .* \*:4433$$'; \
+   do test $$(date +%s) -lt $$timeout || exit 1; done
+   # start client
+   echo "data" | openssl s_client -connect 127.0.0.1:4433 \
+   | grep "Verify return code: 21"
+
+test-00-04-ssl:
+   # common wildcard cert, CA given to client
+   # cleanup
+   pkill openssl || true
+   sleep 2
+   # start server
+   ${KTRACE} openssl s_server -cert server-unusual-wildcard.pem \
+   -key server-unusual-wildcard.pem -www & \
+   timeout=$$(($$(date +%s) + 5)); \
+   while fstat -p $$! | ! grep -q 'tcp .* \*:4433$$'; \
+   do test $$(date +%s) -lt $$timeout || exit 1; done
+   # start client
+   echo "data" | openssl s_client -connect 127.0.0.1:4433 -CAfile caR.pem \
+   | grep "Verify return code: 21"
+
+test-00-05-ssl:
+   # openssl verify, unusual wildcard cert
+   openssl verify -CAfile caR.pem server-unusual-wildcard.pem \
+   | grep "server-unusual-wildcard.pem: OK"
+
+test-00-06-ssl:
+   # openssl verify, common wildcard cert
+   openssl verify -CAfile caR.pem server-common-wildcard.pem \
+   | grep "server-common-wildcard.pem: OK"
+
+test-01-ssl:
+   # Not all chain certificates are sent in s_server
+   # 

Re: diff: tcp ack improvement

2021-02-08 Thread Jan Klemkow
On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote:
> On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote:
> > Just commit it. OK claudio@
> > If people see problems we can back it out again.
> 
> This has huge impact on TCP performance.
> 
> http://bluhm.genua.de/perform/results/2021-02-07T00%3A01%3A40Z/perform.html
> 
> For a single TCP connection between to OpenBSD boxes, througput
> drops by 77% from 3.1 GBit/sec to 710 MBit/sec.  But with 100
> parallel connections the througput over all increases by 5%.

For single connections our kernel is limited to send out 4 max TCP
segments.  I don't see that, because I just measured with 10 and 30
streams in parallel.

FreeBSD disabled it 20 yeas ago.
https://github.com/freebsd/freebsd-src/commit/d912c694ee00de5ea0f46743295a0fc603cab562

I would suggest to remove the whole feature.

bye,
Jan

Index: tcp.h
===
RCS file: /cvs/src/sys/netinet/tcp.h,v
retrieving revision 1.21
diff -u -p -r1.21 tcp.h
--- tcp.h   10 Jul 2019 18:45:31 -  1.21
+++ tcp.h   8 Feb 2021 17:52:38 -
@@ -105,8 +105,6 @@ struct tcphdr {
 #defineTCP_MAX_SACK3   /* Max # SACKs sent in any segment */
 #defineTCP_SACKHOLE_LIMIT 128  /* Max # SACK holes per connection */
 
-#defineTCP_MAXBURST4   /* Max # packets after leaving Fast 
Rxmit */
-
 /*
  * Default maximum segment size for TCP.
  * With an IP MSS of 576, this is 536,
Index: tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.129
diff -u -p -r1.129 tcp_output.c
--- tcp_output.c25 Jan 2021 03:40:46 -  1.129
+++ tcp_output.c8 Feb 2021 17:53:07 -
@@ -203,7 +203,6 @@ tcp_output(struct tcpcb *tp)
int idle, sendalot = 0;
int i, sack_rxmit = 0;
struct sackhole *p;
-   int maxburst = TCP_MAXBURST;
 #ifdef TCP_SIGNATURE
unsigned int sigoff;
 #endif /* TCP_SIGNATURE */
@@ -1120,7 +1119,7 @@ out:
tp->last_ack_sent = tp->rcv_nxt;
tp->t_flags &= ~TF_ACKNOW;
TCP_TIMER_DISARM(tp, TCPT_DELACK);
-   if (sendalot && --maxburst)
+   if (sendalot)
goto again;
return (0);
 }



Re: diff: tcp ack improvement

2021-02-03 Thread Jan Klemkow
On Tue, Jan 05, 2021 at 10:30:33AM +0100, Claudio Jeker wrote:
> On Tue, Jan 05, 2021 at 10:16:04AM +0100, Jan Klemkow wrote:
> > On Wed, Dec 23, 2020 at 11:59:13AM +, Stuart Henderson wrote:
> > > On 2020/12/17 20:50, Jan Klemkow wrote:
> > > > ping
> > > > 
> > > > On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> > > > > bluhm and I make some network performance measurements and kernel
> > > > > profiling.
> > > 
> > > I've been running this on my workstation since you sent it out - lots
> > > of long-running ssh connections, hourly reposync, daily rsync of base
> > > snapshots.
> > > 
> > > I don't know enough about TCP stack behaviour to really give a meaningful
> > > OK, but certainly not seeing any problems with it.
> > 
> > Thanks, Stuart.  Has someone else tested this diff?  Or, are there some
> > opinions or objections about it?  Even bike-shedding is welcome :-)
> 
> From my memory TCP uses the ACKs on startup to increase the send window
> and so your diff could slow down the initial startup. Not sure if that
> matters actually. It can have some impact if userland reads in big blocks
> at infrequent intervals since then the ACK clock slows down.
> 
> I guess to get converage it would be best to commit this and then monitor
> the lists for possible slowdowns.

It there a way to commit this, or to test the diff in snapshots?

bye,
Jan
 
> > > > > Setup:Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> 
> > > > > Linux (iperf)
> > > > > 
> > > > > We figured out, that the kernel uses a huge amount of processing time
> > > > > for sending ACKs to the sender on the receiving interface.  After
> > > > > receiving a data segment, we send our two ACK.  The first one in
> > > > > tcp_input() direct after receiving.  The second ACK is send out, after
> > > > > the userland or the sosplice task read some data out of the socket
> > > > > buffer.
> > > > > 
> > > > > The fist ACK in tcp_input() is called after receiving every other data
> > > > > segment like it is discribed in RFC1122:
> > > > > 
> > > > >   4.2.3.2  When to Send an ACK Segment
> > > > >   A TCP SHOULD implement a delayed ACK, but an ACK should
> > > > >   not be excessively delayed; in particular, the delay
> > > > >   MUST be less than 0.5 seconds, and in a stream of
> > > > >   full-sized segments there SHOULD be an ACK for at least
> > > > >   every second segment.
> > > > > 
> > > > > This advice is based on the paper "Congestion Avoidance and Control":
> > > > > 
> > > > >   4 THE GATEWAY SIDE OF CONGESTION CONTROL
> > > > >   The 8 KBps senders were talking to 4.3+BSD receivers
> > > > >   which would delay an ack for atmost one packet (because
> > > > >   of an ack’s clock’ role, the authors believe that the
> > > > >   minimum ack frequency should be every other packet).
> > > > > 
> > > > > Sending the first ACK (on every other packet) coasts us too much
> > > > > processing time.  Thus, we run into a full socket buffer earlier.  The
> > > > > first ACK just acknowledges the received data, but does not update the
> > > > > window.  The second ACK, caused by the socket buffer reader, also
> > > > > acknowledges the data and also updates the window.  So, the second 
> > > > > ACK,
> > > > > is much more worth for a fast packet processing than the fist one.
> > > > > 
> > > > > The performance improvement is between 33% with splicing and 20% 
> > > > > without
> > > > > splice:
> > > > > 
> > > > >   splicingrelaying
> > > > > 
> > > > >   current 3.1 GBit/s  2.6 GBit/s
> > > > >   w/o first ack   4.1 GBit/s  3.1 GBit/s
> > > > > 
> > > > > As far as I understand the implementation of other operating systems:
> > > > > Linux has implement a custom TCP_QUICKACK socket option, to turn this
> > > > > kind of feature on and off.  FreeBSD and NetBSD sill depend on it, 
> > > > > when
> > > > > 

Re: diff: tcp ack improvement

2021-01-05 Thread Jan Klemkow
On Wed, Dec 23, 2020 at 11:59:13AM +, Stuart Henderson wrote:
> On 2020/12/17 20:50, Jan Klemkow wrote:
> > ping
> > 
> > On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> > > bluhm and I make some network performance measurements and kernel
> > > profiling.
> 
> I've been running this on my workstation since you sent it out - lots
> of long-running ssh connections, hourly reposync, daily rsync of base
> snapshots.
> 
> I don't know enough about TCP stack behaviour to really give a meaningful
> OK, but certainly not seeing any problems with it.

Thanks, Stuart.  Has someone else tested this diff?  Or, are there some
opinions or objections about it?  Even bike-shedding is welcome :-)

Thanks,
Jan

> > > Setup:Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)
> > > 
> > > We figured out, that the kernel uses a huge amount of processing time
> > > for sending ACKs to the sender on the receiving interface.  After
> > > receiving a data segment, we send our two ACK.  The first one in
> > > tcp_input() direct after receiving.  The second ACK is send out, after
> > > the userland or the sosplice task read some data out of the socket
> > > buffer.
> > > 
> > > The fist ACK in tcp_input() is called after receiving every other data
> > > segment like it is discribed in RFC1122:
> > > 
> > >   4.2.3.2  When to Send an ACK Segment
> > >   A TCP SHOULD implement a delayed ACK, but an ACK should
> > >   not be excessively delayed; in particular, the delay
> > >   MUST be less than 0.5 seconds, and in a stream of
> > >   full-sized segments there SHOULD be an ACK for at least
> > >   every second segment.
> > > 
> > > This advice is based on the paper "Congestion Avoidance and Control":
> > > 
> > >   4 THE GATEWAY SIDE OF CONGESTION CONTROL
> > >   The 8 KBps senders were talking to 4.3+BSD receivers
> > >   which would delay an ack for atmost one packet (because
> > >   of an ack’s clock’ role, the authors believe that the
> > >   minimum ack frequency should be every other packet).
> > > 
> > > Sending the first ACK (on every other packet) coasts us too much
> > > processing time.  Thus, we run into a full socket buffer earlier.  The
> > > first ACK just acknowledges the received data, but does not update the
> > > window.  The second ACK, caused by the socket buffer reader, also
> > > acknowledges the data and also updates the window.  So, the second ACK,
> > > is much more worth for a fast packet processing than the fist one.
> > > 
> > > The performance improvement is between 33% with splicing and 20% without
> > > splice:
> > > 
> > >   splicingrelaying
> > > 
> > >   current 3.1 GBit/s  2.6 GBit/s
> > >   w/o first ack   4.1 GBit/s  3.1 GBit/s
> > > 
> > > As far as I understand the implementation of other operating systems:
> > > Linux has implement a custom TCP_QUICKACK socket option, to turn this
> > > kind of feature on and off.  FreeBSD and NetBSD sill depend on it, when
> > > using the New Reno implementation.
> > > 
> > > The following diff turns off the direct ACK on every other segment.  We
> > > are running this diff in production on our own machines at genua and on
> > > our products for several month, now.  We don't noticed any problems,
> > > even with interactive network sessions (ssh) nor with bulk traffic.
> > > 
> > > Another solution could be a sysctl(3) or an additional socket option,
> > > similar to Linux, to control this behavior per socket or system wide.
> > > Also, a counter to ACK every 3rd, 4th... data segment could beat the
> > > problem.
> > > 
> > > bye,
> > > Jan
> > > 
> > > Index: netinet/tcp_input.c
> > > ===
> > > RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> > > retrieving revision 1.365
> > > diff -u -p -r1.365 tcp_input.c
> > > --- netinet/tcp_input.c   19 Jun 2020 22:47:22 -  1.365
> > > +++ netinet/tcp_input.c   5 Nov 2020 23:00:34 -
> > > @@ -165,8 +165,8 @@ do { \
> > >  #endif
> > >  
> > >  /*
> > > - * Macro to compute ACK transmission behavior.  Delay the ACK unless
> > > - * we have already delayed an ACK (must send a

Re: remove double call of ttyopen()

2020-12-28 Thread Jan Klemkow
On Mon, Dec 28, 2020 at 07:59:23PM +0100, Klemens Nanni wrote:
> On Mon, Dec 28, 2020 at 03:49:35PM +0100, Jan Klemkow wrote:
> > The following diff removes useless double calls of ttyopen.  l_open is
> > a pointer to ttyopen().  All other serial drivers also just use l_open,
> > as it is the general API for this.
> I'm not familiar with the subsystem/API, but one thing looks off to me.
> 
> > Index: dev/pci/cz.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/cz.c,v
> > retrieving revision 1.24
> > diff -u -p -r1.24 cz.c
> > --- dev/pci/cz.c21 May 2020 09:31:59 -  1.24
> > +++ dev/pci/cz.c28 Dec 2020 14:41:30 -
> > @@ -1034,10 +1034,6 @@ czttyopen(dev_t dev, int flags, int mode
> >  
> > splx(s);
> >  
> > -   error = ttyopen(CZTTY_DIALOUT(dev), tp, p);
> > -   if (error)
> > -   goto bad;
> > -
> > error = (*linesw[tp->t_line].l_open)(dev, tp, p);
> 
> Is `CZTTY_DIALOUT(dev)' the same as `dev'?

No, is not the same in all cases.  The macro converts cuaXX to
corresponding ttyXX.  But, it doesn't matter, would be overwritten by
l_open anyway:
...
tp->t_dev = device;
...

> Either way, the `CZTTY_DIALOUT' macro becomes unused with this diff.

The updated diff below also removes the dead CZTTY_DIALOUT macro.

OK?

Thanks,
Jan

Index: arch/luna88k/dev/siotty.c
===
RCS file: /cvs/src/sys/arch/luna88k/dev/siotty.c,v
retrieving revision 1.23
diff -u -p -r1.23 siotty.c
--- arch/luna88k/dev/siotty.c   25 Feb 2019 11:29:30 -  1.23
+++ arch/luna88k/dev/siotty.c   28 Dec 2020 14:40:29 -
@@ -503,9 +503,6 @@ sioopen(dev_t dev, int flag, int mode, s
splx(s);
}
 
-   error = ttyopen(dev, tp, p);
-   if (error > 0)
-   return error;
return (*linesw[tp->t_line].l_open)(dev, tp, p);
 }
  
Index: arch/sh/dev/scif.c
===
RCS file: /cvs/src/sys/arch/sh/dev/scif.c,v
retrieving revision 1.19
diff -u -p -r1.19 scif.c
--- arch/sh/dev/scif.c  19 Feb 2018 08:59:52 -  1.19
+++ arch/sh/dev/scif.c  28 Dec 2020 14:41:05 -
@@ -756,10 +756,6 @@ scifopen(dev_t dev, int flag, int mode, 
 
splx(s);
 
-   error = ttyopen(dev, tp, p);
-   if (error)
-   goto bad;
-
error = (*linesw[tp->t_line].l_open)(dev, tp, p);
if (error)
goto bad;
Index: dev/pci/cz.c
===
RCS file: /cvs/src/sys/dev/pci/cz.c,v
retrieving revision 1.24
diff -u -p -r1.24 cz.c
--- dev/pci/cz.c21 May 2020 09:31:59 -  1.24
+++ dev/pci/cz.c29 Dec 2020 00:48:52 -
@@ -835,7 +835,6 @@ cz_wait_pci_doorbell(struct cz_softc *cz
 
 #define CZTTYDIALOUT_MASK  0x80
 
-#defineCZTTY_DIALOUT(dev)  (minor((dev)) & CZTTYDIALOUT_MASK)
 #defineCZTTY_CZ(sc)((sc)->sc_parent)
 
 #defineCZTTY_SOFTC(dev)cztty_getttysoftc(dev)
@@ -1033,10 +1032,6 @@ czttyopen(dev_t dev, int flags, int mode
}
 
splx(s);
-
-   error = ttyopen(CZTTY_DIALOUT(dev), tp, p);
-   if (error)
-   goto bad;
 
error = (*linesw[tp->t_line].l_open)(dev, tp, p);
if (error)



remove double call of ttyopen()

2020-12-28 Thread Jan Klemkow
Hi,

The following diff removes useless double calls of ttyopen.  l_open is
a pointer to ttyopen().  All other serial drivers also just use l_open,
as it is the general API for this.

OK?

Bye,
Jan

Index: arch/luna88k/dev/siotty.c
===
RCS file: /cvs/src/sys/arch/luna88k/dev/siotty.c,v
retrieving revision 1.23
diff -u -p -r1.23 siotty.c
--- arch/luna88k/dev/siotty.c   25 Feb 2019 11:29:30 -  1.23
+++ arch/luna88k/dev/siotty.c   28 Dec 2020 14:40:29 -
@@ -503,9 +503,6 @@ sioopen(dev_t dev, int flag, int mode, s
splx(s);
}
 
-   error = ttyopen(dev, tp, p);
-   if (error > 0)
-   return error;
return (*linesw[tp->t_line].l_open)(dev, tp, p);
 }
  
Index: arch/sh/dev/scif.c
===
RCS file: /cvs/src/sys/arch/sh/dev/scif.c,v
retrieving revision 1.19
diff -u -p -r1.19 scif.c
--- arch/sh/dev/scif.c  19 Feb 2018 08:59:52 -  1.19
+++ arch/sh/dev/scif.c  28 Dec 2020 14:41:05 -
@@ -756,10 +756,6 @@ scifopen(dev_t dev, int flag, int mode, 
 
splx(s);
 
-   error = ttyopen(dev, tp, p);
-   if (error)
-   goto bad;
-
error = (*linesw[tp->t_line].l_open)(dev, tp, p);
if (error)
goto bad;
Index: dev/pci/cz.c
===
RCS file: /cvs/src/sys/dev/pci/cz.c,v
retrieving revision 1.24
diff -u -p -r1.24 cz.c
--- dev/pci/cz.c21 May 2020 09:31:59 -  1.24
+++ dev/pci/cz.c28 Dec 2020 14:41:30 -
@@ -1034,10 +1034,6 @@ czttyopen(dev_t dev, int flags, int mode
 
splx(s);
 
-   error = ttyopen(CZTTY_DIALOUT(dev), tp, p);
-   if (error)
-   goto bad;
-
error = (*linesw[tp->t_line].l_open)(dev, tp, p);
if (error)
goto bad;



Re: diff: tcp ack improvement

2020-12-17 Thread Jan Klemkow
ping

On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> Hi,
> 
> bluhm and I make some network performance measurements and kernel
> profiling.
> 
> Setup:Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)
> 
> We figured out, that the kernel uses a huge amount of processing time
> for sending ACKs to the sender on the receiving interface.  After
> receiving a data segment, we send our two ACK.  The first one in
> tcp_input() direct after receiving.  The second ACK is send out, after
> the userland or the sosplice task read some data out of the socket
> buffer.
> 
> The fist ACK in tcp_input() is called after receiving every other data
> segment like it is discribed in RFC1122:
> 
>   4.2.3.2  When to Send an ACK Segment
>   A TCP SHOULD implement a delayed ACK, but an ACK should
>   not be excessively delayed; in particular, the delay
>   MUST be less than 0.5 seconds, and in a stream of
>   full-sized segments there SHOULD be an ACK for at least
>   every second segment.
> 
> This advice is based on the paper "Congestion Avoidance and Control":
> 
>   4 THE GATEWAY SIDE OF CONGESTION CONTROL
>   The 8 KBps senders were talking to 4.3+BSD receivers
>   which would delay an ack for atmost one packet (because
>   of an ack’s clock’ role, the authors believe that the
>   minimum ack frequency should be every other packet).
> 
> Sending the first ACK (on every other packet) coasts us too much
> processing time.  Thus, we run into a full socket buffer earlier.  The
> first ACK just acknowledges the received data, but does not update the
> window.  The second ACK, caused by the socket buffer reader, also
> acknowledges the data and also updates the window.  So, the second ACK,
> is much more worth for a fast packet processing than the fist one.
> 
> The performance improvement is between 33% with splicing and 20% without
> splice:
> 
>   splicingrelaying
> 
>   current 3.1 GBit/s  2.6 GBit/s
>   w/o first ack   4.1 GBit/s  3.1 GBit/s
> 
> As far as I understand the implementation of other operating systems:
> Linux has implement a custom TCP_QUICKACK socket option, to turn this
> kind of feature on and off.  FreeBSD and NetBSD sill depend on it, when
> using the New Reno implementation.
> 
> The following diff turns off the direct ACK on every other segment.  We
> are running this diff in production on our own machines at genua and on
> our products for several month, now.  We don't noticed any problems,
> even with interactive network sessions (ssh) nor with bulk traffic.
> 
> Another solution could be a sysctl(3) or an additional socket option,
> similar to Linux, to control this behavior per socket or system wide.
> Also, a counter to ACK every 3rd, 4th... data segment could beat the
> problem.
> 
> bye,
> Jan
> 
> Index: netinet/tcp_input.c
> ===
> RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> retrieving revision 1.365
> diff -u -p -r1.365 tcp_input.c
> --- netinet/tcp_input.c   19 Jun 2020 22:47:22 -  1.365
> +++ netinet/tcp_input.c   5 Nov 2020 23:00:34 -
> @@ -165,8 +165,8 @@ do { \
>  #endif
>  
>  /*
> - * Macro to compute ACK transmission behavior.  Delay the ACK unless
> - * we have already delayed an ACK (must send an ACK every two segments).
> + * Macro to compute ACK transmission behavior.  Delay the ACK until
> + * a read from the socket buffer or the delayed ACK timer causes one.
>   * We also ACK immediately if we received a PUSH and the ACK-on-PUSH
>   * option is enabled or when the packet is coming from a loopback
>   * interface.
> @@ -176,8 +176,7 @@ do { \
>   struct ifnet *ifp = NULL; \
>   if (m && (m->m_flags & M_PKTHDR)) \
>   ifp = if_get(m->m_pkthdr.ph_ifidx); \
> - if (TCP_TIMER_ISARMED(tp, TCPT_DELACK) || \
> - (tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> + if ((tcp_ack_on_push && (tiflags) & TH_PUSH) || \
>   (ifp && (ifp->if_flags & IFF_LOOPBACK))) \
>   tp->t_flags |= TF_ACKNOW; \
>   else \
> 



Re: rc.d(8) for tcpbench

2020-12-15 Thread Jan Klemkow
On Tue, Dec 15, 2020 at 10:59:50PM +, Stuart Henderson wrote:
> On 2020/12/15 23:07, Jan Klemkow wrote:
> > for frequent performance test it would be nice to just start tcpbench
> > as a regular service.  tcpbench gets an extra user and group with this
> > diff and is already pledged to "stdio".  Thus, there should be no
> > security risk to do this even in hostile environments.
> 
> "io" is just for client, for server it's:
> 
> $ ps -O pledge -ax|grep [t]cpb
> 43696 stdio,inet,unix  pf  
> I+p  0:00.00 tcpbench -s

Oh yes, sorry, I missed that by looking over the source too quickly.

> > diff -u -p -r1.104 master.passwd
> > --- etc/master.passwd   24 Apr 2020 14:57:31 -  1.104
> > +++ etc/master.passwd   15 Dec 2020 21:25:17 -
> > @@ -62,4 +62,5 @@ _ftp_proxy:*:109:109::0:0:ftp proxy daem
> >  _sndiop:*:110:110::0:0:sndio privileged user:/var/empty:/sbin/nologin
> >  _syspatch:*:112:112::0:0:syspatch unprivileged 
> > user:/var/empty:/sbin/nologin
> >  _slaacd:*:115:115::0:0:SLAAC Daemon:/var/empty:/sbin/nologin
> > +_tcpbench:*:116:116::0:0:tcpbench unprivileged 
> > user:/var/empty:/sbin/nologin
> >  nobody:*:32767:32767::0:0:Unprivileged user:/nonexistent:/sbin/nologin
> 
> no need to grow the "used system uid" space, 111 is available and was
> taken for less than a day so it's unlikely anyone would even need to
> merge passwd/group files. or maybe a lower one is better, I don't know
> if there's a particular numbering plan for these..

Sure, I will fix that, if this thing has a future.

> > Index: etc/rc.d/tcpbench
> > ===
> > RCS file: etc/rc.d/tcpbench
> > diff -N etc/rc.d/tcpbench
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ etc/rc.d/tcpbench   15 Dec 2020 20:30:18 -
> > @@ -0,0 +1,12 @@
> > +#!/bin/ksh
> > +
> > +daemon="/usr/bin/tcpbench"
> > +daemon_flags="-s"
> > +daemon_user=_tcpbench
> > +
> > +. /etc/rc.d/rc.subr
> > +
> > +rc_reload=NO
> > +rc_bg=YES
> > +
> > +rc_cmd $1
> > 
> 
> I am not a big fan of this to be honest. tcpbench is written more as a
> test tool than a network daemon. For starters, the spew on the console
> when it's active is not very nice.

As I described in answer to Theo, its seems to be easier this way, if
you and to script its. Or, you want to test the quality of link to
different locations frequently.



Re: rc.d(8) for tcpbench

2020-12-15 Thread Jan Klemkow
On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote:
> Jan Klemkow  wrote:
> 
> > for frequent performance test it would be nice to just start tcpbench
> > as a regular service.  tcpbench gets an extra user and group with this
> > diff and is already pledged to "stdio".  Thus, there should be no
> > security risk to do this even in hostile environments.
> 
> You're kidding me.  If someone starts this in a hostile environment, their
> network/host will be flattened.

You are right, someone can use this, to flood a link.  But, you can
flood someones link with traffic anyway, as botnets do it, or?

> I find it difficult to believe there is any environment where someone
> wants tcpbench running *all the time*.

Sure, its not ideal to run this on public interfaces.  I just want to
say, its unlikely that someone will take over you system via bugs in
this daemon, in my opinion.  As it has similar mitigation techniques
as our other daemons.

I run this daemon in permanent tests setups and on links to different
locations.  Its easier to use rcctl enable/start then to deal with
background sessions on remote machines in shell scripts.

Do you think its OK to make a port out of this rc-script for this
purpose?



rc.d(8) for tcpbench

2020-12-15 Thread Jan Klemkow
Hi,

for frequent performance test it would be nice to just start tcpbench
as a regular service.  tcpbench gets an extra user and group with this
diff and is already pledged to "stdio".  Thus, there should be no
security risk to do this even in hostile environments.

OK?

bye,
Jan

Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.480
diff -u -p -r1.480 Makefile
--- etc/Makefile13 Sep 2020 11:29:52 -  1.480
+++ etc/Makefile15 Dec 2020 21:05:07 -
@@ -64,7 +64,7 @@ RCDAEMONS=amd apmd bgpd bootparamd cron 
lpd mopd mountd mrouted nfsd npppd nsd ntpd ospf6d ospfd \
pflogd portmap rad radiusd rarpd rbootd relayd ripd route6d \
sasyncd sensorsd slowcgi slaacd smtpd sndiod snmpd spamd \
-   spamlogd sshd statd switchd syslogd tftpd tftpproxy unbound \
+   spamlogd sshd statd switchd syslogd tcpbench tftpd tftpproxy unbound \
unwind vmd watchdogd wsmoused xenodm ypbind ypldap ypserv
 
 MISETS=base${OSrev}.tgz comp${OSrev}.tgz man${OSrev}.tgz 
game${OSrev}.tgz
Index: etc/group
===
RCS file: /cvs/src/etc/group,v
retrieving revision 1.94
diff -u -p -r1.94 group
--- etc/group   28 Jan 2020 16:51:03 -  1.94
+++ etc/group   15 Dec 2020 20:48:07 -
@@ -79,6 +79,7 @@ _ftp_proxy:*:109:
 _sndiop:*:110:
 _syspatch:*:112:
 _slaacd:*:115:
+_tcpbench:*:116:
 dialer:*:117:
 nogroup:*:32766:
 nobody:*:32767:
Index: etc/master.passwd
===
RCS file: /cvs/src/etc/master.passwd,v
retrieving revision 1.104
diff -u -p -r1.104 master.passwd
--- etc/master.passwd   24 Apr 2020 14:57:31 -  1.104
+++ etc/master.passwd   15 Dec 2020 21:25:17 -
@@ -62,4 +62,5 @@ _ftp_proxy:*:109:109::0:0:ftp proxy daem
 _sndiop:*:110:110::0:0:sndio privileged user:/var/empty:/sbin/nologin
 _syspatch:*:112:112::0:0:syspatch unprivileged user:/var/empty:/sbin/nologin
 _slaacd:*:115:115::0:0:SLAAC Daemon:/var/empty:/sbin/nologin
+_tcpbench:*:116:116::0:0:tcpbench unprivileged user:/var/empty:/sbin/nologin
 nobody:*:32767:32767::0:0:Unprivileged user:/nonexistent:/sbin/nologin
Index: etc/rc.conf
===
RCS file: /cvs/src/etc/rc.conf,v
retrieving revision 1.220
diff -u -p -r1.220 rc.conf
--- etc/rc.conf 24 Jan 2020 06:17:37 -  1.220
+++ etc/rc.conf 15 Dec 2020 20:32:46 -
@@ -65,6 +65,7 @@ spamlogd_flags=   # use eg. "-i interface
 sshd_flags=
 switchd_flags=NO
 syslogd_flags= # add more flags, e.g. "-u -a /chroot/dev/log"
+tcpbench_flags=NO
 tftpd_flags=NO
 tftpproxy_flags=NO
 unbound_flags=NO
Index: etc/mail/aliases
===
RCS file: /cvs/src/etc/mail/aliases,v
retrieving revision 1.68
diff -u -p -r1.68 aliases
--- etc/mail/aliases24 Jan 2020 06:17:37 -  1.68
+++ etc/mail/aliases15 Dec 2020 20:48:31 -
@@ -79,6 +79,7 @@ _ftp_proxy: /dev/null
 _sndiop: /dev/null
 _syspatch: /dev/null
 _slaacd: /dev/null
+_tcpbench: /dev/null
 sshd:   /dev/null
 
 # Well-known aliases -- these should be filled in!
Index: etc/rc.d/tcpbench
===
RCS file: etc/rc.d/tcpbench
diff -N etc/rc.d/tcpbench
--- /dev/null   1 Jan 1970 00:00:00 -
+++ etc/rc.d/tcpbench   15 Dec 2020 20:30:18 -
@@ -0,0 +1,12 @@
+#!/bin/ksh
+
+daemon="/usr/bin/tcpbench"
+daemon_flags="-s"
+daemon_user=_tcpbench
+
+. /etc/rc.d/rc.subr
+
+rc_reload=NO
+rc_bg=YES
+
+rc_cmd $1



diff: mbuf-chains for tcp/ip/ether_ouput

2020-12-15 Thread Jan Klemkow
Hi,

I took on old idea and diff [1] from bluhm and finished it for the IPv4
case.

This change uses mbuf chains in tcp/ip/ether_output instead of single
mbufs.  This approach takes lesser processing power per packets, which
we want to send out.  In several code path it optimises the
processing because we just have to look at the first mbuf of a chain.
In other cases we process several packets in a row for one step, which
saves context switches between functions.

Thus, we gain an performance improvement of around 36% with relayd(8).
The measurements were made with iperf and with 30 streams:

2823.0 MBit/s   current
3844.4 MBit/s   current + mbuf-chaining diff below

ip6_output() is not implemented yet.  I would do that in a followup diff
later, if this one is successful.

I tested the diff on amd64 in several testing environments without any
problem.

Whats your opinion about this change?

bye,
Jan

[1]: https://github.com/bluhm/sys/tree/tcp-outlist

Index: net/fq_codel.c
===
RCS file: /cvs/src/sys/net/fq_codel.c,v
retrieving revision 1.14
diff -u -p -r1.14 fq_codel.c
--- net/fq_codel.c  10 Dec 2020 06:53:38 -  1.14
+++ net/fq_codel.c  15 Dec 2020 09:37:36 -
@@ -138,6 +138,7 @@ void fqcodel_purge(struct fqcodel *, s
 static const struct ifq_ops fqcodel_ops = {
fqcodel_idx,
fqcodel_if_enq,
+   NULL,
fqcodel_if_deq_begin,
fqcodel_if_deq_commit,
fqcodel_if_purge,
Index: net/hfsc.c
===
RCS file: /cvs/src/sys/net/hfsc.c,v
retrieving revision 1.48
diff -u -p -r1.48 hfsc.c
--- net/hfsc.c  22 Oct 2018 23:44:53 -  1.48
+++ net/hfsc.c  15 Dec 2020 09:37:36 -
@@ -270,6 +270,7 @@ void hfsc_free(unsigned int, void *);
 const struct ifq_ops hfsc_ops = {
hfsc_idx,
hfsc_enq,
+   NULL,
hfsc_deq_begin,
hfsc_deq_commit,
hfsc_purge,
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.620
diff -u -p -r1.620 if.c
--- net/if.c3 Oct 2020 00:23:55 -   1.620
+++ net/if.c15 Dec 2020 09:37:36 -
@@ -633,6 +633,8 @@ if_attach_common(struct ifnet *ifp)
ifp->if_rtrequest = if_rtrequest_dummy;
if (ifp->if_enqueue == NULL)
ifp->if_enqueue = if_enqueue_ifq;
+   if (ifp->if_enqueue_ml == NULL)
+   ifp->if_enqueue_ml = if_enqueue_ifq_ml;
ifp->if_llprio = IFQ_DEFPRIO;
 }
 
@@ -682,35 +684,72 @@ if_qstart_compat(struct ifqueue *ifq)
 int
 if_enqueue(struct ifnet *ifp, struct mbuf *m)
 {
+   struct mbuf_list ml = MBUF_LIST_INITIALIZER();
+
+   ml_enqueue(, m);
+   return (if_enqueue_ml(ifp, ));
+}
+
+int
+if_enqueue_ml(struct ifnet *ifp, struct mbuf_list *ml)
+{
+   int error;
+   struct mbuf *m;
+
+   while ((m = ml_dequeue(ml)) != NULL) {
 #if NPF > 0
-   if (m->m_pkthdr.pf.delay > 0)
-   return (pf_delay_pkt(m, ifp->if_index));
+   if (m->m_pkthdr.pf.delay > 0) {
+   error = pf_delay_pkt(m, ifp->if_index);
+   if (error != 0)
+   goto bad;
+   continue;
+   }
 #endif
 
 #if NBRIDGE > 0
-   if (ifp->if_bridgeidx && (m->m_flags & M_PROTO1) == 0) {
-   int error;
-
-   error = bridge_enqueue(ifp, m);
-   return (error);
-   }
+   if (ifp->if_bridgeidx && (m->m_flags & M_PROTO1) == 0) {
+   error = bridge_enqueue(ifp, m);
+   if (error != 0)
+   goto bad;
+   continue;
+   }
 #endif
 
 #if NPF > 0
-   pf_pkt_addr_changed(m);
+   pf_pkt_addr_changed(m);
 #endif /* NPF > 0 */
 
-   return ((*ifp->if_enqueue)(ifp, m));
+   error = (*ifp->if_enqueue)(ifp, m);
+   if (error != 0)
+   goto bad;
+   }
+
+   return 0;
+ bad:
+   ml_purge(ml);
+   return error;
 }
 
 int
 if_enqueue_ifq(struct ifnet *ifp, struct mbuf *m)
 {
+   struct mbuf_list ml = MBUF_LIST_INITIALIZER();
+
+   ml_enqueue(, m);
+   return (if_enqueue_ifq_ml(ifp, ));
+}
+
+int
+if_enqueue_ifq_ml(struct ifnet *ifp, struct mbuf_list *ml)
+{
struct ifqueue *ifq = >if_snd;
int error;
 
if (ifp->if_nifqs > 1) {
unsigned int idx;
+   struct mbuf *m;
+
+   m = MBUF_LIST_FIRST(ml);
 
/*
 * use the operations on the first ifq to pick which of
@@ -721,13 +760,16 @@ if_enqueue_ifq(struct ifnet *ifp, struct
ifq = ifp->if_ifqs[idx];
}
 
-   error = ifq_enqueue(ifq, m);
-   if (error)
-   return (error);
+  

diff: cleanup type handling

2020-12-12 Thread Jan Klemkow
Hi,

The type of the local variable hash in pf_map_addr() has right length
but the wrong type.  This diff uses the correct type and removes the
useless casts.  Both functions uses hash as pf_addr, so no cast is
needed.

OK?

bye,
Jan

Index: net/pf_lb.c
===
RCS file: /cvs/src/sys/net/pf_lb.c,v
retrieving revision 1.67
diff -u -p -r1.67 pf_lb.c
--- net/pf_lb.c 29 Jul 2020 02:32:13 -  1.67
+++ net/pf_lb.c 12 Dec 2020 13:06:49 -
@@ -349,7 +349,7 @@ pf_map_addr(sa_family_t af, struct pf_ru
 struct pf_addr *naddr, struct pf_addr *init_addr, struct pf_src_node **sns,
 struct pf_pool *rpool, enum pf_sn_types type)
 {
-   unsigned charhash[16];
+   struct pf_addr   hash;
struct pf_addr   faddr;
struct pf_addr  *raddr = >addr.v.a.addr;
struct pf_addr  *rmask = >addr.v.a.mask;
@@ -460,8 +460,7 @@ pf_map_addr(sa_family_t af, struct pf_ru
}
break;
case PF_POOL_SRCHASH:
-   hashidx =
-   pf_hash(saddr, (struct pf_addr *), >key, af);
+   hashidx = pf_hash(saddr, , >key, af);
 
if (rpool->addr.type == PF_ADDR_TABLE ||
rpool->addr.type == PF_ADDR_DYNIFTL) {
@@ -483,8 +482,7 @@ pf_map_addr(sa_family_t af, struct pf_ru
return (1);
pf_addrcpy(naddr, >counter, af);
} else {
-   pf_poolmask(naddr, raddr, rmask,
-   (struct pf_addr *), af);
+   pf_poolmask(naddr, raddr, rmask, , af);
}
break;
case PF_POOL_ROUNDROBIN:



diff: replace useless use of MCLGETL with MCLGET

2020-12-12 Thread Jan Klemkow
Hi,

The use of MCLGETL with the default length MCLBYTES is useless.  Thus,
this diff removes '(void)' from the MCLGET macro as it is in the MCLGETL
and replaces all uses of MCLGETL with MCLBYTES by MCLGET.

OK?

bye,
Jan

Index: arch/octeon/dev/if_ogx.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/if_ogx.c,v
retrieving revision 1.3
diff -u -p -r1.3 if_ogx.c
--- arch/octeon/dev/if_ogx.c12 Dec 2020 11:48:52 -  1.3
+++ arch/octeon/dev/if_ogx.c12 Dec 2020 12:58:31 -
@@ -1147,7 +1147,7 @@ ogx_load_mbufs(struct ogx_softc *sc, uns
paddr_t pktbuf;
 
for ( ; n > 0; n--) {
-   m = MCLGETL(NULL, M_NOWAIT, MCLBYTES);
+   m = MCLGET(NULL, M_NOWAIT);
if (m == NULL)
break;
 
Index: dev/fdt/if_dwge.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwge.c,v
retrieving revision 1.7
diff -u -p -r1.7 if_dwge.c
--- dev/fdt/if_dwge.c   12 Dec 2020 11:48:52 -  1.7
+++ dev/fdt/if_dwge.c   12 Dec 2020 12:58:31 -
@@ -1283,7 +1283,7 @@ dwge_alloc_mbuf(struct dwge_softc *sc, b
 {
struct mbuf *m = NULL;
 
-   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+   m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/fdt/if_dwxe.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwxe.c,v
retrieving revision 1.18
diff -u -p -r1.18 if_dwxe.c
--- dev/fdt/if_dwxe.c   12 Dec 2020 11:48:52 -  1.18
+++ dev/fdt/if_dwxe.c   12 Dec 2020 12:58:31 -
@@ -1342,7 +1342,7 @@ dwxe_alloc_mbuf(struct dwxe_softc *sc, b
 {
struct mbuf *m = NULL;
 
-   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+   m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/fdt/if_fec.c
===
RCS file: /cvs/src/sys/dev/fdt/if_fec.c,v
retrieving revision 1.11
diff -u -p -r1.11 if_fec.c
--- dev/fdt/if_fec.c12 Dec 2020 11:48:52 -  1.11
+++ dev/fdt/if_fec.c12 Dec 2020 12:58:31 -
@@ -1298,7 +1298,7 @@ fec_alloc_mbuf(struct fec_softc *sc, bus
 {
struct mbuf *m = NULL;
 
-   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+   m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/fdt/if_mvneta.c
===
RCS file: /cvs/src/sys/dev/fdt/if_mvneta.c,v
retrieving revision 1.16
diff -u -p -r1.16 if_mvneta.c
--- dev/fdt/if_mvneta.c 12 Dec 2020 11:48:52 -  1.16
+++ dev/fdt/if_mvneta.c 12 Dec 2020 12:58:31 -
@@ -1654,7 +1654,7 @@ mvneta_alloc_mbuf(struct mvneta_softc *s
 {
struct mbuf *m = NULL;
 
-   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+   m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/fdt/if_mvpp.c
===
RCS file: /cvs/src/sys/dev/fdt/if_mvpp.c,v
retrieving revision 1.44
diff -u -p -r1.44 if_mvpp.c
--- dev/fdt/if_mvpp.c   12 Dec 2020 11:48:52 -  1.44
+++ dev/fdt/if_mvpp.c   12 Dec 2020 12:58:31 -
@@ -3124,7 +3124,7 @@ mvpp2_alloc_mbuf(struct mvpp2_softc *sc,
 {
struct mbuf *m = NULL;
 
-   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+   m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/ic/bcmgenet.c
===
RCS file: /cvs/src/sys/dev/ic/bcmgenet.c,v
retrieving revision 1.4
diff -u -p -r1.4 bcmgenet.c
--- dev/ic/bcmgenet.c   12 Dec 2020 11:48:52 -  1.4
+++ dev/ic/bcmgenet.c   12 Dec 2020 12:58:31 -
@@ -300,7 +300,7 @@ genet_alloc_mbufcl(struct genet_softc *s
 {
struct mbuf *m;
 
-   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+   m = MCLGET(NULL, M_DONTWAIT);
if (m != NULL)
m->m_pkthdr.len = m->m_len = m->m_ext.ext_size;
 
Index: dev/ic/elink3.c
===
RCS file: /cvs/src/sys/dev/ic/elink3.c,v
retrieving revision 1.98
diff -u -p -r1.98 elink3.c
--- dev/ic/elink3.c 12 Dec 2020 11:48:52 -  1.98
+++ dev/ic/elink3.c 12 Dec 2020 12:58:31 -
@@ -1343,7 +1343,7 @@ epget(struct ep_softc *sc, int totlen)
m = sc->mb[sc->next_mb];
sc->mb[sc->next_mb] = NULL;
if (m == NULL) {
-   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+   m = MCLGET(NULL, M_DONTWAIT);
/* If the queue is no longer full, refill. */
if (!timeout_pending(>sc_epmbuffill_tmo))
   

Re: FT232H variant in uftdi(4)

2020-12-09 Thread Jan Klemkow
On Wed, Dec 09, 2020 at 09:11:35AM +0100, Jan Klemkow wrote:
> On Tue, Dec 08, 2020 at 09:03:53PM -0300, Daniel Bolgheroni wrote:
> > I have a FT232H variant (marked FT232HQ, 0403:6014) which works with 
> > uftdi(4).
> > 
> > Still related to uftdi(4), sys/dev/usb/ftdi.c has a comment saying uftdi(4)
> > does not support multiple serial ports because ucom(4), but I'm able to use
> > both ucom(4) in parallel from the same FT2232H (dual).
> 
> Hi Daniel,
> 
> How does your device attach?

Could you send a dmesg with your device attached?

sorry, for the noise.

> Thanks,
> Jan
> 
> > diff --git a/sys/dev/usb/uftdi.c b/sys/dev/usb/uftdi.c
> > index fb7b8ae8621..80eb3f2c928 100644
> > --- a/sys/dev/usb/uftdi.c
> > +++ b/sys/dev/usb/uftdi.c
> > @@ -34,11 +34,6 @@
> >   * FTDI FT8U100AX serial adapter driver
> >   */
> > 
> > -/*
> > - * XXX This driver will not support multiple serial ports.
> > - * XXX The ucom layer needs to be extended first.
> > - */



Re: FT232H variant in uftdi(4)

2020-12-09 Thread Jan Klemkow
On Tue, Dec 08, 2020 at 09:03:53PM -0300, Daniel Bolgheroni wrote:
> I have a FT232H variant (marked FT232HQ, 0403:6014) which works with uftdi(4).
> 
> Still related to uftdi(4), sys/dev/usb/ftdi.c has a comment saying uftdi(4)
> does not support multiple serial ports because ucom(4), but I'm able to use
> both ucom(4) in parallel from the same FT2232H (dual).

Hi Daniel,

How does your device attach?  Could you send with your device attached?

Thanks,
Jan

> diff --git a/sys/dev/usb/uftdi.c b/sys/dev/usb/uftdi.c
> index fb7b8ae8621..80eb3f2c928 100644
> --- a/sys/dev/usb/uftdi.c
> +++ b/sys/dev/usb/uftdi.c
> @@ -34,11 +34,6 @@
>   * FTDI FT8U100AX serial adapter driver
>   */
> 
> -/*
> - * XXX This driver will not support multiple serial ports.
> - * XXX The ucom layer needs to be extended first.
> - */



Re: diff: tcp ack improvement

2020-11-06 Thread Jan Klemkow
On Fri, Nov 06, 2020 at 08:03:36AM +0100, Otto Moerbeek wrote:
> On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> > bluhm and I make some network performance measurements and kernel
> > profiling.
> > 
> > Setup:  Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)
> > 
> > We figured out, that the kernel uses a huge amount of processing time
> > for sending ACKs to the sender on the receiving interface.  After
> > receiving a data segment, we send our two ACK.  The first one in
> > tcp_input() direct after receiving.  The second ACK is send out, after
> > the userland or the sosplice task read some data out of the socket
> > buffer.
> > 
> > The fist ACK in tcp_input() is called after receiving every other data
> > segment like it is discribed in RFC1122:
> > 
> > 4.2.3.2  When to Send an ACK Segment
> > A TCP SHOULD implement a delayed ACK, but an ACK should
> > not be excessively delayed; in particular, the delay
> > MUST be less than 0.5 seconds, and in a stream of
> > full-sized segments there SHOULD be an ACK for at least
> > every second segment.
> > 
> > This advice is based on the paper "Congestion Avoidance and Control":
> > 
> > 4 THE GATEWAY SIDE OF CONGESTION CONTROL
> > The 8 KBps senders were talking to 4.3+BSD receivers
> > which would delay an ack for atmost one packet (because
> > of an ack’s clock’ role, the authors believe that the
> > minimum ack frequency should be every other packet).
> > 
> > Sending the first ACK (on every other packet) coasts us too much
> > processing time.  Thus, we run into a full socket buffer earlier.  The
> > first ACK just acknowledges the received data, but does not update the
> > window.  The second ACK, caused by the socket buffer reader, also
> > acknowledges the data and also updates the window.  So, the second ACK,
> > is much more worth for a fast packet processing than the fist one.
> > 
> > The performance improvement is between 33% with splicing and 20% without
> > splice:
> > 
> > splicingrelaying
> > 
> > current 3.1 GBit/s  2.6 GBit/s
> > w/o first ack   4.1 GBit/s  3.1 GBit/s
> > 
> > As far as I understand the implementation of other operating systems:
> > Linux has implement a custom TCP_QUICKACK socket option, to turn this
> > kind of feature on and off.  FreeBSD and NetBSD sill depend on it, when
> > using the New Reno implementation.
> > 
> > The following diff turns off the direct ACK on every other segment.  We
> > are running this diff in production on our own machines at genua and on
> > our products for several month, now.  We don't noticed any problems,
> > even with interactive network sessions (ssh) nor with bulk traffic.
> > 
> > Another solution could be a sysctl(3) or an additional socket option,
> > similar to Linux, to control this behavior per socket or system wide.
> > Also, a counter to ACK every 3rd, 4th... data segment could beat the
> > problem.
> 
> I am wondering if you also looked at another scenario: the process
> reading the soecket is sleeping so the receive buffer fills up without
> any acks being sent. Won't that lead to a lot of retransmissions
> containing data?

No, an ACK will always send out after the delayed ACK timer is
triggered.  So, its shouldn't be a problem, when nobody on the system
reads from the socket buffer.

> > Index: netinet/tcp_input.c
> > ===
> > RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> > retrieving revision 1.365
> > diff -u -p -r1.365 tcp_input.c
> > --- netinet/tcp_input.c 19 Jun 2020 22:47:22 -  1.365
> > +++ netinet/tcp_input.c 5 Nov 2020 23:00:34 -
> > @@ -165,8 +165,8 @@ do { \
> >  #endif
> >  
> >  /*
> > - * Macro to compute ACK transmission behavior.  Delay the ACK unless
> > - * we have already delayed an ACK (must send an ACK every two segments).
> > + * Macro to compute ACK transmission behavior.  Delay the ACK until
> > + * a read from the socket buffer or the delayed ACK timer causes one.
> >   * We also ACK immediately if we received a PUSH and the ACK-on-PUSH
> >   * option is enabled or when the packet is coming from a loopback
> >   * interface.
> > @@ -176,8 +176,7 @@ do { \
> > struct ifnet *ifp = NULL; \
> > if (m && (m->m_flags & M_PKTHDR)) \
> > ifp = if_get(m->m_pkthdr.ph_ifidx); \
> > -   if (TCP_TIMER_ISARMED(tp, TCPT_DELACK) || \
> > -   (tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> > +   if ((tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> > (ifp && (ifp->if_flags & IFF_LOOPBACK))) \
> > tp->t_flags |= TF_ACKNOW; \
> > else \
> > 
> 



diff: tcp ack improvement

2020-11-05 Thread Jan Klemkow
Hi,

bluhm and I make some network performance measurements and kernel
profiling.

Setup:  Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)

We figured out, that the kernel uses a huge amount of processing time
for sending ACKs to the sender on the receiving interface.  After
receiving a data segment, we send our two ACK.  The first one in
tcp_input() direct after receiving.  The second ACK is send out, after
the userland or the sosplice task read some data out of the socket
buffer.

The fist ACK in tcp_input() is called after receiving every other data
segment like it is discribed in RFC1122:

4.2.3.2  When to Send an ACK Segment
A TCP SHOULD implement a delayed ACK, but an ACK should
not be excessively delayed; in particular, the delay
MUST be less than 0.5 seconds, and in a stream of
full-sized segments there SHOULD be an ACK for at least
every second segment.

This advice is based on the paper "Congestion Avoidance and Control":

4 THE GATEWAY SIDE OF CONGESTION CONTROL
The 8 KBps senders were talking to 4.3+BSD receivers
which would delay an ack for atmost one packet (because
of an ack’s clock’ role, the authors believe that the
minimum ack frequency should be every other packet).

Sending the first ACK (on every other packet) coasts us too much
processing time.  Thus, we run into a full socket buffer earlier.  The
first ACK just acknowledges the received data, but does not update the
window.  The second ACK, caused by the socket buffer reader, also
acknowledges the data and also updates the window.  So, the second ACK,
is much more worth for a fast packet processing than the fist one.

The performance improvement is between 33% with splicing and 20% without
splice:

splicingrelaying

current 3.1 GBit/s  2.6 GBit/s
w/o first ack   4.1 GBit/s  3.1 GBit/s

As far as I understand the implementation of other operating systems:
Linux has implement a custom TCP_QUICKACK socket option, to turn this
kind of feature on and off.  FreeBSD and NetBSD sill depend on it, when
using the New Reno implementation.

The following diff turns off the direct ACK on every other segment.  We
are running this diff in production on our own machines at genua and on
our products for several month, now.  We don't noticed any problems,
even with interactive network sessions (ssh) nor with bulk traffic.

Another solution could be a sysctl(3) or an additional socket option,
similar to Linux, to control this behavior per socket or system wide.
Also, a counter to ACK every 3rd, 4th... data segment could beat the
problem.

bye,
Jan

Index: netinet/tcp_input.c
===
RCS file: /cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.365
diff -u -p -r1.365 tcp_input.c
--- netinet/tcp_input.c 19 Jun 2020 22:47:22 -  1.365
+++ netinet/tcp_input.c 5 Nov 2020 23:00:34 -
@@ -165,8 +165,8 @@ do { \
 #endif
 
 /*
- * Macro to compute ACK transmission behavior.  Delay the ACK unless
- * we have already delayed an ACK (must send an ACK every two segments).
+ * Macro to compute ACK transmission behavior.  Delay the ACK until
+ * a read from the socket buffer or the delayed ACK timer causes one.
  * We also ACK immediately if we received a PUSH and the ACK-on-PUSH
  * option is enabled or when the packet is coming from a loopback
  * interface.
@@ -176,8 +176,7 @@ do { \
struct ifnet *ifp = NULL; \
if (m && (m->m_flags & M_PKTHDR)) \
ifp = if_get(m->m_pkthdr.ph_ifidx); \
-   if (TCP_TIMER_ISARMED(tp, TCPT_DELACK) || \
-   (tcp_ack_on_push && (tiflags) & TH_PUSH) || \
+   if ((tcp_ack_on_push && (tiflags) & TH_PUSH) || \
(ifp && (ifp->if_flags & IFF_LOOPBACK))) \
tp->t_flags |= TF_ACKNOW; \
else \



diff: refactor MCLGETI() macro

2020-10-07 Thread Jan Klemkow
Hi,

The name of the macro MCLGETI obsolete.  It was made to use a network
interface pointer inside.  But, now it is just used to define a special
length and the interface pointer is discarded.

Thus, the following diff renames the macro to MCLGETL and removes the
dead parameter ifp.

OK?

Bye,
Jan

Index: share/man/man9/mbuf.9
===
RCS file: /cvs/src/share/man/man9/mbuf.9,v
retrieving revision 1.119
diff -u -p -r1.119 mbuf.9
--- share/man/man9/mbuf.9   8 Aug 2020 07:42:31 -   1.119
+++ share/man/man9/mbuf.9   7 Oct 2020 19:24:48 -
@@ -58,7 +58,7 @@
 .Nm m_devget ,
 .Nm m_apply ,
 .Nm MCLGET ,
-.Nm MCLGETI ,
+.Nm MCLGETL ,
 .Nm MEXTADD ,
 .Nm m_align ,
 .Nm M_READONLY ,
@@ -126,7 +126,7 @@
 "int (*func)(caddr_t, caddr_t, unsigned int)" "caddr_t fstate"
 .Fn MCLGET "struct mbuf *m" "int how"
 .Ft struct mbuf *
-.Fn MCLGETI "struct mbuf *m" "int how" "struct ifnet *ifp" "int len"
+.Fn MCLGETL "struct mbuf *m" "int how" "int len"
 .Fn MEXTADD "struct mbuf *m" "caddr_t buf" "u_int size" "int flags" \
 "void (*free)(caddr_t, u_int, void *)" "void *arg"
 .Ft void
@@ -721,7 +721,7 @@ See
 .Fn m_get
 for a description of
 .Fa how .
-.It Fn MCLGETI "struct mbuf *m" "int how" "struct ifnet *ifp" "int len"
+.It Fn MCLGETL "struct mbuf *m" "int how" "int len"
 If
 .Fa m
 is NULL, allocate it.
Index: sys/arch/octeon/dev/if_cnmac.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/if_cnmac.c,v
retrieving revision 1.79
diff -u -p -r1.79 if_cnmac.c
--- sys/arch/octeon/dev/if_cnmac.c  4 Sep 2020 15:18:05 -   1.79
+++ sys/arch/octeon/dev/if_cnmac.c  7 Oct 2020 19:27:08 -
@@ -1106,7 +1106,7 @@ cnmac_mbuf_alloc(int n)
paddr_t pktbuf;
 
while (n > 0) {
-   m = MCLGETI(NULL, M_NOWAIT, NULL,
+   m = MCLGETL(NULL, M_NOWAIT,
OCTEON_POOL_SIZE_PKT + CACHELINESIZE);
if (m == NULL || !ISSET(m->m_flags, M_EXT)) {
m_freem(m);
Index: sys/arch/octeon/dev/if_ogx.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/if_ogx.c,v
retrieving revision 1.2
diff -u -p -r1.2 if_ogx.c
--- sys/arch/octeon/dev/if_ogx.c9 Sep 2020 15:53:25 -   1.2
+++ sys/arch/octeon/dev/if_ogx.c7 Oct 2020 19:27:25 -
@@ -1147,7 +1147,7 @@ ogx_load_mbufs(struct ogx_softc *sc, uns
paddr_t pktbuf;
 
for ( ; n > 0; n--) {
-   m = MCLGETI(NULL, M_NOWAIT, NULL, MCLBYTES);
+   m = MCLGETL(NULL, M_NOWAIT, MCLBYTES);
if (m == NULL)
break;
 
Index: sys/arch/sparc64/dev/vnet.c
===
RCS file: /cvs/src/sys/arch/sparc64/dev/vnet.c,v
retrieving revision 1.62
diff -u -p -r1.62 vnet.c
--- sys/arch/sparc64/dev/vnet.c 10 Jul 2020 13:26:36 -  1.62
+++ sys/arch/sparc64/dev/vnet.c 7 Oct 2020 19:27:41 -
@@ -834,7 +834,7 @@ vnet_rx_vio_dring_data(struct vnet_softc
goto skip;
}
 
-   m = MCLGETI(NULL, M_DONTWAIT, NULL, desc.nbytes);
+   m = MCLGETL(NULL, M_DONTWAIT, desc.nbytes);
if (!m)
break;
m->m_len = m->m_pkthdr.len = desc.nbytes;
Index: sys/dev/fdt/if_dwge.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwge.c,v
retrieving revision 1.6
diff -u -p -r1.6 if_dwge.c
--- sys/dev/fdt/if_dwge.c   13 Sep 2020 01:54:05 -  1.6
+++ sys/dev/fdt/if_dwge.c   7 Oct 2020 19:28:00 -
@@ -1283,7 +1283,7 @@ dwge_alloc_mbuf(struct dwge_softc *sc, b
 {
struct mbuf *m = NULL;
 
-   m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: sys/dev/fdt/if_dwxe.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwxe.c,v
retrieving revision 1.17
diff -u -p -r1.17 if_dwxe.c
--- sys/dev/fdt/if_dwxe.c   10 Jul 2020 13:26:36 -  1.17
+++ sys/dev/fdt/if_dwxe.c   7 Oct 2020 19:28:28 -
@@ -1342,7 +1342,7 @@ dwxe_alloc_mbuf(struct dwxe_softc *sc, b
 {
struct mbuf *m = NULL;
 
-   m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+   m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: sys/dev/fdt/if_fec.c
===
RCS file: /cvs/src/sys/dev/fdt/if_fec.c,v
retrieving revision 1.10
diff -u -p -r1.10 if_fec.c
--- sys/dev/fdt/if_fec.c10 Jul 2020 13:26:36 -  1.10
+++ sys/dev/fdt/if_fec.c7 

diff: remove dead code in a{rm,md}64/a{rm,md}/conf.c

2020-10-07 Thread Jan Klemkow
Hi,

the cdev_joy_init makro is just used in i386.

OK?

Bye,
Jan

Index: amd64/amd64/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v
retrieving revision 1.71
diff -u -p -r1.71 conf.c
--- amd64/amd64/conf.c  6 Jul 2020 04:32:25 -   1.71
+++ amd64/amd64/conf.c  7 Oct 2020 13:10:57 -
@@ -75,13 +75,6 @@ struct bdevswbdevsw[] =
 };
 intnblkdev = nitems(bdevsw);
 
-/* open, close, read, ioctl */
-#define cdev_joy_init(c,n) { \
-   dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
-   (dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
-   (dev_type_stop((*))) enodev, 0, seltrue, \
-   (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
-
 /* open, close, ioctl */
 #define cdev_ocis_init(c,n) { \
 dev_init(c,n,open), dev_init(c,n,close), (dev_type_read((*))) enodev, \
Index: arm64/arm64/conf.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/conf.c,v
retrieving revision 1.15
diff -u -p -r1.15 conf.c
--- arm64/arm64/conf.c  6 Jul 2020 04:32:25 -   1.15
+++ arm64/arm64/conf.c  7 Oct 2020 13:10:57 -
@@ -72,13 +72,6 @@ struct bdevswbdevsw[] =
 };
 intnblkdev = nitems(bdevsw);
 
-/* open, close, read, ioctl */
-#define cdev_joy_init(c,n) { \
-   dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
-   (dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
-   (dev_type_stop((*))) enodev, 0, seltrue, \
-   (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
-
 /* open, close, ioctl, select -- XXX should be a generic device */
 #define cdev_ocis_init(c,n) { \
 dev_init(c,n,open), dev_init(c,n,close), (dev_type_read((*))) enodev, \



new: rp(4): RocketPort multi serial port pci card driver

2020-10-03 Thread Jan Klemkow
Hi,

The following diff contains a port of the FreeBSD driver for RocketPort PCI
cards.  The tty interface works with getty(8) and the cua part with cu for
outbound connections.  Some issues are still in, which I could not figure out
yet.  I worked on this driver for one and half year now, and think it ready to
get in.

I've done a lot of clean up of the original FreeBSD code.  Because there is no
specification available, I kept most of the comments.  I also switched the
original polling mode, which is used in the FreeBSD and Linux version of the
driver to an interrupt driven mode.

This is my first major work in the driver section.  I'm sure that I may miss
something.  So, even nitpicks are welcome :-)

OK?

Thanks,
Jan

Index: share/man/man4/rp.4
===
RCS file: share/man/man4/rp.4
diff -N share/man/man4/rp.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/rp.4 2 Oct 2020 17:50:01 -
@@ -0,0 +1,54 @@
+.\" $OpenBSD$
+.\"
+.\" Copyright (c) 2020 Jan Klemkow 
+.\"
+.\" 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.
+.\"
+.Dd $Mdocdate: October 3 2020 $
+.Dt RP 4
+.Os
+.Sh NAME
+.Nm rp
+.Nd Comtrol RocketPort Intelligent Serial Port Cards device driver
+.Sh SYNOPSIS
+.Cd "rp* at pci?"
+.Sh DESCRIPTION
+This driver provides an interface to RocketPort multiport serial boards.
+.Pp
+The device minor numbers for this driver are encoded as follows:
+.Bd -literal
+d c c u u u u u- bits in the minor device number
+
+bitsmeaning
+---
+u   physical serial line (i.e., unit) to use
+   0-7 on a 8Y, 0-15 on a 16Y
+
+cc  card number
+
+d   dial-out flag
+.Ed
+.Sh SEE ALSO
+.Xr com 4 ,
+.Xr cy 4 ,
+.Xr intro 4 ,
+.Xr pci 4 ,
+.Xr termios 4 ,
+.Xr tty 4
+.Sh AUTHORS
+This driver was written under contract for Comtrol Corporation by
+.An Theodore Ts'o Aq Mt ty...@mit.edu .
+It was ported to OpenBSD by
+.An Jan Klemkow Aq Mt j.klem...@wemelug.de .
+.Sh BUGS
+Modem control does not work properly.
Index: sys/arch/amd64/amd64/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v
retrieving revision 1.71
diff -u -p -r1.71 conf.c
--- sys/arch/amd64/amd64/conf.c 6 Jul 2020 04:32:25 -   1.71
+++ sys/arch/amd64/amd64/conf.c 2 Oct 2020 17:08:36 -
@@ -75,6 +75,12 @@ struct bdevswbdevsw[] =
 };
 intnblkdev = nitems(bdevsw);
 
+/* open, close, read, write, ioctl, tty, mmap */
+#define cdev_pc_init(c,n) { \
+   dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
+   dev_init(c,n,write), dev_init(c,n,ioctl), dev_init(c,n,stop), \
+   dev_init(c,n,tty), ttselect, dev_init(c,n,mmap), D_TTY }
+
 /* open, close, read, ioctl */
 #define cdev_joy_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
@@ -132,6 +138,8 @@ cdev_decl(lms);
 #include "opms.h"
 cdev_decl(pms);
 #endif
+#include "rp.h"
+cdev_decl(rp);
 #include "cy.h"
 cdev_decl(cy);
 #include "tun.h"
@@ -222,7 +230,7 @@ struct cdevsw   cdevsw[] =
cdev_notdef(),  /* 31 */
cdev_notdef(),  /* 32 */
cdev_notdef(),  /* 33 */
-   cdev_notdef(),  /* 34 */
+   cdev_tty_init(NRP,rp),  /* 34: Comtrol RocketPort serial port */
cdev_notdef(),  /* 35: Microsoft mouse */
cdev_notdef(),  /* 36: Logitech mouse */
cdev_notdef(),  /* 37: Extended PS/2 mouse */
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.493
diff -u -p -r1.493 GENERIC
--- sys/arch/amd64/conf/GENERIC 15 Sep 2020 18:31:14 -  1.493
+++ sys/arch/amd64/conf/GENERIC 2 Oct 2020 17:08:39 -
@@ -399,6 +399,7 @@ com*at puc?
 # options CY_HW_RTS
 #cy*   at pci? # PCI cyclom serial card
 #cz*   at pci? # Cyclades-Z multi-port serial boards
+rp*at pci?   

fix: ospf6d(8): wrong intra area announcement

2020-10-01 Thread Jan Klemkow
Hi,

The new intra area db entry has to be saved into the tree before
orig_intra_area_prefix_lsas() is called.  If not, the ospf6d will not
announce the new intra area db for a newly learned link from another
ospf router of the broadcast domain.

This bug is triggered, if you add new addresses an ospf interface while
the ospf6d is already running as a backup designated router.  The
opposite designated ospf6d will get your new link announcement and
return an old intra area db without the new address.

Beside of the fix, the diff removes redundant code.  I made the same
diff for the ospfd to keep code in sync and remove redundant code there,
too.  ospfd does not have the bug explained above, as far as I know.

Both regression tests passes with this diff.

OK?

Bye,
Jan

Index: ospf6d/rde_lsdb.c
===
RCS file: /cvs//src/usr.sbin/ospf6d/rde_lsdb.c,v
retrieving revision 1.45
diff -u -p -r1.45 rde_lsdb.c
--- ospf6d/rde_lsdb.c   21 Aug 2020 10:17:35 -  1.45
+++ ospf6d/rde_lsdb.c   1 Oct 2020 23:09:38 -
@@ -467,6 +467,7 @@ lsa_add(struct rde_nbr *nbr, struct lsa 
struct lsa_tree *tree;
struct vertex   *new, *old;
struct timeval   tv, now, res;
+   int update = 1;
 
if (LSA_IS_SCOPE_AS(ntohs(lsa->hdr.type)))
tree = _tree;
@@ -495,16 +496,13 @@ lsa_add(struct rde_nbr *nbr, struct lsa 
fatal("lsa_add");
return (1);
}
-   if (!lsa_equal(new->lsa, old->lsa)) {
-   if (ntohs(lsa->hdr.type) == LSA_TYPE_LINK)
-   orig_intra_area_prefix_lsas(nbr->area);
-   if (ntohs(lsa->hdr.type) != LSA_TYPE_EXTERNAL)
-   nbr->area->dirty = 1;
-   start_spf_timer();
-   }
+   if (lsa_equal(new->lsa, old->lsa))
+   update = 0;
vertex_free(old);
RB_INSERT(lsa_tree, tree, new);
-   } else {
+   }
+
+   if (update) {
if (ntohs(lsa->hdr.type) == LSA_TYPE_LINK)
orig_intra_area_prefix_lsas(nbr->area);
if (ntohs(lsa->hdr.type) != LSA_TYPE_EXTERNAL)
Index: ospfd/rde_lsdb.c
===
RCS file: /cvs//src/usr.sbin/ospfd/rde_lsdb.c,v
retrieving revision 1.50
diff -u -p -r1.50 rde_lsdb.c
--- ospfd/rde_lsdb.c22 Nov 2015 13:09:10 -  1.50
+++ ospfd/rde_lsdb.c1 Oct 2020 23:06:57 -
@@ -383,6 +383,7 @@ lsa_add(struct rde_nbr *nbr, struct lsa 
struct lsa_tree *tree;
struct vertex   *new, *old;
struct timeval   tv, now, res;
+   int update = 1;
 
if (lsa->hdr.type == LSA_TYPE_EXTERNAL ||
lsa->hdr.type == LSA_TYPE_AS_OPAQ)
@@ -410,15 +411,13 @@ lsa_add(struct rde_nbr *nbr, struct lsa 
fatal("lsa_add");
return (1);
}
-   if (!lsa_equal(new->lsa, old->lsa)) {
-   if (lsa->hdr.type != LSA_TYPE_EXTERNAL &&
-   lsa->hdr.type != LSA_TYPE_AS_OPAQ)
-   nbr->area->dirty = 1;
-   start_spf_timer();
-   }
+   if (lsa_equal(new->lsa, old->lsa))
+   update = 0;
vertex_free(old);
RB_INSERT(lsa_tree, tree, new);
-   } else {
+   }
+
+   if (update) {
if (lsa->hdr.type != LSA_TYPE_EXTERNAL &&
lsa->hdr.type != LSA_TYPE_AS_OPAQ)
nbr->area->dirty = 1;



Re: snmpd(8) Remove struct listen_sock

2020-08-22 Thread Jan Klemkow
On Sun, Aug 09, 2020 at 04:10:13PM +0200, Martijn van Duren wrote:
> I still want to move udp/tcp handling out of snmpe, so that there's 
> better layering, but my previous diff never got any response and might  
> do with some more polishing.
> 
> For now, lets remove listen_sock from snmpd, since there's a 1:1
> correlation with struct address. This saves a couple of callocs during
> startup and 18 LoC.
> 
> OK?

OK jan@

> martijn@
> 
> Index: parse.y
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
> retrieving revision 1.58
> diff -u -p -r1.58 parse.y
> --- parse.y   30 Jun 2020 17:11:49 -  1.58
> +++ parse.y   9 Aug 2020 14:08:18 -
> @@ -997,7 +997,6 @@ parse_config(const char *filename, u_int
>   conf->sc_flags = flags;
>   conf->sc_confpath = filename;
>   TAILQ_INIT(>sc_addresses);
> - TAILQ_INIT(>sc_sockets);
>   strlcpy(conf->sc_rdcommunity, "public", SNMPD_MAXCOMMUNITYLEN);
>   strlcpy(conf->sc_rwcommunity, "private", SNMPD_MAXCOMMUNITYLEN);
>   strlcpy(conf->sc_trcommunity, "public", SNMPD_MAXCOMMUNITYLEN);
> Index: snmpd.h
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
> retrieving revision 1.88
> diff -u -p -r1.88 snmpd.h
> --- snmpd.h   8 Aug 2020 13:39:57 -   1.88
> +++ snmpd.h   9 Aug 2020 14:08:18 -
> @@ -482,6 +482,9 @@ struct address {
>   struct sockaddr_storage  ss;
>   in_port_tport;
>   int  ipproto;
> + int  fd;
> + struct event ev;
> + struct event evt;
>  
>   TAILQ_ENTRY(address) entry;
>  
> @@ -492,15 +495,6 @@ struct address {
>  };
>  TAILQ_HEAD(addresslist, address);
>  
> -struct listen_sock {
> - int s_fd;
> - int s_ipproto;
> - struct events_ev;
> - struct events_evt;
> - TAILQ_ENTRY(listen_sock)entry;
> -};
> -TAILQ_HEAD(socklist, listen_sock);
> -
>  enum usmauth {
>   AUTH_NONE = 0,
>   AUTH_MD5,   /* HMAC-MD5-96, RFC3414 */
> @@ -545,7 +539,6 @@ struct snmpd {
>  
>   const char  *sc_confpath;
>   struct addresslist   sc_addresses;
> - struct socklist  sc_sockets;
>   struct timeval   sc_starttime;
>   u_int32_tsc_engine_boots;
>  
> Index: snmpe.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 snmpe.c
> --- snmpe.c   8 Aug 2020 13:39:57 -   1.63
> +++ snmpe.c   9 Aug 2020 14:08:18 -
> @@ -68,7 +68,6 @@ snmpe(struct privsep *ps, struct privsep
>  {
>   struct snmpd*env = ps->ps_env;
>   struct address  *h;
> - struct listen_sock  *so;
>  #ifdef DEBUG
>   char buf[BUFSIZ];
>   struct oid  *oid;
> @@ -82,14 +81,9 @@ snmpe(struct privsep *ps, struct privsep
>  #endif
>  
>   /* bind SNMP UDP/TCP sockets */
> - TAILQ_FOREACH(h, >sc_addresses, entry) {
> - if ((so = calloc(1, sizeof(*so))) == NULL)
> - fatal("snmpe: %s", __func__);
> - if ((so->s_fd = snmpe_bind(h)) == -1)
> + TAILQ_FOREACH(h, >sc_addresses, entry)
> + if ((h->fd = snmpe_bind(h)) == -1)
>   fatal("snmpe: failed to bind SNMP socket");
> - so->s_ipproto = h->ipproto;
> - TAILQ_INSERT_TAIL(>sc_sockets, so, entry);
> - }
>  
>   proc_run(ps, p, procs, nitems(procs), snmpe_init, NULL);
>  }
> @@ -99,7 +93,7 @@ void
>  snmpe_init(struct privsep *ps, struct privsep_proc *p, void *arg)
>  {
>   struct snmpd*env = ps->ps_env;
> - struct listen_sock  *so;
> + struct address  *h;
>  
>   kr_init();
>   trap_init();
> @@ -107,17 +101,17 @@ snmpe_init(struct privsep *ps, struct pr
>   usm_generate_keys();
>  
>   /* listen for incoming SNMP UDP/TCP messages */
> - TAILQ_FOREACH(so, >sc_sockets, entry) {
> - if (so->s_ipproto == IPPROTO_TCP) {
> - if (listen(so->s_fd, 5) < 0)
> + TAILQ_FOREACH(h, >sc_addresses, entry) {
> + if (h->ipproto == IPPROTO_TCP) {
> + if (listen(h->fd, 5) < 0)
>   fatalx("snmpe: failed to listen on socket");
> - event_set(>s_ev, so->s_fd, EV_READ, snmpe_acceptcb, 
> so);
> - evtimer_set(>s_evt, snmpe_acceptcb, so);
> + event_set(>ev, h->fd, EV_READ, snmpe_acceptcb, h);
> + evtimer_set(>evt, snmpe_acceptcb, h);
>   } else {
> - event_set(>s_ev, so->s_fd, EV_READ|EV_PERSIST,
> + event_set(>ev, h->fd, 

diff: simplify ospf6d code

2020-08-21 Thread Jan Klemkow
Hi,

The following diff simplifies a switch case statement with no functional
change.

In case of IMSG_CTL_SHOW_DATABASE duplicated code is removed.  This part
of the code is now the same as in ospfd.

In case of IMSG_CTL_SHOW_DB_INTRA the code was also duplicated and due
to a missing continue the v->type variable was double check.

OK?

bye,
Jan

Index: rde_lsdb.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/rde_lsdb.c,v
retrieving revision 1.43
diff -u -p -r1.43 rde_lsdb.c
--- rde_lsdb.c  17 Feb 2020 08:12:22 -  1.43
+++ rde_lsdb.c  21 Aug 2020 07:52:15 -
@@ -763,9 +763,7 @@ lsa_dump(struct lsa_tree *tree, int imsg
lsa_age(v);
switch (imsg_type) {
case IMSG_CTL_SHOW_DATABASE:
-   rde_imsg_compose_ospfe(IMSG_CTL_SHOW_DATABASE, 0, pid,
-   >lsa->hdr, ntohs(v->lsa->hdr.len));
-   continue;
+   break;
case IMSG_CTL_SHOW_DB_SELF:
if (v->lsa->hdr.adv_rtr == rde_router_id())
break;
@@ -787,8 +785,6 @@ lsa_dump(struct lsa_tree *tree, int imsg
break;
continue;
case IMSG_CTL_SHOW_DB_INTRA:
-   if (v->type == LSA_TYPE_INTRA_A_PREFIX)
-   break;
case IMSG_CTL_SHOW_DB_SUM:
if (v->type == LSA_TYPE_INTER_A_PREFIX)
break;



diff: uvm: fix unitialized var and simplify code in km_alloc()

2020-05-20 Thread Jan Klemkow
Hi,

The function km_alloc() returns the uninitialized local variable sva if
pgl is empty.  It seems to be not possible in the current condition of
the code, but I'm not sure if this is guaranteed.  Thus, I would prefer
to initialize sva with zero.

It also seems to be unnecessary to loop over the whole pagelist to find
the first element.  The marco pmap_map_direct() just does some
calculations and the value of va is discarded.

I build and run the code on amd64 without any issue and regress/sys/uvm
also doesn't show any problems with that diff.

OK?

bye,
Jan

Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.136
diff -u -p -r1.136 uvm_km.c
--- uvm/uvm_km.c18 Feb 2020 12:13:40 -  1.136
+++ uvm/uvm_km.c20 May 2020 06:17:41 -
@@ -816,7 +816,7 @@ km_alloc(size_t sz, const struct kmem_va
paddr_t pla_align;
int pla_flags;
int pla_maxseg;
-   vaddr_t va, sva;
+   vaddr_t va, sva = 0;
 
KASSERT(sz == round_page(sz));
 
@@ -851,11 +851,8 @@ km_alloc(size_t sz, const struct kmem_va
 * allocations.
 */
if (kv->kv_singlepage || kp->kp_maxseg == 1) {
-   TAILQ_FOREACH(pg, , pageq) {
-   va = pmap_map_direct(pg);
-   if (pg == TAILQ_FIRST())
-   sva = va;
-   }
+   if ((pg = TAILQ_FIRST()) != NULL)
+   sva = pmap_map_direct(pg);
return ((void *)sva);
}
 #endif



Re: diff: em(4) deadlock fix

2020-05-09 Thread Jan Klemkow
On Fri, May 08, 2020 at 04:36:28PM +0200, Mark Kettenis wrote:
> > Date: Fri, 8 May 2020 15:39:26 +0200
> > From: Jan Klemkow 
> > On Mon, Apr 27, 2020 at 10:42:52AM +0200, Martin Pieuchot wrote:
> > > So the current logic assumes that as long as the ring contains descriptors
> > > em_rxrefill() failures aren't fatal and it is not necessary to schedule a
> > > refill.  Why?
> > 
> > I'm not sure.  I just figured out, what I described below.
> > 
> > > Unless we understand this it is difficult to reason about a fix.  Have
> > > you looked at other drivers, is it a common pattern?
> > 
> > Drivers like iavf(4) and ixl(4) just set the timeout when the alive
> > (if_rxr_inuse returns) counter is 0.  Other drivers like ix(4) and
> > bnx(4) call the timeout, when refill was not possible.
> > 
> > I adjust the patch to the behavior of ix(4).  (see below).
> > 
> > > > In my case, the function em_rxeof is unable to pull the last one or two
> > > > mbufs from the receive ring, because the descriptor status hasn't set
> > > > the "descriptor done" flag (E1000_RXD_STAT_DD).  Thus, the ring has one
> > > > or two remaining mbufs, and the timeout to put new ones in is never set.
> > > > When new mbufs are available later, the em driver stays in that
> > > > situation.
> > > 
> > > Are you saying there's always some descriptor on the ring?  Did you
> > > investigate why?
> > 
> > Yes, with printf-debugging:  I see that we return from em_rxeof()
> > because the status bit E1000_RXD_STAT_DD is not set.  And systat(8)
> > shows one or two remaining mbufs in the ALIVE column.
> > 
> > > > The diff always sets the timeout to put new mbufs in the receive ring,
> > > > when it has lesser mbufs then the "low water mark".
> > > 
> > > This changes the logic explained above.  With it the fatal condition
> > > changes from 0 to `lwm'.  Another possible fix would be to always
> > > schedule a timeout as soon as em_rxrefill() fails.
> > 
> > I adjusted the patch to this behavior, as I mentioned above.
> > 
> > > I'm not advocating for a particular change, I'm suggesting we understand
> > > the current logic and its implications.
> > 
> > The logic looks to me like: The NIC should first fill the last mbuf
> > (descriptor), then we set a timeout to refill new mbufs (descriptors).
> > It seems to me, that one or two mbufs maybe some kind of small to
> > operate correctly?!
> > 
> > But, as far as I understand the documentation of Intel, It should be
> > find to deal with such a low amount of mbufs.  I couldn't find any text
> > that said, the firmware needs a minimum amount of DMA memory.
> 
> Sorry, I was going to reply earlier to this mail thread.
> 
> As far as I know, OpenBSD is the only OS that tries to run with
> partially filled rings.  When we started doing this we quickly found
> out that there was hardware out there that didn't work with only a
> single descriptor on the Rx ring.  This is why we introduced the low
> water mark.

Should I make similar diffs for drivers that check for 0 descriptors as
well?

> I'm not certain if we ever found this documented unambiguously the the
> hardware documentation available to us.  But there certainly are hints
> that indicate that descriptors are read a full cache-line at a time.
> And if the descrioptor size is 16 bytes, you need 4 descriptors to
> fill a 64-byte cache line.

Good to know.

> So what you were proposing in your first diff makes sense.  It maight
> make sense to introduce a function to check the limit though, perhaps
> something like if_rxr_needfill() that returns true if the number of
> descriptors on the ring is below the low water mark.

What do you think of this diff, OK?

Thanks,
Jan

Index: share/man/man9/if_rxr_init.9
===
RCS file: /cvs/src/share/man/man9/if_rxr_init.9,v
retrieving revision 1.7
diff -u -p -r1.7 if_rxr_init.9
--- share/man/man9/if_rxr_init.917 Nov 2017 03:51:32 -  1.7
+++ share/man/man9/if_rxr_init.99 May 2020 06:40:46 -
@@ -35,6 +35,8 @@
 .Fn if_rxr_put "struct if_rxring *rxr" "unsigned int n"
 .Ft void
 .Fn if_rxr_livelocked "struct if_rxring *rxr"
+.Ft int
+.Fn if_rxr_needrefill "struct if_rxring *rxr"
 .Ft unsigned int
 .Fn if_rxr_inuse "struct if_rxring *rxr"
 .Ft unsigned int
@@ -88,6 +90,10 @@ receive descriptor slots to the ring.
 .Fn if_rxr_livelocked
 can signal that that receive ring is generating too much load.
 .Pp
+.Fn if

Re: diff: em(4) deadlock fix

2020-05-08 Thread Jan Klemkow
On Mon, Apr 27, 2020 at 10:42:52AM +0200, Martin Pieuchot wrote:
> On 21/04/20(Tue) 15:54, Jan Klemkow wrote:
> > The following diff fixes a deadlock in em(4) when system runs out of
> > mbuf(9)s.
> > 
> > Tested with current on amd64 with:
> > em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x05: msi, mac 0x1e phy 
> > 0xb, address d0:50:99:c1:67:94
> > 
> > When the system runs out of mbufs, the receive ring of the em-NIC also
> > run out of mbufs.  If the driver puts an mbuf from the NICs receive ring
> > with em_rxeof, it calls em_rxrefill to refill the ring.  If its not
> > possible to refill the ring and the receive ring is empty, it sets a
> > timer to retry refilling later till new mbufs are available.
> 
> So the current logic assumes that as long as the ring contains descriptors
> em_rxrefill() failures aren't fatal and it is not necessary to schedule a
> refill.  Why?

I'm not sure.  I just figured out, what I described below.

> Unless we understand this it is difficult to reason about a fix.  Have
> you looked at other drivers, is it a common pattern?

Drivers like iavf(4) and ixl(4) just set the timeout when the alive
(if_rxr_inuse returns) counter is 0.  Other drivers like ix(4) and
bnx(4) call the timeout, when refill was not possible.

I adjust the patch to the behavior of ix(4).  (see below).

> > In my case, the function em_rxeof is unable to pull the last one or two
> > mbufs from the receive ring, because the descriptor status hasn't set
> > the "descriptor done" flag (E1000_RXD_STAT_DD).  Thus, the ring has one
> > or two remaining mbufs, and the timeout to put new ones in is never set.
> > When new mbufs are available later, the em driver stays in that
> > situation.
> 
> Are you saying there's always some descriptor on the ring?  Did you
> investigate why?

Yes, with printf-debugging:  I see that we return from em_rxeof()
because the status bit E1000_RXD_STAT_DD is not set.  And systat(8)
shows one or two remaining mbufs in the ALIVE column.

> > The diff always sets the timeout to put new mbufs in the receive ring,
> > when it has lesser mbufs then the "low water mark".
> 
> This changes the logic explained above.  With it the fatal condition
> changes from 0 to `lwm'.  Another possible fix would be to always
> schedule a timeout as soon as em_rxrefill() fails.

I adjusted the patch to this behavior, as I mentioned above.

> I'm not advocating for a particular change, I'm suggesting we understand
> the current logic and its implications.

The logic looks to me like: The NIC should first fill the last mbuf
(descriptor), then we set a timeout to refill new mbufs (descriptors).
It seems to me, that one or two mbufs maybe some kind of small to
operate correctly?!

But, as far as I understand the documentation of Intel, It should be
find to deal with such a low amount of mbufs.  I couldn't find any text
that said, the firmware needs a minimum amount of DMA memory.

> This bugs reminds me of sthen@'s change to be able to stability use NFS
> on a port machine.  I wonder if they have something in common.
> 
> > A side effect is: when the mbufs in use (alive) are below then the "low
> > water mark", the "current water mark" raises up to value of the "high
> > water mark".  When new mbufs are available the number of mbufs in use
> > also raises to that value.  Because, the "current water mark" just sinks
> > during net livelocks.

Thanks,
Jan

Index: dev/pci/if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.351
diff -u -p -r1.351 if_em.c
--- dev/pci/if_em.c 26 Apr 2020 20:49:56 -  1.351
+++ dev/pci/if_em.c 8 May 2020 08:49:40 -
@@ -2833,7 +2833,7 @@ em_rxrefill(void *arg)
 
if (em_rxfill(que))
E1000_WRITE_REG(>hw, RDT(que->me), que->rx.sc_rx_desc_head);
-   else if (if_rxr_inuse(>rx.sc_rx_ring) == 0)
+   else
timeout_add(>rx_refill, 1);
 }



Re: patch: Enable dock audio on Thinkpad dock (Thinkpad L460)

2020-04-27 Thread Jan Klemkow
On Thu, Apr 16, 2020 at 05:59:44PM -0500, Abel Abraham Camarillo Ojeda wrote:
> On Tuesday, February 11, 2020, Abel Abraham Camarillo Ojeda 
>  wrote:
> > On Wednesday, January 8, 2020, Abel Abraham Camarillo Ojeda 
> >  wrote:
> >> On Mon, Dec 30, 2019 at 1:24 PM Abel Abraham Camarillo Ojeda 
> >>  wrote:
> >>
> >>> The following enables audio via the dock station port in my
> >>> thinkpad L460.  But, anyone knows if its possible to automatically
> >>> disable the laptop speaker when I plug in the audio port in the
> >>> dock? it doesn't appear to have a *_sense, ideas?
> >>>
> >>> this also enables the annoying beep (echo -e "\a"; in console)
> >>>
> >>> patch inline and attached:
> >> Hi, comments, oks?
> > Anyone?
> Hi, any ok, comments?

Hi Abel,

Thanks for your diff.  Please add an applicable diff inline in your mail
next time and don't attach it.

I can't test the diff with the right hardware.  But, the patch applies,
builds and doesn't break audio on my ThinkPad X1C6.  The diff also looks
fine for me.

bye,
Jan

Index: azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.178
diff -u -p -r1.178 azalia_codec.c
--- azalia_codec.c  14 Oct 2019 02:04:35 -  1.178
+++ azalia_codec.c  27 Apr 2020 07:42:45 -
@@ -159,6 +159,17 @@ azalia_codec_init_vtbl(codec_t *this)
this->subid == 0x503c17aa)
this->qrks |= AZ_QRK_WID_TPDOCK2;
break;
+   case 0x10ec0293:
+   this->name = "Realtek ALC293";
+   this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
+
+   /*
+* Enable dock audio on Thinkpad docks
+* 0x17aa : 0x5051 = Thinkpad L460
+*/
+   if (this->subid == 0x505117aa)
+   this->qrks |= AZ_QRK_WID_TPDOCK2;
+   break;
case 0x10ec0298:
this->name = "Realtek ALC298";
if (this->subid == 0x320019e5 ||



diff: em(4) deadlock fix

2020-04-21 Thread Jan Klemkow
Hi,

The following diff fixes a deadlock in em(4) when system runs out of
mbuf(9)s.

Tested with current on amd64 with:
em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x05: msi, mac 0x1e phy 0xb, 
address d0:50:99:c1:67:94

When the system runs out of mbufs, the receive ring of the em-NIC also
run out of mbufs.  If the driver puts an mbuf from the NICs receive ring
with em_rxeof, it calls em_rxrefill to refill the ring.  If its not
possible to refill the ring and the receive ring is empty, it sets a
timer to retry refilling later till new mbufs are available.

In my case, the function em_rxeof is unable to pull the last one or two
mbufs from the receive ring, because the descriptor status hasn't set
the "descriptor done" flag (E1000_RXD_STAT_DD).  Thus, the ring has one
or two remaining mbufs, and the timeout to put new ones in is never set.
When new mbufs are available later, the em driver stays in that
situation.

The diff always sets the timeout to put new mbufs in the receive ring,
when it has lesser mbufs then the "low water mark".

A side effect is: when the mbufs in use (alive) are below then the "low
water mark", the "current water mark" raises up to value of the "high
water mark".  When new mbufs are available the number of mbufs in use
also raises to that value.  Because, the "current water mark" just sinks
during net livelocks.

I'm sure this path is not the best solution.  Maybe someone else has a
better idea to avoid that situation?!

Bye,
Jan

Index: dev/pci/if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.349
diff -u -p -r1.349 if_em.c
--- dev/pci/if_em.c 24 Mar 2020 09:30:06 -  1.349
+++ dev/pci/if_em.c 21 Apr 2020 12:02:28 -
@@ -2809,7 +2809,8 @@ em_rxrefill(void *arg)
 
if (em_rxfill(que))
E1000_WRITE_REG(>hw, RDT(que->me), que->rx.sc_rx_desc_head);
-   else if (if_rxr_inuse(>rx.sc_rx_ring) == 0)
+   else if (if_rxr_inuse(>rx.sc_rx_ring) <
+   if_rxr_lwm(>rx.sc_rx_ring))
timeout_add(>rx_refill, 1);
 }
 
Index: net/if_var.h
===
RCS file: /cvs/src/sys/net/if_var.h,v
retrieving revision 1.104
diff -u -p -r1.104 if_var.h
--- net/if_var.h12 Apr 2020 07:02:43 -  1.104
+++ net/if_var.h21 Apr 2020 11:58:17 -
@@ -389,6 +389,7 @@ u_int   if_rxr_get(struct if_rxring *, u_i
 #define if_rxr_put(_r, _c) do { (_r)->rxr_alive -= (_c); } while (0)
 #define if_rxr_inuse(_r)   ((_r)->rxr_alive)
 #define if_rxr_cwm(_r) ((_r)->rxr_cwm)
+#define if_rxr_lwm(_r) ((_r)->rxr_lwm)
 
 intif_rxr_info_ioctl(struct if_rxrinfo *, u_int, struct if_rxring_info *);
 intif_rxr_ioctl(struct if_rxrinfo *, const char *, u_int,



Re: snmpd(8): fix use of uninitialized pointer

2020-03-10 Thread Jan Klemkow
On Tue, Mar 10, 2020 at 06:25:10PM +0100, Martijn van Duren wrote:
> So I did some last minute testing of my own and apparently I misread.
> A varbindlist means a new sequence of varbinds, while the code assumes
> a list of varbinds.
> 
> Code below actually works and also gives the additional varbinds to
> the trap handle "command".
> 
> Now actually asking for OKs. :-)

OK jan@

> On 3/10/20 1:43 PM, Jan Klemkow wrote:
> > On Tue, Mar 10, 2020 at 01:13:46PM +0100, Martijn van Duren wrote:
> >> On 3/10/20 10:21 AM, Jan Klemkow wrote:
> >>> On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
> >>>> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
> >>>> varbindlist.
> >>>>
> >>>> Could you test the diff below?
> >>>
> >>> Is also OK for me and the current call path seems to be clean.
> >>> But, shouldn't we set iter to NULL anyway?
> >>
> >> If we state that traphandler_parse must initialize *vbinds, then not
> >> setting it allows us to differentiate between undefined behaviour
> >> (initialized to garbage) and no varbindlist. The first one will only
> >> show its head if someone screws up a refactor.
> >> But if you feel strongly about it we can initialize it.
> > 
> > I don't feel strong about it.  Commit your change and I fine with it.
> > 
> > OK jan@
> > 
> >>>> On 3/9/20 11:38 PM, Jan Klemkow wrote:
> >>>>> Hi,
> >>>>>
> >>>>> The following diff fixes the use of the uninitialized pointer iter
> >>>>> in trapcmd_exec().
> >>>>>
> >>>>> iter is just initialized in traphandler_parse() if vers is SNMP_V2.  In
> >>>>> all other cases iter stays uninitialized and may dereferenced in
> >>>>> trapcmd_exec().
> >>>>>
> >>>>> OK?
> >>>>>
> >>>>> bye,
> >>>>> Jan
> 
> Index: traphandler.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/traphandler.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 traphandler.c
> --- traphandler.c 24 Oct 2019 12:39:27 -  1.15
> +++ traphandler.c 10 Mar 2020 17:23:51 -
> @@ -232,10 +232,13 @@ traphandler_parse(char *buf, size_t n, s
>  
>   switch (vers) {
>   case SNMP_V1:
> - if (ober_scanf_elements(elm, "{oSddd",
> - trapoid, , , uptime) == -1)
> + if (ober_scanf_elements(elm, "{oSddde",
> + trapoid, , , uptime, ) == -1)
>   goto done;
>   traphandler_v1translate(trapoid, gtype, etype);
> + if (elm->be_type != BER_TYPE_SEQUENCE)
> + goto done;
> + *vbinds = elm->be_sub;
>   break;
>  
>   case SNMP_V2:
> 



Re: snmpd(8): fix use of uninitialized pointer

2020-03-10 Thread Jan Klemkow
On Tue, Mar 10, 2020 at 01:13:46PM +0100, Martijn van Duren wrote:
> On 3/10/20 10:21 AM, Jan Klemkow wrote:
> > On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
> >> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
> >> varbindlist.
> >>
> >> Could you test the diff below?
> > 
> > Is also OK for me and the current call path seems to be clean.
> > But, shouldn't we set iter to NULL anyway?
> 
> If we state that traphandler_parse must initialize *vbinds, then not
> setting it allows us to differentiate between undefined behaviour
> (initialized to garbage) and no varbindlist. The first one will only
> show its head if someone screws up a refactor.
> But if you feel strongly about it we can initialize it.

I don't feel strong about it.  Commit your change and I fine with it.

OK jan@

> >> On 3/9/20 11:38 PM, Jan Klemkow wrote:
> >>> Hi,
> >>>
> >>> The following diff fixes the use of the uninitialized pointer iter
> >>> in trapcmd_exec().
> >>>
> >>> iter is just initialized in traphandler_parse() if vers is SNMP_V2.  In
> >>> all other cases iter stays uninitialized and may dereferenced in
> >>> trapcmd_exec().
> >>>
> >>> OK?
> >>>
> >>> bye,
> >>> Jan
> >>>
> >>
> >> Index: traphandler.c
> >> ===
> >> RCS file: /cvs/src/usr.sbin/snmpd/traphandler.c,v
> >> retrieving revision 1.15
> >> diff -u -p -r1.15 traphandler.c
> >> --- traphandler.c  24 Oct 2019 12:39:27 -  1.15
> >> +++ traphandler.c  9 Mar 2020 23:26:56 -
> >> @@ -236,6 +236,8 @@ traphandler_parse(char *buf, size_t n, s
> >>trapoid, , , uptime) == -1)
> >>goto done;
> >>traphandler_v1translate(trapoid, gtype, etype);
> >> +  *vbinds =
> >> +  elm->be_sub->be_next->be_next->be_next->be_next->be_next;
> >>break;
> >>  
> >>case SNMP_V2:
> >>
> 



Re: snmpd(8): fix use of uninitialized pointer

2020-03-10 Thread Jan Klemkow
On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
> varbindlist.
> 
> Could you test the diff below?

Is also OK for me and the current call path seems to be clean.
But, shouldn't we set iter to NULL anyway?

bye,
Jan

> On 3/9/20 11:38 PM, Jan Klemkow wrote:
> > Hi,
> > 
> > The following diff fixes the use of the uninitialized pointer iter
> > in trapcmd_exec().
> > 
> > iter is just initialized in traphandler_parse() if vers is SNMP_V2.  In
> > all other cases iter stays uninitialized and may dereferenced in
> > trapcmd_exec().
> > 
> > OK?
> > 
> > bye,
> > Jan
> > 
> 
> Index: traphandler.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/traphandler.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 traphandler.c
> --- traphandler.c 24 Oct 2019 12:39:27 -  1.15
> +++ traphandler.c 9 Mar 2020 23:26:56 -
> @@ -236,6 +236,8 @@ traphandler_parse(char *buf, size_t n, s
>   trapoid, , , uptime) == -1)
>   goto done;
>   traphandler_v1translate(trapoid, gtype, etype);
> + *vbinds =
> + elm->be_sub->be_next->be_next->be_next->be_next->be_next;
>   break;
>  
>   case SNMP_V2:
> 



snmpd(8): fix use of uninitialized pointer

2020-03-09 Thread Jan Klemkow
Hi,

The following diff fixes the use of the uninitialized pointer iter
in trapcmd_exec().

iter is just initialized in traphandler_parse() if vers is SNMP_V2.  In
all other cases iter stays uninitialized and may dereferenced in
trapcmd_exec().

OK?

bye,
Jan

Index: traphandler.c
===
RCS file: /cvs/src/usr.sbin/snmpd/traphandler.c,v
retrieving revision 1.15
diff -u -p -r1.15 traphandler.c
--- traphandler.c   24 Oct 2019 12:39:27 -  1.15
+++ traphandler.c   9 Mar 2020 21:59:56 -
@@ -305,7 +305,7 @@ traphandler_fork_handler(struct privsep_
struct sockaddr *sa;
char*buf;
ssize_t  n;
-   struct ber_element  *req, *iter;
+   struct ber_element  *req, *iter = NULL;
struct trapcmd  *cmd;
struct ber_oid   trapoid;
u_intuptime;



Re: diff: simplify globbing in ftpd(8)

2020-01-14 Thread Jan Klemkow
On Mon, Jan 13, 2020 at 10:30:11AM -0700, Todd C. Miller wrote:
> On Mon, 13 Jan 2020 13:45:55 +0100, Jan Klemkow wrote:
> 
> > This diff simplifies globbing for the ftpd(8) ls and stat command.  And
> > it avoids to glob for the parameters "-lgA".
> >
> > Due, we just pass a single string to the ftpd_ls() function, we don't
> > need to provide infrastructure for a dynamic list of arguments.
> 
> This conflicts with the diff to support NLIST arguments from SASANO
> Takayoshi.  I think we can support this by adding a flag to ftpd_ls()
> that indicates whether it is a long list or not.

Here is an improved version of the diff, but as I explaind here [1]
without argument injection.  I stopped argument injection by adding
"--" before client paramenters for ls(1).

[1]: https://marc.info/?l=openbsd-tech=157900764005335=2

OK?

Thanks,
Jan

Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.20
diff -u -p -r1.20 extern.h
--- extern.h8 May 2019 23:56:48 -   1.20
+++ extern.h13 Jan 2020 11:03:39 -
@@ -68,7 +68,7 @@ void  delete(char *);
 void   dologout(int);
 void   fatal(char *);
 intftpd_pclose(FILE *, pid_t);
-FILE   *ftpd_ls(char *, char *, pid_t *);
+FILE   *ftpd_ls(const char *, pid_t *);
 int get_line(char *, int, FILE *);
 void   ftpdlogwtmp(char *, char *, char *);
 void   lreply(int, const char *, ...);
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.228
diff -u -p -r1.228 ftpd.c
--- ftpd.c  3 Jul 2019 03:24:04 -   1.228
+++ ftpd.c  13 Jan 2020 11:15:31 -
@@ -1124,7 +1124,7 @@ retrieve(enum ret_cmd cmd, char *name)
fin = fopen(name, "r");
st.st_size = 0;
} else {
-   fin = ftpd_ls("-lgA", name, );
+   fin = ftpd_ls(name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
@@ -1730,7 +1730,7 @@ statfilecmd(char *filename)
int c;
int atstart;
pid_t pid;
-   fin = ftpd_ls("-lgA", filename, );
+   fin = ftpd_ls(filename, );
if (fin == NULL) {
reply(451, "Local resource failure");
return;
Index: popen.c
===
RCS file: /cvs/src/libexec/ftpd/popen.c,v
retrieving revision 1.28
diff -u -p -r1.28 popen.c
--- popen.c 28 Jun 2019 13:32:53 -  1.28
+++ popen.c 14 Jan 2020 18:54:52 -
@@ -60,51 +60,45 @@
 #define MAX_GARGV  1000
 
 FILE *
-ftpd_ls(char *arg, char *path, pid_t *pidptr)
+ftpd_ls(const char *path, pid_t *pidptr)
 {
char *cp;
FILE *iop;
-   int argc = 0, gargc, pdes[2];
+   int argc = 0, pdes[2];
pid_t pid;
-   char **pop, *argv[MAX_ARGV], *gargv[MAX_GARGV];
+   char **pop, *argv[MAX_ARGV];
 
if (pipe(pdes) == -1)
return (NULL);
 
/* break up string into pieces */
argv[argc++] = "/bin/ls";
-   if (arg != NULL)
-   argv[argc++] = arg;
-   if (path != NULL)
-   argv[argc++] = path;
-   argv[argc] = NULL;
-   argv[MAX_ARGV-1] = NULL;
+   argv[argc++] = "-lgA";
+   argv[argc++] = "--";
 
-   /* glob each piece */
-   gargv[0] = argv[0];
-   for (gargc = argc = 1; argv[argc]; argc++) {
+   /* glob that path */
+   if (path != NULL) {
glob_t gl;
 
memset(, 0, sizeof(gl));
-   if (glob(argv[argc],
+   if (glob(path,
GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE|GLOB_LIMIT,
NULL, )) {
-   if (gargc < MAX_GARGV-1) {
-   gargv[gargc++] = strdup(argv[argc]);
-   if (gargv[gargc -1] == NULL)
-   fatal ("Out of memory.");
-   }
+   argv[argc++] = strdup(path);
+   if (argv[argc -1] == NULL)
+   fatal ("Out of memory.");
 
} else if (gl.gl_pathc > 0) {
-   for (pop = gl.gl_pathv; *pop && gargc < MAX_GARGV-1; 
pop++) {
-   gargv[gargc++] = strdup(*pop);
-   if (gargv[gargc - 1] == NULL)
+   for (pop = gl.gl_pathv; *pop && argc < MAX_GARGV-1; 
pop++) {
+   argv[argc++] = strdup(*pop);
+   if (argv[argc - 1] == NULL)
fatal ("Out of memory.");
}
}
 

Re: [PATCH] src/libexec/ftpd: fix nlist with -option does not work

2020-01-14 Thread Jan Klemkow
On Mon, Nov 18, 2019 at 02:56:46PM +0900, SASANO Takayoshi wrote:
> At least OpenBSD-6.5 and 6.6's ftpd does not work NLIST command with
> any -option like this.
> 
> 
> ftp> nlist
> 150 Opening ASCII mode data connection for 'file list'.
> uaa
> _sysupgrade
> 226 Transfer complete.
> ftp> nlist -LF
> 550 -LF: No such file or directory.
> ftp>
> 
> 
> Here is the remedy, ok?

I don't like the idea to let the client call custom options of ls(1).
It seems to be secure, but no one knows what options will implemented in
ls(1) in the future.  Also the FTP RFC does not mention custom options,
as far as I can see.

It's just possible to do that, because traditional ftp daemons (like
ours) call ls(1).  I'm more interested in avoiding option insertion by
put a "--" before the clients parameters.

bye,
Jan



Re: diff: simplify globbing in ftpd(8)

2020-01-13 Thread Jan Klemkow
On Mon, Jan 13, 2020 at 10:30:11AM -0700, Todd C. Miller wrote:
> On Mon, 13 Jan 2020 13:45:55 +0100, Jan Klemkow wrote:
> > This diff simplifies globbing for the ftpd(8) ls and stat command.  And
> > it avoids to glob for the parameters "-lgA".
> >
> > Due, we just pass a single string to the ftpd_ls() function, we don't
> > need to provide infrastructure for a dynamic list of arguments.
> 
> This conflicts with the diff to support NLIST arguments from SASANO
> Takayoshi.  I think we can support this by adding a flag to ftpd_ls()
> that indicates whether it is a long list or not.

Oh, I missed that.  And will it checkout first.

Thanks.



diff: simplify globbing in ftpd(8)

2020-01-13 Thread Jan Klemkow
Hi,

This diff simplifies globbing for the ftpd(8) ls and stat command.  And
it avoids to glob for the parameters "-lgA".

Due, we just pass a single string to the ftpd_ls() function, we don't
need to provide infrastructure for a dynamic list of arguments.

Tested it manually and by regression test.

OK?

Bye,
Jan

Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.20
diff -u -p -r1.20 extern.h
--- extern.h8 May 2019 23:56:48 -   1.20
+++ extern.h13 Jan 2020 11:03:39 -
@@ -68,7 +68,7 @@ void  delete(char *);
 void   dologout(int);
 void   fatal(char *);
 intftpd_pclose(FILE *, pid_t);
-FILE   *ftpd_ls(char *, char *, pid_t *);
+FILE   *ftpd_ls(const char *, pid_t *);
 int get_line(char *, int, FILE *);
 void   ftpdlogwtmp(char *, char *, char *);
 void   lreply(int, const char *, ...);
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.228
diff -u -p -r1.228 ftpd.c
--- ftpd.c  3 Jul 2019 03:24:04 -   1.228
+++ ftpd.c  13 Jan 2020 11:15:31 -
@@ -1124,7 +1124,7 @@ retrieve(enum ret_cmd cmd, char *name)
fin = fopen(name, "r");
st.st_size = 0;
} else {
-   fin = ftpd_ls("-lgA", name, );
+   fin = ftpd_ls(name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
@@ -1730,7 +1730,7 @@ statfilecmd(char *filename)
int c;
int atstart;
pid_t pid;
-   fin = ftpd_ls("-lgA", filename, );
+   fin = ftpd_ls(filename, );
if (fin == NULL) {
reply(451, "Local resource failure");
return;
Index: popen.c
===
RCS file: /cvs/src/libexec/ftpd/popen.c,v
retrieving revision 1.28
diff -u -p -r1.28 popen.c
--- popen.c 28 Jun 2019 13:32:53 -  1.28
+++ popen.c 13 Jan 2020 12:07:14 -
@@ -60,51 +60,44 @@
 #define MAX_GARGV  1000
 
 FILE *
-ftpd_ls(char *arg, char *path, pid_t *pidptr)
+ftpd_ls(const char *path, pid_t *pidptr)
 {
char *cp;
FILE *iop;
-   int argc = 0, gargc, pdes[2];
+   int argc = 0, pdes[2];
pid_t pid;
-   char **pop, *argv[MAX_ARGV], *gargv[MAX_GARGV];
+   char **pop, *argv[MAX_ARGV];
 
if (pipe(pdes) == -1)
return (NULL);
 
/* break up string into pieces */
argv[argc++] = "/bin/ls";
-   if (arg != NULL)
-   argv[argc++] = arg;
-   if (path != NULL)
-   argv[argc++] = path;
-   argv[argc] = NULL;
-   argv[MAX_ARGV-1] = NULL;
+   argv[argc++] = "-lgA";
 
-   /* glob each piece */
-   gargv[0] = argv[0];
-   for (gargc = argc = 1; argv[argc]; argc++) {
+   /* glob that path */
+   if (path != NULL) {
glob_t gl;
 
memset(, 0, sizeof(gl));
-   if (glob(argv[argc],
+   if (glob(path,
GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE|GLOB_LIMIT,
NULL, )) {
-   if (gargc < MAX_GARGV-1) {
-   gargv[gargc++] = strdup(argv[argc]);
-   if (gargv[gargc -1] == NULL)
-   fatal ("Out of memory.");
-   }
+   argv[argc++] = strdup(path);
+   if (argv[argc -1] == NULL)
+   fatal ("Out of memory.");
 
} else if (gl.gl_pathc > 0) {
-   for (pop = gl.gl_pathv; *pop && gargc < MAX_GARGV-1; 
pop++) {
-   gargv[gargc++] = strdup(*pop);
-   if (gargv[gargc - 1] == NULL)
+   for (pop = gl.gl_pathv; *pop && argc < MAX_GARGV-1; 
pop++) {
+   argv[argc++] = strdup(*pop);
+   if (argv[argc - 1] == NULL)
fatal ("Out of memory.");
}
}
globfree();
}
-   gargv[gargc] = NULL;
+   argv[argc] = NULL;
+   argv[MAX_ARGV-1] = NULL;
 
iop = NULL;
 
@@ -128,15 +121,15 @@ ftpd_ls(char *arg, char *path, pid_t *pi
 
/* reset getopt for ls_main */
optreset = optind = 1;
-   exit(ls_main(gargc, gargv));
+   exit(ls_main(argc, argv));
}
/* parent; assume fdopen can't fail...  */
iop = fdopen(pdes[0], "r");
(void)close(pdes[1]);
*pidptr = pid;
 
-pfree: for (argc = 1; gargv[argc] != NULL; argc++)
-   free(gargv[argc]);
+pfree: for (argc = 2; argv[argc] != NULL; argc++)
+   free(argv[argc]);
 
return (iop);
 }


signature.asc
Description: 

Re: Add sizes for free() in clct(4)

2019-12-20 Thread Jan Klemkow
On Fri, Dec 20, 2019 at 05:26:56PM +0100, Frederic Cambus wrote:
> Here is a diff to add sizes for free() in clct(4).
> 
> Similar diff to the ones previously sent for other audio drivers.
> 
> Comments? OK?

OK jan@
 
> Index: sys/dev/pci/cs4281.c
> ===
> RCS file: /cvs/src/sys/dev/pci/cs4281.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 cs4281.c
> --- sys/dev/pci/cs4281.c  19 Sep 2016 06:46:44 -  1.36
> +++ sys/dev/pci/cs4281.c  20 Dec 2019 15:56:40 -
> @@ -1187,7 +1187,7 @@ cs4281_malloc(void *addr, int direction,
>   error = cs4281_allocmem(sc, size, pool, flags, p);
>  
>   if (error) {
> - free(p, pool, 0);
> + free(p, pool, sizeof(*p));
>   return (0);
>   }
>  
> @@ -1212,7 +1212,7 @@ cs4281_free(void *addr, void *ptr, int p
>   bus_dmamem_unmap(sc->sc_dmatag, p->addr, p->size);
>   bus_dmamem_free(sc->sc_dmatag, p->segs, p->nsegs);
>   *pp = p->next;
> - free(p, pool, 0);
> + free(p, pool, sizeof(*p));
>   return;
>   }
>   }
> 



Re: ublink(4), led(4) and ledctl(1)

2019-12-14 Thread Jan Klemkow
On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote:

Nice project.  If this makes it into the tree then I could rewrite [1].
[1]: https://github.com/younix/g403led

> And I don't often do userland tools, so feel free to
> let me know how to improve it.
> ...
> +int
> +main(int argc, char **argv)
> +{
> ...
> + exit(0);
> +}

I think its better to return 0 in main() instead of calling the libc
function exit(3).

> ... and also there are no manpages yet.

Below is an example for ledctl.8.

Thanks,
Jan

.\" $OpenBSD$
.\"
.\" Copyright (c) 2019 Jan Klemkow 
.\"
.\" 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.
.\"
.Dd $Mdocdate: December 14 2019 $
.Dt LEDCTL 8
.Os
.Sh NAME
.Nm ledctl
.Nd sets the colors of LEDs
.Sh SYNOPSIS
.Nm
.Op Fl f Ar device
.Op Fl n Ar led
.Op Ar on|off|rgb
.Sh DESCRIPTION
The
.Nm
utility turns LEDs
.Ar on ,
.Ar off
or set their color state.
The color value
.Ar rgb
has to be in hex format.
The parameters
.Ar on
and
.Ar off
are shortcuts for the color values 0xff and 0x00.
.Pp
The options are as follows:
.Bl -tag -width Ds
.It Fl f Ar device
.Nm
uses
the device file
.Ar device .
Default is
.Pa /dev/led0 .
.It Fl n Ar led
A
.Xr led 4
device may consists of multiple LEDs.
Sets
.Ar led
to the index of the right LED.
Default is 0.
.El
.Sh FILES
.Pa /dev/led0
.Sh EXIT STATUS
.Ex -std
.Sh EXAMPLES
Sets the first LED of
.Pa /dev/led0
to red:
.Bd -literal -offset indent
$ ledctl 0xff
.Ed
.Pp
Sets the second LED of
.Pa /dev/led0
to green:
.Bd -literal -offset indent
$ ledctl -n 1 0x00ff00
.Ed
.Pp
Sets the first LED of
.Pa /dev/led2
to blue:
.Bd -literal -offset indent
$ ledctl -f /dev/led2 0xff
.Ed
.\".Sh SEE ALSO
.\".Xr led 4
.Sh AUTHORS
The
.Nm
program was written by
.An Patrick Wildt Aq Mt patr...@blueri.se .


signature.asc
Description: PGP signature


Re: diff: simplify MGETHDR error handling in tcp_output

2019-11-06 Thread Jan Klemkow
Hi Lucas,

On Wed, Nov 06, 2019 at 08:28:43PM +, Lucas wrote:
> Jan Klemkow  wrote:
> > the following diff simplifies the error handling of MGETHDR() in
> > tcp_output().  Jumps earlier to out, prevents a double check of NULL and
> > makes the code more readable.
> > 
> > OK?
> > 
> > Bye,
> > Jan
> > 
> > Index: netinet/tcp_output.c
> > ===
> > RCS file: /cvs/src/sys/netinet/tcp_output.c,v
> > retrieving revision 1.128
> > diff -u -p -r1.128 tcp_output.c
> > --- netinet/tcp_output.c10 Nov 2018 18:40:34 -  1.128
> > +++ netinet/tcp_output.c6 Nov 2019 14:34:40 -
> > @@ -652,17 +652,17 @@ send:
> > m->m_data -= hdrlen;
> >  #else
> > MGETHDR(m, M_DONTWAIT, MT_HEADER);
> > -   if (m != NULL && max_linkhdr + hdrlen > MHLEN) {
> > +   if (m == NULL) {
> > +   error = ENOBUFS;
> > +   goto out;
> > +   }
> > +   if (max_linkhdr + hdrlen > MHLEN) {
> > MCLGET(m, M_DONTWAIT);
> > if ((m->m_flags & M_EXT) == 0) {
> > m_freem(m);
> > m = NULL;
> > }
> > }
> > -   if (m == NULL) {
> > -   error = ENOBUFS;
> > -   goto out;
> > -   }
> > m->m_data += max_linkhdr;
> > m->m_len = hdrlen;
> 
> I might be missing something, but m can be NULL here, if (m->m_flags &
> M_EXT) == 0.

Yes, you are right.  I missed that.

Thank,
Jan



Re: [patch] ftp: improve SMALL and NOSSL #ifdefs

2019-11-06 Thread Jan Klemkow
Hi Hiltjo,

On Wed, Nov 06, 2019 at 07:53:02PM +0100, Hiltjo Posthuma wrote:
> The below patch fixes the #ifndef's for usr.bin/ftp so any combination of 
> SMALL
> and NOSSL will compile again.

Diff looks good for me and works in all ifdef combinations without any
warning or error.

OK jan@

Thanks,
Jan

> diff --git usr.bin/ftp/fetch.c usr.bin/ftp/fetch.c
> index 4c7e14b04bd..15927471f1a 100644
> --- usr.bin/ftp/fetch.c
> +++ usr.bin/ftp/fetch.c
> @@ -201,14 +201,14 @@ url_get(const char *origline, const char *proxyenv, 
> const char *outfile, int las
>   char *proxyhost = NULL;
>  #ifndef NOSSL
>   char *sslpath = NULL, *sslhost = NULL;
> - char *full_host = NULL;
> - const char *scheme;
>   int ishttpurl = 0, ishttpsurl = 0;
>  #endif /* !NOSSL */
>  #ifndef SMALL
> + char *full_host = NULL;
> + const char *scheme;
>   char *locbase;
>   struct addrinfo *ares = NULL;
> -#endif
> +#endif /* !SMALL */
>   struct tls *tls = NULL;
>   int status;
>   int save_errno;
> @@ -221,8 +221,10 @@ url_get(const char *origline, const char *proxyenv, 
> const char *outfile, int las
>   errx(1, "Can't allocate memory to parse URL");
>   if (strncasecmp(newline, HTTP_URL, sizeof(HTTP_URL) - 1) == 0) {
>   host = newline + sizeof(HTTP_URL) - 1;
> -#ifndef SMALL
> +#ifndef NOSSL
>   ishttpurl = 1;
> +#endif /* !NOSSL */
> +#ifndef SMALL
>   scheme = HTTP_URL;
>  #endif /* !SMALL */
>   } else if (strncasecmp(newline, FTP_URL, sizeof(FTP_URL) - 1) == 0) {
> @@ -234,13 +236,17 @@ url_get(const char *origline, const char *proxyenv, 
> const char *outfile, int las
>   } else if (strncasecmp(newline, FILE_URL, sizeof(FILE_URL) - 1) == 0) {
>   host = newline + sizeof(FILE_URL) - 1;
>   isfileurl = 1;
> -#ifndef NOSSL
> +#ifndef SMALL
>   scheme = FILE_URL;
> +#endif /* !SMALL */
> +#ifndef NOSSL
>   } else if (strncasecmp(newline, HTTPS_URL, sizeof(HTTPS_URL) - 1) == 0) 
> {
>   host = newline + sizeof(HTTPS_URL) - 1;
>   ishttpsurl = 1;
> - scheme = HTTPS_URL;
>  #endif /* !NOSSL */
> +#ifndef SMALL
> + scheme = HTTPS_URL;
> +#endif /* !SMALL */
>   } else
>   errx(1, "url_get: Invalid URL '%s'", newline);
>  
> @@ -1066,8 +1072,10 @@ improper:
>   warnx("Improper response from %s", host);
>  
>  cleanup_url_get:
> -#ifndef NOSSL
> +#ifndef SMALL
>   free(full_host);
> +#endif /* !SMALL */
> +#ifndef NOSSL
>   free(sslhost);
>  #endif /* !NOSSL */
>   ftp_close(, , );



diff: simplify MGETHDR error handling in tcp_output

2019-11-06 Thread Jan Klemkow
Hi,

the following diff simplifies the error handling of MGETHDR() in
tcp_output().  Jumps earlier to out, prevents a double check of NULL and
makes the code more readable.

OK?

Bye,
Jan

Index: netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.128
diff -u -p -r1.128 tcp_output.c
--- netinet/tcp_output.c10 Nov 2018 18:40:34 -  1.128
+++ netinet/tcp_output.c6 Nov 2019 14:34:40 -
@@ -652,17 +652,17 @@ send:
m->m_data -= hdrlen;
 #else
MGETHDR(m, M_DONTWAIT, MT_HEADER);
-   if (m != NULL && max_linkhdr + hdrlen > MHLEN) {
+   if (m == NULL) {
+   error = ENOBUFS;
+   goto out;
+   }
+   if (max_linkhdr + hdrlen > MHLEN) {
MCLGET(m, M_DONTWAIT);
if ((m->m_flags & M_EXT) == 0) {
m_freem(m);
m = NULL;
}
}
-   if (m == NULL) {
-   error = ENOBUFS;
-   goto out;
-   }
m->m_data += max_linkhdr;
m->m_len = hdrlen;
if (len <= m_trailingspace(m)) {
@@ -701,16 +701,16 @@ send:
tcpstat_inc(tcps_sndwinup);
 
MGETHDR(m, M_DONTWAIT, MT_HEADER);
-   if (m != NULL && max_linkhdr + hdrlen > MHLEN) {
+   if (m == NULL) {
+   error = ENOBUFS;
+   goto out;
+   }
+   if (max_linkhdr + hdrlen > MHLEN) {
MCLGET(m, M_DONTWAIT);
if ((m->m_flags & M_EXT) == 0) {
m_freem(m);
m = NULL;
}
-   }
-   if (m == NULL) {
-   error = ENOBUFS;
-   goto out;
}
m->m_data += max_linkhdr;
m->m_len = hdrlen;



Re: iwm: support dynamic queue allocation (DQA)

2019-10-16 Thread Jan Klemkow
On Mon, Oct 14, 2019 at 01:51:02PM +0200, Stefan Sperling wrote:
> I have successfully tested this diff on 8265 with our current firmware
> image (22.361476.0) as well as a newer -22 firmware image (22.391740.0,
> which is *not* in fw_update yet). I have also tested 7265 successfully.

Also works for me with 8265 and firmware 22.361476.0

bye,
Jan



Re: net80211: increase background scan backoff timer

2019-10-16 Thread Jan Klemkow
On Mon, Oct 14, 2019 at 02:22:24PM +0200, Stefan Sperling wrote:
> Is anyone running this already? OK?

I run the diff without any noticeable problems.
Run this with iwm and wpa-enterprise.

iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi

Seems to work for me.

bye,
Jan

> On Mon, Oct 07, 2019 at 04:41:37PM +0200, Stefan Sperling wrote:
> > Frequent background scans are known to cause packet loss with
> > some types of APs (e.g. old Apple APs and some Android phones).
> > 
> > There is already a heuristic to make bgscans less frequent if we
> > keep choosing the same AP. However, the current backoff interval 
> > keeps increasing in tiny steps of 500ms, so problems caused by
> > background scans remain noticable for some time after association
> > to a problematic AP.
> > 
> > This diff increases the hgscan backoff timer such that the interval
> > keeps doubling each time we choose the same AP again. I hope this will
> > help in situations where a single AP is used and frequent bgscans are
> > causing trouble.
> >  
> > diff e17574f85785da4fa4073c8b9a00d8d738f3298f 
> > c6d97512c3c477464b2407c31d85add72ed1df9f
> > blob - 313d7249f09646a2eeabc21e9e760c9debcdf790
> > blob + dde43eda321beaa949255c143b249339c39f027c
> > --- sys/net80211/ieee80211_node.c
> > +++ sys/net80211/ieee80211_node.c
> > @@ -1421,8 +1421,12 @@ ieee80211_end_scan(struct ifnet *ifp)
> >  * and make background scans less frequent.
> >  */
> > if (selbs == curbs) {
> > -   if (ic->ic_bgscan_fail < IEEE80211_BGSCAN_FAIL_MAX)
> > -   ic->ic_bgscan_fail++;
> > +   if (ic->ic_bgscan_fail < IEEE80211_BGSCAN_FAIL_MAX) {
> > +   if (ic->ic_bgscan_fail <= 0)
> > +   ic->ic_bgscan_fail = 1;
> > +   else
> > +   ic->ic_bgscan_fail *= 2;
> > +   }
> > ic->ic_flags &= ~IEEE80211_F_BGSCAN;
> > return;
> > }
> > blob - 0f2072288232ac276c2979b799b03c37e0ca8032
> > blob + b475001b14ddb11c5c1713d072358ef2b9e2736d
> > --- sys/net80211/ieee80211_var.h
> > +++ sys/net80211/ieee80211_var.h
> > @@ -62,7 +62,7 @@
> >  #define IEEE80211_RSSI_THRES_RATIO_2GHZ60  /* in percent */
> >  #define IEEE80211_RSSI_THRES_RATIO_5GHZ50  /* in percent */
> >  
> > -#define IEEE80211_BGSCAN_FAIL_MAX  360 /* units of 500 msec */
> > +#define IEEE80211_BGSCAN_FAIL_MAX  512 /* units of 500 msec */
> >  
> >  enum ieee80211_phytype {
> > IEEE80211_T_DS, /* direct sequence spread spectrum */
> > 
> 



fix: build of aac(4)

2019-10-05 Thread Jan Klemkow
Hi,

aac(4) doesn't build in the current status.  The following diff fixes
compile errors.  Also, with the AAC_DEBUG option.  I removed the
prototypes of the inline functions in aacvar.h because of a K style
compile error and that the prototypes are directly followed by their
implementation.

ok?

Bye,
Jan

Index: dev/ic/aac.c
===
RCS file: /mount/openbsd/cvs/src/sys/dev/ic/aac.c,v
retrieving revision 1.70
diff -u -p -r1.70 aac.c
--- dev/ic/aac.c11 Apr 2017 14:43:49 -  1.70
+++ dev/ic/aac.c5 Oct 2019 11:06:18 -
@@ -2129,7 +2129,7 @@ aac_internal_cache_cmd(struct scsi_xfer 
struct scsi_read_cap_data rcd;
u_int8_t target = link->target;
 
-   AAC_DPRINTF(AAC_D_CMD, ("aac_internal_cache_cmd: ",
+   AAC_DPRINTF(AAC_D_CMD, ("%s: aac_internal_cache_cmd: ",
sc->aac_dev.dv_xname));
 
switch (xs->cmd->opcode) {
@@ -2277,7 +2277,7 @@ aac_scsi_cmd(struct scsi_xfer *xs)
blockcnt = _2btol(rwb->length);
}
 
-   AAC_DPRINTF(AAC_D_CMD, ("blkno=%d bcount=%d ",
+   AAC_DPRINTF(AAC_D_CMD, ("opcode=%d blkno=%d bcount=%d ",
xs->cmd->opcode, blockno, blockcnt));
 
if (blockno >= sc->aac_hdr[target].hd_size ||
Index: dev/ic/aacvar.h
===
RCS file: /mount/openbsd/cvs/src/sys/dev/ic/aacvar.h,v
retrieving revision 1.13
diff -u -p -r1.13 aacvar.h
--- dev/ic/aacvar.h 1 Apr 2016 04:16:27 -   1.13
+++ dev/ic/aacvar.h 5 Oct 2019 15:01:12 -
@@ -429,11 +429,6 @@ intaac_attach(struct aac_softc *);
 intaac_intr(void *);
 
 /* These all require correctly aligned buffers */
-static __inline__ void aac_enc16(u_int8_t *, u_int16_t);
-static __inline__ void aac_enc32(u_int8_t *, u_int32_t);
-static __inline__ u_int16_t aac_dec16(u_int8_t *);
-static __inline__ u_int32_t aac_dec32(u_int8_t *);
-
 static __inline__ void
 aac_enc16(addr, value)
u_int8_t *addr;



Re: system boot hang due to inteldrm(4)

2019-10-02 Thread Jan Klemkow
On Tue, Oct 01, 2019 at 11:34:09AM +1000, Jonathan Gray wrote:
> On Tue, Oct 01, 2019 at 12:27:48AM +0200, Jan Klemkow wrote:
> > After updating my router to current, the systems hangs during the boot.
> > Maybe its caused by the "invalid EDID"?!  The System boots up normaly
> > and doesn't hang, if I disable inteldrm(4) in UKC.
> > 
> > Is this issue known?  Or, witch additional debug information should I
> > provide to help fixing this bug?

Hi Jonathan,

> Building a kernel with 'option DRMDEBUG' will give more information.

See the log below:

> Is the machine hooked up to a kvm or monitor?

No KVM and no monitor.  Just serial access.

> What Lanner model is this?  "gbXSo" doesn't help.

Lanner LEC-7233

Thanks,
Jan

Kernel boot messages with DRMDEBUG enabled:
The last part seems to repeat endlessly?!

[ using 2760504 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.6-beta (GENERIC.MP) #102: Wed Oct  2 09:10:14 CEST 2019
you...@fabien.klemkow.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2024398848 (1930MB)
avail mem = 1950064640 (1859MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeca50 (49 entries)
bios0: vendor American Megatrends Inc. version "5.6.5" date 01/05/2017
bios0: Lanner Electronics gbXSo
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT LPIT MCFG HPET SSDT SSDT SSDT UEFI
acpi0: wakeup devices EHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) 
BRCM(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.69 MHz, 06-37-08
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
tsc_timecounter_init: TSC skew=0 observed drift=0
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
TSC skew=0
cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
tsc_timecounter_init: TSC skew=0 observed drift=0
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP02)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 4 (RP04)
acpiprt4 at acpi0: bus 1 (RP01)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: PLPE
acpipwrres1 at acpi0: PLPE
acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1
acpipwrres3 at acpi0: CLK0, resource for CAM1
acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 90 degC
"INT3396" at acpi0 not configured
acpicmos0 at acpi0
acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001
"DMA0F28" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
"BCM2E1A" at acpi0 not configured
"BCM4752" at acpi0 not configured
"AUTH2750" at acpi0 not configured
"INTCF0B" at acpi0 not configured
"INTCF1A" at acpi0 not configured
"INTCF1C" at acpi0 not configured
"SMO91D0" at acpi0 not configured
"MSFT0002" at acpi0 not configured
"INT33BD" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: using VERW MDS workaround
cpu0: Enhanced SpeedStep 1583 MHz: speeds: 1577, 1494, 1411, 1328, 1245, 1162, 
1079, 996, 913, 830, 747, 664, 581, 498 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e
inteldrm0 at pci0 dev 2 func

system boot hang due to inteldrm(4)

2019-09-30 Thread Jan Klemkow
Hi,

After updating my router to current, the systems hangs during the boot.
Maybe its caused by the "invalid EDID"?!  The System boots up normaly
and doesn't hang, if I disable inteldrm(4) in UKC.

Is this issue known?  Or, witch additional debug information should I
provide to help fixing this bug?

Thanks,
Jan

[ using 2744944 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.6-beta (GENERIC.MP) #328: Thu Sep 26 21:37:06 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2024398848 (1930MB)
avail mem = 1950400512 (1860MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeca50 (49 entries)
bios0: vendor American Megatrends Inc. version "5.6.5" date 01/05/2017
bios0: Lanner Electronics gbXSo
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT LPIT MCFG HPET SSDT SSDT SSDT UEFI
acpi0: wakeup devices EHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) 
BRCM(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.59 MHz, 06-37-08
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
tsc_timecounter_init: TSC skew=0 observed drift=0
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
TSC skew=0
cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
tsc_timecounter_init: TSC skew=0 observed drift=0
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP02)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 4 (RP04)
acpiprt4 at acpi0: bus 1 (RP01)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: PLPE
acpipwrres1 at acpi0: PLPE
acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1
acpipwrres3 at acpi0: CLK0, resource for CAM1
acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 90 degC
"INT3396" at acpi0 not configured
acpicmos0 at acpi0
acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001
"DMA0F28" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
"BCM2E1A" at acpi0 not configured
"BCM4752" at acpi0 not configured
"AUTH2750" at acpi0 not configured
"INTCF0B" at acpi0 not configured
"INTCF1A" at acpi0 not configured
"INTCF1C" at acpi0 not configured
"SMO91D0" at acpi0 not configured
"MSFT0002" at acpi0 not configured
"INT33BD" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: using VERW MDS workaround
cpu0: Enhanced SpeedStep 1583 MHz: speeds: 1577, 1494, 1411, 1328, 1245, 1162, 
1079, 996, 913, 830, 747, 664, 581, 498 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e
inteldrm0 at pci0 dev 2 function 0 "Intel Bay Trail Video" rev 0x0e
drm0 at inteldrm0
inteldrm0: msi
ahci0 at pci0 dev 19 function 0 "Intel Bay Trail AHCI" rev 0x0e: msi, AHCI 1.3
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  naa.524693f2ca20f959
sd0: 7641MB, 512 bytes/sector, 15649200 sectors, thin
"Intel Bay Trail TXE" rev 0x0e at pci0 dev 26 function 0 not configured
azalia0 at pci0 dev 27 function 0 "Intel Bay Trail HD Audio" rev 0x0e: msi
azalia0: no supported codecs
ppb0 at pci0 dev 28 function 0 "Intel Bay Trail PCIE" rev 0x0e: msi
pci1 at ppb0 bus 1
bwfm0 at pci1 dev 0 function 0 "Broadcom BCM4350" rev 0x08: msi
ppb1 at pci0 dev 28 function 1 "Intel Bay Trail PCIE" rev 0x0e: msi
pci2 

Re: ix(4): enable checksum offload

2019-07-27 Thread Jan Klemkow
On 9.9.2013. 22:07, Mike Belopuhov wrote:
> On 9 September 2013 21:48, Brad Smith  wrote:
> > Here is a diff to enable the checksum offload support for ix(4).
> >
> > Looking for any testing.
> >
> 
> last time i checked this broke ospf traffic.  please make sure at least
> ip/tcp, ip/udp, ip/icmp, ip/ip, ip/gre, ip/esp, ip/ah and ip/ospf work fine
> with this.

With checksum offloading enabled on the ix(4) I got ~20% performance
improvement with relayd(8) using socket splicing.  I think its worth to
enable this feature by default.

I also did my homework and tested all requested protocols:

IPv4IPv64over6  6over4
ip/tcp  check   check
ip/udp  check   check
ip/icmp check   check
ip/ip   check   check   check   check
ip/gre  check   check   check   check
ip/esp  check   check
ip/ospf check   check
nfs v2  check   -
nfs v3  check   -

I used the following card for testing:
ix0 at pci3 dev 0 function 0 "Intel 82599" rev 0x01: msi, address 
xx:xx:xx:xx:xx:xx

Looking for further testing or any OK?

Bye,
Jan

Index: sys/dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.157
diff -u -p -r1.157 if_ix.c
--- sys/dev/pci/if_ix.c 10 Apr 2019 09:55:02 -  1.157
+++ sys/dev/pci/if_ix.c 27 Jul 2019 19:50:04 -
@@ -1678,9 +1678,7 @@ ixgbe_setup_interface(struct ix_softc *s
ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING;
 #endif
 
-#ifdef IX_CSUM_OFFLOAD
ifp->if_capabilities |= IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;
-#endif
 
/*
 * Specify the media types supported by this sc and register



Re: fix: NULL dereference in bios(4)

2019-07-23 Thread Jan Klemkow
On Tue, Jul 23, 2019 at 10:05:58PM +1000, Jonathan Gray wrote:
> On Mon, Jul 22, 2019 at 10:03:38AM +0200, Jan Klemkow wrote:
> > On Sat, Jul 20, 2019 at 07:16:05PM +1000, Jonathan Gray wrote:
> > > On Fri, Jul 19, 2019 at 02:15:03PM +0200, Jan Klemkow wrote:
> > > > On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote:
> > > > > On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote:
> > > > > > fixstring() can return NULL and it does on one of my machines.
> > > > > > Here is s fix that checks for NULL and return an empty string.
> > > > > > 
> > > > > > ok?
> > > > > 
> > > > > If it returns NULL shouldn't the strlcpy and printf both be skipped?
> > > > 
> > > > I was unsure about this.
> > > > 
> > > > > You've also not included the i386 portion of this.
> > > > 
> > > > I missed that.
> > > > 
> > > > The diff below addresses all issues.
> > > > 
> > > > ok?
> > > 
> > > What argument does fixstring have in this case?
> > 
> > Ten spaces (10x 0x20).
> > 
> > > Does you dmesg not include a date in the 'bios0' line?
> > 
> > no.
> > 
> > > I was considering making this a pointer/dynamically allocated so it can
> > > be NULL.  If there is no valid date it should probably be NULL.
 
Ahh, sorry.  I don't get your suggestion on the first read.

> how about this?

Yes, this solution is fine for me and works on my hardware.

Thanks and OK,
Jan
 
> Index: amd64/amd64/bios.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 bios.c
> --- amd64/amd64/bios.c15 Jul 2019 00:35:10 -  1.38
> +++ amd64/amd64/bios.c23 Jul 2019 12:00:27 -
> @@ -92,6 +92,7 @@ bios_attach(struct device *parent, struc
>   u_int8_t *p;
>   int smbiosrev = 0;
>   struct smbhdr *hdr = NULL;
> + char *sminfop;
>  
>   if (bios_efiinfo != NULL && bios_efiinfo->config_smbios != 0)
>   hdr = smbios_find(PMAP_DIRECT_MAP(
> @@ -144,9 +145,13 @@ bios_attach(struct device *parent, struc
>   fixstring(scratch));
>   if ((smbios_get_string(, sb->release,
>   scratch, sizeof(scratch))) != NULL) {
> - strlcpy(smbios_bios_date, fixstring(scratch),
> - sizeof(smbios_bios_date));
> - printf(" date %s", fixstring(scratch));
> + sminfop = fixstring(scratch);
> + if (sminfop != NULL) {
> + strlcpy(smbios_bios_date,
> + sminfop,
> + sizeof(smbios_bios_date));
> + printf(" date %s", sminfop);
> + }
>   }
>   }
>  
> Index: i386/i386/bios.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
> retrieving revision 1.121
> diff -u -p -r1.121 bios.c
> --- i386/i386/bios.c  15 Jul 2019 00:35:10 -  1.121
> +++ i386/i386/bios.c  23 Jul 2019 12:00:51 -
> @@ -245,6 +245,7 @@ biosattach(struct device *parent, struct
>   for (va = ISA_HOLE_VADDR(SMBIOS_START);
>   va < (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END); va+= 16) {
>   struct smbhdr *sh = (struct smbhdr *)va;
> + char *sminfop;
>   u_int8_t chksum;
>   vaddr_t eva;
>   paddr_t pa, end;
> @@ -308,10 +309,13 @@ biosattach(struct device *parent, struct
>   fixstring(scratch));
>   if ((smbios_get_string(, sb->release,
>   scratch, sizeof(scratch))) != NULL) {
> - strlcpy(smbios_bios_date,
> - fixstring(scratch),
> - sizeof(smbios_bios_date));
> - printf(" date %s", fixstring(scratch));
> + sminfop = fixstring(scratch);
> + if (sminfop != NULL) {
> + strlcpy(smbios_bios_date,
> + sminfop,
> + sizeof(smbios_bios_date));
> + printf(" date %s", sminfop);
> + }
>   }
>   }
>   smbios_info(sc->sc_dev.dv_xname);



Re: fix: NULL dereference in bios(4)

2019-07-22 Thread Jan Klemkow
On Sat, Jul 20, 2019 at 07:16:05PM +1000, Jonathan Gray wrote:
> On Fri, Jul 19, 2019 at 02:15:03PM +0200, Jan Klemkow wrote:
> > On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote:
> > > On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote:
> > > > fixstring() can return NULL and it does on one of my machines.
> > > > Here is s fix that checks for NULL and return an empty string.
> > > > 
> > > > ok?
> > > 
> > > If it returns NULL shouldn't the strlcpy and printf both be skipped?
> > 
> > I was unsure about this.
> > 
> > > You've also not included the i386 portion of this.
> > 
> > I missed that.
> > 
> > The diff below addresses all issues.
> > 
> > ok?
> 
> What argument does fixstring have in this case?

Ten spaces (10x 0x20).

> Does you dmesg not include a date in the 'bios0' line?

no.

> I was considering making this a pointer/dynamically allocated so it can
> be NULL.  If there is no valid date it should probably be NULL.
> 
> > 
> > Thanks,
> > Jan
> > 
> > Index: arch/amd64/amd64/bios.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
> > retrieving revision 1.38
> > diff -u -p -r1.38 bios.c
> > --- arch/amd64/amd64/bios.c 15 Jul 2019 00:35:10 -  1.38
> > +++ arch/amd64/amd64/bios.c 19 Jul 2019 11:45:11 -
> > @@ -144,9 +144,11 @@ bios_attach(struct device *parent, struc
> > fixstring(scratch));
> > if ((smbios_get_string(, sb->release,
> > scratch, sizeof(scratch))) != NULL) {
> > -   strlcpy(smbios_bios_date, fixstring(scratch),
> > +   char *s = fixstring(scratch) == NULL ? "" :
> > +   fixstring(scratch);
> > +   strlcpy(smbios_bios_date, s,
> > sizeof(smbios_bios_date));
> > -   printf(" date %s", fixstring(scratch));
> > +   printf(" date %s", s);
> > }
> > }
> >  
> > Index: arch/i386/i386/bios.c
> > ===
> > RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
> > retrieving revision 1.121
> > diff -u -p -r1.121 bios.c
> > --- arch/i386/i386/bios.c   15 Jul 2019 00:35:10 -  1.121
> > +++ arch/i386/i386/bios.c   19 Jul 2019 11:58:57 -
> > @@ -308,10 +308,11 @@ biosattach(struct device *parent, struct
> > fixstring(scratch));
> > if ((smbios_get_string(, sb->release,
> > scratch, sizeof(scratch))) != NULL) {
> > -   strlcpy(smbios_bios_date,
> > -   fixstring(scratch),
> > +   char *s = fixstring(scratch) == NULL ?
> > +   "" : fixstring(scratch);
> > +   strlcpy(smbios_bios_date, s,
> > sizeof(smbios_bios_date));
> > -   printf(" date %s", fixstring(scratch));
> > +   printf(" date %s", s);
> > }
> > }
> > smbios_info(sc->sc_dev.dv_xname);
> > 



Re: fix: NULL dereference in bios(4)

2019-07-19 Thread Jan Klemkow
On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote:
> On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote:
> > Hi,
> > 
> > fixstring() can return NULL and it does on one of my machines.
> > Here is s fix that checks for NULL and return an empty string.
> > 
> > ok?
> 
> If it returns NULL shouldn't the strlcpy and printf both be skipped?

I was unsure about this.

> You've also not included the i386 portion of this.

I missed that.

The diff below addresses all issues.

ok?

Thanks,
Jan

Index: arch/amd64/amd64/bios.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
retrieving revision 1.38
diff -u -p -r1.38 bios.c
--- arch/amd64/amd64/bios.c 15 Jul 2019 00:35:10 -  1.38
+++ arch/amd64/amd64/bios.c 19 Jul 2019 11:45:11 -
@@ -144,9 +144,11 @@ bios_attach(struct device *parent, struc
fixstring(scratch));
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
-   strlcpy(smbios_bios_date, fixstring(scratch),
+   char *s = fixstring(scratch) == NULL ? "" :
+   fixstring(scratch);
+   strlcpy(smbios_bios_date, s,
sizeof(smbios_bios_date));
-   printf(" date %s", fixstring(scratch));
+   printf(" date %s", s);
}
}
 
Index: arch/i386/i386/bios.c
===
RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
retrieving revision 1.121
diff -u -p -r1.121 bios.c
--- arch/i386/i386/bios.c   15 Jul 2019 00:35:10 -  1.121
+++ arch/i386/i386/bios.c   19 Jul 2019 11:58:57 -
@@ -308,10 +308,11 @@ biosattach(struct device *parent, struct
fixstring(scratch));
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
-   strlcpy(smbios_bios_date,
-   fixstring(scratch),
+   char *s = fixstring(scratch) == NULL ?
+   "" : fixstring(scratch);
+   strlcpy(smbios_bios_date, s,
sizeof(smbios_bios_date));
-   printf(" date %s", fixstring(scratch));
+   printf(" date %s", s);
}
}
smbios_info(sc->sc_dev.dv_xname);



fix: NULL dereference in bios(4)

2019-07-19 Thread Jan Klemkow
Hi,

fixstring() can return NULL and it does on one of my machines.
Here is s fix that checks for NULL and return an empty string.

ok?

bye,
Jan

Index: arch/amd64/amd64/bios.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
retrieving revision 1.38
diff -u -p -r1.38 bios.c
--- arch/amd64/amd64/bios.c 15 Jul 2019 00:35:10 -  1.38
+++ arch/amd64/amd64/bios.c 19 Jul 2019 08:56:27 -
@@ -144,7 +144,9 @@ bios_attach(struct device *parent, struc
fixstring(scratch));
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
-   strlcpy(smbios_bios_date, fixstring(scratch),
+   strlcpy(smbios_bios_date,
+   fixstring(scratch) == NULL ? "" :
+   fixstring(scratch),
sizeof(smbios_bios_date));
printf(" date %s", fixstring(scratch));
}



Re: wsfont & free(9) sizes

2019-07-10 Thread Jan Klemkow
On Wed, Jul 10, 2019 at 12:59:41PM -0300, Martin Pieuchot wrote:
> Some free(9) sizes & fix to make wsfont_remove() compile.  This function
> is #ifndef for the moment.  That's mainly for coherency and to reduce
> grep noise.
> 
> ok?

ok jan
 
> Index: dev/wsfont/wsfont.c
> ===
> RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v
> retrieving revision 1.55
> diff -u -p -u -1 -0 -r1.55 wsfont.c
> --- dev/wsfont/wsfont.c   9 Jan 2019 11:23:32 -   1.55
> +++ dev/wsfont/wsfont.c   23 Jun 2019 00:17:43 -
> @@ -346,23 +346,23 @@ wsfont_rotate_ccw(struct wsdisplay_font 
>  }
>  
>  struct wsdisplay_font *
>  wsfont_rotate_internal(struct wsdisplay_font *font, int ccw)
>  {
>   int newstride;
>   struct wsdisplay_font *newfont;
>   char *newbits;
>  
>   /* Duplicate the existing font... */
> - newfont = malloc(sizeof *font, M_DEVBUF, M_WAITOK);
> + newfont = malloc(sizeof(*newfont), M_DEVBUF, M_WAITOK);
>  
> - bcopy(font, newfont, sizeof *font);
> + bcopy(font, newfont, sizeof(*font));
>   newfont->cookie = NULL;
>  
>   /* Allocate a buffer big enough for the rotated font. */
>   newstride = (font->fontheight + 7) / 8;
>   newbits = mallocarray(font->numchars, newstride * font->fontwidth,
>   M_DEVBUF, M_WAITOK | M_ZERO);
>  
>   if (ccw)
>   wsfont_rotate_ccw(font, newbits, newstride);
>   else
> @@ -374,22 +374,22 @@ wsfont_rotate_internal(struct wsdisplay_
>   newfont->stride = newstride;
>   newfont->fontwidth = font->fontheight;
>   newfont->fontheight = font->fontwidth;
>  
>   if (wsfont_add(newfont, 0) != 0) {
>   /*
>* If we seem to have rotated this font already, drop the
>* new one...
>*/
>   free(newbits, M_DEVBUF,
> - font->numchars * newstride * font->fontwidth);
> - free(newfont, M_DEVBUF, sizeof *font);
> + newfont->numchars * newfont->stride * newfont->fontwidth);
> + free(newfont, M_DEVBUF, sizeof(*newfont));
>   newfont = NULL;
>   }
>  
>   return (newfont);
>  }
>  
>  int
>  wsfont_rotate(int cookie, int ccw)
>  {
>   int s, ncookie;
> @@ -499,33 +499,32 @@ wsfont_add(struct wsdisplay_font *font, 
>   }
>  
>   TAILQ_FOREACH(ent, , chain)
>   fontc++;
>  
>   if (fontc >= WSDISPLAY_MAXFONTCOUNT) {
>   splx(s);
>   return (-1);
>   }
>  
> - ent = (struct font *)malloc(sizeof *ent, M_DEVBUF, M_WAITOK);
> + ent = malloc(sizeof(*ent), M_DEVBUF, M_WAITOK);
>  
>   ent->lockcount = 0;
>   ent->flg = 0;
>   ent->cookie = cookiegen++;
>  
>   /*
>* If we are coming from a WSDISPLAYIO_LDFONT ioctl, we need to
>* make a copy of the wsdisplay_font struct, but not of font->bits.
>*/
>   if (copy) {
> - ent->font = (struct wsdisplay_font *)malloc(sizeof *ent->font,
> - M_DEVBUF, M_WAITOK);
> + ent->font = malloc(sizeof(*ent->font), M_DEVBUF, M_WAITOK);
>   memcpy(ent->font, font, sizeof(*ent->font));
>   ent->flg = 0;
>   } else {
>   ent->font = font;
>   ent->flg = WSFONT_STATIC;
>   }
>  
>   /* Now link into the list and return */
>   TAILQ_INSERT_TAIL(, ent, chain);
>   splx(s);
> @@ -549,27 +548,31 @@ wsfont_remove(int cookie)
>   return (-1);
>   }
>  
>   if ((ent->flg & WSFONT_BUILTIN) != 0 || ent->lockcount != 0) {
>   splx(s);
>   return (-1);
>   }
>  
>   /* Don't free statically allocated font data */
>   if ((ent->flg & WSFONT_STATIC) != 0) {
> - free(ent->font->data, M_DEVBUF, 0);
> - free(ent->font, M_DEVBUF, 0);
> + struct wsdisplay_font *font = ent->font;
> +
> + free(font->data, M_DEVBUF,
> + font->numchars * font->stride * font->fontwidth);
> + free(font, M_DEVBUF, sizeof(*font));
> + ent->font = NULL;
>   }
>  
>   /* Remove from list, free entry */
> - TAILQ_REMOVE(, ent, chain);
> - free(ent, M_DEVBUF, 0);
> + TAILQ_REMOVE(, ent, chain);
> + free(ent, M_DEVBUF, sizeof(*ent));
>   splx(s);
>   return (0);
>  }
>  #endif
>  
>  /*
>   * Lock a given font and return new lockcount. This fails if the cookie
>   * is invalid, or if the font is already locked and the bit/byte order
>   * requested by the caller differs.
>   */
> 



Re: uvideo(4): *ALL*

2019-07-08 Thread Jan Klemkow
Hi Patrick,

I tested all you patches with my integrated uvideo(4) device.

...
uvideo0 at uhub0 port 8 configuration 1 interface 0 "SunplusIT Inc Integrated 
Camera" rev 2.01/54.20 addr 9
video0 at uvideo0
...
addr 09: 5986:2115 SunplusIT Inc, Integrated Camera
 high speed, power 500 mA, config 1, rev 54.20
 driver: uvideo0

My device don't need your patches to work, but at least they doesn't
break it :) Your diffs looks ok for me, but I'm not a USB expert.

Just a nitpick:

There is a spacing mistake in the definition of the new macro
UVIDEO_FORMAT_GUID_KSMEDIA_L8_IR and in the two above.  We may fix them
while here?!

Bye,
Jan

Index: uvideo.h
===
RCS file: /cvs/src/sys/dev/usb/uvideo.h,v
retrieving revision 1.57
diff -u -p -r1.57 uvideo.h
--- uvideo.h9 Jul 2015 14:58:32 -   1.57
+++ uvideo.h8 Jul 2019 20:08:07 -
@@ -302,11 +302,15 @@ struct usb_video_probe_commit {
 
 #defineUVIDEO_FORMAT_GUID_NV12 {   \
 0x4e, 0x56, 0x31, 0x32, 0x00, 0x00, 0x10, 0x00,\
-0x80, 0x00, 0x00, 0xaa, 0x00, 0x38,0x9b, 0x71 }
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
 
 #defineUVIDEO_FORMAT_GUID_UYVY {   \
 0x55, 0x59, 0x56, 0x59, 0x00, 0x00, 0x10, 0x00,\
-0x80, 0x00, 0x00, 0xaa, 0x00, 0x38,0x9b, 0x71 }
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
+
+#defineUVIDEO_FORMAT_GUID_KSMEDIA_L8_IR{   \
+0x32, 0x00, 0x00, 0x00, 0x02, 0x00, 0x10, 0x00,\
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
 
 /*
  * USB Video Payload MJPEG



Re: sparc64 ldomctl(8) fix

2019-07-06 Thread Jan Klemkow
On Sat, Jul 06, 2019 at 12:59:55AM +0200, Mark Kettenis wrote:
> The diff below fixes interction between ldomctl(8) and the firmware on
> a SPARC T4 system that I have access to.  To make sure that this
> doesn't break other machines it would be good if people could test
> this on a few more ldoms-capable sparc64 machines.  To test just build
> ldomctl with this patch, install it and run "ldomctl list":
> 
> # cd /usr/src/usr.sbin/ldomctl
> # make obj
> # make
> # make install
> # ldomctl list

Tested on:
hw.model=SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
hw.product=SUNW,SPARC-Enterprise-T5220

# ldomctl list
factory-default
openbsd [current]

Works fine for me.

bye,
Jan

> Index: usr.sbin/ldomctl/mdstore.c
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/mdstore.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 mdstore.c
> --- usr.sbin/ldomctl/mdstore.c15 Sep 2018 13:20:16 -  1.8
> +++ usr.sbin/ldomctl/mdstore.c5 Jul 2019 22:54:01 -
> @@ -55,6 +55,7 @@ struct mdstore_msg {
>   uint64_tsvc_handle;
>   uint64_treqnum;
>   uint16_tcommand;
> + uint8_t reserved[6];
>  } __packed;
>  
>  struct mdstore_begin_end_req {
> @@ -104,7 +105,7 @@ struct mdstore_sel_del_req {
>   uint64_tsvc_handle;
>   uint64_treqnum;
>   uint16_tcommand;
> - uint16_treserved;
> + uint8_t reserved[2];
>   uint32_tnamelen;
>   charname[1];
>  } __packed;
> 



Re: free() sizes for ahc(4)

2019-05-14 Thread Jan Klemkow
On Tue, May 14, 2019 at 10:35:22AM +, Miod Vallat wrote:
> Note ahc_set_name() gets invoked with the dv_xname field of a struct
> device, so it's not a good idea to free anything, should it be invoked
> more than once.
> 
> Tested on:
> ahc0 at pci0 dev 1 function 0 "Adaptec AIC-7880" rev 0x00: irq 8
> ahc0: Host Adapter Bios disabled.  Using default SCSI device parameters
> scsibus0 at ahc0: 16 targets, initiator 7
> sd0 at scsibus0 targ 1 lun 0:  SCSI3 0/direct 
> fixed serial.SGI_IBM_DNES-318350Y_AK0T7943
> sd0: 17364MB, 512 bytes/sector, 35563040 sectors
> cd0 at scsibus0 targ 4 lun 0:  SCSI2 5/cdrom 
> removable
> ahc1 at pci0 dev 2 function 0 "Adaptec AIC-7880" rev 0x00: irq 9
> ahc1: Host Adapter Bios disabled.  Using default SCSI device parameters
> scsibus1 at ahc1: 16 targets, initiator 7

OK Jan
 
> Index: dev/ic/aic7xxx.c
> ===
> RCS file: /OpenBSD/src/sys/dev/ic/aic7xxx.c,v
> retrieving revision 1.93
> diff -u -p -u -p -r1.93 aic7xxx.c
> --- dev/ic/aic7xxx.c  12 Dec 2017 12:33:36 -  1.93
> +++ dev/ic/aic7xxx.c  14 May 2019 10:28:10 -
> @@ -1688,7 +1688,7 @@ ahc_free_tstate(struct ahc_softc *ahc, u
>   scsi_id += 8;
>   tstate = ahc->enabled_targets[scsi_id];
>   if (tstate != NULL)
> - free(tstate, M_DEVBUF, 0);
> + free(tstate, M_DEVBUF, sizeof(*tstate));
>   ahc->enabled_targets[scsi_id] = NULL;
>  }
>  #endif
> @@ -3957,8 +3957,6 @@ ahc_set_unit(struct ahc_softc *ahc, int 
>  void
>  ahc_set_name(struct ahc_softc *ahc, char *name)
>  {
> - if (ahc->name != NULL)
> - free(ahc->name, M_DEVBUF, 0);
>   ahc->name = name;
>  }
>  
> @@ -3997,21 +3995,21 @@ ahc_free(struct ahc_softc *ahc)
>   lstate = tstate->enabled_luns[j];
>   if (lstate != NULL) {
> /*xpt_free_path(lstate->path);*/
> - free(lstate, M_DEVBUF, 0);
> + free(lstate, M_DEVBUF, sizeof(*lstate));
>   }
>   }
>  #endif
> - free(tstate, M_DEVBUF, 0);
> + free(tstate, M_DEVBUF, sizeof(*tstate));
>   }
>   }
>  #ifdef AHC_TARGET_MODE
>   if (ahc->black_hole != NULL) {
> /*xpt_free_path(ahc->black_hole->path);*/
> - free(ahc->black_hole, M_DEVBUF, 0);
> + free(ahc->black_hole, M_DEVBUF, sizeof(*ahc->black_hole));
>   }
>  #endif
>   if (ahc->seep_config != NULL)
> - free(ahc->seep_config, M_DEVBUF, 0);
> + free(ahc->seep_config, M_DEVBUF, sizeof(*ahc->seep_config));
>   return;
>  }
>  
> @@ -4329,7 +4327,7 @@ ahc_fini_scbdata(struct ahc_softc *ahc)
>   ahc_freedmamem(ahc->parent_dmat, PAGE_SIZE,
>   sg_map->sg_dmamap, (caddr_t)sg_map->sg_vaddr,
>   _map->sg_dmasegs, sg_map->sg_nseg);
> - free(sg_map, M_DEVBUF, 0);
> + free(sg_map, M_DEVBUF, sizeof(*sg_map));
>   }
>   }
>   /*FALLTHROUGH*/
> @@ -4350,8 +4348,10 @@ ahc_fini_scbdata(struct ahc_softc *ahc)
>   case 0:
>   break;
>   }
> - if (scb_data->scbarray != NULL)
> - free(scb_data->scbarray, M_DEVBUF, 0);
> + if (scb_data->scbarray != NULL) {
> + free(scb_data->scbarray, M_DEVBUF,
> + AHC_SCB_MAX_ALLOC * sizeof(struct scb));
> + }
>  }
>  
>  void
> @@ -4383,7 +4383,7 @@ ahc_alloc_scbs(struct ahc_softc *ahc)
>(caddr_t *)_map->sg_vaddr, _map->sg_physaddr,
>_map->sg_dmasegs, _map->sg_nseg, 
> ahc_name(ahc),
>"SG space") < 0) {
> - free(sg_map, M_DEVBUF, 0);
> + free(sg_map, M_DEVBUF, sizeof(*sg_map));
>   return;
>   }
>  
> @@ -6859,7 +6859,7 @@ ahc_handle_en_lun(struct ahc_softc *ahc,
>xpt_path_target_id(ccb->ccb_h.path),
>xpt_path_lun_id(ccb->ccb_h.path));
>   if (status != CAM_REQ_CMP) {
> - free(lstate, M_DEVBUF, 0);
> + free(lstate, M_DEVBUF, sizeof(*lstate));
>   xpt_print_path(ccb->ccb_h.path);
>   printf("Couldn't allocate path\n");
>   ccb->ccb_h.status = CAM_RESRC_UNAVAIL;
> @@ -6980,7 +6980,7 @@ ahc_handle_en_lun(struct ahc_softc *ahc,
>   xpt_print_path(ccb->ccb_h.path);
>   printf("Target mode disabled\n");
>   xpt_free_path(lstate->path);
> - free(lstate, M_DEVBUF, 0);
> + free(lstate, M_DEVBUF, sizeof(*lstate));
>  
>   ahc_pause(ahc);
>   /* Can we clean up the target too? */
> Index: 

Re: softraid(4): fix wrong malloc size and zero sized free calls

2019-05-13 Thread Jan Klemkow
On Mon, May 13, 2019 at 07:25:37PM -0400, Ted Unangst wrote:
> Jan Klemkow wrote:
> > The diff mainly add sizes to free(9) calls.  But, while here fix a
> > malloc(9) call with the wrong size in sr_ioctl_installboot().
> > omi->omi_som is allocated with size of struct sr_meta_crypto, but used
> > as struct sr_meta_boot later.
> > 
> > One free(9) with size zero left over in sr_discipline_free().  As, the
> > allocated size of sd->sd_vol.sv_chunks is not ascertainable here without
> > larger changes.
> > 
> > Build and run the kernel for testing.
> 
> The change in installboot for the size is suspicious. I would leave that out.
> Especially if you haven't tested installboot to a crypto softraid. :)

Here is a diff with just the fixed free sizes.  Malloc size fix comes
separately.

OK?

Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.392
diff -u -p -r1.392 softraid.c
--- dev/softraid.c  2 May 2018 02:24:55 -   1.392
+++ dev/softraid.c  14 May 2019 05:13:02 -
@@ -1470,28 +1470,29 @@ unwind:
for (bc1 = SLIST_FIRST(>sbv_chunks); bc1 != NULL;
bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
-   free(bc1->sbc_metadata, M_DEVBUF, 0);
-   free(bc1, M_DEVBUF, 0);
+   free(bc1->sbc_metadata, M_DEVBUF,
+   sizeof(*bc1->sbc_metadata));
+   free(bc1, M_DEVBUF, sizeof(*bc1));
}
-   free(bv1, M_DEVBUF, 0);
+   free(bv1, M_DEVBUF, sizeof(*bv1));
}
/* Free keydisks chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
-   free(bc1->sbc_metadata, M_DEVBUF, 0);
-   free(bc1, M_DEVBUF, 0);
+   free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+   free(bc1, M_DEVBUF, sizeof(*bc1));
}
/* Free unallocated chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
-   free(bc1->sbc_metadata, M_DEVBUF, 0);
-   free(bc1, M_DEVBUF, 0);
+   free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+   free(bc1, M_DEVBUF, sizeof(*bc1));
}
 
while (!SLIST_EMPTY()) {
sdk = SLIST_FIRST();
SLIST_REMOVE_HEAD(, sdk_link);
-   free(sdk, M_DEVBUF, 0);
+   free(sdk, M_DEVBUF, sizeof(*sdk));
}
 
free(devs, M_DEVBUF, BIOC_CRMAXLEN * sizeof(dev_t));
@@ -1751,7 +1752,7 @@ sr_hotplug_unregister(struct sr_discipli
if (mhe != NULL) {
SLIST_REMOVE(_hotplug_callbacks, mhe,
sr_hotplug_list, shl_link);
-   free(mhe, M_DEVBUF, 0);
+   free(mhe, M_DEVBUF, sizeof(*mhe));
}
 }
 
@@ -1953,7 +1954,7 @@ sr_ccb_free(struct sr_discipline *sd)
while ((ccb = TAILQ_FIRST(>sd_ccb_freeq)) != NULL)
TAILQ_REMOVE(>sd_ccb_freeq, ccb, ccb_link);
 
-   free(sd->sd_ccb, M_DEVBUF, 0);
+   free(sd->sd_ccb, M_DEVBUF, sizeof(*sd->sd_ccb));
 }
 
 struct sr_ccb *
@@ -2132,7 +2133,7 @@ sr_wu_free(struct sr_discipline *sd)
 
while ((wu = TAILQ_FIRST(>sd_wu)) != NULL) {
TAILQ_REMOVE(>sd_wu, wu, swu_next);
-   free(wu, M_DEVBUF, 0);
+   free(wu, M_DEVBUF, sizeof(*wu));
}
 }
 
@@ -2966,13 +2967,14 @@ sr_hotspare(struct sr_softc *sc, dev_t d
goto done;
 
 fail:
-   free(hotspare, M_DEVBUF, 0);
+   free(hotspare, M_DEVBUF, sizeof(*hotspare));
 
 done:
if (sd)
-   free(sd->sd_vol.sv_chunks, M_DEVBUF, 0);
-   free(sd, M_DEVBUF, 0);
-   free(sm, M_DEVBUF, 0);
+   free(sd->sd_vol.sv_chunks, M_DEVBUF,
+   sizeof(sd->sd_vol.sv_chunks));
+   free(sd, M_DEVBUF, sizeof(*sd));
+   free(sm, M_DEVBUF, sizeof(*sm));
if (open) {
VOP_CLOSE(vn, FREAD | FWRITE, NOCRED, curproc);
vput(vn);
@@ -3079,7 +3081,7 @@ sr_hotspare_rebuild(struct sr_discipline
/* Remove hotspare from available list. */
sc->sc_hotspare_no--;
SLIST_REMOVE(cl, hotspare, sr_chunk, src_link);
-   free(hotspare, M_DEVBUF, 0);
+   free(hotspare, M_DEVBUF, sizeof(*hotspare));
 
}
rw_exit_write(>sc_lock);
@@ -3375,7 +3377,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
>sd_meta->ssdi.ssd_uuid);
sr_error(sc, &q

softraid(4): fix wrong malloc size and zero sized free calls

2019-05-13 Thread Jan Klemkow
Hi,

The diff mainly add sizes to free(9) calls.  But, while here fix a
malloc(9) call with the wrong size in sr_ioctl_installboot().
omi->omi_som is allocated with size of struct sr_meta_crypto, but used
as struct sr_meta_boot later.

One free(9) with size zero left over in sr_discipline_free().  As, the
allocated size of sd->sd_vol.sv_chunks is not ascertainable here without
larger changes.

Build and run the kernel for testing.

OK?

Bye,
Jan

Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.392
diff -u -p -r1.392 softraid.c
--- dev/softraid.c  2 May 2018 02:24:55 -   1.392
+++ dev/softraid.c  13 May 2019 22:40:04 -
@@ -1470,28 +1470,29 @@ unwind:
for (bc1 = SLIST_FIRST(>sbv_chunks); bc1 != NULL;
bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
-   free(bc1->sbc_metadata, M_DEVBUF, 0);
-   free(bc1, M_DEVBUF, 0);
+   free(bc1->sbc_metadata, M_DEVBUF,
+   sizeof(*bc1->sbc_metadata));
+   free(bc1, M_DEVBUF, sizeof(*bc1));
}
-   free(bv1, M_DEVBUF, 0);
+   free(bv1, M_DEVBUF, sizeof(*bv1));
}
/* Free keydisks chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
-   free(bc1->sbc_metadata, M_DEVBUF, 0);
-   free(bc1, M_DEVBUF, 0);
+   free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+   free(bc1, M_DEVBUF, sizeof(*bc1));
}
/* Free unallocated chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
-   free(bc1->sbc_metadata, M_DEVBUF, 0);
-   free(bc1, M_DEVBUF, 0);
+   free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+   free(bc1, M_DEVBUF, sizeof(*bc1));
}
 
while (!SLIST_EMPTY()) {
sdk = SLIST_FIRST();
SLIST_REMOVE_HEAD(, sdk_link);
-   free(sdk, M_DEVBUF, 0);
+   free(sdk, M_DEVBUF, sizeof(*sdk));
}
 
free(devs, M_DEVBUF, BIOC_CRMAXLEN * sizeof(dev_t));
@@ -1751,7 +1752,7 @@ sr_hotplug_unregister(struct sr_discipli
if (mhe != NULL) {
SLIST_REMOVE(_hotplug_callbacks, mhe,
sr_hotplug_list, shl_link);
-   free(mhe, M_DEVBUF, 0);
+   free(mhe, M_DEVBUF, sizeof(*mhe));
}
 }
 
@@ -1953,7 +1954,7 @@ sr_ccb_free(struct sr_discipline *sd)
while ((ccb = TAILQ_FIRST(>sd_ccb_freeq)) != NULL)
TAILQ_REMOVE(>sd_ccb_freeq, ccb, ccb_link);
 
-   free(sd->sd_ccb, M_DEVBUF, 0);
+   free(sd->sd_ccb, M_DEVBUF, sizeof(*sd->sd_ccb));
 }
 
 struct sr_ccb *
@@ -2132,7 +2133,7 @@ sr_wu_free(struct sr_discipline *sd)
 
while ((wu = TAILQ_FIRST(>sd_wu)) != NULL) {
TAILQ_REMOVE(>sd_wu, wu, swu_next);
-   free(wu, M_DEVBUF, 0);
+   free(wu, M_DEVBUF, sizeof(*wu));
}
 }
 
@@ -2966,13 +2967,14 @@ sr_hotspare(struct sr_softc *sc, dev_t d
goto done;
 
 fail:
-   free(hotspare, M_DEVBUF, 0);
+   free(hotspare, M_DEVBUF, sizeof(*hotspare));
 
 done:
if (sd)
-   free(sd->sd_vol.sv_chunks, M_DEVBUF, 0);
-   free(sd, M_DEVBUF, 0);
-   free(sm, M_DEVBUF, 0);
+   free(sd->sd_vol.sv_chunks, M_DEVBUF,
+   sizeof(sd->sd_vol.sv_chunks));
+   free(sd, M_DEVBUF, sizeof(*sd));
+   free(sm, M_DEVBUF, sizeof(*sm));
if (open) {
VOP_CLOSE(vn, FREAD | FWRITE, NOCRED, curproc);
vput(vn);
@@ -3079,7 +3081,7 @@ sr_hotspare_rebuild(struct sr_discipline
/* Remove hotspare from available list. */
sc->sc_hotspare_no--;
SLIST_REMOVE(cl, hotspare, sr_chunk, src_link);
-   free(hotspare, M_DEVBUF, 0);
+   free(hotspare, M_DEVBUF, sizeof(*hotspare));
 
}
rw_exit_write(>sc_lock);
@@ -3375,7 +3377,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
>sd_meta->ssdi.ssd_uuid);
sr_error(sc, "disk %s is currently in use; "
"cannot force create", uuid);
-   free(uuid, M_DEVBUF, 0);
+   free(uuid, M_DEVBUF, 37);
goto unwind;
}
 
@@ -3439,7 +3441,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
if (sr_already_assembled(sd)) {
uuid = sr_uuid_format(>sd_meta->ssdi.ssd_uuid);
sr_error(sc, "disk %s already 

enable cy(4) by default on amd64

2019-05-12 Thread Jan Klemkow
Hi,

I use tree cy(4) cards on amd64 for several releases.  Its totally
stable and works fine beside known bugs already mentioned in the
manpage.  Thus, I would prefer to enabled it by default in amd64 as it
is in i386.

Bye,
Jan

Index: arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.471
diff -u -p -r1.471 GENERIC
--- arch/amd64/conf/GENERIC 8 May 2019 23:54:39 -   1.471
+++ arch/amd64/conf/GENERIC 13 May 2019 05:13:47 -
@@ -382,7 +382,7 @@ com*at pcmcia?  # PCMCIA 
modems/serial
 com*   at puc?
 
 # options CY_HW_RTS
-#cy*   at pci? # PCI cyclom serial card
+cy*at pci? # PCI cyclom serial card
 #cz*   at pci? # Cyclades-Z multi-port serial boards
 
 lpt0   at isa? port 0x378 irq 7# standard PC parallel ports



sv(4): fix free with zero size

2019-05-12 Thread Jan Klemkow
Hi,

The following diff fixes "free with zero size" in sv(4).  Builds and
stats the kernel with sv at pci and audio at sv enabled.

bye,
Jan

Index: dev/pci/sv.c
===
RCS file: /cvs/src/sys/dev/pci/sv.c,v
retrieving revision 1.34
diff -u -p -r1.34 sv.c
--- dev/pci/sv.c19 Sep 2016 06:46:44 -  1.34
+++ dev/pci/sv.c13 May 2019 04:33:56 -
@@ -1286,7 +1286,7 @@ sv_malloc(void *addr, int direction, siz
 return (0);
 error = sv_allocmem(sc, size, 16, p);
 if (error) {
-free(p, pool, 0);
+free(p, pool, sizeof(*p));
return (0);
 }
 p->next = sc->sc_dmas;
@@ -1304,7 +1304,7 @@ sv_free(void *addr, void *ptr, int pool)
 if (KERNADDR(*p) == ptr) {
 sv_freemem(sc, *p);
 *p = (*p)->next;
-free(*p, pool, 0);
+free(*p, pool, sizeof(**p));
 return;
 }
 }



Re: ftpd(8): rm dead code and simplifies popen clone

2019-05-08 Thread Jan Klemkow
On Wed, May 08, 2019 at 07:10:37PM -0400, Ted Unangst wrote:
> Jan Klemkow wrote:
> > - * Special version of popen which avoids call to shell.  This ensures noone
> > + * Special version of popen which avoids call to shell.  This ensures none
> 
> If we don't like noone, the correct spelling is no one.
> 
> Rest of the diff seems like a good improvement.

fixed.

Thanks,
Jan

Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.19
diff -u -p -r1.19 extern.h
--- extern.h4 Oct 2015 11:58:09 -   1.19
+++ extern.h8 May 2019 20:02:23 -
@@ -68,7 +68,7 @@ void  delete(char *);
 void   dologout(int);
 void   fatal(char *);
 intftpd_pclose(FILE *, pid_t);
-FILE   *ftpd_popen(char *, char *, pid_t *);
+FILE   *ftpd_ls(char *, char *, pid_t *);
 int get_line(char *, int, FILE *);
 void   ftpdlogwtmp(char *, char *, char *);
 void   lreply(int, const char *, ...);
@@ -89,7 +89,8 @@ void  renamecmd(char *, char *);
 char   *renamefrom(char *);
 void   reply(int, const char *, ...);
 void   reply_r(int, const char *, ...);
-void   retrieve(char *, char *);
+enum ret_cmd { RET_FILE, RET_LIST };
+void   retrieve(enum ret_cmd, char *);
 void   send_file_list(char *);
 void   setproctitle(const char *, ...);
 void   statcmd(void);
Index: ftpcmd.y
===
RCS file: /cvs/src/libexec/ftpd/ftpcmd.y,v
retrieving revision 1.66
diff -u -p -r1.66 ftpcmd.y
--- ftpcmd.y27 Apr 2017 13:30:54 -  1.66
+++ ftpcmd.y8 May 2019 20:03:29 -
@@ -342,7 +342,7 @@ cmd
| RETR check_login SP pathname CRLF
{
if ($2 && $4 != NULL)
-   retrieve(NULL, $4);
+   retrieve(RET_FILE, $4);
if ($4 != NULL)
free($4);
}
@@ -374,12 +374,12 @@ cmd
| LIST check_login CRLF
{
if ($2)
-   retrieve("/bin/ls -lgA", "");
+   retrieve(RET_LIST, NULL);
}
| LIST check_login SP pathname CRLF
{
if ($2 && $4 != NULL)
-   retrieve("/bin/ls -lgA %s", $4);
+   retrieve(RET_LIST, $4);
if ($4 != NULL)
free($4);
}
Index: ftpd.8
===
RCS file: /cvs/src/libexec/ftpd/ftpd.8,v
retrieving revision 1.75
diff -u -p -r1.75 ftpd.8
--- ftpd.8  25 Oct 2015 23:10:53 -  1.75
+++ ftpd.8  8 May 2019 20:08:15 -
@@ -385,15 +385,6 @@ subtree be constructed with care, follow
 Make the home directory owned by
 .Dq root
 and unwritable by anyone (mode 555).
-.It Pa ~ftp/bin
-Make this directory owned by
-.Dq root
-and unwritable by anyone (mode 511).
-This directory is optional unless you have commands you wish
-the anonymous FTP user to be able to run (the
-.Xr ls 1
-command exists as a built-in).
-Any programs in this directory should be mode 111 (executable only).
 .It Pa ~ftp/etc
 Make this directory owned by
 .Dq root
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.225
diff -u -p -r1.225 ftpd.c
--- ftpd.c  11 Dec 2018 18:19:55 -  1.225
+++ ftpd.c  8 May 2019 22:45:07 -
@@ -1113,36 +1113,32 @@ bad:
 }
 
 void
-retrieve(char *cmd, char *name)
+retrieve(enum ret_cmd cmd, char *name)
 {
FILE *fin, *dout;
struct stat st;
pid_t pid;
time_t start;
 
-   if (cmd == NULL) {
+   if (cmd == RET_FILE) {
fin = fopen(name, "r");
st.st_size = 0;
} else {
-   char line[BUFSIZ];
-
-   (void) snprintf(line, sizeof(line), cmd, name);
-   name = line;
-   fin = ftpd_popen(line, "r", );
+   fin = ftpd_ls("-lgA", name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
if (fin == NULL) {
if (errno != 0) {
perror_reply(550, name);
-   if (cmd == NULL) {
+   if (cmd == RET_FILE) {
LOGCMD("get", name);
}
}
return;
}
byte_count = -1;
-   if (cmd == NULL &&
+   if (cmd == RET_FILE &&
(fstat(fileno(fin), ) < 0 || !S_ISREG(st.st_mode))) {
reply(550, "%s: not a plain file.", name);
goto done;
@@ -1175,

ftpd(8): rm dead code and simplifies popen clone

2019-05-08 Thread Jan Klemkow
Hi,

This diff removes dead code from ftpd(8).  In the past ftpd executes
ls(1) for directory listings.  But, quite a while now It justs calls the
main function of the linked in ls(1) directly.  The code path to the
main function of ls(1) as well as the read-only mode are hard coded in
the current version of ftpd.  All callers of ftpd_popen() calls it with
"/bin/ls" as program path.  The diff below renames ftpd_popen() to
ftpd_ls() and simplifies the function.  Also, the manpage section to
"~ftp/bin" is removed, because ftpd is not able to exec other programs.

I don't know if its usual?!  But, I used an enum to signal file transfer
or listing for the retrieve function.  The code seems to be more
readable for for me.

bye,
Jan

Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.19
diff -u -p -r1.19 extern.h
--- extern.h4 Oct 2015 11:58:09 -   1.19
+++ extern.h8 May 2019 20:02:23 -
@@ -68,7 +68,7 @@ void  delete(char *);
 void   dologout(int);
 void   fatal(char *);
 intftpd_pclose(FILE *, pid_t);
-FILE   *ftpd_popen(char *, char *, pid_t *);
+FILE   *ftpd_ls(char *, char *, pid_t *);
 int get_line(char *, int, FILE *);
 void   ftpdlogwtmp(char *, char *, char *);
 void   lreply(int, const char *, ...);
@@ -89,7 +89,8 @@ void  renamecmd(char *, char *);
 char   *renamefrom(char *);
 void   reply(int, const char *, ...);
 void   reply_r(int, const char *, ...);
-void   retrieve(char *, char *);
+enum ret_cmd { RET_FILE, RET_LIST };
+void   retrieve(enum ret_cmd, char *);
 void   send_file_list(char *);
 void   setproctitle(const char *, ...);
 void   statcmd(void);
Index: ftpcmd.y
===
RCS file: /cvs/src/libexec/ftpd/ftpcmd.y,v
retrieving revision 1.66
diff -u -p -r1.66 ftpcmd.y
--- ftpcmd.y27 Apr 2017 13:30:54 -  1.66
+++ ftpcmd.y8 May 2019 20:03:29 -
@@ -342,7 +342,7 @@ cmd
| RETR check_login SP pathname CRLF
{
if ($2 && $4 != NULL)
-   retrieve(NULL, $4);
+   retrieve(RET_FILE, $4);
if ($4 != NULL)
free($4);
}
@@ -374,12 +374,12 @@ cmd
| LIST check_login CRLF
{
if ($2)
-   retrieve("/bin/ls -lgA", "");
+   retrieve(RET_LIST, NULL);
}
| LIST check_login SP pathname CRLF
{
if ($2 && $4 != NULL)
-   retrieve("/bin/ls -lgA %s", $4);
+   retrieve(RET_LIST, $4);
if ($4 != NULL)
free($4);
}
Index: ftpd.8
===
RCS file: /cvs/src/libexec/ftpd/ftpd.8,v
retrieving revision 1.75
diff -u -p -r1.75 ftpd.8
--- ftpd.8  25 Oct 2015 23:10:53 -  1.75
+++ ftpd.8  8 May 2019 20:08:15 -
@@ -385,15 +385,6 @@ subtree be constructed with care, follow
 Make the home directory owned by
 .Dq root
 and unwritable by anyone (mode 555).
-.It Pa ~ftp/bin
-Make this directory owned by
-.Dq root
-and unwritable by anyone (mode 511).
-This directory is optional unless you have commands you wish
-the anonymous FTP user to be able to run (the
-.Xr ls 1
-command exists as a built-in).
-Any programs in this directory should be mode 111 (executable only).
 .It Pa ~ftp/etc
 Make this directory owned by
 .Dq root
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.225
diff -u -p -r1.225 ftpd.c
--- ftpd.c  11 Dec 2018 18:19:55 -  1.225
+++ ftpd.c  8 May 2019 22:45:07 -
@@ -1113,36 +1113,32 @@ bad:
 }
 
 void
-retrieve(char *cmd, char *name)
+retrieve(enum ret_cmd cmd, char *name)
 {
FILE *fin, *dout;
struct stat st;
pid_t pid;
time_t start;
 
-   if (cmd == NULL) {
+   if (cmd == RET_FILE) {
fin = fopen(name, "r");
st.st_size = 0;
} else {
-   char line[BUFSIZ];
-
-   (void) snprintf(line, sizeof(line), cmd, name);
-   name = line;
-   fin = ftpd_popen(line, "r", );
+   fin = ftpd_ls("-lgA", name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
if (fin == NULL) {
if (errno != 0) {
perror_reply(550, name);
-   if (cmd == NULL) {
+   if (cmd == RET_FILE) {
LOGCMD("get", name);
}
}
return;
}
byte_count = -1;
-   if (cmd == 

diff: reboot(8): document the -l option

2019-03-25 Thread Jan Klemkow
Hi,

The following diff adds missing documentation for the -l option of
reboot(8) as its done in NetBSD.

Bye,
Jan

Index: reboot.8
===
RCS file: /cvs/src/sbin/reboot/reboot.8,v
retrieving revision 1.50
diff -u -p -r1.50 reboot.8
--- reboot.83 Sep 2016 14:25:05 -   1.50
+++ reboot.825 Mar 2019 14:12:48 -
@@ -30,7 +30,7 @@
 .\"
 .\"@(#)reboot.88.1 (Berkeley) 6/9/93
 .\"
-.Dd $Mdocdate: September 3 2016 $
+.Dd $Mdocdate: March 25 2019 $
 .Dt REBOOT 8
 .Os
 .Sh NAME
@@ -39,9 +39,9 @@
 .Nd stopping and restarting the system
 .Sh SYNOPSIS
 .Nm halt
-.Op Fl dnpq
+.Op Fl dlnpq
 .Nm reboot
-.Op Fl dnq
+.Op Fl dlnq
 .Sh DESCRIPTION
 The
 .Nm halt
@@ -70,6 +70,10 @@ capturing the state of a corrupted or mi
 See
 .Xr savecore 8
 for information on how to recover this dump.
+.It Fl l
+Suppress sending a message via
+.Xr syslog 3
+before halting or restarting.
 .It Fl n
 Prevent file system cache from being flushed.
 This option should probably not be used.
Index: reboot.c
===
RCS file: /cvs/src/sbin/reboot/reboot.c,v
retrieving revision 1.38
diff -u -p -r1.38 reboot.c
--- reboot.c22 Aug 2017 00:30:16 -  1.38
+++ reboot.c25 Mar 2019 14:03:43 -
@@ -94,7 +94,7 @@ main(int argc, char *argv[])
case 'd':
howto |= RB_DUMP;
break;
-   case 'l':   /* Undocumented; used by shutdown. */
+   case 'l':
lflag = 1;
break;
case 'n':
@@ -272,7 +272,7 @@ restart:
 void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-dn%sq]\n", __progname,
+   fprintf(stderr, "usage: %s [-dln%sq]\n", __progname,
dohalt ? "p" : "");
exit(1);
 }



diff: add support for ANT-USBStick2 to uscom(4)

2019-02-22 Thread Jan Klemkow
Hi,

The diff below adds support for the Dynastream "ANT USBStick2" to
uscom(4).  The device attached with the following message:

uscom0 at uhub0 port 2 configuration 1 interface 0 "Dynastream Innovations ANT 
USBStick2" rev 2.00/1.00 addr 2
ucom0 at uscom0 portno 0

Additionally, I tested the device with the command:

# cu -l /dev/cuaU0 | od -h
... a4 01 ae 00 0b ...

It returns a valid ANT binary error message.

Bye,
Jan

Index: dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.694
diff -u -p -r1.694 usbdevs
--- dev/usb/usbdevs 14 Jan 2019 03:28:03 -  1.694
+++ dev/usb/usbdevs 22 Feb 2019 17:54:59 -
@@ -1640,6 +1640,7 @@ product DVICO RT3070  0xb307  RT3070
 product DYNASTREAM ANTDEVBOARD 0x1003  ANT dev board
 product DYNASTREAM ANT2USB 0x1004  ANT2USB
 product DYNASTREAM ANTDEVBOARD20x1006  ANT dev board
+product DYNASTREAM ANTUSB2 0x1008  ANTUSB-2 Stick
 product DYNASTREAM ANTUSBM 0x1009  ANTUSB-m Stick
 
 /* EasyDisk products */
Index: dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.706
diff -u -p -r1.706 usbdevs.h
--- dev/usb/usbdevs.h   14 Jan 2019 03:28:51 -  1.706
+++ dev/usb/usbdevs.h   22 Feb 2019 18:05:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.706 2019/01/14 03:28:51 jmatthew Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -1647,6 +1647,7 @@
 #defineUSB_PRODUCT_DYNASTREAM_ANTDEVBOARD  0x1003  /* ANT 
dev board */
 #defineUSB_PRODUCT_DYNASTREAM_ANT2USB  0x1004  /* ANT2USB */
 #defineUSB_PRODUCT_DYNASTREAM_ANTDEVBOARD2 0x1006  /* ANT 
dev board */
+#defineUSB_PRODUCT_DYNASTREAM_ANTUSB2  0x1008  /* ANTUSB-2 
Stick */
 #defineUSB_PRODUCT_DYNASTREAM_ANTUSBM  0x1009  /* ANTUSB-m 
Stick */
 
 /* EasyDisk products */
Index: dev/usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.700
diff -u -p -r1.700 usbdevs_data.h
--- dev/usb/usbdevs_data.h  14 Jan 2019 03:28:51 -  1.700
+++ dev/usb/usbdevs_data.h  22 Feb 2019 18:05:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.700 2019/01/14 03:28:51 jmatthew Exp $ 
*/
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -2876,6 +2876,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTDEVBOARD2,
"ANT dev board",
+   },
+   {
+   USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTUSB2,
+   "ANTUSB-2 Stick",
},
{
USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTUSBM,
Index: dev/usb/uscom.c
===
RCS file: /cvs/src/sys/dev/usb/uscom.c,v
retrieving revision 1.6
diff -u -p -r1.6 uscom.c
--- dev/usb/uscom.c 22 Aug 2018 15:32:49 -  1.6
+++ dev/usb/uscom.c 22 Feb 2019 17:55:44 -
@@ -53,6 +53,7 @@ struct ucom_methods uscom_methods = {
 
 static const struct usb_devno uscom_devs[] = {
{ USB_VENDOR_HP,USB_PRODUCT_HP_HPX9GP },
+   { USB_VENDOR_DYNASTREAM,USB_PRODUCT_DYNASTREAM_ANTUSB2 },
{ USB_VENDOR_DYNASTREAM,USB_PRODUCT_DYNASTREAM_ANTUSBM }
 };
 



diff: add missing bit description for pkthdr_pf.flags

2019-02-08 Thread Jan Klemkow
Hi,

The following diff adds the description of the second bit of the struct
pkthdr_pf field flags.

bye,
Jan

Index: sys/sys/mbuf.h
===
RCS file: /cvs/src/sys/sys/mbuf.h,v
retrieving revision 1.241
diff -u -p -r1.241 mbuf.h
--- sys/sys/mbuf.h  7 Dec 2018 08:37:24 -   1.241
+++ sys/sys/mbuf.h  8 Feb 2019 16:25:12 -
@@ -119,8 +119,8 @@ struct pkthdr_pf {
 
 #ifdef _KERNEL
 #define MPF_BITS \
-("\20\1GENERATED\3TRANSLATE_LOCALHOST\4DIVERTED\5DIVERTED_PACKET" \
-"\6REROUTE\7REFRAGMENTED\10PROCESSED")
+("\20\1GENERATED\2SYNCOOKIE_RECREATED\3TRANSLATE_LOCALHOST\4DIVERTED" \
+"\5DIVERTED_PACKET\6REROUTE\7REFRAGMENTED\10PROCESSED")
 #endif
 
 /* record/packet header in first mbuf of chain; valid if M_PKTHDR set */



snmpd: dup open ttys to /dev/null in demons mode

2019-01-07 Thread Jan Klemkow
Hi,

This diff is similar to bluhm@'s fix for httpd and relayd, but for snmpd.

> During the fork+exec implementation, daemon(3) was moved after
> proc_init().  As a consequence httpd(8) and relayd(8) child processes
> do not detach from the terminal anymore.  Dup /dev/null to the stdio
> file descriptors in the children.

bye,
Jan

Index: proc.c
===
RCS file: /cvs/src/usr.sbin/snmpd/proc.c,v
retrieving revision 1.25
diff -u -p -r1.25 proc.c
--- proc.c  5 Aug 2018 09:33:13 -   1.25
+++ proc.c  8 Jan 2019 00:29:29 -
@@ -29,13 +29,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 #include "snmpd.h"
 
-voidproc_exec(struct privsep *, struct privsep_proc *, unsigned int,
+voidproc_exec(struct privsep *, struct privsep_proc *, unsigned int, int,
int, char **);
 voidproc_setup(struct privsep *, struct privsep_proc *, unsigned int);
 voidproc_open(struct privsep *, int, int);
@@ -80,7 +81,7 @@ proc_getid(struct privsep_proc *procs, u
 
 void
 proc_exec(struct privsep *ps, struct privsep_proc *procs, unsigned int nproc,
-int argc, char **argv)
+int debug, int argc, char **argv)
 {
unsigned int proc, nargc, i, proc_i;
char**nargv;
@@ -141,6 +142,16 @@ proc_exec(struct privsep *ps, struct pri
} else if (fcntl(fd, F_SETFD, 0) == -1)
fatal("fcntl");
 
+   /* Daemons detach from terminal. */
+   if (!debug && (fd =
+   open(_PATH_DEVNULL, O_RDWR, 0)) != -1) {
+   (void)dup2(fd, STDIN_FILENO);
+   (void)dup2(fd, STDOUT_FILENO);
+   (void)dup2(fd, STDERR_FILENO);
+   if (fd > 2)
+   (void)close(fd);
+   }
+
execvp(argv[0], nargv);
fatal("%s: execvp", __func__);
break;
@@ -191,7 +202,7 @@ proc_connect(struct privsep *ps)
 
 void
 proc_init(struct privsep *ps, struct privsep_proc *procs, unsigned int nproc,
-int argc, char **argv, enum privsep_procid proc_id)
+int debug, int argc, char **argv, enum privsep_procid proc_id)
 {
struct privsep_proc *p = NULL;
struct privsep_pipes*pa, *pb;
@@ -231,7 +242,7 @@ proc_init(struct privsep *ps, struct pri
}
 
/* Engage! */
-   proc_exec(ps, procs, nproc, argc, argv);
+   proc_exec(ps, procs, nproc, debug, argc, argv);
return;
}
 
Index: snmpd.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.c,v
retrieving revision 1.40
diff -u -p -r1.40 snmpd.c
--- snmpd.c 5 Nov 2018 11:59:05 -   1.40
+++ snmpd.c 8 Jan 2019 00:29:02 -
@@ -230,7 +230,7 @@ main(int argc, char *argv[])
pf_init();
snmpd_generate_engineid(env);
 
-   proc_init(ps, procs, nitems(procs), argc0, argv0, proc_id);
+   proc_init(ps, procs, nitems(procs), debug, argc0, argv0, proc_id);
if (!debug && daemon(0, 0) == -1)
err(1, "failed to daemonize");
 
Index: snmpd.h
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
retrieving revision 1.80
diff -u -p -r1.80 snmpd.h
--- snmpd.h 5 Aug 2018 09:33:13 -   1.80
+++ snmpd.h 8 Jan 2019 00:25:01 -
@@ -762,7 +762,7 @@ void usm_make_report(struct snmp_messa
 /* proc.c */
 enum privsep_procid
proc_getid(struct privsep_proc *, unsigned int, const char *);
-voidproc_init(struct privsep *, struct privsep_proc *, unsigned int,
+voidproc_init(struct privsep *, struct privsep_proc *, unsigned int, int,
int, char **, enum privsep_procid);
 voidproc_kill(struct privsep *);
 voidproc_connect(struct privsep *);



diff: new PCI Vendor and Product ID for RocketPort serial card

2019-01-07 Thread Jan Klemkow
Hi,

the following diff adds the PCI vendor and product ID for a PCI
multiport serial card.

dmesg shows the device as:
"Comtrol Corporation RocketPort PCI 16-port Serial" rev 0x01 at pci1 dev
1 function 0 not configured

bye,
Jan

Index: pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1874
diff -u -p -r1.1874 pcidevs
--- pci/pcidevs 5 Jan 2019 11:49:41 -   1.1874
+++ pci/pcidevs 7 Jan 2019 20:23:36 -
@@ -194,6 +194,7 @@ vendor  AD  0x11d4  Analog Devices
 vendor ZORAN   0x11de  Zoran
 vendor PIJNENBURG  0x11e3  Pijnenburg
 vendor COMPEX  0x11f6  Compex
+vendor COMCORP 0x11fe  Comtrol Corporation
 vendor CYCLADES0x120e  Cyclades
 vendor ESSENTIAL   0x120f  Essential Communications
 vendor O2MICRO 0x1217  O2 Micro
@@ -2423,6 +2424,9 @@ product COMPAQ NF3P_BNC   0xf150  NetFlex 
 product COMPEX COMPEXE 0x1401  Compexe
 product COMPEX RL100ATX0x2011  RL100-ATX 10/100
 product COMPEX 98713   0x9881  PMAC 98713
+
+/* Comtrol Corporation */
+product COMCORP ROCKETPORT_16  0x0009  RocketPort PCI 16-port Serial
 
 /* Conexant products */
 product CONEXANT 56K_WINMODEM  0x1033  56k Winmodem
Index: pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1867
diff -u -p -r1.1867 pcidevs.h
--- pci/pcidevs.h   5 Jan 2019 11:50:32 -   1.1867
+++ pci/pcidevs.h   7 Jan 2019 20:23:37 -
@@ -199,6 +199,7 @@
 #definePCI_VENDOR_ZORAN0x11de  /* Zoran */
 #definePCI_VENDOR_PIJNENBURG   0x11e3  /* Pijnenburg */
 #definePCI_VENDOR_COMPEX   0x11f6  /* Compex */
+#definePCI_VENDOR_COMCORP  0x11fe  /* Comtrol Corporation 
*/
 #definePCI_VENDOR_CYCLADES 0x120e  /* Cyclades */
 #definePCI_VENDOR_ESSENTIAL0x120f  /* Essential 
Communications */
 #definePCI_VENDOR_O2MICRO  0x1217  /* O2 Micro */
@@ -2428,6 +2429,9 @@
 #definePCI_PRODUCT_COMPEX_COMPEXE  0x1401  /* Compexe */
 #definePCI_PRODUCT_COMPEX_RL100ATX 0x2011  /* RL100-ATX 
10/100 */
 #definePCI_PRODUCT_COMPEX_987130x9881  /* PMAC 98713 */
+
+/* Comtrol Corporation */
+#definePCI_PRODUCT_COMCORP_ROCKETPORT_16   0x0009  /* 
RocketPort PCI 16-port Serial */
 
 /* Conexant products */
 #definePCI_PRODUCT_CONEXANT_56K_WINMODEM   0x1033  /* 56k 
Winmodem */
Index: pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1862
diff -u -p -r1.1862 pcidevs_data.h
--- pci/pcidevs_data.h  5 Jan 2019 11:50:32 -   1.1862
+++ pci/pcidevs_data.h  7 Jan 2019 20:23:37 -
@@ -7680,6 +7680,10 @@ static const struct pci_known_product pc
"PMAC 98713",
},
{
+   PCI_VENDOR_COMCORP, PCI_PRODUCT_COMCORP_ROCKETPORT_16,
+   "RocketPort PCI 16-port Serial",
+   },
+   {
PCI_VENDOR_CONEXANT, PCI_PRODUCT_CONEXANT_56K_WINMODEM,
"56k Winmodem",
},
@@ -28734,6 +28738,10 @@ static const struct pci_known_vendor pci
{
PCI_VENDOR_COMPEX,
"Compex",
+   },
+   {
+   PCI_VENDOR_COMCORP,
+   "Comtrol Corporation",
},
{
PCI_VENDOR_CYCLADES,



diff: fix missing include guard in dev/biovar.h

2018-12-19 Thread Jan Klemkow
Hi,

I run into double definition problems because of a missing include guard
in dev/biovar.h.  The diff below should fix that issue.

Bye,
Jan

Index: sys/dev/biovar.h
===
RCS file: /cvs/src/sys/dev/biovar.h,v
retrieving revision 1.45
diff -u -p -r1.45 biovar.h
--- sys/dev/biovar.h14 Aug 2016 04:08:03 -  1.45
+++ sys/dev/biovar.h19 Dec 2018 18:00:36 -
@@ -26,6 +26,9 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#ifndef _DEV_BIOVAR_H_
+#define _DEV_BIOVAR_H_
+
 /*
  * Devices getting ioctls through this interface should use ioctl class 'B'
  * and command numbers starting from 32, lower ones are reserved for generic
@@ -305,3 +308,4 @@ voidbio_info(struct bio_status *, int, 
 void   bio_warn(struct bio_status *, int, const char *, ...);
 void   bio_error(struct bio_status *, int, const char *, ...);
 #endif
+#endif /* _DEV_BIOVAR_H_ */



Re: diff: ftpd(8): fix for sign-compare compiler warnings

2018-12-06 Thread Jan Klemkow
On Tue, Nov 27, 2018 at 09:03:15AM +0100, Theo Buehler wrote:
> On Sun, Nov 25, 2018 at 12:32:23AM +0100, Jan Klemkow wrote:
> > This diff fixes some -Wsign-compare compiler warnings in ftpd(8) by
> > using the right types for 'i' and 'len'.  One warning is left, but I
> > don't see that it's fixable without suppressing the warning by a cast of
> > len to size_t.  And casting might be controversial in this case?!
> 
> The diff looks correct to me. If anyone wants to commit
> 
> ok tb
> 
> > /usr/src/libexec/ftpd/ftpd.c:2781:11: warning: comparison of integers of
> > different signs: 'int' and
> >   'unsigned long' [-Wsign-compare]
> > if (len >= sizeof(buf) || len == -1) {
> > ~~~ ^  ~~~
> 
> This test is the wrong way around: compare CAVEATS in snprintf(3).

I missed that.  The following diff fixes that, but doesn't include
a cast.

> There's a ton of unchecked snprintfs in this code. Did you take a look
> at those?

Yes, I noticed that.  I may change that in a later diff.

Thanks,
Jan

Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.223
diff -u -p -r1.223 ftpd.c
--- ftpd.c  3 Sep 2016 15:00:48 -   1.223
+++ ftpd.c  6 Dec 2018 18:19:21 -
@@ -390,10 +390,10 @@ main(int argc, char *argv[])
endpwent();
 
if (daemon_mode) {
-   int *fds, i, fd;
+   int *fds, fd;
struct pollfd *pfds;
struct addrinfo hints, *res, *res0;
-   nfds_t n;
+   nfds_t n, i;
 
/*
 * Detach from parent.
@@ -1809,8 +1809,8 @@ statcmd(void)
ispassive++;
goto printaddr;
} else if (usedefault == 0) {
-   size_t alen;
-   int af, i;
+   size_t alen, i;
+   int af;
 
su = (union sockunion *)_dest;
 printaddr:
@@ -2545,7 +2545,8 @@ guniquefd(char *local, char **nam)
 {
static char new[PATH_MAX];
struct stat st;
-   int count, len, fd;
+   size_t len;
+   int count, fd;
char *cp;
 
cp = strrchr(local, '/');
@@ -2777,7 +2778,7 @@ logxfer(char *name, off_t size, time_t s
((guest) ? "*" : pw->pw_name), dhostname);
free(vpw);
 
-   if (len >= sizeof(buf) || len == -1) {
+   if (len == -1 || len >= sizeof(buf)) {
if ((len = strlen(buf)) == 0)
return; /* should not happen */
buf[len - 1] = '\n';



diff: ftpd(8): fix for sign-compare compiler warnings

2018-11-24 Thread Jan Klemkow
Hi,

This diff fixes some -Wsign-compare compiler warnings in ftpd(8) by
using the right types for 'i' and 'len'.  One warning is left, but I
don't see that it's fixable without suppressing the warning by a cast of
len to size_t.  And casting might be controversial in this case?!

/usr/src/libexec/ftpd/ftpd.c:2781:11: warning: comparison of integers of
different signs: 'int' and
  'unsigned long' [-Wsign-compare]
if (len >= sizeof(buf) || len == -1) {
~~~ ^  ~~~

Bye,
Jan

Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.223
diff -u -p -r1.223 ftpd.c
--- ftpd.c  3 Sep 2016 15:00:48 -   1.223
+++ ftpd.c  24 Nov 2018 22:26:02 -
@@ -390,10 +390,10 @@ main(int argc, char *argv[])
endpwent();
 
if (daemon_mode) {
-   int *fds, i, fd;
+   int *fds, fd;
struct pollfd *pfds;
struct addrinfo hints, *res, *res0;
-   nfds_t n;
+   nfds_t n, i;
 
/*
 * Detach from parent.
@@ -1809,8 +1809,8 @@ statcmd(void)
ispassive++;
goto printaddr;
} else if (usedefault == 0) {
-   size_t alen;
-   int af, i;
+   size_t alen, i;
+   int af;
 
su = (union sockunion *)_dest;
 printaddr:
@@ -2545,7 +2545,8 @@ guniquefd(char *local, char **nam)
 {
static char new[PATH_MAX];
struct stat st;
-   int count, len, fd;
+   size_t len;
+   int count, fd;
char *cp;
 
cp = strrchr(local, '/');



Re: diff: Fix send(2) EACCES mistake

2018-11-10 Thread Jan Klemkow
On Sat, Nov 10, 2018 at 11:22:48AM +0100, Claudio Jeker wrote:
> On Fri, Nov 09, 2018 at 03:49:32PM -0700, Alexander Bluhm wrote:
> > On Fri, Nov 09, 2018 at 09:03:20PM +0100, Jan Klemkow wrote:
> > > On Fri, Nov 09, 2018 at 12:36:20PM -0700, Alexander Bluhm wrote:
> > > > On Fri, Nov 09, 2018 at 08:24:47PM +0100, Jan Klemkow wrote:
> > > > > Perfect, I also think its more intuitive to get a "permission denied"
> > > > > in case of a pf(4) block then a "Host is unreachable".  The diff below
> > > > > corrects kernel and extents the manpage for pf(4) blocks.
> > > > 
> > > > Don't forget divert_output() and rip_output().
> > > 
> > > You are right, I missed that.  Fix below.
> > 
> > code is OK bluhm@
> 
> Also OK claudio@
>  
> > > --- lib/libc/sys/send.2   5 Oct 2017 12:30:16 -   1.32
> > > +++ lib/libc/sys/send.2   9 Nov 2018 19:06:47 -
> > > @@ -162,7 +162,9 @@ The output queue for a network interface
> > >  This generally indicates that the interface has stopped sending,
> > >  but may be caused by transient congestion.
> > >  .It Bq Er EACCES
> > > -The
> > > +The connection was blocked by
> > > +.Xr pf 4 ,
> > > +or
> > >  .Dv SO_BROADCAST
> > >  option is not set on the socket, and a broadcast address
> > >  was given as the destination.
> > 
> > I have seen man pages that have multiple entries of the errno,
> > instead of the "or" for different reasons in the text.
> > 
> > +.It Bq Er EACCES
> > +The connection was blocked by
> > +.Xr pf 4 .
> >  .It Bq Er EACCES
> >  The
> >  .Dv SO_BROADCAST
> >  option is not set on the socket, and a broadcast address
> >  was given as the destination.
> > 
> > What is our style here?
> 
> This is something for jmc@ to decided. I'm happy with both versions.

Diff with fixed manpage from jmc.

Thanks,
Jan

Index: sys/netinet/ip_divert.c
===
RCS file: /cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.59
diff -u -p -r1.59 ip_divert.c
--- sys/netinet/ip_divert.c 4 Oct 2018 17:33:41 -   1.59
+++ sys/netinet/ip_divert.c 9 Nov 2018 19:48:25 -
@@ -157,8 +157,6 @@ divert_output(struct inpcb *inp, struct 
 
error = ip_output(m, NULL, >inp_route,
IP_ALLOWBROADCAST | IP_RAWOUTPUT, NULL, NULL, 0);
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
}
 
divstat_inc(divs_opackets);
Index: sys/netinet/raw_ip.c
===
RCS file: /cvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.114
diff -u -p -r1.114 raw_ip.c
--- sys/netinet/raw_ip.c4 Oct 2018 17:33:41 -   1.114
+++ sys/netinet/raw_ip.c9 Nov 2018 19:46:33 -
@@ -292,8 +292,6 @@ rip_output(struct mbuf *m, struct socket
 
error = ip_output(m, inp->inp_options, >inp_route, flags,
inp->inp_moptions, inp, 0);
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
return (error);
 }
 
Index: sys/netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.127
diff -u -p -r1.127 tcp_output.c
--- sys/netinet/tcp_output.c9 Nov 2018 14:14:31 -   1.127
+++ sys/netinet/tcp_output.c9 Nov 2018 18:53:02 -
@@ -1084,8 +1084,6 @@ out:
tcp_mtudisc(tp->t_inpcb, -1);
return (0);
}
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
if ((error == EHOSTUNREACH || error == ENETDOWN) &&
TCPS_HAVERCVDSYN(tp->t_state)) {
tp->t_softerror = error;
Index: sys/netinet/udp_usrreq.c
===
RCS file: /cvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.253
diff -u -p -r1.253 udp_usrreq.c
--- sys/netinet/udp_usrreq.c4 Oct 2018 17:33:41 -   1.253
+++ sys/netinet/udp_usrreq.c9 Nov 2018 18:52:08 -
@@ -1004,8 +1004,6 @@ udp_output(struct inpcb *inp, struct mbu
error = ip_output(m, inp->inp_options, >inp_route,
(inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
inp, ipsecflowinfo);
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
 
 bail:
m_fr

Re: diff: Fix send(2) EACCES mistake

2018-11-09 Thread Jan Klemkow
On Fri, Nov 09, 2018 at 12:36:20PM -0700, Alexander Bluhm wrote:
> On Fri, Nov 09, 2018 at 08:24:47PM +0100, Jan Klemkow wrote:
> > Perfect, I also think its more intuitive to get a "permission denied"
> > in case of a pf(4) block then a "Host is unreachable".  The diff below
> > corrects kernel and extents the manpage for pf(4) blocks.
> 
> Don't forget divert_output() and rip_output().

You are right, I missed that.  Fix below.

Thanks,
Jan

Index: sys/netinet/ip_divert.c
===
RCS file: /cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.59
diff -u -p -r1.59 ip_divert.c
--- sys/netinet/ip_divert.c 4 Oct 2018 17:33:41 -   1.59
+++ sys/netinet/ip_divert.c 9 Nov 2018 19:48:25 -
@@ -157,8 +157,6 @@ divert_output(struct inpcb *inp, struct 
 
error = ip_output(m, NULL, >inp_route,
IP_ALLOWBROADCAST | IP_RAWOUTPUT, NULL, NULL, 0);
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
}
 
divstat_inc(divs_opackets);
Index: sys/netinet/raw_ip.c
===
RCS file: /cvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.114
diff -u -p -r1.114 raw_ip.c
--- sys/netinet/raw_ip.c4 Oct 2018 17:33:41 -   1.114
+++ sys/netinet/raw_ip.c9 Nov 2018 19:46:33 -
@@ -292,8 +292,6 @@ rip_output(struct mbuf *m, struct socket
 
error = ip_output(m, inp->inp_options, >inp_route, flags,
inp->inp_moptions, inp, 0);
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
return (error);
 }
 
Index: sys/netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.127
diff -u -p -r1.127 tcp_output.c
--- sys/netinet/tcp_output.c9 Nov 2018 14:14:31 -   1.127
+++ sys/netinet/tcp_output.c9 Nov 2018 18:53:02 -
@@ -1084,8 +1084,6 @@ out:
tcp_mtudisc(tp->t_inpcb, -1);
return (0);
}
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
if ((error == EHOSTUNREACH || error == ENETDOWN) &&
TCPS_HAVERCVDSYN(tp->t_state)) {
tp->t_softerror = error;
Index: sys/netinet/udp_usrreq.c
===
RCS file: /cvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.253
diff -u -p -r1.253 udp_usrreq.c
--- sys/netinet/udp_usrreq.c4 Oct 2018 17:33:41 -   1.253
+++ sys/netinet/udp_usrreq.c9 Nov 2018 18:52:08 -
@@ -1004,8 +1004,6 @@ udp_output(struct inpcb *inp, struct mbu
error = ip_output(m, inp->inp_options, >inp_route,
(inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
inp, ipsecflowinfo);
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
 
 bail:
m_freem(control);
Index: lib/libc/sys/send.2
===
RCS file: /cvs/src/lib/libc/sys/send.2,v
retrieving revision 1.32
diff -u -p -r1.32 send.2
--- lib/libc/sys/send.2 5 Oct 2017 12:30:16 -   1.32
+++ lib/libc/sys/send.2 9 Nov 2018 19:06:47 -
@@ -162,7 +162,9 @@ The output queue for a network interface
 This generally indicates that the interface has stopped sending,
 but may be caused by transient congestion.
 .It Bq Er EACCES
-The
+The connection was blocked by
+.Xr pf 4 ,
+or
 .Dv SO_BROADCAST
 option is not set on the socket, and a broadcast address
 was given as the destination.



Re: diff: Fix send(2) EACCES mistake

2018-11-09 Thread Jan Klemkow
On Fri, Nov 09, 2018 at 06:57:16PM +0100, Claudio Jeker wrote:
> On Fri, Nov 09, 2018 at 06:09:34PM +0100, Jan Klemkow wrote:
> > I printed the code path below to make it easier to review the diff.
> > While I was following the code path again, I found an inconsistency
> > between udp_output() and upd6_output().  Just upd_output() turns EACCES
> > to EHOSTUNREACH, udp6_output does not.  The Diff below fixes udp6_output
> > and rounds up the sendto(2) manpage.
> > 
> > Reviewer guide from sendto(2) to EHOSTUNREACH:
> > 
> > sys_sendto() -> sendit() -> sosend() ---+
> > |
> >  +--+
> >  |
> >  +-> udp_usrreq() -> udp_output():
> >  |  ...
> >  |  error = ip_output(m, inp->inp_options, >inp_route,
> >  |  (inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
> >  |  inp, ipsecflowinfo);
> >  |  if (error == EACCES)/* translate pf(4) error for userland */
> >  |  error = EHOSTUNREACH;
> >  |  ...
> >  |
> >  +-> udp_usrreq() -> udp6_output():
> >  |  ...
> >  |  error = ip6_output(m, optp, >inp_route6,
> >  |  flags, in6p->inp_moptions6, in6p);
> >  |  if (error == EACCES)/* translate pf(4) error for userland */
> >  |  error = EHOSTUNREACH;
> >  |  ...
> >  |
> >  +-> tcp_usrreq() -> tcp_output():
> > ...
> > error = ip_output(m, tp->t_inpcb->inp_options,
> > tp->t_inpcb->inp_route,
> > ip_mtudisc ? IP_MTUDISC : 0), NULL, tp->t_inpcb, 0);
> > ...
> > error = ip6_output(m, tp->t_inpcb->inp_outputopts6,
> > >t_inpcb->inp_route6,
> > 0, NULL, tp->t_inpcb);
> > ...
> > if (error == EACCES)/* translate pf(4) error for userland */
> > error = EHOSTUNREACH;
> > ...
> > 
> 
> I really don't like this translation and therefor change of semantics of
> an old documented errno code.
> 
> If I remember correctly this was added because of the fear that EACCES was
> not properly handled when used with write(2) since it is not documented
> there but neither is EHOSTUNREACH.
> 
> I would prefer to remove this errno translation magic for pf(4) in the
> midlayer of the network code. As shown it is always prone for errors.

Hi Claudio,

Perfect, I also think its more intuitive to get a "permission denied"
in case of a pf(4) block then a "Host is unreachable".  The diff below
corrects kernel and extents the manpage for pf(4) blocks.

Thanks,
Jan

Index: sys/netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.127
diff -u -p -r1.127 tcp_output.c
--- sys/netinet/tcp_output.c9 Nov 2018 14:14:31 -   1.127
+++ sys/netinet/tcp_output.c9 Nov 2018 18:53:02 -
@@ -1084,8 +1084,6 @@ out:
tcp_mtudisc(tp->t_inpcb, -1);
return (0);
}
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
if ((error == EHOSTUNREACH || error == ENETDOWN) &&
TCPS_HAVERCVDSYN(tp->t_state)) {
tp->t_softerror = error;
Index: sys/netinet/udp_usrreq.c
===
RCS file: /cvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.253
diff -u -p -r1.253 udp_usrreq.c
--- sys/netinet/udp_usrreq.c4 Oct 2018 17:33:41 -   1.253
+++ sys/netinet/udp_usrreq.c9 Nov 2018 18:52:08 -
@@ -1004,8 +1004,6 @@ udp_output(struct inpcb *inp, struct mbu
error = ip_output(m, inp->inp_options, >inp_route,
(inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
inp, ipsecflowinfo);
-   if (error == EACCES)/* translate pf(4) error for userland */
-   error = EHOSTUNREACH;
 
 bail:
m_freem(control);
Index: lib/libc/sys//send.2
===
RCS file: /cvs/src/lib/libc/sys/send.2,v
retrieving revision 1.32
diff -u -p -r1.32 send.2
--- lib/libc/sys//send.25 Oct 2017 12:30:16 -   1.32
+++ lib/libc/sys//send.29 Nov 2018 19:06:47 -
@@ -162,7 +162,9 @@ The output queue for a network interface
 This generally indicates that the interface has stopped sending,
 but may be caused by transient congestion.
 .It Bq Er EACCES
-The
+The connection was blocked by
+.Xr pf 4 ,
+or
 .Dv SO_BROADCAST
 option is not set on the socket, and a broadcast address
 was given as the destination.



Re: diff: Fix send(2) EACCES mistake

2018-11-09 Thread Jan Klemkow
On Tue, Oct 30, 2018 at 07:13:24AM +, Jason McIntyre wrote:
> On Mon, Oct 29, 2018 at 11:55:52PM +0100, Jan Klemkow wrote:
> > On Sun, Oct 28, 2018 at 10:58:34PM +, Jason McIntyre wrote:
> > > On Sun, Oct 28, 2018 at 09:40:33PM +0100, Jan Klemkow wrote:
> > > > Unlike the manpage saids or one might think , sendto(2) sets errno to
> > > > EHOSTUNREACH instead of EACCES in cases of blocking by pf(4) or not
> > > > enabled broadcasts.  Finally I ran into both cases and think, its time
> > > > to fix this issue.  The diff suggests a new explanation that should
> > > > cover all error cases.
> > > > 
> > > > Index: /usr/src/lib/libc/sys/send.2
> > > > ===
> > > > RCS file: /cvs/src/lib/libc/sys/send.2,v
> > > > retrieving revision 1.32
> > > > diff -u -p -r1.32 send.2
> > > > --- /usr/src/lib/libc/sys/send.25 Oct 2017 12:30:16 -   
> > > > 1.32
> > > > +++ /usr/src/lib/libc/sys/send.228 Oct 2018 20:16:20 -
> > > > @@ -161,13 +161,13 @@ The operation may succeed when buffers b
> > > >  The output queue for a network interface was full.
> > > >  This generally indicates that the interface has stopped sending,
> > > >  but may be caused by transient congestion.
> > > > -.It Bq Er EACCES
> > > > -The
> > > > -.Dv SO_BROADCAST
> > > > -option is not set on the socket, and a broadcast address
> > > > -was given as the destination.
> > > >  .It Bq Er EHOSTUNREACH
> > > > -The destination address specified an unreachable host.
> > > > +The destination address specified an host that is unreachable,
> > > 
> > > unless you're going for humour, "a host" rather than "an host".
> > > 
> > > i can;t comment on the accuracy, but the rest of the diff reads ok.
> > 
> > No humour (here in Germany), just a spelling mistakes :-)
> > Fixed version below.
> 
> morning.
> 
> to be fair, some people do still unambiguously use "an" before h* words.
> so as such it is not wrong (i think). still, our pages do not use that format.
> 
> anyway, enough of the small stuff. who wants to review this page and
> actually ok or nok it?

Hi,

I printed the code path below to make it easier to review the diff.
While I was following the code path again, I found an inconsistency
between udp_output() and upd6_output().  Just upd_output() turns EACCES
to EHOSTUNREACH, udp6_output does not.  The Diff below fixes udp6_output
and rounds up the sendto(2) manpage.

Bye,
Jan

Reviewer guide from sendto(2) to EHOSTUNREACH:

sys_sendto() -> sendit() -> sosend() ---+
|
 +--+
 |
 +-> udp_usrreq() -> udp_output():
 |  ...
 |  error = ip_output(m, inp->inp_options, >inp_route,
 |  (inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
 |  inp, ipsecflowinfo);
 |  if (error == EACCES)/* translate pf(4) error for userland */
 |  error = EHOSTUNREACH;
 |  ...
 |
 +-> udp_usrreq() -> udp6_output():
 |  ...
 |  error = ip6_output(m, optp, >inp_route6,
 |  flags, in6p->inp_moptions6, in6p);
 |  if (error == EACCES)/* translate pf(4) error for userland */
 |  error = EHOSTUNREACH;
 |  ...
 |
 +-> tcp_usrreq() -> tcp_output():
...
error = ip_output(m, tp->t_inpcb->inp_options,
tp->t_inpcb->inp_route,
ip_mtudisc ? IP_MTUDISC : 0), NULL, tp->t_inpcb, 0);
...
error = ip6_output(m, tp->t_inpcb->inp_outputopts6,
>t_inpcb->inp_route6,
0, NULL, tp->t_inpcb);
...
if (error == EACCES)/* translate pf(4) error for userland */
error = EHOSTUNREACH;
...

Index: sys/netinet6/udp6_output.c
===
RCS file: /cvs/src/sys/netinet6/udp6_output.c,v
retrieving revision 1.56
diff -u -p -r1.56 udp6_output.c
--- sys/netinet6/udp6_output.c  13 Sep 2018 19:53:58 -  1.56
+++ sys/netinet6/udp6_output.c  9 Nov 2018 16:31:21 -
@@ -235,6 +235,8 @@ udp6_output(struct inpcb *in6p, struct m
 
error = ip6_output(m, optp, >inp_route6,
flags, in6p->inp_moptions6, in6p);
+   if (error == EACCES)/* translate pf(4) error for userland */
+   error = EHOSTUNREACH;
goto releaseopt;
 
 release:
Index: /usr/src/lib/libc/sys/send.2
=

Re: diff: Fix send(2) EACCES mistake

2018-10-29 Thread Jan Klemkow
On Sun, Oct 28, 2018 at 10:58:34PM +, Jason McIntyre wrote:
> On Sun, Oct 28, 2018 at 09:40:33PM +0100, Jan Klemkow wrote:
> > Unlike the manpage saids or one might think , sendto(2) sets errno to
> > EHOSTUNREACH instead of EACCES in cases of blocking by pf(4) or not
> > enabled broadcasts.  Finally I ran into both cases and think, its time
> > to fix this issue.  The diff suggests a new explanation that should
> > cover all error cases.
> > 
> > Index: /usr/src/lib/libc/sys/send.2
> > ===
> > RCS file: /cvs/src/lib/libc/sys/send.2,v
> > retrieving revision 1.32
> > diff -u -p -r1.32 send.2
> > --- /usr/src/lib/libc/sys/send.25 Oct 2017 12:30:16 -   1.32
> > +++ /usr/src/lib/libc/sys/send.228 Oct 2018 20:16:20 -
> > @@ -161,13 +161,13 @@ The operation may succeed when buffers b
> >  The output queue for a network interface was full.
> >  This generally indicates that the interface has stopped sending,
> >  but may be caused by transient congestion.
> > -.It Bq Er EACCES
> > -The
> > -.Dv SO_BROADCAST
> > -option is not set on the socket, and a broadcast address
> > -was given as the destination.
> >  .It Bq Er EHOSTUNREACH
> > -The destination address specified an unreachable host.
> > +The destination address specified an host that is unreachable,
> 
> unless you're going for humour, "a host" rather than "an host".
> 
> i can;t comment on the accuracy, but the rest of the diff reads ok.

No humour (here in Germany), just a spelling mistakes :-)
Fixed version below.

Thanks,
Jan

Index: /usr/src/lib/libc/sys/send.2
===
RCS file: /cvs/src/lib/libc/sys/send.2,v
retrieving revision 1.32
diff -u -p -r1.32 send.2
--- /usr/src/lib/libc/sys/send.25 Oct 2017 12:30:16 -   1.32
+++ /usr/src/lib/libc/sys/send.229 Oct 2018 22:48:24 -
@@ -161,13 +161,13 @@ The operation may succeed when buffers b
 The output queue for a network interface was full.
 This generally indicates that the interface has stopped sending,
 but may be caused by transient congestion.
-.It Bq Er EACCES
-The
-.Dv SO_BROADCAST
-option is not set on the socket, and a broadcast address
-was given as the destination.
 .It Bq Er EHOSTUNREACH
-The destination address specified an unreachable host.
+The destination address specified a host that is unreachable,
+blocked by
+.Xr pf 4
+or is broadcast communication which was not enabled
+via the socket option 
+.Dv SO_BROADCAST .
 .It Bq Er EINVAL
 The
 .Fa flags



diff: Fix send(2) EACCES mistake

2018-10-28 Thread Jan Klemkow
Hi,

Unlike the manpage saids or one might think , sendto(2) sets errno to
EHOSTUNREACH instead of EACCES in cases of blocking by pf(4) or not
enabled broadcasts.  Finally I ran into both cases and think, its time
to fix this issue.  The diff suggests a new explanation that should
cover all error cases.

Bye,
Jan

Index: /usr/src/lib/libc/sys/send.2
===
RCS file: /cvs/src/lib/libc/sys/send.2,v
retrieving revision 1.32
diff -u -p -r1.32 send.2
--- /usr/src/lib/libc/sys/send.25 Oct 2017 12:30:16 -   1.32
+++ /usr/src/lib/libc/sys/send.228 Oct 2018 20:16:20 -
@@ -161,13 +161,13 @@ The operation may succeed when buffers b
 The output queue for a network interface was full.
 This generally indicates that the interface has stopped sending,
 but may be caused by transient congestion.
-.It Bq Er EACCES
-The
-.Dv SO_BROADCAST
-option is not set on the socket, and a broadcast address
-was given as the destination.
 .It Bq Er EHOSTUNREACH
-The destination address specified an unreachable host.
+The destination address specified an host that is unreachable,
+blocked by
+.Xr pf 4
+or is broadcast communication which was not enabled
+via the socket option 
+.Dv SO_BROADCAST .
 .It Bq Er EINVAL
 The
 .Fa flags



Re: inteldrm(4): uvm write-combining support

2018-10-28 Thread Jan Klemkow
On Sat, Oct 27, 2018 at 12:31:48PM +0200, Mark Kettenis wrote:
> > Date: Sat, 27 Oct 2018 17:16:57 +1100
> > From: Jonathan Gray 
> > 
> > On Fri, Oct 26, 2018 at 09:47:51PM +0200, Mark Kettenis wrote:
> > > Diff below adds support to uvm to create wtite-combining mappings and
> > > uses this to implement support for the I915_MMAP_WC flag in
> > > inteldrm(4).  With this diff I can re-enable support for the
> > > I915_PARAM_MMAP_VERSION.
> > > 
> > > Please test.
> > 
> > Defining PMAP_WC like that in uvm headers will make
> > pgprot_writecombine() in dev/pci/drm/drm_linux.h take the wrong path
> > on archs without PMAP_WC.
> > 
> > static inline pgprot_t
> > pgprot_writecombine(pgprot_t prot)
> > {
> > #ifdef PMAP_WC
> > return prot | PMAP_WC;
> > #else
> > return prot | PMAP_NOCACHE;
> > #endif
> > }
> > 
> > Should it instead be #if defined(PMAP_WC) && PMAP_WC > 0
> > or just #if PMAP_WC > 0 here?
> 
> Good catch.  Maybe at some point we should revisit the naming of these
> flags and make them more uniform across architectures.  Write-combing
> is a bit of an x86-specific thing, but other architectures have
> similar concepts.
> 
> I went with #if PMAP_WC != 0 and did the same for PMAP_DEVICE.

Works for me, so far.  But, I don't know how to test, or if its relevant
for my hardware?!  Are there aeny edge cases I can test?

Bye,
Jan

OpenBSD 6.4-current (GENERIC.MP) #25: Sun Oct 28 15:41:05 CET 2018
you...@fabien.klemkow.net:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8451149824 (8059MB)
avail mem = 8185753600 (7806MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xca63b000 (63 entries)
bios0: vendor LENOVO version "N23ET55W (1.30 )" date 08/31/2018
bios0: LENOVO 20KHS08H00
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT 
SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 POAT DMAR NHLT 
ASF! FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1397.33 MHz, 06-8e-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1148.48 MHz, 06-8e-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1097.44 MHz, 06-8e-09
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1097.44 MHz, 06-8e-09
cpu3: 

Re: Add acpipci(4) on amd64

2018-10-23 Thread Jan Klemkow
Hi Mark,

On Tue, Oct 23, 2018 at 07:32:16PM +0200, Mark Kettenis wrote:
> > Date: Tue, 23 Oct 2018 18:40:42 +0200
> > From: Jan Klemkow 
> > On Mon, Oct 22, 2018 at 09:45:06PM +0200, Mark Kettenis wrote:
> > > Diff below adds an acpipci(4) driver on amd64.  For now the main
> > > purpose of this driver is to make the PCI-specific _OSC calls to
> > > advertise the functionality we support.  Most notably this advertises
> > > support for PCIE native hotplug as we have some indications that this
> > > will help Thunderbolt 3 support on some machines.
> > > 
> > > I'd like to see this tested on a wide range of amd64 hardware, but
> > > especially on laptops.  Please reply with a diff of your dmesg before
> > > and after.  Make sure you run make config before building a new kernel.
> > 
> > Tested with ThinkPad X1 Carbon 6th Gen under OpenBSD/amd64-current.  It
> > is tested with Thunderbold 3 enabled in BIOS.
> 
> Bingo!
> 
> Just to be sure, both dmesg's were made with the same BIOS
> configuration and no devices connected to Thunderbolt 3 at boot?

Yes, same BIOS option and no devices attached for both dmesgs .  But, I
have changed the BIOS option them.  When "Thunderbolt 3" is enabled and
the machine resumes from suspend (S3), than the acpi0 kernel thread
takes 80-90% CPU usage till reboot.

Tomorrow, I will see if could get a thunderbolt device for testing.

FYI, with "Thunderbolt 3" disabled the dmesg looks like the ThinkPad X1
Carbon 5th Gen. dmesgs from the other testers.

See below for a full dmesg listing with your diff and "Thunderbolt 3"
enabled.

Thanks,
Jan

--- dmesg.boot_before_hack  Tue Oct 23 15:24:35 2018
+++ dmesg.boot_after_hack   Tue Oct 23 15:24:58 2018
@@ -1,4 +1,4 @@
-OpenBSD 6.4-current (GENERIC.MP) #22: Tue Oct 23 15:04:51 CEST 2018
+OpenBSD 6.4-current (GENERIC.MP) #23: Tue Oct 23 15:16:49 CEST 2018
 you...@fabien.klemkow.net:/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8451149824 (8059MB)
 avail mem = 8185741312 (7806MB)
@@ -24,7 +24,7 @@
 cpu0: apic clock running at 24MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
 cpu1 at mainbus0: apid 2 (application processor)
-cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1155.00 MHz, 06-8e-09
+cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1156.38 MHz, 06-8e-09
 cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 1, package 0
@@ -73,6 +73,7 @@
 acpicpu3 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
 acpipwrres0 at acpi0: PUBS, resource for XHC_
 acpitz0 at acpi0: critical temperature is 128 degC
+acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
 acpithinkpad0 at acpi0
 acpiac0 at acpi0: AC unit online
 acpibat0 at acpi0: BAT0 model "01AV430" serial   585 type LiP oem "SMP"


Full dmegs listing:


OpenBSD 6.4-current (GENERIC.MP) #23: Tue Oct 23 15:16:49 CEST 2018
you...@fabien.klemkow.net:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8451149824 (8059MB)
avail mem = 8185741312 (7806MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xca63b000 (63 entries)
bios0: vendor LENOVO version "N23ET55W (1.30 )" date 08/31/2018
bios0: LENOVO 20KHS08H00
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT 
SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 POAT DMAR NHLT 
ASF! FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1397.33 MHz, 06-8e-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XS

Re: Add acpipci(4) on amd64

2018-10-23 Thread Jan Klemkow
Hi Mark,

On Mon, Oct 22, 2018 at 09:45:06PM +0200, Mark Kettenis wrote:
> Diff below adds an acpipci(4) driver on amd64.  For now the main
> purpose of this driver is to make the PCI-specific _OSC calls to
> advertise the functionality we support.  Most notably this advertises
> support for PCIE native hotplug as we have some indications that this
> will help Thunderbolt 3 support on some machines.
> 
> I'd like to see this tested on a wide range of amd64 hardware, but
> especially on laptops.  Please reply with a diff of your dmesg before
> and after.  Make sure you run make config before building a new kernel.

Tested with ThinkPad X1 Carbon 6th Gen under OpenBSD/amd64-current.  It
is tested with Thunderbold 3 enabled in BIOS.

Bye,
Jan

--- dmesg.boot_before_nohackTue Oct 23 18:00:39 2018
+++ dmesg.boot_after_nohack Tue Oct 23 16:43:35 2018
@@ -1,7 +1,7 @@
-OpenBSD 6.4-current (GENERIC.MP) #22: Tue Oct 23 15:04:51 CEST 2018
+OpenBSD 6.4-current (GENERIC.MP) #23: Tue Oct 23 15:16:49 CEST 2018
 you...@fabien.klemkow.net:/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8451149824 (8059MB)
-avail mem = 8185745408 (7806MB)
+avail mem = 8185741312 (7806MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
@@ -16,7 +16,7 @@
 acpihpet0 at acpi0: 2399 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
-cpu0: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1394.63 MHz, 06-8e-09
+cpu0: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1397.33 MHz, 06-8e-09
 cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
@@ -24,7 +24,7 @@
 cpu0: apic clock running at 23MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
 cpu1 at mainbus0: apid 2 (application processor)
-cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1158.97 MHz, 06-8e-09
+cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1144.60 MHz, 06-8e-09
 cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 1, package 0
@@ -74,6 +74,7 @@
 acpipwrres0 at acpi0: PUBS, resource for XHC_
 acpipwrres1 at acpi0: PXP_, resource for RP09
 acpitz0 at acpi0: critical temperature is 128 degC
+acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
 acpithinkpad0 at acpi0
 acpiac0 at acpi0: AC unit online
 acpibat0 at acpi0: BAT0 model "01AV430" serial   585 type LiP oem "SMP"
@@ -91,7 +92,7 @@
 "USBC000" at acpi0 not configured
 acpivideo0 at acpi0: GFX0
 acpivout at acpivideo0 not configured
-cpu0: Enhanced SpeedStep 1394 MHz: speeds: 2601, 2600, 2500, 2400, 2200, 2000, 
1900, 1700, 1500, 1400, 1200, 1100, 800, 700, 600, 400 MHz
+cpu0: Enhanced SpeedStep 1397 MHz: speeds: 2601, 2600, 2500, 2400, 2200, 2000, 
1900, 1700, 1500, 1400, 1200, 1100, 800, 700, 600, 400 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 "Intel Core 7G Host" rev 0x02
 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 620" rev 0x02
@@ -122,6 +123,20 @@
 sd0: 244198MB, 512 bytes/sector, 500118192 sectors
 ppb2 at pci0 dev 29 function 0 "Intel 100 Series PCIE" rev 0xf1: msi
 pci3 at ppb2 bus 5
+ppb3 at pci3 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02
+pci4 at ppb3 bus 6
+ppb4 at pci4 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi
+pci5 at ppb4 bus 7
+"Intel JHL6540 Thunderbolt" rev 0x02 at pci5 dev 0 function 0 not configured
+ppb5 at pci4 dev 1 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi
+pci6 at ppb5 bus 8
+ppb6 at pci4 dev 2 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi
+pci7 at ppb6 bus 59
+xhci1 at pci7 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi, xHCI 
1.16
+usb1 at xhci1: USB revision 3.0
+uhub1 at usb1 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
+ppb7 at pci4 dev 4 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi
+pci8 at ppb7 bus 60
 pcib0 at pci0 dev 31 function 0 "Intel 200 Series LPC" rev 0x21
 "Intel 100 Series PMC" rev 0x21 at pci0 dev 31 function 2 not configured
 azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 

diff: ndp(8): hostname lookup via /etc/ethers

2018-10-22 Thread Jan Klemkow
Hi,

The following diff adds the option -e to ndp(8), which resolved printed
hostnames via /etc/ethers.  You are able to recognise hosts with IPv6
auto privacy extension addresses on local IPv6 routers.  Also hosts
inside of a yp(8) domain are able to lookup their neighbors via the
shared /etc/ethers database.  (Yes, I run a yp domain :-)

This helps me, to keep track of known and unknown IPv6 hosts in my
network.

The ndp(8) implementations of FreeBSD, NetBSD and Linux don't have an
option named -e or a feature like this.  Thus, there shouldn't be any
problem or misbehavior by existing scripts around ndp(8) with this new
option.

What's your opinion about this feature?

Bye,
Jan

Index: ndp.8
===
RCS file: /cvs/src/usr.sbin/ndp/ndp.8,v
retrieving revision 1.45
diff -u -p -r1.45 ndp.8
--- ndp.8   9 Aug 2017 14:36:00 -   1.45
+++ ndp.8   22 Oct 2018 21:32:46 -
@@ -36,7 +36,7 @@
 .Nd control/diagnose IPv6 Neighbor Discovery Protocol (NDP)
 .Sh SYNOPSIS
 .Nm ndp
-.Op Fl acnt
+.Op Fl acent
 .Op Fl A Ar wait
 .Op Fl d Ar hostname
 .Op Fl f Ar filename
@@ -112,6 +112,12 @@ the node has sent during the current sta
 Erase all the NDP entries.
 .It Fl d Ar hostname
 Delete the specified NDP entry.
+.It Fl e
+Use the mappings of ethernet addresses in
+.Pa /etc/ethers
+to resolve hostnames.
+This is useful to resolve hostnames of privacy externsion addresses on local
+routers.
 .It Fl f Ar filename
 Parse entries from
 .Ar file
Index: ndp.c
===
RCS file: /cvs/src/usr.sbin/ndp/ndp.c,v
retrieving revision 1.90
diff -u -p -r1.90 ndp.c
--- ndp.c   13 Jul 2018 09:03:44 -  1.90
+++ ndp.c   22 Oct 2018 21:38:54 -
@@ -86,6 +86,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -110,6 +111,7 @@
((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long))
 
 static pid_t pid;
+static int eflag;
 static int nflag;
 static int tflag;
 static int32_t thiszone;   /* time difference with gmt */
@@ -148,7 +150,7 @@ main(int argc, char *argv[])
pid = getpid();
thiszone = gmt2local(0);
rdomain = getrtable();
-   while ((ch = getopt(argc, argv, "acd:f:i:nstA:V:")) != -1) {
+   while ((ch = getopt(argc, argv, "acd:ef:i:nstA:V:")) != -1) {
switch (ch) {
case 'a':
case 'c':
@@ -173,6 +175,9 @@ main(int argc, char *argv[])
mode = ch;
arg = optarg;
break;
+   case 'e':
+   eflag = 1;
+   break;
case 'n':
nflag = 1;
break;
@@ -612,6 +617,17 @@ again:;
delete(host_buf);
continue;
}
+
+   if (eflag && sdl->sdl_alen) {
+   u_char *cp = (u_char *)LLADDR(sdl);
+   struct ether_addr eaddr;
+   char nhost[NI_MAXHOST];
+
+   memcpy(eaddr.ether_addr_octet, cp, ETHER_ADDR_LEN);
+   if (ether_ntohost(nhost, ) == 0)
+   strlcpy(host_buf, nhost, sizeof(host_buf));
+   }
+
gettimeofday(, 0);
if (tflag)
ts_print();
@@ -753,7 +769,7 @@ ndp_ether_aton(char *a, u_char *n)
 void
 usage(void)
 {
-   printf("usage: ndp [-acnt] ");
+   printf("usage: ndp [-acent] ");
printf("[-A wait] [-d hostname] [-f filename] [-i interface]\n");
printf("\t[-s nodename ether_addr [temp] [proxy]] ");
printf("[-V rdomain] [hostname]\n");



fix: unveil(2) error handling

2018-08-30 Thread Jan Klemkow
Hi,

I found a little bug in the unveil(2) error handling.  After blocking
unveil(2) by unveil(NULL, NULL), an additional unveil(2) call sets errno
to EINVAL instead of EPERM as the manpage saids:

EPERM   An attempt to increase permissions was made, or the
path was not accessible, or unveil was called after
locking.

bye,
Jan

Index: kern/vfs_syscalls.c
===
RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.304
diff -u -p -r1.304 vfs_syscalls.c
--- kern/vfs_syscalls.c 20 Aug 2018 16:00:22 -  1.304
+++ kern/vfs_syscalls.c 30 Aug 2018 20:04:48 -
@@ -899,7 +899,7 @@ sys_unveil(struct proc *p, void *v, regi
}
 
if (p->p_p->ps_uvdone != 0)
-   return EINVAL;
+   return EPERM;
 
error = copyinstr(SCARG(uap, permissions), permissions,
sizeof(permissions), NULL);



diff: add USB ANT-m Stick via uscom(4)

2018-08-09 Thread Jan Klemkow
Hi,

the following diff adds support for an USB ANT+ receiver which is used
to communicate with wireless fitness tracking devices.  The USB device
appears as a serial interface.  I just add the device ID to the existing
uscom(4) driver and enabled it in GENERIC.  I don't know why it was
deactivated.  But, I tested the uscom(4) driver with my ANT device
with OpenBSD-current on amd64, i386, macppc and sparc64.

The device attache with this message:

uscom0 at uhub0 port 1 configuration 1 interface 0 "Dynastream Innovations ANT 
USB-m Stick" rev 2.00/1.00 addr 2
ucom0 at uscom0 portno 0

It works well on every tested architecture.  I got a valid binary error
message from the ANT device by the following test command:

# cu -l /dev/cuaU0 | od -h
... a4 01 ae 00 0b ...

Did I test enough to enable this driver by default in GENERIC?
Or did I miss something else?

bye,
Jan

Index: share/man/man4/uscom.4
===
RCS file: /cvs/src/share/man/man4/uscom.4,v
retrieving revision 1.2
diff -u -p -r1.2 uscom.4
--- share/man/man4/uscom.4  25 Mar 2014 07:10:34 -  1.2
+++ share/man/man4/uscom.4  9 Aug 2018 18:24:50 -
@@ -34,6 +34,7 @@ driver:
 .Bd -literal -offset indent
 HP 39G
 HP 49G
+Dynastream ANT USB-m Stick
 .Ed
 .Sh SEE ALSO
 .Xr tty 4 ,
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.457
diff -u -p -r1.457 GENERIC
--- sys/arch/amd64/conf/GENERIC 3 Aug 2018 01:50:14 -   1.457
+++ sys/arch/amd64/conf/GENERIC 9 Aug 2018 18:22:33 -
@@ -230,6 +230,8 @@ umct*   at uhub?# MCT USB-RS232 serial a
 ucom*  at umct?
 uslcom*at uhub?# Silicon Laboratories CP210x serial
 ucom*  at uslcom?
+uscom* at uhub?# Simple USB serial adapters
+ucom*  at uscom?
 uark*  at uhub?# Arkmicro ARK3116 serial
 ucom*  at uark?
 moscom*at uhub?# MosChip MCS7703 serial
Index: sys/arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.833
diff -u -p -r1.833 GENERIC
--- sys/arch/i386/conf/GENERIC  3 Aug 2018 01:50:14 -   1.833
+++ sys/arch/i386/conf/GENERIC  9 Aug 2018 18:22:33 -
@@ -246,6 +246,8 @@ umct*   at uhub?# MCT USB-RS232 serial a
 ucom*  at umct?
 uslcom*at uhub?# Silicon Laboratories CP210x serial
 ucom*  at uslcom?
+uscom* at uhub?# Simple USB serial adapters
+ucom*  at uscom?
 uark*  at uhub?# Arkmicro ARK3116 serial
 ucom*  at uark?
 moscom*at uhub?# MosChip MCS7703 serial
Index: sys/arch/macppc/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/macppc/conf/GENERIC,v
retrieving revision 1.264
diff -u -p -r1.264 GENERIC
--- sys/arch/macppc/conf/GENERIC14 Feb 2018 23:51:49 -  1.264
+++ sys/arch/macppc/conf/GENERIC9 Aug 2018 18:22:33 -
@@ -223,6 +223,8 @@ umct*   at uhub?# MCT USB-RS232 serial a
 ucom*  at umct?
 uslcom*at uhub?# Silicon Laboratories CP210x serial
 ucom*  at uslcom?
+uscom* at uhub?# Simple USB serial adapters
+ucom*  at uscom?
 uark*  at uhub?# Arkmicro ARK3116 serial
 ucom*  at uark?
 moscom*at uhub?# MosChip MCS7703 serial
Index: sys/arch/sparc64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/sparc64/conf/GENERIC,v
retrieving revision 1.307
diff -u -p -r1.307 GENERIC
--- sys/arch/sparc64/conf/GENERIC   28 Aug 2017 19:32:53 -  1.307
+++ sys/arch/sparc64/conf/GENERIC   9 Aug 2018 18:22:33 -
@@ -193,6 +193,8 @@ umct*   at uhub?# MCT USB-RS232 serial a
 ucom*  at umct?
 uslcom*at uhub?# Silicon Laboratories CP210x serial
 ucom*  at uslcom?
+uscom* at uhub?# Simple USB serial adapters
+ucom*  at uscom?
 uark*  at uhub?# Arkmicro ARK3116 serial
 ucom*  at uark?
 uipaq* at uhub?# iPAQ serial adapter
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.690
diff -u -p -r1.690 usbdevs
--- sys/dev/usb/usbdevs 19 Jul 2018 17:33:26 -  1.690
+++ sys/dev/usb/usbdevs 9 Aug 2018 18:22:33 -
@@ -1638,6 +1638,7 @@ product DVICO RT3070  0xb307  RT3070
 product DYNASTREAM ANTDEVBOARD 0x1003  ANT dev board
 product DYNASTREAM ANT2USB 0x1004  ANT2USB
 product DYNASTREAM ANTDEVBOARD20x1006  ANT dev board
+product DYNASTREAM ANTUSBM 0x1009  ANTUSB-m Stick
 
 /* EasyDisk products */
 product EASYDISK EASYDISK  0x0005  

Re: diff: add if group table to snmpd

2018-05-18 Thread Jan Klemkow
On Mon, May 14, 2018 at 09:21:13PM +0200, Jan Klemkow wrote:
> On Mon, May 14, 2018 at 06:53:20PM +0100, Stuart Henderson wrote:
> > On 2018/05/14 17:59, Jan Klemkow wrote:
> > > The following diff adds an interface group table to the OpenBSD MIBs and
> > > the OpenSNMPd.  The new snmp table helps to keep track of the demote
> > > values of more complex carp setups.  To iterate directly through all
> > > interface groups, the diff has to extent ioctl interface by a new
> > > command SIOCGIFGLIST.
> > > 
> > > This new interface could also be used to extent ifconfig(8), in a later
> > > diff, to list all interface groups with there demote counter.
> > > 
> > > I tested this diff with snmpctl(8) from base and snmpwalk from
> > > net/net-snmp under current amd64.
> 
> > This seems a reasonable thing to report on and I didn't spot any code
> > problems yet, one thing with the MIB file though:
> 
> > > Index: share/snmp/OPENBSD-CARP-MIB.txt
> > > ===
> > > RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
> > > retrieving revision 1.3
> > > diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
> > > --- share/snmp/OPENBSD-CARP-MIB.txt   28 Sep 2012 09:21:48 -  
> > > 1.3
> > > +++ share/snmp/OPENBSD-CARP-MIB.txt   14 May 2018 14:53:02 -
> > > @@ -41,7 +41,7 @@ carpMIBObjects MODULE-IDENTITY
> > >   "
> > >  DESCRIPTION  "The MIB module for gathering information about
> > >Common Address Redundancy Protocol (CARP) interfaces."
> > > -REVISION "20120131Z"
> > > +REVISION "20180514Z"
> > >  DESCRIPTION  "Add the OPENBSD-CARP-MIB to snmpd."
> > >  ::= { openBSD 6 }
> > 
> > This section is meant to be a sort of changelog; please add a new
> > REVISION/DESCRIPTION rather than changing the existing one. (Also check
> > that smilint is happy).
> 
> Thanks for the hint.  I fixed the changelog and some other issues
> pointed by smilint.

This is the merged version of the diff:

Thanks,
Jan

Index: share/snmp/OPENBSD-CARP-MIB.txt
===
RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
retrieving revision 1.3
diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
--- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 -  1.3
+++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 18:58:59 -
@@ -32,7 +32,7 @@ IMPORTS
FROM SNMPv2-CONF;
 
 carpMIBObjects MODULE-IDENTITY
-LAST-UPDATED "20120131Z"
+LAST-UPDATED "20180514Z"
 ORGANIZATION "OpenBSD"
 CONTACT-INFO "
   Author: Joel Knight
@@ -41,6 +41,8 @@ carpMIBObjects MODULE-IDENTITY
  "
 DESCRIPTION  "The MIB module for gathering information about
 Common Address Redundancy Protocol (CARP) interfaces."
+REVISION "20180514Z"
+DESCRIPTION  "Add the carpGroupTable to OPENBSD-CARP-MIB."
 REVISION "20120131Z"
 DESCRIPTION  "Add the OPENBSD-CARP-MIB to snmpd."
 ::= { openBSD 6 }
@@ -174,6 +176,58 @@ carpIfState OBJECT-TYPE
DESCRIPTION
"Indicates the operational state of the CARP interface."
::= { carpIfEntry 7 }
+
+
+-- carpGroup
+
+carpGroupTable OBJECT-TYPE
+   SYNTAX  SEQUENCE OF CarpGroupEntry
+   MAX-ACCESS  not-accessible
+   STATUS  current
+   DESCRIPTION
+   "A list of interface groups."
+   ::= { carpMIBObjects 4 }
+
+carpGroupEntry OBJECT-TYPE
+   SYNTAX  CarpGroupEntry
+   MAX-ACCESS  not-accessible
+   STATUS  current
+   DESCRIPTION
+   "An entry containing management information applicable to a
+   particular interface group."
+   INDEX   { carpGroupIndex }
+   ::= { carpGroupTable 1 }
+
+CarpGroupEntry ::=
+   SEQUENCE {
+   carpGroupIndex  Integer32,
+   carpGroupName   OCTET STRING,
+   carpGroupDemote Integer32
+   }
+
+carpGroupIndex OBJECT-TYPE
+   SYNTAX  Integer32 (1..2147483647)
+   MAX-ACCESS  not-accessible
+   STATUS  current
+   DESCRIPTION
+   "The demote value of the interface group."
+   ::= { carpGroupEntry 1 }
+
+carpGroupName OBJECT-TYPE
+   SYNTAX  OCTET STRING
+   MAX-ACCESS  read-only
+   STATUS  current
+   DESCRIPTION
+   "The name of the interface group."
+   ::= { carpGroupEntry 2 }
+
+c

Re: [patch] httpd: add tls client certificate authentication

2018-05-16 Thread Jan Klemkow
Hi Jack,

On Wed, May 16, 2018 at 05:32:56PM +0930, Jack Burton wrote:
> I figured that if we can agree on this much, so httpd can be used for
> the authentication-only case (which is all non-fastcgi sites would want)
> straight away, that's be a good first step -- then we can come back and
> argue the toss over how much client cert data is necessary/sufficient
> to pass through for authorisation/accounting purposes.

I agree with you.  Lets commit this first step.

I tested your diff on current amd64 and sparc64 with an own PKI [1] and
the firefox browser.  Every thing works for me.  I also looked down your
source code which also seams fine to me.

I tested the optional and non-optional "client ca" configuration, as
well as the revocation and the fastcgi environment feature on both
architectures.  Everything works so far.

Hopefully, it will committed this time! :-)

Thanks!
Jan

[1]: https://github.com/younix/ca

> There's also a trivial regression test (unchanged from last year), which
> I'll post again separately next.
> 
> 
> Index: config.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/config.c,v
> retrieving revision 1.53
> diff -u -p -r1.53 config.c
> --- config.c  19 Jul 2017 17:36:25 -  1.53
> +++ config.c  16 May 2018 07:59:10 -
> @@ -304,10 +304,18 @@ config_setserver_tls(struct httpd *env, 
>  
>   log_debug("%s: configuring tls for %s", __func__, srv_conf->name);
>  
> + if (config_settls(env, srv, TLS_CFG_CA, "ca", srv_conf->tls_ca,
> + srv_conf->tls_ca_len) != 0)
> + return (-1);
> +
>   if (config_settls(env, srv, TLS_CFG_CERT, "cert", srv_conf->tls_cert,
>   srv_conf->tls_cert_len) != 0)
>   return (-1);
>  
> + if (config_settls(env, srv, TLS_CFG_CRL, "crl", srv_conf->tls_crl,
> + srv_conf->tls_crl_len) != 0)
> + return (-1);
> +
>   if (config_settls(env, srv, TLS_CFG_KEY, "key", srv_conf->tls_key,
>   srv_conf->tls_key_len) != 0)
>   return (-1);
> @@ -431,6 +439,7 @@ config_getserver_config(struct httpd *en
>  
>   f = SRVFLAG_TLS;
>   srv_conf->flags |= parent->flags & f;
> + srv_conf->tls_flags = parent->tls_flags;
>  
>   f = SRVFLAG_ACCESS_LOG;
>   if ((srv_conf->flags & f) == 0) {
> @@ -655,9 +664,21 @@ config_getserver_tls(struct httpd *env, 
>   }
>  
>   switch (tls_conf.tls_type) {
> + case TLS_CFG_CA:
> + if (config_gettls(env, srv_conf, _conf, "ca", p, len,
> + _conf->tls_ca, _conf->tls_ca_len) != 0)
> + goto fail;
> + break;
> +
>   case TLS_CFG_CERT:
>   if (config_gettls(env, srv_conf, _conf, "cert", p, len,
>   _conf->tls_cert, _conf->tls_cert_len) != 0)
> + goto fail;
> + break;
> +
> + case TLS_CFG_CRL:
> + if (config_gettls(env, srv_conf, _conf, "crl", p, len,
> + _conf->tls_crl, _conf->tls_crl_len) != 0)
>   goto fail;
>   break;
>  
> Index: httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.90
> diff -u -p -r1.90 httpd.conf.5
> --- httpd.conf.5  11 Apr 2018 15:50:46 -  1.90
> +++ httpd.conf.5  16 May 2018 07:59:10 -
> @@ -342,6 +342,10 @@ The revision of the HTTP specification u
>  .It Ic SERVER_SOFTWARE
>  The server software name of
>  .Xr httpd 8 .
> +.It Ic TLS_PEER_VERIFY
> +A variable that is set to a comma separated list of TLS client verification
> +features in use
> +.Pq omitted when TLS client verification is not in use .
>  .El
>  .It Ic hsts Oo Ar option Oc
>  Enable HTTP Strict Transport Security.
> @@ -526,6 +530,23 @@ will be used (strong crypto cipher suite
>  See the CIPHERS section of
>  .Xr openssl 1
>  for information about SSL/TLS cipher suites and preference lists.
> +.It Ic client ca Ar cafile Oo Ic crl Ar crlfile Oc Op Ic optional
> +Require
> +.Po
> +or, if
> +.Ic optional
> +is specified, request but do not require
> +.Pc
> +TLS client certificates whose authenticity can be verified
> +against the CA certificate(s) in
> +.Ar cafile
> +in order to proceed beyond the TLS handshake.
> +With
> +.Ic crl
> +specified, additionally require that no certificate in the client chain be
> +listed as revoked in the CRL(s) in
> +.Ar crlfile .
> +CA certificates and CRLs should be PEM encoded.
>  .It Ic dhe Ar params
>  Specify the DHE parameters to use for DHE cipher suites.
>  Valid parameter values are none, legacy and auto.
> Index: httpd.h
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
> retrieving revision 1.136
> diff -u -p -r1.136 httpd.h
> --- httpd.h   11 Apr 2018 15:50:46 -  1.136
> +++ httpd.h   16 May 2018 07:59:10 

Re: diff: add if group table to snmpd

2018-05-14 Thread Jan Klemkow
Hi Stuart,

On Mon, May 14, 2018 at 06:53:20PM +0100, Stuart Henderson wrote:
> On 2018/05/14 17:59, Jan Klemkow wrote:
> > The following diff adds an interface group table to the OpenBSD MIBs and
> > the OpenSNMPd.  The new snmp table helps to keep track of the demote
> > values of more complex carp setups.  To iterate directly through all
> > interface groups, the diff has to extent ioctl interface by a new
> > command SIOCGIFGLIST.
> > 
> > This new interface could also be used to extent ifconfig(8), in a later
> > diff, to list all interface groups with there demote counter.
> > 
> > I tested this diff with snmpctl(8) from base and snmpwalk from
> > net/net-snmp under current amd64.

> This seems a reasonable thing to report on and I didn't spot any code
> problems yet, one thing with the MIB file though:

> > Index: share/snmp/OPENBSD-CARP-MIB.txt
> > ===
> > RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
> > --- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 -  1.3
> > +++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 14:53:02 -
> > @@ -41,7 +41,7 @@ carpMIBObjects MODULE-IDENTITY
> >   "
> >  DESCRIPTION  "The MIB module for gathering information about
> >  Common Address Redundancy Protocol (CARP) interfaces."
> > -REVISION "20120131Z"
> > +REVISION "20180514Z"
> >  DESCRIPTION  "Add the OPENBSD-CARP-MIB to snmpd."
> >  ::= { openBSD 6 }
> 
> This section is meant to be a sort of changelog; please add a new
> REVISION/DESCRIPTION rather than changing the existing one. (Also check
> that smilint is happy).

Thanks for the hint.  I fixed the changelog and some other issues
pointed by smilint.

Thanks,
Jan

Index: share/snmp/OPENBSD-CARP-MIB.txt
===
RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
retrieving revision 1.3
diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
--- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 -  1.3
+++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 18:58:59 -
@@ -32,7 +32,7 @@ IMPORTS
FROM SNMPv2-CONF;
 
 carpMIBObjects MODULE-IDENTITY
-LAST-UPDATED "20120131Z"
+LAST-UPDATED "20180514Z"
 ORGANIZATION "OpenBSD"
 CONTACT-INFO "
   Author: Joel Knight
@@ -41,6 +41,8 @@ carpMIBObjects MODULE-IDENTITY
  "
 DESCRIPTION  "The MIB module for gathering information about
 Common Address Redundancy Protocol (CARP) interfaces."
+REVISION "20180514Z"
+DESCRIPTION  "Add the carpGroupTable to OPENBSD-CARP-MIB."
 REVISION "20120131Z"
 DESCRIPTION  "Add the OPENBSD-CARP-MIB to snmpd."
 ::= { openBSD 6 }
@@ -174,6 +176,58 @@ carpIfState OBJECT-TYPE
DESCRIPTION
"Indicates the operational state of the CARP interface."
::= { carpIfEntry 7 }
+
+
+-- carpGroup
+
+carpGroupTable OBJECT-TYPE
+   SYNTAX  SEQUENCE OF CarpGroupEntry
+   MAX-ACCESS  not-accessible
+   STATUS  current
+   DESCRIPTION
+   "A list of interface groups."
+   ::= { carpMIBObjects 4 }
+
+carpGroupEntry OBJECT-TYPE
+   SYNTAX  CarpGroupEntry
+   MAX-ACCESS  not-accessible
+   STATUS  current
+   DESCRIPTION
+   "An entry containing management information applicable to a
+   particular interface group."
+   INDEX   { carpGroupIndex }
+   ::= { carpGroupTable 1 }
+
+CarpGroupEntry ::=
+   SEQUENCE {
+   carpGroupIndex  Integer32,
+   carpGroupName   OCTET STRING,
+   carpGroupDemote Integer32
+   }
+
+carpGroupIndex OBJECT-TYPE
+   SYNTAX  Integer32 (1..2147483647)
+   MAX-ACCESS  not-accessible
+   STATUS  current
+   DESCRIPTION
+   "The demote value of the interface group."
+   ::= { carpGroupEntry 1 }
+
+carpGroupName OBJECT-TYPE
+   SYNTAX  OCTET STRING
+   MAX-ACCESS  read-only
+   STATUS  current
+   DESCRIPTION
+   "The name of the interface group."
+   ::= { carpGroupEntry 2 }
+
+carpGroupDemote OBJECT-TYPE
+   SYNTAX  Integer32 (1..2147483647)
+   MAX-ACCESS  read-only
+   STATUS  current
+   DESCRIPTION
+   "The demote value of the interface group."
+   ::= { carpGroupEntry 3 }
 
 
 -- carpStats
Index: sys/net/if.c
=

diff: add if group table to snmpd

2018-05-14 Thread Jan Klemkow
Hi,

The following diff adds an interface group table to the OpenBSD MIBs and
the OpenSNMPd.  The new snmp table helps to keep track of the demote
values of more complex carp setups.  To iterate directly through all
interface groups, the diff has to extent ioctl interface by a new
command SIOCGIFGLIST.

This new interface could also be used to extent ifconfig(8), in a later
diff, to list all interface groups with there demote counter.

I tested this diff with snmpctl(8) from base and snmpwalk from
net/net-snmp under current amd64.

Bye,
Jan

Index: share/snmp/OPENBSD-CARP-MIB.txt
===
RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
retrieving revision 1.3
diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
--- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 -  1.3
+++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 14:53:02 -
@@ -32,7 +32,7 @@ IMPORTS
FROM SNMPv2-CONF;
 
 carpMIBObjects MODULE-IDENTITY
-LAST-UPDATED "20120131Z"
+LAST-UPDATED "20180514Z"
 ORGANIZATION "OpenBSD"
 CONTACT-INFO "
   Author: Joel Knight
@@ -41,7 +41,7 @@ carpMIBObjects MODULE-IDENTITY
  "
 DESCRIPTION  "The MIB module for gathering information about
 Common Address Redundancy Protocol (CARP) interfaces."
-REVISION "20120131Z"
+REVISION "20180514Z"
 DESCRIPTION  "Add the OPENBSD-CARP-MIB to snmpd."
 ::= { openBSD 6 }
 
@@ -51,6 +51,7 @@ carpMIBObjects MODULE-IDENTITY
 carpSysctl OBJECT IDENTIFIER ::= { carpMIBObjects 1 }
 carpIf OBJECT IDENTIFIER ::= { carpMIBObjects 2 }
 carpStats  OBJECT IDENTIFIER ::= { carpMIBObjects 3 }
+carpGroupTable OBJECT IDENTIFIER ::= { carpMIBObjects 4 }
 
 
 -- carpSysctl
@@ -174,6 +175,49 @@ carpIfState OBJECT-TYPE
DESCRIPTION
"Indicates the operational state of the CARP interface."
::= { carpIfEntry 7 }
+
+
+-- carpGroup
+
+carpGroupTable OBJECT-TYPE
+   SYNTAX  SEQUENCE OF CarpGroupEntry
+   MAX-ACCESS  not-accessible
+   STATUS  current
+   DESCRIPTION
+   "A list of interface groups."
+   ::= { carpMIBObjects 4 }
+
+carpGroupEntry OBJECT-TYPE
+   SYNTAX  CarpGroupEntry
+   MAX-ACCESS  not-accessible
+   STATUS  current
+   DESCRIPTION
+   "An entry containing management information applicable to a
+   particular interface group."
+   INDEX   { carpGroupIndex }
+   ::= { carpGroupTable 1 }
+
+CarpGroupEntry ::=
+   SEQUENCE {
+   carpGroupName   OCTET STRING,
+   carpGroupDemote Integer32
+   }
+
+carpGroupName OBJECT-TYPE
+   SYNTAX  OCTET STRING
+   MAX-ACCESS  read-only
+   STATUS  current
+   DESCRIPTION
+   "The name of the interface group."
+   ::= { carpIfEntry 1 }
+
+carpGroupDemote OBJECT-TYPE
+   SYNTAX  Integer32 (1..2147483647)
+   MAX-ACCESS  read-only
+   STATUS  current
+   DESCRIPTION
+   "The demote value of the interface group."
+   ::= { carpIfEntry 2 }
 
 
 -- carpStats
Index: sys/net/if.c
===
RCS file: /cvs//src/sys/net/if.c,v
retrieving revision 1.551
diff -u -p -r1.551 if.c
--- sys/net/if.c28 Apr 2018 15:44:59 -  1.551
+++ sys/net/if.c9 May 2018 08:16:33 -
@@ -145,6 +145,7 @@ int if_getgroup(caddr_t, struct ifnet *)
 intif_getgroupmembers(caddr_t);
 intif_getgroupattribs(caddr_t);
 intif_setgroupattribs(caddr_t);
+intif_getgrouplist(caddr_t);
 
 void   if_linkstate(struct ifnet *);
 void   if_linkstate_task(void *);
@@ -1838,6 +1839,7 @@ ifioctl(struct socket *so, u_long cmd, c
case SIOCIFGCLONERS:
case SIOCGIFGMEMB:
case SIOCGIFGATTR:
+   case SIOCGIFGLIST:
case SIOCGIFFLAGS:
case SIOCGIFXFLAGS:
case SIOCGIFMETRIC:
@@ -2178,6 +2180,11 @@ ifioctl_get(u_long cmd, caddr_t data)
error = if_getgroupattribs(data);
NET_RUNLOCK();
return (error);
+   case SIOCGIFGLIST:
+   NET_RLOCK();
+   error = if_getgrouplist(data);
+   NET_RUNLOCK();
+   return (error);
}
 
ifp = ifunit(ifr->ifr_name);
@@ -2609,6 +2616,41 @@ if_setgroupattribs(caddr_t data)
 
TAILQ_FOREACH(ifgm, >ifg_members, ifgm_next)
ifgm->ifgm_ifp->if_ioctl(ifgm->ifgm_ifp, SIOCSIFGATTR, data);
+
+   return (0);
+}
+
+/*
+ * Stores all groups in memory pointed to by data
+ */
+int
+if_getgrouplist(caddr_t data)
+{
+   struct ifgroupreq   *ifgr = (struct ifgroupreq *)data;
+   struct ifg_group*ifg;
+   struct ifg_req   ifgrq, *ifgp;
+   int  len, 

Re: diff: cu(1): add secure kiosk mode + stricter pledge

2017-12-03 Thread Jan Klemkow
On Sat, Dec 02, 2017 at 08:37:34PM +0100, Jan Klemkow wrote:
> On Sat, Dec 02, 2017 at 08:17:15PM +0100, Jan Klemkow wrote:
> > On Fri, Dec 01, 2017 at 04:17:42PM -0700, Theo de Raadt wrote:
> > > So two comments:  Calling this thing by the right name (escape),
> > > would allow you to search other programs which have similar functions,
> > > see if someone did it before, and match the behaviour / option.
> > 
> > Yes, the term "kiosk mode" is not that common in unix environments.
> > So, I changed it to "restricted mode" as it is used in ksh(1).

I forget to change the usage from "-k" to "-r".
Hopefully this is the final version:

Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c   5 Oct 2015 23:15:31 -   1.15
+++ command.c   2 Dec 2017 19:30:52 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+   if (restricted) {
+   cu_warnx("~C command is not allowed in restricted 
mode");
+   break;
+   }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+   if (restricted) {
+   cu_warnx("~R command is not allowed in restricted 
mode");
+   break;
+   }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+   if (restricted) {
+   cu_warnx("~X command is not allowed in restricted 
mode");
+   break;
+   }
send_xmodem();
break;
case '$':
+   if (restricted) {
+   cu_warnx("~$ command is not allowed in restricted 
mode");
+   break;
+   }
pipe_command();
break;
case '>':
+   if (restricted) {
+   cu_warnx("~> command is not allowed in restricted 
mode");
+   break;
+   }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 -  1.15
+++ cu.12 Dec 2017 18:06:25 -
@@ -35,7 +35,7 @@
 .Nd serial terminal emulator
 .Sh SYNOPSIS
 .Nm
-.Op Fl d
+.Op Fl dr
 .Op Fl l Ar line
 .Op Fl s Ar speed | Fl Ar speed
 .Nm
@@ -55,6 +55,11 @@ The options are as follows:
 Specify that the line is directly connected and
 .Nm
 should not allow the driver to block waiting for a carrier to be detected.
+.It Fl r
+Starts
+.Nm
+in restricted mode.
+This prevents all local filesystem operations and command executions.
 .It Fl l Ar line
 Specify the line to use.
 Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
 The command string sent to the local
 .Ux
 system is processed by the shell.
+This command is not allowed in restricted mode.
 .It Ic ~#
 Send a
 .Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
 1 \*(Lt-\*(Gt remote tty out
 2 \*(Lt-\*(Gt local tty stderr
 .Ed
+.Pp
+This command is not allowed in restricted mode.
 .It Ic ~D
 Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in restricted mode.
 .It Ic ~R
 Record all output from the remote system to a file.
 If the given file already exists, it is appended to.
 If no file is specified, any existing recording is stopped.
+This command is not allowed in restricted mode.
 .It Ic ~S
 Change the speed of the connection.
 .It Ic ~X
 Send a file with the XMODEM protocol.
+This command is not allowed in restricted mode.
 .It Ic ~?
 Get a summary of the tilde escapes.
 .El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 -  1.25
+++ cu.c3 Dec 2017 10:15:30 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
 int is_direct = -1;
+int restricted = 0;
 const char *line_path = NULL;
 int line_speed = -1;
 int line_fd;
@@ -66,7 +67,7 @@ void  try_remote(const char *, const cha
 __dead void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-d] [-l line] [-s speed

Re: diff: cu(1): add secure kiosk mode + stricter pledge

2017-12-02 Thread Jan Klemkow
On Sat, Dec 02, 2017 at 08:17:15PM +0100, Jan Klemkow wrote:
> On Fri, Dec 01, 2017 at 04:17:42PM -0700, Theo de Raadt wrote:
> > So two comments:  Calling this thing by the right name (escape),
> > would allow you to search other programs which have similar functions,
> > see if someone did it before, and match the behaviour / option.
> 
> Yes, the term "kiosk mode" is not that common in unix environments.
> So, I changed it to "restricted mode" as it is used in ksh(1).

Sorry for the noise.  I forget to change the warning messages.  I also
changed the variable r_flag to "restricted" as it is used in the source
of ksh(1), too.

This version should be fine:

Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c   5 Oct 2015 23:15:31 -   1.15
+++ command.c   2 Dec 2017 19:30:52 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+   if (restricted) {
+   cu_warnx("~C command is not allowed in restricted 
mode");
+   break;
+   }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+   if (restricted) {
+   cu_warnx("~R command is not allowed in restricted 
mode");
+   break;
+   }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+   if (restricted) {
+   cu_warnx("~X command is not allowed in restricted 
mode");
+   break;
+   }
send_xmodem();
break;
case '$':
+   if (restricted) {
+   cu_warnx("~$ command is not allowed in restricted 
mode");
+   break;
+   }
pipe_command();
break;
case '>':
+   if (restricted) {
+   cu_warnx("~> command is not allowed in restricted 
mode");
+   break;
+   }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 -  1.15
+++ cu.12 Dec 2017 18:06:25 -
@@ -35,7 +35,7 @@
 .Nd serial terminal emulator
 .Sh SYNOPSIS
 .Nm
-.Op Fl d
+.Op Fl dr
 .Op Fl l Ar line
 .Op Fl s Ar speed | Fl Ar speed
 .Nm
@@ -55,6 +55,11 @@ The options are as follows:
 Specify that the line is directly connected and
 .Nm
 should not allow the driver to block waiting for a carrier to be detected.
+.It Fl r
+Starts
+.Nm
+in restricted mode.
+This prevents all local filesystem operations and command executions.
 .It Fl l Ar line
 Specify the line to use.
 Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
 The command string sent to the local
 .Ux
 system is processed by the shell.
+This command is not allowed in restricted mode.
 .It Ic ~#
 Send a
 .Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
 1 \*(Lt-\*(Gt remote tty out
 2 \*(Lt-\*(Gt local tty stderr
 .Ed
+.Pp
+This command is not allowed in restricted mode.
 .It Ic ~D
 Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in restricted mode.
 .It Ic ~R
 Record all output from the remote system to a file.
 If the given file already exists, it is appended to.
 If no file is specified, any existing recording is stopped.
+This command is not allowed in restricted mode.
 .It Ic ~S
 Change the speed of the connection.
 .It Ic ~X
 Send a file with the XMODEM protocol.
+This command is not allowed in restricted mode.
 .It Ic ~?
 Get a summary of the tilde escapes.
 .El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 -  1.25
+++ cu.c2 Dec 2017 19:28:52 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
 int is_direct = -1;
+int restricted = 0;
 const char *line_path = NULL;
 int line_speed = -1;
 int line_fd;
@@ -66,7 +67,7 @@ void  try_remote(const char *, const cha
 __dead void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-d] [-l line] 

Re: diff: cu(1): add secure kiosk mode + stricter pledge

2017-12-02 Thread Jan Klemkow
On Fri, Dec 01, 2017 at 04:17:42PM -0700, Theo de Raadt wrote:
> > The diff adds the option -k (for kiosk mode) 
> 
> Congratulations, you win some sort of prize.  That is the worst-named
> option I have seen in more than a decade.

Thanks. :-)

> Good idea though, but I think we have better getopt interfaces for
> blocking escapes in other commands.  ssh has to do this, and I suspect
> a few other commands do also.
> 
> So two comments:  Calling this thing by the right name (escape),
> would allow you to search other programs which have similar functions,
> see if someone did it before, and match the behaviour / option.

Yes, the term "kiosk mode" is not that common in unix environments.
So, I changed it to "restricted mode" as it is used in ksh(1).

Thanks,
Jan

Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c   5 Oct 2015 23:15:31 -   1.15
+++ command.c   2 Dec 2017 18:02:20 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+   if (r_flag) {
+   cu_warnx("~C command is not allowed in kiosk mode");
+   break;
+   }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+   if (r_flag) {
+   cu_warnx("~R command is not allowed in kiosk mode");
+   break;
+   }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+   if (r_flag) {
+   cu_warnx("~X command is not allowed in kiosk mode");
+   break;
+   }
send_xmodem();
break;
case '$':
+   if (r_flag) {
+   cu_warnx("~$ command is not allowed in kiosk mode");
+   break;
+   }
pipe_command();
break;
case '>':
+   if (r_flag) {
+   cu_warnx("~> command is not allowed in kiosk mode");
+   break;
+   }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 -  1.15
+++ cu.12 Dec 2017 18:06:25 -
@@ -35,7 +35,7 @@
 .Nd serial terminal emulator
 .Sh SYNOPSIS
 .Nm
-.Op Fl d
+.Op Fl dr
 .Op Fl l Ar line
 .Op Fl s Ar speed | Fl Ar speed
 .Nm
@@ -55,6 +55,11 @@ The options are as follows:
 Specify that the line is directly connected and
 .Nm
 should not allow the driver to block waiting for a carrier to be detected.
+.It Fl r
+Starts
+.Nm
+in restricted mode.
+This prevents all local filesystem operations and command executions.
 .It Fl l Ar line
 Specify the line to use.
 Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
 The command string sent to the local
 .Ux
 system is processed by the shell.
+This command is not allowed in restricted mode.
 .It Ic ~#
 Send a
 .Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
 1 \*(Lt-\*(Gt remote tty out
 2 \*(Lt-\*(Gt local tty stderr
 .Ed
+.Pp
+This command is not allowed in restricted mode.
 .It Ic ~D
 Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in restricted mode.
 .It Ic ~R
 Record all output from the remote system to a file.
 If the given file already exists, it is appended to.
 If no file is specified, any existing recording is stopped.
+This command is not allowed in restricted mode.
 .It Ic ~S
 Change the speed of the connection.
 .It Ic ~X
 Send a file with the XMODEM protocol.
+This command is not allowed in restricted mode.
 .It Ic ~?
 Get a summary of the tilde escapes.
 .El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 -  1.25
+++ cu.c2 Dec 2017 18:02:06 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
 int is_direct = -1;
+int r_flag = 0;
 const char *line_path = NULL;
 int line_speed = -1;
 int line_fd;
@@ -66,7 +67,7 @@ void  try_remote(const char *, const cha
 __dead void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-d] [-l line] [-s speed | -speed]\n",
+   fprintf(stderr, "usage: %s [-dk] [-l line] [-s speed 

diff: cu(1): add secure kiosk mode + stricter pledge

2017-12-01 Thread Jan Klemkow
Hi,

I run cu(1) as ssh forced command for other users on my machine.
This allows them to reach the serial port of their machines over mine.
To prevent them of doing filesystem operations or further command
executions I implement this diff.

The diff adds the option -k (for kiosk mode) to cu(1) and reduces the
pledge string from "stdio rpath wpath cpath getpw proc exec tty" to
"stdio tty".  If a user still tries to type a forbidden command, he gets
a warning message.

I successfully tested all escape command with and without the -k option.

Bye,
Jan

Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c   5 Oct 2015 23:15:31 -   1.15
+++ command.c   1 Dec 2017 22:10:17 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+   if (k_flag) {
+   cu_warnx("~C command is not allowed in kiosk mode");
+   break;
+   }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+   if (k_flag) {
+   cu_warnx("~R command is not allowed in kiosk mode");
+   break;
+   }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+   if (k_flag) {
+   cu_warnx("~X command is not allowed in kiosk mode");
+   break;
+   }
send_xmodem();
break;
case '$':
+   if (k_flag) {
+   cu_warnx("~$ command is not allowed in kiosk mode");
+   break;
+   }
pipe_command();
break;
case '>':
+   if (k_flag) {
+   cu_warnx("~> command is not allowed in kiosk mode");
+   break;
+   }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 -  1.15
+++ cu.11 Dec 2017 22:36:32 -
@@ -35,7 +35,7 @@
 .Nd serial terminal emulator
 .Sh SYNOPSIS
 .Nm
-.Op Fl d
+.Op Fl dk
 .Op Fl l Ar line
 .Op Fl s Ar speed | Fl Ar speed
 .Nm
@@ -55,6 +55,11 @@ The options are as follows:
 Specify that the line is directly connected and
 .Nm
 should not allow the driver to block waiting for a carrier to be detected.
+.It Fl k
+Starts
+.Nm
+in kiosk mode.
+This prevents all local filesystem operations and command executions.
 .It Fl l Ar line
 Specify the line to use.
 Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
 The command string sent to the local
 .Ux
 system is processed by the shell.
+This command is not allowed in kiosk mode.
 .It Ic ~#
 Send a
 .Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
 1 \*(Lt-\*(Gt remote tty out
 2 \*(Lt-\*(Gt local tty stderr
 .Ed
+.Pp
+This command is not allowed in kiosk mode.
 .It Ic ~D
 Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in kiosk mode.
 .It Ic ~R
 Record all output from the remote system to a file.
 If the given file already exists, it is appended to.
 If no file is specified, any existing recording is stopped.
+This command is not allowed in kiosk mode.
 .It Ic ~S
 Change the speed of the connection.
 .It Ic ~X
 Send a file with the XMODEM protocol.
+This command is not allowed in kiosk mode.
 .It Ic ~?
 Get a summary of the tilde escapes.
 .El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 -  1.25
+++ cu.c1 Dec 2017 23:02:23 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
 int is_direct = -1;
+int k_flag = 0;
 const char *line_path = NULL;
 int line_speed = -1;
 int line_fd;
@@ -66,7 +67,7 @@ void  try_remote(const char *, const cha
 __dead void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-d] [-l line] [-s speed | -speed]\n",
+   fprintf(stderr, "usage: %s [-dk] [-l line] [-s speed | -speed]\n",
__progname);
fprintf(stderr, "   %s [host]\n", __progname);
exit(1);
@@ -100,11 +101,16 @@ main(int argc, char **argv)
errx(1, "speed asprintf");
}
 
-   while ((opt 

Re: tftpd(8): diff for ip path rewrite

2017-10-27 Thread Jan Klemkow
On Wed, Oct 25, 2017 at 04:54:01PM +, Jeremie Courreges-Anglas wrote:
> On Tue, Oct 24 2017, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
> > On Mon, Oct 23 2017, Jan Klemkow <j.klem...@wemelug.de> wrote:
> >> On Sun, Oct 22, 2017 at 09:32:54PM +, Jeremie Courreges-Anglas wrote:
> >>> On Sat, Oct 21 2017, Jan Klemkow <j.klem...@wemelug.de> wrote:
> >>> > On Fri, Oct 20, 2017 at 12:04:41PM +, Jeremie Courreges-Anglas 
> >>> > wrote:
> >>> >> On Fri, Oct 20 2017, Sebastien Marie <sema...@online.fr> wrote:
> >>> >> > On Thu, Oct 19, 2017 at 08:58:12PM +0200, Jan Klemkow wrote:
> >>> >> >> +   char nfilename[PATH_MAX];
> >>> >> >> +
> >>> >> >> +   snprintf(nfilename, sizeof nfilename, "%s/%s",
> >>> >> >> +   getip(>ss), filename);
> >>> >> >
> >>> >> > - filename has PATH_MAX length
> >>> >> > - getip(>ss) could have NI_MAXHOST length
> >>> >> 
> >>> >> INET6_ADDRSTRLEN since getip() calls getnameinfo(NI_NUMERICHOST), but
> >>> >> your point stands.
> >>> >> 
> >>> >> > so nfilename could be larger than PATH_MAX (sizeof nfilename).
> >>> >> >
> >>> >> > I assume the return of snprintf() need to be checked. if truncation
> >>> >> > occured, a warning should be issued and nfilename discarded (just
> >>> >> > calling tftp_open(client, filename)) ?
> >>> >> 
> >>> >> I think we should refuse the request if truncated.
> >>> >
> >>> > done
> >>> >  
> >>> >> >> +   if (access(nfilename, R_OK) == 0)
> >>> >> >> +   tftp_open(client, nfilename);
> >>> >> >> +   else
> >>> >> >> +   tftp_open(client, filename);
> >>> >> >> +   }
> >>> >> 
> >>> >> Here we look up the same file in both the client-specific subdirectory
> >>> >> and the default directory.  Should we instead look only in the
> >>> >> client-specific directory if the latter exist?
> >>> >
> >>> > Common files should be found in the default directory.  But, host
> >>> > specific files could be overwritten if they exist in the subdirectory.
> >>> 
> >>> I think it would be better to perform those access tests in
> >>> validate_access(); logic in a single place, and a less quirky handling
> >>> of SEEDPATH.  Also the test done should probably depend on the type
> >>> (read, write) of the request.  Retrying with the default directory may
> >>> make sense in read mode, but maybe not in write (and -c, create) mode?
> >>> 
> >>> The updated diff below implements such semantics, but in
> >>> validate_access().  While here,
> >>> - improve diagnostic if both -i and -r are given; usage() doesn't show
> >>>   the conflict
> >>> - also test snprintf return value against -1, as spotted by semarie@
> >>> 
> >>> Maybe we should add a mention in the manpage that the client can
> >>> "escape" its client-specific directory?  (ie /../192.0.2.1/file)
> >>> 
> >>> The logic is more complicated but I hope it's for good.
> >>
> >> I successfully testes jca's diff in my setup and add two lines about
> >> directory escaping to the manpage.
> >
> > I don't think there is a need to expand on security and machines
> > changing their IP address, especially when you're using TFTP, an
> > insecure protocol.  I just wanted to stress that no enforcement was
> > done.
> >
> > Here's an alternate take at documenting -i, addressing a few issues. It
> > moves the "no path enforcement" sentence to CAVEATS.  I hope you agree
> > with this move.
> 
> At least jmc@ thinks that the -i flag description is a better place.
> 
> > While here:
> > - kill .Tn
> > - the content of the previous BUGS section doesn't look like a TFTP bug,
> >   so CAVEATS looks more appropriate to me
> 
> I've kept those changes (to be committed seperately).
> 
> > Feedback & oks welcome.
> 
> New diff after feedback from jmc@

I tested this diff.  It looks fine for me. 

Thanks,
Jan
 
> I

Re: tftpd(8): diff for ip path rewrite

2017-10-23 Thread Jan Klemkow
On Sun, Oct 22, 2017 at 09:32:54PM +, Jeremie Courreges-Anglas wrote:
> On Sat, Oct 21 2017, Jan Klemkow <j.klem...@wemelug.de> wrote:
> > On Fri, Oct 20, 2017 at 12:04:41PM +, Jeremie Courreges-Anglas wrote:
> >> On Fri, Oct 20 2017, Sebastien Marie <sema...@online.fr> wrote:
> >> > On Thu, Oct 19, 2017 at 08:58:12PM +0200, Jan Klemkow wrote:
> >> >> +   char nfilename[PATH_MAX];
> >> >> +
> >> >> +   snprintf(nfilename, sizeof nfilename, "%s/%s",
> >> >> +   getip(>ss), filename);
> >> >
> >> > - filename has PATH_MAX length
> >> > - getip(>ss) could have NI_MAXHOST length
> >> 
> >> INET6_ADDRSTRLEN since getip() calls getnameinfo(NI_NUMERICHOST), but
> >> your point stands.
> >> 
> >> > so nfilename could be larger than PATH_MAX (sizeof nfilename).
> >> >
> >> > I assume the return of snprintf() need to be checked. if truncation
> >> > occured, a warning should be issued and nfilename discarded (just
> >> > calling tftp_open(client, filename)) ?
> >> 
> >> I think we should refuse the request if truncated.
> >
> > done
> >  
> >> >> +   if (access(nfilename, R_OK) == 0)
> >> >> +   tftp_open(client, nfilename);
> >> >> +   else
> >> >> +   tftp_open(client, filename);
> >> >> +   }
> >> 
> >> Here we look up the same file in both the client-specific subdirectory
> >> and the default directory.  Should we instead look only in the
> >> client-specific directory if the latter exist?
> >
> > Common files should be found in the default directory.  But, host
> > specific files could be overwritten if they exist in the subdirectory.
> 
> I think it would be better to perform those access tests in
> validate_access(); logic in a single place, and a less quirky handling
> of SEEDPATH.  Also the test done should probably depend on the type
> (read, write) of the request.  Retrying with the default directory may
> make sense in read mode, but maybe not in write (and -c, create) mode?
> 
> The updated diff below implements such semantics, but in
> validate_access().  While here,
> - improve diagnostic if both -i and -r are given; usage() doesn't show
>   the conflict
> - also test snprintf return value against -1, as spotted by semarie@
> 
> Maybe we should add a mention in the manpage that the client can
> "escape" its client-specific directory?  (ie /../192.0.2.1/file)
> 
> The logic is more complicated but I hope it's for good.

I successfully testes jca's diff in my setup and add two lines about
directory escaping to the manpage.

Thanks,
Jan

Index: tftpd.8
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
retrieving revision 1.5
diff -u -p -r1.5 tftpd.8
--- tftpd.8 18 Jul 2015 05:32:56 -  1.5
+++ tftpd.8 23 Oct 2017 18:03:41 -
@@ -37,7 +37,7 @@
 .Nd DARPA Trivial File Transfer Protocol daemon
 .Sh SYNOPSIS
 .Nm tftpd
-.Op Fl 46cdv
+.Op Fl 46cdiv
 .Op Fl l Ar address
 .Op Fl p Ar port
 .Op Fl r Ar socket
@@ -100,6 +100,19 @@ If this option is specified,
 .Nm
 will run in the foreground and log
 the client IP, type of request, and filename to stderr.
+.It Fl i
+.Nm
+tries to rewrite the requested filename with a prefix of
+the client's IP address.
+If the rewritten path exists
+.Nm
+will serve this file.
+If not, it will serve the original filename.
+This option is no security feature.
+Clients are able to escape thier specific directory by
+paths like /../ or by changing their IP address.
+This option can not be combined with
+.Fl r .
 .It Fl l Ar address
 Listen on the specified address.
 By default
@@ -126,6 +139,8 @@ before the TFTP request will continue.
 By default
 .Nm
 does not use filename rewriting.
+This option can not be combined with
+.Fl i .
 .It Fl v
 Log the client IP, type of request, and filename.
 .It Ar directory
Index: tftpd.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
retrieving revision 1.39
diff -u -p -r1.39 tftpd.c
--- tftpd.c 26 May 2017 17:38:46 -  1.39
+++ tftpd.c 23 Oct 2017 17:56:03 -
@@ -282,7 +282,7 @@ __dead void
 usage(void)
 {
extern char *__progname;
-   fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]"
+   fprintf(stderr, "usage: %s [-46cdiv] [-l address] [-p port] [-r socket]"
" directory\n", __progna

Re: tftpd(8): diff for ip path rewrite

2017-10-21 Thread Jan Klemkow
On Fri, Oct 20, 2017 at 12:04:41PM +, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 20 2017, Sebastien Marie <sema...@online.fr> wrote:
> > On Thu, Oct 19, 2017 at 08:58:12PM +0200, Jan Klemkow wrote:
> >> +  char nfilename[PATH_MAX];
> >> +
> >> +  snprintf(nfilename, sizeof nfilename, "%s/%s",
> >> +  getip(>ss), filename);
> >
> > - filename has PATH_MAX length
> > - getip(>ss) could have NI_MAXHOST length
> 
> INET6_ADDRSTRLEN since getip() calls getnameinfo(NI_NUMERICHOST), but
> your point stands.
> 
> > so nfilename could be larger than PATH_MAX (sizeof nfilename).
> >
> > I assume the return of snprintf() need to be checked. if truncation
> > occured, a warning should be issued and nfilename discarded (just
> > calling tftp_open(client, filename)) ?
> 
> I think we should refuse the request if truncated.

done
 
> >> +  if (access(nfilename, R_OK) == 0)
> >> +  tftp_open(client, nfilename);
> >> +  else
> >> +  tftp_open(client, filename);
> >> +  }
> 
> Here we look up the same file in both the client-specific subdirectory
> and the default directory.  Should we instead look only in the
> client-specific directory if the latter exist?

Common files should be found in the default directory.  But, host
specific files could be overwritten if they exist in the subdirectory.

The diff below should address all comments.

Thanks,
Jan

Index: tftpd.8
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
retrieving revision 1.5
diff -u -p -r1.5 tftpd.8
--- tftpd.8 18 Jul 2015 05:32:56 -  1.5
+++ tftpd.8 21 Oct 2017 18:41:15 -
@@ -37,7 +37,7 @@
 .Nd DARPA Trivial File Transfer Protocol daemon
 .Sh SYNOPSIS
 .Nm tftpd
-.Op Fl 46cdv
+.Op Fl 46cdiv
 .Op Fl l Ar address
 .Op Fl p Ar port
 .Op Fl r Ar socket
@@ -100,6 +100,16 @@ If this option is specified,
 .Nm
 will run in the foreground and log
 the client IP, type of request, and filename to stderr.
+.It Fl i
+.Nm
+tries to rewrite the requested filename with a prefix of
+the client's IP address.
+If the rewritten path exists
+.Nm
+will serve this file.
+If not, it will serve the original filename.
+This option can not be combined with
+.Fl r .
 .It Fl l Ar address
 Listen on the specified address.
 By default
@@ -126,6 +136,8 @@ before the TFTP request will continue.
 By default
 .Nm
 does not use filename rewriting.
+This option can not be combined with
+.Fl i .
 .It Fl v
 Log the client IP, type of request, and filename.
 .It Ar directory
Index: tftpd.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
retrieving revision 1.39
diff -u -p -r1.39 tftpd.c
--- tftpd.c 26 May 2017 17:38:46 -  1.39
+++ tftpd.c 21 Oct 2017 19:49:04 -
@@ -282,7 +282,7 @@ __dead void
 usage(void)
 {
extern char *__progname;
-   fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]"
+   fprintf(stderr, "usage: %s [-46cdiv] [-l address] [-p port] [-r socket]"
" directory\n", __progname);
exit(1);
 }
@@ -290,6 +290,7 @@ usage(void)
 int  cancreate = 0;
 int  verbose = 0;
 int  debug = 0;
+int  iflag = 0;
 
 int
 main(int argc, char *argv[])
@@ -307,7 +308,7 @@ main(int argc, char *argv[])
int family = AF_UNSPEC;
int devnull = -1;
 
-   while ((c = getopt(argc, argv, "46cdl:p:r:v")) != -1) {
+   while ((c = getopt(argc, argv, "46cdil:p:r:v")) != -1) {
switch (c) {
case '4':
family = AF_INET;
@@ -321,6 +322,11 @@ main(int argc, char *argv[])
case 'd':
verbose = debug = 1;
break;
+   case 'i':
+   if (rewrite != NULL)
+   usage();
+   iflag = 1;
+   break;
case 'l':
addr = optarg;
break;
@@ -328,6 +334,8 @@ main(int argc, char *argv[])
port = optarg;
break;
case 'r':
+   if (iflag == 1)
+   usage();
rewrite = optarg;
break;
case 'v':
@@ -903,7 +911,20 @@ again:
 
if (rwmap != NULL)
rewrite_map(client, filename);
-   else
+   else if (iflag) {
+   char nfilename[PATH_MAX];
+
+   if (snprintf(nfilename, sizeof(nfilename), "%s/%s",
+  

Re: tftpd(8): diff for ip path rewrite

2017-10-19 Thread Jan Klemkow
On Thu, Oct 19, 2017 at 09:36:50AM +, Jeremie Courreges-Anglas wrote:
> On Wed, Oct 18 2017, Jan Klemkow <j.klem...@wemelug.de> wrote:
> > On Wed, Oct 18, 2017 at 08:37:48PM +, Jason McIntyre wrote:
> >> On Wed, Oct 18, 2017 at 10:25:13PM +0200, Jan Klemkow wrote:
> >> > This diff adds an option for client IP address path prefixes to the
> >> > tftpd(8).  First, I used the -r rewrite socket for this, but...
> >> > 
> >> > If you use the rewrite socket feature, the tftpd(8) will exit with an
> >> > error when the rewrite socket is closed.  A reopen of the socket is not
> >> > possible, if its outside of the chroot directory.  And a privilege
> >> > separated tftpd(8) is a bit overkill for a stable per client path
> >> > rewrite feature.  This story led me to this change here.
> 
> I think it makes sense to support this feature without the need for an
> additional unix service.
> 
> >> > Any suggestions or objections are welcome. :-)
> 
> Do we want to provide a fallback directory so that you don't need to
> restart tftpd without -i to support unknown clients?

bluhm@ suggested, that this should be the default behavior.  Thus, the
ftpd(8) checks if a subdirectory with the client's ip address exists and
contains the requested file.  It not, it uses the original path as
default.  I implemented it in this diff:

Index: tftpd.8
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
retrieving revision 1.5
diff -u -p -r1.5 tftpd.8
--- tftpd.8 18 Jul 2015 05:32:56 -  1.5
+++ tftpd.8 19 Oct 2017 18:41:07 -
@@ -78,6 +78,14 @@ and therefore this path will be ignored 
 .Ox
 network bootloaders access this path to harvest entropy during
 kernel load.
+Also,
+.Nm
+always tries to rewrite the requested filename with a prefix of
+the client's IP address.
+If the rewritten path exists
+.Nm
+will serve this file.
+If not, it will serve the original filename.
 .Pp
 The options are as follows:
 .Bl -tag -width Ds
Index: tftpd.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
retrieving revision 1.39
diff -u -p -r1.39 tftpd.c
--- tftpd.c 26 May 2017 17:38:46 -  1.39
+++ tftpd.c 19 Oct 2017 18:27:24 -
@@ -903,8 +903,17 @@ again:
 
if (rwmap != NULL)
rewrite_map(client, filename);
-   else
-   tftp_open(client, filename);
+   else {
+   char nfilename[PATH_MAX];
+
+   snprintf(nfilename, sizeof nfilename, "%s/%s",
+   getip(>ss), filename);
+
+   if (access(nfilename, R_OK) == 0)
+   tftp_open(client, nfilename);
+   else
+   tftp_open(client, filename);
+   }
 
return;
 



  1   2   >