xonly on amd64: testing wanted

2023-01-14 Thread Theo de Raadt
Some of you have probably noticed activity about "xonly" happening
to a bunch of architectures.  First arm64, then riscv64, then hppa,
and ongoing efforts with octeon, sparc64 (sun4u only), and more of this
is going to come in the future.

Like past work decades ago (and I suppose continually also) on W^X, and
increasing use of .rodata, the idea here is to have code (text segments)
not be readable.  Or in a more generic sense, if you mprotect a region
with only PROT_EXEC, it is not readable.

This has a number of nice characteristics.  It makes BROP techniques not
work as well (when accompanied by the effects of many other migitations),
it makes complex gadgets containing side effects harder to use (if the
registers involved in the side effect contain pointers to code), etc etc.

But most of us have amd64 machines.  Thrilling news:

It turns out we can do this fairly modern modern 64-bit x86 machines
from Intel and AMD, if operating in LONG mode, aka. amd64.  The cpu
needs to have a feature called PKU.  The way this works is not 100%
perfect, but it a serious enough hinderance.  A PKU memory key is
instantiated for all memory which is PROT_EXEC-only, and that key is
told to block memory reads.  Instruction reads are still permitted.  Now
some of you may know how PKU works, so you will say that userland can
change the behaviour and make the memory readable.  That is true.  Until
a system call happens.  Then we force it back to blocking read.  Or a
memory fault, we force it back.  Or an interrupt, even a clock
interrupt.  We force it back.  Generally if an attacker is trying to
read code it is because they don't have a lot of (turing complete or a
subset) of flexibility and want more information.  Imagine they are able
to generate a the "wrpkru" sequence to disable it, and then do something
else?  My guess is if they can do two things in a row, then they already
have power, and won't be doing this.  So this is a protection method
against a lower-level attack construction.  The concept is this:  If you
can bypass this to gain a tiny foothold, you would not have bothered,
because you have more power and would be reaching higher. 

As I mention, some other architectures have crossed already, but not
without little bits of pain.  Especially in the ports tree, where
unprepared code is more common.  Mostly this consists of assembly language
files that have put read-only data into the .text region, instead of into
the .rodata (some people still haven't read the memos from around 1997).

So I'd like to recruit some help from those of you capable of building
your own kernels.  Can you apply the following kernel diff, and try the
applications you are used to.  A list of applications that fail on some
way would be handy.  Be sure to ktrace -di then, and check there is a
SIGSEGV near the end, and include a snippet of that information.

If you don't know how to do this, please don't ask for help.  Just let
others do it.

The kernel diff isn't perfect yet, because it is less than 24 hours
since this started working.  But it appears good enough for testing,
while we work out the wrinkles.

After the kernel diff are two additional diffs, which can be done
independently

1) you can recompile gnu/usr.bin/clang to get a new linker that
defaults to --execute-only libraries and binaries, and competely
cross over

2) the shared library linker ld.so also needs a tweak


And after that, a silly test program, which generates this before:

  userland   kernel
ld.so   0x59bd652920  readable   readable  
mmap xz 0x5a08e6d000  unreadable unreadable
mmap x  0x5a33152000  readable   readable  
mmap nrx0x597c8af000  readable   readable  
mmap nwx0x5988309000  readable   readable  
mmap xnwx   0x59e6118000  readable   readable  
main0x5773dfe390  readable   readable  
libc0x5a2ec49b00  readable   readable  

and after:

  userland   kernel
ld.so  0x9476e6f36a0  unreadable unreadable
mmap xz0x947e5bb3000  unreadable unreadable
mmap x 0x947bc6ba000  unreadable unreadable
mmap nrx   0x947d07fa000  unreadable unreadable
mmap nwx   0x947bc631000  unreadable unreadable
mmap xnwx  0x947a2aa9000  unreadable unreadable
main   0x9455cc2e490  unreadable unreadable
libc   0x9476b5f8a60  unreadable unreadable






Index: sys/arch/amd64/amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.163
diff -u -p -u -r1.163 cpu.c
--- sys/arch/amd64/amd64/cpu.c  29 Nov 2022 21:41:39 -  1.163
+++ sys/arch/amd64/amd64/cpu.c  14 Jan 2023 05:46:34 -
@@ -735,6 +735,8 @@ cpu_init(struct cpu_info *ci)
cr4 |= CR4_SMAP;
if 

