elf(5): mention the ELF machine type EM_AARCH64
ok? Index: share/man/man5/elf.5 === RCS file: /cvs/src/share/man/man5/elf.5,v retrieving revision 1.34 diff -u -p -u -p -r1.34 elf.5 --- share/man/man5/elf.527 Oct 2017 08:36:42 - 1.34 +++ share/man/man5/elf.517 Jun 2019 06:46:19 - @@ -325,6 +325,8 @@ Intel IA-64. AMD64. .It Dv EM_VAX DEC Vax. +.It Dv EM_AARCH64 +ARM 64-bit. .It Dv EM_ALPHA_EXP Compaq [DEC] Alpha with enhanced instruction set. .El
Re: logger(1): add -c option for LOG_CONS
OK kn
Re: logger(1): add -c option for LOG_CONS
Philip Guenther(guent...@gmail.com) on 2019.06.16 12:28:35 -0700:
>
> Testing something else I needed to call syslog(3) with LOG_CONS. Diff
> below adds support to logger(1) for doing that. Option choice is
> compatible with NetBSD.
>
> ok?
sounds useful, -c looks like a good choice too.
ok
>
> Philip Guenther
>
> Index: logger.1
> ===
> RCS file: /data/src/openbsd/src/usr.bin/logger/logger.1,v
> retrieving revision 1.21
> diff -u -p -r1.21 logger.1
> --- logger.1 5 Jun 2013 17:35:12 - 1.21
> +++ logger.1 16 Jun 2019 19:19:26 -
> @@ -38,7 +38,7 @@
> .Nd make entries in the system log
> .Sh SYNOPSIS
> .Nm logger
> -.Op Fl is
> +.Op Fl cis
> .Op Fl f Ar file
> .Op Fl p Ar pri
> .Op Fl t Ar tag
> @@ -52,6 +52,10 @@ system log module.
> .Pp
> The options are as follows:
> .Bl -tag -width "-f file"
> +.It Fl c
> +If unable to pass the message to
> +.Xr syslogd 8 ,
> +attempt to write the message to the console.
> .It Fl f Ar file
> Read from the specified
> .Ar file .
> @@ -102,5 +106,5 @@ utility is compliant with the
> specification.
> .Pp
> The flags
> -.Op Fl ifpst
> +.Op Fl cfipst
> are extensions to that specification.
> Index: logger.c
> ===
> RCS file: /data/src/openbsd/src/usr.bin/logger/logger.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 logger.c
> --- logger.c 28 Mar 2016 18:18:52 - 1.17
> +++ logger.c 16 Jun 2019 19:18:33 -
> @@ -61,8 +61,11 @@ main(int argc, char *argv[])
> tag = NULL;
> pri = LOG_NOTICE;
> logflags = 0;
> - while ((ch = getopt(argc, argv, "f:ip:st:")) != -1)
> + while ((ch = getopt(argc, argv, "cf:ip:st:")) != -1)
> switch(ch) {
> + case 'c': /* log to console */
> + logflags |= LOG_CONS;
> + break;
> case 'f': /* file to log */
> if (freopen(optarg, "r", stdin) == NULL) {
> (void)fprintf(stderr, "logger: %s: %s.\n",
> @@ -180,6 +183,6 @@ void
> usage(void)
> {
> (void)fprintf(stderr,
> - "usage: logger [-is] [-f file] [-p pri] [-t tag] [message ...]\n");
> + "usage: logger [-cis] [-f file] [-p pri] [-t tag] [message ...]\n");
> exit(1);
> }
>
Re: update: libXext 1.3.4
On Mon, Jun 10, 2019 at 10:01:59AM +0200, Matthieu Herrb wrote: > Hi, > > another update: libXext 1.3.4. No real bug fixes though. > > ok ? ok tb I tested this together with the libXcomposite, libXcursor, libXdamage, libXext updates on my main laptop without noticing any regressions. The diffs look good. I will add your other diffs in my next snap build and provide feedback once they're tested.
Re: update libXdamage 1.1.5
On Mon, Jun 10, 2019 at 06:43:25PM +0200, Matthieu Herrb wrote: > Hi, > > last update of the current batch : libXdamage 1.1.5 > > ok ? ok tb
Re: update: libXcursor 1.2.0
On Mon, Jun 10, 2019 at 06:42:19PM +0200, Matthieu Herrb wrote: > Hi, > > another update : libXcursor 1.2.0 > > ok ? ok tb
Re: update: libXcomposite 0.45
On Mon, Jun 10, 2019 at 06:41:24PM +0200, Matthieu Herrb wrote: > Hi, > > a another quite boring update to libXcomposte 0.4.5. > > ok? ok tb
logger(1): add -c option for LOG_CONS
Testing something else I needed to call syslog(3) with LOG_CONS. Diff
below adds support to logger(1) for doing that. Option choice is
compatible with NetBSD.
ok?
Philip Guenther
Index: logger.1
===
RCS file: /data/src/openbsd/src/usr.bin/logger/logger.1,v
retrieving revision 1.21
diff -u -p -r1.21 logger.1
--- logger.15 Jun 2013 17:35:12 - 1.21
+++ logger.116 Jun 2019 19:19:26 -
@@ -38,7 +38,7 @@
.Nd make entries in the system log
.Sh SYNOPSIS
.Nm logger
-.Op Fl is
+.Op Fl cis
.Op Fl f Ar file
.Op Fl p Ar pri
.Op Fl t Ar tag
@@ -52,6 +52,10 @@ system log module.
.Pp
The options are as follows:
.Bl -tag -width "-f file"
+.It Fl c
+If unable to pass the message to
+.Xr syslogd 8 ,
+attempt to write the message to the console.
.It Fl f Ar file
Read from the specified
.Ar file .
@@ -102,5 +106,5 @@ utility is compliant with the
specification.
.Pp
The flags
-.Op Fl ifpst
+.Op Fl cfipst
are extensions to that specification.
Index: logger.c
===
RCS file: /data/src/openbsd/src/usr.bin/logger/logger.c,v
retrieving revision 1.17
diff -u -p -r1.17 logger.c
--- logger.c28 Mar 2016 18:18:52 - 1.17
+++ logger.c16 Jun 2019 19:18:33 -
@@ -61,8 +61,11 @@ main(int argc, char *argv[])
tag = NULL;
pri = LOG_NOTICE;
logflags = 0;
- while ((ch = getopt(argc, argv, "f:ip:st:")) != -1)
+ while ((ch = getopt(argc, argv, "cf:ip:st:")) != -1)
switch(ch) {
+ case 'c': /* log to console */
+ logflags |= LOG_CONS;
+ break;
case 'f': /* file to log */
if (freopen(optarg, "r", stdin) == NULL) {
(void)fprintf(stderr, "logger: %s: %s.\n",
@@ -180,6 +183,6 @@ void
usage(void)
{
(void)fprintf(stderr,
- "usage: logger [-is] [-f file] [-p pri] [-t tag] [message ...]\n");
+ "usage: logger [-cis] [-f file] [-p pri] [-t tag] [message ...]\n");
exit(1);
}
Re: ssh-askpass(1): fix indicator size with multiple screens
On Sun, Jun 16, 2019 at 09:55:24PM +1000, Damien Miller wrote: > > > On Sun, 16 Jun 2019, Matthieu Herrb wrote: > > > On Sun, Jun 09, 2019 at 04:47:53PM +0200, Matthieu Herrb wrote: > > > Hi, > > > > > > ssh-askpass(1) is trying to be clever and computes the size of its > > > indicator relatively to the screen resolution. > > > > > > Unfortunatly, when multiple screens are present, this gets ugly. The > > > support for Xinerama correctly computes the dimensions of the window > > > to be created, relatively to the screen on which it will appear, but > > > the computation of the indicator size is based on the size of the > > > whole display, resulting in too small indicators (and too many of them > > > if the screens hare layed out horizontally). > > > > > > The patch below fixes that by computing the resolution of the whole > > > display before taking xinerama into account. > > > > > > A better fix would be to make this application really aware of XRandR > > > and use the actual screen resolution from XRandR; this is an > > > interesting project, if anyone wants to give it a try. > > > > > > ok? > > > > ping > > ok djm. Thanks, > Is there an upstream for ssh-askpass? The old one I have > http://www.jmknoble.net/software/x11-ssh-askpass/ doesn't resolve any more. I have the same (dead) reference in /usr/xenocara/3RDPARTY and google can't find any newer home, except https://github.com/sigmavirus24/x11-ssh-askpass but it's just a mirror of the original code, without anything new. -- Matthieu Herrb
Re: acme-client(1): elliptic curve account key
On Sun, Jun 16, 2019 at 09:25:45AM +0200, Florian Obser wrote:
> On Sat, Jun 15, 2019 at 06:20:49PM +0200, Florian Obser wrote:
> > OK?
>
> update to apply cleanly on -current
The acctproc.c change looks ok with some minor comments inline.
I haven't tried to verify the JSON stuff.
>
> diff --git acctproc.c acctproc.c
> index 52309b765d5..09ac8c83372 100644
> --- acctproc.c
> +++ acctproc.c
> @@ -24,6 +24,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -90,6 +91,42 @@ op_thumb_rsa(EVP_PKEY *pkey)
> return json;
> }
>
> +/*
> + * Extract the relevant EC components from the key and create the JSON
> + * thumbprint from them.
> + */
> +static char *
> +op_thumb_ec(EVP_PKEY *pkey)
> +{
> + BIGNUM *X = NULL, *Y = NULL;
> + EC_KEY *ec = NULL;
> + char*x = NULL, *y = NULL;
> + char*json = NULL;
> +
> + if ((ec = EVP_PKEY_get1_EC_KEY(pkey)) == NULL)
I would suggest using get0 as in the RSA case ...
> + warnx("EVP_PKEY_get1_EC_KEY");
> + else if ((X = BN_new()) == NULL)
> + warnx("BN_new");
> + else if ((Y = BN_new()) == NULL)
> + warnx("BN_new");
> + else if (!EC_POINT_get_affine_coordinates_GFp(EC_KEY_get0_group(ec),
> + EC_KEY_get0_public_key(ec), X, Y, NULL))
> + warnx("EC_POINT_get_affine_coordinates_GFp");
> + else if ((x = bn2string(X)) == NULL)
> + warnx("bn2string");
> + else if ((y = bn2string(Y)) == NULL)
> + warnx("bn2string");
> + else if ((json = json_fmt_thumb_ec(x, y)) == NULL)
> + warnx("json_fmt_thumb_rsa");
> +
> + EC_KEY_free(ec);
...and drop this EC_KEY_free()
> + BN_free(X);
> + BN_free(Y);
> + free(x);
> + free(y);
> + return json;
> +}
> +
> /*
> * The thumbprint operation is used for the challenge sequence.
> */
> @@ -109,6 +146,10 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
> if ((thumb = op_thumb_rsa(pkey)) != NULL)
> break;
> goto out;
> + case EVP_PKEY_EC:
> + if ((thumb = op_thumb_ec(pkey)) != NULL)
> + break;
> + goto out;
> default:
> warnx("EVP_PKEY_type: unknown key type");
> goto out;
> @@ -183,6 +224,42 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char
> *nonce, const char *url)
> return rc;
> }
>
> +static int
> +op_sign_ec(char **prot, EVP_PKEY *pkey, const char *nonce, const char *url)
> +{
> + BIGNUM *X = NULL, *Y = NULL;
> + EC_KEY *ec = NULL;
> + char*x = NULL, *y = NULL;
> + int rc = 0;
> +
> + *prot = NULL;
> +
> + if ((ec = EVP_PKEY_get1_EC_KEY(pkey)) == NULL)
> + warnx("EVP_PKEY_get1_EC_KEY");
same here: get0...
> + else if ((X = BN_new()) == NULL)
> + warnx("BN_new");
> + else if ((Y = BN_new()) == NULL)
> + warnx("BN_new");
> + else if (!EC_POINT_get_affine_coordinates_GFp(EC_KEY_get0_group(ec),
> + EC_KEY_get0_public_key(ec), X, Y, NULL))
> + warnx("EC_POINT_get_affine_coordinates_GFp");
> + else if ((x = bn2string(X)) == NULL)
> + warnx("bn2string");
> + else if ((y = bn2string(Y)) == NULL)
> + warnx("bn2string");
> + else if ((*prot = json_fmt_protected_ec(x, y, nonce, url)) == NULL)
> + warnx("json_fmt_protected_ec");
> + else
> + rc = 1;
> +
> + EC_KEY_free(ec);
... and omit EC_KEY_free()
> + BN_free(X);
> + BN_free(Y);
> + free(x);
> + free(y);
> + return rc;
> +}
> +
> /*
> * Operation to sign a message with the account key.
> * This requires the sender ("fd") to provide the payload and a nonce.
> @@ -190,14 +267,19 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char
> *nonce, const char *url)
> static int
> op_sign(int fd, EVP_PKEY *pkey, enum acctop op)
> {
> - char*nonce = NULL, *pay = NULL, *pay64 = NULL;
> - char*prot = NULL, *prot64 = NULL;
> - char*sign = NULL, *dig64 = NULL, *fin = NULL;
> - char*url = NULL, *kid = NULL;
> - unsigned char *dig = NULL;
> - EVP_MD_CTX *ctx = NULL;
> - int cc, rc = 0;
> - unsigned int digsz;
> + EVP_MD_CTX *ctx = NULL;
> + const EVP_MD*evp_md = NULL;
> + EC_KEY *ec;
> + ECDSA_SIG *ec_sig = NULL;
> + const BIGNUM*ec_sig_r = NULL, *ec_sig_s = NULL;
> + int cc, rc = 0;
> + unsigned int digsz, bufsz, degree, bn_len, r_len, s_len;
> + char*nonce = NULL, *pay = NULL, *pay64 = NULL;
> + char*prot = NULL, *prot64 = NULL;
> + char*sign = NULL, *dig64 = NULL, *fin = NULL;
> + char*url = NULL, *kid = NULL, *alg = NULL;
> + unsigned c
Re: new env defaults for doas
Martijn van Duren wrote:
> > 2. When doing keepenv, nothing changes, except addition of above.
>
> It feels inconsistent to make keepenv behave different here.
> - It may allow certain applications to behave unexpected compared to
> without keepenv (e.g. scripts that use $HOME/.cache).
> - The values are hard to retrofit into doas.conf by the end-user, while
> it's easy to keep the original with setenv { HOME ... }.
Yes, I think it's better to always reset these things. Here's a diff.
1. Always set HOME, PATH, SHELL etc to the target.
2. Without keepenv, other environment variables are discarded.
3. With keepenv, other variables are retained, but the above are still reset.
4. Possible to override this with setenv.
This is much more consistent and predictable.
Index: doas.conf.5
===
RCS file: /cvs/src/usr.bin/doas/doas.conf.5,v
retrieving revision 1.36
diff -u -p -r1.36 doas.conf.5
--- doas.conf.5 16 Jun 2019 18:16:34 - 1.36
+++ doas.conf.5 16 Jun 2019 18:20:20 -
@@ -54,6 +54,14 @@ The default is to reset the environment,
.Ev DISPLAY
and
.Ev TERM .
+The variables
+.Ev HOME ,
+.Ev LOGNAME ,
+.Ev PATH ,
+.Ev SHELL ,
+and
+.Ev USER
+are always reset.
.It Ic setenv { Oo Ar variable ... Oc Oo Ar variable=value ... Oc Ic }
In addition to the variables mentioned above, keep the space-separated
specified variables.
Index: env.c
===
RCS file: /cvs/src/usr.bin/doas/env.c,v
retrieving revision 1.7
diff -u -p -r1.7 env.c
--- env.c 16 Jun 2019 18:16:34 - 1.7
+++ env.c 16 Jun 2019 18:20:20 -
@@ -85,6 +85,10 @@ static struct env *
createenv(const struct rule *rule, const struct passwd *mypw,
const struct passwd *targpw)
{
+ static const char *copyset[] = {
+ "DISPLAY", "TERM",
+ NULL
+ };
struct env *env;
u_int i;
@@ -95,6 +99,13 @@ createenv(const struct rule *rule, const
env->count = 0;
addnode(env, "DOAS_USER", mypw->pw_name);
+ addnode(env, "HOME", targpw->pw_dir);
+ addnode(env, "LOGNAME", targpw->pw_name);
+ addnode(env, "PATH", getenv("PATH"));
+ addnode(env, "SHELL", targpw->pw_shell);
+ addnode(env, "USER", targpw->pw_name);
+
+ fillenv(env, copyset);
if (rule->options & KEEPENV) {
extern const char **environ;
@@ -124,19 +135,6 @@ createenv(const struct rule *rule, const
env->count++;
}
}
- } else {
- static const char *copyset[] = {
- "DISPLAY", "TERM",
- NULL
- };
-
- addnode(env, "HOME", targpw->pw_dir);
- addnode(env, "LOGNAME", targpw->pw_name);
- addnode(env, "PATH", getenv("PATH"));
- addnode(env, "SHELL", targpw->pw_shell);
- addnode(env, "USER", targpw->pw_name);
-
- fillenv(env, copyset);
}
return env;
Re: drm(4), multi-threaded task queues and barriers
Mark Kettenis on Thu, Jun 13 2019: > So here is a diff that fixes the problem as far as I can tell. > Jonathan, Sven, can you give this a go? Works for me. > + tq->tq_waiting++; > msleep(tq, &tq->tq_mtx, PWAIT, "bored", 0); > + tq->tq_waiting--; Heh, didn't spot this either. State machines are hard. :) Regards.
Re: [patch] make bioctl(8) print the correct error
*bump*
On Fri, May 24, 2019 at 07:17:29PM +0200, Jesper Wallin wrote:
> Hi tech@
>
> A few days ago, I decided to set kern.securelevel=2 just for the sake
> of locking down my machine as much as possible. Today I learned that
> this affects bioctl(8) when trying to attach a crypto RAID.
>
> So, bioctl(8) gave me "softraid0: invalid metadata format" and I had
> a minor panic attack, thinking my backup disk was corrupt. I then
> remembered increasing securelevel and tried again with a lower value.
>
> This patch makes sr_meta_probe() print an error if the device can't
> be opened with read/write. It also returns SR_META_F_NOOPEN to
> prevent giving the normal SR_META_F_INVALID error. I guess the error
> could be moved to the function above, but then we don't know the
> device name.
>
>
> Jesper Wallin
>
>
> Index: sys/dev/softraid.c
> ===
> RCS file: /cvs/src/sys/dev/softraid.c,v
> retrieving revision 1.394
> diff -u -p -r1.394 softraid.c
> --- sys/dev/softraid.c18 May 2019 14:02:27 - 1.394
> +++ sys/dev/softraid.c24 May 2019 10:57:50 -
> @@ -337,10 +337,9 @@ sr_meta_probe(struct sr_discipline *sd,
>*/
> error = VOP_OPEN(vn, FREAD | FWRITE, NOCRED, curproc);
> if (error) {
> - DNPRINTF(SR_D_META,"%s: sr_meta_probe can't "
> - "open %s\n", DEVNAME(sc), devname);
> + sr_error(sc, "sr_meta_probe can't open %s",
> devname);
> vput(vn);
> - goto unwind;
> + return (SR_META_F_NOOPEN);
> }
>
> strlcpy(ch_entry->src_devname, devname,
> @@ -3365,8 +3364,8 @@ sr_ioctl_createraid(struct sr_softc *sc,
> sr_error(sc, "invalid metadata format");
> goto unwind;
> }
> -
> - if (sr_meta_attach(sd, no_chunk, bc->bc_flags & BIOC_SCFORCE))
> + if (sd->sd_meta_type == SR_META_F_NOOPEN ||
> + sr_meta_attach(sd, no_chunk, bc->bc_flags & BIOC_SCFORCE))
> goto unwind;
>
> /* force the raid volume by clearing metadata region */
> Index: sys/dev/softraidvar.h
> ===
> RCS file: /cvs/src/sys/dev/softraidvar.h,v
> retrieving revision 1.168
> diff -u -p -r1.168 softraidvar.h
> --- sys/dev/softraidvar.h 6 Jan 2019 14:59:56 - 1.168
> +++ sys/dev/softraidvar.h 24 May 2019 10:57:50 -
> @@ -102,6 +102,7 @@ struct sr_crypto_kdfpair {
>
> #define SR_META_F_NATIVE 0 /* Native metadata format. */
> #define SR_META_F_INVALID-1
> +#define SR_META_F_NOOPEN -2
>
> #define SR_HEADER_SIZE (SR_META_SIZE + SR_BOOT_SIZE)
> #define SR_DATA_OFFSET (SR_META_OFFSET + SR_HEADER_SIZE)
>
Re: ssh-askpass(1): fix indicator size with multiple screens
On Sun, 16 Jun 2019, Matthieu Herrb wrote: > On Sun, Jun 09, 2019 at 04:47:53PM +0200, Matthieu Herrb wrote: > > Hi, > > > > ssh-askpass(1) is trying to be clever and computes the size of its > > indicator relatively to the screen resolution. > > > > Unfortunatly, when multiple screens are present, this gets ugly. The > > support for Xinerama correctly computes the dimensions of the window > > to be created, relatively to the screen on which it will appear, but > > the computation of the indicator size is based on the size of the > > whole display, resulting in too small indicators (and too many of them > > if the screens hare layed out horizontally). > > > > The patch below fixes that by computing the resolution of the whole > > display before taking xinerama into account. > > > > A better fix would be to make this application really aware of XRandR > > and use the actual screen resolution from XRandR; this is an > > interesting project, if anyone wants to give it a try. > > > > ok? > > ping ok djm. Is there an upstream for ssh-askpass? The old one I have http://www.jmknoble.net/software/x11-ssh-askpass/ doesn't resolve any more. -d
Re: patch axen(4) (WIP)
hi,
On 2019/02/26 14:00, Nils Frohberg wrote:
> On Mon, Feb 25, 2019 at 03:50:48PM -0300, Martin Pieuchot wrote:
>> On 25/02/19(Mon) 14:52, Nils Frohberg wrote:
[snip]
>>> I didn't get around to much testing/debugging lately, therefore I
>>> wanted to share the current state (diff below).
>>>
>>> The current state works a lot better than previously (for me). I
>>> used to have a huge amount of ierrs (aprrox. 1 ierr per ipkt) and
>>> often no packets would be transferred at all (or stop being transferred
>>> after some time).
>>
>> Do you know why? What were the problems?
>
> I'm not 100% sure, since I did a lot of back and forth. It finally
> got better once I disabled EEE and lowered the watermark levels.
I run my axen + your [1-7]/7 patches on amd64 with ehci,
that is, on high-speed.
When I ping to another host, it drops 20-30% of receiving packets.
It looks like the txeof does its job but the rxeof is not called
when packets arrive.
(debug messages and tcpdump on another host says so).
I checked each difference of diffs and found out that the initial
bufsz value in attach causes the drops.
I reverted like as following diff, it works correctly without drops
even the BUFSZ of HS is lower than bufsz of qctrl of HS.
Thoughts?
--- sys/dev/usb/if_axenreg.hSun Jun 16 00:48:48 2019
+++ sys/dev/usb/if_axenreg.hSun Jun 16 00:49:24 2019
@@ -13,7 +13,7 @@
#define AXEN_MCAST_FILTER_SIZE 8
/* unit: KB */
#define AXEN_BUFSZ_LS 0x18
-#define AXEN_BUFSZ_HS 0x16
+#define AXEN_BUFSZ_HS 0x10
#define AXEN_BUFSZ_SS 0x12
#define AXEN_BUFSZ_MAX AXEN_BUFSZ_LS
--- sys/dev/usb/if_axen.c Wed Jun 12 12:52:01 2019
+++ sys/dev/usb/if_axen.c Sun Jun 16 00:50:08 2019
@@ -690,8 +695,10 @@ axen_attach(struct device *parent, struct device *self
* this will be updated once the link state changes
*/
switch (sc->axen_udev->speed) {
- case USB_SPEED_FULL:
case USB_SPEED_HIGH:
+ sc->axen_bufsz = AXEN_BUFSZ_HS * 1024;
+ break;
+ case USB_SPEED_FULL:
case USB_SPEED_SUPER:
/* linux adds 2 to the buffer size (why?) */
sc->axen_bufsz = (AXEN_BUFSZ_MAX + 2) * 1024;
>>> This box hosts backups (rsync and TimeMachine), so it gets its fair
>>> share of traffic. I could reduce the ierrs to ~2100 with 5d uptime,
>>> and the packets keep flowing:
>>>
>>> $ netstat -niI axen0
>>> NameMtu Network Address Ipkts IerrsOpkts Oerrs
>>> Colls
>>> axen0 150094:c6:91:1f:85:a5 141199356 2099 112289969 0
>>> 0
>>> $ uptime
>>> 7:15PM up 5 days, 9:57, 3 users, load averages: 0.11, 0.13, 0.14
>>> $
>>>
>>> But there a still a few problems:
>>>
>>> 1) There are still ierrs. These happen when the rx path can't
>>> allocate mbufs (cf. diff below for DPRINTF):
>>> axen0: could not allocate rx mbuf (2 total, 2 remaining)
>>> axen0: could not allocate rx mbuf (3 total, 3 remaining)
>>> axen0: could not allocate rx mbuf (2 total, 2 remaining)
>>> axen0: could not allocate rx mbuf (1 total, 1 remaining)
>>
>> Look at the pools when this happen, what do you see? What is the size
>> of `pkt_len' when this happen?
>
> I added pkt_len to the DPRINTF so that I can check the relevant
> pools once I see this error.
>
>>> 2) If the adapter is plugged into a USB 3 port at boot, it will
>>> return 0x42 when aked for AXEN_PHYSICAL_LINK_STATUS, ie.
>>> (AXEN_EPHY_1000|AXEN_USB_HS). The adapter most often then simply
>>> doesn't receive packets. If I plug in the adapter after boot is
>>> complete, 0x44 is returned (AXEN_EPHY_1000|AXEN_USB_SS), as expected.
>>> I'm not sure if I'm still missing something in init (probably) or
>>> if this results from something higher in the stack (xhci?).
>>> (Didn't test USB 2 or lower.)
>>
>> Do you see any difference in 'usbdevs -vv' output during the two cases?
>
> Yes, high speed vs super speed and power draw:
>
> # Plugged in after boot:
>
> $ usbdevs -vv
> Controller /dev/usb0:
> addr 01: 8086: Intel, xHCI root hub
>super speed, self powered, config 1, rev 1.00
>driver: uhub0
>port 01: 0001.02a0 power Rx.detect
>port 02: 0011.02a0 power Rx.detect
>port 03: .0503 connect enabled recovery
>port 04: .0503 connect enabled recovery
>port 05: .02a0 power Rx.detect
>port 06: .02a0 power Rx.detect
>port 07: .02a0 power Rx.detect
>port 08: .0103 connect enabled recovery
>port 09: .02a0 power Rx.detect
>port 10: .0203 connect enabled power U0
>port 11: .0203 connect enabled power U0
>port 12: .0203 connect enabled power U0
>port 13: .02a0 power Rx.detect
>port 14: .02a0 power Rx.detect
>port 15: .02a0 power Rx.detect
> addr 04: 0bc2:ab44 Seagate, Backup+ Hub
>high speed, self powered, config 1, rev 48.85, iSerial 01
Re: patch axen(4) (WIP)
hi,
On 2019/02/28 06:53, Nils Frohberg wrote:
> On Tue, Feb 26, 2019 at 08:57:57PM +0200, Artturi Alm wrote:
>> On Tue, Feb 26, 2019 at 03:00:15PM +0100, Nils Frohberg wrote:
[snip]
>> Have you looked at what NetBSD has done with their axen(4)? there has
>> been 20commits in 2019 so far[0], while some of them are possibly,
>> idk., useless to us(thinking about hw checksum offloading), there was
>> some bug fixes that did look relevant to me, but i succesfully
>> installed&built kernels on nfs over axen(4) a couple of weeks ago,
>> so the bugs it has didn't feel critical enough for me to make
>> a branch for them. that was on arm64/dwctwo(4), tbh. i haven't been
>> happy with axen(4) on amd64/{e,x}hci(4) myself in the past either. :]
>
> I wrote the diff last December. I looked at NetBSD's code back then,
> but they didn't have any significant changes.
>
> At a cursory glance, many changes are similar to mine. But there are
> a few things that should be worth looking at.
Do you see the link status LED of axen is down when ifconfig it up/down?
The attached patch should fix that bug.
I applied the diff of NetBSD's if_axen.c between rev 1.20 and 1.21
https://github.com/NetBSD/src/commit/4603809d1167ab5cc2d8d35f95722aec85789fd0#diff-4748c3be63ca566d4a07520285f031a9
to if_axen.c of 6.5-current with [1-7]/7 patches.
The log reads:
> Enable AXEN_RXCTL_START bit only when RX is ready. Otherwise,
> the adapter eventually falls into "no carrier" state while it
> is not running.
I reverted 3/7 partially to keep previous value of AXEN_MAC_RXCTL reg,
so that RXCTL_START is set only in axen_init and is reset in axen_stop.
axen_reset does not initialise the chip any more.
It does nothing but delay.
The chip init, axen_ax88179_init, is called once while attach.
--- sys/dev/usb/if_axen.c Wed Jun 12 12:52:01 2019
+++ sys/dev/usb/if_axen.c Thu Jun 13 09:19:32 2019
@@ -421,7 +421,10 @@ axen_iff(struct axen_softc *sc)
/* Enable receiver, set RX mode */
axen_lock_mii(sc);
- rxmode = AXEN_RXCTL_DROPCRCERR | AXEN_RXCTL_START;
+ axen_cmd(sc, AXEN_CMD_MAC_READ2, 2, AXEN_MAC_RXCTL, &wval);
+ rxmode = UGETW(wval);
+ rxmode &= ~(AXEN_RXCTL_ACPT_ALL_MCAST | AXEN_RXCTL_PROMISC |
+ AXEN_RXCTL_ACPT_MCAST);
ifp->if_flags &= ~IFF_ALLMULTI;
/*
@@ -476,8 +479,6 @@ axen_reset(struct axen_softc *sc)
/* Wait a little while for the chip to get its brains in order. */
DELAY(1000);
- axen_ax88179_init(sc);
-
return;
}
@@ -486,7 +487,7 @@ axen_ax88179_init(struct axen_softc *sc)
{
uWord wval;
uByte val;
- u_int16_t ctl, temp;
+ u_int16_t ctl, rxmode, temp;
DPRINTFN(2,("%s: %s: enter\n", sc->axen_dev.dv_xname,__func__));
@@ -565,6 +566,10 @@ axen_ax88179_init(struct axen_softc *sc)
axen_cmd(sc, AXEN_CMD_MAC_WRITE, 1, AXEN_PAUSE_HIGH_WATERMARK, &val);
/* Set RX/TX configuration. */
+ rxmode = AXEN_RXCTL_DROPCRCERR;
+ USETW(wval, rxmode);
+ axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MAC_RXCTL, &wval);
+
#ifdef AXEN_TOE
/* enable offloading */
val = AXEN_RXCOE_IPv4 |
@@ -1566,7 +1571,7 @@ axen_stop(struct axen_softc *sc)
usbd_status err;
struct ifnet*ifp;
int i;
- u_int16_t ctl;
+ u_int16_t ctl, rxmode;
uWord wval;
DPRINTFN(2,("%s: %s: enter\n", sc->axen_dev.dv_xname,__func__));
@@ -1578,7 +1583,13 @@ axen_stop(struct axen_softc *sc)
timeout_del(&sc->axen_stat_ch);
- /* disable receive */
+ /* Disable receiver, set RX mode */
+ axen_cmd(sc, AXEN_CMD_MAC_READ2, 2, AXEN_MAC_RXCTL, &wval);
+ rxmode = UGETW(&wval);
+ rxmode &= ~AXEN_RXCTL_START;
+ USETW(wval, rxmode);
+ axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MAC_RXCTL, &wval);
+
axen_cmd(sc, AXEN_CMD_MAC_READ2, 2, AXEN_MEDIUM_STATUS, &wval);
ctl = UGETW(wval);
ctl &= ~AXEN_MEDIUM_RECV_EN;
>> I guess i'm trying to say maybe it wouldn't hurt to sync a bit before
>> deviating as much as atleast your whole WIP diff did. I haven't read
>> your separate patches yet, but i'll try to get around to also testing
>> those before weekend:]
>
> The separate patches are (more or less) the big patch split up via
> $(git add -p). There are a few things that might be worth looking
> into, such as the pause water levels, enabling EEE, axen_bulk_size
> values, buffer sizes, ...
>
> More testing would be great. Especially since this is the only box
> I have where I can attach it to xhci.
>
>> -Artturi
>>
>> [0] https://github.com/NetBSD/src/commits/trunk/sys/dev/usb/if_axen.c
>>
>
Re: libXfont2: disable font server code
On Sun, Jun 09, 2019 at 07:22:26PM +0200, Matthieu Herrb wrote: > Hi, > > We disabled almost all X font server support code already. The patch > below removes support for connecting to a font server from libXfont2. > > It means that you X server will no longer be able to use fonts from a > remote font server. But did you even know this was possible ? > > ok? comments? ping > > Index: Makefile.bsd-wrapper > === > RCS file: /cvs/OpenBSD/xenocara/lib/libXfont2/Makefile.bsd-wrapper,v > retrieving revision 1.2 > diff -u -r1.2 Makefile.bsd-wrapper > --- Makefile.bsd-wrapper 26 May 2018 07:51:00 - 1.2 > +++ Makefile.bsd-wrapper 9 Jun 2019 17:15:38 - > @@ -3,6 +3,6 @@ > > SHARED_LIBS= Xfont2 1.0 > > -CONFIGURE_ARGS+= --with-xmlto=no --disable-devel-docs > +CONFIGURE_ARGS+= --disable-fc --with-xmlto=no --disable-devel-docs > > .include > > -- > Matthieu Herrb -- Matthieu Herrb
Re: ssh-askpass(1): fix indicator size with multiple screens
On Sun, Jun 09, 2019 at 04:47:53PM +0200, Matthieu Herrb wrote:
> Hi,
>
> ssh-askpass(1) is trying to be clever and computes the size of its
> indicator relatively to the screen resolution.
>
> Unfortunatly, when multiple screens are present, this gets ugly. The
> support for Xinerama correctly computes the dimensions of the window
> to be created, relatively to the screen on which it will appear, but
> the computation of the indicator size is based on the size of the
> whole display, resulting in too small indicators (and too many of them
> if the screens hare layed out horizontally).
>
> The patch below fixes that by computing the resolution of the whole
> display before taking xinerama into account.
>
> A better fix would be to make this application really aware of XRandR
> and use the actual screen resolution from XRandR; this is an
> interesting project, if anyone wants to give it a try.
>
> ok?
ping
>
> Index: x11-ssh-askpass.c
> ===
> RCS file: /cvs/OpenBSD/xenocara/app/ssh-askpass/x11-ssh-askpass.c,v
> retrieving revision 1.6
> diff -u -p -u -r1.6 x11-ssh-askpass.c
> --- x11-ssh-askpass.c 24 Apr 2015 02:19:41 - 1.6
> +++ x11-ssh-askpass.c 9 Jun 2019 14:32:59 -
> @@ -1507,6 +1507,12 @@ int main(int argc, char **argv)
> app.screen_height = HeightOfScreen(app.screen);
> app.screen_xoffset = 0;
> app.screen_yoffset = 0;
> +
> + app.xResolution =
> + app.screen_width * 1000 / WidthMMOfScreen(app.screen);
> + app.yResolution =
> + app.screen_height * 1000 / HeightMMOfScreen(app.screen);
> +
> if (XineramaIsActive(app.dpy) &&
>(screens = XineramaQueryScreens(app.dpy, &nscreens)) != NULL &&
>nscreens) {
> @@ -1516,11 +1522,6 @@ int main(int argc, char **argv)
>app.screen_yoffset = screens[0].y_org;
>XFree(screens);
> }
> -
> - app.xResolution =
> - app.screen_width * 1000 / WidthMMOfScreen(app.screen);
> - app.yResolution =
> - app.screen_height * 1000 / HeightMMOfScreen(app.screen);
>
> createDialog(&app);
> createGCs(&app);
>
> --
> Matthieu Herrb
--
Matthieu Herrb
Re: acme-client(1): don't leak RSA keys
On Sun, Jun 16, 2019 at 10:05:55AM +0200, Florian Obser wrote:
> I'm not sure why we use get1 and not get0.
> get0 should be ok here, no?
>
> Someone in the know please apply a clue bat, thanks.
Since the references are local to the functions and there are no
threads, no-one's going to invalidate the reference underneath you,
so get0 (without matching RSA_free()) would be ok.
Your diff is ok, too.
>
> diff --git acctproc.c acctproc.c
> index 09ac8c83372..fd0a22629db 100644
> --- acctproc.c
> +++ acctproc.c
> @@ -86,6 +86,7 @@ op_thumb_rsa(EVP_PKEY *pkey)
> else if ((json = json_fmt_thumb_rsa(exp, mod)) == NULL)
> warnx("json_fmt_thumb_rsa");
>
> + RSA_free(r);
> free(exp);
> free(mod);
> return json;
> @@ -219,6 +220,7 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char
> *nonce, const char *url)
> else
> rc = 1;
>
> + RSA_free(r);
> free(exp);
> free(mod);
> return rc;
>
>
> --
> I'm not entirely sure you are real.
>
acme-client(1): don't leak RSA keys
I'm not sure why we use get1 and not get0.
get0 should be ok here, no?
Someone in the know please apply a clue bat, thanks.
diff --git acctproc.c acctproc.c
index 09ac8c83372..fd0a22629db 100644
--- acctproc.c
+++ acctproc.c
@@ -86,6 +86,7 @@ op_thumb_rsa(EVP_PKEY *pkey)
else if ((json = json_fmt_thumb_rsa(exp, mod)) == NULL)
warnx("json_fmt_thumb_rsa");
+ RSA_free(r);
free(exp);
free(mod);
return json;
@@ -219,6 +220,7 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char *nonce,
const char *url)
else
rc = 1;
+ RSA_free(r);
free(exp);
free(mod);
return rc;
--
I'm not entirely sure you are real.
acme-client(1): use unveil(2) instead of chroot(2)
This uses less code and unveil(2) seems to be the better tool here.
There is probably nothing wrong with the chroot code because of pledge
but it still makes me feel uneasy.
The directory one chroots into needs to be carefully setup (they are
not) and comon wisedom is that root can break out of chroots.
Again, pledge probably takes away all the necessary tools to mess with
the chroot...
OK?
diff --git chngproc.c chngproc.c
index 218b608000d..bb3cea6710e 100644
--- chngproc.c
+++ chngproc.c
@@ -36,14 +36,12 @@ chngproc(int netsock, const char *root)
enum chngop op;
void *pp;
- if (chroot(root) == -1) {
- warn("chroot");
- goto out;
- }
- if (chdir("/") == -1) {
- warn("chdir");
+
+ if (unveil(root, "rwc") == -1) {
+ warn("unveil");
goto out;
}
+
if (pledge("stdio cpath wpath", NULL) == -1) {
warn("pledge");
goto out;
@@ -80,6 +78,11 @@ chngproc(int netsock, const char *root)
else if ((tok = readstr(netsock, COMM_TOK)) == NULL)
goto out;
+ if (asprintf(&fmt, "%s.%s", tok, th) == -1) {
+ warn("asprintf");
+ goto out;
+ }
+
/* Vector appending... */
pp = reallocarray(fs, (fsz + 1), sizeof(char *));
@@ -88,14 +91,13 @@ chngproc(int netsock, const char *root)
goto out;
}
fs = pp;
- fs[fsz] = tok;
- tok = NULL;
- fsz++;
-
- if (asprintf(&fmt, "%s.%s", fs[fsz - 1], th) == -1) {
+ if (asprintf(&fs[fsz], "%s/%s", root, tok) == -1) {
warn("asprintf");
goto out;
}
+ fsz++;
+ free(tok);
+ tok = NULL;
/*
* Create and write to our challenge file.
@@ -121,7 +123,7 @@ chngproc(int netsock, const char *root)
free(fmt);
th = fmt = NULL;
- dodbg("%s/%s: created", root, fs[fsz - 1]);
+ dodbg("%s: created", fs[fsz - 1]);
/*
* Write our acknowledgement.
diff --git extern.h extern.h
index 7fcbf77d88f..ae18b133b29 100644
--- extern.h
+++ extern.h
@@ -203,8 +203,8 @@ int acctproc(int, const char *, enum keytype);
int certproc(int, int);
int chngproc(int, const char *);
int dnsproc(int);
-int revokeproc(int, const char *, const char *,
- int, int, const char *const *, size_t);
+int revokeproc(int, const char *, int, int, const char *const *,
+ size_t);
int fileproc(int, const char *, const char *, const char *,
const char *);
int keyproc(int, const char *, const char **, size_t,
diff --git fileproc.c fileproc.c
index 00ce339670a..c09da6244ac 100644
--- fileproc.c
+++ fileproc.c
@@ -86,12 +86,8 @@ fileproc(int certsock, const char *certdir, const char
*certfile, const char
long lval;
enum fileop op;
- if (chroot(certdir) == -1) {
- warn("chroot");
- goto out;
- }
- if (chdir("/") == -1) {
- warn("chdir");
+ if (unveil(certdir, "rwc") == -1) {
+ warn("unveil");
goto out;
}
@@ -129,27 +125,26 @@ fileproc(int certsock, const char *certdir, const char
*certfile, const char
if (FILE_REMOVE == op) {
if (certfile) {
if (unlink(certfile) == -1 && errno != ENOENT) {
- warn("%s/%s", certdir, certfile);
+ warn("%s", certfile);
goto out;
} else
- dodbg("%s/%s: unlinked", certdir, certfile);
+ dodbg("%s: unlinked", certfile);
}
if (chainfile) {
if (unlink(chainfile) == -1 && errno != ENOENT) {
- warn("%s/%s", certdir, chainfile);
+ warn("%s", chainfile);
goto out;
} else
- dodbg("%s/%s: unlinked", certdir, chainfile);
+ dodbg("%s: unlinked", chainfile);
}
if (fullchainfile) {
if (unlink(fullchainfile) == -1 && errno != ENOENT) {
- warn("%s/%s", certdir, fullchainfile);
+ warn("%s", fullchainfile);
goto out;
} else
-
Re: acme-client(1): elliptic curve account key
On Sat, Jun 15, 2019 at 06:20:49PM +0200, Florian Obser wrote:
> OK?
update to apply cleanly on -current
diff --git acctproc.c acctproc.c
index 52309b765d5..09ac8c83372 100644
--- acctproc.c
+++ acctproc.c
@@ -24,6 +24,7 @@
#include
#include
+#include
#include
#include
#include
@@ -90,6 +91,42 @@ op_thumb_rsa(EVP_PKEY *pkey)
return json;
}
+/*
+ * Extract the relevant EC components from the key and create the JSON
+ * thumbprint from them.
+ */
+static char *
+op_thumb_ec(EVP_PKEY *pkey)
+{
+ BIGNUM *X = NULL, *Y = NULL;
+ EC_KEY *ec = NULL;
+ char*x = NULL, *y = NULL;
+ char*json = NULL;
+
+ if ((ec = EVP_PKEY_get1_EC_KEY(pkey)) == NULL)
+ warnx("EVP_PKEY_get1_EC_KEY");
+ else if ((X = BN_new()) == NULL)
+ warnx("BN_new");
+ else if ((Y = BN_new()) == NULL)
+ warnx("BN_new");
+ else if (!EC_POINT_get_affine_coordinates_GFp(EC_KEY_get0_group(ec),
+ EC_KEY_get0_public_key(ec), X, Y, NULL))
+ warnx("EC_POINT_get_affine_coordinates_GFp");
+ else if ((x = bn2string(X)) == NULL)
+ warnx("bn2string");
+ else if ((y = bn2string(Y)) == NULL)
+ warnx("bn2string");
+ else if ((json = json_fmt_thumb_ec(x, y)) == NULL)
+ warnx("json_fmt_thumb_rsa");
+
+ EC_KEY_free(ec);
+ BN_free(X);
+ BN_free(Y);
+ free(x);
+ free(y);
+ return json;
+}
+
/*
* The thumbprint operation is used for the challenge sequence.
*/
@@ -109,6 +146,10 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
if ((thumb = op_thumb_rsa(pkey)) != NULL)
break;
goto out;
+ case EVP_PKEY_EC:
+ if ((thumb = op_thumb_ec(pkey)) != NULL)
+ break;
+ goto out;
default:
warnx("EVP_PKEY_type: unknown key type");
goto out;
@@ -183,6 +224,42 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char
*nonce, const char *url)
return rc;
}
+static int
+op_sign_ec(char **prot, EVP_PKEY *pkey, const char *nonce, const char *url)
+{
+ BIGNUM *X = NULL, *Y = NULL;
+ EC_KEY *ec = NULL;
+ char*x = NULL, *y = NULL;
+ int rc = 0;
+
+ *prot = NULL;
+
+ if ((ec = EVP_PKEY_get1_EC_KEY(pkey)) == NULL)
+ warnx("EVP_PKEY_get1_EC_KEY");
+ else if ((X = BN_new()) == NULL)
+ warnx("BN_new");
+ else if ((Y = BN_new()) == NULL)
+ warnx("BN_new");
+ else if (!EC_POINT_get_affine_coordinates_GFp(EC_KEY_get0_group(ec),
+ EC_KEY_get0_public_key(ec), X, Y, NULL))
+ warnx("EC_POINT_get_affine_coordinates_GFp");
+ else if ((x = bn2string(X)) == NULL)
+ warnx("bn2string");
+ else if ((y = bn2string(Y)) == NULL)
+ warnx("bn2string");
+ else if ((*prot = json_fmt_protected_ec(x, y, nonce, url)) == NULL)
+ warnx("json_fmt_protected_ec");
+ else
+ rc = 1;
+
+ EC_KEY_free(ec);
+ BN_free(X);
+ BN_free(Y);
+ free(x);
+ free(y);
+ return rc;
+}
+
/*
* Operation to sign a message with the account key.
* This requires the sender ("fd") to provide the payload and a nonce.
@@ -190,14 +267,19 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char
*nonce, const char *url)
static int
op_sign(int fd, EVP_PKEY *pkey, enum acctop op)
{
- char*nonce = NULL, *pay = NULL, *pay64 = NULL;
- char*prot = NULL, *prot64 = NULL;
- char*sign = NULL, *dig64 = NULL, *fin = NULL;
- char*url = NULL, *kid = NULL;
- unsigned char *dig = NULL;
- EVP_MD_CTX *ctx = NULL;
- int cc, rc = 0;
- unsigned int digsz;
+ EVP_MD_CTX *ctx = NULL;
+ const EVP_MD*evp_md = NULL;
+ EC_KEY *ec;
+ ECDSA_SIG *ec_sig = NULL;
+ const BIGNUM*ec_sig_r = NULL, *ec_sig_s = NULL;
+ int cc, rc = 0;
+ unsigned int digsz, bufsz, degree, bn_len, r_len, s_len;
+ char*nonce = NULL, *pay = NULL, *pay64 = NULL;
+ char*prot = NULL, *prot64 = NULL;
+ char*sign = NULL, *dig64 = NULL, *fin = NULL;
+ char*url = NULL, *kid = NULL, *alg = NULL;
+ unsigned char *dig = NULL, *buf = NULL;
+ const unsigned char *digp;
/* Read our payload and nonce from the requestor. */
@@ -219,8 +301,23 @@ op_sign(int fd, EVP_PKEY *pkey, enum acctop op)
goto out;
}
+ switch (EVP_PKEY_type(pkey->type)) {
+ case EVP_PKEY_RSA:
+ alg = "RS256";
+ evp_md = EVP_sha256();
+ break;
