Re: libtls, smtpd: switch to EC_KEY_METHOD
On Thu, May 25, 2023 at 07:23:48PM +0200, Omar Polo wrote: > As far as I (and grep) can see, smtpd and the part it needs in libtls > are the only user of ECDSA_METHOD in tree. Yes, nothing else should be using this anymore, including ports. ECDSA_METHOD and ECDH_METHOD were merged into EC_KEY_METHOD and removed as part of the OpenSSL 1.1 API transition. We still have the former two because removal is blocked by smtpd, so this diff is definitely a most welcome step in the right direction. >From the libcrypto perspective this paves the way for removal of a still exposed public struct and unneded API and will subsequently allow more internal simplifications. In particular, it should allow us to clean up and get rid of the messy split between ec/ecdsa/ecdh. > What I've understood talking with tb (and apologizes if I'm making > mistakes) is that ECDSA_METHOD was replaced with EC_KEY_METHOD. "We" > inherited the former, it got used in smtpd, and then added the latter > for openssh. smtpd and libtls were never updated to these new shiny > APIs. This is also correct. We (markus) added EC_KEY_METHOD to libcrypto to allow OpenSSH to switch to OpenSSL 1.1 API which simplified their portable efforts. (Now EC_KEY_METHOD is deprecated in OpenSSL 3 thanks to the new provider things, but one step at a time...) > Diff below is 99% gilles' work on OpenSMTPD-portable. I only had to > tweak EC_KEY_METHOD_get_compute_key() since the compute key function > has a different signature in LibreSSL than OpenSSL, and some minor > style nits. Addressing this signature difference will something to look into later. > While I've tested it (on localhost and between vms), and I'm also > running it on linux and freebsd with OpenSSL 3.1 and 1.1 respectively > via OpenSMTPD-portable, additional testing on busier mx is greatly > appreciated. I don't expect regressions however. It should also be noted that libretls carries a similar diff. > > To test: > > - apply the diff > - rebuild and reinstall libtls > - rebuild, reinstall and restart smtpd > > It doesn't change the libtls ABI (tls_signer_ecdsa_method is internal) > and the parts it touches are only used by smtpd AFAIK, so no need to > rebuild anything else. I am ok with the diff, but some more testing in the real world would be nice.
Re: pfioctl: drop net lock from SIOC{S,G}LIMIT
Hello, On Thu, May 25, 2023 at 07:14:54AM +, Klemens Nanni wrote: > On Thu, May 25, 2023 at 03:28:45AM +, Klemens Nanni wrote: > > On Thu, May 25, 2023 at 03:20:04AM +, Klemens Nanni wrote: > > > pfsync_in_bus() looks like the only place where the static array > > > pf_pool_limits[] is accessed without the pf lock, so grab it there. > > > > > > Limits themselves are protected by the pf lock and pool(9)s are never > > > destroyed and have builtint per-pool locks, so the net lock is not > > > needed. > > > > > > (pf_pool_limits[] access in DIOCXCOMMIT remains under pf *and net* lock > > > until the rest in there gets pulled out of the net lock.) > > > > > > Feedback? OK? > > > > Correct diff without typo and with missing locking comment. > > Diffing pfvar.h instead of pfvar_priv.h helps to get the comment hunk... looks good to me. OK sashan
Re: ix(4): LRO forwarding
On Wed, May 24, 2023 at 05:28:58PM +0200, Alexander Bluhm wrote:
> On Tue, May 23, 2023 at 02:14:57PM +0200, Jan Klemkow wrote:
> > Hi,
> >
> > This diff sets needed offloading flags and the calculated mss to LRO
> > mbufs in ix(4). Thus, we can forward this packets and process them via
> > tcp_if_output_tso(). This diff also uses tcp_if_output_tso() in
> > ip6_forward().
> >
> > I tested the ip6_forward path via the address family transition in pf:
> >
> > pass in inet from 192.168.1.1 to 192.168.13.2 af-to \
> > inet6 from fc00:13::1 to fc00:13::2
> >
> > ok?
>
> crashes during my tests with lro turned on. Looks like devision
> by zero.
I added a check, that avoids the TSO flags if mss it zero. Thus, we
avoid a division by zero in later TSO processing.
ok?
Thanks,
Jan
Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.196
diff -u -p -r1.196 if_ix.c
--- dev/pci/if_ix.c 23 May 2023 09:16:16 - 1.196
+++ dev/pci/if_ix.c 25 May 2023 20:02:06 -
@@ -3257,13 +3257,40 @@ ixgbe_rxeof(struct rx_ring *rxr)
if (sendmp->m_pkthdr.ph_mss > 0) {
struct ether_extracted ext;
+ uint64_t hlen;
uint16_t pkts = sendmp->m_pkthdr.ph_mss;
+ /* Calculate header size. */
ether_extract_headers(sendmp, &ext);
- if (ext.tcp)
+ hlen = sizeof(*ext.eh);
+ if (ext.ip4) {
+ hlen += ext.ip4->ip_hl << 2;
+ } else if (ext.ip6) {
+ if (ext.ip6->ip6_nxt == IPPROTO_TCP)
+ hlen += sizeof(*ext.ip6);
+ else
+ tcpstat_inc(tcps_inbadlro);
+ }
+ if (ext.tcp) {
tcpstat_inc(tcps_inhwlro);
- else
+ hlen += ext.tcp->th_off << 2;
+ } else {
tcpstat_inc(tcps_inbadlro);
+ }
+
+ /*
+* If we gonna forward this packet, we have to
+* mark it as TSO, recalculate the TCP checksum
+* and set a correct mss.
+*/
+ sendmp->m_pkthdr.ph_mss =
+ (sendmp->m_pkthdr.len - hlen) / pkts;
+
+ if (sendmp->m_pkthdr.ph_mss != 0) {
+ SET(sendmp->m_pkthdr.csum_flags,
+ M_TCP_CSUM_OUT | M_TCP_TSO);
+ }
+
tcpstat_add(tcps_inpktlro, pkts);
}
Index: netinet6/ip6_forward.c
===
RCS file: /cvs/src/sys/netinet6/ip6_forward.c,v
retrieving revision 1.109
diff -u -p -r1.109 ip6_forward.c
--- netinet6/ip6_forward.c 5 Apr 2023 13:56:31 - 1.109
+++ netinet6/ip6_forward.c 25 May 2023 20:03:06 -
@@ -63,8 +63,10 @@
#include
#include
#include
-#include
#endif
+#include
+#include
+#include
/*
* Forward a packet. If some error occurs return the sender
@@ -316,7 +318,11 @@ reroute:
goto reroute;
}
#endif
- in6_proto_cksum_out(m, ifp);
+
+ error = tcp_if_output_tso(ifp, &m, sin6tosa(sin6), rt, IFCAP_TSOv6,
+ ifp->if_mtu);
+ if (error || m == NULL)
+ goto freecopy;
/* Check the size after pf_test to give pf a chance to refragment. */
if (m->m_pkthdr.len > ifp->if_mtu) {
@@ -326,6 +332,8 @@ reroute:
m_freem(m);
goto out;
}
+
+ in6_proto_cksum_out(m, ifp);
error = ifp->if_output(ifp, m, sin6tosa(sin6), rt);
if (error) {
libtls, smtpd: switch to EC_KEY_METHOD
As far as I (and grep) can see, smtpd and the part it needs in libtls
are the only user of ECDSA_METHOD in tree.
What I've understood talking with tb (and apologizes if I'm making
mistakes) is that ECDSA_METHOD was replaced with EC_KEY_METHOD. "We"
inherited the former, it got used in smtpd, and then added the latter
for openssh. smtpd and libtls were never updated to these new shiny
APIs.
Diff below is 99% gilles' work on OpenSMTPD-portable. I only had to
tweak EC_KEY_METHOD_get_compute_key() since the compute key function
has a different signature in LibreSSL than OpenSSL, and some minor
style nits.
While I've tested it (on localhost and between vms), and I'm also
running it on linux and freebsd with OpenSSL 3.1 and 1.1 respectively
via OpenSMTPD-portable, additional testing on busier mx is greatly
appreciated. I don't expect regressions however.
To test:
- apply the diff
- rebuild and reinstall libtls
- rebuild, reinstall and restart smtpd
It doesn't change the libtls ABI (tls_signer_ecdsa_method is internal)
and the parts it touches are only used by smtpd AFAIK, so no need to
rebuild anything else.
Thanks!
diff a6995f7d4e4b475f514b46014b476ba2fb99e6ca
15eb8637ab039139400e655284e2e2d8ca898a03
commit - a6995f7d4e4b475f514b46014b476ba2fb99e6ca
commit + 15eb8637ab039139400e655284e2e2d8ca898a03
blob - 989339dc033f3c231659a9a37946c453d03509da
blob + f6ba5760737d40ec5250a21c0bdcc7446073111f
--- lib/libtls/tls.c
+++ lib/libtls/tls.c
@@ -389,7 +389,7 @@ tls_keypair_setup_pkey(struct tls *ctx, struct tls_key
tls_keypair_setup_pkey(struct tls *ctx, struct tls_keypair *keypair, EVP_PKEY
*pkey)
{
RSA_METHOD *rsa_method;
- ECDSA_METHOD *ecdsa_method;
+ EC_KEY_METHOD *ecdsa_method;
RSA *rsa = NULL;
EC_KEY *eckey = NULL;
int ret = -1;
@@ -427,15 +427,15 @@ tls_keypair_setup_pkey(struct tls *ctx, struct tls_key
break;
case EVP_PKEY_EC:
if ((eckey = EVP_PKEY_get1_EC_KEY(pkey)) == NULL ||
- ECDSA_set_ex_data(eckey, 0, keypair->pubkey_hash) == 0) {
+ EC_KEY_set_ex_data(eckey, 0, keypair->pubkey_hash) == 0) {
tls_set_errorx(ctx, "EC key setup failure");
goto err;
}
if (ctx->config->sign_cb != NULL) {
ecdsa_method = tls_signer_ecdsa_method();
if (ecdsa_method == NULL ||
- ECDSA_set_ex_data(eckey, 1, ctx->config) == 0 ||
- ECDSA_set_method(eckey, ecdsa_method) == 0) {
+ EC_KEY_set_ex_data(eckey, 1, ctx->config) == 0 ||
+ EC_KEY_set_method(eckey, ecdsa_method) == 0) {
tls_set_errorx(ctx, "failed to setup EC key");
goto err;
}
blob - f4c23f64e67f2f45056467dbdffe84960cdc4e2c
blob + f53b6c800941a746425ba01ffe26daf4c236bc37
--- lib/libtls/tls_internal.h
+++ lib/libtls/tls_internal.h
@@ -298,7 +298,7 @@ ECDSA_METHOD *tls_signer_ecdsa_method(void);
int tls_password_cb(char *_buf, int _size, int _rwflag, void *_u);
RSA_METHOD *tls_signer_rsa_method(void);
-ECDSA_METHOD *tls_signer_ecdsa_method(void);
+EC_KEY_METHOD *tls_signer_ecdsa_method(void);
#define TLS_PADDING_NONE 0
#define TLS_PADDING_RSA_PKCS1 1
blob - f6005d3e07ac6423098c9d35f1f03993cd4dfd88
blob + 93777aa3253fdacbc28abc852f8e660fbd882b01
--- lib/libtls/tls_signer.c
+++ lib/libtls/tls_signer.c
@@ -419,26 +419,21 @@ ECDSA_METHOD *
return (NULL);
}
-ECDSA_METHOD *
+EC_KEY_METHOD *
tls_signer_ecdsa_method(void)
{
- static ECDSA_METHOD *ecdsa_method = NULL;
+ static EC_KEY_METHOD *ecdsa_method = NULL;
pthread_mutex_lock(&signer_method_lock);
if (ecdsa_method != NULL)
goto out;
- ecdsa_method = calloc(1, sizeof(*ecdsa_method));
+ ecdsa_method = EC_KEY_METHOD_new(NULL);
if (ecdsa_method == NULL)
goto out;
- ecdsa_method->ecdsa_do_sign = tls_ecdsa_do_sign;
- ecdsa_method->name = strdup("libtls ECDSA method");
- if (ecdsa_method->name == NULL) {
- free(ecdsa_method);
- ecdsa_method = NULL;
- }
+ EC_KEY_METHOD_set_sign(ecdsa_method, NULL, NULL, tls_ecdsa_do_sign);
out:
pthread_mutex_unlock(&signer_method_lock);
blob - c0c918601e741019515da6c83a6874fb9f552a1a
blob + f5d81174b597f8368b45719833d92772e49e78db
--- usr.sbin/smtpd/ca.c
+++ usr.sbin/smtpd/ca.c
@@ -47,10 +47,17 @@ static int rsae_keygen(RSA *, int, BIGNUM *, BN_GENCB
static int rsae_init(RSA *);
static int rsae_finish(RSA *);
static int rsae_keygen(RSA *, int, BIGNUM *, BN_GENCB *);
+static int ecdsae_keygen(EC_KEY *);
+static int ecdsae_compute_key(void *, size_t, const EC_POINT *, EC_KEY *,
+ void *(*)(const
Re: userdel: remove login group for =uid
On Thu, 25 May 2023 06:54:08 +0100, Stuart Henderson wrote: > > As Aisha pointed out, pkg_delete hints could be updated too. > > If that is done, pkg_delete would need to check whether the group will > actually get removed i.e. make sure that no other user has been added > to the group. If pkg_delete is going to rely on userdel removing the group I think I need to remove the "=uid" check in my userdel patch. In other words, the primary group will always be removed if it matches the username, the uid and gid are the same and the group has no other members. That is also a lot easier to document. - todd
Re: bgpd fix for possible crash in SE
On Thu, May 25, 2023 at 02:20:37PM +0100, Stuart Henderson wrote: > On 2023/05/25 15:06, Claudio Jeker wrote: > > sthen@ reported a bgpd SE crash to me and after inspection of the report > > it looks like he managed to trigger a mistake in session_process_msg(). > > When for example a NOTIFICATION message is received then the state change > > clears the rbuf. Now normally the for loop starts over afterwards and the > > if (p->rbuf == NULL) at the top causes the function to return. > > In his case the peer had enough messages queued that the if (++processed > > > MSG_PROCESS_LIMIT) limit triggered after the NOTIFICATION was processed. > > This hits a break from the for loop and the code at the end of the > > function adjusting the rbuf trips over the NULL rbuf pointer. > > > > This can be fixed in many ways, I decided to just check at the end of the > > loop that rbuf is still valid. > > Thanks for looking into this. OK. > > > Triggering this bug is not trivial so it is hard test but the problem is > > obvious. > > indeed, I don't think I have hit this one at all before. > > Running sessions over routes maintained by ospf6d seems a fairly > good way to trigger a number of issues ;) I do run ospf6d on some systems but it seems my setup is too small to trigger all those strange issues. :( -- :wq Claudio
Re: bgpd fix for possible crash in SE
On 2023/05/25 15:06, Claudio Jeker wrote:
> sthen@ reported a bgpd SE crash to me and after inspection of the report
> it looks like he managed to trigger a mistake in session_process_msg().
> When for example a NOTIFICATION message is received then the state change
> clears the rbuf. Now normally the for loop starts over afterwards and the
> if (p->rbuf == NULL) at the top causes the function to return.
> In his case the peer had enough messages queued that the if (++processed >
> MSG_PROCESS_LIMIT) limit triggered after the NOTIFICATION was processed.
> This hits a break from the for loop and the code at the end of the
> function adjusting the rbuf trips over the NULL rbuf pointer.
>
> This can be fixed in many ways, I decided to just check at the end of the
> loop that rbuf is still valid.
Thanks for looking into this. OK.
> Triggering this bug is not trivial so it is hard test but the problem is
> obvious.
indeed, I don't think I have hit this one at all before.
Running sessions over routes maintained by ospf6d seems a fairly
good way to trigger a number of issues ;)
> :wq Claudio
>
> Index: session.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
> retrieving revision 1.444
> diff -u -p -r1.444 session.c
> --- session.c 5 May 2023 07:28:08 - 1.444
> +++ session.c 25 May 2023 09:32:11 -
> @@ -1998,6 +1998,8 @@ session_process_msg(struct peer *p)
> }
> }
>
> + if (p->rbuf == NULL)
> + return;
> if (rpos < av) {
> left = av - rpos;
> memmove(&p->rbuf->buf, p->rbuf->buf + rpos, left);
>
Re: bgpd fix for possible crash in SE
On Thu, May 25, 2023 at 03:06:05PM +0200, Claudio Jeker wrote:
> sthen@ reported a bgpd SE crash to me and after inspection of the report
> it looks like he managed to trigger a mistake in session_process_msg().
> When for example a NOTIFICATION message is received then the state change
> clears the rbuf. Now normally the for loop starts over afterwards and the
> if (p->rbuf == NULL) at the top causes the function to return.
> In his case the peer had enough messages queued that the if (++processed >
> MSG_PROCESS_LIMIT) limit triggered after the NOTIFICATION was processed.
> This hits a break from the for loop and the code at the end of the
> function adjusting the rbuf trips over the NULL rbuf pointer.
>
> This can be fixed in many ways, I decided to just check at the end of the
> loop that rbuf is still valid.
>
> Triggering this bug is not trivial so it is hard test but the problem is
> obvious.
Indeed.
ok
> --
> :wq Claudio
>
> Index: session.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
> retrieving revision 1.444
> diff -u -p -r1.444 session.c
> --- session.c 5 May 2023 07:28:08 - 1.444
> +++ session.c 25 May 2023 09:32:11 -
> @@ -1998,6 +1998,8 @@ session_process_msg(struct peer *p)
> }
> }
>
> + if (p->rbuf == NULL)
> + return;
> if (rpos < av) {
> left = av - rpos;
> memmove(&p->rbuf->buf, p->rbuf->buf + rpos, left);
>
bgpd fix for possible crash in SE
sthen@ reported a bgpd SE crash to me and after inspection of the report
it looks like he managed to trigger a mistake in session_process_msg().
When for example a NOTIFICATION message is received then the state change
clears the rbuf. Now normally the for loop starts over afterwards and the
if (p->rbuf == NULL) at the top causes the function to return.
In his case the peer had enough messages queued that the if (++processed >
MSG_PROCESS_LIMIT) limit triggered after the NOTIFICATION was processed.
This hits a break from the for loop and the code at the end of the
function adjusting the rbuf trips over the NULL rbuf pointer.
This can be fixed in many ways, I decided to just check at the end of the
loop that rbuf is still valid.
Triggering this bug is not trivial so it is hard test but the problem is
obvious.
--
:wq Claudio
Index: session.c
===
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.444
diff -u -p -r1.444 session.c
--- session.c 5 May 2023 07:28:08 - 1.444
+++ session.c 25 May 2023 09:32:11 -
@@ -1998,6 +1998,8 @@ session_process_msg(struct peer *p)
}
}
+ if (p->rbuf == NULL)
+ return;
if (rpos < av) {
left = av - rpos;
memmove(&p->rbuf->buf, p->rbuf->buf + rpos, left);
Re: smtpd.h: drop two unused define
On 5/25/23 11:18, Omar Polo wrote: both values have been unused for quite some time. last PROC_COUNT use was removed in 'Implement the fork+exec pattern in smtpd' by eric@ in 2016. I've checked the other #defines and they seem to be all used, except these two. ok? sure, ok giovanni@ Cheers Giovanni diff /usr/src commit - 6f5cff98d90c274a5222db1a9bd17d5c26da7920 path + /usr/src blob - 125a6a5dfbe176065b9fb3835363ed47d32a94ae file + usr.sbin/smtpd/smtpd.h --- usr.sbin/smtpd/smtpd.h +++ usr.sbin/smtpd/smtpd.h @@ -45,10 +45,7 @@ #define CONF_FILE "/etc/mail/smtpd.conf" #define MAILNAME_FILE "/etc/mail/mailname" -#define CA_FILE "/etc/ssl/cert.pem" -#define PROC_COUNT 7 - #define MAX_HOPS_COUNT 100 #define DEFAULT_MAX_BODY_SIZE (35*1024*1024)
Re: smtpd.h: drop two unused define
On Thu, May 25, 2023 at 11:18:00AM +0200, Omar Polo wrote: > both values have been unused for quite some time. last PROC_COUNT use > was removed in 'Implement the fork+exec pattern in smtpd' by eric@ in > 2016. > > I've checked the other #defines and they seem to be all used, except > these two. > > ok? ok. The last CA_FILE use was removed with cert.c two years ago. > > diff /usr/src > commit - 6f5cff98d90c274a5222db1a9bd17d5c26da7920 > path + /usr/src > blob - 125a6a5dfbe176065b9fb3835363ed47d32a94ae > file + usr.sbin/smtpd/smtpd.h > --- usr.sbin/smtpd/smtpd.h > +++ usr.sbin/smtpd/smtpd.h > @@ -45,10 +45,7 @@ > > #define CONF_FILE "/etc/mail/smtpd.conf" > #define MAILNAME_FILE "/etc/mail/mailname" > -#define CA_FILE "/etc/ssl/cert.pem" > > -#define PROC_COUNT7 > - > #define MAX_HOPS_COUNT100 > #define DEFAULT_MAX_BODY_SIZE (35*1024*1024) > >
Re: Virtio fix for testing
On Wed, May 24, 2023 at 08:50:26PM +0200, Stefan Fritsch wrote: > I forgot to mention that no stress test is necessary. If it boots and the > virtio devices work at all, that should be enough. amd64 bsd.mp keeps working with disks and network interfaces behind VirtIO, no dmesg or behaviour change inside OpenBSD VMM and Linux KVM. Linux KVM dmesg below: OpenBSD 7.3-current (GENERIC.MP) #3: Thu May 25 15:05:23 +04 2023 k...@atar.my.domain:/sys/arch/amd64/compile/GENERIC.MP real mem = 1056788480 (1007MB) avail mem = 1005174784 (958MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5ab0 (10 entries) bios0: vendor SeaBIOS version "1.14.0-2" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: ACPI 1.0 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC WAET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC 73F3 16-Core Processor, 3500.37 MHz, 19-01-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,WAITPKG,IBRS,IBPB,STIBP,SSBD,IBPB,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD EPYC 73F3 16-Core Processor, 3500.93 MHz, 19-01-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache cpu1: 512KB 64b/line 16-way L2 cache cpu1: smt 0, core 0, package 1 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0 com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com0: console acpicmos0 at acpi0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9 iic0 at piixpm0 vga1 at pci0 dev 2 function 0 "Red Hat QXL Video" rev 0x05 wsdisplay at vga1 not configured virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio0: address 52:54:00:56:32:db virtio0: msix shared uhci0 at pci0 dev 4 function 0 "Intel 82801I USB" rev 0x03: apic 0 int 11 uhci1 at pci0 dev 4 function 1 "Intel 82801I USB" rev 0x03: apic 0 int 10 uhci2 at pci0 dev 4 function 2 "Intel 82801I USB" rev 0x03: apic 0 int 10 ehci0 at pci0 dev 4 function 7 "Intel 82801I USB" rev 0x03: apic 0 int 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Console" rev 0x00 virtio1: no matching child driver; not configured virtio2 at pci0 dev 6 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk0 at virtio2 scsibus1 at vioblk0: 1 targets sd0 at scsibus1 targ 0 lun 0: sd0: 5120MB, 512 bytes/sector, 10485760 sectors virtio2: msix per-VQ virtio3 at pci0 dev 7 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk1 at virtio3 scsibus2 at vioblk1: 1 targets sd1 at scsibus2 targ 0 lun 0: sd1: 5MB, 512 bytes/sector, 11392 sectors, readonly virtio3: msix per-VQ virtio4 at pci0 dev 8 function 0 "Qumranet Virtio Memory Balloon" rev 0x00 viomb0 at virtio4 virtio4: apic 0 int 11 virtio5 at pci0 dev 9 function 0 "Qumranet Virtio Network" rev 0x00 vio1 at virtio5: address 52:54:00:93:3a:c1 virtio5: msix shared isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port
smtpd.h: drop two unused define
both values have been unused for quite some time. last PROC_COUNT use was removed in 'Implement the fork+exec pattern in smtpd' by eric@ in 2016. I've checked the other #defines and they seem to be all used, except these two. ok? diff /usr/src commit - 6f5cff98d90c274a5222db1a9bd17d5c26da7920 path + /usr/src blob - 125a6a5dfbe176065b9fb3835363ed47d32a94ae file + usr.sbin/smtpd/smtpd.h --- usr.sbin/smtpd/smtpd.h +++ usr.sbin/smtpd/smtpd.h @@ -45,10 +45,7 @@ #define CONF_FILE "/etc/mail/smtpd.conf" #define MAILNAME_FILE "/etc/mail/mailname" -#define CA_FILE "/etc/ssl/cert.pem" -#define PROC_COUNT 7 - #define MAX_HOPS_COUNT 100 #defineDEFAULT_MAX_BODY_SIZE (35*1024*1024)
Re: 443 udp for /etc/services
... If IANA say it (and Stuart says it) ... then .. Im not going to contradict :) (or at least persist in contradicting Stuart :) Thanks for the clarificaiton... On Thu, 25 May 2023 at 10:38, Stuart Henderson wrote: > > On 2023/05/25 10:29, Tom Smyth wrote: > > Folks, > > > > Can I suggest calling it quic as opposed to https > > I think it should follow the name in the IANA registry which uses https. > > > do we want PF Firewal to match https for TCP and UDP (for traditional) > > servers that only require https TCP ... > > PF requires that the protocol is specified, it doesn't assume TCP or UDP > based on the /etc/services entry. > -- Kindest regards, Tom Smyth.
Re: 443 udp for /etc/services
On 2023/05/25 10:29, Tom Smyth wrote: > Folks, > > Can I suggest calling it quic as opposed to https I think it should follow the name in the IANA registry which uses https. > do we want PF Firewal to match https for TCP and UDP (for traditional) > servers that only require https TCP ... PF requires that the protocol is specified, it doesn't assume TCP or UDP based on the /etc/services entry.
Re: 443 udp for /etc/services
Folks, Can I suggest calling it quic as opposed to https do we want PF Firewal to match https for TCP and UDP (for traditional) servers that only require https TCP ... Just a thought On Thu, 25 May 2023 at 10:27, Stuart Henderson wrote: > > - Forwarded message from Renaud Allard - > > From: Renaud Allard > Date: Thu, 25 May 2023 10:48:24 +0200 > To: po...@openbsd.org > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 > Thunderbird/102.9.0 > Subject: Re: http3 in nginx > > > > On 5/24/23 18:01, Theo Buehler wrote: > > This isn't intended for commit, but if anyone wants to play with quic > > in nginx, this diff is all that's needed. Build, then install the main > > package. The config is documented here: > > > > https://nginx.org/en/docs/http/ngx_http_v3_module.html > > > > Works for me. > > > > It might be a good idea to add this to /etc/services too > > https 443udphttp protocol over TLS/SSL > > - - > > while I would not use quite that description (it comes from the > IANA registry, but afaik there is no way this is going to work over > anything old enough to be called SSL), I think it is correct to add > this, we do want it populated in net.inet.udp.baddynamic. > > https://www.rfc-editor.org/rfc/rfc9110.html > > ok? > > > Index: services > === > RCS file: /cvs/src/etc/services,v > retrieving revision 1.104 > diff -u -p -r1.104 services > --- services2 Mar 2022 11:43:52 - 1.104 > +++ services25 May 2023 09:14:49 - > @@ -118,6 +118,7 @@ svrloc 427/tcp # > Server Location > svrloc 427/udp > nnsp 433/tcp usenet # Network News Transfer > https 443/tcp # secure http (TLS) > +https 443/udp # secure http (TLS) > snpp 444/tcp # Simple Network Paging > Protocol > microsoft-ds 445/tcp # Microsoft-DS > microsoft-ds 445/udp # Microsoft-DS > -- Kindest regards, Tom Smyth.
443 udp for /etc/services
- Forwarded message from Renaud Allard - From: Renaud Allard Date: Thu, 25 May 2023 10:48:24 +0200 To: po...@openbsd.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: http3 in nginx On 5/24/23 18:01, Theo Buehler wrote: > This isn't intended for commit, but if anyone wants to play with quic > in nginx, this diff is all that's needed. Build, then install the main > package. The config is documented here: > > https://nginx.org/en/docs/http/ngx_http_v3_module.html > > Works for me. > It might be a good idea to add this to /etc/services too https 443udphttp protocol over TLS/SSL - - while I would not use quite that description (it comes from the IANA registry, but afaik there is no way this is going to work over anything old enough to be called SSL), I think it is correct to add this, we do want it populated in net.inet.udp.baddynamic. https://www.rfc-editor.org/rfc/rfc9110.html ok? Index: services === RCS file: /cvs/src/etc/services,v retrieving revision 1.104 diff -u -p -r1.104 services --- services2 Mar 2022 11:43:52 - 1.104 +++ services25 May 2023 09:14:49 - @@ -118,6 +118,7 @@ svrloc 427/tcp # Server Location svrloc 427/udp nnsp 433/tcp usenet # Network News Transfer https 443/tcp # secure http (TLS) +https 443/udp # secure http (TLS) snpp 444/tcp # Simple Network Paging Protocol microsoft-ds 445/tcp # Microsoft-DS microsoft-ds 445/udp # Microsoft-DS
installer: simplify yes/no answer handling
ask_yn() returns 0/1 for no/yes, so almost all users in install.sub use
the same 'ask_yn && do-it', 'ask_yn || skip' idioms.
Adjust two MD calls accordingly.
OK?
Index: amd64/common/install.md
===
RCS file: /cvs/src/distrib/amd64/common/install.md,v
retrieving revision 1.60
diff -u -p -r1.60 install.md
--- amd64/common/install.md 26 Apr 2023 22:45:32 - 1.60
+++ amd64/common/install.md 22 May 2023 21:25:52 -
@@ -77,8 +77,7 @@ md_prep_fdisk() {
return ;;
[gG]*)
if [[ $MDEFI != y ]]; then
- ask_yn "An EFI/GPT disk may not boot. Proceed?"
- [[ $resp == n ]] && continue
+ ask_yn "An EFI/GPT disk may not boot. Proceed?"
|| continue
fi
echo -n "Setting OpenBSD GPT partition to whole
$_disk..."
Index: macppc/ramdisk/install.md
===
RCS file: /cvs/src/distrib/macppc/ramdisk/install.md,v
retrieving revision 1.77
diff -u -p -r1.77 install.md
--- macppc/ramdisk/install.md 27 Mar 2023 19:43:36 - 1.77
+++ macppc/ramdisk/install.md 10 May 2023 20:02:15 -
@@ -54,8 +54,7 @@ WARNING: Putting an MBR partition table
$(pdisk -l $_disk)
__EOT
- ask_yn "Are you *sure* you want an MBR partition table on
$_disk?"
- [[ $resp == n ]] && return 1
+ ask_yn "Are you *sure* you want an MBR partition table on
$_disk?" || return 1
fi
while :; do
Re: pfioctl: drop net lock from SIOC{S,G}LIMIT
On Thu, May 25, 2023 at 03:28:45AM +, Klemens Nanni wrote:
> On Thu, May 25, 2023 at 03:20:04AM +, Klemens Nanni wrote:
> > pfsync_in_bus() looks like the only place where the static array
> > pf_pool_limits[] is accessed without the pf lock, so grab it there.
> >
> > Limits themselves are protected by the pf lock and pool(9)s are never
> > destroyed and have builtint per-pool locks, so the net lock is not
> > needed.
> >
> > (pf_pool_limits[] access in DIOCXCOMMIT remains under pf *and net* lock
> > until the rest in there gets pulled out of the net lock.)
> >
> > Feedback? OK?
>
> Correct diff without typo and with missing locking comment.
Diffing pfvar.h instead of pfvar_priv.h helps to get the comment hunk...
Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.315
diff -u -p -r1.315 if_pfsync.c
--- if_pfsync.c 18 May 2023 12:10:04 - 1.315
+++ if_pfsync.c 25 May 2023 03:27:29 -
@@ -1009,10 +1009,12 @@ pfsync_in_bus(caddr_t buf, int len, int
switch (bus->status) {
case PFSYNC_BUS_START:
+ PF_LOCK();
timeout_add(&sc->sc_bulkfail_tmo, 4 * hz +
pf_pool_limits[PF_LIMIT_STATES].limit /
((sc->sc_if.if_mtu - PFSYNC_MINPKT) /
sizeof(struct pfsync_state)));
+ PF_UNLOCK();
DPFPRINTF(LOG_INFO, "received bulk update start");
break;
@@ -2037,10 +2039,12 @@ pfsync_request_full_update(struct pfsync
#endif
pfsync_sync_ok = 0;
DPFPRINTF(LOG_INFO, "requesting bulk update");
+ PF_LOCK();
timeout_add(&sc->sc_bulkfail_tmo, 4 * hz +
pf_pool_limits[PF_LIMIT_STATES].limit /
((sc->sc_if.if_mtu - PFSYNC_MINPKT) /
sizeof(struct pfsync_state)));
+ PF_UNLOCK();
pfsync_request_update(0, 0);
}
}
Index: pfvar.h
===
RCS file: /cvs/src/sys/net/pfvar.h,v
retrieving revision 1.530
diff -u -p -r1.530 pfvar.h
--- pfvar.h 28 Apr 2023 14:08:38 - 1.530
+++ pfvar.h 13 May 2023 16:23:27 -
@@ -1795,10 +1795,16 @@ const struct pfq_ops
extern struct pf_statuspf_status;
extern struct pool pf_frent_pl, pf_frag_pl;
+/*
+ * Protection/ownership of pf_pool_limit:
+ * I immutable after pfattach()
+ * p pf_lock
+ */
+
struct pf_pool_limit {
- void*pp;
- unsigned limit;
- unsigned limit_new;
+ void*pp;/* [I] */
+ unsigned limit; /* [p] */
+ unsigned limit_new; /* [p] */
};
extern struct pf_pool_limitpf_pool_limits[PF_LIMIT_MAX];
Index: pf_ioctl.c
===
RCS file: /cvs/src/sys/net/pf_ioctl.c,v
retrieving revision 1.404
diff -u -p -r1.404 pf_ioctl.c
--- pf_ioctl.c 11 May 2023 12:36:22 - 1.404
+++ pf_ioctl.c 24 May 2023 13:48:52 -
@@ -2094,44 +2094,37 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
error = EINVAL;
goto fail;
}
- NET_LOCK();
PF_LOCK();
pl->limit = pf_pool_limits[pl->index].limit;
PF_UNLOCK();
- NET_UNLOCK();
break;
}
case DIOCSETLIMIT: {
struct pfioc_limit *pl = (struct pfioc_limit *)addr;
- NET_LOCK();
PF_LOCK();
if (pl->index < 0 || pl->index >= PF_LIMIT_MAX) {
error = EINVAL;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
if (((struct pool *)pf_pool_limits[pl->index].pp)->pr_nout >
pl->limit) {
error = EBUSY;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
/* Fragments reference mbuf clusters. */
if (pl->index == PF_LIMIT_FRAGS && pl->limit > nmbclust) {
error = EINVAL;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
pf_pool_limits[pl->index].limit_new = pl->limit;
pl->limit = pf_pool_limits[pl->index].limit;
PF_UNLOCK();
- NET_UNLOCK();
break;
}
