Re: pf route-to issues

2020-10-19 Thread Stuart Henderson
On 2020/10/19 19:53, David Gwynne wrote:
> On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> > On 2020/10/19 15:35, David Gwynne wrote:
> > > every few years i try and use route-to in pf, and every time it
> > > goes badly. i tried it again last week in a slightly different
> > > setting, and actually tried to understand the sharp edges i hit
> > > this time instead of giving up. it turns out there are 2 or 3
> > > different things together that have cause me trouble, which is why
> > > the diff below is so big.
> > 
> > I used to route-to/reply-to quite a lot at places with poor internet
> > connections to split traffic between lines (mostly those have better
> > connections now so I don't need it as often). It worked as I expected -
> > but I only ever used it with the interface specified.
> 
> cool. did it work beyond the first packet in a connection?

It must have done. The webcams would have utterly broken the rest of
traffic if it hadn't :)

> > I mostly used it with pppoe interfaces so the peer address was unknown
> > at ruleset load time. (I was lucky and had static IPs my side, but the
> > ISP side was variable). I relied on the fact that once packets are
> > directed at a point-point interface there's only one place for them to
> > go. I didn't notice that ":peer" might be useful here (and the syntax
> > 'route-to pppoe1:peer@pppoe1' is pretty awkward so I probably wouldn't
> > have come up with it), I had 0.0.0.1@pppoe1, 0.0.0.2@pppoe2 etc
> > (though actually I think it works with $any_random_address@pppoeX).
> 
> yes. i was trying to use it with peers over ethernet, and always
> struggled with the syntax.
> 
> > > the first and i would argue most fundamental problem is a semantic
> > > problem. if you ask a random person who has some clue about networks
> > > and routing what they would expect the "argument" to route-to or
> > > reply-to to be, they would say "a nexthop address" or "a gateway
> > > address". eg, say i want to force packets to a specific backend
> > > server without using NAT, i would write a rule like this:
> > > 
> > >   n_servers="192.0.2.128/27"
> > >   pass out on $if_internal to $n_servers route-to 192.168.0.1
> > > 
> > > pfctl will happily parse this, shove it into the kernel, let you read
> > > the rules back out again with pfctl -sr, and it all looks plausible, but
> > > it turns out that it's using the argument to route-to as an interface
> > > name. because rulesets can refer to interfaces that don't exist yet, pf
> > > just passes the IP address around as a string, hoping i'll plug in an
> > > interface with a driver name that looks like an ip address. i spent
> > > literally a day trying to figure out why a rule like this wasn't
> > > working.
> > 
> > I don't think I tried this, but the pf.conf(5) BNF syntax suggests it's
> > supposed to work. So either doc or implementation bug there.
> 
> im leaning toward implementation bug.
> 
> >  route  = ( "route-to" | "reply-to" | "dup-to" )
> >   ( routehost | "{" routehost-list "}" )
> >   [ pooltype ]
> > 
> >  routehost-list = routehost [ [ "," ] routehost-list ]
> > 
> >  routehost  = host | host "@" interface-name |
> >   "(" interface-name [ address [ "/" mask-bits ] ] ")"
> > 
> > > the second problem is that the pf_route calls from pfsync don't
> > > have all the information it is supposed to have. more specifically,
> > > an ifp pointer isn't set which leads to a segfault. the ifp pointer
> > > isn't set because pfsync doesnt track which interface a packet is
> > > going out, it assumes the ip layer will get it right again later, or a
> > > rule provided something usable.
> > > 
> > > the third problem is that pf_route relies on information from rules to
> > > work correctly. this is a problem in a pfsync environment because you
> > > cannot have the same ruleset on both firewalls 100% of the time, which
> > > means you cannot have route-to/reply-to behave consistently on a pair of
> > > firwalls 100% of the time.
> > 
> > I didn't run into this because pppoe(4) and pfsync/carp don't really
> > go well together, but ouch!
> > 
> > > all of this together makes things work pretty obviously and smoothly.
> > > in my opinion 

Re: net.inet.ip.forwarding=0 vs lo(4)

2020-10-19 Thread Stuart Henderson
On 2020/10/19 11:47, David Gwynne wrote:
> On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote:
> > On 2020/10/18 14:04, David Gwynne wrote:
> > > the problem i'm hitting is that i have a multihomed box where the
> > > service it provides listens on an IP address that's assigned to lo1.
> > > it's a host running a service, it's not a router, so the
> > > net.inet.ip.forwarding sysctl is not set to 1.
> > 
> > I ran into this, I just turned on the forwarding sysctl to avoid the
> > problem.
> > 
> > > i came up with this diff, which adds even more special casing for
> > > loopback interfaces. it says addreesses on loopbacks are globally
> > > reachable, even if ip forwarding is disabled.
> > 
> > I don't see why loopbacks should be special. Another place this
> > might show up is services running on carp addresses (I haven't updated
> > those machines yet but there's a fair chance they'll be affected too).
> > I would prefer an explicit sysctl to disable "strong host model".
> 
> loopback is already special. if a packet comes from an loopback
> interface, we allow it to talk to any IP on the local machine. i think
> this is mostly to cope with the semantic we've had where local traffic
> get's tied to a loopback interface instead of going anywhere near the
> physical ones.
> 
> carp is also special.
> 
> let me paste the ip_laddr function instead of the diff to it, it's a bit
> more obvious what's going on:

Thanks, that will already work for the machines I was thinking of then.

> back to loopback and receiving packets. loopback is special because it
> is not connected to the outside world. it is impossible to send a packet
> via a loopback interface from another host, so configuring a globally
> (externally) routable IP on it is currently pointless unless you enable
> forwarding. i think making loopback more special and allowing it
> to be globally reachable makes sense. i can't think of any downsides to
> this at the moment, except that the behaviour would be subtle/not
> obvious

ok, so it makes sense for this to be independent of any possible
separate lever.

> is there a need to configure a globally reachable IP on a non-loopback
> interface on a host (not router)? if so, then i'd be more convinced that
> we need a separate lever to pull.

I'm not using it this way, but here's a scenario.

Say there are a couple of webservers with addresses from a carp on
ethernet/vlan, with a link to their upstream router on some separate
interface. They announce the carp prefix into ospf.

They aren't routing themselves so the only reason to have forwarding=1
is to have them use "weak host model".

With forwarding=0 I think they'll have to use "stub router no" otherwise
everything will be announced high metric (rather than being dependent on
carp state), but ospfd explicitly handles this; it's marked in parse.y
with "/* allow to force non stub mode */".



Re: pf route-to issues

2020-10-19 Thread Stuart Henderson
On 2020/10/19 15:35, David Gwynne wrote:
> every few years i try and use route-to in pf, and every time it
> goes badly. i tried it again last week in a slightly different
> setting, and actually tried to understand the sharp edges i hit
> this time instead of giving up. it turns out there are 2 or 3
> different things together that have cause me trouble, which is why
> the diff below is so big.

I used to route-to/reply-to quite a lot at places with poor internet
connections to split traffic between lines (mostly those have better
connections now so I don't need it as often). It worked as I expected -
but I only ever used it with the interface specified.

I mostly used it with pppoe interfaces so the peer address was unknown
at ruleset load time. (I was lucky and had static IPs my side, but the
ISP side was variable). I relied on the fact that once packets are
directed at a point-point interface there's only one place for them to
go. I didn't notice that ":peer" might be useful here (and the syntax
'route-to pppoe1:peer@pppoe1' is pretty awkward so I probably wouldn't
have come up with it), I had 0.0.0.1@pppoe1, 0.0.0.2@pppoe2 etc
(though actually I think it works with $any_random_address@pppoeX).

> the first and i would argue most fundamental problem is a semantic
> problem. if you ask a random person who has some clue about networks
> and routing what they would expect the "argument" to route-to or
> reply-to to be, they would say "a nexthop address" or "a gateway
> address". eg, say i want to force packets to a specific backend
> server without using NAT, i would write a rule like this:
> 
>   n_servers="192.0.2.128/27"
>   pass out on $if_internal to $n_servers route-to 192.168.0.1
> 
> pfctl will happily parse this, shove it into the kernel, let you read
> the rules back out again with pfctl -sr, and it all looks plausible, but
> it turns out that it's using the argument to route-to as an interface
> name. because rulesets can refer to interfaces that don't exist yet, pf
> just passes the IP address around as a string, hoping i'll plug in an
> interface with a driver name that looks like an ip address. i spent
> literally a day trying to figure out why a rule like this wasn't
> working.

I don't think I tried this, but the pf.conf(5) BNF syntax suggests it's
supposed to work. So either doc or implementation bug there.

 route  = ( "route-to" | "reply-to" | "dup-to" )
  ( routehost | "{" routehost-list "}" )
  [ pooltype ]

 routehost-list = routehost [ [ "," ] routehost-list ]

 routehost  = host | host "@" interface-name |
  "(" interface-name [ address [ "/" mask-bits ] ] ")"

> the second problem is that the pf_route calls from pfsync don't
> have all the information it is supposed to have. more specifically,
> an ifp pointer isn't set which leads to a segfault. the ifp pointer
> isn't set because pfsync doesnt track which interface a packet is
> going out, it assumes the ip layer will get it right again later, or a
> rule provided something usable.
> 
> the third problem is that pf_route relies on information from rules to
> work correctly. this is a problem in a pfsync environment because you
> cannot have the same ruleset on both firewalls 100% of the time, which
> means you cannot have route-to/reply-to behave consistently on a pair of
> firwalls 100% of the time.

I didn't run into this because pppoe(4) and pfsync/carp don't really
go well together, but ouch!

> all of this together makes things work pretty obviously and smoothly.
> in my opinion anyway. route-to now works more like rdr-to, it just
> feels like it changes the address used for the route lookup rather
> than changing the actual IP address in the packet. it also works
> predictably in a pfsync pair, which is great from the point of view of
> high availability.
> 
> the main caveat is that it's not backward compatible. if you're already
> using route-to, you will need to tweak your rules to have them parse.
> however, i doubt anyone is using this stuff because it feels very broken
> to me.

Do you expect this to work with a bracketed "address" to defer lookup
until rule evaluation time? i.e.

pass out proto tcp to any port 22 route-to (pppoe1:peer)

I think that will be all that's needed to allow converting the pppoe
use case. I don't have a multiple pppoe setup handy but I can probably
hack together some sort of test.

I've also used route-to with squid "transparent" proxying (shown in
the pkg-readme), I don't do that any more but I can put a squid test
together easily enough.

