Re: patch: profiling using utrace(2) (compatible with pledge and unveil)

2023-05-08 Thread Job Snijders
Hi Sebastien,

Super super interesting stuff!

On Tue, Apr 11, 2023 at 09:28:31AM +0200, Sebastien Marie wrote:
> ## compile and collect profil information (-tu option on ktrace is optional)
> $ cc -static -pg test.c
> $ ktrace -di -tu ./a.out
> 
> ## get gmon.out file
> $ kdump -u gmon.out | unvis > gmon.out
> 
> ## get gmon.out.$name.$pid for multiple processes
> ##  - first get pid process-name
> ##  - extract each gmon.out for each pid and store in "gmon.out.$name.$pid" 
> file
> $ kdump -tu | sed -ne 's/^ \([0-9][0-9]*\) \([^ ]*\) .*/\1 \2/p' | sort -u \
>   | while read pid name; do kdump -u gmon.out -p $pid | unvis > 
> gmon.out.$name.$pid ; done
> 
> kdump diff from otto@ mallocdump is need for 'kdump -u label'.
> 
> Feedback would be appreciated.

I used your diff to get more insight into the performance profile of
rpki-client. I always considered profiling rpki-client a bit tricky
because of multiple processes (privsep) and pledge, but with your diff
it suddenly became quite easy.

I profiled a workload that's easy to reliably reproduce. Then I used
gprof2dot to make images with and without a diff intended to improve
performance (the diff reduces duplicate work being done in the X.509
validator).

With https://marc.info/?l=openbsd-tech&m=168354732821734&w=2 applied:
main process: https://sobornost.net/~job/main.png
parser process: https://sobornost.net/~job/parser.png

Without that flags |= X509_V_FLAG_PARTIAL_CHAIN diff:
https://sobornost.net/~job/main-without-partialchains.png
https://sobornost.net/~job/parser-without-partialchains.png

Look for the rectangle that says 'addr_contains' (this is a function in
lib/libcrypto/x509/x509_addr.c). One can see that tb@'s diff reduced use
of 'addr_contains' from 17.06%/5.03% down to 5.05%/0.59%. 

Its very handy to be able to confirm that there was an improvement in
the area where the diff was expected to cause an improvement (on top of
confirming performance improvement in overall runtime).

Thanks for sharing this! I hope it lands in base at some point.

Kind regards,

Job



[patch] Discontinued Toshiba dynadock lines for usbdevs and udl driver

2023-05-08 Thread S V
Good Day,

https://uk.dynabook.com/discontinued-products/pa3542e-2prp/

one more device with old (probably DL-160, but unsure so leaving
DLUNK) DisplayLink chip. works ok.

$ less /var/log/Xorg.0.log | grep wsudl
[   114.394] (II) LoadModule: "wsudl"
[   114.395] (II) Loading /usr/X11R6/lib/modules/drivers/wsudl_drv.so
[   114.395] (II) Module wsudl: vendor="X.Org Foundation"
[   114.396] (II) wsudl: driver for: DisplayLink
[   114.396] (WW) Falling back to old probe method for wsudl
[   114.396] (II) wsudl(0): using /dev/ttyD0
[   114.397] (II) wsudl(0): Creating default Display subsection in
Screen section
[   114.397] (==) wsudl(0): Depth 16, (--) framebuffer bpp 16
[   114.397] (==) wsudl(0): RGB weight 565
[   114.397] (==) wsudl(0): Default visual is TrueColor
[   114.397] (==) wsudl(0): Using gamma correction (1.0, 1.0, 1.0)
[   114.397] (II) wsudl(0): Vidmem: 2531k
[   114.397] (==) wsudl(0): DPI set to (96, 96)
[   114.399] (==) wsudl(0): Backing store enabled

xrandr output:
Screen 0: minimum 1440 x 900, current 1440 x 900, maximum 1440 x 900
default connected 1440x900+0+0 0mm x 0mm
   1440x900   0.00*

