base64.c: u_char -> unsigned char

2021-10-21 Thread Theo Buehler
LibreSSL portable uses base64.c. Not everyone has u_char, so this is a mild portability annoyance. This means that we can get rid of sys/types.h. I also removed stdio.h since that seems unused. As far as I can see, base64.c directly needs ctype.h for isspace() resolv.h for the function

macppc: ignore 0 BARs in vgafb

2021-10-21 Thread Ryan Farley
Hello, Based on the history it seems that the drm code is now used for AMD/ATI graphics hardware, leaving those with lowly old nvidia cards (which can't be replaced in the case of my powerbook) to rely on xf86-video-nv for a proper full-color X experience; the problem is that the existing logic

remove lzs compression

2021-10-21 Thread Alexander Bluhm
Hi, After deleting hifn(4) the only provider for the LZS compression algorithm is gone. Reomve all LZS references from our tree. The v42bis in isakmpd also looks unsupported. ok? bluhm Index: sys/crypto/cryptodev.h === RCS file:

Re: crypto: remove crypto queue

2021-10-21 Thread Patrick Wildt
On Fri, Oct 22, 2021 at 12:03:07AM +0200, Tobias Heider wrote: > Currently, all crypto users set CRYPTO_F_NOQUEUE to run crypto operations > without queue and there are no plans to switch back to using the queue. > The diff below removes the flag together with the queueing code. > > ok? Looks

Re: crypto: remove crypto queue

2021-10-21 Thread Vitaliy Makkoveev
On Fri, Oct 22, 2021 at 12:03:07AM +0200, Tobias Heider wrote: > Currently, all crypto users set CRYPTO_F_NOQUEUE to run crypto operations > without queue and there are no plans to switch back to using the queue. > The diff below removes the flag together with the queueing code. > > ok? > ok

crypto: remove crypto queue

2021-10-21 Thread Tobias Heider
Currently, all crypto users set CRYPTO_F_NOQUEUE to run crypto operations without queue and there are no plans to switch back to using the queue. The diff below removes the flag together with the queueing code. ok? Index: dev/softraid_crypto.c

Re: pcidevs: intel gemini lake mei

2021-10-21 Thread Jonathan Gray
On Thu, Oct 21, 2021 at 11:17:56PM +0200, Felix Kronlage-Dammers wrote: > hi, > > found this mei pci device id in a gemini lake based shuttle pc. thanks, committed

pcidevs: intel gemini lake mei

2021-10-21 Thread Felix Kronlage-Dammers
hi, found this mei pci device id in a gemini lake based shuttle pc. Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1977 diff -u -p -u -r1.1977 pcidevs --- sys/dev/pci/pcidevs 29 Sep

Re: agintc(4): initialize IGROUP (tests required on RK3399 like RockPro64 or Pinebook Pro)

2021-10-21 Thread Felix Kronlage-Dammers
On Thu, Oct 21, 2021 at 08:18:40PM +0200, Patrick Wildt wrote: Hi Patrick, > This diff is one of two steps in getting Parallels on Apple M1s to work. > It initializes two registers to configure the interrupts as GNS1. > > It works fine on the Ampere machine that I have access to, but it would >

Re: More pchgpio(4)

2021-10-21 Thread Mike Larkin
On Tue, Oct 12, 2021 at 01:19:55PM -0700, Mike Larkin wrote: > On Sun, Oct 10, 2021 at 11:42:31PM +0200, Mark Kettenis wrote: > > > Date: Sat, 9 Oct 2021 22:27:52 +0200 (CEST) > > > From: Mark Kettenis > > > > > > > Date: Sat, 9 Oct 2021 20:55:10 +0200 (CEST) > > > > From: Mark Kettenis > > > >

agintc(4): initialize IGROUP (tests required on RK3399 like RockPro64 or Pinebook Pro)

2021-10-21 Thread Patrick Wildt
Hi, This diff is one of two steps in getting Parallels on Apple M1s to work. It initializes two registers to configure the interrupts as GNS1. It works fine on the Ampere machine that I have access to, but it would be very nice if someone can give this a try on an RK3399 machine like the

Re: retire hifn safe ubsec

2021-10-21 Thread Stuart Henderson
On 2021/10/21 10:02, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2021/10/21 16:30, Alexander Bluhm wrote: > > > Hi, > > > > > > Goal is to retire the async crypto API. It is slow and adds > > > complexity which hinders MP progress in IPsec. It is used by the > > > old PCI devices

Re: retire hifn safe ubsec

2021-10-21 Thread Theo de Raadt
Stuart Henderson wrote: > On 2021/10/21 16:30, Alexander Bluhm wrote: > > Hi, > > > > Goal is to retire the async crypto API. It is slow and adds > > complexity which hinders MP progress in IPsec. It is used by the > > old PCI devices hifn(4), safe(4), and ubsec(4). > > > > These devices are

Re: retire hifn safe ubsec

2021-10-21 Thread Stuart Henderson
On 2021/10/21 16:30, Alexander Bluhm wrote: > Hi, > > Goal is to retire the async crypto API. It is slow and adds > complexity which hinders MP progress in IPsec. It is used by the > old PCI devices hifn(4), safe(4), and ubsec(4). > > These devices are not common anymore. Using the CPU for

new option for rcctl ls

2021-10-21 Thread Stuart Henderson
Sometimes I find it useful to list daemons which are set to 'disabled' but are actually running. Either those where I have started them by hand forgotten to enable in rc.conf.local, or to check for services which shouldn't be running but which are anyway. Any comments on this diff to add it to

Re: retire hifn safe ubsec

2021-10-21 Thread Claudio Jeker
On Thu, Oct 21, 2021 at 04:30:02PM +0200, Alexander Bluhm wrote: > Hi, > > Goal is to retire the async crypto API. It is slow and adds > complexity which hinders MP progress in IPsec. It is used by the > old PCI devices hifn(4), safe(4), and ubsec(4). > > These devices are not common anymore.

Re: retire hifn safe ubsec

2021-10-21 Thread Visa Hankala
On Thu, Oct 21, 2021 at 04:30:02PM +0200, Alexander Bluhm wrote: > Goal is to retire the async crypto API. It is slow and adds > complexity which hinders MP progress in IPsec. It is used by the > old PCI devices hifn(4), safe(4), and ubsec(4). > > These devices are not common anymore. Using

Re: snmpd: s/SNMP_C_GETRESP/SNMP_C_RESPONSE

2021-10-21 Thread Martijn van Duren
On Thu, 2021-10-21 at 15:22 +0100, Stuart Henderson wrote: > On 2021/10/21 15:08, Martijn van Duren wrote: > > This one has been bothering me for a while. > > > > OK? > > > > martijn@ > > > > Index: smi.c > > === > > RCS file:

Re: snmpd: s/SNMP_C_GETRESP/SNMP_C_RESPONSE

2021-10-21 Thread Stuart Henderson
On 2021/10/21 15:08, Martijn van Duren wrote: > This one has been bothering me for a while. > > OK? > > martijn@ > > Index: smi.c > === > RCS file: /cvs/src/usr.sbin/snmpd/smi.c,v > retrieving revision 1.28 > diff -u -p -r1.28

snmpd: s/SNMP_C_GETRESP/SNMP_C_RESPONSE

2021-10-21 Thread Martijn van Duren
This one has been bothering me for a while. OK? martijn@ Index: smi.c === RCS file: /cvs/src/usr.sbin/snmpd/smi.c,v retrieving revision 1.28 diff -u -p -r1.28 smi.c --- smi.c 4 Jan 2021 07:59:54 - 1.28 +++ smi.c

Re: isakmpd: prepare for opaque X509_EXTENSION

2021-10-21 Thread Theo Buehler
On Thu, Oct 21, 2021 at 02:29:17PM +0200, Sebastian Benoit wrote: > see the "if (csc == NULL)" error case below. > ugh, thanks. fixed in my tree

Re: isakmpd: prepare for opaque X509_EXTENSION

2021-10-21 Thread Sebastian Benoit
see the "if (csc == NULL)" error case below. otherwise ok Theo Buehler(t...@theobuehler.org) on 2021.10.21 13:45:43 +0200: > On Thu, Oct 21, 2021 at 01:05:18PM +0200, Theo Buehler wrote: > > This is the first of two diffs to prepare isakmpd for upcoming libcrypto > > changes. X509_EXTENSION

Re: isakmpd: prepare for opaque X509_EXTENSION

2021-10-21 Thread Sebastian Benoit
Theo Buehler(t...@theobuehler.org) on 2021.10.21 13:05:18 +0200: > This is the first of two diffs to prepare isakmpd for upcoming libcrypto > changes. X509_EXTENSION will become opaque so we need to use an accessor. > I decided to leave accesses into ASN1_OCTET_STRING as they are for >

Re: ipsec tdb error handling

2021-10-21 Thread Vitaliy Makkoveev
On Thu, Oct 21, 2021 at 12:08:57PM +0200, Alexander Bluhm wrote: > On Sat, Oct 16, 2021 at 12:50:46AM +0300, Vitaliy Makkoveev wrote: > > This time tdb_delete() doesn't kill passed `tdb' but schedules timeout > > to do this. So this `tdb' is logically killed and should be not used, > > but because

Re: xen.4: document how to inform Xen host of IP in VM

2021-10-21 Thread Klemens Nanni
On Thu, Oct 21, 2021 at 01:30:27PM +0200, Denis Fondras wrote: > Document commands used to send VM IP to Xen host. OK kn

Re: Exit status of pkg_add

2021-10-21 Thread Marc Espie
On Tue, Oct 19, 2021 at 10:42:04AM +0900, Yuichiro NAITO wrote: > Following patch changes pkg_add to return a error code, > if a package name is wrong. > > diff --git a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm > b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm > index 7a968cbf05d..39bee874ff1 100644 > ---

Re: isakmpd: prepare for opaque X509_EXTENSION

2021-10-21 Thread Theo Buehler
On Thu, Oct 21, 2021 at 01:05:18PM +0200, Theo Buehler wrote: > This is the first of two diffs to prepare isakmpd for upcoming libcrypto > changes. X509_EXTENSION will become opaque so we need to use an accessor. > I decided to leave accesses into ASN1_OCTET_STRING as they are for > readability

xen.4: document how to inform Xen host of IP in VM

2021-10-21 Thread Denis Fondras
Document commands used to send VM IP to Xen host. Index: xen.4 === RCS file: /cvs/src/share/man/man4/xen.4,v retrieving revision 1.2 diff -u -p -r1.2 xen.4 --- xen.4 21 Jul 2017 18:27:32 - 1.2 +++ xen.4 21 Oct

isakmpd: prepare for opaque X509_EXTENSION

2021-10-21 Thread Theo Buehler
This is the first of two diffs to prepare isakmpd for upcoming libcrypto changes. X509_EXTENSION will become opaque so we need to use an accessor. I decided to leave accesses into ASN1_OCTET_STRING as they are for readability (asn1_string_st is still exposed in OpenSSL's asn1.h). Index: x509.c

Re: unp_internalize() and `unp_lock'

2021-10-21 Thread Alexander Bluhm
On Thu, Oct 21, 2021 at 12:11:09PM +0300, Vitaliy Makkoveev wrote: > A little update for previous diff: `unp_lock' is taken around the whole > fd_getfile(9) loop. OK bluhm@ > Index: sys/kern/uipc_usrreq.c > === > RCS file:

Re: ipsec tdb error handling

2021-10-21 Thread Alexander Bluhm
On Sat, Oct 16, 2021 at 12:50:46AM +0300, Vitaliy Makkoveev wrote: > This time tdb_delete() doesn't kill passed `tdb' but schedules timeout > to do this. So this `tdb' is logically killed and should be not used, > but because the killer timeout is also serialized with netlock we don;t > catch

Re: unp_internalize() and `unp_lock'

2021-10-21 Thread Vitaliy Makkoveev
A little update for previous diff: `unp_lock' is taken around the whole fd_getfile(9) loop. Index: sys/kern/uipc_usrreq.c === RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.149 diff -u -p -r1.149 uipc_usrreq.c ---

Re: patch: nullify v_data with NULL (and not with 0)

2021-10-21 Thread Sebastien Marie
On Wed, Oct 20, 2021 at 10:18:57AM +1100, Jonathan Gray wrote: > On Tue, Oct 19, 2021 at 07:37:36AM -0600, Todd C. Miller wrote: > > On Tue, 19 Oct 2021 18:08:04 +1100, Jonathan Gray wrote: > > > > > There are many others along those lines in the kernel, for example > > > sparse complains about

Re: libagentx: Fix thumbling after free

2021-10-21 Thread Martijn van Duren
ping On Wed, 2021-09-01 at 22:51 +0200, Martijn van Duren wrote: > Bluhm asked me to rethink the freeing strategy. > Here's the end result. > > On Mon, 2021-08-30 at 12:03 +0200, Martijn van Duren wrote: > > I missed this one before, since apparently it doesn't show up with > > MALLOC_OPTIONS

Re: libagentx(3): Don't deallocate dynamic indices

2021-10-21 Thread Martijn van Duren
ping On Thu, 2021-09-09 at 21:49 +0200, Martijn van Duren wrote: > When calling agentx_index_start we short-circuit the call to the agentx > master when the index is dynamic. This is in accordance with the RFC. > At the moment we don't do the same thing when calling > agentx_index_close. Diff

Re: snmpd(8): Log correct engineid

2021-10-21 Thread Martijn van Duren
ping On Sun, 2021-09-26 at 10:22 +0200, Martijn van Duren wrote: > ober_get_nstring writes a pointer to buf and does not overwrite the > content of buf itself. So pushing an array in there will result in it > only writing the pointer address to the array, which is not exactly what > we want to

Re: ober_oid_cmp: copy over ax_oid_cmp logic

2021-10-21 Thread Martijn van Duren
ping On Fri, 2021-10-01 at 16:42 +0200, Martijn van Duren wrote: > Right now ober_oid_cmp has inverted logic compared to other *cmp > functions. Specifically values greater than 0 are returned when > a is smaller than b. > Additionally, the value of 2 is only used b is a child of a, but > -1 is