> @@ -1842,37 +1833,18 @@ pfrule: action dir logquick interface 
>   decide_address_family($7.src.host, );
>   decide_address_family($7.dst.host, );
>  
> - if ($8.route.rt) {
> + if ($8.rt) {
> + if ($8.rt != PF_DUPTO && !r.direction) {
> + 

Re: net.inet.ip.forwarding=0 vs lo(4)

2020-10-18 Thread Stuart Henderson
On 2020/10/18 14:04, David Gwynne wrote:
> the problem i'm hitting is that i have a multihomed box where the
> service it provides listens on an IP address that's assigned to lo1.
> it's a host running a service, it's not a router, so the
> net.inet.ip.forwarding sysctl is not set to 1.

I ran into this, I just turned on the forwarding sysctl to avoid the
problem.

> i came up with this diff, which adds even more special casing for
> loopback interfaces. it says addreesses on loopbacks are globally
> reachable, even if ip forwarding is disabled.

I don't see why loopbacks should be special. Another place this
might show up is services running on carp addresses (I haven't updated
those machines yet but there's a fair chance they'll be affected too).
I would prefer an explicit sysctl to disable "strong host model".



Re: Typo Diffs

2020-10-16 Thread Stuart Henderson
On 2020/10/16 02:36, Varik Valefor wrote:
> Sir or Madam:
> 
> Included within this message should be some diffs which can be applied to
> fix some typographical errors and general wording problems which exist
> within the OpenBSD manual pages, as well as some other files.
> 
> These changes are proposed because typographical errors look bad and can
> lead to assumptions of incompetence.
> 
> KUTGW,
> Varik "NOT A COMPUTER PROGRAMMER!!!" Valefor

The "the the" fixes are good; the others seem to mostly be stylistic
changes which are a matter of opinion, a diff in the reverse direction 
would be equally valid, we don't usually commit changes like that though
the maintainers of the relevant parts of the tree may take some of them.
One proposed change in openssl(1) is clearly worse ("to for").


> - BEGIN DIFFS -
> diff --git a/lib/libutil/ober_add_string.3 b/lib/libutil/ober_add_string.3
> index 5eb6bd32ea0..77a13e629a0 100644
> --- a/lib/libutil/ober_add_string.3
> +++ b/lib/libutil/ober_add_string.3
> @@ -134,7 +134,7 @@ creates zero or more
>  structures.
>  For each byte in
>  .Fa fmt ,
> -arguments of the the types given in the following table are consumed
> +arguments of the types given in the following table are consumed
>  and passed to the listed function, creating one
>  .Vt ber_element
>  per byte.
> 
> diff --git a/share/man/man9/physio.9 b/share/man/man9/physio.9
> index 528581eedaa..2977813bbe8 100644
> --- a/share/man/man9/physio.9
> +++ b/share/man/man9/physio.9
> @@ -56,7 +56,7 @@ The maximum amount of data to transfer with each call to
>  is determined by the
>  .Fa minphys
>  routine.
> -Since
> +Because
>  .Fa uio
>  normally describes user space addresses,
>  .Fn physio
> @@ -85,7 +85,9 @@ A break-down of the arguments follows:
>  The device strategy routine to call for each chunk of data to initiate
>  device I/O.
>  .It Fa dev
> -The device number identifying the device to interact with.
> +The device number of the device with which
> +.Nm
> +should interact.
>  .It Fa flags
>  Direction of transfer; the only valid settings are
>  .Dv B_READ
> 
> diff --git a/usr.bin/ftp/ftp.1 b/usr.bin/ftp/ftp.1
> index 4f4bfd8d5d5..b5683b0d546 100644
> --- a/usr.bin/ftp/ftp.1
> +++ b/usr.bin/ftp/ftp.1
> @@ -316,7 +316,7 @@ slow connection after
>  The host with which
>  .Nm
>  is to communicate may be specified on the command line.
> -If this is done,
> +If this host is specified,
>  .Nm
>  will immediately attempt to establish a connection to an
>  FTP server on that host; otherwise,
> @@ -1675,7 +1675,7 @@ entry cannot be utilized by multiple
>  .Ic machine
>  definitions; rather, it must be defined following each
>  .Ic machine
> -it is intended to be used with.
> +with which it is to be used.
>  If a macro named
>  .Ic init
>  is defined, it is automatically executed as the last step in the
> 
> diff --git a/usr.bin/sed/sed.1 b/usr.bin/sed/sed.1
> index 87a5d04aa4a..4d4b0d3660c 100644
> --- a/usr.bin/sed/sed.1
> +++ b/usr.bin/sed/sed.1
> @@ -427,7 +427,7 @@ string for the first instance of the regular expression
>  in the pattern space.
>  Any character other than backslash or newline can be used instead of
>  a slash to delimit the regular expression and the replacement.
> -Also see the the section about
> +Also see the section about
>  .Sx SED REGULAR EXPRESSIONS .
>  .Pp
>  An ampersand
> 
> diff --git a/usr.bin/openssl/openssl.1 b/usr.bin/openssl/openssl.1
> index e364586f5ad..f1f4361c472 100644
> --- a/usr.bin/openssl/openssl.1
> +++ b/usr.bin/openssl/openssl.1
> @@ -408,10 +408,10 @@ are assumed to be the names of files containing 
> certificate requests.
>  The
>  .Fa password
>  used to encrypt the private key.
> -Since on some systems the command line arguments are visible,
> +On some systems, the command line arguments are visible; therefore,
>  this option should be used with caution.
>  .It Fl keyfile Ar file
> -The private key to sign requests with.
> +The private key with which requests should be signed.
>  .It Fl keyform Cm pem | der
>  Private key file format.
>  The default is
> 
> diff --git a/usr.bin/x99token/x99token.1 b/usr.bin/x99token/x99token.1
> index 1d004dea440..8a29f22ce99 100644
> --- a/usr.bin/x99token/x99token.1
> +++ b/usr.bin/x99token/x99token.1
> @@ -49,7 +49,7 @@ is not specified,
>  is in calculator mode.
>  In this mode you must enter the same PIN as used in the initialization step.
>  The PIN is used to decode the key read from the keyfile.
> -Next you enter the challenge you have been presented with.
> +Next, you enter the challenge which has been presented to you.
>  The
>  .Nm
>  program will provide you with a response to the challenge.
> 
> diff --git a/usr.bin/openssl/openssl.1 b/usr.bin/openssl/openssl.1
> index e364586f5ad..da4b73aee3c 100644
> --- a/usr.bin/openssl/openssl.1
> +++ b/usr.bin/openssl/openssl.1
> @@ -371,7 +371,7 @@ If reading the serial from the text file as specified in 
> the
>  configuration fails, create a new random serial 

[s...@spacehopper.org: Re: Remove useless line from daemon class in login.conf]

2020-10-14 Thread Stuart Henderson
Just found this in my local tree still, iirc danj liked it but there
wasn't much other enthusiasm. Any other comments? Should I just drop
the diff? Change 'a' to use 2^10 minimum? Change to fixed 2^10 with
no auto measurement?

- Forwarded message from Stuart Henderson  -

From: Stuart Henderson 
Date: Sat, 23 May 2020 22:08:11 +0100
Subject: Re: Remove useless line from daemon class in login.conf

On 2020/05/22 16:04, Theo de Raadt wrote:
> Stuart Henderson  wrote:
> 
> > On 2020/05/22 17:06, Daniel Jakots wrote:
> > > Hi,
> > > 
> > > We used to have different numbers of blowfish rounds between the
> > > default and daemon classes in login.conf. On Jun 26, 2016, tedu
> > > committed "upgrade selected login.conf to use auto rounds for bcrypt"
> > > for amd64, sparc64, i386, and maccpc [1].
> > > 
> > > Since the class daemon inherits from the default class, the 
> > > :localcipher=blowfish,a:\
> > > is a duplicate.
> > > 
> > > Here's a diff to remove them.
> > 
> > I'm OK with unifying these settings, but FWIW I never switched to auto
> > for these, it doesn't seem all that sensible for somebody with the ability
> > to generate enough load on the machine to be able to reduce the strength
> > of bcrypt down to the 64 (2^6) rounds minimum.
> 
> Yes, that is problematic.
> 
> The minimum should be probably be raised, we should consider if auto
> should even exist anymore.
> 

As long as it doesn't allow weakening things I think auto should still
exist so that machines can have a stronger bcrypt where it's cheap.

When this was introduced, login.conf for amd64/i386/macppc/sparc64
changed from 8 (normal users) and 9 (daemon class i.e. root) to auto.
Since other, mainly slower, arches stayed with hardcoded 8/9 I don't
think the current minimum reachable in the code makes sense at all.

I've gone to a few machines and done:

- 50 runs of "encrypt -b a" to see what setting was chosen by auto

for i in `jot 50`; do echo foo | encrypt -b a; sleep .1; done | cut -d'$' -f3 | 
sort | uniq -c

- 50 runs of "encrypt -b 9" or "encrypt -b 10" and averaged, to see
how long those two settings take

time for i in `jot 50`; do echo foo | encrypt -b 10; done
(divided by 50)

Chosen  -b 9-b 10
Cortex-A53 1.4GHz (pi3) all 8   0.220.40
GX-412TC 1GHz (APU2)all 8   0.160.31
Cortex-A72 1.5GHz (pi4) all 9   0.070.14
L5520 2.27GHz   all 9   0.080.16
E3-1225v3 3.2GHz12x8 3x9 35x10  0.050.10
E3-1240v5 3.5GHzall 10  0.040.08
E3-1270v6 3.8GHzall 11  0.030.05

I think bumping the minimum to 2^9 would be reasonable, there's a more
noticeable delay on some machines but I think that's fair enough (any
cracking is likely to be done on a fast machine, and the user can force
it lower themselves if they want to take the risk).

With a higher minimum than that the delay starts to get very noticeable
in some cases, so I'm not sure we're ready for that yet.

I think it also makes sense to use blowfish,a in login.conf on all
arches, replacing the old 8/9. Actually -b a is already used in the
installer for both root and the standard user on all archs, whatever
they have in login.conf. Resulting in the situation that on some
archs, the bcrypt created during install for root's password is
weaker than it would be if reset after boot.

So maybe this or something like it?

Index: lib/libc/crypt/bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.57
diff -u -p -r1.57 bcrypt.c
--- lib/libc/crypt/bcrypt.c 26 Aug 2016 08:25:02 -  1.57
+++ lib/libc/crypt/bcrypt.c 23 May 2020 20:16:46 -
@@ -237,14 +237,15 @@ bcrypt_checkpass(const char *pass, const
 DEF_WEAK(bcrypt_checkpass);
 
 /*
- * Measure this system's performance by measuring the time for 8 rounds.
- * We are aiming for something that takes around 0.1s, but not too much over.
+ * Measure this system's performance by measuring the time for 2^9 rounds.
+ * We are aiming for something that takes around 0.1s, not too much over,
+ * but without allowing it to be too weak.
  */
 int
 _bcrypt_autorounds(void)
 {
struct timespec before, after;
-   int r = 8;
+   int r = 9;
char buf[_PASSWORD_LEN];
int duration;
 
@@ -257,12 +258,12 @@ _bcrypt_autorounds(void)
duration += (after.tv_nsec - before.tv_nsec) / 1000;
 
/* too quick? slow it down. */
-   while (r < 16 && duration <= 6) {
+   while (r < 16 && duration <= 75000) {
r += 1;
duration *= 2;
}
/* too slow? speed it up. */
-   while (r > 6 &&

Re: Unbound 1.12.0

2020-10-13 Thread Stuart Henderson
On 2020/10/11 15:37, Renaud Allard wrote:
> 
> 
> On 10/10/2020 22:05, Stuart Henderson wrote:
> > Here's an update to the recently released version of Unbound. Much of
> > the additional code is for DoH and is unused here as it requires the
> > nghttp2 library.
> > 
> 
> nghttp2 seems to be MIT licensed. Could it be possible to import it in base?
> 

Personally I am not particularly interested in pushing a library that is
already in ports into base..

At this point I would prefer to handle it as a simple update, then
consider 1) whether there should be a separate "ports unbound" with
things that can't (or can't easily) be handled in base - e.g. this,
python, dnstap or 2) whether unbound should just move back to ports
completely.



Re: NSD 4.3.3

2020-10-09 Thread Stuart Henderson
On 2020/10/09 21:35, Stuart Henderson wrote:
> Here's an update to NSD 4.3.3.  Any tests/comments/OKs?

Updated to reinstate the pledge lost in nsd.c (merge error as we had a
local commit post 4.3.2), spotted by tb.

(I didn't reorder the diff for easier reading this time).

Index: Makefile.in
===
RCS file: /cvs/src/usr.sbin/nsd/Makefile.in,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile.in
--- Makefile.in 23 Jul 2020 13:54:07 -  1.29
+++ Makefile.in 9 Oct 2020 21:36:14 -
@@ -126,7 +126,7 @@ install:
 orig-install: all
$(INSTALL) -d $(DESTDIR)$(sbindir)
$(INSTALL) -d $(DESTDIR)$(configdir)
-   $(INSTALL) -d $(DESTDIR)$(piddir)
+   if test -n "$(piddir)"; then $(INSTALL) -d $(DESTDIR)$(piddir); fi
$(INSTALL) -d $(DESTDIR)$(xfrdir)
$(INSTALL) -d $(DESTDIR)$(dbdir)
$(INSTALL) -d $(DESTDIR)$(mandir)
Index: acx_nlnetlabs.m4
===
RCS file: /cvs/src/usr.sbin/nsd/acx_nlnetlabs.m4,v
retrieving revision 1.3
diff -u -p -r1.3 acx_nlnetlabs.m4
--- acx_nlnetlabs.m424 Jun 2016 08:34:03 -  1.3
+++ acx_nlnetlabs.m49 Oct 2020 21:36:14 -
@@ -2,7 +2,8 @@
 # Copyright 2009, Wouter Wijngaards, NLnet Labs.   
 # BSD licensed.
 #
-# Version 34
+# Version 35
+# 2020-08-24 Use EVP_sha256 instead of HMAC_Update (for openssl-3.0.0).
 # 2016-03-21 Check -ldl -pthread for libcrypto for ldns and openssl 1.1.0.
 # 2016-03-21 Use HMAC_Update instead of HMAC_CTX_Init (for openssl-1.1.0).
 # 2016-01-04 -D_DEFAULT_SOURCE defined with -D_BSD_SOURCE for Linux glibc 2.20
@@ -673,30 +674,30 @@ AC_DEFUN([ACX_SSL_CHECKS], [
 ACX_RUNTIME_PATH_ADD([$ssldir/lib])
 fi
 
-AC_MSG_CHECKING([for HMAC_Update in -lcrypto])
+AC_MSG_CHECKING([for EVP_sha256 in -lcrypto])
 LIBS="$LIBS -lcrypto"
 LIBSSL_LIBS="$LIBSSL_LIBS -lcrypto"
 AC_TRY_LINK(, [
-int HMAC_Update(void);
-(void)HMAC_Update();
+int EVP_sha256(void);
+(void)EVP_sha256();
   ], [
 AC_MSG_RESULT(yes)
-AC_DEFINE([HAVE_HMAC_UPDATE], 1, 
-  [If you have HMAC_Update])
+AC_DEFINE([HAVE_EVP_SHA256], 1,
+  [If you have EVP_sha256])
   ], [
 AC_MSG_RESULT(no)
 # check if -lwsock32 or -lgdi32 are needed.
 BAKLIBS="$LIBS"
 BAKSSLLIBS="$LIBSSL_LIBS"
-LIBS="$LIBS -lgdi32"
-LIBSSL_LIBS="$LIBSSL_LIBS -lgdi32"
+   LIBS="$LIBS -lgdi32 -lws2_32"
+   LIBSSL_LIBS="$LIBSSL_LIBS -lgdi32 -lws2_32"
 AC_MSG_CHECKING([if -lcrypto needs -lgdi32])
 AC_TRY_LINK([], [
-int HMAC_Update(void);
-(void)HMAC_Update();
+int EVP_sha256(void);
+(void)EVP_sha256();
   ],[
-AC_DEFINE([HAVE_HMAC_UPDATE], 1, 
-[If you have HMAC_Update])
+AC_DEFINE([HAVE_EVP_SHA256], 1,
+[If you have EVP_sha256])
 AC_MSG_RESULT(yes) 
   ],[
 AC_MSG_RESULT(no)
@@ -706,11 +707,11 @@ AC_DEFUN([ACX_SSL_CHECKS], [
 LIBSSL_LIBS="$LIBSSL_LIBS -ldl"
 AC_MSG_CHECKING([if -lcrypto needs -ldl])
 AC_TRY_LINK([], [
-int HMAC_Update(void);
-(void)HMAC_Update();
+int EVP_sha256(void);
+(void)EVP_sha256();
   ],[
-AC_DEFINE([HAVE_HMAC_UPDATE], 1, 
-[If you have HMAC_Update])
+AC_DEFINE([HAVE_EVP_SHA256], 1,
+[If you have EVP_sha256])
 AC_MSG_RESULT(yes) 
   ],[
 AC_MSG_RESULT(no)
@@ -720,11 +721,11 @@ AC_DEFUN([ACX_SSL_CHECKS], [
 LIBSSL_LIBS="$LIBSSL_LIBS -ldl -pthread"
 AC_MSG_CHECKING([if -lcrypto needs -ldl -pthread])
 AC_TRY_LINK([], [
-int HMAC_Update(void);
-(void)HMAC_Update();
+int EVP_sha256(void);
+(void)EVP_sha256();
   ],[
-AC_DEFINE([HAVE_HMAC_UPDATE], 1, 
-[If you have HMAC_Update])
+AC_DEFINE([HAVE_EVP_SHA2

NSD 4.3.3

2020-10-09 Thread Stuart Henderson
Here's an update to NSD 4.3.3.  Any tests/comments/OKs?

diff in order;
- changelog
- code changes
- manpage changes
- autoconf foo

 doc/ChangeLog  |   55 
 doc/RELNOTES   |   24 
 dbaccess.c |4 -
 ipc.c  |1 
 mini_event.h   |5 +
 nsd-control.c  |2 
 nsd.c  |  141 ---
 options.c  |   16 +
 options.h  |4 +
 server.c   |2 
 tsig-openssl.c |  145 +
 tsig-openssl.h |2 
 util.c |   13 
 util.h |3 -
 zonec.c|8 ++
 zonec.h|2 
 nsd-checkconf.8.in |2 
 nsd-checkzone.8.in |2 
 nsd-control.8.in   |2 
 nsd.8.in   |4 -
 nsd.conf.5.in  |   12 ++--
 nsd.conf.sample.in |4 -
 Makefile.in|2 
 acx_nlnetlabs.m4   |   47 +
 config.h.in|   12 
 configure  |   56 ++--
 configure.ac   |   22 
 27 files changed, 507 insertions(+), 85 deletions(-)

Index: doc/ChangeLog
===
RCS file: /cvs/src/usr.sbin/nsd/doc/ChangeLog,v
retrieving revision 1.4
diff -u -p -r1.4 ChangeLog
--- doc/ChangeLog   23 Jul 2020 13:54:08 -  1.4
+++ doc/ChangeLog   9 Oct 2020 20:28:16 -
@@ -1,3 +1,58 @@
+1 October 2020: Wouter
+   - tag for 4.3.3rc1 release.
+
+30 September 2020: Wouter
+   - Updated date in nsd -v output.
+   - Fixup bug013_truncate, checkconf and cutest_qroot tests for new
+ default EDNS size.
+
+29 September 2020: Willem
+   - Follow DNS flag day 2020 advice and
+ set default EDNS message size to 1232.
+
+4 September 2020: Wouter
+   - Remove unused space from LIBS on link line.
+
+3 September 2020: Wouter
+   - Merge PR #121: Increase log level of recreated database from
+ WARNING to ERR.
+
+1 September 2020: Wouter
+   - Fix #119: fix compile warnings from new gcc.
+   - Fix #119: warn when trying to parse a directory.
+
+27 August 2020: Wouter
+   - Merged PR #113 with fixes.  Instead of listing an IP-address to
+ listen on, an interface name can be specified in nsd.conf, with
+ ip-address: eth0.  The IP-addresses for that interface are then used.
+
+26 August 2020: Wouter
+   - Add xstrdup for PR #113.
+   - Tidy up code like in PR #113.
+   - Import code from PR #113.
+   - Fix for unknown EVP_MAC_CTX_free function in openssl 3.0.0 tsig code.
+
+24 August 2020: Wouter
+   - Fix that configure checks for EVP_sha256 to detect openssl, because
+ HMAC_CTX_new is deprecated in 3.0.0.
+   - Port TSIG code for openssl 3.0.0-alpha6.
+   - Sync acx_nlnetlabs.m4 with the unbound repo.
+   - Review fixes for tsig, defensive free and zero.
+
+4 August 2020: Wouter
+   - Merge #117: mini_event.h (4.3.2 and 4.3.1) on OpenBSD cannot find
+ fd_set - patch.
+
+23 July 2020: Wouter
+   - Merge #115 from millert: Fix strlcpy() usage. From OpenBSD.
+
+15 July 2020: Wouter
+   - Fix make install with --with-pidfile="".
+
+14 July 2020: Wouter
+   - Tag for 4.3.2 release.  Master branch contains the next version
+ in development, 4.3.3.
+
 7 July 2020: Wouter
- Tag for 4.3.2rc1.
 
Index: doc/RELNOTES
===
RCS file: /cvs/src/usr.sbin/nsd/doc/RELNOTES,v
retrieving revision 1.3
diff -u -p -r1.3 RELNOTES
--- doc/RELNOTES23 Jul 2020 13:54:08 -  1.3
+++ doc/RELNOTES9 Oct 2020 20:28:16 -
@@ -1,5 +1,29 @@
 NSD RELEASE NOTES
 
+4.3.3
+
+FEATURES:
+   - Follow DNS flag day 2020 advice and
+ set default EDNS message size to 1232.
+   - Merged PR #113 with fixes.  Instead of listing an IP-address to
+ listen on, an interface name can be specified in nsd.conf, with
+ ip-address: eth0.  The IP-addresses for that interface are then used.
+   - Port TSIG code for openssl 3.0.0-alpha6.
+BUG FIXES:
+   - Fix make install with --with-pidfile="".
+   - Merge #115 from millert: Fix strlcpy() usage. From OpenBSD.
+   - Merge #117: mini_event.h (4.3.2 and 4.3.1) on OpenBSD cannot find
+ fd_set - patch.
+   - Fix that configure checks for EVP_sha256 to detect openssl, because
+ HMAC_CTX_new is deprecated in 3.0.0.
+   - Fix #119: fix compile warnings from new gcc.
+   - Fix #119: warn when trying to parse a directory.
+   - Merge PR #121: Increase log level of recreated database from
+ WARNING to ERR.
+   - Remove unused space from LIBS on link line.
+   - Updated date in nsd -v output.
+
+
 4.3.2
 
 FEATURES:
Index: dbaccess.c
===
RCS file: 

Re: ssh-keygen: generate ed25519 keys by default

2020-10-08 Thread Stuart Henderson
On 2020/10/08 15:40, Christian Weisgerber wrote:
> At this point, I don't know how many SSH servers are still out there
> that don't handle Ed25519.  I still have an ECDSA key somewhere
> that I use to log into a machine that still runs... "OpenSSH_6.0p1
> Debian-4+deb7u7, OpenSSL 1.0.1t  3 May 2016".  There is a lot of
> networking equipment that allows uploading of a user key for SSH
> login but may include a comically obsolete version of OpenSSH or
> some alternative implementation that doesn't do Ed25519.

I don't think that's a show-stopper, people using such equipment likely
already need to do non-default things to have OpenSSH connect to it,
My typical config for connecting to switches, including some current
models running latest available firmware, looks like

  KexAlgorithms +diffie-hellman-group14-sha1
  HostKeyAlgorithms +ssh-rsa

(and I still have a few things running where I need to break out an
alternative client because openssh won't talk to them at all any more..)



Re: Make df output more human friendly in daily(8)

2020-10-03 Thread Stuart Henderson
On 2020/10/03 08:44, Daniel Jakots wrote:
> On Sat, 3 Oct 2020 08:00:44 +0200, Ingo Schwarze 
> wrote:
> 
> > But this needs to remain:
> > 
> > > -Reports on which file systems need to be dumped via
> > > -.Xr dump 8 .
> > > -.It  
> 
> Indeed, I wrongly assumed that the other dump call was silent. Here's
> the updated diff:

> -if [ "X$VERBOSESTATUS" != X0 ]; then
> - netstat -ivn
> -fi
> +next_part "Backing up filesystems with dump:"
> +dump w | grep -vB1 ^Dump

The "next_part" header text is wrong, it isn't doing a backup here,
it's only reporting which need to be dumped.



Re: pthread_spin_unlock and ownership behaviour

2020-10-03 Thread Stuart Henderson

Ports-wise, from a Nov 2019 build on i386, these used it:

$ grep -Rl pthread_spin_unlock wrkscan
wrkscan/devel/libivykis
wrkscan/x11/gnustep/base wrkscan/x11/e17/eina
wrkscan/misc/posixtestsuite
wrkscan/net/libunbound
wrkscan/net/libshout
wrkscan/net/icecast
wrkscan/net/bird/1,-doc
wrkscan/net/bird/1,-main,v6
wrkscan/net/bird/2
wrkscan/net/strongswan wrkscan/mail/mailest
wrkscan/geo/gdal,-main


--
 Sent from a phone, apologies for poor formatting.
On 3 October 2020 10:45:05 Martijn van Duren 
 wrote:



Back in 2012 kurt@ added an abort call for the undefined behaviour cases
on pthread_mutex_unlock. This helped me a great deal in examining the
cause of some weird behaviour in icinga (or in the case of openbsd, just
plain crash).

For shits and giggles I deceided to look into pthread_spin_unlock and
saw that we return EPERM here, while POSIX states that this behaviour
is unconditionally undefined.[0] Is there a reason why we shouldn't
abort here as well?

I don't have a particular usecase for this, but the mutex case helped me
and it only seems like the right thing to do from a semetrical point of
view. The only cases of pthread_spin_unlock in base I found were in
libunbound (which with my testing with unwind didn't caused any issues)
and gnu/llvm/compiler-rt/lib/tsan, which I don't know where to test.
I have no idea which ports use it.

martijn@

[0] 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_spin_unlock.html


Index: librthread/rthread_spin_lock.c
===
RCS file: /cvs/src/lib/librthread/rthread_spin_lock.c,v
retrieving revision 1.5
diff -u -p -r1.5 rthread_spin_lock.c
--- librthread/rthread_spin_lock.c  6 Apr 2020 00:01:08 -   1.5
+++ librthread/rthread_spin_lock.c  3 Oct 2020 09:42:21 -
@@ -102,12 +102,12 @@ pthread_spin_unlock(pthread_spinlock_t *
pthread_spinlock_t l;

if (lock == NULL || *lock == NULL)
-   return (EINVAL);
+   abort();

l = *lock;

if (l->owner != self)
-   return (EPERM);
+   abort();

l->owner = NULL;
_spinunlock(>lock);
Index: libpthread/man/pthread_spin_unlock.3
===
RCS file: /cvs/src/lib/libpthread/man/pthread_spin_unlock.3,v
retrieving revision 1.3
diff -u -p -r1.3 pthread_spin_unlock.3
--- libpthread/man/pthread_spin_unlock.36 Apr 2020 00:01:08 -   
1.3
+++ libpthread/man/pthread_spin_unlock.33 Oct 2020 09:42:21 -
@@ -38,17 +38,14 @@ functions.
.Sh RETURN VALUES
If successful,
.Fn pthread_spin_unlock
-returns zero; otherwise an error number is returned to indicate the error.
+returns zero.
.Sh ERRORS
.Fn pthread_spin_unlock
-will fail if:
-.Bl -tag -width Er
-.It Bq Er EINVAL
-The value specified by
+will call
+.Xr abort 3
+if the value specified by
.Fa lock
-is invalid.
-.It Bq Er EPERM
-The lock is not owned by the calling thread.
+is invalid or if the lock is not owned by the calling thread.
.El
.Sh SEE ALSO
.Xr pthread_spin_init 3 ,




Re: trunk: keep interface up on port removal

2020-09-14 Thread Stuart Henderson
On 2020/09/14 10:57, Klemens Nanni wrote:
> On Sun, Sep 13, 2020 at 06:44:13PM +0100, Stuart Henderson wrote:
> > I can't test at the moment, but the other case is removing a port from
> > the trunk without destroying the trunk interface itself. That's almost
> > certainly what I was testing at the time.
> Right, that's different from destroying the trunk.
> 
> > The other thing to be aware of is that you may then end up with two
> > separate interfaces with the same MAC. This may cause some problems for
> > incoming traffic now we don't use weak host model on non-router systems.
> > Not sure there is much we can do about that though.
> I tested removing a single port from trunk and observed that both
> interfaces do end up with the same MAC address, but this happens without
> my diff already - I still don't see any behaviour after my diff wrt. MAC
> addresses or anything else but the UP flag on port interfaces.
> 

Thanks, that sounds like it's alright then.



Re: trunk: keep interface up on port removal

2020-09-13 Thread Stuart Henderson
On 2020/09/13 14:47, Klemens Nanni wrote:
> So there's a dance around UP interfaces already;  CVS log dates this
> code back to 2010 when deraadt rearanged code into ifnewlladdr(), the
> previous if.c revision also head this dance around UP.
> 
> The if_down() line I removed from trunk(4) dates back to if_trunk.c r1.1
> from 2005.
> 
> 
> Here's some practical tests further indicating that my diff does not
> break anything and whatever sthen encountered at whatever time in the
> past is no longer an issue:

This was in 2015 btw.

> With my commit in -CURRENT, the MAC address *is* being restored on my
> physical interfaces:
> 
>   $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
>   em0: flags=8843 mtu 1500
>   lladdr 3c:97:0e:6e:e9:1b
>   athn0: flags=8843 mtu 1500
>   lladdr 04:f0:21:30:37:de
> 
>   $ doas ifconfig trunk0 trunkport em0 trunkport athn0
> 
>   $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
>   em0: 
> flags=8b43 mtu 1500
>   lladdr 3c:97:0e:6e:e9:1b
>   athn0: flags=8943 mtu 
> 1500
>   lladdr 3c:97:0e:6e:e9:1b
> 
>   $ doas ifconfig trunk0 destroy
> 
>   $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
>   em0: flags=8843 mtu 1500
>   lladdr 3c:97:0e:6e:e9:1b
>   athn0: flags=8843 mtu 1500
>   lladdr 04:f0:21:30:37:de
> 
> Observe how UP is set on the physical interfaces, i.e. my diff is in.
> MAC addresses of physical interfaces are properly restored.
> 
> They are also restored when I create the same trunk0 interface but
> generate a random MAC for it as well, i.e. overwriting MACs for all
> ports while in the trunk:
> 
> 
>   $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
>   em0: flags=8843 mtu 1500
>   lladdr 3c:97:0e:6e:e9:1b
>   athn0: flags=8843 mtu 1500
>   lladdr 04:f0:21:30:37:de
> 
>   $ doas ifconfig trunk0 trunkport em0 trunkport athn0 lladdr random
> 
>   $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
>   em0: 
> flags=8b43 mtu 1500
>   lladdr 88:c2:6a:b2:21:41
>   athn0: flags=8943 mtu 
> 1500
>   lladdr 88:c2:6a:b2:21:41
> 
>   $ doas ifconfig trunk0 destroy
> 
>   $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
>   em0: flags=8843 mtu 1500
>   lladdr 3c:97:0e:6e:e9:1b
>   athn0: flags=8843 mtu 1500
>   lladdr 04:f0:21:30:37:de
> 
> 
> I also tested this with vether(4) ports under trunk just to check if
> there's anything different for pseudo interfaces, but they behave the
> same as em(4) and athn(4) for me regardless of `lladdr random' on trunk.
> 
> Am I missing anything?

I can't test at the moment, but the other case is removing a port from
the trunk without destroying the trunk interface itself. That's almost
certainly what I was testing at the time.

The other thing to be aware of is that you may then end up with two
separate interfaces with the same MAC. This may cause some problems for
incoming traffic now we don't use weak host model on non-router systems.
Not sure there is much we can do about that though.



Re: trunk: keep interface up on port removal

2020-09-13 Thread Stuart Henderson
On 2020/09/13 13:23, Klemens Nanni wrote:
> On Sun, Sep 13, 2020 at 11:31:12AM +0100, Stuart Henderson wrote:
> > On 2020/09/13 11:12, Stuart Henderson wrote:
> > > This has been tried before, I forget what but there were problems
> > 
> > from chat logs when I tried this before:
> > 
> > 14:52 < sthen> if i kill the if_down, no crash, but the mac address doesn't 
> > get updated so i end up with the same one on em0, em1, trunk0
> Thanks for mentioning it, I'll look into whether I can fix this or we
> have revert my commit to avoid breakage around MAC addresses.
> 
> I'd expect such information to be present in CVS log or code (comments).
> 

It's not in CVS log because it was tested and didn't work so wasn't
committed. I don't know if there's precedent for documenting everything
somebody might try but fails in a code comment, feels like the tree
would be littered with possibly outdated comments if that's done
regularly?



Re: trunk: keep interface up on port removal

2020-09-13 Thread Stuart Henderson
On 2020/09/13 11:12, Stuart Henderson wrote:
> This has been tried before, I forget what but there were problems

from chat logs when I tried this before:

14:52 < sthen> if i kill the if_down, no crash, but the mac address doesn't get 
updated so i end up with the same one on em0, em1, trunk0



Re: trunk: keep interface up on port removal

2020-09-13 Thread Stuart Henderson

This has been tried before, I forget what but there were problems

--
 Sent from a phone, apologies for poor formatting.
On 12 September 2020 21:16:31 Alexander Bluhm  wrote:


OK bluhm@

On Sat, Sep 12, 2020 at 05:49:52PM +0200, Klemens Nanni wrote:

Index: if_trunk.c
===
RCS file: /cvs/src/sys/net/if_trunk.c,v
retrieving revision 1.149
diff -u -p -r1.149 if_trunk.c
--- if_trunk.c  28 Jul 2020 09:52:32 -  1.149
+++ if_trunk.c  12 Sep 2020 15:41:14 -
@@ -423,10 +423,6 @@ trunk_port_destroy(struct trunk_port *tp
/* Remove multicast addresses from this port */
trunk_ether_cmdmulti(tp, SIOCDELMULTI);

-   /* Port has to be down */
-   if (ifp->if_flags & IFF_UP)
-   if_down(ifp);
-
ifpromisc(ifp, 0);

if (tr->tr_port_destroy != NULL)




Re: sppp: add free() sizes

2020-09-12 Thread Stuart Henderson
On 2020/09/12 19:13, Martin Pieuchot wrote:
> Another approach would be to always use array of AUTHMAXLEN, I'm not sure
> the size justifies two malloc(9).

it used to do that, changed in if_sppsubr.c 1.74



Re: shrinking and growing reallocs: a theoretical? bad case for performance

2020-09-01 Thread Stuart Henderson
On 2020/08/31 08:39, Otto Moerbeek wrote:
> A question from Theo made me think about realloc and come up with a
> particular bad case for performance. I do not know if it happens in
> practice, but it was easy to create a test program to hit the case.

Not very scientific testing (a single attempt at building one port), but
this seems to help quite a lot when compiling programs written in rust.
I encourage others to test the diff :-)



Re: unwind(8): use SO_REUSEADDR

2020-08-30 Thread Stuart Henderson
On 2020/08/29 20:06, Florian Obser wrote:
> I can't think of a downside, OK.
> (Not sure of a use case either though.)

It makes it easier to test unwind diffs on a machine that normally
runs another nameserver :)

OK.



Re: sync unwind to libunbound 1.11.0

2020-08-29 Thread Stuart Henderson
On 2020/08/27 15:28, Florian Obser wrote:
> all heavy lifting done by sthen in unbound
> 
> tests?

ok with me. only tested lightly (the machine I normally use does DNS for
other machines too so runs unbound).

related, any idea what's happening here?

unwind[51500]: fatal in main: could not bind to 127.0.0.1 or ::1 on port 53: 
Address already in use

unbound is listening to *:53, but shouldn't other software be able to
listen if bound to a specific address like 127.0.0.1:53? is this a bug
somewhere or am I just missing something about UDP?

_unbound unbound381773* internet6 dgram udp *:53
_unbound unbound381775* internet dgram udp *:53
_unbound unbound481983* internet6 dgram udp *:53
_unbound unbound481985* internet dgram udp *:53



Re: $pexp in re.subr(8)

2020-08-07 Thread Stuart Henderson
On 2020/08/06 18:12, Thomas Levine wrote:
> The present patch changes the rc.subr(8) manual page to match
> the implementation.
> 
> The current manual page for rc.subr(8) says that $pexp is "A regular
> expression to be passed to pgrep(1) in order to find the desired process
> or to be passed to pkill(1) to stop it."
> 
> The file /etc/rc.d/rc.subr currently uses $pexp only as a fixed
> expression, with the -xf flags.
> 
>   > grep pexp /etc/rc.d/rc.subr
>   pexp=${pexp}
>   multicast nfs_server pexp pf pkg_scripts shlib_dirs spamd_black
> pgrep -T "${daemon_rtable}" -q -xf "${pexp}"
> pkill -HUP -T "${daemon_rtable}" -xf "${pexp}"
> pkill -T "${daemon_rtable}" -xf "${pexp}"
>   # make sure pexp matches the process (i.e. doesn't include the quotes)
>   pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
> 
> The -xf flags are explained in the pgrep(1) and pkill(1) man page.
> 
> -x  Require an exact match of the process name, or argument
> list if -f is given.  The default is to match any substring.

This means that the regular expression must match the full process
string. Equivalent to providing an expression with ^ at the start and
$ at the end of the.

> 
> The present patch replaces instances of "regular expression" with
> "fixed expression".
> 
> I also think a better phrasing would be to explain in the rc.subr(8)
> man page that $pexp is a substring of the process name with flags and
> that it uses pgrep with -xf. I might eventually do that in a separate
> patch.
> 
> 
> Index: rc.subr.8
> ===
> RCS file: /cvs/src/share/man/man8/rc.subr.8,v
> retrieving revision 1.37
> diff -u -p -r1.37 rc.subr.8
> --- rc.subr.8 21 Feb 2020 00:47:21 -  1.37
> +++ rc.subr.8 7 Aug 2020 00:46:34 -
> @@ -184,7 +184,7 @@ call
>  .It Ic rc_check
>  Search for processes of the service with
>  .Xr pgrep 1
> -using the regular expression given in the
> +using the fixed expression given in the
>  .Va pexp
>  variable.
>  .It Ic rc_start
> @@ -199,7 +199,7 @@ Send a
>  .Dv SIGTERM
>  signal using
>  .Xr pkill 1
> -on the regular expression given in the
> +on the fixed expression given in the
>  .Va pexp
>  variable.
>  .It Ic rc_reload
> @@ -207,7 +207,7 @@ Send a
>  .Dv SIGHUP
>  signal using
>  .Xr pkill 1
> -on the regular expression given in the
> +on the fixed expression given in the
>  .Va pexp
>  variable.
>  One has to make sure that sending
> @@ -267,7 +267,7 @@ functions.
>  User to run the daemon as, using
>  .Xr su 1 .
>  .It Va pexp
> -A regular expression to be passed to
> +A fixed expression to be passed to
>  .Xr pgrep 1
>  in order to find the desired process or to be passed to
>  .Xr pkill 1
> 



Re: [PATCH]: Add a check for upgrade feature to sysupgrade(8)

2020-08-03 Thread Stuart Henderson
On 2020/08/03 13:50, Solene Rapenne wrote:
> On Mon, 3 Aug 2020 13:28:38 +0200
> Emil Engler :
> 
> > ## Abstract
> > This patch adds an argument to sysupgrade(8) which makes it possible
> > to check if an upgrade is available, similar to "syspatch -c".
> > This works both, for snapshots and releases.
> > 
> > ## Usage
> > Add "-c" to sysupgrade.
> > If the script exits with a zero, an upgrade is available. If it fails
> > you are already on the newest version or an upgrade cannot be pulled
> > for whatever reason.
> > 
> > ## Motivation
> > I want a cronjob on my desktop (which is on -current) that checks
> > regularly if a new snapshot is available and notifies me if this is
> > the case. syspatch(8) already has such a feature, so why not add
> > one to sysupgrade? Also it could be useful on -stable and -release
> > systems.
> 
> it seems to me you could use this in your crontab
> 
> sysupgrade -n | grep "Already on last snapshot" || sh 
> send_mail_new_snasphot.sh
> 

That won't just check, it will stage the release for install on next boot.



Re: no output on glass console after switching to serial

2020-08-01 Thread Stuart Henderson
On 2020/08/01 22:21, Mark Kettenis wrote:
> > pci11 at ppb9 bus 10
> > vga1 at pci11 dev 0 function 0 "ASPEED Technology AST2000" rev 0x30
> 
> This is the BMC graphics and seems to be the only grapics device
> available on this machine.

Correct.

> > wsdisplay at vga1 not configured
> 
> And I think this means the BIOS did not configure it as the primary
> graphics device and/or an active VGA device.  I'm not sure VGA text
> mode will work in such a setup so even if wsdisplay(4) would attach
> here it probably wouldn't work.

Aha. That sounds plausible, thanks.

> Any reason why you've chosen to installl this machine as a "legacy
> BIOS" machine instead of UEFI?  I think the latter would have given
> you efifb(4).

Mostly because I normally pxeboot machines to install them, and I
couldn't figure out how to get that to work with UEFI.



no output on glass console after switching to serial

2020-08-01 Thread Stuart Henderson
I've just been building a machine with serial console to go to colo
tomorrow and have noticed that there's no output on glass console
after the "switching console to com0" message. The only getty running
after boot is the one on serial console.

I won't be able to do much in the way of testing on it now but thought
it would be worth flagging anyway. Anyone see similar on other machines?

>> OpenBSD/amd64 BOOT 3.52
boot>
booting hd0a:/bsd: 14488904+3191824+344096+0+872448 
[972760+128+1137936+860957]=0x14ddc88
entry point at 0x81001000
[ using 2972808 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.7-current (GENERIC.MP) #380: Fri Jul 31 09:04:24 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8464842752 (8072MB)
avail mem = 8193216512 (7813MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries)
bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018
bios0: Supermicro Super Server
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT SSDT 
SSDT PRAD DMAR HEST BERT ERST EINJ
acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) 
BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) 
BR3D(S4) RP01(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) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.27 MHz, 06-56-03
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,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 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03
cpu2: 
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03
cpu3: 
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.00 MHz, 06-56-03
cpu4: 

Re: cat(1): add more restrictive pledge(2)

2020-07-31 Thread Stuart Henderson
On 2020/07/31 00:07, tempmai...@firemail.cc wrote:
> I have to say I'm only a beginner to C but hopefully my patch is
> good.
> 
> This patch adds a second and more restrictive pledge (only "stdio"
> instead of "stdio rpath") after the getopt loop if there is no
> input file or if the input file is "-" (stdin) or a sequence of
> repeated instances of "-". It doesn't move argv past the last "-",
> and doesn't pledge if it runs into an input file other than "-".
> 
> I've compiled it and tested it with ktrace(1) and kdump(1) and it
> appears to work as expected and pledge correctly with at least
> these invocations:
> $ echo test | ./cat -uv # pledge("stdio", NULL);
> $ echo test | ./cat -uv -   # pledge("stdio", NULL);
> $ echo test | ./cat # pledge("stdio", NULL);
> $ echo test | ./cat - - -   # pledge("stdio", NULL);
> $ echo test | ./cat -   # pledge("stdio", NULL);
> $ echo test | ./cat - cat.c # pledge("stdio rpath", NULL);
> $ echo test | ./cat cat.c - # pledge("stdio rpath", NULL);
> 
> 
> 
> Index: bin/cat/cat.c
> ===
> RCS file: /cvs/src/bin/cat/cat.c,v
> retrieving revision 1.27
> diff -u -p -u -p -r1.27 cat.c
> --- bin/cat/cat.c 28 Jun 2019 13:34:58 -  1.27
> +++ bin/cat/cat.c 30 Jul 2020 23:21:14 -
> @@ -94,7 +94,26 @@ main(int argc, char *argv[])
>   "usage: %s [-benstuv] [file ...]\n", __progname);
>   return 1;
>   }
> + argc -= optind;
>   argv += optind;
> +
> + if (argc) {
> + if (!strcmp(*argv, "-")) {
> + do {
> + if (argc == 1) {
> + if (pledge("stdio", NULL) == -1)
> + err(1, "pledge");
> + argc--, argv++;
> + break;
> + } else
> + argc--, argv++;
> + } while (argc && !strcmp(*argv, "-"));
> + argc++, argv--;
> + }
> + } else {
> + if (pledge("stdio", NULL) == -1)
> + err(1, "pledge");
> + }
> 
>   if (bflag || eflag || nflag || sflag || tflag || vflag)
>   cook_args(argv);
> 

The improvement is fairly small; cat doesn't have network access or the
ability to write files with the previous pledge. Is this worth the
considerable extra complexity?

It's hard to get a feel for whether the argc/argv manipulation is correct.



Re: Python 3.8 os.listdir EINVAL on large directories

2020-07-26 Thread Stuart Henderson
Moving to tech.

In gmane.os.openbsd.misc, you wrote:
> Hi all,
>
> I am getting a stacktrace from the borg command in the borgbackup
> package while checking a backup (see bottom of email for full
> output, since it's verbose). The relevant part is this:
>
> filenames = os.listdir(os.path.join(data_path, dir))
>   OSError: [Errno 22] Invalid argument:
> '/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12'
>
> This is same error is reproducible with a test Python 3.8 program:
>
>  #!/usr/bin/env python
>
>  import os
>  os.listdir('/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/')
>
> Running ktrace & kdump reveals the error is from calling
> getdents(2):
>
>  76903 python3.8
> CALL  open(0x1ec7f06de3b0,0x3)
>  76903 python3.8
> NAMI  "/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/"
>  76903 python3.8 RET   open 3
>  [...]
>  76903 python3.8 CALL  getdents(3,0x1ec7c9257000,0x4000)
>  76903 python3.8 RET   getdents 16384/0x4000
>  [...]
>  76903 python3.8 CALL  getdents(3,0x1ec7c9257000,0x4000)
>  76903 python3.8 RET   getdents 16384/0x4000
>  [...]
>  76903 python3.8 CALL  getdents(3,0x1ec7c9257000,0x4000)
>  76903 python3.8 RET   getdents 16384/0x4000
>  [...]
>  76903 python3.8 CALL  getdents(3,0x1ec7c9257000,0x4000)
>  76903 python3.8 RET   getdents -1 errno 22 Invalid argument
>
> Looking at the man page for getdents(2), I found it interesting
> that it says this call "is not a portable interface and should not
> be used directly by applications" and it recommends using
> readdir(3) instead.

ktrace only shows system calls not library functions. I don't
see python calling getdents directly, there is a fair chance that
python is calling readdir, and readdir is calling getdents.

> To give you a rough idea of the number of files and filename sizes
> in this directory:
>
>   $ ls /mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/ | wc
>   15341534   10738

I haven't been able to recreate this including over nfs yet.
What filesystem type and mount options?

getdents(2) :-

   format.  Up to nbytes of data will be transferred.  nbytes must be greater
   than or equal to the block size associated with the file (see stat(2)).
   Some filesystems may not support getdents() with buffers smaller than this
   size.
...
   getdents() will fail if:
...
   [EINVAL]   The file referenced by fd is not a directory, or nbytes
  is too small for returning a directory entry or block of
  entries, or the current position pointer is invalid.

> Where does the problem lie -- the upstream Python code, the
> OpenBSD-specific patches in its port definition, or somewhere
> else? And in case it matters, this is a -current amd64 system,
> with "sysupgrade -s" executed on 7/15.
>
> Thank you,
> Aaron Miller
>
> --
> Exception ignored in:  0x1e17e13fd310>
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 180, in __del__
> assert False, "cleanup happened in Repository.__del__"
> AssertionError: cleanup happened in Repository.__del__
> Local Exception
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> line 4565, in main
> exit_code = archiver.run(args)
>   File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> line 4497, in run
> return set_ec(func(args))
>   File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> line 161, in wrapper
> with repository:
>   File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 190, in __enter__
> self.open(self.path, bool(self.exclusive),
> lock_wait=self.lock_wait, lock=self.do_lock)
>   File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 450, in open
> segment = self.io.get_latest_segment()
>   File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 1253, in get_latest_segment
> for segment, filename in self.segment_iterator(reverse=True):
>   File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 1241, in segment_iterator
> filenames = os.listdir(os.path.join(data_path, dir))
> OSError: [Errno 22] Invalid argument:
> '/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12'
>
> Platform: OpenBSD millipede.iforgotmy.name 6.7 GENERIC.MP#348
> amd64
> Borg: 1.1.13  Python: CPython 3.8.3 msgpack: 0.5.6
> PID: 31745  CWD: /mnt/thinkpad_void_obsd_borg
> sys.argv: ['/usr/local/bin/borg', 'check', 'thinkpad.borg']
> SSH_ORIGINAL_COMMAND: None
>
>



Re: Add ability to set control values with video(1)

2020-07-25 Thread Stuart Henderson
On 2020/07/25 09:20, Theo de Raadt wrote:
> The normal idiom is when last-close happens in a driver, all modal-state
> is lost and restored to default, and when you use the driver again --
> the new open gets you a raw configuration which is then changed via
> ioctl, before futher use.

Isn't this a bit like volume controls for audio which do exist outside
of a particular application's opening of the device?



Re: wsfontload(8): display number of characters in a loaded font

2020-07-17 Thread Stuart Henderson
Seems useful. While it's not especially likely anyone is parsing the output 
of this, just in case they are it's usually more admin-friendly to add a 
new column at the end unless there's a good reason not to.


--
 Sent from a phone, apologies for poor formatting.
On 16 July 2020 21:29:50 Frederic Cambus  wrote:


Hi tech@,

Here is a diff to add a new column to wsfontload -l output, which
reports the number of characters contained in a loaded font.

It's especially useful with user loaded fonts as they can contain more
than 256 characters.

Below is the current output of wsfontload -l, without the diff:

# Name Encoding  W  H
0 Boldface  ibm  8 16
1 Spleen 6x12   iso  6 12
2 Spleen 8x16   iso  8 16
3 Spleen 12x24  iso 12 24
4 Spleen 16x32  iso 16 32
5 Spleen 32x64  iso 32 64

And now with the diff:

# Name EncodingChars  W  H
0 Boldface  ibm  254  8 16
1 Spleen 6x12   iso   96  6 12
2 Spleen 8x16   iso  224  8 16
3 Spleen 12x24  iso  224 12 24
4 Spleen 16x32  iso  224 16 32
5 Spleen 32x64  iso  224 32 64

Comments? OK?

Index: usr.sbin/wsfontload/wsfontload.c
===
RCS file: /cvs/src/usr.sbin/wsfontload/wsfontload.c,v
retrieving revision 1.21
diff -u -p -r1.21 wsfontload.c
--- usr.sbin/wsfontload/wsfontload.c 28 Jun 2019 13:32:51 - 1.21
+++ usr.sbin/wsfontload/wsfontload.c 16 Jul 2020 16:11:18 -
@@ -141,7 +141,8 @@ main(int argc, char *argv[])

 if (list) {
 i = 0;
- p = " # Name Encoding  W  H";
+ p = " # Name Encoding" \
+"Chars  W  H";
 do {
 f.index = i;
 res = ioctl(wsfd, WSDISPLAYIO_LSFONT, );
@@ -151,10 +152,11 @@ main(int argc, char *argv[])
 puts(p);
 p = NULL;
 }
- printf("%2d %-32s %8s %2d %2d\n",
+ printf("%2d %-32s %8s %8d %2d %2d\n",
f.index, f.name,
encodings[f.encoding].name,
-f.fontwidth, f.fontheight);
+f.numchars, f.fontwidth,
+f.fontheight);
 }
 }
 i++;




Re: iked.conf.5: provide gre example

2020-07-16 Thread Stuart Henderson
On 2020/07/15 10:02, Theo de Raadt wrote:
> It is extremely unwise to use DNS names at this level (or things which
> look like DNS names).  The same problems that pf has with DNS, are
> present here.  You really don't want people to get into this habit.

Same in gre(4) config which needs addresses too. I agree.

> > +.Pp
> > +This example encrypts a
> > +.Xr gre 4
> > +tunnel from local machine A to peer D using FQDN-based public key
> > +authentication.
> > +.Ar transport
> > +mode is used to avoid duplicate encapsulation of GRE;

The inside encapsulation of IPsec tunnel mode is gif not gre, so it
isn't duplicate gre encap. "transport mode is used to avoid double
encapsulation" would do?

> > +.Ar dstid
> > +is set explicitly to the peer's FQDN such that its public key is looked up 
> > even
> > +if the peer does not send its FQDN as peer ID:
> > +.Bd -literal -offset indent
> > +ikev2 transport \e
> > +   proto gre \e
> > +   from A.example.com to D.example.com \e
> > +   peer D.example.com \e
> > +   dstid D.example.com
> > +.Ed
> >  .Sh SEE ALSO
> >  .Xr enc 4 ,
> >  .Xr ipsec 4 ,
> > 
> 



Re: empty rc.firsttime when installing

2020-07-14 Thread Stuart Henderson
On 2020/07/14 15:03, Denis Fondras wrote:
> I was upgrading an EdgeRouter and it restarted multiple times instead of 
> booting
> /bsd
> 
> When I had a chance to boot it correctly, I noticed that sysmerge and 
> fw_update
> were run multiple times.
> 
> This diff avoids filling rc.firsttime and rc.sysmerge.

hmm, that will cause problems for some things I do (the main one being:
sysupgrade -n, add a pkg_add -u line to rc.firsttime, reboot).

> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1154
> diff -u -p -r1.1154 install.sub
> --- distrib/miniroot/install.sub  26 May 2020 16:21:00 -  1.1154
> +++ distrib/miniroot/install.sub  14 Jul 2020 12:54:27 -
> @@ -2734,6 +2734,9 @@ finish_up() {
>   local _kernel_dir=/mnt/usr/share/relink/kernel
>   local _kernel=${MDKERNEL:-GENERIC} _syspatch_archs="amd64 arm64 i386"
>  
> + # Empty rc.firsttime
> + echo "" >/mnt/etc/rc.firsttime
> +
>   # Mount all known swap partitions.  This gives systems with little
>   # memory a better chance at running 'MAKEDEV all'.
>   if [[ -x /mnt/sbin/swapctl ]]; then
> @@ -2812,7 +2815,7 @@ finish_up() {
>  
>   # Ensure that sysmerge in batch mode is run on reboot.
>   [[ $MODE == upgrade ]] &&
> - echo "/usr/sbin/sysmerge -b" >>/mnt/etc/rc.sysmerge
> + echo "/usr/sbin/sysmerge -b" >/mnt/etc/rc.sysmerge
>  
>   # If a proxy was needed to fetch the sets, use it for fw_update and 
> syspatch
>   [[ -n $http_proxy ]] &&
> 



Re: silicom X710 ixl, unable to query phy types, no sff

2020-07-09 Thread Stuart Henderson
Thanks. The Intel NVM update on that link is the one I mentioned that
says not to use it on OEM cards, this is in the readme

"This package is intended to be used on Intel branded adapters. Please contact
your OEM vendor for an appropriate package. In some cases this package may
update an OEM device. This package only updates the NVM image for the device
family listed on the package. Each Intel Ethernet product family has its own
NVM Update Package."

The quad cards are expensive enough that I thought it prudent to
follow that advice and ask the vendor. If they had been less helpful then
maybe I would have tried the straight-from-Intel file anyway but no need
now :)


On 2020/07/09 20:55, Tom Smyth wrote:
> Hi Stuart,
> Just a suggestion
>  but I have had a difficult time with xl710s Last summer and my vendor
> advised me to upgrade the firmware on the cards
> if you upgrade
> The firmware can be downloaded from here:
> https://downloadcenter.intel.com/product/93104/Intel-Ethernet-Controller-XL710-BM1
> (check the exact chipset you have)
> 
> 
> You can apply the update by running "nvmupdate64e" and following the
> prompts. You'll need to restart the machine or power cycle ...
> 
> Hope this helps,
> 
> 
> 
> 
> 
> On Wed, 8 Jul 2020 at 23:09, Stuart Henderson  wrote:
> 
> > I have some ixl cards which show "unable to query phy types" at
> > attach time, and return either EIO or ENODEV if I try fetching sff
> > pages.
> >
> > I booted with SFP+ in all ixl ports and have this:
> >
> > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW
> > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c
> > ixl0: unable to query phy types
> > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW
> > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d
> > ixl1: unable to query phy types
> > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW
> > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e
> > ixl2: unable to query phy types
> > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW
> > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f
> > ixl3: unable to query phy types
> >
> > # ifconfig ixl sff
> > ixl0: flags=8802 mtu 1500
> > lladdr 00:e0:ed:75:a5:5c
> > index 3 priority 0 llprio 3
> > media: Ethernet autoselect
> > status: no carrier
> > ifconfig: ixl0 transceiver: Input/output error
> > ixl1: flags=8802 mtu 1500
> > lladdr 00:e0:ed:75:a5:5d
> > index 4 priority 0 llprio 3
> > media: Ethernet autoselect
> > status: no carrier
> > ifconfig: ixl1 transceiver: Input/output error
> > ixl2: flags=8802 mtu 1500
> > lladdr 00:e0:ed:75:a5:5e
> > index 5 priority 0 llprio 3
> > media: Ethernet autoselect (10GbaseLR full-duplex)
> > status: active
> > ifconfig: ixl2 transceiver: Operation not supported by device
> > ixl3: flags=8802 mtu 1500
> > lladdr 00:e0:ed:75:a5:5f
> > index 6 priority 0 llprio 3
> > media: Ethernet autoselect
> > status: no carrier
> > ifconfig: ixl3 transceiver: Input/output error
> >
> > With "ifconfig ixlX debug" set, I get this on the interface
> >
> > ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003
> >
> > Firmware on these are a bit older than the Intel cards that I've seen
> > so my first thought is to try updating, I've mailed Silicom to ask them
> > if they can provide anything newer (Intel's own downloads say not to
> > use them for non Intel-branded cards and I don't really want to
> > brick a card..), does anyone have other ideas while I'm waiting to
> > hear back from them?
> >
> >
> > OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul  8 10:37:10 MDT 2020
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 8464842752 (8072MB)
> > avail mem = 8193245184 (7813MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries)
> > bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018
> > bios0: Supermicro Super Server
> > acpi0 at bios0: ACPI 5.0
> > acpi0: sleep states S0 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT
> > SSDT SSDT PRAD DMAR HEST BERT ERST EINJ
> > acpi0: 

Re: silicom X710 ixl, unable to query phy types, no sff

2020-07-09 Thread Stuart Henderson
On 2020/07/09 22:57, David Gwynne wrote:
> ok.
>
> so the problem is the older api doenst support the "get phy types" command, 
> or the sff commands.

yes, looks like it.

> should we silence the "get phy types" error output?

I think that makes sense.

> is there a better errno to use when the sff command isn't supported? should 
> we add something to the manpage? should that something be "i'm not angry, 
> just disappointed"?

linux does this in the kernel driver (i40e_ethdev.c) 

static int i40e_get_module_info(struct rte_eth_dev *dev,
struct rte_dev_module_info *modinfo)
{
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t sff8472_comp = 0;
uint32_t sff8472_swap = 0;
uint32_t sff8636_rev = 0;
i40e_status status;
uint32_t type = 0;

/* Check if firmware supports reading module EEPROM. */
if (!(hw->flags & I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE)) {
PMD_DRV_LOG(ERR,
"Module EEPROM memory read not supported. "
"Please update the NVM image.\n");
return -EINVAL;
}


reported by ethtool like this

# /usr/sbin/ethtool --module-info ens1f2
Cannot get module EEPROM information: Invalid argument

btw, Silicom didn't recognise the firmware version as we print it (5.0.40043),
ethtool and the intel tools display it like this instead

# /usr/sbin/ethtool -i ens1f2
driver: i40e
version: 2.3.2-k
firmware-version: 5.02 0x80002248 0.0.0
expansion-rom-version:
bus-info: :05:00.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes



>
> > On 9 Jul 2020, at 10:36 pm, Stuart Henderson  wrote:
> >
> > Update on this: Silicom support responded promptly, asked sensible
> > questions, didn't immediately bail on the fact that I'm not running a
> > supported OS, and prepared an update (to run under Linux but the
> > Debian live image worked fine for this).
> >
> > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5c
> > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW 
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5d
> > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW 
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5e
> > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW 
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5f
> >
> > ixl3: flags=8802 mtu 1500
> >lladdr 00:e0:ed:75:a5:5f
> >index 6 priority 0 llprio 3
> >media: Ethernet autoselect (10GbaseLR full-duplex)
> >status: active
> >transceiver: SFP LC, 1310 nm, 10.0km SMF
> >model: FLEXOPTIX P.1396.10 rev A
> >serial: F78R21S, date: 2018-07-09
> >voltage: 3.30 V, bias current: 32.07 mA
> >temp: 29.43 C (low -25.00 C, high 90.00 C)
> >tx: -2.63 dBm (low -7.00 dBm, high 2.50 dBm)
> >rx: -4.75 dBm (low -16.00 dBm, high 1.00 dBm)
> >
> >
> >
> > On 2020/07/08 22:59, Stuart Henderson wrote:
> >> I have some ixl cards which show "unable to query phy types" at
> >> attach time, and return either EIO or ENODEV if I try fetching sff
> >> pages.
> >>
> >> I booted with SFP+ in all ixl ports and have this:
> >>
> >> ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c
> >> ixl0: unable to query phy types
> >> ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW 
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d
> >> ixl1: unable to query phy types
> >> ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW 
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e
> >> ixl2: unable to query phy types
> >> ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW 
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f
> >> ixl3: unable to query phy types
> >>
> >> # ifconfig ixl sff
> >> ixl0: flags=8802 mtu 1500
> >>lladdr 00:e0:ed:75:a5:5c
> >>index 3 priority 0 llprio 3
> >>media: Ethernet autoselect
> >>status: no carrier
> >> ifc

Re: silicom X710 ixl, unable to query phy types, no sff

2020-07-09 Thread Stuart Henderson
Update on this: Silicom support responded promptly, asked sensible
questions, didn't immediately bail on the fact that I'm not running a
supported OS, and prepared an update (to run under Linux but the
Debian live image worked fine for this).

ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 7.0.50775 
API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5c
ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW 7.0.50775 
API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5d
ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW 7.0.50775 
API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5e
ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW 7.0.50775 
API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5f

ixl3: flags=8802 mtu 1500
lladdr 00:e0:ed:75:a5:5f
index 6 priority 0 llprio 3
media: Ethernet autoselect (10GbaseLR full-duplex)
status: active
transceiver: SFP LC, 1310 nm, 10.0km SMF
model: FLEXOPTIX P.1396.10 rev A
serial: F78R21S, date: 2018-07-09
voltage: 3.30 V, bias current: 32.07 mA
temp: 29.43 C (low -25.00 C, high 90.00 C)
tx: -2.63 dBm (low -7.00 dBm, high 2.50 dBm)
rx: -4.75 dBm (low -16.00 dBm, high 1.00 dBm)



On 2020/07/08 22:59, Stuart Henderson wrote:
> I have some ixl cards which show "unable to query phy types" at
> attach time, and return either EIO or ENODEV if I try fetching sff
> pages.
> 
> I booted with SFP+ in all ixl ports and have this:
> 
> ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 
> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c
> ixl0: unable to query phy types
> ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW 
> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d
> ixl1: unable to query phy types
> ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW 
> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e
> ixl2: unable to query phy types
> ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW 
> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f
> ixl3: unable to query phy types
> 
> # ifconfig ixl sff
> ixl0: flags=8802 mtu 1500
> lladdr 00:e0:ed:75:a5:5c
> index 3 priority 0 llprio 3
> media: Ethernet autoselect
> status: no carrier
> ifconfig: ixl0 transceiver: Input/output error
> ixl1: flags=8802 mtu 1500
> lladdr 00:e0:ed:75:a5:5d
> index 4 priority 0 llprio 3
> media: Ethernet autoselect
> status: no carrier
> ifconfig: ixl1 transceiver: Input/output error
> ixl2: flags=8802 mtu 1500
> lladdr 00:e0:ed:75:a5:5e
> index 5 priority 0 llprio 3
> media: Ethernet autoselect (10GbaseLR full-duplex)
> status: active
> ifconfig: ixl2 transceiver: Operation not supported by device
> ixl3: flags=8802 mtu 1500
> lladdr 00:e0:ed:75:a5:5f
> index 6 priority 0 llprio 3
> media: Ethernet autoselect
> status: no carrier
> ifconfig: ixl3 transceiver: Input/output error
> 
> With "ifconfig ixlX debug" set, I get this on the interface
> 
> ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003
> 
> Firmware on these are a bit older than the Intel cards that I've seen
> so my first thought is to try updating, I've mailed Silicom to ask them
> if they can provide anything newer (Intel's own downloads say not to
> use them for non Intel-branded cards and I don't really want to
> brick a card..), does anyone have other ideas while I'm waiting to
> hear back from them?
> 
> 
> OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul  8 10:37:10 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8464842752 (8072MB)
> avail mem = 8193245184 (7813MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries)
> bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018
> bios0: Supermicro Super Server
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT 
> SSDT SSDT PRAD DMAR HEST BERT ERST EINJ
> acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) 
> BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) 
> BR3D(S4) RP01(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) Xeon(R) CPU 

silicom X710 ixl, unable to query phy types, no sff

2020-07-08 Thread Stuart Henderson
I have some ixl cards which show "unable to query phy types" at
attach time, and return either EIO or ENODEV if I try fetching sff
pages.

I booted with SFP+ in all ixl ports and have this:

ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 5.0.40043 
API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c
ixl0: unable to query phy types
ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW 5.0.40043 
API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d
ixl1: unable to query phy types
ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW 5.0.40043 
API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e
ixl2: unable to query phy types
ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW 5.0.40043 
API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f
ixl3: unable to query phy types

# ifconfig ixl sff
ixl0: flags=8802 mtu 1500
lladdr 00:e0:ed:75:a5:5c
index 3 priority 0 llprio 3
media: Ethernet autoselect
status: no carrier
ifconfig: ixl0 transceiver: Input/output error
ixl1: flags=8802 mtu 1500
lladdr 00:e0:ed:75:a5:5d
index 4 priority 0 llprio 3
media: Ethernet autoselect
status: no carrier
ifconfig: ixl1 transceiver: Input/output error
ixl2: flags=8802 mtu 1500
lladdr 00:e0:ed:75:a5:5e
index 5 priority 0 llprio 3
media: Ethernet autoselect (10GbaseLR full-duplex)
status: active
ifconfig: ixl2 transceiver: Operation not supported by device
ixl3: flags=8802 mtu 1500
lladdr 00:e0:ed:75:a5:5f
index 6 priority 0 llprio 3
media: Ethernet autoselect
status: no carrier
ifconfig: ixl3 transceiver: Input/output error

With "ifconfig ixlX debug" set, I get this on the interface

ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003

Firmware on these are a bit older than the Intel cards that I've seen
so my first thought is to try updating, I've mailed Silicom to ask them
if they can provide anything newer (Intel's own downloads say not to
use them for non Intel-branded cards and I don't really want to
brick a card..), does anyone have other ideas while I'm waiting to
hear back from them?


OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul  8 10:37:10 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8464842752 (8072MB)
avail mem = 8193245184 (7813MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries)
bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018
bios0: Supermicro Super Server
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT SSDT 
SSDT PRAD DMAR HEST BERT ERST EINJ
acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) 
BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) 
BR3D(S4) RP01(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) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.27 MHz, 06-56-03
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC skew=0 observed drift=0
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: TSC skew=4 observed drift=0
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.00 MHz, 06-56-03
cpu2: 

Re: Use VGA text mode palette RGB values in rasops(9)

2020-07-07 Thread Stuart Henderson
On 2020/07/07 15:16, Frederic Cambus wrote:
> Hi tech@,
> 
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
> 
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from the original rasops palette carefully matched what OpenFirmware
> uses for the console on sparc64.

..and they're a good choice on sparc64 console with the pale background
that the palette is normally used with.

I agree that the blue we have now is a bit too dark against a black
background.



Re: userland clock_gettime proof of concept

2020-07-01 Thread Stuart Henderson
running on 38 of these, btw.

OpenBSD 6.7-current (GENERIC.MP) #0: Sat Jun 27 21:15:58 BST 2020
sthen@...:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4169592832 (3976MB)
avail mem = 4028198912 (3841MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec170 (83 entries)
bios0: vendor Intel Corp. version "WYLPT10H.86A.0044.2016.1214.1710" date 
12/14/2016
bios0: Intel Corporation D34010WYK
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT MCFG HPET SSDT SSDT DMAR CSRT
acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) 
PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) 
HDEF(S4) PEG0(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) i3-4010U CPU @ 1.70GHz, 1696.34 MHz, 06-45-01
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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC skew=0 observed drift=0
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
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) i3-4010U CPU @ 1.70GHz, 1696.09 MHz, 06-45-01
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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: TSC skew=-22 observed drift=0
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, 1696.08 MHz, 06-45-01
cpu2: 
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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: TSC skew=-8 observed drift=0
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, 1696.08 MHz, 06-45-01
cpu3: 
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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: TSC skew=-22 observed drift=0
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus -1 (PEG0)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
 0x3f - 0xff
extent `acpipci0 pciio' (0x0 - 0x), flags=0
 0xcf8 - 0xcff
 0x1 - 0x
extent `acpipci0 pcimem' (0x0 - 0x), flags=0
 0x0 - 0x9
 0xc - 0xc
 0xe8000 - 0xdf1f
 0xfeb0 - 0x
acpicmos0 at acpi0

Re: Stuck in Needbuf state, trying to understand (6.7)

2020-06-26 Thread Stuart Henderson
On 2020/06/26 15:30, sven falempin wrote:
> behavior confirmed on current.
> 
> Once the process stalls,  ( could be anything writing to the vnconfig disk,
> cp , umount )
> a few other calls like df , or ps, etc may hang, never the same
> sp or mp kernel, reproduced on today's snapshots.

vnconfig is used as part of "make release", many builds are done every
week using this so it's not a general problem with vnconfig.

Can you show some commands or a script to trigger the behaviour?



awk FS behaviour change

2020-06-26 Thread Stuart Henderson
The Sep 10, 2019 version of awk introduced a change in handling this:

  ifconfig egress | awk '/inet / {FS="[ .]"; print "host-"$4"-"$5"}'

Given a line like

inet 10.20.30.40 netmask 0xff00 broadcast 10.20.30.255

it used to return host-30-40, now it returns host-0xfff0-broadcast.
The new behaviour is the same as gawk and old behaviour can be obtained
by doing this instead

  ifconfig egress | awk -F '[ .]' '/inet / {print "host-"$4"-"$5}'

I don't know which is "correct" (the manpage isn't enlightening) but
it was a bit unexpected so I wanted to at least draw attention to it
in case it breaks somebody else's script.



Re: Blacklist Ericsson F5521GW from umass

2020-06-22 Thread Stuart Henderson
On 2020/06/22 14:10, Tobias Heider wrote:
> On Mon, Jun 22, 2020 at 02:01:43PM +0200, Tobias Heider wrote:
> > Hi,
> > 
> > I noticed that the ramdisk takes ages to boot on my T420.
> > It seems that without umodem in the kernel, umass tries to attach to my
> > Erricson F5521GW WAN modem and fails after a annoyingly long timeout.
> > 
> > The diff below should prevent umass from matching this device.
> > 
> > ok?
> > 
> 
> Whoops, small update because uq_match should be UMATCH_NONE.
> 
> diff --git a/sys/dev/usb/umass_quirks.c b/sys/dev/usb/umass_quirks.c
> index cf17d07ef96..ba80c4fb6a6 100644
> --- a/sys/dev/usb/umass_quirks.c
> +++ b/sys/dev/usb/umass_quirks.c
> @@ -473,6 +473,14 @@ const struct umass_quirk umass_quirks[] = {
>UMATCH_VENDOR_PRODUCT,
>NULL, NULL
>   },
> +
> + { { USB_VENDOR_ERICSSON, USB_PRODUCT_ERICSSON_F5521GW },
> +  UMASS_WPROTO_UNSPEC, UMASS_CPROTO_UNSPEC,
> +  0,
> +  0,
> +  UMATCH_NONE,
> +  NULL, NULL
> + },
>  };
>  
>  const struct umass_quirk *
> diff --git a/sys/dev/usb/usbdevs.h b/sys/dev/usb/usbdevs.h
> index 45fda88512f..e9d2b6e6169 100644
> --- a/sys/dev/usb/usbdevs.h
> +++ b/sys/dev/usb/usbdevs.h

Generally OK but don't commit directly to usbdevs.h.

Edit usbdevs, commit, run "make", then commit the generated files
usbdevs_data.h and usbdevs.h.

> @@ -427,6 +427,7 @@
>  #define  USB_VENDOR_AMBIT0x0bb2  /* Ambit Microsystems */
>  #define  USB_VENDOR_HTC  0x0bb4  /* HTC */
>  #define  USB_VENDOR_REALTEK  0x0bda  /* Realtek */
> +#define  USB_VENDOR_ERICSSON 0x0bdb  /* Ericsson  */
>  #define  USB_VENDOR_MEI  0x0bed  /* MEI */
>  #define  USB_VENDOR_ADDONICS20x0bf6  /* Addonics Technology 
> */
>  #define  USB_VENDOR_FSC  0x0bf8  /* Fujitsu Siemens Computers */
> @@ -1774,6 +1775,9 @@
>  #define  USB_PRODUCT_EPSON_DX60000x082e  /* Stylus 
> DX6000 */
>  #define  USB_PRODUCT_EPSON_DX40000x082f  /* Stylus 
> DX4000 */
>  
> +/* Ericsson products */
> +#define USB_PRODUCT_ERICSSON_F5521GW 0x1911  /* Wireless WAN */
> +
>  /* e-TEK Labs products */
>  #define  USB_PRODUCT_ETEK_1COM   0x8007  /* Serial */
>  
> 



Re: sample unbound.conf tweak

2020-06-21 Thread Stuart Henderson
On 2020/06/21 18:29, Klemens Nanni wrote:
> On Sun, Jun 21, 2020 at 04:47:22PM +0100, Stuart Henderson wrote:
> > An "uncomment" was left in when we reenabled dnssec by default,
> > and it seems a bit pointless to say "comment out to disable".  ok?
> Reads better, yes.
>  
> > Index: unbound.conf
> > ===
> > RCS file: /cvs/src/etc/unbound.conf,v
> > retrieving revision 1.19
> > diff -u -p -r1.19 unbound.conf
> > --- unbound.conf7 Nov 2019 15:46:37 -   1.19
> > +++ unbound.conf21 Jun 2020 15:46:34 -
> > @@ -19,12 +19,12 @@ server:
> > hide-identity: yes
> > hide-version: yes
> >  
> > -   # Perform DNSSEC validation. Comment out the below option to
> > disable.
> Your MUA broke this line, it seems.

editor actually. thanks.

> 
> > +   # Perform DNSSEC validation.
> > #
> > auto-trust-anchor-file: "/var/unbound/db/root.key"
> > val-log-level: 2
> >  
> > -   # Uncomment to synthesize NXDOMAINs from DNSSEC NSEC chains
> > +   # Synthesize NXDOMAINs from DNSSEC NSEC chains.
> > # https://tools.ietf.org/html/rfc8198
> > #
> > aggressive-nsec: yes
> > 
> 



Re: lfence for rdtsc

2020-06-21 Thread Stuart Henderson
On 2020/06/21 18:46, Paul Irofti wrote:
> 
> 
> În 21 iunie 2020 16:30:43 EEST, Theo de Raadt  a scris:
> >Paul Irofti  wrote:
> >
> >> If you change the name to rdtsc_ordered(), OK.
> >
> >That is a weaker name.
> >
> >Ordered in what way, at what level; ordered against what?
> >
> >This is using a specific pipeline ordering known as lfence.
> >So it might as well say lfence.  That is the technical name for
> >that type of ordering.  Being vague is unhelpful.
> 
> 
> Ok then, if you think that's best.
> 

Any idea why in
https://www.intel.com/content/www/us/en/embedded/training/ia-32-ia-64-benchmark-code-execution-paper.html
they are using cpuid to serialize access instead of lfence?



sample unbound.conf tweak

2020-06-21 Thread Stuart Henderson
An "uncomment" was left in when we reenabled dnssec by default,
and it seems a bit pointless to say "comment out to disable".  ok?


Index: unbound.conf
===
RCS file: /cvs/src/etc/unbound.conf,v
retrieving revision 1.19
diff -u -p -r1.19 unbound.conf
--- unbound.conf7 Nov 2019 15:46:37 -   1.19
+++ unbound.conf21 Jun 2020 15:46:34 -
@@ -19,12 +19,12 @@ server:
hide-identity: yes
hide-version: yes
 
-   # Perform DNSSEC validation. Comment out the below option to
disable.
+   # Perform DNSSEC validation.
#
auto-trust-anchor-file: "/var/unbound/db/root.key"
val-log-level: 2
 
-   # Uncomment to synthesize NXDOMAINs from DNSSEC NSEC chains
+   # Synthesize NXDOMAINs from DNSSEC NSEC chains.
# https://tools.ietf.org/html/rfc8198
#
aggressive-nsec: yes



Re: userland clock_gettime proof of concept

2020-06-19 Thread Stuart Henderson
On 2020/06/19 20:28, Paul Irofti wrote:
> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> > I don't expect userland processes to call CLOCK_UPTIME in a loop like
> > they tend to do do for CLOCK_MONOTONIC and CLOCK_REALTIME.  Linux
> > doesn't have it ;).
> 
> I don't care eitherway about this. But I don't see why we would not have
> this functionality if it is easy to offer. Maybe someone can help us
> grep the ports tree for this? Stuart? :)

I don't have time to run a grep at the moment but have looked at
https://codesearch.debian.net/search?q=CLOCK_UPTIME=1 which
I think is good enough to show anything important. Most occurrences
are constants in languages. There are a couple of small uses in
code but not much e.g.

https://sources.debian.org/src/rsyslog/8.2004.0-1/runtime/msg.c/?hl=3857#L3857
https://sources.debian.org/src/mactelnet/0.4.4-4/src/mactelnetd.c/?hl=837#L837

The important ones are gettimeofday/CLOCK_MONOTONIC and to a lesser
extent CLOCK_REALTIME.



pckbd_enable: command error. anything to worry about?

2020-06-17 Thread Stuart Henderson
It doesn't seem to be causing a problem but I've noticed these recently
and thought I'd write a mail to at least document it / when it started.

2020-06-17T11:00:52.021Z symphytum /bsd: root on sd1a (2b4432fd9000a5b7.a) swap 
on sd1b dump on sd1b
2020-06-17T11:00:52.021Z symphytum /bsd: inteldrm0: 1920x1200, 32bpp
2020-06-17T11:00:52.021Z symphytum /bsd: wsdisplay0 at inteldrm0 mux 1
2020-06-17T11:00:52.021Z symphytum /bsd: pckbd_enable: command error
2020-06-17T11:00:52.021Z symphytum /bsd: wskbd1: connecting to wsdisplay0
2020-06-17T11:00:52.021Z symphytum /bsd: wskbd2: connecting to wsdisplay0
2020-06-17T11:00:52.022Z symphytum /bsd: wsdisplay0: screen 0-5 added (std, 
vt100 emulation)
2020-06-17T11:01:10.626Z symphytum /bsd: pckbd_enable: command error
2020-06-17T11:01:10.676Z symphytum /bsd: pckbd_disable: command error

First seen with
OpenBSD 6.7-current (GENERIC.MP) #24: Thu May 28 16:43:24 BST 2020

Previous kernel before I was running that
OpenBSD 6.7-current (GENERIC.MP) #213: Sat May 23 20:38:40 MDT 2020

2020-06-17T11:00:51.991Z symphytum /bsd: OpenBSD 6.7-current (GENERIC.MP) #5: 
Wed Jun 17 11:38:10 BST 2020
2020-06-17T11:00:51.991Z symphytum /bsd: 
st...@symphytum.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP
2020-06-17T11:00:51.992Z symphytum /bsd: real mem = 34247069696 (32660MB)
2020-06-17T11:00:51.992Z symphytum /bsd: avail mem = 33194221568 (31656MB)
2020-06-17T11:00:51.992Z symphytum /bsd: random: good seed from bootblocks
2020-06-17T11:00:51.992Z symphytum /bsd: mpath0 at root
2020-06-17T11:00:51.992Z symphytum /bsd: scsibus0 at mpath0: 256 targets
2020-06-17T11:00:51.992Z symphytum /bsd: mainbus0 at root
2020-06-17T11:00:51.992Z symphytum /bsd: bios0 at mainbus0: SMBIOS rev. 2.7 @ 
0xec400 (92 entries)
2020-06-17T11:00:51.993Z symphytum /bsd: bios0: vendor Dell Inc. version "A12" 
date 05/11/2017
2020-06-17T11:00:51.993Z symphytum /bsd: bios0: Dell Inc. PowerEdge T20
2020-06-17T11:00:51.993Z symphytum /bsd: acpi0 at bios0: ACPI 5.0
2020-06-17T11:00:51.993Z symphytum /bsd: acpi0: sleep states S0 S4 S5
2020-06-17T11:00:51.994Z symphytum /bsd: acpi0: tables DSDT FACP APIC FPDT SLIC 
LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! DMAR
2020-06-17T11:00:51.994Z symphytum /bsd: acpi0: wakeup devices UAR1(S4) 
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP05(S4) PXSX(S4) PXSX(S4) 
PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(S4) [...]
2020-06-17T11:00:51.994Z symphytum /bsd: acpitimer0 at acpi0: 3579545 Hz, 24 
bits
2020-06-17T11:00:51.994Z symphytum /bsd: acpimadt0 at acpi0 addr 0xfee0: 
PC-AT compat
2020-06-17T11:00:51.994Z symphytum /bsd: cpu0 at mainbus0: apid 0 (boot 
processor)
2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: Intel(R) Xeon(R) CPU E3-1225 v3 
@ 3.20GHz, 3392.57 MHz, 06-3c-03
2020-06-17T11:00:51.995Z symphytum /bsd: 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: 256KB 64b/line 8-way L2 cache
2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: smt 0, core 0, package 0
2020-06-17T11:00:51.995Z symphytum /bsd: mtrr: Pentium Pro MTRR support, 10 var 
ranges, 88 fixed ranges
2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: apic clock running at 99MHz
2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: mwait min=64, max=64, 
C-substates=0.2.1.2.4, IBE
2020-06-17T11:00:51.996Z symphytum /bsd: cpu1 at mainbus0: apid 2 (application 
processor)
2020-06-17T11:00:51.996Z symphytum /bsd: cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 
@ 3.20GHz, 3392.17 MHz, 06-3c-03
2020-06-17T11:00:51.996Z symphytum /bsd: 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
2020-06-17T11:00:51.996Z symphytum /bsd: cpu1: 256KB 64b/line 8-way L2 cache
2020-06-17T11:00:51.996Z symphytum /bsd: cpu1: smt 0, core 1, package 0
2020-06-17T11:00:51.996Z symphytum /bsd: cpu2 at mainbus0: apid 4 (application 
processor)
2020-06-17T11:00:51.996Z symphytum /bsd: cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 
@ 3.20GHz, 3392.17 MHz, 06-3c-03
2020-06-17T11:00:51.996Z symphytum /bsd: cpu2: 

ddb(4): tr /t 0t

2020-06-17 Thread Stuart Henderson
Every time I want to use this I spend several minutes figuring out rhe
correct prefix, it would help to add a note.  Ok?

Index: man4/ddb.4
===
RCS file: /cvs/src/share/man/man4/ddb.4,v
retrieving revision 1.97
diff -u -p -r1.97 ddb.4
--- man4/ddb.4  17 May 2020 14:34:35 -  1.97
+++ man4/ddb.4  17 Jun 2020 09:31:49 -
@@ -557,6 +557,8 @@ modifier interprets the
 .Ar frameaddr
 argument as the TID of a process and shows the stack trace of
 that process.
+.Ar frameaddr
+is subject to the radix; use the 0t prefix to enter a decimal TID.
 The
 .Cm /t
 modifier is not supported on all platforms.



Re: netstat -R: list rdomains with associated ifs and tables

2020-06-14 Thread Stuart Henderson
On 2020/06/13 23:29, Sebastian Benoit wrote:
> Of course that makes parsing the output more difficult.

not really..

netstat -R|awk -F : '/Routing table/ {print $2}'



Re: netstat -R: list rdomains with associated ifs and tables

2020-06-10 Thread Stuart Henderson
It's useful information, I like it. (I preferred it with the route
count, but I agree, it's hard on the system if there's a full DFZ
table).

One thing though -

> twister ..in/netstat$ obj/netstat -R 
> Rdomain 0
>   Interfaces: lo0 iwm0 re0 enc0 pflog0
>   Routing tables: 0 6 7 77

When there are multiple tables it's clear that this is a list of
table numbers, but when there's only one the output text is confusing:

Rdomain 0
  Interfaces: lo0 em1 enc0 tun2 vlan1 pflog0
  Routing tables: 0

"there are zero routing tables?"

Rdomain 100
  Interfaces: vether100 lo100 vether101 [...]
  Routing tables: 100

"there are 100 tables?"

This would be clearer if it used table/tables as appropriate e.g.

  Routing table: 0
  Routing table: 100
  Routing tables: 0 6 7 77

the code to handle this gets messy though, maybe someone can think
of alternative wording that gets around this another way..



Re: userland clock_gettime proof of concept

2020-06-08 Thread Stuart Henderson
On 2020/06/08 12:59, Paul Irofti wrote:
> This iteration of the diff adds bounds checking for tk_user and moves
> the usertc.c stub to every arch in libc as recommanded by deraadt@.
> It also fixes a gettimeofday issue reported by cheloha@ and tb@.
> 
> The acpihpet stub is still there, but it will be removed in the final
> diff.

Good timing as I wanted to update my kernel for the DRM update anyway
now that I don't have to pick that out of git :)

FWIW it's still working as expected on my uninteresting amd64.



Re: Some redundant code lines in sys

2020-06-05 Thread Stuart Henderson
On 2020/06/05 13:50, Denis Fondras wrote:
> On Fri, Jun 05, 2020 at 12:56:21PM +0200, Prof. Dr. Steffen Wendzel wrote:
> > Dear all:
> > 
> > just in case this appears useful to you: I found some redundant code
> > lines in the following files.
> > 
> > sys/net/pipex.h:
> >struct pipex_session  *pipex_pppoe_lookup_session (struct mbuf *);
> >struct pipex_session  *pipex_pppoe_lookup_session (struct mbuf *);
> > 
> > usr.sbin/relayd/agentx.c
> >snmp_agentx_oid(pdu, oid) == -1 ||
> >snmp_agentx_oid(pdu, oid) == -1 ||
> > 
> > usr.sbin/snmpd/agentx.c:
> >  snmp_agentx_oid(pdu, oid) == -1 ||
> >  snmp_agentx_oid(pdu, oid) == -1 ||

My first thought for these two was "were they just accidentally
duplicated, or was something else meant to be there instead". Looking at
the commit and code (the function is identical in snmpd and relayd) I am
going more on the side of accidental dup (plus removing it doesn't
change behaviour of code that been running for a while) so OK with me.

> > 
> > usr.sbin/bgpd/rde.h:
> >   void path_init(u_int32_t);
> >   void path_init(u_int32_t);
> > 
> > lib/libcurses/nc_tparm.h:
> > #define TPARM_1(a,b) TPARM_2(a,b,0)
> > #define TPARM_1(a,b) TPARM_2(a,b,0)
> > 
> 
> Nice catch, thank you.
> 
> 
> Index: lib/libcurses/nc_tparm.h
> ===
> RCS file: /cvs/src/lib/libcurses/nc_tparm.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 nc_tparm.h
> --- lib/libcurses/nc_tparm.h  12 Jan 2010 23:21:59 -  1.1
> +++ lib/libcurses/nc_tparm.h  5 Jun 2020 11:45:41 -
> @@ -62,6 +62,5 @@
>  #define TPARM_3(a,b,c,d) TPARM_4(a,b,c,d,0)
>  #define TPARM_2(a,b,c) TPARM_3(a,b,c,0)
>  #define TPARM_1(a,b) TPARM_2(a,b,0)
> -#define TPARM_1(a,b) TPARM_2(a,b,0)
>  #define TPARM_0(a) TPARM_1(a,0)
>  #endif
> Index: sys/net/pipex.h
> ===
> RCS file: /cvs/src/sys/net/pipex.h,v
> retrieving revision 1.22
> diff -u -p -r1.22 pipex.h
> --- sys/net/pipex.h   26 May 2020 07:06:37 -  1.22
> +++ sys/net/pipex.h   5 Jun 2020 11:45:44 -
> @@ -206,7 +206,6 @@ int   pipex_notify_close
>  
>  struct mbuf   *pipex_output (struct mbuf *, int, int, struct 
> pipex_iface_context *);
>  struct pipex_session  *pipex_pppoe_lookup_session (struct mbuf *);
> -struct pipex_session  *pipex_pppoe_lookup_session (struct mbuf *);
>  struct mbuf   *pipex_pppoe_input (struct mbuf *, struct 
> pipex_session *);
>  struct pipex_session  *pipex_pptp_lookup_session (struct mbuf *);
>  struct mbuf   *pipex_pptp_input (struct mbuf *, struct pipex_session 
> *);
> Index: usr.sbin/bgpd/rde.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
> retrieving revision 1.233
> diff -u -p -r1.233 rde.h
> --- usr.sbin/bgpd/rde.h   24 Jan 2020 05:44:05 -  1.233
> +++ usr.sbin/bgpd/rde.h   5 Jun 2020 11:45:45 -
> @@ -557,7 +557,6 @@ re_rib(struct rib_entry *re)
>  }
>  
>  void  path_init(u_int32_t);
> -void  path_init(u_int32_t);
>  void  path_shutdown(void);
>  void  path_hash_stats(struct rde_hashstats *);
>  int   path_compare(struct rde_aspath *, struct rde_aspath *);
> Index: usr.sbin/relayd/agentx.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/agentx.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 agentx.c
> --- usr.sbin/relayd/agentx.c  28 May 2017 10:39:15 -  1.14
> +++ usr.sbin/relayd/agentx.c  5 Jun 2020 11:45:45 -
> @@ -654,7 +654,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
>  
>   if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
>   snmp_agentx_oid(pdu, oid) == -1 ||
> - snmp_agentx_oid(pdu, oid) == -1 ||
>   (range_index && snmp_agentx_int(pdu, _bound) == -1)) {
>   snmp_agentx_pdu_free(pdu);
>   return (NULL);
> Index: usr.sbin/snmpd/agentx.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 agentx.c
> --- usr.sbin/snmpd/agentx.c   17 Jun 2018 18:19:59 -  1.13
> +++ usr.sbin/snmpd/agentx.c   5 Jun 2020 11:45:45 -
> @@ -658,7 +658,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
>  
>   if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
>   snmp_agentx_oid(pdu, oid) == -1 ||
> - snmp_agentx_oid(pdu, oid) == -1 ||
>   (range_index && snmp_agentx_int(pdu, _bound) == -1)) {
>   snmp_agentx_pdu_free(pdu);
>   return (NULL);
> 



Re: top: Fill last character in process line

2020-06-03 Thread Stuart Henderson
On 2020/06/03 14:49, Klemens Nanni wrote:
> On Wed, Jun 03, 2020 at 12:45:35PM +0100, Stuart Henderson wrote:
> > It should check terminal capabilities for this, see termcap(5).
> > If 'am' (auto-margin) is set then it shouldn't write to the final column.
> > If 'xn' is set then it's OK in some circumstances (it's probably easier to
> > skip writing to the final column if this is set too).
> Thanks mark and Stuart, I did not know about auto-margin (or autoWrap as
> xterm(1) seems to call it).
> 
> What I understand is that writing to the screen's last terminal should
> be avoided in terminal without the "am" capability, presumably because
> it would cause a line wrap - is that correct?
> 
> Preliminary testing however indicates to me that at least xterm(1)
> behaves the same in top's interactive screen with my patch, regardless
> of the auto-margin capablility.
> 
> According to termcap(5) I did the following to disable "am", with
> tput(1) I verify that it gets indeed disabled:
> 
>   $  echo $TERM ; tput am ; echo $?
>   xterm
>   0
>   $ TERM=vt100-nam ; tput am ; echo $?
>   1
> 
> But in both cases, starting ./obj/top in the very same terminal/shell
> behaves the same, that is to say the last column is written properly and
> I see no line wrap or any change of behaviour.
> 

termcap/TERM isn't an instruction to the terminal to behave in a
certain way, it describes characteristics of the actual terminal (or
terminal emulator). Most of the common X-based emulators don't have the
same characteristic. Even when they have something that looks similar
e.g. xterm in "autowraparound" mode, it isn't quite the same thing as
automargin as it only wraps when you've printed a char in the right-hand
column and then print an additional char.

It's quite possible you will need to find certain types of older real
hardware terminal to see the behaviour that requires 'am' handling.

(You *can* still print to the RH column of most lines with an auto-margin
terminal, as long as you don't send an extra linefeed. However you can't
write to the RH column of the bottom line of the screen without shifting
chars into place. The easy way out is to just not print to RH column on
am terminals).



Re: top: Fill last character in process line

2020-06-03 Thread Stuart Henderson
On 2020/06/03 12:46, Klemens Nanni wrote:
> 
> i_process() prints process lines from the global buffer thisline[MAX_COLS]
> which is filed by format_next_process() using snprintf(3), i.e. it is
> guaranteed to be NUL terminated.
> 
> display_width is always set to screen_width and capped to MAX_COLS-1
> in display_resize(), so NUL terminating thisline[] at index
> display_width is not only redundant but also cuts off the last visibile
> character for each process line.
> 
> Remove this redundancy to make top use the entire line and not have
> process names (or arguments) end one char too early in interactive use.
> 
> Feedback? OK?

It should check terminal capabilities for this, see termcap(5).
If 'am' (auto-margin) is set then it shouldn't write to the final column.
If 'xn' is set then it's OK in some circumstances (it's probably easier to
skip writing to the final column if this is set too).



Re: drop addtrust from cert.pem?

2020-06-03 Thread Stuart Henderson
On 2020/06/02 21:38, Bob Beck wrote:
> On Mon, Jun 01, 2020 at 06:04:17PM +0100, Stuart Henderson wrote:
> > OK to drop the expired AddTrust cert from cert.pem?
> 
> yes, thanks.
> 
> > 
> > I checked against the firefox set, there are no new/removed certs that
> > work with libressl there. There are now two with GENERALIZEDTIME notAfter
> > dates from before 2050 that don't work though (I only remember seeing one
> > of those when I last looked).. but that is a separate issue.
> > 
> > /C=EE/O=AS Sertifitseerimiskeskus/CN=EE Certification Centre Root 
> > CA/emailAddress=p...@sk.ee
> > /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification 
> > Authority/CN=Certum Trusted Network CA 2
> 
> I suspect these can safely be dropped too.

I haven't included them anyway because they don't work with libressl.
btw Mozilla knew about this at least when they added the Certum one,

https://bugzilla.mozilla.org/show_bug.cgi?id=999378#c30

"mozilla::pkix does not enforce this rule about when Generalized Time
may be used. If we decide to add code to enforce this rule, it will be
for certificates created after a certain date (definitely later than
2013)"

Not sure what the Certum one is used for, the p...@sk.ee one is kinda
important, it's used for https://en.wikipedia.org/wiki/Estonian_identity_card



drop addtrust from cert.pem?

2020-06-01 Thread Stuart Henderson
OK to drop the expired AddTrust cert from cert.pem?

I checked against the firefox set, there are no new/removed certs that
work with libressl there. There are now two with GENERALIZEDTIME notAfter
dates from before 2050 that don't work though (I only remember seeing one
of those when I last looked).. but that is a separate issue.

/C=EE/O=AS Sertifitseerimiskeskus/CN=EE Certification Centre Root 
CA/emailAddress=p...@sk.ee
/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum 
Trusted Network CA 2


Index: cert.pem
===
RCS file: /cvs/src/lib/libcrypto/cert.pem,v
retrieving revision 1.20
diff -u -p -r1.20 cert.pem
--- cert.pem10 Apr 2020 12:13:17 -  1.20
+++ cert.pem1 Jun 2020 16:59:23 -
@@ -350,58 +350,6 @@ LysRJyU3eExRarDzzFhdFPFqSBX/wge2sY0PjlxQ
 LnPqZih4zR0Uv6CPLy64Lo7yFIrM6bV8+2ydDKXhlg==
 -END CERTIFICATE-
 
-### AddTrust AB
-
-=== /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
-Certificate:
-Data:
-Version: 3 (0x2)
-Serial Number: 1 (0x1)
-Signature Algorithm: sha1WithRSAEncryption
-Validity
-Not Before: May 30 10:48:38 2000 GMT
-Not After : May 30 10:48:38 2020 GMT
-Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, 
CN=AddTrust External CA Root
-X509v3 extensions:
-X509v3 Subject Key Identifier: 
-AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
-X509v3 Key Usage: 
-Certificate Sign, CRL Sign
-X509v3 Basic Constraints: critical
-CA:TRUE
-X509v3 Authority Key Identifier: 
-
keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
-DirName:/C=SE/O=AddTrust AB/OU=AddTrust External TTP 
Network/CN=AddTrust External CA Root
-serial:01
-
-SHA1 Fingerprint=02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
-SHA256 
Fingerprint=68:7F:A4:51:38:22:78:FF:F0:C8:B1:1F:8D:43:D5:76:67:1C:6E:B2:BC:EA:B4:13:FB:83:D9:65:D0:6D:2F:F2
--BEGIN CERTIFICATE-
-MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
-MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
-IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
-MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
-FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
-bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
-dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
-H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
-uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
-mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
-a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
-E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
-WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
-VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
-Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
-cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
-IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
-AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
-YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
-6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
-Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
-c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
-mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
--END CERTIFICATE-
-
 ### AffirmTrust
 
 === /C=US/O=AffirmTrust/CN=AffirmTrust Commercial



Re: Xwindows keymap weirdness

2020-06-01 Thread Stuart Henderson
On 2020/06/01 15:56, Stéphane Aulery wrote:
> Le 01/06/2020 15:46, Matthieu Herrb a écrit :
> > On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote:
> > > Le 01/06/2020 14:55, Matthieu Herrb a écrit :
> > > >
> > > > >
> > > > > (I have just tried with a test user with nothing configured besides
> > > > > LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper
> > > > > characters)
> > > >
> > > > I'm using a real US keyboard with AltGr or the Menu Key (depending on
> > > > the actual keyboard) set as Compose and typing full compose sequences
> > > > to get diacritics. ieand so on.
> > > 
> > > I use a Bépo keyboard but this but
> > > 
> > > Your experience interests me. I use a Bépo keyboard but I plan to
> > > switch to
> > > a QWERTY + compose keyboard like you do. I hope this will give better
> > > compatibility between systems and less software config remapping.
> > > 
> > > I do not see how to configure this in console.
> > 
> > I'm only using this under X. the OpenBSD console is plain ASCII and
> > has no support for for UTF8 characters, so no need to enter them.
> 
> This explains why I cannot enter accented characters through SSH. I can't
> edit a plain UTF-8 file remotely then... when the server has no X server
> running. Doh!

It doesn't matter if the server is running X or not, it is down to the
terminal used on the machine with the SSH client, and the setting for
LC_CTYPE.

By default ssh passes TERM to the server but not LC_CTYPE. You might
find it helpful to set "SendEnv LC_CTYPE" in .ssh/config on the client and
"AcceptEnv LC_CTYPE" in /etc/ssh/sshd_config on the server (some other OS
do this by default).



Re: official ports vs DEBUG_PACKAGES

2020-05-29 Thread Stuart Henderson
On 2020/05/29 17:25, Bob Beck wrote:
> On Fri, May 29, 2020 at 06:14:44PM +0200, Marc Espie wrote:
> > In a trace:
> > 
> > > > > #3  0x15e48c95459e in WebVfx::shutdown ()
> > > > >  at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
> > 
> > Now, this is NOT the default location for WRKOBJDIR, but we are shipping
> > packages with debug information...
> > 
> > This could be a bit cumbersome, if in order to debug locally, you have
> > to make patch NO_DEPENDS=Yes, and then you figure out you have to mimic the
> > "official" setup for ports, which does not even match the default.
> > 
> > There are about 3 solutions to that:
> > - change the bulk machines to /usr/ports/pobj
> > - change the ports default to /usr/obj/ports
> 
> It's not realpathing is it? correct me if I am wrong but would
> making /usr/ports/pobj a symlink to /usr/obj/ports on the bulk 
> machines and running them with the default config just "fix" this? 

It might workaround this but it wouldn't surprise me if it breaks
something else, we have seen weird problems before with ports builds and
paths involving symlinks (iirc python does something strange)

> > - have some magic I don't know in ELF handling that would allow to either
> > tweak the default location/introduce ${WRKOBJDIR} in that debug info.
> > 
> 




Re: official ports vs DEBUG_PACKAGES

2020-05-29 Thread Stuart Henderson
On 2020/05/29 18:14, Marc Espie wrote:
> In a trace:
> 
> > > > #3  0x15e48c95459e in WebVfx::shutdown ()
> > > >  at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
> 
> Now, this is NOT the default location for WRKOBJDIR, but we are shipping
> packages with debug information...
> 
> This could be a bit cumbersome, if in order to debug locally, you have
> to make patch NO_DEPENDS=Yes, and then you figure out you have to mimic the
> "official" setup for ports, which does not even match the default.
> 
> There are about 3 solutions to that:
> - change the bulk machines to /usr/ports/pobj

That often won't match the layout for users either, disklabel auto
defaults push them into using something they've come up with (I have seen
quite a few emails with things like /home/ports or /home/user/ports).

> - change the ports default to /usr/obj/ports
> 
> - have some magic I don't know in ELF handling that would allow to either
> tweak the default location/introduce ${WRKOBJDIR} in that debug info.

Something like /pobj would work for me, it makes sense to mount a
separate filesystem directly there on a dedicated bulk build machine,
for non-dedicated machines it's easier to symlink to the real path than
something a few levels deep.



Re: userland clock_gettime proof of concept

2020-05-29 Thread Stuart Henderson
On 2020/05/29 13:50, Paul Irofti wrote:
> +struct __timekeep {
> + uint32_t major; /* version major number */
> + uint32_t minor; /* version minor number */
> +
> + u_int64_t   th_scale;
> + unsigned intth_offset_count;
> + struct bintime  th_offset;
> + struct bintime  th_naptime;
> + struct bintime  th_boottime;
> + volatile unsigned int   th_generation;
> +
> + unsigned inttc_user;
> + unsigned inttc_counter_mask;
> +};

Ah good, you got rid of u_int, that was causing problems with port builds.



Re: [RFC] pppd: add pipex(4) L2TP control support

2020-05-29 Thread Stuart Henderson
On 2020/05/28 19:42, Jason McIntyre wrote:
> On Wed, May 27, 2020 at 08:43:47AM +0200, Martin Pieuchot wrote:
> > On 26/05/20(Tue) 10:31, Claudio Jeker wrote:
> > > [...] 
> > > npppd(8) is server only it can not establish a connection. pppd(8) on the
> > > other hand is more client side (but I think it can do both).
> > 
> > Could someone knowledgable indicate that in the man pages?
> 
> well, i don;t qualify as knowledgable about ppp, but i'll bite anyway:
> 
> > Currently there is:
> > 
> > npppd ??? new Point-to-Point Protocol daemon
> > pppd ??? Point-to-Point Protocol daemon
> > 
> > Confusing...
> > 
> 
> yes. at the time, i think npppd's description made sense - it was
> a newer version of the ppp server. i think it was pppd that had
> the confusing description, but there was a reason for that too.
> wasn;t there an alternative way to do dialup, and pppd was the
> kernel method?

Here's an overview.

ppp(4), runs PPP in the kernel, controlled by pppd(8). Used for
serial port devices or via a helper application (e.g. xl2tpd in ports
for L2TP client/server - could do PPPoE via a helper too). Client or
server. The version we have is IPv4 only. (Still maintained upstream
but the support for most OS was removed after 2.3.11 in 1999,
it's now Linux/Solaris only).

pppoe(4), runs PPP-over-Ethernet in the kernel using the sppp(4) layer.
Controlled by ifconfig. Client side only. IPv4 and IPv6.

ppp(8), removed in 5.6. Ran PPP in userland and used the tun(4) device
to send packets to/from the kernel. It was used for serial port devices
or PPPoE via a helper (probably also pptp via a helper IIRC). Client
or server. IPv4 and IPv6.

npppd(8), runs L2TP, PPTP, PPPoE. Either userland via tun(4), or hybrid
userland+kernel - userland for connection setup, kernel via pipex(4)
devices handling bulk data transfer after setup. Server side only.
Mostly IPv4 only (L2TP can listen on IPv6 but the PPP sessions
themselves are v4-only).



Re: userland clock_gettime proof of concept

2020-05-28 Thread Stuart Henderson
I'm running it here.

On 2020/05/28 17:44, Paul Irofti wrote:
> diff --git lib/libc/shlib_version lib/libc/shlib_version
> index 06f98b01084..5fb0770494f 100644
> --- lib/libc/shlib_version
> +++ lib/libc/shlib_version
> @@ -1,4 +1,4 @@
>  major=96
> -minor=0
> +minor=1
>  # note: If changes were made to include/thread_private.h or if system calls
>  # were added/changed then librthread/shlib_version must also be updated.

Is the bump actually needed? Symbols.list is untouched so there's no change to
the exported symbols.



Re: Remove useless line from daemon class in login.conf

2020-05-23 Thread Stuart Henderson
On 2020/05/22 16:04, Theo de Raadt wrote:
> Stuart Henderson  wrote:
> 
> > On 2020/05/22 17:06, Daniel Jakots wrote:
> > > Hi,
> > > 
> > > We used to have different numbers of blowfish rounds between the
> > > default and daemon classes in login.conf. On Jun 26, 2016, tedu
> > > committed "upgrade selected login.conf to use auto rounds for bcrypt"
> > > for amd64, sparc64, i386, and maccpc [1].
> > > 
> > > Since the class daemon inherits from the default class, the 
> > > :localcipher=blowfish,a:\
> > > is a duplicate.
> > > 
> > > Here's a diff to remove them.
> > 
> > I'm OK with unifying these settings, but FWIW I never switched to auto
> > for these, it doesn't seem all that sensible for somebody with the ability
> > to generate enough load on the machine to be able to reduce the strength
> > of bcrypt down to the 64 (2^6) rounds minimum.
> 
> Yes, that is problematic.
> 
> The minimum should be probably be raised, we should consider if auto
> should even exist anymore.
> 

As long as it doesn't allow weakening things I think auto should still
exist so that machines can have a stronger bcrypt where it's cheap.

When this was introduced, login.conf for amd64/i386/macppc/sparc64
changed from 8 (normal users) and 9 (daemon class i.e. root) to auto.
Since other, mainly slower, arches stayed with hardcoded 8/9 I don't
think the current minimum reachable in the code makes sense at all.

I've gone to a few machines and done:

- 50 runs of "encrypt -b a" to see what setting was chosen by auto

for i in `jot 50`; do echo foo | encrypt -b a; sleep .1; done | cut -d'$' -f3 | 
sort | uniq -c

- 50 runs of "encrypt -b 9" or "encrypt -b 10" and averaged, to see
how long those two settings take

time for i in `jot 50`; do echo foo | encrypt -b 10; done
(divided by 50)

Chosen  -b 9-b 10
Cortex-A53 1.4GHz (pi3) all 8   0.220.40
GX-412TC 1GHz (APU2)all 8   0.160.31
Cortex-A72 1.5GHz (pi4) all 9   0.070.14
L5520 2.27GHz   all 9   0.080.16
E3-1225v3 3.2GHz12x8 3x9 35x10  0.050.10
E3-1240v5 3.5GHzall 10  0.040.08
E3-1270v6 3.8GHzall 11  0.030.05

I think bumping the minimum to 2^9 would be reasonable, there's a more
noticeable delay on some machines but I think that's fair enough (any
cracking is likely to be done on a fast machine, and the user can force
it lower themselves if they want to take the risk).

With a higher minimum than that the delay starts to get very noticeable
in some cases, so I'm not sure we're ready for that yet.

I think it also makes sense to use blowfish,a in login.conf on all
arches, replacing the old 8/9. Actually -b a is already used in the
installer for both root and the standard user on all archs, whatever
they have in login.conf. Resulting in the situation that on some
archs, the bcrypt created during install for root's password is
weaker than it would be if reset after boot.

So maybe this or something like it?

Index: lib/libc/crypt/bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.57
diff -u -p -r1.57 bcrypt.c
--- lib/libc/crypt/bcrypt.c 26 Aug 2016 08:25:02 -  1.57
+++ lib/libc/crypt/bcrypt.c 23 May 2020 20:16:46 -
@@ -237,14 +237,15 @@ bcrypt_checkpass(const char *pass, const
 DEF_WEAK(bcrypt_checkpass);
 
 /*
- * Measure this system's performance by measuring the time for 8 rounds.
- * We are aiming for something that takes around 0.1s, but not too much over.
+ * Measure this system's performance by measuring the time for 2^9 rounds.
+ * We are aiming for something that takes around 0.1s, not too much over,
+ * but without allowing it to be too weak.
  */
 int
 _bcrypt_autorounds(void)
 {
struct timespec before, after;
-   int r = 8;
+   int r = 9;
char buf[_PASSWORD_LEN];
int duration;
 
@@ -257,12 +258,12 @@ _bcrypt_autorounds(void)
duration += (after.tv_nsec - before.tv_nsec) / 1000;
 
/* too quick? slow it down. */
-   while (r < 16 && duration <= 6) {
+   while (r < 16 && duration <= 75000) {
r += 1;
duration *= 2;
}
/* too slow? speed it up. */
-   while (r > 6 && duration > 12) {
+   while (r > 10 && duration > 12) {
r -= 1;
duration /= 2;
}
Index: etc/etc.alpha/login.conf
===
RCS file: /cvs/src/etc/etc.alpha/login.conf,v
retrieving revision 1.8
diff -u -p -r1.8 login.conf
--- etc/etc.alpha/login.conf5 Nov 2019 19:03:46 - 

Re: Remove useless line from daemon class in login.conf

2020-05-22 Thread Stuart Henderson
On 2020/05/22 17:06, Daniel Jakots wrote:
> Hi,
> 
> We used to have different numbers of blowfish rounds between the
> default and daemon classes in login.conf. On Jun 26, 2016, tedu
> committed "upgrade selected login.conf to use auto rounds for bcrypt"
> for amd64, sparc64, i386, and maccpc [1].
> 
> Since the class daemon inherits from the default class, the 
> :localcipher=blowfish,a:\
> is a duplicate.
> 
> Here's a diff to remove them.

I'm OK with unifying these settings, but FWIW I never switched to auto
for these, it doesn't seem all that sensible for somebody with the ability
to generate enough load on the machine to be able to reduce the strength
of bcrypt down to the 64 (2^6) rounds minimum.



Re: Removing old video drivers

2020-05-19 Thread Stuart Henderson
On 2020/05/19 14:23, Dirk Praet wrote:
> A manual xorg config with the vesa driver brought X back to life, but not
> until I set machdep.allowaperture=2 in /etc/sysctl.conf . Thanks for your
> reply, Matthieu. I do hope 6.7 doesn't come with similar surprises, though 

Run -current between releases if you don't want to see surprises in a release.



Re: Prometheus core metrics for bgpd and ospfd approach ideas

2020-05-18 Thread Stuart Henderson
On 2020/05/18 15:31, Richard Chivers wrote:
> Hi,
> 
> We could do with exposing certain metrics from bgpd, ospfd and pf.
> 
> I was considering a couple of approaches and really was just
> interested in what would make most sense in general.
> 
> Has anyone else considered this at all?
> 
> Would this be useful to anyone else?

It would be useful.

I think the method which fits best with the rest of the system would
be to export these via agentx -> snmpd, where possible using standard
MIBs e.g. for BGP that would be BGP4-MIB/CISCO-BGP4-MIB.

IIRC it has been looked at a bit, but I'm not sure of the current state
of any of it.

Data can be picked up from SNMP directly by some existing tools,
for Prometheus it could be sent via snmp_exporter.



Re: bgpctl paged output for show rib

2020-05-17 Thread Stuart Henderson
On 2020/05/17 12:02, Claudio Jeker wrote:
> On Sun, May 17, 2020 at 11:51:33AM +0200, Denis Fondras wrote:
> > > This implements a way to add a limit for bgpctl show rib output.
> > > When a limit is set then the output will include a token (at the end)
> > > that can be used to get the next batch of output. These two things allow
> > > to build a frontend that puts the output onto multiple pages.
> > > Both regular output and JSON output include the token.
> > >
> > 
> > I am not comfortable with this. It seems out of the scope of bgpctl.
> > I would prefer to keep it simple / follow the unix way, aka pipe the output 
> > to
> > another tool to paginate the output.
> > In your example you use a temp file, why not work on this file to manage the
> > limit / page display ?
> 
> The idea is to use this for looking glass software. Currently bgplg will
> a) load the bgpd excessivly when 'bgpctl show rib' is requested

This is quite a problem if you have public access to bgplg. It does
feel a bit of a non-unixy approach but it's simple and fits nicely with
the existing infrastructure and how it will actually be used (in
particular it doesn't need a persistent connection to bgpd).

I haven't read the diff thoroughly but I agree with the idea.

> b) the output is too long for the user
> c) if used with JSON the array will blow up some systems because there are
> just too many objects in the output.
> 
> This is a place where unix tools don't work well. You also don't want to
> use head and tail to build a poor man paging system since it will not do a
> fast lookup of the offset but instead walk over the table over and over
> again. Also most of this is for a webservice using the JSON export.



Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

2020-05-13 Thread Stuart Henderson
On 2020/05/13 13:46, sven falempin wrote:
> *Please*
> advise how to squeeze more information to thwart that problem.

If I had a card using a newly developed driver that was doing that,
I would remove the card, offer to send it to somebody working on the
driver if they want it, and replace it with an alternative..



Re: userland clock_gettime proof of concept

2020-05-13 Thread Stuart Henderson
Thanks for looking at this Paul!

On 2020/05/13 17:15, Robert Nagy wrote:
> On 13/05/20 17:05 +0200, Mark Kettenis wrote:
> > > The update currently does the work of clock_gettime(), but it can
> > > probably be changed to only update the timehands and move the logic
> > > elsewhere. Note that if we expose only the timehands to userland, most
> > > of the bintime functionality has to also be made available there. Or so
> > > I think.
> > 
> > Unfortunately what you're doing here isn't good enough.  You're only
> > exporting low-resolution versions of the clocks.  The equivalent of
> > what Linux class CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE.
> > And I'm fairly certain that isn't what the applications want.  Why
> > else would they be calling clock_gettime() a gazillion times per
> > second...
> 
> 
> Most of the big programs use CLOCK_MONOTONIC.
> 

Agreed.

Quick counts from a dumb search with codesearch.debian:

CLOCK_REALTIME_COARSE   376
CLOCK_MONOTONIC_COARSE  639
CLOCK_REALTIME  8756
CLOCK_MONOTONIC 10776

I have looked over ports source and almost everything I see prefers
CLOCK_MONOTONIC if available then falls back to CLOCK_REALTIME.
Occasionally you have things using only CLOCK_REALTIME but not many.
So I think it's fair to say most of the latter two are overlapping
cases.

In linux the vdso handles CLOCK_{REALTIME,MONOTONIC}{,_COARSE}.
Depending on the clock source it may still use syscalls though, people
got bitten by this on ec2 where some machine types default to a source
that still needed syscalls.



Re: nsd 4.3.1

2020-05-08 Thread Stuart Henderson
On 2020/05/08 06:58, Florian Obser wrote:
> I'm running this for about 2 weeks or so.
> Tests, OKs?

Just off to look at a radio link in a church tower that I suspect a pigeon
may have knocked out of alignment, I'll put this on some machines when I get
back, just wanted to comment:

> - I'm adding RELNOTES, it helps my process of merging upstream
> - I forgot to update ChangeLog previously, so there are unrelated
> changes in there as well. I'll first bring in the ChangeLog and
> RELNOTES changes up to 4.2.4 and then update to 4.3.1 on top.

Yes please, I found this very helpful when doing Unbound updates.

I wonder if testers will notice what's different about responses (I think
it's a good thing).



Re: JSON support for bgpctl(8)

2020-05-07 Thread Stuart Henderson
On 2020/05/07 17:02, Richard Chivers wrote:
> Hi,
> 
> Great to hear about the json support for bgpctl.
> 
> Will bgpctl latest work with 6.6 bgpd, so we can compile a bgpctl_latest
> with the json support for testing, without upgrading the rest of bgpd on
> our boxes?

It definitely won't, but if it helps, you should have no problems building
-current bgpd+bgpctl, or ospfd/ospf6d for that matter, on a 6.6 system.
(That isn't always the case - for example you wouldn't be able to do
that with iked at the moment).



Re: [PATCH] add ping(1)-like stats to tcpbench(1)

2020-05-03 Thread Stuart Henderson
On 2020/05/04 09:23, Richard Procter wrote:
> I like it. 
> 
> Assuming a mention in tcpbench.1 - ok procter

ok like this?  text stolen from ping.

Index: tcpbench.1
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.1,v
retrieving revision 1.27
diff -u -p -r1.27 tcpbench.1
--- tcpbench.1  2 May 2020 22:00:29 -   1.27
+++ tcpbench.1  3 May 2020 21:29:22 -
@@ -82,6 +82,15 @@ Its accuracy may be increased by decreas
 .Ar interval .
 The summary bytes and duration cover the interval from transfer start
 to process exit.
+The summary information can also be displayed while
+.Nm
+is running by sending it a
+.Dv SIGINFO
+signal (see the
+.Cm status
+argument of
+.Xr stty 1
+for more information).
 .Pp
 The options are as follows:
 .Bl -tag -width Ds
Index: tcpbench.c
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
retrieving revision 1.62
diff -u -p -r1.62 tcpbench.c
--- tcpbench.c  2 May 2020 22:00:29 -   1.62
+++ tcpbench.c  3 May 2020 21:29:22 -
@@ -213,6 +213,10 @@ signal_handler(int sig, short event, voi
 * signal handler rules don't apply, libevent decouples for us
 */
switch (sig) {
+   case SIGINFO:
+   printf("\n");
+   wrapup(-1);
+   break;
case SIGINT:
printf("\n");
wrapup(0);
@@ -1109,7 +1113,8 @@ wrapup(int err)
summary_display();
}
 
-   exit(err);
+   if (err != -1)
+   exit(err);
 }
 
 int
@@ -1126,7 +1131,7 @@ main(int argc, char **argv)
int family = PF_UNSPEC;
struct nlist nl[] = { { "_tcbtable" }, { "" } };
const char *host = NULL, *port = DEFAULT_PORT, *srcbind = NULL;
-   struct event ev_sigint, ev_sigterm, ev_sighup, ev_progtimer;
+   struct event ev_sigint, ev_sigterm, ev_sighup, ev_siginfo, ev_progtimer;
struct sockaddr_un sock_un;
 
/* Init world */
@@ -1362,9 +1367,11 @@ main(int argc, char **argv)
signal_set(_sigterm, SIGTERM, signal_handler, NULL);
signal_set(_sighup, SIGHUP, signal_handler, NULL);
signal_set(_sigint, SIGINT, signal_handler, NULL);
+   signal_set(_siginfo, SIGINFO, signal_handler, NULL);
signal_add(_sigint, NULL);
signal_add(_sigterm, NULL);
signal_add(_sighup, NULL);
+   signal_add(_siginfo, NULL);
signal(SIGPIPE, SIG_IGN);
 
if (UDP_MODE) {



Re: [PATCH] add ping(1)-like stats to tcpbench(1)

2020-05-03 Thread Stuart Henderson
Is it worth triggering this on SIGINFO? I use that often with ping(1).

Index: tcpbench.c
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
retrieving revision 1.62
diff -u -p -r1.62 tcpbench.c
--- tcpbench.c  2 May 2020 22:00:29 -   1.62
+++ tcpbench.c  3 May 2020 16:24:05 -
@@ -213,6 +213,10 @@ signal_handler(int sig, short event, voi
 * signal handler rules don't apply, libevent decouples for us
 */
switch (sig) {
+   case SIGINFO:
+   printf("\n");
+   wrapup(-1);
+   break;
case SIGINT:
printf("\n");
wrapup(0);
@@ -1109,7 +1113,8 @@ wrapup(int err)
summary_display();
}
 
-   exit(err);
+   if (err != -1)
+   exit(err);
 }
 
 int
@@ -1126,7 +1131,7 @@ main(int argc, char **argv)
int family = PF_UNSPEC;
struct nlist nl[] = { { "_tcbtable" }, { "" } };
const char *host = NULL, *port = DEFAULT_PORT, *srcbind = NULL;
-   struct event ev_sigint, ev_sigterm, ev_sighup, ev_progtimer;
+   struct event ev_sigint, ev_sigterm, ev_sighup, ev_siginfo, ev_progtimer;
struct sockaddr_un sock_un;
 
/* Init world */
@@ -1362,9 +1367,11 @@ main(int argc, char **argv)
signal_set(_sigterm, SIGTERM, signal_handler, NULL);
signal_set(_sighup, SIGHUP, signal_handler, NULL);
signal_set(_sigint, SIGINT, signal_handler, NULL);
+   signal_set(_siginfo, SIGINFO, signal_handler, NULL);
signal_add(_sigint, NULL);
signal_add(_sigterm, NULL);
signal_add(_sighup, NULL);
+   signal_add(_siginfo, NULL);
signal(SIGPIPE, SIG_IGN);
 
if (UDP_MODE) {



Re: Tighter pledges for ftp(1)

2020-05-03 Thread Stuart Henderson
On 2020/05/02 20:19, Demi M. Obenour wrote:
> The following patch tightens the pledges for ftp(1).
> 
> This guarantees that ftp(1) cannot spawn child processes when operating
> in batch mode, which is a significant security win.

It breaks interactive mode (!ls, more somefile, get somefile "|rot13"),
something is wrong with how you decide that exec is needed.

Also it complicates the code for the SMALL version used on the ramdisk
(and maybe makes the pledge weaker too, the code is no longer easy to
follow so I didn't work out for sure).

Note the commit log when pledge was added:

-
Date: 2017/01/10 17:43:12
Author: deraadt
Branch: HEAD
Tag: (none)
Log:
Pledge more strictly.  This is only enabled on the ramdisk version of the
ftp(1) client, which operates only in URL mode.  Not willing to spend the
time tracking piles of global variables for sub-modes, and finding all
the pledge interactions.  Would rather have the install media ftp(1) as
safe as possible, immediately.
ok tb jca

Members:
fetch.c:1.156->1.157
-

..that isn't to say that it can't be improved, but it does need care as
ftp(1) is quite complicated.



Re: ospf6d ls_update segv

2020-05-02 Thread Stuart Henderson
On 2020/05/02 16:48, Stuart Henderson wrote:
> Seeing some of these, including in brand new -current. I think it's triggered
> when another ospf6-speaker in the area restarts.
> 
> ospf6d[1296]: route decision engine exiting
> ospf6d[214]: kernel routing table decoupled
> ospf6d[214]: ospf engine terminated; signal 11
> ospf6d[214]: terminating
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  add_ls_update (buf=, iface=0xdada9dbfc00, 
> data=0xdada9dbd1c0, len=, 
> older=) at /usr/src/usr.sbin/ospf6d/lsupdate.c:211
> 211 memcpy(lsage, , sizeof(age));
> (gdb) bt
> #0  add_ls_update (buf=, iface=0xdada9dbfc00, 
> data=0xdada9dbd1c0, len=, 
> older=) at /usr/src/usr.sbin/ospf6d/lsupdate.c:211
> #1  ls_retrans_timer (fd=, event=, 
> bula=)
> at /usr/src/usr.sbin/ospf6d/lsupdate.c:493
> #2  0x0dadf8147fbf in event_process_active (base=) at 
> /usr/src/lib/libevent/event.c:333
> #3  event_base_loop (base=0xdada9dc3800, flags=0) at 
> /usr/src/lib/libevent/event.c:483
> #4  0x0dab3c11bf75 in ospfe (xconf=0xdada9db9f00, 
> pipe_parent2ospfe=0xdab3c132230 , 
> pipe_ospfe2rde=0xdab3c132228 , 
> pipe_parent2rde=0xdab3c132238 )
> at /usr/src/usr.sbin/ospf6d/ospfe.c:187
> #5  0x0dab3c11a34d in main (argc=0, argv=0x7f7be018) at 
> /usr/src/usr.sbin/ospf6d/ospf6d.c:234
> 
> Any ideas?
> 
> 

I should add: also seen on one running a snap from Feb 20th so it's not 
super-new.



ospf6d ls_update segv

2020-05-02 Thread Stuart Henderson
Seeing some of these, including in brand new -current. I think it's triggered
when another ospf6-speaker in the area restarts.

ospf6d[1296]: route decision engine exiting
ospf6d[214]: kernel routing table decoupled
ospf6d[214]: ospf engine terminated; signal 11
ospf6d[214]: terminating

Program terminated with signal SIGSEGV, Segmentation fault.
#0  add_ls_update (buf=, iface=0xdada9dbfc00, 
data=0xdada9dbd1c0, len=, 
older=) at /usr/src/usr.sbin/ospf6d/lsupdate.c:211
211 memcpy(lsage, , sizeof(age));
(gdb) bt
#0  add_ls_update (buf=, iface=0xdada9dbfc00, 
data=0xdada9dbd1c0, len=, 
older=) at /usr/src/usr.sbin/ospf6d/lsupdate.c:211
#1  ls_retrans_timer (fd=, event=, 
bula=)
at /usr/src/usr.sbin/ospf6d/lsupdate.c:493
#2  0x0dadf8147fbf in event_process_active (base=) at 
/usr/src/lib/libevent/event.c:333
#3  event_base_loop (base=0xdada9dc3800, flags=0) at 
/usr/src/lib/libevent/event.c:483
#4  0x0dab3c11bf75 in ospfe (xconf=0xdada9db9f00, 
pipe_parent2ospfe=0xdab3c132230 , 
pipe_ospfe2rde=0xdab3c132228 , 
pipe_parent2rde=0xdab3c132238 )
at /usr/src/usr.sbin/ospf6d/ospfe.c:187
#5  0x0dab3c11a34d in main (argc=0, argv=0x7f7be018) at 
/usr/src/usr.sbin/ospf6d/ospf6d.c:234

Any ideas?




Re: acpipci(4); derive bus number from _CRS

2020-05-02 Thread Stuart Henderson
On 2020/05/02 14:29, Mark Kettenis wrote:
> I've always interpreted the bit of code that takes the bus number from
> _CRS instead of _BBN, ut allegedly this is not how it works and _BBN
> is supposedly only there to make sure we can access PCI config space
> of the host bridge from AML code.
> 
> Fortunately having _CRS provide the bus number is just a one-line
> diff.  This might fix PCIe on the Honeycomb LX2K which is a 16-core
> "workstation" mini-ITX board based on NXP's LX2160A board made bu
> SolidRun.  I'd like to have this in 6.7.  Tested on the Ampere machine
> and the od1000 in ACPI mode.
> 
> ok?

RPi4 in ACPI mode is still happy.

OK

> 
> Index: arch/arm64/dev/acpipci.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/dev/acpipci.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 acpipci.c
> --- arch/arm64/dev/acpipci.c  22 Aug 2019 17:14:21 -  1.13
> +++ arch/arm64/dev/acpipci.c  2 May 2020 12:21:24 -
> @@ -268,6 +268,10 @@ acpipci_parse_resources(int crsidx, unio
>   break;
>   case LR_TYPE_BUS:
>   extent_free(sc->sc_busex, min, len, EX_WAITOK);
> + /*
> +  * Let _CRS minimum bus number override _BBN.
> +  */
> + sc->sc_bus = min;
>   break;
>   }
>  
> 



Re: iked(8): Removing SHA1 from default transforms

2020-05-01 Thread Stuart Henderson
On 2020/05/02 00:43, Stephan Mending wrote:
> On 02/05/2020 00:40, Stuart Henderson wrote:
> > On 2020/05/02 00:23, Stephan Mending wrote:
> > > Hi,
> > > 
> > > I actually read your thread. By what I understood you're at the moment
> > > trying to change a few defaults.
> > > 
> > > That was the reason I wanted to add SHA1 for removal. I just thought it
> > > deserved a seperate thread.
> > > 
> > > I do understand that you're trying to be careful with removing or changing
> > > defaults. From my point of view everybody that is (maybe implicitly) using
> > > SHA1 right now is better off to be get this wakeup call the earlier the
> > > better.
> > > 
> > > We aren't even removing SHA1 we're just not offering it as default. And 
> > > for
> > > those Windows boxes who require it, those people just have to add a line 
> > > to
> > > explicitly enable it. I would not see such big of a problem.
> > The things removed recently have a very low risk of affecting anyone.
> > sha1 (and modp1024) are high risk.
> > 
> > Removing from the default list may cause some people to be unable
> > to connect to their network after updating. This may mean that they
> > are then unable to connect back in to fix it.
> > 
> > If this change is made it needs to be done fairly early in the release
> > cycle, and preferably at a time when slightly fewer people are relying
> > on working remote access to get at their networks.
> > 
> 
> I dont't have much experience with such a big projekt like OpenBSD. How do
> you normally carry through with such significant changes ? Just the release
> notes and hoping somebody in snaps will complain ? Or is there more to it,
> which I didn't notice ?
> 

Testing where we can, but allowing for the fact that we can't test
everything riskier changes need to be done at a point where we have a
good chance to get feedback from -current users so we can come up with
good advice for release notes.



Re: iked(8): Removing SHA1 from default transforms

2020-05-01 Thread Stuart Henderson
On 2020/05/02 00:23, Stephan Mending wrote:
> Hi,
> 
> I actually read your thread. By what I understood you're at the moment
> trying to change a few defaults.
> 
> That was the reason I wanted to add SHA1 for removal. I just thought it
> deserved a seperate thread.
> 
> I do understand that you're trying to be careful with removing or changing
> defaults. From my point of view everybody that is (maybe implicitly) using
> SHA1 right now is better off to be get this wakeup call the earlier the
> better.
> 
> We aren't even removing SHA1 we're just not offering it as default. And for
> those Windows boxes who require it, those people just have to add a line to
> explicitly enable it. I would not see such big of a problem.

The things removed recently have a very low risk of affecting anyone.
sha1 (and modp1024) are high risk.

Removing from the default list may cause some people to be unable
to connect to their network after updating. This may mean that they
are then unable to connect back in to fix it.

If this change is made it needs to be done fairly early in the release
cycle, and preferably at a time when slightly fewer people are relying
on working remote access to get at their networks.



Re: IPv6 Support for umb(4)

2020-05-01 Thread Stuart Henderson
On 2020/05/01 20:10, Gerhard Roth wrote:
> On 4/30/20 11:07 PM, Stuart Henderson wrote:
> > On 2020/04/30 20:32, Gerhard Roth wrote:
> > > Hi Theo,
> > > 
> > > is umb really working that differently for a P2P interface? I think it is
> > > very similar to ppp(4) and IPv6. The standard way is to obtain the IP
> > > address via PPP protocol. Just like this, umb(4) obtains the IP address 
> > > via
> > > MBIM protocol.
> > 
> > PPP is quite different, it only negotiates a link-local v6 address. If you
> > want a routable address you must use slaac, dhcpv6, or static config.
> > 
> > > That's what is implemented with this and former umb(4) patches. With the
> > > current patch you can just do "ifconfig umb0 inet eui64" or "ifconfig umb0
> > > -inet6" anytime, whether the interface is up or not.
> > > 
> > > But then there seem to be strange ISPs in Japan as detected by job@. They
> > > don't provide any IPv6 address via MBIM protocol but rather use the 
> > > standard
> > > IPv6 SLAAC protocol. It strange; just as if ppp(4) would need DHCP to 
> > > obtain
> > > its IPv4 address. But still, it seems to exist and users can still work 
> > > with
> > > umb(4) if they do "ifconfig umb0 inet6 autoconf".
> > 
> > What happens if an ISP provides a v6 address via MBIM-config and the 
> > interface
> > is set to "inet6 autoconf", does it still work OK? That's what most people
> > will try. Since we disabled IPv6 by default, IPv6 users already know how to
> > use "inet6 autoconf".
> 
> I just can't tell. All providers here in Germany will give me an IPv6
> address via MBIM. There's no way I could test this case. Especially not in
> times of Corona.

That's exactly the case I mean. What happens if you are on a network like
that which gives a v6 address via MBIM and you also set "inet6 autoconf" -
does that work ok?

If that works then we can just tell people to use autoconf, it won't be
necessary but will work for your standard case, will work for the ISP that
Job found, and matches what people would normally do anyway.



Re: Audio over hdmi

2020-05-01 Thread Stuart Henderson
On 2020/05/01 17:16, Damien Couderc wrote:
> Le 01/05/2020 à 15:01, Mark Kettenis a écrit :
> > > Date: Fri, 1 May 2020 14:17:56 +0200
> > > From: Alexandre Ratchov 
> > > 
> > > On Fri, May 01, 2020 at 01:11:16PM +0200, Damien Couderc wrote:
> > > > 
> > > > Speaking of the hdmi-only devices that were disabled in 2009: does the
> > > > project still stand on this position in 2020? I made a quick search and 
> > > > it
> > > > seems that more than half of the screens are audio capable now. I 
> > > > understand
> > > > the defaults back in 2009, but now is it still true?
> > > 
> > > There's nothing wrong with hdmi-only devices. As long as audio works
> > > by default with no tweaks, nobody will object to re-enabling
> > > them. AFAIK, this was the only reason to disable them.
> > 
> > Right.  The main issue was that by default we only send output to
> > audio0.  On many machines the audio device associated with the HDMI
> > port appears before the audio device that is associated with the
> > speakers and/or headphone jack on our laptops.  Therefore by default
> > audio would go to an unconnected HDMI.  Just enabling digital-only
> > devices would not work.
> > 
> > There are a couple things we could do here.
> > 
> > 1. Make sndiod(8) responsible for picking a default output device.
> 
> I thought it was the case with the -f and -F options:
> 
>  -F device
>  Specify an alternate device to use.  If it doesn't work, the
> one
>  given with the last -f or -F options will be used.  For
> instance,
>  specifying a USB device following a PCI device allows sndiod to
>  use the USB one preferably when it's connected and to fall back
>  to the PCI one when it's disconnected.
> 
>  -f device
>  Add this sndio(7) audio device to devices used for playing
> and/or
>  recording.  Preceding per-device options (-aberwz) apply to
> this
>  device.  Sub-devices (-s) that are applied after will be
> attached
>  to this device.  Device mode and parameters are determined from
>  sub-devices attached to it.
> 
> So if I'm not wrong it could be possible to set the -f option with the
> analog device and the -F option with the digital-only one.

These flags are to cope with a new audio device connected at runtime,
for example so you can set it to use audio1 if the device is available,
otherwise use audio0.

The problem with HDMI audio is that the device *is* available but the
output often doesn't go anywhere. This mechanism doesn't help that case.



Re: IPv6 Support for umb(4)

2020-04-30 Thread Stuart Henderson
On 2020/04/30 22:28, Jason McIntyre wrote:
> On Thu, Apr 30, 2020 at 10:07:14PM +0100, Stuart Henderson wrote:
> > 
> > On 2020/04/30 20:52, Gerhard Roth wrote:
> > > It it too much to expect users to read the ifconfig man page?
> > 
> > Printed, it is 28 pages of A4.
> > 
> 
> ouch.

admittedly one of them just has 'HISTORY' on which is 1 line, but still ;)

The formatting (I am using "MANPAGER=mupdf man -T pdf ifconfig") to see
this is lovely though!



Re: iked(8): Add ECDH groups and AEADs to defaults

2020-04-30 Thread Stuart Henderson
On 2020/04/30 23:03, Tobias Heider wrote:
> On Thu, Apr 30, 2020 at 09:33:28PM +0100, Stuart Henderson wrote:
> > On 2020/04/30 20:11, Tobias Heider wrote:
> > > Hi,
> > > 
> > > I would like to modernize our crypto defaults a bit and add some of the
> > > supported ECDH Diffie-Hellman groups to the default IKE crypto proposal.
> > > There should be no downside to this, if they are not supported by the
> > > other side one of the old MODP groups will be used.
> > > 
> > > The same for AEADs in the ESP proposal.  We have support for AES-GCM
> > > and CHACHA20 for some time now but they never made it into the
> > > defaults.
> > > 
> > > ok?
> > 
> > ok to add them.
> 
> On second thought i would actually only add the ECDH groups for now.
> For AEADs we would probably need a bit more boilerplate because they would
> have to be sent in a second proposal without the AUTH transforms and
> that can wait until after the release.

oh yes..

> > 
> > I'm really tempted to suggest dropping the worst of the rest from default
> > transforms, users can still re-add them if needed. Not sure if that's a now
> > thing or a post unlock thing though.
> > 
> > I was going to experiment some more (in particular to see what Windows
> > comes up with by default nowadays) but the only box I'm running iked on
> > that isn't going to interrupt other VPN users, is also running bgpd and
> > I just discovered the hard way that starting iked clears out existing
> > tcpmd5 SAs so I'm not going to touch that right now ;)
> > 
> 
> According to the strongswan website [1] the Windows defaults should be:
> 
> 128-CBC, AES-192-CBC, AES-256-CBC, 3DES, SHA-1,SHA-256, SHA-384 and MODP-1024.
> 
> If this is true we could actually drop 3DES and HMAC-SHA1-96, which would be
> great.  MODP-1024 as the only Diffie-Hellman group however is already the
> weakest group we offer (and if not for windows I would gladly drop it as 
> well).
> 
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients

I'll check it with a newly setup phonebook entry on a Windows box tomorrow
to make sure. I also want to have another look at rekeying as I had some
problems reported with that (the strongswan page talks about problems
with W7 but I think we had some problems with W10 as well).



Re: IPv6 Support for umb(4)

2020-04-30 Thread Stuart Henderson
On 2020/04/30 20:32, Gerhard Roth wrote:
> Hi Theo,
> 
> is umb really working that differently for a P2P interface? I think it is
> very similar to ppp(4) and IPv6. The standard way is to obtain the IP
> address via PPP protocol. Just like this, umb(4) obtains the IP address via
> MBIM protocol.

PPP is quite different, it only negotiates a link-local v6 address. If you
want a routable address you must use slaac, dhcpv6, or static config.

> That's what is implemented with this and former umb(4) patches. With the
> current patch you can just do "ifconfig umb0 inet eui64" or "ifconfig umb0
> -inet6" anytime, whether the interface is up or not.
> 
> But then there seem to be strange ISPs in Japan as detected by job@. They
> don't provide any IPv6 address via MBIM protocol but rather use the standard
> IPv6 SLAAC protocol. It strange; just as if ppp(4) would need DHCP to obtain
> its IPv4 address. But still, it seems to exist and users can still work with
> umb(4) if they do "ifconfig umb0 inet6 autoconf".

What happens if an ISP provides a v6 address via MBIM-config and the interface
is set to "inet6 autoconf", does it still work OK? That's what most people
will try. Since we disabled IPv6 by default, IPv6 users already know how to
use "inet6 autoconf".

> > I also feel noone is going to read the manual page, find this piece
> > of text, and understand it.  Honestly, I don't understand this piece
> > of text.  I'm not going to set the AUTOCONF6 flag.  How does one even
> > set it?
> > 
> > ifconfig: AUTOCONF6: bad value
> > 
> > Of course not, but I am ironically trying to show this documentation
> > chunk doesn't help at all.  People can't act upon it properly.
> > 
> > I still argue umb's inet6 should work absolutely as much like regular
> > interfaces, or it is useless.  People are not going to treat this
> > interface differently and then gain successful inet6.  If inet6 can't
> > work naturally and easily, but instead is a special snowflake, that
> > is just plain dumb.

Unfortunately mobile data is a special snowflake because you get some
providers who say "to conserve licenses with the network vendor you can
have either an IPv4 address or an IPv6 address but not both at the same
time" so you need a way to do something which isn't required on normal
ethernet.

> > > > +.Pp
> > > > +To use IPv6, configure a link-local address.
> > > > +If the device is able to connect to the ISP's network but doesn't
> > > > +show an IPv6 address, setting the
> > > > +.Sy AUTOCONF6
> > > > +flag on the interface before bringing it up may help.
> > > > +.Ed

Showing the actual command to type will help a lot here.

On 2020/04/30 20:52, Gerhard Roth wrote:
> It it too much to expect users to read the ifconfig man page?

Printed, it is 28 pages of A4.

Compare with the wifi drivers, you have to look at ifconfig(8) if
you want all the details, but EXAMPLES in iwm(4) (and I think all the other
drivers) is enough for a quick bare-bones config. That seems a reasonable
model.



Re: iked(8): Add ECDH groups and AEADs to defaults

2020-04-30 Thread Stuart Henderson
On 2020/04/30 20:11, Tobias Heider wrote:
> Hi,
> 
> I would like to modernize our crypto defaults a bit and add some of the
> supported ECDH Diffie-Hellman groups to the default IKE crypto proposal.
> There should be no downside to this, if they are not supported by the
> other side one of the old MODP groups will be used.
> 
> The same for AEADs in the ESP proposal.  We have support for AES-GCM
> and CHACHA20 for some time now but they never made it into the
> defaults.
> 
> ok?

ok to add them.

I'm really tempted to suggest dropping the worst of the rest from default
transforms, users can still re-add them if needed. Not sure if that's a now
thing or a post unlock thing though.

I was going to experiment some more (in particular to see what Windows
comes up with by default nowadays) but the only box I'm running iked on
that isn't going to interrupt other VPN users, is also running bgpd and
I just discovered the hard way that starting iked clears out existing
tcpmd5 SAs so I'm not going to touch that right now ;)



Re: [PATCH] sysupgrade

2020-04-30 Thread Stuart Henderson
On 2020/04/30 10:07, Anders Andersson wrote:
> I recently bought an APU with the smallest disk I could find (16 GB
> mSATA), I don't remember the full install of all sets taking more than
> 10%. No need to remove stuff.

With current auto layouts from the installer it's usually ok, but with
ones from a couple of releases ago it's very much not. It's also tricky to
fit everything if you're using a system from a few years ago with say a
1-2GB CF.

> I don't really see why a system-wide tool should have several options
> for hardcoded subsets of some of the possible ways to create a
> non-standard installation, especially when using these options will
> break an otherwise working setup. IF there is such an option, surely
> it should take a list of sets that you have installed?

The only way I see this making sense is if it detects which sets are
installed. But the impression I got was that this was unwanted for sysupgrade
(so I use my own script). FWIW in case it helps anyone writing their own,
I use these for detection.

[ -r /usr/share/man/man1/dd.1 ] && _SETS="${_SETS}man,"
[ -r /usr/X11R6/bin/xterm ] && _SETS="${_SETS}xbase,"
[ -r /usr/lib/libc.a ] && _SETS="${_SETS}comp,"
[ -r /usr/X11R6/include/X11/X.h ] && _SETS="${_SETS}xshare,"
[ -r /usr/X11R6/bin/X ] && _SETS="${_SETS}xserv,"
[ -d /usr/X11R6/lib/X11/fonts/misc ] && _SETS="${_SETS}xfont,"
[ -r /usr/games/rain ] && _SETS="${_SETS}game,"



release(8) - mention u-boot-*, dtb, raspberrypi-firmware

2020-04-29 Thread Stuart Henderson
OK to add this?

Index: release.8
===
RCS file: /cvs/src/share/man/man8/release.8,v
retrieving revision 1.94
diff -u -p -r1.94 release.8
--- release.8   23 Jun 2018 23:19:11 -  1.94
+++ release.8   29 Apr 2020 13:44:19 -
@@ -157,6 +157,13 @@ The base system release consists of at l
 some installation media, the release tarballs,
 installation instructions, and checksum files.
 .Pp
+On arm64 and armv7 architectures, additional files are required.
+For armv7, install u-boot-arm and dtb using
+.Xr pkg_add 1
+or from
+.Xr ports 7 .
+For arm64, install raspberrypi-firmware and u-boot-aarch64.
+.Pp
 Create a
 .Va RELEASEDIR
 directory to store the release files.



Re: Install: Invalid group _sndiop in #163 amd64

2020-04-29 Thread Stuart Henderson
On 2020/04/29 11:58, Oliver Marugg wrote:
> Yes, I made the mistake using this older snap for install (was on my usb
> stick) with consequences.
> With a today downloaded install.fs to USB Stick and http install no problem
> as you, Otto and Stuart mentioned. thx.
> Sorry, I really should know using latest -current only, but I learnt not
> using an older install.fs to install. Sorry for the noise.

btw, since you are fetching new files from the net anyway, you can save
time by just using miniroot67.fs instead of install67.fs

install67 includes all the sets, which is useful if you're installing on
a machine that doesn't have net unless you have wifi firmware, or need
to install offline, but otherwise it's usually quicker to just dd the
miniroot instead and avoid the extra stage.



Re: Install: Invalid group _sndiop in #163 amd64

2020-04-29 Thread Stuart Henderson
On 2020/04/29 10:28, Oliver Marugg wrote:
> Possible typo group _sniop shoud be _sndiod:
> 
> During fresh install from install.fs amd64 of OpenBSD 6.7-beta (GENERIC.MP)
> #163: Tue Apr 28 21:35:13 MDT 2020

You are showing the version of the installed GENERIC.MP kernel not the
install image.

I think you are using an old install67.fs.

> ...
> Making all device nodes...chgrp: group is invalid: _sndiop
> chgrp: group is invalid: _sndiop
>  done.
> 
> Multiprocessor machine; using bsd.mp instead of bsd.
> ...
> 
> -oliver
> 



Re: iked(8): remove insecure EC2N curves

2020-04-28 Thread Stuart Henderson
...after some more research:

ec2n never actually made it into the IKEv2 RFC, it was present in drafts
up to 15, but removed in

https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-ipsec-ikev2-16.txt

the relevant entry from https://datatracker.ietf.org/doc/rfc4306/history/ is

: 2004-09-02   17   Russ Housley[Ballot discuss]
: 
: In 2002, the working group decided not to pursue elliptic curves.
: Hilarie Orman made several presentation advocating them; her slides
: are in the minutes.  However, the IPR concerns associate with
: elliptic curves lead the working group to classic Diffie-Hellman.
: Yet, two elliptic curve groups are still included in the document.
: This seems to contradict the working group decision.  I suggest the
: removal of the elliptic curve groups from Appendix B.

A quick search doesn't find any implementations supporting ec2n other
than iked and CLJ^H^H^H routeros. OK I have changed my mind and agree
with you Tobias, I am happy to kill it now.



On 2020/04/28 08:59, Theo de Raadt wrote:
> If so, immediately.  That means for about 2 weeks someone in snaps
> can scream.
> 
> Tobias Heider  wrote:
> 
> > On Tue, Apr 28, 2020 at 11:22:02AM +0100, Stuart Henderson wrote:
> > > On 2020/04/28 01:09, Tobias Heider wrote:
> > > > Hi,
> > > > 
> > > > the EC2N family of curves have been marked as insecure for at least 10 
> > > > years.
> > > > In fact, IANA has stopped listing them altogether [1].
> > > > Their former IDs are now 'reserved'.
> > > > 
> > > > I think it's time for us to drop them as well.
> > > > 
> > > > ok?
> > > 
> > > I agree with dropping them. Timing-wise perhaps it's better to do it
> > > after release (possible text for upgrade notes below); OTOH probably
> > > nobody really uses ec2n so it's not all that likely to hurt users (we
> > > can use similar text but say "prior to upgrade, add alternative groups
> > > [...]" instead).
> > > 
> > >   "The insecure ec2n D-H groups will be removed from iked in the next
> > >   release; if you are using these, add alternative groups to ikesa/childsa
> > >   in iked.conf, then you can move clients across one by one and remove
> > >   the ec2n groups in advance of 6.8.
> > > 
> > >   While removal of other groups is not imminent, some are considered
> > >   insecure (768-bit MODP, group 1) or weak (1024- and 1536-bit MODP,
> > >   groups 2 and 5). Prefer curve25519, an ECP group of 256 bits or
> > >   more, or a MODP group of 2048 bits or more."
> > 
> > I would really rather do it now.  It has been marked as insecure for long
> > enough and really no one should be using it.
> > IMHO shipping them for another six months would be rather irresponsible
> > from our side.
> > 
> > The upgrade note sound good.
> > 
> > > 
> > > > Index: iked.conf.5
> > > > ===
> > > > RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> > > > retrieving revision 1.66
> > > > diff -u -p -r1.66 iked.conf.5
> > > > --- iked.conf.5 27 Apr 2020 22:40:09 -  1.66
> > > > +++ iked.conf.5 27 Apr 2020 22:58:24 -
> > > > @@ -909,8 +909,6 @@ keyword:
> > > >  .It Em Name Ta Em Group Ta Em Size Ta Em Type
> > > >  .It Li modp768 Ta grp1 Ta 768 Ta "MODP"
> > > >  .It Li modp1024 Ta grp2 Ta 1024 Ta "MODP"
> > > 
> > >.It Li modp768 Ta grp1 Ta 768 Ta "MODP" [insecure]
> > >.It Li modp1024 Ta grp2 Ta 1024 Ta "MODP" [weak]
> > > 
> > > > -.It Li ec2n155 Ta grp3 Ta 155 Ta "EC2N [insecure]"
> > > > -.It Li ec2n185 Ta grp4 Ta 185 Ta "EC2N [insecure]"
> > > >  .It Li modp1536 Ta grp5 Ta 1536 Ta "MODP"
> > > 
> > >.It Li modp1536 Ta grp5 Ta 1536 Ta "MODP" [weak]
> > > 
> > > I guess we should sprinkle some other weak/insecure in the manual
> > > too but this is a start.
> > 
> > Good idea, your classification makes sense.  We should do the same for
> > all algorithms.
> > 
> > > 
> > > >  .It Li modp2048 Ta grp14 Ta 2048 Ta "MODP"
> > > >  .It Li modp3072 Ta grp15 Ta 3072 Ta "MODP"
> > > > @@ -931,11 +929,8 @@ keyword:
> > > >  .Pp
> > > >  The currently supported group types are either
> > > >  MODP (exponentiation groups modulo a prime),
> > > > -EC2N (

Re: iked(8): remove insecure EC2N curves

2020-04-28 Thread Stuart Henderson
On 2020/04/28 01:09, Tobias Heider wrote:
> Hi,
> 
> the EC2N family of curves have been marked as insecure for at least 10 years.
> In fact, IANA has stopped listing them altogether [1].
> Their former IDs are now 'reserved'.
> 
> I think it's time for us to drop them as well.
> 
> ok?

I agree with dropping them. Timing-wise perhaps it's better to do it
after release (possible text for upgrade notes below); OTOH probably
nobody really uses ec2n so it's not all that likely to hurt users (we
can use similar text but say "prior to upgrade, add alternative groups
[...]" instead).

  "The insecure ec2n D-H groups will be removed from iked in the next
  release; if you are using these, add alternative groups to ikesa/childsa
  in iked.conf, then you can move clients across one by one and remove
  the ec2n groups in advance of 6.8.

  While removal of other groups is not imminent, some are considered
  insecure (768-bit MODP, group 1) or weak (1024- and 1536-bit MODP,
  groups 2 and 5). Prefer curve25519, an ECP group of 256 bits or
  more, or a MODP group of 2048 bits or more."

> Index: iked.conf.5
> ===
> RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> retrieving revision 1.66
> diff -u -p -r1.66 iked.conf.5
> --- iked.conf.5   27 Apr 2020 22:40:09 -  1.66
> +++ iked.conf.5   27 Apr 2020 22:58:24 -
> @@ -909,8 +909,6 @@ keyword:
>  .It Em Name Ta Em Group Ta Em Size Ta Em Type
>  .It Li modp768 Ta grp1 Ta 768 Ta "MODP"
>  .It Li modp1024 Ta grp2 Ta 1024 Ta "MODP"

   .It Li modp768 Ta grp1 Ta 768 Ta "MODP" [insecure]
   .It Li modp1024 Ta grp2 Ta 1024 Ta "MODP" [weak]

> -.It Li ec2n155 Ta grp3 Ta 155 Ta "EC2N [insecure]"
> -.It Li ec2n185 Ta grp4 Ta 185 Ta "EC2N [insecure]"
>  .It Li modp1536 Ta grp5 Ta 1536 Ta "MODP"

   .It Li modp1536 Ta grp5 Ta 1536 Ta "MODP" [weak]

I guess we should sprinkle some other weak/insecure in the manual
too but this is a start.

>  .It Li modp2048 Ta grp14 Ta 2048 Ta "MODP"
>  .It Li modp3072 Ta grp15 Ta 3072 Ta "MODP"
> @@ -931,11 +929,8 @@ keyword:
>  .Pp
>  The currently supported group types are either
>  MODP (exponentiation groups modulo a prime),
> -EC2N (elliptic curve groups over GF[2^N]),
>  ECP (elliptic curve groups modulo a prime),
>  or Curve25519.
> -Please note that the EC2N groups are considered as insecure and only
> -provided for backwards compatibility.

   Please note that MODP groups of less than 2048 bits are considered
   as weak or insecure (see RFC 8247 section 2.4) and only provided for
   backwards compatibility.

> --- dh.h  27 Oct 2017 14:26:35 -  1.11
> +++ dh.h  27 Apr 2020 22:58:24 -
> @@ -21,7 +21,6 @@
>  
>  enum group_type {
>   GROUP_MODP  = 0,
> - GROUP_EC2N  = 1,
>   GROUP_ECP   = 2,
>   GROUP_CURVE25519= 3
>  };

Should the others be renumbered so that somebody looking later doesn't
have to figure out why there's a gap?



Re: Raspberry Pi GPIO

2020-04-27 Thread Stuart Henderson
On 2020/04/26 12:56, Mark Kettenis wrote:
> Diff below adds GPIO support to bcmgpio(4).  It also adds the bits to
> attach gpio(4) such that GPIO pins can be controlled from userland.
> This makes sense on boards like the Raspberry Pi and the
> implementation makes sure that pins used by kernel drivers can't be
> touched.
> 
> ok?

Only tested with inputs so far, but works for me. OK sthen@



Re: Update /etc/examples/doas.conf and doas.conf(5)

2020-04-25 Thread Stuart Henderson
On 2020/04/25 19:41, clematis wrote:
> +permit nopass solene cmd /usr/bin/touch
> +permit nopass setenv { TRUSTED_PKG_PATH TERM } solene cmd \
> + /usr/sbin/pkg_add
> +permit nopass setenv { TERM } solene cmd /usr/sbin/pkg_delete

it is bad enough that the dangerous "nopass pkg_add" is in bsd.port.mk(5),
please don't copy it other places!



Re: bgpd local-address improvement

2020-04-23 Thread Stuart Henderson
We could use it in the sample config too. OK?

Index: bgpd.conf
===
RCS file: /cvs/src/etc/examples/bgpd.conf,v
retrieving revision 1.18
diff -u -p -r1.18 bgpd.conf
--- bgpd.conf   16 Feb 2020 20:02:21 -  1.18
+++ bgpd.conf   23 Apr 2020 17:07:12 -
@@ -51,18 +51,15 @@ prefix-set bogons {
 network prefix-set mynetworks set large-community $ASN:1:1
 
 # assume simple network with 3 routers in IBGP full mesh
-group "ibgp mesh v4" {
+group "ibgp mesh" {
remote-as $ASN
-   # use loopback for IBGP sessions, assume its distributed in OSPF
+   # use loopback for IBGP sessions, assume it's distributed in OSPF
local-address 192.0.2.1
-   neighbor 192.0.2.2  # router 2 ipv4
-   neighbor 192.0.2.3  # router 3 ipv4
-}
-# define the IPv6 IBGP sessions
-group "ibgp mesh v6" {
-   remote-as $ASN
local-address 2001:db8:abcd::1
+
+   neighbor 192.0.2.2  # router 2 ipv4
neighbor 2001:db8:abcd::2   # router 2 ipv6
+   neighbor 192.0.2.3  # router 3 ipv4
neighbor 2001:db8:abcd::3   # router 3 ipv6
 }
 



Re: add support for STAILQ_* to queue.h

2020-04-23 Thread Stuart Henderson
On 2020/04/23 10:31, Theo de Raadt wrote:
> Todd C. Miller  wrote:
> 
> > On Thu, 23 Apr 2020 08:41:05 -0600, "Theo de Raadt" wrote:
> > 
> > > My questions boil down to:
> > >
> > > 1) When are too many APIs too may? (It seems there is some agreement 
> > > already)
> > >
> > > 2) Is STAILQ more ubiqitous? (I suspect so)
> > 
> > STAILQ is supported by: FreeBSD, macOS, NetBSD, Solaris, Linux (via libbsd)
> > SIMPLEQ is supported by: NetBSD, OpenBSD, Solaris
> > 
> > So based on a quick survey, STAILQ is more ubiqitous.
> > 
> > > 3) Can upstream be convinced to use STAILQ instead?
> > 
> > Upstream *is* using STAILQ, we're the ones who only support SIMPLEQ.
> > 
> > Personally, I would rather replace SIMPLEQ with STAILQ in our code,
> > though I suspect that is not a popular opinion here.  When I see
> > STAILQ I know exactly what it means and it is consistent with the
> > other macros.  I find that the SIMPLEQ naming conveys very little
> > meaning and I always have to go check to see if it is singly or
> > doubly linked.  Of course, like most things, you get used to the
> > way things are...
> 
> I would be happy wit such unification.
> 
> Are there any objectors?
> 
> (finishing this might need to be put off for about a month, tho)
> 

No objection, after we're done with release builds I can do a test ports
build for this.



Re: Support additional SD/MMC controller on Raspberry Pi 4

2020-04-20 Thread Stuart Henderson
On 2020/04/20 23:43, Mark Kettenis wrote:
> > bwfm(4) is working for me, but when in device tree mode (wherever the
> > uSD is routed) bse(4) is flaky - ethernet link doesn't come up at boot,
> > if I leave it for a little while with a ping running to the bse from
> > another machine I get the occasional packet through but that's all.
> > Do you see that too?
> 
> I don't see that, but I suspect this is because the device tree has
> phy-mode set to "rgmii" instead of "rgmii-rxid".
> 
> A workaround is to take the bcm2711-rpi-4-b.dtb, fixup4.dat and
> start4.elf files from
> 
>   https://github.com/raspberrypi/firmware/tree/next/boot
> 
> and put them on the MS-DOS partition of your uSD card.

Thanks, confirmed it's working for me with the newer files.



Re: distrib/notes/arm64/prep update

2020-04-20 Thread Stuart Henderson
On 2020/04/20 22:23, Olivier wrote:
> Hi stuart,
> 
> Thanks.
> 
> I let you handle it. I would like just share and maybe help.
> 
> My point; is possible that i am doing someting bad ^^, is that on rockpro64, 
> when you perform the install :
> 
> _ emmc with u-boot
> _ pen with miniroot67.fs
> 
> If i did not install the dtb on the pen... i can not write on the emmc, even 
> if i can boot the pen from the emmc.
> 
> As i said, i let you manage ^^ I think i should open a specific thread on 
> that matter in @arm mailing list :)
> 
> Thank you all, for your job ^^

The file I sent the diff for is src/distrib/notes/arm64.

It already has a section, "Install on systems without a supported
miniroot:" telling you to install the dtb and showing how.

The only 64-bit ARM hardware I have is raspberry pi and OD1000 so
if that is not enough then you or somebody else who has a system
that needs this will need to figure out what is missing and propose a
diff.

> 0liv.
> 
> On Mon, 20 Apr 2020 13:42:37 +0100
> Stuart Henderson  wrote:
> 
> > On 2020/04/20 11:06, Olivier wrote:
> > > Hi Mark, 
> > > 
> > > as often i forgot those steps, may i suggest to include the followings 
> > > below ?
> > > 
> > > without it, seems (for me) impossible to write to the installed emmc from 
> > > the installer.
> > 
> > I don't have one of those systems, but I believe this is already coverex
> > by the "Install on systems without a supported miniroot" section.
> 
> 
> -- 
> burelli.fr 
> 



Re: Support additional SD/MMC controller on Raspberry Pi 4

2020-04-20 Thread Stuart Henderson
On 2020/04/19 21:44, Mark Kettenis wrote:
> The Raspberry Pi 4 has an additional SD/MMC controller.  This
> controller is almost completely standard and just needs one tiny
> quirk.  So the diff is really simple.
> 
> By default, if you use the EDK2-base UEFI firmware this controller
> isn't actually connected to anything.  So you'll see
> 
>   sdmmc0: can't enable card
> 
> in your dmesg.  If you change the "Raspberry Pi Configuration" ->
> "SD/MMC Configuration" -> "uSD routing" setting in the "Device
> Manager" firmware configuration screen to "eMMC2 SDHCI".  The uSD card
> will show up behind this controller and WiFi will show up on the other
> controller.  Note that after you've made that configuration change and
> reset the machine, any further change you make won't stick.  You can
> fix this by replacing the RPI_EFI.fd file on the MS-DOS partition of
> your uSD card.
> 
> For now the SDHC controllers are only supported in device tree mode
> which can be enabled using the "Raspberry Pi Configuration" ->
> "Advanced Configuration" -> "Device Tree" option in the "Device
> Manager".

bwfm(4) is working for me, but when in device tree mode (wherever the
uSD is routed) bse(4) is flaky - ethernet link doesn't come up at boot,
if I leave it for a little while with a ping running to the bse from
another machine I get the occasional packet through but that's all.
Do you see that too?

64 bytes from 10.15.5.53: icmp_seq=1977 ttl=255 time=0.590 ms
64 bytes from 10.15.5.53: icmp_seq=1987 ttl=255 time=0.531 ms
64 bytes from 10.15.5.53: icmp_seq=1992 ttl=255 time=0.537 ms
64 bytes from 10.15.5.53: icmp_seq=2024 ttl=255 time=0.543 ms
64 bytes from 10.15.5.53: icmp_seq=2027 ttl=255 time=0.406 ms

Watching interrupt rates whilst flood pinging it, none of them move.

$ vmstat -i 
interrupt   total rate
irq1023/spur   470
irq0/ipinop214576  197
irq153/pluart0  43887   40
irq158/sdhc033516   30
irq175/xhci0   305805  281
irq189/bse0  74136
irq27/tick 867628  797
Total 1472872 1353


ESC (setup), F1 (shell), ENTER (boot).disks: sd0*
>> OpenBSD/arm64 BOOTAA64 0.22
boot>
booting sd0a:/bsd: 7737056+1498096+541152+848472 [509436+109+962448+543543]=0xd3
f930
type 0x0 pa 0x0 va 0x0 pages 0x1d0 attr 0xe
type 0x6 pa 0x1d va 0x97a96c000 pages 0x20 attr 0x800e
type 0x0 pa 0x1f va 0x0 pages 0x10 attr 0xe
type 0x2 pa 0x20 va 0x0 pages 0x4000 attr 0xe
type 0x7 pa 0x420 va 0x0 pages 0x2e8fb attr 0xe
type 0x2 pa 0x32afb000 va 0x0 pages 0xc82 attr 0xe
type 0x1 pa 0x3377d000 va 0x0 pages 0x2a attr 0xe
type 0x0 pa 0x337a7000 va 0x0 pages 0xf9 attr 0xe
type 0x6 pa 0x338a va 0x9ae03c000 pages 0xa0 attr 0x800e
type 0x5 pa 0x3394 va 0x9ae0dc000 pages 0x50 attr 0x800e
type 0x9 pa 0x3399 va 0x0 pages 0x80 attr 0xe
type 0x5 pa 0x33a1 va 0x9ae1ac000 pages 0x80 attr 0x800e
type 0x9 pa 0x33a9 va 0x0 pages 0x20 attr 0xe
type 0x5 pa 0x33ab va 0x9ae24c000 pages 0x80 attr 0x800e
type 0x7 pa 0x33b3 va 0x0 pages 0x19e7 attr 0xe
type 0x4 pa 0x35517000 va 0x0 pages 0x481 attr 0xe
type 0x7 pa 0x35998000 va 0x0 pages 0x5f attr 0xe
type 0x4 pa 0x359f7000 va 0x0 pages 0x1 attr 0xe
type 0x7 pa 0x359f8000 va 0x0 pages 0xd7 attr 0xe
type 0x4 pa 0x35acf000 va 0x0 pages 0xf55 attr 0xe
type 0x7 pa 0x36a24000 va 0x0 pages 0x19e attr 0xe
type 0x3 pa 0x36bc2000 va 0x0 pages 0x43e attr 0xe
type 0x5 pa 0x3700 va 0x9b179c000 pages 0x190 attr 0x800e
type 0x6 pa 0x3719 va 0x9b192c000 pages 0x250 attr 0x800e
type 0x7 pa 0x373e va 0x0 pages 0x1f attr 0xe
type 0x4 pa 0x373ff000 va 0x0 pages 0x1 attr 0xe
type 0x7 pa 0x3740 va 0x0 pages 0x302b attr 0xe
type 0x3 pa 0x3a42b000 va 0x0 pages 0x36 attr 0xe
type 0x4 pa 0x3a461000 va 0x0 pages 0xf9f attr 0xe
type 0x7 pa 0x4000 va 0x0 pages 0x8 attr 0xe
[ using 2016504 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.7-beta (GENERIC.MP) #2: Mon Apr 20 21:13:03 BST 2020
st...@moo.spacehopper.org:/sys/arch/arm64/compile/GENERIC.MP
real mem  = 3076521984 (2934MB)
avail mem = 2951929856 (2815MB)
mainbus0 at root: Raspberry Pi 4 Model B Rev 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
efi0 at mainbus0: UEFI 2.7
efi0: https://github.com/pftf/RPi4 rev 0x1
smbios0 at efi0: SMBIOS 3.3.0
smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.8" date 
Apr 14 2020 21:24:48
smbios0: Sony UK Raspberry Pi 4 Model B
apm0 at mainbus0
psci0 at mainbus0: PSCI 1.1, 

Re: distrib/notes/arm64/prep update

2020-04-20 Thread Stuart Henderson
On 2020/04/20 11:06, Olivier wrote:
> Hi Mark, 
> 
> as often i forgot those steps, may i suggest to include the followings below ?
> 
> without it, seems (for me) impossible to write to the installed emmc from the 
> installer.

I don't have one of those systems, but I believe this is already coverex
by the "Install on systems without a supported miniroot" section.



rpki-client(8), fix default cachedir

2020-04-18 Thread Stuart Henderson
Spotted while trying to figure out what "rpki-client: cache directory required"
meant.

ok?

Index: rpki-client.8
===
RCS file: /cvs/src/usr.sbin/rpki-client/rpki-client.8,v
retrieving revision 1.22
diff -u -p -r1.22 rpki-client.8
--- rpki-client.8   6 Mar 2020 22:22:31 -   1.22
+++ rpki-client.8   18 Apr 2020 12:37:18 -
@@ -68,7 +68,7 @@ The directory where
 .Nm
 will store the cached repository data.
 Defaults to
-.Pa /var/db/rpki-client/ .
+.Pa /var/cache/rpki-client .
 .It Fl e Ar rsync_prog
 Use
 .Ar rsync_prog



Re: a POSIXy diff for what(1)

2020-04-18 Thread Stuart Henderson
On 2020/04/18 11:12, Martijn van Duren wrote:
> Looks fine to me. And I don't expect the tool to be widely used on
> OpenBSD. Anyone objects/OK?
> 
> Small sidenote: Could you attach your diffs inline in the future? It's
> the standard way of doing things here. I've added it here, so people
> who don't want to open the file can see it.

:   The standard output shall consist of the following for each file operand:
:
:   "%s:\n\t%s\n", , 

That is pretty clear. OK sthen@ (and I do use what(1) :)



distrib/notes/arm64/prep update

2020-04-16 Thread Stuart Henderson
any comments? ok?

Index: prep
===
RCS file: /cvs/src/distrib/notes/arm64/prep,v
retrieving revision 1.9
diff -u -p -r1.9 prep
--- prep15 Apr 2020 11:41:08 -  1.9
+++ prep16 Apr 2020 20:29:56 -
@@ -24,11 +24,11 @@ Booting from an SD card:
   storage devices.  Under OpenBSD, it will appear as a ``sd'' device, for
   example sd1.
   
-  Use the dd(1) utility to copy the miniroot to the hard drive.
+  Use the dd(1) utility to copy the miniroot to the SD card.
   The command would likely be, under OpenBSD:
dd if=miniroot{:--:}OSrev.fs of=/dev/rsd1c bs=1m
   
-  When you have connected the serial to you computer, a command such
+  When you have connected the serial to your computer, a command such
   as "cu -l cuaU0 -s 115200" (assuming cuaU0 is your serial port device)
   should connect you to the board's console.
 
@@ -48,6 +48,35 @@ script.
=> bootefi ${kernel_addr_r} ${fdt_addr_r}
 The bootloader will then run and try to load sd0a:/bsd off an FFS
 filesystem after a timeout.
+
+Install on Raspberry Pi 4:
+
+  You will need a microSD card (only a small one is needed), a USB
+  storage device, a TTL serial interface adapter (e.g. CP2102 USB-UART
+  converter), and a cable to attach this to the TXD/RXD/GND pins on the
+  https://pinout.xyz/ header on the board.
+
+  Follow the installation instructions at https://github.com/pftf/RPi4
+  to install UEFI firmware to a FAT-formatted microSD card.
+
+  Use the dd(1) utility to copy the miniroot to the USB storage device.
+  The command would likely be, under OpenBSD:
+   dd if=miniroot{:--:}OSrev.fs of=/dev/rsd1c bs=1m
+
+  When you have connected the serial to your computer, a command such
+  as "cu -l cuaU0 -s 115200" (assuming cuaU0 is your serial port device)
+  should connect you to the board's console.
+
+  Shortly after powering the board, you should see messages on the serial
+  console starting with "Initialising SDRAM" followed by messages from the
+  UEFI firmware.  If you have a monitor connected to the HDMI port, you
+  should see a multi-coloured screen followed by UEFI firmware output.
+  If you do not see this, re-check your UEFI firmware installation.
+
+  OpenBSD should boot automatically soon after loading the UEFI firmware.
+  If a monitor is connected you will see messages from the boot loader,
+  but after the kernel has started running you will only see output on
+  the serial console.
 
 Install on systems without a supported miniroot:
 



  1   2   3   4   5   6   7   8   9   10   >