dmesg output:
udl0 at uhub5 port 1 configuration 1 interface 0 "DisplayLink TOSHIBA
Video Dock" rev 2.00/0.09 addr 8
wsdisplay1 at udl0 mux 1

if somebody don't know how to get it work (or any other udl) in X,
you need to create corresponding tty device (ttyD0 for wsdisplay1)
and create this additional conf for xenocara

$ cat /etc/X11/xorg.conf.d/wsudl.conf
Section "Device"
 Identifier "USB"
 Driver "wsudl"
 Option "Device" "/dev/ttyD0"
EndSection
Index: sys/dev/usb/udl.c
===
RCS file: /cvs/src/sys/dev/usb/udl.c,v
retrieving revision 1.98
diff -u -p -r1.98 udl.c
--- sys/dev/usb/udl.c   15 Jul 2022 17:57:27 -  1.98
+++ sys/dev/usb/udl.c   8 May 2023 17:46:19 -
@@ -249,7 +249,8 @@ static const struct udl_type udl_devs[] 
{ { USB_VENDOR_DISPLAYLINK, USB_PRODUCT_DISPLAYLINK_CONV }, DL160 },
{ { USB_VENDOR_DISPLAYLINK, USB_PRODUCT_DISPLAYLINK_LUM70 },DL125 },
{ { USB_VENDOR_DISPLAYLINK, USB_PRODUCT_DISPLAYLINK_POLARIS2 }, DLUNK },
-   { { USB_VENDOR_DISPLAYLINK, USB_PRODUCT_DISPLAYLINK_LT1421 },   DLUNK }
+   { { USB_VENDOR_DISPLAYLINK, USB_PRODUCT_DISPLAYLINK_LT1421 },   DLUNK },
+   { { USB_VENDOR_DISPLAYLINK, USB_PRODUCT_DISPLAYLINK_TOSHIBA },  DLUNK }
 };
 #define udl_lookup(v, p) ((struct udl_type *)usb_lookup(udl_devs, v, p))
 
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.755
diff -u -p -r1.755 usbdevs
--- sys/dev/usb/usbdevs 28 Apr 2023 01:24:14 -  1.755
+++ sys/dev/usb/usbdevs 8 May 2023 17:46:20 -
@@ -1575,6 +1575,7 @@ product DIGITALSTREAM PS2 0x0001  PS/2 Ac
 /* DisplayLink products */
 product DISPLAYLINK GUC20200x0059  IOGEAR DVI GUC2020
 product DISPLAYLINK LD220  0x0100  Samsung LD220
+product DISPLAYLINK TOSHIBA0x0110  TOSHIBA Video Dock
 product DISPLAYLINK POLARIS2   0x0117  Polaris2 USB dock
 product DISPLAYLINK VCUD60 0x0136  Rextron DVI
 product DISPLAYLINK CONV   0x0138  StarTech CONV-USB2DVI


Re: passwd: fix error paths and undefined behaviour

2023-05-08 Thread Todd C . Miller
On Mon, 08 May 2023 16:17:51 -, Tobias Stoeckmann wrote:

> Turns out that we have yet another possibility to trigger a theoretical
> signed integer overflow if pwd_tries is INT_MAX. This one avoids such
> situation as well.

OK millert@

 - todd



Re: passwd: fix error paths and undefined behaviour

2023-05-08 Thread Tobias Stoeckmann
I have committed the error handling aspects of the patch.

Turns out that we have yet another possibility to trigger a theoretical
signed integer overflow if pwd_tries is INT_MAX. This one avoids such
situation as well.

Okay?

