Re: uhidpp(4): logitech hid++ device driver
On Fri, Feb 05, 2021 at 10:36:34AM +0100, Landry Breuil wrote: > On Fri, Jan 22, 2021 at 08:18:51AM +0100, Anton Lindqvist wrote: > > Hi, > > Here's a new driver for Logitech HID++ devices, currently limited to > > exposing battery sensors. Here's an example using a Logitech M330 mouse: > > > > $ dmesg | grep uhidpp > > uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33 > > $ sysctl hw.sensors.uhidpp0 > > hw.sensors.uhidpp0.raw0=2 (battery levels) > > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > thanks anton, now that this got commited i realize i have a pair of > devices: > > device 1 (M235 according to bottom) previously reported this in dmesg: > > uhidev0 at uhub0 port 2 configuration 1 interface 0 "Logitech USB Receiver" > rev 2.00/12.03 addr 2 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes > wskbd1 at ukbd0 mux 1 > uhidev1 at uhub0 port 2 configuration 1 interface 1 "Logitech USB Receiver" > rev 2.00/12.03 addr 2 > uhidev1: iclass 3/1, 8 report ids > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > wsmouse2 at ums0 mux 0 > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/12.03 addr 2 > uhidev2: iclass 3/0, 33 report ids > uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0 > uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0 > uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0 > uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0 > > device 2 (M235 2nd gen according to bottom) previously reported this in dmesg > (same thing, but the rev/addr values): > > uhidev1 at uhub0 port 4 configuration 1 interface 0 "Logitech USB Receiver" > rev 2.00/24.07 addr 3 > uhidev1: iclass 3/1 > ukbd1 at uhidev1: 8 variable keys, 6 key codes > wskbd2 at ukbd1 mux 1 > uhidev2 at uhub0 port 4 configuration 1 interface 1 "Logitech USB Receiver" > rev 2.00/24.07 addr 3 > uhidev2: iclass 3/1, 8 report ids > ums0 at uhidev2 reportid 2: 16 buttons, Z and W dir > wsmouse2 at ums0 mux 0 > uhid0 at uhidev2 reportid 3: input=4, output=0, feature=0 > uhid1 at uhidev2 reportid 4: input=1, output=0, feature=0 > uhid2 at uhidev2 reportid 8: input=1, output=0, feature=0 > uhidev3 at uhub0 port 4 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/24.07 addr 3 > uhidev3: iclass 3/0, 33 report ids > uhid3 at uhidev3 reportid 16: input=6, output=6, feature=0 > uhid4 at uhidev3 reportid 17: input=19, output=19, feature=0 > uhid5 at uhidev3 reportid 32: input=14, output=14, feature=0 > uhid6 at uhidev3 reportid 33: input=31, output=31, feature=0 > > now device 1/uhidev2 is properly identified by uhidpp: > > uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/12.03 addr 2 > uhidev2: iclass 3/0, 33 report ids > uhidpp0 at uhidev2 device 1 mouse "M325" serial 69-b1-af-84 > > and properly reports sensors: > hw.sensors.uhidpp0.raw0=2 (battery levels) > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > and device2 (plugged on the same laptop so device renumbered) also works with > uhidpp: > > uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/24.07 addr 2 > uhidev2: iclass 3/0, 33 report ids > uhidpp0 at uhidev2 device 1 mouse "Wireless Mouse" serial f3-94-18-8c > > same level reported in sensors for a different mouse (?): > hw.sensors.uhidpp0.raw0=2 (battery levels) > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > let me know if you need more details/infos from those devices (usbdevs dumps > etc..) As both your devices only are capable of reporting two battery levels, as given by hw.sensors.uhidpp0.raw0, it's quite likely that they will report the same level. > i'll eventually look at adding support for uhidpp to upower so mouse battery > levels can be reported in xfce4-power-manager and gnome, like it does on > linux.. There has been some work on this from a Linux perspective[1], not sure if there's anything you could piggy back on there. Let me know if any more data needs to be expsoed in order to satisfy upower. [1] https://julien.danjou.info/logitech-unifying-upower/
Re: broadcast simplex checksum
Hi,
Thanks for the background.
I'm ok with your latest diff as-is. I prefer a slightly different
direction, see below, but not enough to object.
On Mon, 1 Feb 2021, Alexander Bluhm wrote:
> On Mon, Feb 01, 2021 at 08:08:56AM +1300, Richard Procter wrote:
> > - Might the rule disabling checksum offload for broadcasts on IFF_SIMPLEX
> > interfaces be weakened to disable checksum offload for all broadcast
> > packets instead?
>
> I just copied the condition from ether_resolve():
>
> /* If broadcasting on a simplex interface, loopback a copy */
> if (ISSET(m->m_flags, M_BCAST) &&
> ISSET(ifp->if_flags, IFF_SIMPLEX) &&
> !m->m_pkthdr.pf.routed) {
> struct mbuf *mcopy;
>
> /* XXX Should we input an unencrypted IPsec packet? */
> mcopy = m_copym(m, 0, M_COPYALL, M_NOWAIT);
> if (mcopy != NULL)
> if_input_local(ifp, mcopy, af);
> }
>
> The bug is triggered when the packet is processed by if_input_local().
>
> > This simplifies the logic, and shouldn't impact performance as
>
> Yes, performance does not matter. I just wanted to show that the
> code is necessary for simplex interfaces.
I think the log message and comment suffice to capture the rationale.
I see the following downside with the IFF_SIMPLEX term. The network layer
offloads its checksum responsibility to the link layer, as an
optimisation. The more the network layer accomodates the quirks of the
link layer in making its decision to offload, the greater the layer
violation.
Independently of this, there is good reason to compute /all/ broadcast
checksums at the network layer: it is unprofitable to offload them. And
avoiding unnecessary offload minimises what the link layer must handle on
the network's behalf, its scope for going wrong.
So, I would rather eliminate the coupling than document it. And I would
rather do that by eliminating unnecessary offload than disable it for each
unhandled edge case.
> > - what motivates the new '!m->m_pkthdr.pf.routed??? term?
>
> Just copied from ether_resolve(). It looks strange I don't know
> why it is there. I can leave it out in my check if you think this
> is clearer.
It appears to eliminate a local broadcast storm when doing route-to
the broadcast address:
> > if_ethersubr.c: revision 1.70
> > date: 2003/08/18 11:01:41; author: dhartmei; state: Exp; lines: +3
-2;
> > prevent looutput() feedback of broadcast/multicast packets if they are
> > pf routed. prevents a kernel lockup with some (non-sensical) route-to
> > r6ules. report and debugging by mpech@. ok itojun@, henning@, mpech@.
As software offload is always safer, it should be fine to omit the
!m->m_pkthdr.pf.routed term.
So given the above, my preference would be to prune the unnecessary
offload and weaken
+ if (ISSET(m->m_flags, M_BCAST) &&
+ ISSET(ifp->if_flags, IFF_SIMPLEX) &&
+ !m->m_pkthdr.pf.routed)
+ return (0);
to
+ if (ISSET(m->m_flags, M_BCAST))
+ return (0);
I like the addition of in_ifcap_cksum() as it can encapsulate the offload
policy.
cheers,
Richard.
>
> bluhm
>
Re: ifg_refcnt atomic operation
refcnt_init starts counting at 1, while the existing code starts at 0. Do
the crashes stop because we never fully release all the references and
never free it now?
On Sat, 6 Feb 2021, 10:55 Alexander Bluhm, wrote:
> Hi,
>
> When I replace the ++ and -- of ifg_refcnt with an atomic operation,
> it fixes this syzkaller panic.
>
>
> https://syzkaller.appspot.com/bug?id=54e16dc5bce6929e14b42e2f1379f1c18f62be43
>
> Without the fix "syz-execprog -repeat=0 -procs=8 repro-pfi.syz"
> crashes my vmm in a few seconds. With the diff I cannot reproduce
> for several minutes.
>
> ok?
>
> bluhm
>
> Index: net/if.c
> ===
> RCS file: /cvs/src/sys/net/if.c,v
> retrieving revision 1.626
> diff -u -p -r1.626 if.c
> --- net/if.c1 Feb 2021 07:43:33 - 1.626
> +++ net/if.c6 Feb 2021 00:37:50 -
> @@ -2601,7 +2601,7 @@ if_creategroup(const char *groupname)
> return (NULL);
>
> strlcpy(ifg->ifg_group, groupname, sizeof(ifg->ifg_group));
> - ifg->ifg_refcnt = 0;
> + refcnt_init(>ifg_refcnt);
> ifg->ifg_carp_demoted = 0;
> TAILQ_INIT(>ifg_members);
> #if NPF > 0
> @@ -2648,7 +2648,7 @@ if_addgroup(struct ifnet *ifp, const cha
> return (ENOMEM);
> }
>
> - ifg->ifg_refcnt++;
> + refcnt_take(>ifg_refcnt);
> ifgl->ifgl_group = ifg;
> ifgm->ifgm_ifp = ifp;
>
> @@ -2692,7 +2692,7 @@ if_delgroup(struct ifnet *ifp, const cha
> pfi_group_change(groupname);
> #endif
>
> - if (--ifgl->ifgl_group->ifg_refcnt == 0) {
> + if (refcnt_rele(>ifgl_group->ifg_refcnt)) {
> TAILQ_REMOVE(_head, ifgl->ifgl_group, ifg_next);
> #if NPF > 0
> pfi_detach_ifgroup(ifgl->ifgl_group);
> Index: net/if_var.h
> ===
> RCS file: /cvs/src/sys/net/if_var.h,v
> retrieving revision 1.112
> diff -u -p -r1.112 if_var.h
> --- net/if_var.h29 Jul 2020 12:09:31 - 1.112
> +++ net/if_var.h6 Feb 2021 00:38:23 -
> @@ -263,7 +263,7 @@ struct ifmaddr {
>
> struct ifg_group {
> char ifg_group[IFNAMSIZ];
> - u_intifg_refcnt;
> + struct refcntifg_refcnt;
> caddr_t ifg_pf_kif;
> int ifg_carp_demoted;
> TAILQ_HEAD(, ifg_member) ifg_members;
> Index: netinet/ip_carp.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_carp.c,v
> retrieving revision 1.351
> diff -u -p -r1.351 ip_carp.c
> --- netinet/ip_carp.c 21 Jan 2021 13:18:07 - 1.351
> +++ netinet/ip_carp.c 6 Feb 2021 00:39:14 -
> @@ -789,7 +789,7 @@ carpattach(int n)
> struct ifg_group*ifg;
>
> if ((ifg = if_creategroup("carp")) != NULL)
> - ifg->ifg_refcnt++; /* keep around even if empty */
> + refcnt_take(>ifg_refcnt); /* keep around even if
> empty */
> if_clone_attach(_cloner);
> carpcounters = counters_alloc(carps_ncounters);
> }
>
>
Re: Replace libfuse from base with libfuse from ports
On Fri, Feb 05, 2021 at 07:17:09PM +0100, Gr??goire Jadi wrote: > Helg writes: > > Hi, > > > I currently only have a port of the 2.x branch of libfuse (attached) but > > will also port the 3.x libfuse once I have user mounting working. I am > > not aware of any ports other than the latest version of sshfs that > > depends on 3.x. In any case, we will need to support libfuse 2.x for > > some time until all file systems are updated upstream to work with 3.x. > > > > I can't comment for the rest of your work, but borgbackup seems to > prefer libfuse 3.x Thanks for letting me know. borgbackup is an example of a port that will benefit from this work. Are you suggesting that I should not commit until libfuse3 has also been ported? Even thought it's not actively maintained, llfuse could be ported in the meantime to enable FUSE functionality in borgbackup.. > https://github.com/borgbackup/borg/blob/master/setup.py#L77 > > # note for package maintainers: if you package borgbackup for distribution, > > # please (if available) add pyfuse3 (preferably) or llfuse (not maintained > > any more) > > # as a *requirement*. "borg mount" needs one of them to work. > > # if neither is available, do not require it, most of borgbackup will > > work. > > https://pypi.org/project/pyfuse3/ > > pyfuse3 is a set of Python 3 bindings for libfuse 3. It provides an > > asynchronous API compatible with Trio and asyncio, and enables you to > > easily write a full-featured Linux filesystem in Python. > > Thanks for your work. > Best, > > -- > gjadi > PGP : AF26 E9C2 A1C8 8D32 A868 4386 1373 5477 2B65 1894
ifg_refcnt atomic operation
Hi,
When I replace the ++ and -- of ifg_refcnt with an atomic operation,
it fixes this syzkaller panic.
https://syzkaller.appspot.com/bug?id=54e16dc5bce6929e14b42e2f1379f1c18f62be43
Without the fix "syz-execprog -repeat=0 -procs=8 repro-pfi.syz"
crashes my vmm in a few seconds. With the diff I cannot reproduce
for several minutes.
ok?
bluhm
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.626
diff -u -p -r1.626 if.c
--- net/if.c1 Feb 2021 07:43:33 - 1.626
+++ net/if.c6 Feb 2021 00:37:50 -
@@ -2601,7 +2601,7 @@ if_creategroup(const char *groupname)
return (NULL);
strlcpy(ifg->ifg_group, groupname, sizeof(ifg->ifg_group));
- ifg->ifg_refcnt = 0;
+ refcnt_init(>ifg_refcnt);
ifg->ifg_carp_demoted = 0;
TAILQ_INIT(>ifg_members);
#if NPF > 0
@@ -2648,7 +2648,7 @@ if_addgroup(struct ifnet *ifp, const cha
return (ENOMEM);
}
- ifg->ifg_refcnt++;
+ refcnt_take(>ifg_refcnt);
ifgl->ifgl_group = ifg;
ifgm->ifgm_ifp = ifp;
@@ -2692,7 +2692,7 @@ if_delgroup(struct ifnet *ifp, const cha
pfi_group_change(groupname);
#endif
- if (--ifgl->ifgl_group->ifg_refcnt == 0) {
+ if (refcnt_rele(>ifgl_group->ifg_refcnt)) {
TAILQ_REMOVE(_head, ifgl->ifgl_group, ifg_next);
#if NPF > 0
pfi_detach_ifgroup(ifgl->ifgl_group);
Index: net/if_var.h
===
RCS file: /cvs/src/sys/net/if_var.h,v
retrieving revision 1.112
diff -u -p -r1.112 if_var.h
--- net/if_var.h29 Jul 2020 12:09:31 - 1.112
+++ net/if_var.h6 Feb 2021 00:38:23 -
@@ -263,7 +263,7 @@ struct ifmaddr {
struct ifg_group {
char ifg_group[IFNAMSIZ];
- u_intifg_refcnt;
+ struct refcntifg_refcnt;
caddr_t ifg_pf_kif;
int ifg_carp_demoted;
TAILQ_HEAD(, ifg_member) ifg_members;
Index: netinet/ip_carp.c
===
RCS file: /cvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.351
diff -u -p -r1.351 ip_carp.c
--- netinet/ip_carp.c 21 Jan 2021 13:18:07 - 1.351
+++ netinet/ip_carp.c 6 Feb 2021 00:39:14 -
@@ -789,7 +789,7 @@ carpattach(int n)
struct ifg_group*ifg;
if ((ifg = if_creategroup("carp")) != NULL)
- ifg->ifg_refcnt++; /* keep around even if empty */
+ refcnt_take(>ifg_refcnt); /* keep around even if empty */
if_clone_attach(_cloner);
carpcounters = counters_alloc(carps_ncounters);
}
Re: unwind(8): open DNSSEC trustanchor late
On Fri, Jan 29 2021, Florian Obser wrote:
> Last piece of the puzzle...
>
> Re-try to open DNSSEC trust anchor file if /var is not mounted yet.
> With this we are able to start unwind before the network is up and
> partitions are mounted.
Sorry for being late to the party, I just upgraded to the latest snaps
and DNS broke. Reverting this diff unbreaks unwind(8) operations.
My unwind.conf:
preference { recursor }
(Can't reproduce this problem with an empty config file.)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: rpki-client parse and check caRepository Subject Information Access
On Fri, Feb 05, 2021 at 02:45:41PM +0100, Claudio Jeker wrote: > RPKI certificates have 3 possible Subject Information Access URI that we > may be interested in: > - 1.3.6.1.5.5.7.48.5 (caRepository) > - 1.3.6.1.5.5.7.48.10 (rpkiManifest) > - 1.3.6.1.5.5.7.48.13 (rpkiNotify) > > rpkiManifest points to the .mft file inside the caRepository. > Because of this caRepository is the base URI for all the files below > this certificate. rpkiNotify points to an RRDP endpoint where the XML > data also contains URI that again need to match the caRepository. If not > something strange is going on. > > Since the caRepository data is useful extract it from the cert and also > do a simple strstr() check to ensure that rpkiManifest starts with > caRepository. > > Currently the data is not used further than that but I want to add it to > the repository information as a next step. ok tb
Re: Replace libfuse from base with libfuse from ports
Helg writes: Hi, > I currently only have a port of the 2.x branch of libfuse (attached) but > will also port the 3.x libfuse once I have user mounting working. I am > not aware of any ports other than the latest version of sshfs that > depends on 3.x. In any case, we will need to support libfuse 2.x for > some time until all file systems are updated upstream to work with 3.x. > I can't comment for the rest of your work, but borgbackup seems to prefer libfuse 3.x https://github.com/borgbackup/borg/blob/master/setup.py#L77 > # note for package maintainers: if you package borgbackup for distribution, > # please (if available) add pyfuse3 (preferably) or llfuse (not maintained > any more) > # as a *requirement*. "borg mount" needs one of them to work. > # if neither is available, do not require it, most of borgbackup will > work. https://pypi.org/project/pyfuse3/ > pyfuse3 is a set of Python 3 bindings for libfuse 3. It provides an > asynchronous API compatible with Trio and asyncio, and enables you to > easily write a full-featured Linux filesystem in Python. Thanks for your work. Best, -- gjadi PGP : AF26 E9C2 A1C8 8D32 A868 4386 1373 5477 2B65 1894
Re: smtpd: use libtls
Been running it for a few days, no regressions so far
> On 5 Feb 2021, at 09:35, Eric Faurot wrote:
>
> No much report so far.
> Anybody had a chance to test this?
> Here is the same diff again with manpage update this time.
>
> Eric.
>
> Index: ca.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/ca.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 ca.c
> --- ca.c 31 Dec 2020 08:27:15 - 1.37
> +++ ca.c 19 Jan 2021 11:09:54 -
> @@ -69,6 +69,7 @@ static int ecdsae_do_verify(const unsign
> EC_KEY *);
>
>
> +static struct dict pkeys;
> static uint64_treqid = 0;
>
> static void
> @@ -132,26 +133,29 @@ ca_init(void)
> struct pki *pki;
> const char *k;
> void*iter_dict;
> + char*hash;
>
> log_debug("debug: init private ssl-tree");
> + dict_init();
> iter_dict = NULL;
> while (dict_iter(env->sc_pki_dict, _dict, , (void **))) {
> if (pki->pki_key == NULL)
> continue;
>
> - if ((in = BIO_new_mem_buf(pki->pki_key,
> - pki->pki_key_len)) == NULL)
> - fatalx("ca_launch: key");
> -
> - if ((pkey = PEM_read_bio_PrivateKey(in,
> - NULL, NULL, NULL)) == NULL)
> - fatalx("ca_launch: PEM");
> + in = BIO_new_mem_buf(pki->pki_key, pki->pki_key_len);
> + if (in == NULL)
> + fatalx("ca_init: key");
> + pkey = PEM_read_bio_PrivateKey(in, NULL, NULL, NULL);
> + if (pkey == NULL)
> + fatalx("ca_init: PEM");
> BIO_free(in);
>
> - pki->pki_pkey = pkey;
> -
> - freezero(pki->pki_key, pki->pki_key_len);
> - pki->pki_key = NULL;
> + hash = ssl_pubkey_hash(pki->pki_cert, pki->pki_cert_len);
> + if (dict_check(, hash))
> + EVP_PKEY_free(pkey);
> + else
> + dict_xset(, hash, pkey);
> + free(hash);
> }
> }
>
> @@ -223,15 +227,15 @@ end:
> void
> ca_imsg(struct mproc *p, struct imsg *imsg)
> {
> + EVP_PKEY*pkey;
> RSA *rsa = NULL;
> EC_KEY *ecdsa = NULL;
> const void *from = NULL;
> unsigned char *to = NULL;
> struct msg m;
> - const char *pkiname;
> + const char *hash;
> size_t flen, tlen, padding;
> int buf_len;
> - struct pki *pki;
> int ret = 0;
> uint64_t id;
> int v;
> @@ -267,16 +271,15 @@ ca_imsg(struct mproc *p, struct imsg *im
> case IMSG_CA_RSA_PRIVDEC:
> m_msg(, imsg);
> m_get_id(, );
> - m_get_string(, );
> + m_get_string(, );
> m_get_data(, , );
> m_get_size(, );
> m_get_size(, );
> m_end();
>
> - pki = dict_get(env->sc_pki_dict, pkiname);
> - if (pki == NULL || pki->pki_pkey == NULL ||
> - (rsa = EVP_PKEY_get1_RSA(pki->pki_pkey)) == NULL)
> - fatalx("ca_imsg: invalid pki");
> + pkey = dict_get(, hash);
> + if (pkey == NULL || (rsa = EVP_PKEY_get1_RSA(pkey)) == NULL)
> + fatalx("ca_imsg: invalid pkey hash");
>
> if ((to = calloc(1, tlen)) == NULL)
> fatalx("ca_imsg: calloc");
> @@ -306,14 +309,14 @@ ca_imsg(struct mproc *p, struct imsg *im
> case IMSG_CA_ECDSA_SIGN:
> m_msg(, imsg);
> m_get_id(, );
> - m_get_string(, );
> + m_get_string(, );
> m_get_data(, , );
> m_end();
>
> - pki = dict_get(env->sc_pki_dict, pkiname);
> - if (pki == NULL || pki->pki_pkey == NULL ||
> - (ecdsa = EVP_PKEY_get1_EC_KEY(pki->pki_pkey)) == NULL)
> - fatalx("ca_imsg: invalid pki");
> + pkey = dict_get(, hash);
> + if (pkey == NULL ||
> + (ecdsa = EVP_PKEY_get1_EC_KEY(pkey)) == NULL)
> + fatalx("ca_imsg: invalid pkey hash");
>
> buf_len = ECDSA_size(ecdsa);
> if ((to = calloc(1, buf_len)) == NULL)
> @@ -350,12 +353,12 @@ rsae_send_imsg(int flen, const unsigned
> struct imsg imsg;
> int n, done = 0;
> const void *toptr;
> - char*pkiname;
> + char*hash;
> size_t tlen;
> struct msg m;
> uint64_t id;
>
> - if ((pkiname = RSA_get_ex_data(rsa, 0)) == NULL)
> + if ((hash = RSA_get_ex_data(rsa, 0)) == NULL)
>
rpki-client parse and check caRepository Subject Information Access
RPKI certificates have 3 possible Subject Information Access URI that we
may be interested in:
- 1.3.6.1.5.5.7.48.5 (caRepository)
- 1.3.6.1.5.5.7.48.10 (rpkiManifest)
- 1.3.6.1.5.5.7.48.13 (rpkiNotify)
rpkiManifest points to the .mft file inside the caRepository.
Because of this caRepository is the base URI for all the files below
this certificate. rpkiNotify points to an RRDP endpoint where the XML
data also contains URI that again need to match the caRepository. If not
something strange is going on.
Since the caRepository data is useful extract it from the cert and also
do a simple strstr() check to ensure that rpkiManifest starts with
caRepository.
Currently the data is not used further than that but I want to add it to
the repository information as a next step.
--
:wq Claudio
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.24
diff -u -p -r1.24 cert.c
--- cert.c 4 Feb 2021 08:58:19 - 1.24
+++ cert.c 5 Feb 2021 13:26:14 -
@@ -194,6 +194,7 @@ sbgp_sia_resource_mft(struct parse *p,
p->fn);
return 0;
}
+
if (strcasecmp(d + dsz - 4, ".mft") != 0) {
warnx("%s: RFC 6487 section 4.8.8: SIA: "
"invalid rsync URI suffix", p->fn);
@@ -214,6 +215,43 @@ sbgp_sia_resource_mft(struct parse *p,
}
/*
+ * Parse the SIA manifest, 4.8.8.1.
+ * Returns zero on failure, non-zero on success.
+ */
+static int
+sbgp_sia_resource_carepo(struct parse *p,
+ const unsigned char *d, size_t dsz)
+{
+ size_t i;
+
+ if (p->res->repo != NULL) {
+ warnx("%s: RFC 6487 section 4.8.8: SIA: "
+ "CA repository already specified", p->fn);
+ return 0;
+ }
+
+ /* Make sure it's an rsync:// address. */
+ if (dsz <= 8 || strncasecmp(d, "rsync://", 8)) {
+ warnx("%s: RFC 6487 section 4.8.8: not using rsync schema",
+ p->fn);
+ return 0;
+ }
+
+ /* make sure only US-ASCII chars are in the URL */
+ for (i = 0; i < dsz; i++) {
+ if (isalnum(d[i]) || ispunct(d[i]))
+ continue;
+ warnx("%s: invalid URI", p->fn);
+ return 0;
+ }
+
+ if ((p->res->repo = strndup((const char *)d, dsz)) == NULL)
+ err(1, NULL);
+
+ return 1;
+}
+
+/*
* Parse the SIA entries, 4.8.8.1.
* There may be multiple different resources at this location, so throw
* out all but the matching resource type. Currently only two entries
@@ -271,11 +309,13 @@ sbgp_sia_resource_entry(struct parse *p,
/*
* Ignore all but manifest and RRDP notify URL.
* Things we may see:
+* - 1.3.6.1.5.5.7.48.5 (caRepository)
* - 1.3.6.1.5.5.7.48.10 (rpkiManifest)
* - 1.3.6.1.5.5.7.48.13 (rpkiNotify)
-* - 1.3.6.1.5.5.7.48.5 (CA repository)
*/
- if (strcmp(buf, "1.3.6.1.5.5.7.48.10") == 0)
+ if (strcmp(buf, "1.3.6.1.5.5.7.48.5") == 0)
+ rc = sbgp_sia_resource_carepo(p, d, plen);
+ else if (strcmp(buf, "1.3.6.1.5.5.7.48.10") == 0)
rc = sbgp_sia_resource_mft(p, d, plen);
else if (strcmp(buf, "1.3.6.1.5.5.7.48.13") == 0)
rc = sbgp_sia_resource_notify(p, d, plen);
@@ -317,6 +357,12 @@ sbgp_sia_resource(struct parse *p, const
goto out;
}
+ if (strstr(p->res->mft, p->res->repo) != p->res->mft) {
+ warnx("%s: RFC 6487 section 4.8.8: SIA: "
+ "conflicting URIs for caRepository and rpkiManifest",
+ p->fn);
+ goto out;
+ }
rc = 1;
out:
sk_ASN1_TYPE_pop_free(seq, ASN1_TYPE_free);
@@ -1172,6 +1218,7 @@ cert_free(struct cert *p)
return;
free(p->crl);
+ free(p->repo);
free(p->mft);
free(p->notify);
free(p->ips);
@@ -1230,6 +1277,7 @@ cert_buffer(struct ibuf *b, const struct
io_str_buffer(b, p->mft);
io_str_buffer(b, p->notify);
+ io_str_buffer(b, p->repo);
io_str_buffer(b, p->crl);
io_str_buffer(b, p->aki);
io_str_buffer(b, p->ski);
@@ -1297,6 +1345,7 @@ cert_read(int fd)
io_str_read(fd, >mft);
assert(p->mft);
io_str_read(fd, >notify);
+ io_str_read(fd, >repo);
io_str_read(fd, >crl);
io_str_read(fd, >aki);
io_str_read(fd, >ski);
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.41
diff -u -p -r1.41 extern.h
--- extern.h4 Feb 2021 14:32:01 - 1.41
+++ extern.h5 Feb 2021 13:20:29 -
@@ -112,6 +112,7 @@ struct cert {
size_t ipsz; /* length of "ips" */
struct cert_as *as; /*
Re: HP 13-w0XX laptop's Realtek ALC295 audio codec - Not all speakers produce sound
On 21/02/03 08:45PM, Eugene Moz. wrote:
> Hello, I'm looking to get quad speakers working on my laptop, only 2
> front speakers are working, 2 back speakers are not. I took a
> peek at /usr/src/sys/dev/pci/azalia_codec.c, my 0x10ec0295 codec doesn't
> have explicit support. I might figure how to add support eventualy, I
> used to run Linux on it. I was using this hda-jack-retask.fw patch to get
> all the speakers working there, if anyone is familiar with this. I'll paste it
> here.
>
> $ cat hda-jack-retask.fv
> [codec]
> 0x10ec0295 0x103c827e 0
>
> [pincfg]
> 0x12 0xb7a60130
> 0x13 0x4000
> 0x14 0x02170150
> 0x16 0x41f0
> 0x17 0x90170110
> 0x18 0x41f0
> 0x19 0x50170110
> 0x1a 0x41f0
> 0x1b 0x41f0
> 0x1d 0x4061
> 0x1e 0x41f0
> 0x21 0x01174150
>
> Would be great to get some tips on this.
>
> # mixerctl -v
> inputs.dac-2:3=158,158
> inputs.dac-0:1=158,158
> record.adc-0:1_mute=off [ off on ]
> record.adc-0:1=124,124
> record.adc-2:3_mute=off [ off on ]
> record.adc-2:3=124,124
> record.adc-4:5_mute=off [ off on ]
> record.adc-4:5=124,124
> inputs.mic=85,85
> outputs.spkr_source=dac-2:3 [ dac-2:3 ]
> outputs.spkr_mute=off [ off on ]
> outputs.spkr_eapd=on [ off on ]
> inputs.mic2=85,85
> outputs.mic2_dir=input-vr80 [ none input input-vr0 input-vr50 input-vr80
> input-vr100 ]
> outputs.hp_source=dac-0:1 [ dac-2:3 dac-0:1 ]
> outputs.hp_mute=off [ off on ]
> outputs.hp_boost=off [ off on ]
> outputs.hp_eapd=on [ off on ]
> record.adc-4:5_source=mic2 { mic2 }
> record.adc-2:3_source=mic2,mic { mic2 mic }
> record.adc-0:1_source=mic [ mic ]
> outputs.mic2_sense=unplugged [ unplugged plugged ]
> outputs.hp_sense=unplugged [ unplugged plugged ]
> outputs.spkr_muters=hp { hp }
> outputs.master=158,158
> outputs.master.mute=off [ off on ]
> outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp { dac-2:3 dac-0:1 spkr hp }
> record.volume=124,124
> record.volume.mute=off [ off on ]
> record.volume.slaves=adc-0:1,adc-2:3,adc-4:5 { adc-0:1 adc-2:3 adc-4:5 mic
> mic2 }
> record.enable=sysctl [ off on sysctl ]
>
> # dmesg
> OpenBSD 6.8-stable (GENERIC.MP) #0: Tue Feb 2 11:53:42 MSK 2021
> u...@lap.lan:/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8446021632 (8054MB)
> avail mem = 8175013888 (7796MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x3b2d5000 (40 entries)
> bios0: vendor American Megatrends Inc. version "F.50" date 12/12/2019
> bios0: HP HP Spectre x360 Convertible 13-w0XX
> acpi0 at bios0: ACPI 6.1
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SSDT MSDM SSDT HPET SSDT
> UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 DMAR NHLT TPM2 ASF! BGRT
> acpi0: wakeup devices PS2K(S3) PS2M(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4)
> RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) RP01(S4) PXSX(S4)
> RP02(S4) PXSX(S4) [...]
> 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) Core(TM) i5-7200U CPU @ 2.50GHz, 3094.06 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,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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,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 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-7200U CPU @ 2.50GHz, 3092.81 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,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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,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-7200U CPU @ 2.50GHz, 3092.80 MHz, 06-8e-09
> cpu2:
>
Re: rpki-client remove debug code
On Thu, Feb 04, 2021 at 06:56:05PM +0100, Claudio Jeker wrote: > This bit of debug code to understand the progress of rpki-client is no > longer helpful. Most of the time this is a stuck rsync that causes delays > and those are now nicely handled by an internal timeout. > I propose to remove this. If no longer find it useful, who will? :) ok tb
Re: broadcast simplex checksum
On Mon, Feb 01, 2021 at 02:04:51AM +0100, Alexander Bluhm wrote:
> On Mon, Feb 01, 2021 at 08:08:56AM +1300, Richard Procter wrote:
> > - Might the rule disabling checksum offload for broadcasts on IFF_SIMPLEX
> > interfaces be weakened to disable checksum offload for all broadcast
> > packets instead?
> > - what motivates the new '!m->m_pkthdr.pf.routed??? term?
I think the best way to answer your questions, is to add a comment
to both if conditions.
ok?
bluhm
Index: net/if_ethersubr.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.268
diff -u -p -r1.268 if_ethersubr.c
--- net/if_ethersubr.c 4 Jan 2021 21:21:41 - 1.268
+++ net/if_ethersubr.c 5 Feb 2021 09:40:46 -
@@ -227,7 +227,11 @@ ether_resolve(struct ifnet *ifp, struct
return (error);
eh->ether_type = htons(ETHERTYPE_IP);
- /* If broadcasting on a simplex interface, loopback a copy */
+ /*
+* If broadcasting on a simplex interface, loopback a copy.
+* The checksum must be calculated in software. Keep the
+* contition in sync with in_ifcap_cksum().
+*/
if (ISSET(m->m_flags, M_BCAST) &&
ISSET(ifp->if_flags, IFF_SIMPLEX) &&
!m->m_pkthdr.pf.routed) {
Index: netinet/ip_output.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.363
diff -u -p -r1.363 ip_output.c
--- netinet/ip_output.c 2 Feb 2021 17:47:42 - 1.363
+++ netinet/ip_output.c 5 Feb 2021 09:38:09 -
@@ -79,6 +79,7 @@ void ip_mloopback(struct ifnet *, struct
static __inline u_int16_t __attribute__((__unused__))
in_cksum_phdr(u_int32_t, u_int32_t, u_int32_t);
void in_delayed_cksum(struct mbuf *);
+int in_ifcap_cksum(struct mbuf *, struct ifnet *, int);
#ifdef IPSEC
struct tdb *
@@ -458,8 +459,7 @@ sendit:
*/
if (ntohs(ip->ip_len) <= mtu) {
ip->ip_sum = 0;
- if ((ifp->if_capabilities & IFCAP_CSUM_IPv4) &&
- (ifp->if_bridgeidx == 0))
+ if (in_ifcap_cksum(m, ifp, IFCAP_CSUM_IPv4))
m->m_pkthdr.csum_flags |= M_IPV4_CSUM_OUT;
else {
ipstat_inc(ips_outswcsum);
@@ -719,9 +719,7 @@ ip_fragment(struct mbuf *m, struct ifnet
m->m_pkthdr.ph_ifidx = 0;
mhip->ip_off = htons((u_int16_t)mhip->ip_off);
mhip->ip_sum = 0;
- if ((ifp != NULL) &&
- (ifp->if_capabilities & IFCAP_CSUM_IPv4) &&
- (ifp->if_bridgeidx == 0))
+ if (in_ifcap_cksum(m, ifp, IFCAP_CSUM_IPv4))
m->m_pkthdr.csum_flags |= M_IPV4_CSUM_OUT;
else {
ipstat_inc(ips_outswcsum);
@@ -740,9 +738,7 @@ ip_fragment(struct mbuf *m, struct ifnet
ip->ip_len = htons((u_int16_t)m->m_pkthdr.len);
ip->ip_off |= htons(IP_MF);
ip->ip_sum = 0;
- if ((ifp != NULL) &&
- (ifp->if_capabilities & IFCAP_CSUM_IPv4) &&
- (ifp->if_bridgeidx == 0))
+ if (in_ifcap_cksum(m, ifp, IFCAP_CSUM_IPv4))
m->m_pkthdr.csum_flags |= M_IPV4_CSUM_OUT;
else {
ipstat_inc(ips_outswcsum);
@@ -1855,15 +1851,15 @@ in_proto_cksum_out(struct mbuf *m, struc
}
if (m->m_pkthdr.csum_flags & M_TCP_CSUM_OUT) {
- if (!ifp || !(ifp->if_capabilities & IFCAP_CSUM_TCPv4) ||
- ip->ip_hl != 5 || ifp->if_bridgeidx != 0) {
+ if (!in_ifcap_cksum(m, ifp, IFCAP_CSUM_TCPv4) ||
+ ip->ip_hl != 5) {
tcpstat_inc(tcps_outswcsum);
in_delayed_cksum(m);
m->m_pkthdr.csum_flags &= ~M_TCP_CSUM_OUT; /* Clear */
}
} else if (m->m_pkthdr.csum_flags & M_UDP_CSUM_OUT) {
- if (!ifp || !(ifp->if_capabilities & IFCAP_CSUM_UDPv4) ||
- ip->ip_hl != 5 || ifp->if_bridgeidx != 0) {
+ if (!in_ifcap_cksum(m, ifp, IFCAP_CSUM_UDPv4) ||
+ ip->ip_hl != 5) {
udpstat_inc(udps_outswcsum);
in_delayed_cksum(m);
m->m_pkthdr.csum_flags &= ~M_UDP_CSUM_OUT; /* Clear */
@@ -1872,4 +1868,23 @@ in_proto_cksum_out(struct mbuf *m, struc
in_delayed_cksum(m);
m->m_pkthdr.csum_flags &= ~M_ICMP_CSUM_OUT; /* Clear */
}
+}
+
+int
+in_ifcap_cksum(struct mbuf *m, struct ifnet *ifp, int ifcap)
+{
+ if ((ifp == NULL) ||
+ !ISSET(ifp->if_capabilities, ifcap) ||
+ (ifp->if_bridgeidx != 0))
+ return (0);
+ /*
+* Simplex interface
Re: uhidpp(4): logitech hid++ device driver
On Fri, Jan 22, 2021 at 08:18:51AM +0100, Anton Lindqvist wrote: > Hi, > Here's a new driver for Logitech HID++ devices, currently limited to > exposing battery sensors. Here's an example using a Logitech M330 mouse: > > $ dmesg | grep uhidpp > uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33 > $ sysctl hw.sensors.uhidpp0 > hw.sensors.uhidpp0.raw0=2 (battery levels) > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK thanks anton, now that this got commited i realize i have a pair of devices: device 1 (M235 according to bottom) previously reported this in dmesg: uhidev0 at uhub0 port 2 configuration 1 interface 0 "Logitech USB Receiver" rev 2.00/12.03 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 uhidev1 at uhub0 port 2 configuration 1 interface 1 "Logitech USB Receiver" rev 2.00/12.03 addr 2 uhidev1: iclass 3/1, 8 report ids ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir wsmouse2 at ums0 mux 0 uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/12.03 addr 2 uhidev2: iclass 3/0, 33 report ids uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0 uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0 uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0 uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0 device 2 (M235 2nd gen according to bottom) previously reported this in dmesg (same thing, but the rev/addr values): uhidev1 at uhub0 port 4 configuration 1 interface 0 "Logitech USB Receiver" rev 2.00/24.07 addr 3 uhidev1: iclass 3/1 ukbd1 at uhidev1: 8 variable keys, 6 key codes wskbd2 at ukbd1 mux 1 uhidev2 at uhub0 port 4 configuration 1 interface 1 "Logitech USB Receiver" rev 2.00/24.07 addr 3 uhidev2: iclass 3/1, 8 report ids ums0 at uhidev2 reportid 2: 16 buttons, Z and W dir wsmouse2 at ums0 mux 0 uhid0 at uhidev2 reportid 3: input=4, output=0, feature=0 uhid1 at uhidev2 reportid 4: input=1, output=0, feature=0 uhid2 at uhidev2 reportid 8: input=1, output=0, feature=0 uhidev3 at uhub0 port 4 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/24.07 addr 3 uhidev3: iclass 3/0, 33 report ids uhid3 at uhidev3 reportid 16: input=6, output=6, feature=0 uhid4 at uhidev3 reportid 17: input=19, output=19, feature=0 uhid5 at uhidev3 reportid 32: input=14, output=14, feature=0 uhid6 at uhidev3 reportid 33: input=31, output=31, feature=0 now device 1/uhidev2 is properly identified by uhidpp: uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/12.03 addr 2 uhidev2: iclass 3/0, 33 report ids uhidpp0 at uhidev2 device 1 mouse "M325" serial 69-b1-af-84 and properly reports sensors: hw.sensors.uhidpp0.raw0=2 (battery levels) hw.sensors.uhidpp0.percent0=70.00% (battery level), OK and device2 (plugged on the same laptop so device renumbered) also works with uhidpp: uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/24.07 addr 2 uhidev2: iclass 3/0, 33 report ids uhidpp0 at uhidev2 device 1 mouse "Wireless Mouse" serial f3-94-18-8c same level reported in sensors for a different mouse (?): hw.sensors.uhidpp0.raw0=2 (battery levels) hw.sensors.uhidpp0.percent0=70.00% (battery level), OK let me know if you need more details/infos from those devices (usbdevs dumps etc..) i'll eventually look at adding support for uhidpp to upower so mouse battery levels can be reported in xfce4-power-manager and gnome, like it does on linux.. Thanks ! Landry
Re: smtpd: use libtls
No much report so far.
Anybody had a chance to test this?
Here is the same diff again with manpage update this time.
Eric.
Index: ca.c
===
RCS file: /cvs/src/usr.sbin/smtpd/ca.c,v
retrieving revision 1.37
diff -u -p -r1.37 ca.c
--- ca.c31 Dec 2020 08:27:15 - 1.37
+++ ca.c19 Jan 2021 11:09:54 -
@@ -69,6 +69,7 @@ static int ecdsae_do_verify(const unsign
EC_KEY *);
+static struct dict pkeys;
static uint64_t reqid = 0;
static void
@@ -132,26 +133,29 @@ ca_init(void)
struct pki *pki;
const char *k;
void*iter_dict;
+ char*hash;
log_debug("debug: init private ssl-tree");
+ dict_init();
iter_dict = NULL;
while (dict_iter(env->sc_pki_dict, _dict, , (void **))) {
if (pki->pki_key == NULL)
continue;
- if ((in = BIO_new_mem_buf(pki->pki_key,
- pki->pki_key_len)) == NULL)
- fatalx("ca_launch: key");
-
- if ((pkey = PEM_read_bio_PrivateKey(in,
- NULL, NULL, NULL)) == NULL)
- fatalx("ca_launch: PEM");
+ in = BIO_new_mem_buf(pki->pki_key, pki->pki_key_len);
+ if (in == NULL)
+ fatalx("ca_init: key");
+ pkey = PEM_read_bio_PrivateKey(in, NULL, NULL, NULL);
+ if (pkey == NULL)
+ fatalx("ca_init: PEM");
BIO_free(in);
- pki->pki_pkey = pkey;
-
- freezero(pki->pki_key, pki->pki_key_len);
- pki->pki_key = NULL;
+ hash = ssl_pubkey_hash(pki->pki_cert, pki->pki_cert_len);
+ if (dict_check(, hash))
+ EVP_PKEY_free(pkey);
+ else
+ dict_xset(, hash, pkey);
+ free(hash);
}
}
@@ -223,15 +227,15 @@ end:
void
ca_imsg(struct mproc *p, struct imsg *imsg)
{
+ EVP_PKEY*pkey;
RSA *rsa = NULL;
EC_KEY *ecdsa = NULL;
const void *from = NULL;
unsigned char *to = NULL;
struct msg m;
- const char *pkiname;
+ const char *hash;
size_t flen, tlen, padding;
int buf_len;
- struct pki *pki;
int ret = 0;
uint64_t id;
int v;
@@ -267,16 +271,15 @@ ca_imsg(struct mproc *p, struct imsg *im
case IMSG_CA_RSA_PRIVDEC:
m_msg(, imsg);
m_get_id(, );
- m_get_string(, );
+ m_get_string(, );
m_get_data(, , );
m_get_size(, );
m_get_size(, );
m_end();
- pki = dict_get(env->sc_pki_dict, pkiname);
- if (pki == NULL || pki->pki_pkey == NULL ||
- (rsa = EVP_PKEY_get1_RSA(pki->pki_pkey)) == NULL)
- fatalx("ca_imsg: invalid pki");
+ pkey = dict_get(, hash);
+ if (pkey == NULL || (rsa = EVP_PKEY_get1_RSA(pkey)) == NULL)
+ fatalx("ca_imsg: invalid pkey hash");
if ((to = calloc(1, tlen)) == NULL)
fatalx("ca_imsg: calloc");
@@ -306,14 +309,14 @@ ca_imsg(struct mproc *p, struct imsg *im
case IMSG_CA_ECDSA_SIGN:
m_msg(, imsg);
m_get_id(, );
- m_get_string(, );
+ m_get_string(, );
m_get_data(, , );
m_end();
- pki = dict_get(env->sc_pki_dict, pkiname);
- if (pki == NULL || pki->pki_pkey == NULL ||
- (ecdsa = EVP_PKEY_get1_EC_KEY(pki->pki_pkey)) == NULL)
- fatalx("ca_imsg: invalid pki");
+ pkey = dict_get(, hash);
+ if (pkey == NULL ||
+ (ecdsa = EVP_PKEY_get1_EC_KEY(pkey)) == NULL)
+ fatalx("ca_imsg: invalid pkey hash");
buf_len = ECDSA_size(ecdsa);
if ((to = calloc(1, buf_len)) == NULL)
@@ -350,12 +353,12 @@ rsae_send_imsg(int flen, const unsigned
struct imsg imsg;
int n, done = 0;
const void *toptr;
- char*pkiname;
+ char*hash;
size_t tlen;
struct msg m;
uint64_t id;
- if ((pkiname = RSA_get_ex_data(rsa, 0)) == NULL)
+ if ((hash = RSA_get_ex_data(rsa, 0)) == NULL)
return (0);
/*
@@ -365,7 +368,7 @@ rsae_send_imsg(int flen, const unsigned
m_create(p_ca, cmd, 0, 0, -1);
reqid++;