Re: openssh: update ed25519 and squash into a single file

2023-01-14 Thread Tobias Heider
On Sat, Jan 14, 2023 at 04:29:04PM +1100, Damien Miller wrote:
> 
> 
> On Fri, 13 Jan 2023, Damien Miller wrote:
> 
> > Hi,
> > 
> > Forewarning: this is a big, noisy diff. Also on Github at
> > https://github.com/djmdjm/openssh-wip/pull/18
> > 
> > This updates the ED25519 code to the latest version of SUPERCOP (20221122),
> > but the real motivation for this is to move the ED25519 code to the same
> > approach we use for the Streamlined NTRUPrime code: using a shell-script
> > to extract the bits we want from SUPERCOP and squish them all into a
> > single file.
> > 
> > This removes a bunch of exported function names, a bit of unused
> > code and means that all the ED25519 code is in a single file rather
> > than eight.
> > 
> > To review this, it's probably best to run the shellscript locally
> > (use sh ed25519.sh /path/to/directory/with/supercop) and inspect the
> > output. Apart from the original ed25519.c (assembled from the keypair.c,
> > sign.c and open.c files in SUPERCOP) there are no substantial changes.
> 
> Here's a better way to look at the substantive changes:
> 
> 1. Assemble the existing ed25519 code in the same order as how this
>patch arranges things:
> 
> cat verify.c fe25519.h fe25519.c sc25519.h sc25519.c \
> ge25519.h ge25519.c ed25519.c | \
> sed -e '/#include "ge25519_base.data"/r ge25519_base.data' \
> -e '/#include.*/d'  > ed25519.c.old
> 
> 2. Apply the patch
> 
> 3. Diff the original and new code (below)
> 
> This isn't completely without noise, but it lets you see the substantive
> changes clearly.
> 
> -d

works and looks a lot cleaner than before.

ok tobhe@