Index: local_passwd.c
===
RCS file: /cvs/src/usr.bin/passwd/local_passwd.c,v
retrieving revision 1.63
diff -u -p -u -p -r1.63 local_passwd.c
--- local_passwd.c  10 Feb 2022 13:06:46 -  1.63
+++ local_passwd.c  8 May 2023 16:13:37 -
@@ -202,7 +202,7 @@ getnewpasswd(struct passwd *pw, login_ca
 
pwd_tries = pwd_gettries(lc);
 
-   for (newpass[0] = '\0', tries = 0;;) {
+   for (newpass[0] = '\0', tries = -1;;) {
char repeat[1024];
 
p = readpassphrase("New password:", newpass, sizeof(newpass),
@@ -217,7 +217,7 @@ getnewpasswd(struct passwd *pw, login_ca
continue;
}
 
-   if ((tries++ < pwd_tries || pwd_tries == 0) &&
+   if ((pwd_tries == 0 || ++tries < pwd_tries) &&
pwd_check(lc, p) == 0)
continue;
p = readpassphrase("Retype new password:", repeat, 
sizeof(repeat),



Re: less proto cksum out

2023-05-08 Thread Claudio Jeker
On Mon, May 08, 2023 at 02:29:12PM +0200, Alexander Bluhm wrote:
> Hi,
> 
> The call to in_proto_cksum_out() is only needed before the packet
> is passed to ifp->if_output().  The fragment code has its own
> checksum calculation and the other paths end in goto bad.
> 
> My TSO tcp_copper() will also do its own checksum handling, so I
> have to move the call to in_proto_cksum_out() to avoid calculating
> it twice.
> 
> ok?

Looks good to me and makes total sense.
OK claudio@
 
> bluhm
> 
> Index: net/pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.1176
> diff -u -p -r1.1176 pf.c
> --- net/pf.c  7 May 2023 16:23:23 -   1.1176
> +++ net/pf.c  8 May 2023 12:15:33 -
> @@ -6548,8 +6548,6 @@ pf_route(struct pf_pdesc *pd, struct pf_
>   ip = mtod(m0, struct ip *);
>   }
>  
> - in_proto_cksum_out(m0, ifp);
> -
>   if (ntohs(ip->ip_len) <= ifp->if_mtu) {
>   ip->ip_sum = 0;
>   if (ifp->if_capabilities & IFCAP_CSUM_IPv4)
> @@ -6558,6 +6556,7 @@ pf_route(struct pf_pdesc *pd, struct pf_
>   ipstat_inc(ips_outswcsum);
>   ip->ip_sum = in_cksum(m0, ip->ip_hl << 2);
>   }
> + in_proto_cksum_out(m0, ifp);
>   ifp->if_output(ifp, m0, sintosa(dst), rt);
>   goto done;
>   }
> @@ -6677,8 +6676,6 @@ pf_route6(struct pf_pdesc *pd, struct pf
>   }
>   }
>  
> - in6_proto_cksum_out(m0, ifp);
> -
>   /*
>* If packet has been reassembled by PF earlier, we have to
>* use pf_refragment6() here to turn it back to fragments.
> @@ -6689,6 +6686,7 @@ pf_route6(struct pf_pdesc *pd, struct pf
>   }
>  
>   if ((u_long)m0->m_pkthdr.len <= ifp->if_mtu) {
> + in6_proto_cksum_out(m0, ifp);
>   ifp->if_output(ifp, m0, sin6tosa(dst), rt);
>   goto done;
>   }
> Index: netinet/ip_output.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_output.c,v
> retrieving revision 1.383
> diff -u -p -r1.383 ip_output.c
> --- netinet/ip_output.c   7 May 2023 16:23:23 -   1.383
> +++ netinet/ip_output.c   8 May 2023 12:15:33 -
> @@ -443,7 +443,6 @@ sendit:
>   goto reroute;
>   }
>  #endif
> - in_proto_cksum_out(m, ifp);
>  
>  #ifdef IPSEC
>   if (ipsec_in_use && (flags & IP_FORWARDING) && (ipforwarding == 2) &&
> @@ -464,7 +463,7 @@ sendit:
>   ipstat_inc(ips_outswcsum);
>   ip->ip_sum = in_cksum(m, hlen);
>   }
> -
> + in_proto_cksum_out(m, ifp);
>   error = ifp->if_output(ifp, m, sintosa(dst), ro->ro_rt);
>   goto done;
>   }
> Index: netinet6/ip6_output.c
> ===
> RCS file: /cvs/src/sys/netinet6/ip6_output.c,v
> retrieving revision 1.273
> diff -u -p -r1.273 ip6_output.c
> --- netinet6/ip6_output.c 7 May 2023 16:23:24 -   1.273
> +++ netinet6/ip6_output.c 8 May 2023 12:15:33 -
> @@ -664,8 +664,6 @@ reroute:
>   ip6->ip6_dst.s6_addr16[1] = dst_scope;
>   }
>  
> - in6_proto_cksum_out(m, ifp);
> -
>   /*
>* Send the packet to the outgoing interface.
>* If necessary, do IPv6 fragmentation before sending.
> @@ -701,6 +699,7 @@ reroute:
>* transmit packet without fragmentation
>*/
>   if (dontfrag || (tlen <= mtu)) {/* case 1-a and 2-a */
> + in6_proto_cksum_out(m, ifp);
>   error = ifp->if_output(ifp, m, sin6tosa(dst), ro->ro_rt);
>   goto done;
>   }
> 

-- 
:wq Claudio



less proto cksum out

2023-05-08 Thread Alexander Bluhm
Hi,

The call to in_proto_cksum_out() is only needed before the packet
is passed to ifp->if_output().  The fragment code has its own
checksum calculation and the other paths end in goto bad.

My TSO tcp_copper() will also do its own checksum handling, so I
have to move the call to in_proto_cksum_out() to avoid calculating
it twice.

ok?

bluhm

Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1176
diff -u -p -r1.1176 pf.c
--- net/pf.c7 May 2023 16:23:23 -   1.1176
+++ net/pf.c8 May 2023 12:15:33 -
@@ -6548,8 +6548,6 @@ pf_route(struct pf_pdesc *pd, struct pf_
ip = mtod(m0, struct ip *);
}
 
-   in_proto_cksum_out(m0, ifp);
-
if (ntohs(ip->ip_len) <= ifp->if_mtu) {
ip->ip_sum = 0;
if (ifp->if_capabilities & IFCAP_CSUM_IPv4)
@@ -6558,6 +6556,7 @@ pf_route(struct pf_pdesc *pd, struct pf_
ipstat_inc(ips_outswcsum);
ip->ip_sum = in_cksum(m0, ip->ip_hl << 2);
}
+   in_proto_cksum_out(m0, ifp);
ifp->if_output(ifp, m0, sintosa(dst), rt);
goto done;
}
@@ -6677,8 +6676,6 @@ pf_route6(struct pf_pdesc *pd, struct pf
}
}
 
-   in6_proto_cksum_out(m0, ifp);
-
/*
 * If packet has been reassembled by PF earlier, we have to
 * use pf_refragment6() here to turn it back to fragments.
@@ -6689,6 +6686,7 @@ pf_route6(struct pf_pdesc *pd, struct pf
}
 
if ((u_long)m0->m_pkthdr.len <= ifp->if_mtu) {
+   in6_proto_cksum_out(m0, ifp);
ifp->if_output(ifp, m0, sin6tosa(dst), rt);
goto done;
}
Index: netinet/ip_output.c
===
RCS file: /cvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.383
diff -u -p -r1.383 ip_output.c
--- netinet/ip_output.c 7 May 2023 16:23:23 -   1.383
+++ netinet/ip_output.c 8 May 2023 12:15:33 -
@@ -443,7 +443,6 @@ sendit:
goto reroute;
}
 #endif
-   in_proto_cksum_out(m, ifp);
 
 #ifdef IPSEC
if (ipsec_in_use && (flags & IP_FORWARDING) && (ipforwarding == 2) &&
@@ -464,7 +463,7 @@ sendit:
ipstat_inc(ips_outswcsum);
ip->ip_sum = in_cksum(m, hlen);
}
-
+   in_proto_cksum_out(m, ifp);
error = ifp->if_output(ifp, m, sintosa(dst), ro->ro_rt);
goto done;
}
Index: netinet6/ip6_output.c
===
RCS file: /cvs/src/sys/netinet6/ip6_output.c,v
retrieving revision 1.273
diff -u -p -r1.273 ip6_output.c
--- netinet6/ip6_output.c   7 May 2023 16:23:24 -   1.273
+++ netinet6/ip6_output.c   8 May 2023 12:15:33 -
@@ -664,8 +664,6 @@ reroute:
ip6->ip6_dst.s6_addr16[1] = dst_scope;
}
 
-   in6_proto_cksum_out(m, ifp);
-
/*
 * Send the packet to the outgoing interface.
 * If necessary, do IPv6 fragmentation before sending.
@@ -701,6 +699,7 @@ reroute:
 * transmit packet without fragmentation
 */
if (dontfrag || (tlen <= mtu)) {/* case 1-a and 2-a */
+   in6_proto_cksum_out(m, ifp);
error = ifp->if_output(ifp, m, sin6tosa(dst), ro->ro_rt);
goto done;
}



Re: nd6 RTM_ADD logic

2023-05-08 Thread Claudio Jeker
On Thu, May 04, 2023 at 08:43:19AM +0200, Alexander Bluhm wrote:
> Hi,
> 
> To make ND6 mp-safe, I have to guarantee the life time of ln =
> rt->rt_llinfo.  This call to nd6_llinfo_settimer(ln) looks strange.
> 
> The complicated logic can be replaced with what we have in ARP.
> Digging through the histroy shows a lot of refactoring that seems
> to make rt_expire handling here obsolete.  Just initialize it to
> 0.  And I doubt that event this is necessary.  But let's stick to
> the ARP code for now.
> 
> Cloning and local routes should never expire.  If RTF_LLINFO is
> set, ln should not be NULL.  So nd6_llinfo_settimer() was not reached
> in this case.
> 
> While there, remove obsolete comment and #if 0 code that never worked.
> 
> ok?

OK claudio@
 
> bluhm
> 
> Index: netinet6/nd6.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/nd6.c,v
> retrieving revision 1.274
> diff -u -p -r1.274 nd6.c
> --- netinet6/nd6.c3 May 2023 11:43:31 -   1.274
> +++ netinet6/nd6.c3 May 2023 22:02:28 -
> @@ -760,40 +760,12 @@ nd6_rtrequest(struct ifnet *ifp, int req
>  
>   switch (req) {
>   case RTM_ADD:
> - if ((rt->rt_flags & RTF_CLONING) ||
> - ((rt->rt_flags & (RTF_LLINFO | RTF_LOCAL)) && ln == NULL)) {
> - if (ln != NULL)
> - nd6_llinfo_settimer(ln, 0);
> - if ((rt->rt_flags & RTF_CLONING) != 0)
> - break;
> + if (rt->rt_flags & RTF_CLONING) {
> + rt->rt_expire = 0;
> + break;
>   }
> - /*
> -  * In IPv4 code, we try to announce new RTF_ANNOUNCE entry here.
> -  * We don't do that here since llinfo is not ready yet.
> -  *
> -  * There are also couple of other things to be discussed:
> -  * - unsolicited NA code needs improvement beforehand
> -  * - RFC2461 says we MAY send multicast unsolicited NA
> -  *   (7.2.6 paragraph 4), however, it also says that we
> -  *   SHOULD provide a mechanism to prevent multicast NA storm.
> -  *   we don't have anything like it right now.
> -  *   note that the mechanism needs a mutual agreement
> -  *   between proxies, which means that we need to implement
> -  *   a new protocol, or a new kludge.
> -  * - from RFC2461 6.2.4, host MUST NOT send an unsolicited NA.
> -  *   we need to check ip6forwarding before sending it.
> -  *   (or should we allow proxy ND configuration only for
> -  *   routers?  there's no mention about proxy ND from hosts)
> -  */
> -#if 0
> - /* XXX it does not work */
> - if (rt->rt_flags & RTF_ANNOUNCE)
> - nd6_na_output(ifp,
> -   &satosin6(rt_key(rt))->sin6_addr,
> -   &satosin6(rt_key(rt))->sin6_addr,
> -   ip6_forwarding ? ND_NA_FLAG_ROUTER : 0,
> -   1, NULL);
> -#endif
> + if ((rt->rt_flags & RTF_LOCAL) && rt->rt_llinfo == NULL)
> + rt->rt_expire = 0;
>   /* FALLTHROUGH */
>   case RTM_RESOLVE:
>   if (gate->sa_family != AF_LINK ||
> 

-- 
:wq Claudio



Fix possible mem-leak in snmpd/usm.c

2023-05-08 Thread Gerhard Roth
Rev 1.25 introduced a mem-leak:


Index: usr.sbin/snmpd/usm.c
===
RCS file: /cvs/src/usr.sbin/snmpd/usm.c,v
retrieving revision 1.25
diff -u -p -r1.25 usm.c
--- usr.sbin/snmpd/usm.c20 Dec 2022 20:01:25 -  1.25
+++ usr.sbin/snmpd/usm.c8 May 2023 12:12:16 -
@@ -629,8 +629,10 @@ usm_decrypt(struct snmp_message *msg, st
return NULL;
 
scoped_pdu_len = usm_crypt(msg, privstr, (int)privlen, buf, 0);
-   if (scoped_pdu_len < 0)
+   if (scoped_pdu_len < 0) {
+   free(buf);
return NULL;
+   }
 
bzero(&ber, sizeof(ber));
ober_set_application(&ber, smi_application);



smime.p7s
Description: S/MIME cryptographic signature


Partial chains for rpki-client

2023-05-08 Thread Theo Buehler
The diff below is based on a hint by beck and was discussed extensively
with beck, claudio and job during and after m2k23. It results in a quite
significant reduction of the runtime of an ordinary rpki-client run as
usually done from cron.

One problem we're facing with the generally rather poor quality RFC 3779
code in libcrypto is that its performance is abysmal. Flame graphs show
a lot of time spent in addr_contains(). While there is some room for
improvement in that function itself (the containment check for prefixes
could be optimized quite a bit), we can avoid a lot of the most expensive
checking of certificates with tons of resources close to the TA by using
the partial chains flag.

More precisely, in the tree of already validated certs look for the first
one that has no inherited RFC 3779 resources and use that as the trust
anchor for our chains via the X509_V_FLAG_PARTIAL_CHAIN flag for the
verifier. This way we can be sure that a leaf's delegated resources are
properly covered and at the same time significantly shorten most paths
validated. There is no downside to doing this since we have already
validated the path from all certs in the auth tree to the root.

In my testing, this avoids 30-50% of overhead and works equally well
with LibreSSL and OpenSSL 1.1.

I currently hang any_inherits off struct auth. It may be worthwhile to
move that to struct cert and populate it in cert_parse_pre() in a later
step.

Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.107
diff -u -p -r1.107 cert.c
--- cert.c  15 Apr 2023 00:39:08 -  1.107
+++ cert.c  8 May 2023 11:04:30 -
@@ -1092,6 +1092,7 @@ auth_insert(struct auth_tree *auths, str
 
na->parent = parent;
na->cert = cert;
+   na->any_inherits = x509_any_inherits(cert->x509);
 
if (RB_INSERT(auth_tree, auths, na) != NULL)
err(1, "auth tree corrupted");
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.180
diff -u -p -r1.180 extern.h
--- extern.h27 Apr 2023 08:37:53 -  1.180
+++ extern.h8 May 2023 11:04:30 -
@@ -454,6 +454,7 @@ struct auth {
RB_ENTRY(auth)   entry;
struct cert *cert; /* owner information */
struct auth *parent; /* pointer to parent or NULL for TA cert */
+   int  any_inherits;
 };
 /*
  * Tree of auth sorted by ski
Index: validate.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/validate.c,v
retrieving revision 1.59
diff -u -p -r1.59 validate.c
--- validate.c  27 Apr 2023 08:37:53 -  1.59
+++ validate.c  8 May 2023 11:29:56 -
@@ -332,25 +332,37 @@ valid_origin(const char *uri, const char
 }
 
 /*
- * Walk the certificate tree to the root and build a certificate
- * chain from cert->x509. All certs in the tree are validated and
- * can be loaded as trusted stack into the validator.
+ * Walk the tree of known valid CA certificates until we find a certificate 
that
+ * doesn't inherit. Build a chain of intermediates and use the non-inheriting
+ * certificate as a trusted root by virtue of X509_V_FLAG_PARTIAL_CHAIN. The
+ * RFC 3779 path validation needs a non-inheriting trust root to ensure that
+ * all delegated resources are covered.
  */
 static void
-build_chain(const struct auth *a, STACK_OF(X509) **chain)
+build_chain(const struct auth *a, STACK_OF(X509) **intermediates,
+STACK_OF(X509) **root)
 {
-   *chain = NULL;
+   *intermediates = NULL;
+   *root = NULL;
 
if (a == NULL)
return;
 
-   if ((*chain = sk_X509_new_null()) == NULL)
+   if ((*intermediates = sk_X509_new_null()) == NULL)
+   err(1, "sk_X509_new_null");
+   if ((*root = sk_X509_new_null()) == NULL)
err(1, "sk_X509_new_null");
for (; a != NULL; a = a->parent) {
assert(a->cert->x509 != NULL);
-   if (!sk_X509_push(*chain, a->cert->x509))
+   if (!a->any_inherits) {
+   if (!sk_X509_push(*root, a->cert->x509))
+   errx(1, "sk_X509_push");
+   break;
+   }
+   if (!sk_X509_push(*intermediates, a->cert->x509))
errx(1, "sk_X509_push");
}
+   assert(sk_X509_num(*root) == 1);
 }
 
 /*
@@ -381,13 +393,13 @@ valid_x509(char *file, X509_STORE_CTX *s
 {
X509_VERIFY_PARAM   *params;
ASN1_OBJECT *cp_oid;
-   STACK_OF(X509)  *chain;
+   STACK_OF(X509)  *intermediates, *root;
STACK_OF(X509_CRL)  *crls = NULL;
unsigned longflags;
int  error;
 
*errstr = NULL;
-   build_chain(a, &chain);
+   build_chain(a

Re: installer: disk crypto: crank KDF rounds to hardware based default

2023-05-08 Thread Klemens Nanni
On Sun, Apr 23, 2023 at 05:07:30PM +, Klemens Nanni wrote:
> For new installs, it seems adequate to base the number on the actual hardware,
> assuming the CRYPTO volume will stay in that hardware for a while.
> 
> The current default of 16 is from old PKCS5 PBKDF2 times and changing it in
> bioctl(8) is a more invasive change (for later, perhaps).
> 
> Thoughts?  Feedback from the crypto folks appreciated.
> 
> On X230 and T14, 16 feels pretty instant, whereas 'auto' takes about a second
> on a T14.

Ping.

Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1244
diff -u -p -r1.1244 install.sub
--- install.sub 2 May 2023 15:55:58 -   1.1244
+++ install.sub 8 May 2023 11:00:04 -
@@ -3111,7 +3111,7 @@ __EOT
md_prep_fdisk $_chunk softraid
echo 'RAID *' | disklabel -w -A -T- $_chunk
 
-   until bioctl -c C -l ${_chunk}a softraid0 >/dev/null; do
+   until bioctl -c C -r auto -l ${_chunk}a softraid0 >/dev/null; do
# Most likely botched passphrases, silently retry twice.
((++_tries < 3)) || exit
done