> 
> 
> 
> 
> --- /tmp/ed25519.cSat Jan 14 16:25:09 2023
> +++ ed25519.c Sat Jan 14 16:25:41 2023
> @@ -1,12 +1,30 @@
> -/* $OpenBSD: verify.c,v 1.3 2013/12/09 11:03:45 markus Exp $ */
> +/*  $OpenBSD: $ */
>  
>  /*
> - * Public Domain, Author: Daniel J. Bernstein
> - * Copied from nacl-20110221/crypto_verify/32/ref/verify.c
> + * Public Domain, Authors:
> + * - Daniel J. Bernstein
> + * - Niels Duif
> + * - Tanja Lange
> + * - lead: Peter Schwabe
> + * - Bo-Yin Yang
>   */
>  
> +#include 
>  
> -int crypto_verify_32(const unsigned char *x,const unsigned char *y)
> +#include "crypto_api.h"
> +
> +#define int8 crypto_int8
> +#define uint8 crypto_uint8
> +#define int16 crypto_int16
> +#define uint16 crypto_uint16
> +#define int32 crypto_int32
> +#define uint32 crypto_uint32
> +#define int64 crypto_int64
> +#define uint64 crypto_uint64
> +
> +/* from supercop-20221122/crypto_verify/32/ref/verify.c */
> +
> +static int crypto_verify_32(const unsigned char *x,const unsigned char *y)
>  {
>unsigned int differentbits = 0;
>  #define F(i) differentbits |= x[i] ^ y[i];
> @@ -44,14 +62,7 @@
>F(31)
>return (1 & ((differentbits - 1) >> 8)) - 1;
>  }
> -/* $OpenBSD: fe25519.h,v 1.3 2013/12/09 11:03:45 markus Exp $ */
> -
> -/*
> - * Public Domain, Authors: Daniel J. Bernstein, Niels Duif, Tanja Lange,
> - * Peter Schwabe, Bo-Yin Yang.
> - * Copied from supercop-20130419/crypto_sign/ed25519/ref/fe25519.h
> - */
> -
> +/* from supercop-20221122/crypto_sign/ed25519/ref/fe25519.h */
>  #ifndef FE25519_H
>  #define FE25519_H
>  
> @@ -80,52 +91,45 @@
>  }
>  fe25519;
>  
> -void fe25519_freeze(fe25519 *r);
> +static void fe25519_freeze(fe25519 *r);
>  
> -void fe25519_unpack(fe25519 *r, const unsigned char x[32]);
> +static void fe25519_unpack(fe25519 *r, const unsigned char x[32]);
>  
> -void fe25519_pack(unsigned char r[32], const fe25519 *x);
> +static void fe25519_pack(unsigned char r[32], const fe25519 *x);
>  
> -int fe25519_iszero(const fe25519 *x);
> +static int fe25519_iszero(const fe25519 *x);
>  
> -int fe25519_iseq_vartime(const fe25519 *x, const fe25519 *y);
> +static int fe25519_iseq_vartime(const fe25519 *x, const fe25519 *y);
>  
> -void fe25519_cmov(fe25519 *r, const fe25519 *x, unsigned char b);
> +static void fe25519_cmov(fe25519 *r, const fe25519 *x, unsigned char b);
>  
> -void fe25519_setone(fe25519 *r);
> +static void fe25519_setone(fe25519 *r);
>  
> -void fe25519_setzero(fe25519 *r);
> +static void fe25519_setzero(fe25519 *r);
>  
> -void fe25519_neg(fe25519 *r, const fe25519 *x);
> +static void fe25519_neg(fe25519 *r, const fe25519 *x);
>  
>  unsigned char fe25519_getparity(const fe25519 *x);
>  
> -void fe25519_add(fe25519 *r, const fe25519 *x, const fe25519 *y);
> +static void fe25519_add(fe25519 *r, const fe25519 *x, const fe25519 *y);
>  
> -void fe25519_sub(fe25519 *r, const fe25519 *x, const fe25519 *y);
> +static void fe25519_sub(fe25519 *r, const fe25519 *x, const fe25519 *y);
>  
> -void fe25519_mul(fe25519 *r, const fe25519 *x, const fe25519 *y);
> +static void fe25519_mul(fe25519 *r, const fe25519 *x, const fe25519 *y);
>  
> -void fe25519_square(fe25519 *r, const fe25519 *x);
> +static void fe25519_square(fe25519 *r, const fe25519 *x);
>  
> -void fe25519_invert(fe25519 *r, const fe25519 *x);
> +static void fe25519_invert(fe25519 *r, const 

don't remove known vmd vm's on failure

2023-01-14 Thread Dave Voutila
It turns out not only does vmd have numerous error paths for handling
when something is amiss with a guest, most of the paths don't check if
it's a known vm defined in vm.conf.

As a result, vmd often removes the vm from the SLIST of vm's meaning
one can't easily attempt to start it again or see it in vmctl's status
output.

A simple reproduction:

  1. define a vm with memory > 4gb in vm.conf
  2. run vmd in the foreground (doas vmd -d) so it's not started by rc.d
  3. try to start with `vmctl start -c ${vm_name}`, you should trigger
 an ENOMEM and get the "Cannot allocate memory" message from vmctl.
  4. try to start the same vm again...now you get EPERM!
  5. the vm is no longer visible in the output from `vmctl status` :(

The problem is most of the error paths call vm_remove, which not only
tears down the vm via vm_stop, but also removes it from the vm list and
frees it. Only clean stops or restarts seem to perform this check
currently.

Below diff refactors into checking if the vm is defined in the global
config before deciding to call vm_stop or vm_remove.

ok?
-dv


diff refs/heads/master refs/heads/vmd-accounting
commit - d4e23fe7544b01187ebf3ac8ae32e955445ee666
commit + 46503195403bfab50cd34bd8682f35a17d54d03d
blob - 6bffb2519a31464836aa573dbccb7aa14ea97722
blob + f30dc14de1ff9d5cf121cbc08b6db183a06d0c07
--- usr.sbin/vmd/vmd.c
+++ usr.sbin/vmd/vmd.c
@@ -67,6 +67,8 @@ struct vmd*env;
 int vm_claimid(const char *, int, uint32_t *);
 voidstart_vm_batch(int, short, void*);

+static inline void vm_terminate(struct vmd_vm *, const char *);
+
 struct vmd *env;

 static struct privsep_proc procs[] = {
@@ -395,14 +397,14 @@ vmd_dispatch_vmm(int fd, struct privsep_proc *p, struc
errno = vmr.vmr_result;
log_warn("%s: failed to forward vm result",
vcp->vcp_name);
-   vm_remove(vm, __func__);
+   vm_terminate(vm, __func__);
return (-1);
}
}

if (vmr.vmr_result) {
log_warnx("%s: failed to start vm", vcp->vcp_name);
-   vm_remove(vm, __func__);
+   vm_terminate(vm, __func__);
errno = vmr.vmr_result;
break;
}
@@ -410,7 +412,7 @@ vmd_dispatch_vmm(int fd, struct privsep_proc *p, struc
/* Now configure all the interfaces */
if (vm_priv_ifconfig(ps, vm) == -1) {
log_warn("%s: failed to configure vm", vcp->vcp_name);
-   vm_remove(vm, __func__);
+   vm_terminate(vm, __func__);
break;
}

@@ -441,10 +443,7 @@ vmd_dispatch_vmm(int fd, struct privsep_proc *p, struc
log_info("%s: sent vm %d successfully.",
vm->vm_params.vmc_params.vcp_name,
vm->vm_vmid);
-   if (vm->vm_from_config)
-   vm_stop(vm, 0, __func__);
-   else
-   vm_remove(vm, __func__);
+   vm_terminate(vm, __func__);
}

/* Send a response if a control client is waiting for it */
@@ -470,10 +469,7 @@ vmd_dispatch_vmm(int fd, struct privsep_proc *p, struc
}
if (vmr.vmr_result != EAGAIN ||
vm->vm_params.vmc_bootdevice) {
-   if (vm->vm_from_config)
-   vm_stop(vm, 0, __func__);
-   else
-   vm_remove(vm, __func__);
+   vm_terminate(vm, __func__);
} else {
/* Stop VM instance but keep the tty open */
vm_stop(vm, 1, __func__);
@@ -509,7 +505,7 @@ vmd_dispatch_vmm(int fd, struct privsep_proc *p, struc
imsg->hdr.peerid, -1, , sizeof(vir)) == -1) {
log_debug("%s: GET_INFO_VM failed for vm %d, removing",
__func__, vm->vm_vmid);
-   vm_remove(vm, __func__);
+   vm_terminate(vm, __func__);
return (-1);
}
break;
@@ -545,7 +541,7 @@ vmd_dispatch_vmm(int fd, struct privsep_proc *p, struc
sizeof(vir)) == -1) {
log_debug("%s: GET_INFO_VM_END failed",
__func__);
-   vm_remove(vm, __func__);
+   vm_terminate(vm, __func__);
return (-1);
}
}
@@ -1943,3 +1943,14 

typo in if_urtwn.c

2023-01-14 Thread Mikhail


diff /usr/src
commit - 810555b25bf5444b727efabdb7f5ed0506159a65
path + /usr/src
blob - a615fdea5fca69bcd980bdc027050f59be89d0ed
file + sys/dev/usb/if_urtwn.c
--- sys/dev/usb/if_urtwn.c
+++ sys/dev/usb/if_urtwn.c
@@ -1659,7 +1659,7 @@ urtwn_tx(void *cookie, struct mbuf *m, struct ieee8021
qos = ieee80211_get_qos(wh);
tid = qos & IEEE80211_QOS_TID;
qid = ieee80211_up_to_ac(ic, tid);
-   } else if ((wh->i_fc[1] & IEEE80211_FC0_TYPE_MASK)
+   } else if ((wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK)
!= IEEE80211_FC0_TYPE_DATA) {
/* Use AC VO for management frames. */
qid = EDCA_AC_VO;



Re: only open /dev/vmm once in vmd(8)

2023-01-14 Thread Dave Voutila


Dave Voutila  writes:

> During h2k22 there was some discussion around how vmd(8) manages vms and
> the vmm(4) device's role. While looking into something related, I found
> vmd opens /dev/vmm in each subprocess during the initial fork+execve
> dance.
>
> The only vmd process that needs /dev/vmm is the vmm process.
>
> The diff below changes it so that *only* the parent process opens
> /dev/vmm and then uses fd passing to send it to the vmm process once
> fork+exec'd. This adds a new imsg type specific to this handoff.
>
> The other processes don't end up with the vmm pledge, so there's no
> reason they need open file descriptors to the vmm device.
>
> OK?

ping... Haven't seen any negative reports and I've been working on other
things atop this diff for a few weeks now. Any OKs or objections?

>
>
> diff refs/heads/master refs/heads/vmd-vmm-open
> commit - adc9c11636d08981539860c611938338c714d31e
> commit + 1bb17c1c2d6cd28c231fa2eb6f8494e5498bb1a3
> blob - bd0d8580ffc25d905e5f20c1de5044397ddf313d
> blob + 41e4b7b5852c7523a7b1c0e3a73591638a9c9e56
> --- usr.sbin/vmd/vmd.c
> +++ usr.sbin/vmd/vmd.c
> @@ -847,8 +847,8 @@ main(int argc, char **argv)
>   proc_priv->p_pw = _privpw; /* initialized to all 0 */
>   proc_priv->p_chroot = ps->ps_pw->pw_dir; /* from VMD_USER */
>
> - /* Open /dev/vmm */
> - if (env->vmd_noaction == 0) {
> + /* Open /dev/vmm early. */
> + if (env->vmd_noaction == 0 && proc_id == PROC_PARENT) {
>   env->vmd_fd = open(VMM_NODE, O_RDWR);
>   if (env->vmd_fd == -1)
>   fatal("%s", VMM_NODE);
> @@ -971,6 +971,10 @@ vmd_configure(void)
>   exit(0);
>   }
>
> + /* Send VMM device fd to vmm proc. */
> + proc_compose_imsg(>vmd_ps, PROC_VMM, -1,
> + IMSG_VMDOP_RECEIVE_VMM_FD, -1, env->vmd_fd, NULL, 0);
> +
>   /* Send shared global configuration to all children */
>   if (config_setconfig(env) == -1)
>   return (-1);
> blob - c27d03df7336a2c8ede22ec0d83b74d327fb3244
> blob + 2ca4aa336bf68b0d8bf8183e92c9d0ef99d5411e
> --- usr.sbin/vmd/vmd.h
> +++ usr.sbin/vmd/vmd.h
> @@ -108,6 +108,7 @@ enum imsg_type {
>   IMSG_VMDOP_GET_INFO_VM_DATA,
>   IMSG_VMDOP_GET_INFO_VM_END_DATA,
>   IMSG_VMDOP_LOAD,
> + IMSG_VMDOP_RECEIVE_VMM_FD,
>   IMSG_VMDOP_RELOAD,
>   IMSG_VMDOP_PRIV_IFDESCR,
>   IMSG_VMDOP_PRIV_IFADD,
> blob - 6c2bdbd12a3ee11aa88055200e11e0f2a0ff667f
> blob + 2f82a241c1c1672770529ef98f9b748714512704
> --- usr.sbin/vmd/vmm.c
> +++ usr.sbin/vmd/vmm.c
> @@ -94,9 +94,6 @@ vmm_run(struct privsep *ps, struct privsep_proc *p, vo
>*/
>   if (pledge("stdio vmm sendfd recvfd proc", NULL) == -1)
>   fatal("pledge");
> -
> - /* Get and terminate all running VMs */
> - get_info_vm(ps, NULL, 1);
>  }
>
>  int
> @@ -315,6 +312,14 @@ vmm_dispatch_parent(int fd, struct privsep_proc *p, st
>   imsg->hdr.type, imsg->hdr.peerid, imsg->hdr.pid,
>   imsg->fd, , sizeof(var));
>   break;
> + case IMSG_VMDOP_RECEIVE_VMM_FD:
> + if (env->vmd_fd > -1)
> + fatalx("already received vmm fd");
> + env->vmd_fd = imsg->fd;
> +
> + /* Get and terminate all running VMs */
> + get_info_vm(ps, NULL, 1);
> + break;
>   default:
>   return (-1);
>   }



Re: ifconfig description for wireguard peers

2023-01-14 Thread Theo de Raadt
Stuart Henderson  wrote:

> : Index: share/man/man4/wg.4
> : ===
> : RCS file: /cvs/src/share/man/man4/wg.4,v
> : retrieving revision 1.10
> : diff -u -p -u -r1.10 wg.4
> : --- share/man/man4/wg.4 14 Mar 2021 10:08:38 -  1.10
> : +++ share/man/man4/wg.4 24 Dec 2022 00:49:05 -
> : @@ -42,6 +42,19 @@ configuration file for
> :  .Xr netstart 8 .
> :  The interface itself can be configured with
> :  .Xr ifconfig 8 .
> : +To display
> : +.Cm wgpeer
> : +information for each
> : +.Nm wg
> : +interface option
> : +.Fl A
> : +to
> : +.Xr ifconfig 8
> : +should be used or
> : +.Nm wg
> : +interface should be specified as an argument to
> : +.Xr ifconfig 8
> : +command.
> :  .Pp
> :  .Nm wg
> :  interfaces support the following
> 
> This isn't directly related to the descr diff so should be a separate
> commit if done.
> 
> This diff displays like so:
> 
> -
>  The interfaces can be created at runtime using the ifconfig wgN create
>  command or by setting up a hostname.if(5) configuration file for
>  netstart(8).  The interface itself can be configured with ifconfig(8).
>  To display wgpeer information for each wg interface option -A to
>  ifconfig(8) should be used or wg interface should be specified as an
>  argument to ifconfig(8) command.
>  [...]
> -
> 
> I find this new text a bit confusing really, and really it's more
> general to ifconfig rather than specific to wg, so I'm not sure how
> much explanation is really needed in wg(4). How about just adding
> a couple of lines to Examples instead?
> 
> Index: wg.4
> ===
> RCS file: /cvs/src/share/man/man4/wg.4,v
> retrieving revision 1.10
> diff -u -p -r1.10 wg.4
> --- wg.4  14 Mar 2021 10:08:38 -  1.10
> +++ wg.4  14 Jan 2023 14:24:58 -
> @@ -164,6 +164,11 @@ which resides in the default
>  Show the listening sockets:
>  .Pp
>  .Dl $ netstat -ln
> +.Pp
> +Show full information for peers on a single interface, or all interfaces:
> +.Pp
> +.Dl # ifconfig wg1
> +.Dl # ifconfig -A
>  .Sh DIAGNOSTICS
>  The
>  .Nm

Or just skip all this text explaining how to use ifconfig, because people
need to learn how to use ifconfig from the ifconfig manual page.



Re: ifconfig description for wireguard peers

2023-01-14 Thread Stuart Henderson
On 2023/01/12 04:49, Mikolaj Kucharski wrote:
> Hi,
> 
> Is there anything else which I can do, to help this diff reviwed and
> increase the chance of getting in?
> 
> Thread at https://marc.info/?t=16347829861=1=2
> 
> Last version of the diff at
> https://marc.info/?l=openbsd-tech=167185582521873=mbox

Inlining that for a few comments, otherwise it's ok sthen

: Index: sbin/ifconfig/ifconfig.c
: ===
: RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
: retrieving revision 1.460
: diff -u -p -u -r1.460 ifconfig.c
: --- sbin/ifconfig/ifconfig.c  18 Dec 2022 18:56:38 -  1.460
: +++ sbin/ifconfig/ifconfig.c  24 Dec 2022 00:49:05 -
: @@ -355,12 +355,14 @@ voidsetwgpeerep(const char *, const cha
:  void setwgpeeraip(const char *, int);
:  void setwgpeerpsk(const char *, int);
:  void setwgpeerpka(const char *, int);
: +void setwgpeerdesc(const char *, int);
:  void setwgport(const char *, int);
:  void setwgkey(const char *, int);
:  void setwgrtable(const char *, int);
:  
:  void unsetwgpeer(const char *, int);
:  void unsetwgpeerpsk(const char *, int);
: +void unsetwgpeerdesc(const char *, int);
:  void unsetwgpeerall(const char *, int);
:  
:  void wg_status(int);
: @@ -623,11 +625,13 @@ const structcmd {
:   { "wgaip",  NEXTARG,A_WIREGUARD,setwgpeeraip},
:   { "wgpsk",  NEXTARG,A_WIREGUARD,setwgpeerpsk},
:   { "wgpka",  NEXTARG,A_WIREGUARD,setwgpeerpka},
: + { "wgdesc", NEXTARG,A_WIREGUARD,setwgpeerdesc},
:   { "wgport", NEXTARG,A_WIREGUARD,setwgport},
:   { "wgkey",  NEXTARG,A_WIREGUARD,setwgkey},
:   { "wgrtable",   NEXTARG,A_WIREGUARD,setwgrtable},
:   { "-wgpeer",NEXTARG,A_WIREGUARD,unsetwgpeer},
:   { "-wgpsk", 0,  A_WIREGUARD,unsetwgpeerpsk},
: + { "-wgdesc",0,  A_WIREGUARD,unsetwgpeerdesc},
:   { "-wgpeerall", 0,  A_WIREGUARD,unsetwgpeerall},
:  
:  #else /* SMALL */
: @@ -5856,6 +5860,16 @@ setwgpeerpka(const char *pka, int param)
:  }
:  
:  void
: +setwgpeerdesc(const char *wgdesc, int param)
: +{
: + if (wg_peer == NULL)
: + errx(1, "wgdesc: wgpeer not set");
: + if (strlen(wgdesc))
: + strlcpy(wg_peer->p_description, wgdesc, IFDESCRSIZE);
: + wg_peer->p_flags |= WG_PEER_SET_DESCRIPTION;
: +}
: +
: +void
:  setwgport(const char *port, int param)
:  {
:   const char *errmsg = NULL;
: @@ -5902,6 +5916,15 @@ unsetwgpeerpsk(const char *value, int pa
:  }
:  
:  void
: +unsetwgpeerdesc(const char *value, int param)
: +{
: + if (wg_peer == NULL)
: + errx(1, "wgdesc: wgpeer not set");
: + strlcpy(wg_peer->p_description, "", IFDESCRSIZE);
: + wg_peer->p_flags |= WG_PEER_SET_DESCRIPTION;

I was a bit confused by this at first (wondering if it should use
"&= ~WG_PEER_SET_DESCRIPTION"). I understand it now but I think that
a different name would make it clearer. Maybe WG_PEER_UPDATE_DESCR?

: +}
: +
: +void
:  unsetwgpeerall(const char *value, int param)
:  {
:   ensurewginterface();
: @@ -5961,6 +5984,9 @@ wg_status(int ifaliases)
:   b64_ntop(wg_peer->p_public, WG_KEY_LEN,
:   key, sizeof(key));
:   printf("\twgpeer %s\n", key);
: +
: + if (strlen(wg_peer->p_description))
: + printf("\t\twgdesc %s\n", 
wg_peer->p_description);
:  
:   if (wg_peer->p_flags & WG_PEER_HAS_PSK)
:   printf("\t\twgpsk (present)\n");
: Index: share/man/man4/wg.4
: ===
: RCS file: /cvs/src/share/man/man4/wg.4,v
: retrieving revision 1.10
: diff -u -p -u -r1.10 wg.4
: --- share/man/man4/wg.4   14 Mar 2021 10:08:38 -  1.10
: +++ share/man/man4/wg.4   24 Dec 2022 00:49:05 -
: @@ -42,6 +42,19 @@ configuration file for
:  .Xr netstart 8 .
:  The interface itself can be configured with
:  .Xr ifconfig 8 .
: +To display
: +.Cm wgpeer
: +information for each
: +.Nm wg
: +interface option
: +.Fl A
: +to
: +.Xr ifconfig 8
: +should be used or
: +.Nm wg
: +interface should be specified as an argument to
: +.Xr ifconfig 8
: +command.
:  .Pp
:  .Nm wg
:  interfaces support the following

This isn't directly related to the descr diff so should be a separate
commit if done.

This diff displays like so:

-
 The interfaces can be created at runtime using the ifconfig wgN create
 command or by setting up a hostname.if(5) configuration file for
 netstart(8).  The interface itself can be configured with ifconfig(8).
 To display wgpeer information for each wg interface option -A to
 ifconfig(8) should be used or wg interface should be specified as an
 argument to ifconfig(8) command.
 [...]
-

I find 

Re: openssh: update ed25519 and squash into a single file

2023-01-14 Thread Theo Buehler
> This isn't completely without noise, but it lets you see the substantive
> changes clearly.

This looks good to me and works fine in my environment. Inlining the
weird get_hram() makes things quite a bit clearer. I can't spot anything
wrong in this diff.

ok tb