Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

[Brent Cook]

No problem, I undid that bit.

Thanks all.

On Mon, Jun 20, 2016 at 11:32 AM, Ted Unangst  wrote:

> Brent Cook wrote:
> > diff --git a/src/lib/libssl/src/crypto/dsa/dsa_key.c
> b/src/lib/libssl/src/crypto/dsa/dsa_key.c
> > index 2968fa2..e01bacb 100644
> > --- a/src/lib/libssl/src/crypto/dsa/dsa_key.c
> > +++ b/src/lib/libssl/src/crypto/dsa/dsa_key.c
> > -#endif
> > +#endif
> > \ No newline at end of file
>
> can we please keep the newline at the end of the file?
>

Re: pf.conf macro with space

[Sebastian Benoit]

sven falempin(sven.falem...@gmail.com) on 2016.06.20 17:38:40 -0400:
> Dear Tech Readers,
> 
> in a pf.conf file one can do
> "silly things" = egress

Thanks for your diff, but

one, i dont think spaces in macros are useful in pf.conf.

second, we want to keep this consistent across all the parse.y in our code,
so we have to think how this affects these(*)

Below is a diff that disallows "silly things".

I thinks it's easier to check that spaces in macros can be done without.

diff --git sbin/pfctl/parse.y sbin/pfctl/parse.y
index 934438c..341d1af 100644
--- sbin/pfctl/parse.y
+++ sbin/pfctl/parse.y
@@ -94,6 +94,7 @@ struct sym {
char*nam;
char*val;
 };
+int has_whitespace(const char *);
 int symset(const char *, const char *, int);
 char   *symget(const char *);
 
@@ -714,6 +715,10 @@ numberstring   : NUMBER
{
 varset : STRING '=' varstring  {
if (pf->opts & PF_OPT_VERBOSE)
printf("%s = \"%s\"\n", $1, $3);
+   if (has_whitespace($1)) {
+   yyerror("macro name cannot contain whitespace");
+   YYERROR;
+   }
if (symset($1, $3, 0) == -1)
err(1, "cannot store variable %s", $1);
free($1);
@@ -5455,6 +5460,16 @@ parse_config(char *filename, struct pfctl *xpf)
 }
 
 int
+has_whitespace(const char *s) {
+   while (*s != '\0') {
+   if (isspace(*s))
+   return 1;
+   s++;
+   }
+   return 0;
+}
+
+int
 symset(const char *nam, const char *val, int persist)
 {
struct sym  *sym;



(*)
./bin/chio/parse.y
./sbin/iked/parse.y
./sbin/ipsecctl/parse.y
./sbin/pfctl/parse.y
./usr.bin/doas/parse.y
./usr.sbin/bgpd/parse.y
./usr.sbin/dvmrpd/parse.y
./usr.sbin/eigrpd/parse.y
./usr.sbin/hostapd/parse.y
./usr.sbin/httpd/parse.y
./usr.sbin/ifstated/parse.y
./usr.sbin/iscsictl/parse.y
./usr.sbin/ldapd/parse.y
./usr.sbin/ldomctl/parse.y
./usr.sbin/ldpd/parse.y
./usr.sbin/npppd/npppd/parse.y
./usr.sbin/ntpd/parse.y
./usr.sbin/ospf6d/parse.y
./usr.sbin/ospfd/parse.y
./usr.sbin/radiusd/parse.y
./usr.sbin/relayd/parse.y
./usr.sbin/ripd/parse.y
./usr.sbin/smtpd/parse.y
./usr.sbin/snmpd/parse.y
./usr.sbin/vmd/parse.y
./usr.sbin/ypldap/parse.y
 
> as defined in parse.y like
> 
> varset  : STRING '=' varstring  {
> if (pf->opts & PF_OPT_VERBOSE)
> printf("%s = \"%s\"\n", $1, $3);
> if (symset($1, $3, 0) == -1)
> err(1, "cannot store variable %s", $1);
> free($1);
> free($3);
> }
> 
> and because it s better to triple check
> $ cat /tmp/pf.lol.conf
> karate = egress
> "kar ra tei" = egress
> pass on $kar\ ra\ tei
> $ pfctl -nf /tmp/pf.lol.conf
> /tmp/pf.lol.conf:3: macro 'kar' not defined
> /tmp/pf.lol.conf:3: syntax error
> 
> i also tried the bash ${hope} or makefile $(madness) and even $"sillyness"
> 
> I also remember that being able to read a config file with ease can save a
> lot of time
> 
> "Third Floor Network Switch" = em8
> pass quick on $"Third Floor Network Switch" from www.openbsd.org to
> ($"Third Floor Network Switch":network) set prio (7,7)
> 
> I was wondering why it refused such and read the code,
> fount out a lgetc function is used to read string, and first argument is
> explicit and is a switch to manage quoted string,
> so why not using it after the $macro ?
> 
> --- ./parse.y   Tue Apr 21 12:34:59 2015
> +++ /tmp/1  Mon Jun 20 17:04:08 2016
> @@ -5179,7 +5179,7 @@
> ; /* nothing */
> if (c == '$' && parsebuf == NULL) {
> while (1) {
> -   if ((c = lgetc(0)) == EOF)
> +   if ((c = lgetc(1)) == EOF)
> return (0);
> 
> if (p + 1 >= buf + sizeof(buf) - 1) {
> 
> of course it s not that simple as the code below show, this one works,
> the previous does not.
>  :
> 
> Index: parse.y
> ===
> RCS file: /cvs/src/sbin/pfctl/parse.y,v
> retrieving revision 1.648
> diff -u -r1.648 parse.y
> --- parse.y 21 Apr 2015 16:34:59 -  1.648
> +++ parse.y 20 Jun 2016 21:36:29 -
> @@ -5178,22 +5178,55 @@
> while ((c = lgetc(0)) != '\n' && c != EOF)
> ; /* nothing */
> if (c == '$' && parsebuf == NULL) {
> -   while (1) {
> -   if ((c = lgetc(0)) == EOF)
> -   return (0);
> -
> -   if (p + 1 >= buf + sizeof(buf) - 1) {
> -   yyerror("string too long");
> 

Re: pf divert port reuse

[Sebastian Benoit]

Alexander Bluhm(alexander.bl...@gmx.net) on 2016.06.21 00:14:19 +0200:
> Hi,
> 
> I have seen a problem with pf divert when the dynamic port in a nat
> rule got reused.  The function pf_state_key_attach() reused the
> state as it was in TCPS_FIN_WAIT_2.  The corresponding socket was
> not reused, as the the TCPS_TIME_WAIT case in tcp_input() has
> additional checks for timestamps and sequence numbers.  When I port
> the condition SEQ_GT(th->th_seq, tp->rcv_nxt) from the stack to pf,
> the socket and state are kept in sync.  Then divert works fine.

sounds convincing
 
> ok?

ok

> 
> bluhm
> 
> Index: net/pf.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
> retrieving revision 1.977
> diff -u -p -r1.977 pf.c
> --- net/pf.c  15 Jun 2016 11:49:34 -  1.977
> +++ net/pf.c  20 Jun 2016 21:18:53 -
> @@ -671,7 +671,8 @@ pf_state_key_attach(struct pf_state_key 
>si->s->direction != s->direction))) {
>   if (sk->proto == IPPROTO_TCP &&
>   si->s->src.state >= TCPS_FIN_WAIT_2 &&
> - si->s->dst.state >= TCPS_FIN_WAIT_2) {
> + si->s->dst.state >= TCPS_FIN_WAIT_2 &&
> + SEQ_GT(s->src.seqlo, si->s->src.seqlo)) {
>   si->s->src.state = si->s->dst.state =
>   TCPS_CLOSED;
>   /* remove late or sks can go away */
> 

-- 

Re: fix iwm association problems

[Bryan Vyhmeister]

On Mon, Jun 20, 2016 at 12:34:17PM +0200, Stefan Sperling wrote:
> I found that my 8260 iwm(4) device has trouble associating to my 5 GHz
> AP, which runs OpenBSD with athn(4) in hostap mode. Most of the time
> it won't even get a DHCP lease. Some frames it believes it has sent
> are not even visible on the air.
> 
> The iwm driver still has a copy of code from Linux that sends DTIM TSF
> information to the firmware. I believe this depends on Linux mac80211
> behaviour details and is bogus with our stack, and we should just let
> firmware handle TSF synchronization details by itself (and just look
> at those glories comments...)
> 
> Also, clear in_assoc when going down, as it effects early behaviour
> when coming up, before association (found by Imre).
> 
> I'm now getting much better results when switching between networks
> with the 8260. Doesn't cause problems on 7260 and 7265.
> 
> ok?

This appears to completely solve the delay in getting an address problem
we have talked about previously with my X260 and its 8260 card. There
are multiple access points visible in my environment at any one spot
with multiple 2.4GHz and 5GHz SSIDs. Thank you!

Bryan

pf divert port reuse

[Alexander Bluhm]

Hi,

I have seen a problem with pf divert when the dynamic port in a nat
rule got reused.  The function pf_state_key_attach() reused the
state as it was in TCPS_FIN_WAIT_2.  The corresponding socket was
not reused, as the the TCPS_TIME_WAIT case in tcp_input() has
additional checks for timestamps and sequence numbers.  When I port
the condition SEQ_GT(th->th_seq, tp->rcv_nxt) from the stack to pf,
the socket and state are kept in sync.  Then divert works fine.

ok?

bluhm

Index: net/pf.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
retrieving revision 1.977
diff -u -p -r1.977 pf.c
--- net/pf.c15 Jun 2016 11:49:34 -  1.977
+++ net/pf.c20 Jun 2016 21:18:53 -
@@ -671,7 +671,8 @@ pf_state_key_attach(struct pf_state_key 
 si->s->direction != s->direction))) {
if (sk->proto == IPPROTO_TCP &&
si->s->src.state >= TCPS_FIN_WAIT_2 &&
-   si->s->dst.state >= TCPS_FIN_WAIT_2) {
+   si->s->dst.state >= TCPS_FIN_WAIT_2 &&
+   SEQ_GT(s->src.seqlo, si->s->src.seqlo)) {
si->s->src.state = si->s->dst.state =
TCPS_CLOSED;
/* remove late or sks can go away */

Re: Stop mesa W^X violations

[Theo de Raadt]

>Note that the existing code would have worked just fine if mmap
>returned MAP_FAILED for W^X violations instead of terminating the
>program.  Not entirely sure what the long-term plans are.

Yeah, I am not sure of the long-term plans yet either.  In discussions
with the ports people the idea was fail-hard behaviour for a while,
then we'll try error returns for a while, and maybe we need to see-saw
a few times.  The approach is still very focused on creating awareness
amongst the "right people" who can fix things.

pf.conf macro with space

[sven falempin]

Dear Tech Readers,

in a pf.conf file one can do
"silly things" = egress

as defined in parse.y like

varset  : STRING '=' varstring  {
if (pf->opts & PF_OPT_VERBOSE)
printf("%s = \"%s\"\n", $1, $3);
if (symset($1, $3, 0) == -1)
err(1, "cannot store variable %s", $1);
free($1);
free($3);
}

and because it s better to triple check
$ cat /tmp/pf.lol.conf
karate = egress
"kar ra tei" = egress
pass on $kar\ ra\ tei
$ pfctl -nf /tmp/pf.lol.conf
/tmp/pf.lol.conf:3: macro 'kar' not defined
/tmp/pf.lol.conf:3: syntax error

i also tried the bash ${hope} or makefile $(madness) and even $"sillyness"

I also remember that being able to read a config file with ease can save a
lot of time

"Third Floor Network Switch" = em8
pass quick on $"Third Floor Network Switch" from www.openbsd.org to
($"Third Floor Network Switch":network) set prio (7,7)

I was wondering why it refused such and read the code,
fount out a lgetc function is used to read string, and first argument is
explicit and is a switch to manage quoted string,
so why not using it after the $macro ?

--- ./parse.y   Tue Apr 21 12:34:59 2015
+++ /tmp/1  Mon Jun 20 17:04:08 2016
@@ -5179,7 +5179,7 @@
; /* nothing */
if (c == '$' && parsebuf == NULL) {
while (1) {
-   if ((c = lgetc(0)) == EOF)
+   if ((c = lgetc(1)) == EOF)
return (0);

if (p + 1 >= buf + sizeof(buf) - 1) {

of course it s not that simple as the code below show, this one works,
the previous does not.
 :

Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.648
diff -u -r1.648 parse.y
--- parse.y 21 Apr 2015 16:34:59 -  1.648
+++ parse.y 20 Jun 2016 21:36:29 -
@@ -5178,22 +5178,55 @@
while ((c = lgetc(0)) != '\n' && c != EOF)
; /* nothing */
if (c == '$' && parsebuf == NULL) {
-   while (1) {
-   if ((c = lgetc(0)) == EOF)
-   return (0);
-
-   if (p + 1 >= buf + sizeof(buf) - 1) {
-   yyerror("string too long");
-   return (findeol());
-   }
-   if (isalnum(c) || c == '_') {
+   if ((c = lgetc(0)) == '"') {
+   quotec = c;
+   while (1) {
+   if ((c = lgetc(quotec)) == EOF)
+   return (0);
+   if (c == '\n') {
+   file->lineno++;
+   continue;
+   } else if (c == '\\') {
+   if ((next = lgetc(quotec)) == EOF)
+   return (0);
+   if (next == quotec || c == ' ' || c
== '\t')
+   c = next;
+   else if (next == '\n') {
+   file->lineno++;
+   continue;
+   } else
+   lungetc(next);
+   } else if (c == quotec) {
+   *p = '\0';
+   break;
+   } else if (c == '\0') {
+   yyerror("syntax error");
+   return (findeol());
+   }
+   if (p + 1 >= buf + sizeof(buf) - 1) {
+   yyerror("string too long");
+   return (findeol());
+   }
*p++ = c;
-   continue;
}
-   *p = '\0';
-   lungetc(c);
-   break;
-   }
+   } else
+   while (1) {
+   if ((c = lgetc(0)) == EOF)
+   return (0);
+
+   if (p + 1 >= buf + sizeof(buf) - 1) {
+   yyerror("string too long");
+   return (findeol());
+   }
+
+   if (isalnum(c) || c == '_') {
+   *p++ = c;
+   

Stop mesa W^X violations

[Mark Kettenis]

As reported by several people, mesa contains code that violates W^X.
As a result glxgears aborts when using the swrast driver.  The diff
below disables the offending code.  The code seems to deal the absence
of W|X memory just fine.  There is a fallback path that is also used
on SELinux systems.

Note that the existing code would have worked just fine if mmap
returned MAP_FAILED for W^X violations instead of terminating the
program.  Not entirely sure what the long-term plans are.


Index: src/gallium/auxiliary/rtasm/rtasm_execmem.c
===
RCS file: /cvs/xenocara/lib/mesa/src/gallium/auxiliary/rtasm/rtasm_execmem.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 rtasm_execmem.c
--- src/gallium/auxiliary/rtasm/rtasm_execmem.c 22 Nov 2015 02:43:24 -  
1.1.1.1
+++ src/gallium/auxiliary/rtasm/rtasm_execmem.c 20 Jun 2016 20:08:37 -
@@ -69,6 +69,16 @@ static struct mem_block *exec_heap = NUL
 static unsigned char *exec_mem = NULL;
 
 
+#ifdef __OpenBSD__
+
+static int
+init_heap(void)
+{
+   return 0;
+}
+
+#else
+
 static int
 init_heap(void)
 {
@@ -82,6 +92,8 @@ init_heap(void)
 
return (exec_mem != MAP_FAILED);
 }
+
+#endif
 
 
 void *
Index: src/mapi/u_execmem.c
===
RCS file: /cvs/xenocara/lib/mesa/src/mapi/u_execmem.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 u_execmem.c
--- src/mapi/u_execmem.c22 Nov 2015 02:45:44 -  1.1.1.1
+++ src/mapi/u_execmem.c20 Jun 2016 20:08:39 -
@@ -45,8 +45,15 @@ static unsigned int head = 0;
 
 static unsigned char *exec_mem = (unsigned char *)0;
 
+#if defined(__OpenBSD__)
 
-#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
defined(__sun) || defined(__HAIKU__)
+static int
+init_map(void)
+{
+  return 0;
+}
+
+#elif defined(__linux__) || defined(_NetBSD__) || defined(__sun) || 
defined(__HAIKU__)
 
 #include 
 #include 
Index: src/mesa/main/execmem.c
===
RCS file: /cvs/xenocara/lib/mesa/src/mesa/main/execmem.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 execmem.c
--- src/mesa/main/execmem.c 22 Nov 2015 02:39:37 -  1.1.1.1
+++ src/mesa/main/execmem.c 20 Jun 2016 20:08:40 -
@@ -36,7 +36,15 @@
 
 
 
-#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
defined(__sun) || defined(__HAIKU__)
+#if defined(__OpenBSD__)
+
+static int
+init_heap(void)
+{
+  return 0;
+}
+
+#elif defined(__linux__) || defined(_NetBSD__) || defined(__sun) || 
defined(__HAIKU__)
 
 /*
  * Allocate a large block of memory which can hold code then dole it out

Re: bgpd logging nexthop valid

[Peter Hessler]

On 2016 Jun 19 (Sun) at 17:39:53 +0200 (+0200), Sebastian Benoit wrote:
:i would like to make bgpd a bit more quiet.
:
:This type of message
:
: bgpd[59424]: nexthop 1.2.3.4 now valid: via 192.168.0.1
:
:happens quite often depending on your upstreams. This makes it a debug
:message only.
:
:ok?
:

YES YES YES YES YES

ahem.  "OK"


:diff --git usr.sbin/bgpd/bgpd.c usr.sbin/bgpd/bgpd.c
:index 8e0031e..8925086 100644
:--- usr.sbin/bgpd/bgpd.c
:+++ usr.sbin/bgpd/bgpd.c
:@@ -771,7 +771,7 @@ send_nexthop_update(struct kroute_nexthop *msg)
:   quit = 1;
:   }
: 
:-  log_info("nexthop %s now %s%s%s", log_addr(>nexthop),
:+  log_debug("nexthop %s now %s%s%s", log_addr(>nexthop),
:   msg->valid ? "valid" : "invalid",
:   msg->connected ? ": directly connected" : "",
:   msg->gateway.aid ? gw : "");
:

-- 
Documentation is the castor oil of programming.  Managers know it must
be good because the programmers hate it so much.

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

[Ted Unangst]

Brent Cook wrote:
> diff --git a/src/lib/libssl/src/crypto/dsa/dsa_key.c 
> b/src/lib/libssl/src/crypto/dsa/dsa_key.c
> index 2968fa2..e01bacb 100644
> --- a/src/lib/libssl/src/crypto/dsa/dsa_key.c
> +++ b/src/lib/libssl/src/crypto/dsa/dsa_key.c
> -#endif
> +#endif
> \ No newline at end of file

can we please keep the newline at the end of the file?

Re: bgpd logging nexthop valid

[Stefan Sperling]

On Sun, Jun 19, 2016 at 05:39:53PM +0200, Sebastian Benoit wrote:
> i would like to make bgpd a bit more quiet.
> 
> This type of message
> 
>  bgpd[59424]: nexthop 1.2.3.4 now valid: via 192.168.0.1
> 
> happens quite often depending on your upstreams. This makes it a debug
> message only.
> 
> ok?

Looks fine to me. I don't run bgpd, but this looks like a normal
operational event and not worth logging by default.

> diff --git usr.sbin/bgpd/bgpd.c usr.sbin/bgpd/bgpd.c
> index 8e0031e..8925086 100644
> --- usr.sbin/bgpd/bgpd.c
> +++ usr.sbin/bgpd/bgpd.c
> @@ -771,7 +771,7 @@ send_nexthop_update(struct kroute_nexthop *msg)
>   quit = 1;
>   }
>  
> - log_info("nexthop %s now %s%s%s", log_addr(>nexthop),
> + log_debug("nexthop %s now %s%s%s", log_addr(>nexthop),
>   msg->valid ? "valid" : "invalid",
>   msg->connected ? ": directly connected" : "",
>   msg->gateway.aid ? gw : "");
> 

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

[Stuart Henderson]

On 2016/06/20 16:55, Marc Espie wrote:
> The only thing I'm wondering about is if there's somebody out there who
> just uses the "big integer arithmetic" part of openssl, and doesn't want
> to go libgmp  for licensing reasons.
> 
> Like, if you're in it for (say) trying to break codes, having code that
> goes as fast as it can might be useful.
> 
> Is this a valid concern ?
> 

If someone is doing this and needs the speed, they're going to need
to find a different solution for OpenSSL as well, they have already
enforced constant-time DSA in their tree.

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

[Marc Espie]

The only thing I'm wondering about is if there's somebody out there who
just uses the "big integer arithmetic" part of openssl, and doesn't want
to go libgmp  for licensing reasons.

Like, if you're in it for (say) trying to break codes, having code that
goes as fast as it can might be useful.

Is this a valid concern ?

Re: openssl(1): fix bug loading default certificate path locations

[Bob Beck]

sure.. ok


On Mon, Jun 20, 2016 at 08:35:13AM -0500, Brent Cook wrote:
> 
> This fixes a bug where the default certificate path locations would only
> be loaded if the CAfile or CApath locations were succesfully loaded
> first. Original patch from OpenSSL:
> 
> https://github.com/openssl/openssl/commit/fe9b85c3cb79f1e29e61f01de105b34ce8177190
> 
> Noted here on the LibreSSL-portable github tracker:
> 
> https://github.com/libressl-portable/openbsd/issues/62
> 
> ok?
> 
> Index: s_client.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_client.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 s_client.c
> --- s_client.c1 Dec 2015 12:01:56 -   1.27
> +++ s_client.c20 Jun 2016 13:31:43 -
> @@ -728,15 +728,13 @@ bad:
>   if (!set_cert_key_stuff(ctx, cert, key))
>   goto end;
> 
> - if ((!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) ||
> - (!SSL_CTX_set_default_verify_paths(ctx))) {
> - /*
> -  * BIO_printf(bio_err,"error setting default verify
> -  * locations\n");
> -  */
> + if ((CAfile || CApath)
> + && !SSL_CTX_load_verify_locations(ctx, CAfile, CApath))
>   ERR_print_errors(bio_err);
> - /* goto end; */
> - }
> +
> + if (!SSL_CTX_set_default_verify_paths(ctx))
> + ERR_print_errors(bio_err);
> +
>   if (servername != NULL) {
>   tlsextcbp.biodebug = bio_err;
>   SSL_CTX_set_tlsext_servername_callback(ctx, ssl_servername_cb);
> 

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

[Bob Beck]

Reads good to me, and passes the regress here, so OK from me. 


On Mon, Jun 20, 2016 at 04:40:25AM -0500, Brent Cook wrote:
> Hi,
> 
> This is a patch from Cesar Pereida, removing support for
> DSA_FLAG_NO_EXP_CONSTTIME by making DSA always operate in constant time.
> 
> See https://github.com/libressl-portable/openbsd/pull/61 for more
> details.
> 
> ok?
> 
> diff --git a/src/lib/libssl/src/crypto/dsa/dsa.h 
> b/src/lib/libssl/src/crypto/dsa/dsa.h
> index 909096d..d2d1d5f 100644
> --- a/src/lib/libssl/src/crypto/dsa/dsa.h
> +++ b/src/lib/libssl/src/crypto/dsa/dsa.h
> @@ -89,12 +89,8 @@
>  #endif
> 
>  #define DSA_FLAG_CACHE_MONT_P0x01
> -#define DSA_FLAG_NO_EXP_CONSTTIME   0x02 /* new with 0.9.7h; the 
> built-in DSA
> -  * implementation now uses 
> constant time
> -  * modular exponentiation for 
> secret exponents
> -  * by default. This flag causes 
> the
> -  * faster variable sliding 
> window method to
> -  * be used for all exponents.
> +#define DSA_FLAG_NO_EXP_CONSTTIME   0x00 /* Does nothing. Previously 
> this switched off
> +  * constant time behaviour.
>*/
> 
>  /* If this flag is set the DSA method is FIPS compliant and can be used
> diff --git a/src/lib/libssl/src/crypto/dsa/dsa_key.c 
> b/src/lib/libssl/src/crypto/dsa/dsa_key.c
> index 2968fa2..e01bacb 100644
> --- a/src/lib/libssl/src/crypto/dsa/dsa_key.c
> +++ b/src/lib/libssl/src/crypto/dsa/dsa_key.c
> @@ -104,18 +104,18 @@ dsa_builtin_keygen(DSA *dsa)
>   pub_key=dsa->pub_key;
> 
>   {
> - BIGNUM local_prk;
> - BIGNUM *prk;
> + BIGNUM *prk = BN_new();
> 
> - if ((dsa->flags & DSA_FLAG_NO_EXP_CONSTTIME) == 0) {
> - BN_init(_prk);
> - prk = _prk;
> - BN_with_flags(prk, priv_key, BN_FLG_CONSTTIME);
> - } else
> - prk = priv_key;
> + if (prk == NULL)
> + goto err;
> +
> + BN_with_flags(prk, priv_key, BN_FLG_CONSTTIME);
> 
> - if (!BN_mod_exp(pub_key, dsa->g, prk, dsa->p, ctx))
> + if (!BN_mod_exp(pub_key, dsa->g, prk, dsa->p, ctx)) {
> + BN_free(prk);
>   goto err;
> + }
> + BN_free(prk);
>   }
> 
>   dsa->priv_key = priv_key;
> @@ -130,4 +130,4 @@ err:
>   BN_CTX_free(ctx);
>   return ok;
>  }
> -#endif
> +#endif
> \ No newline at end of file
> diff --git a/src/lib/libssl/src/crypto/dsa/dsa_ossl.c 
> b/src/lib/libssl/src/crypto/dsa/dsa_ossl.c
> index 726e6c7..4a3b417 100644
> --- a/src/lib/libssl/src/crypto/dsa/dsa_ossl.c
> +++ b/src/lib/libssl/src/crypto/dsa/dsa_ossl.c
> @@ -83,46 +83,6 @@ static DSA_METHOD openssl_dsa_meth = {
>   .finish = dsa_finish
>  };
> 
> -/*
> - * These macro wrappers replace attempts to use the dsa_mod_exp() and
> - * bn_mod_exp() handlers in the DSA_METHOD structure. We avoid the problem of
> - * having a the macro work as an expression by bundling an "err_instr". So;
> - *
> - * if (!dsa->meth->bn_mod_exp(dsa, r,dsa->g,,dsa->p,ctx,
> - * dsa->method_mont_p)) goto err;
> - *
> - * can be replaced by;
> - *
> - * DSA_BN_MOD_EXP(goto err, dsa, r, dsa->g, , dsa->p, ctx,
> - * dsa->method_mont_p);
> - */
> -
> -#define DSA_MOD_EXP(err_instr,dsa,rr,a1,p1,a2,p2,m,ctx,in_mont) \
> -do { \
> - int _tmp_res53; \
> - if ((dsa)->meth->dsa_mod_exp) \
> - _tmp_res53 = (dsa)->meth->dsa_mod_exp((dsa), (rr), \
> - (a1), (p1), (a2), (p2), (m), (ctx), (in_mont)); \
> - else \
> - _tmp_res53 = BN_mod_exp2_mont((rr), (a1), \
> - (p1), (a2), (p2), (m), (ctx), (in_mont)); \
> - if (!_tmp_res53) \
> - err_instr; \
> -} while(0)
> -
> -#define DSA_BN_MOD_EXP(err_instr,dsa,r,a,p,m,ctx,m_ctx) \
> -do { \
> - int _tmp_res53; \
> - if ((dsa)->meth->bn_mod_exp) \
> - _tmp_res53 = (dsa)->meth->bn_mod_exp((dsa), (r), \
> - (a), (p), (m), (ctx), (m_ctx)); \
> - else \
> - _tmp_res53 = BN_mod_exp_mont((r), (a), (p), (m), \
> - (ctx), (m_ctx)); \
> - if (!_tmp_res53) \
> - err_instr; \
> -} while(0)
> -
>  const DSA_METHOD *
>  DSA_OpenSSL(void)
>  {
> @@ -222,7 +182,7 @@ static int
>  dsa_sign_setup(DSA *dsa, BN_CTX *ctx_in, BIGNUM **kinvp, BIGNUM **rp)
>  {
>   BN_CTX *ctx;
> - BIGNUM k, kq, *K, *kinv = NULL, *r = NULL;
> + BIGNUM k, *kinv = NULL, *r = NULL;
>   int ret = 0;
> 
>   if (!dsa->p || !dsa->q || !dsa->g) {
> @@ -231,7 +191,6 @@ dsa_sign_setup(DSA *dsa, BN_CTX *ctx_in, BIGNUM 

openssl(1): fix bug loading default certificate path locations

[Brent Cook]

This fixes a bug where the default certificate path locations would only
be loaded if the CAfile or CApath locations were succesfully loaded
first. Original patch from OpenSSL:

https://github.com/openssl/openssl/commit/fe9b85c3cb79f1e29e61f01de105b34ce8177190

Noted here on the LibreSSL-portable github tracker:

https://github.com/libressl-portable/openbsd/issues/62

ok?

Index: s_client.c
===
RCS file: /cvs/src/usr.bin/openssl/s_client.c,v
retrieving revision 1.27
diff -u -p -r1.27 s_client.c
--- s_client.c  1 Dec 2015 12:01:56 -   1.27
+++ s_client.c  20 Jun 2016 13:31:43 -
@@ -728,15 +728,13 @@ bad:
if (!set_cert_key_stuff(ctx, cert, key))
goto end;

-   if ((!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) ||
-   (!SSL_CTX_set_default_verify_paths(ctx))) {
-   /*
-* BIO_printf(bio_err,"error setting default verify
-* locations\n");
-*/
+   if ((CAfile || CApath)
+   && !SSL_CTX_load_verify_locations(ctx, CAfile, CApath))
ERR_print_errors(bio_err);
-   /* goto end; */
-   }
+
+   if (!SSL_CTX_set_default_verify_paths(ctx))
+   ERR_print_errors(bio_err);
+
if (servername != NULL) {
tlsextcbp.biodebug = bio_err;
SSL_CTX_set_tlsext_servername_callback(ctx, ssl_servername_cb);

Re: af-to on pass out should be a parser error

[Henning Brauer]

* Mike Belopuhov  [2016-06-20 00:33]:
> rdr-to/nat-to are not checked on purpose.  i'm not certain about
> route-to/reply-to.

indeed, rdr-to/nat-to in the "unnatural" direction DO work, with
caveats. route-to and af-to are different.

as others already pointed out the check should be != PF_IN and not ==
PF_OUT, to catch unspecified direction.

With that, ok with me.

> as far as i'm concerned, af-to should be restricted to "pass in".
> but it would be nice to know if "pass out route-to" and "pass in
> reply-to" produce working configurations to restrict them as well
> if they don't.

ack - I dunno either otoh

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

pool_setipl for tmpfs

[David Gwynne]

PR_WAITOK implies process context, so IPL_NONE is fine.

this is the same as the ufs change, but in tmpfs.

ok?

Index: tmpfs_vfsops.c
===
RCS file: /cvs/src/sys/tmpfs/tmpfs_vfsops.c,v
retrieving revision 1.8
diff -u -p -r1.8 tmpfs_vfsops.c
--- tmpfs_vfsops.c  13 Jan 2016 13:01:40 -  1.8
+++ tmpfs_vfsops.c  20 Jun 2016 12:16:04 -
@@ -75,8 +75,10 @@ tmpfs_init(struct vfsconf *vfsp)
 
pool_init(_dirent_pool, sizeof(tmpfs_dirent_t), 0, 0, PR_WAITOK,
"tmpfs_dirent", NULL);
+   pool_setipl(_dirent_pool, IPL_NONE);
pool_init(_node_pool, sizeof(tmpfs_node_t), 0, 0, PR_WAITOK,
"tmpfs_node", NULL);
+   pool_setipl(_node_pool, IPL_NONE);
 
return 0;
 }

Re: set art_walk up for an mpsafe world

[David Gwynne]

> On 18 Jun 2016, at 1:53 AM, Martin Pieuchot  wrote:
> 
> On 15/06/16(Wed) 11:38, David Gwynne wrote:
>> this tweaks art_walk in preparation for a world where the table may
>> be updated on another cpu.
>> 
>> at the moment we're relying on the big lock to serialise updates,
>> so this adds big lock calls in the right place.
> 
> I don't understand.  rtable_walk() is always called with the
> KERNEL_LOCK() held, is this going to change?

rtable_walk may always be called with KERNEL_LOCK but rtable_insert and 
rtable_delete wont be because we want them to be able to work during packet 
processing, which is being moved out of big lock.

walk works by taking refcnts on tables while recursing. the refcnt changes 
arent atomic and therefore need to be serialised by the same lock used in the 
insert/delete paths.

> 
>>jmatthew@ has a
>> diff to serialise changes with a mutex, so those kernel lock calls
>> can be replaced with the mutex ones.
> 
> Why?  I assume the mutex will be used to serialize changes with the
> input path...  But taking/releasing the lock for each node doesn't
> sound clever to me.  When rtable_walk() is called you generally want
> the operation to complete on the whole table before allowing any other
> change.
> 
> The whole idea behind moving the EAGAIN check inside rtable_walk() is
> that we can grab the lock around art_walk() which would make sure the
> table has been completely updated before continuing.

taking and releasing the lock isnt particularly clever, but its the least worst 
thing i could come up with. ill try to explain how i got to this.

first, we're going with a mutex to serialise changes to the art structures 
because changes are going to be made in an interrupt path and mutexes are what 
we've got for that. as said above, we need to take the mutex to change the 
refcnts.

secontly, from what i can tell rtable_walk is used for two main things: to read 
the whole table (eg, to serialise it for netstat -nr to read), and to 
filter/mutate routes (eg, if we take an interface down we need to walk the 
rtable to take the associated routes down too).

the callback for dumping the table to userland does so using copyout(9), which 
may sleep, and holding a mutex over a sleep is not a Good Idea(tm). we could 
avoid that by allocating a temporary kernel buffer to have the rtable_walk 
callback copy in to, and then copying that out to userland outside the mutex. 
however, rtables can get large so allocating a bounce buffer may be unreliable 
on some systems, esp with limited kva space.

while we're talking about reads, thrashing the mutex isnt the only caveat. it 
is possible the rtable can change while the callback is running without the 
mutex held. the consequence of that is we wont get a strongly consistent view 
of the rtable. for example, you maybe be halfway through reading a table when 
route A is inserted in the first quarter, followed by an insertion of route B 
in the last quarter. in that situation your table read will show route B and 
not A, even though A occurred first. im reasonably sure that this is ok though. 
think of it as a relaxed memory model where writes can happen out of order with 
reads and we dont have any barriers.

anyway, the other problem with holding the mutex while running rtable_walk 
callbacks is the callbacks that filter entries in the table. those end up 
calling rtable_delete which in turn will try to acquire the mutex. holding the 
mutex for walk while calling those would end up with a deadlock.

an alternative to that would be to create locked and unlocked variants of 
rtable insert and delete and push the knowledge of the locking protocol out to 
the callers. that would mean filters would call the locked variants, and id 
argue that the read callbacks would then have to explicitly give up the lock 
for the reasons discussed above.

i hope this explains how i got to this diff.

> 
>> the idea is that art walk will traverse the tables under the lock.
>> that allows us to bump the refcount on tables, which means they'll
>> still be there when we unwined after descending into them. it gives
>> up the lock when it calls the per route callback. this is so the
>> callback can decide to update the table while looking at it. that
>> route reference is done via the srp api.
> 
> That said, I like where this is going :)

me too. itll be interesting to see how it scales.

> 
>> Index: art.c
>> ===
>> RCS file: /cvs/src/sys/net/art.c,v
>> retrieving revision 1.19
>> diff -u -p -r1.19 art.c
>> --- art.c14 Jun 2016 04:42:02 -  1.19
>> +++ art.c14 Jun 2016 12:36:25 -
>> @@ -78,10 +78,13 @@ struct art_node  *art_table_insert(struc
>>   int, struct art_node *);
>> struct art_node  *art_table_delete(struct art_root *, struct 
>> art_table *,
>> 

Re: fix iwm association problems

[Stefan Sperling]

On Mon, Jun 20, 2016 at 12:34:17PM +0200, Stefan Sperling wrote:
> I found that my 8260 iwm(4) device has trouble associating to my 5 GHz AP,
> which runs OpenBSD with athn(4) in hostap mode. Most of the time it won't
> even get a DHCP lease. Some frames it believes it has sent are not even
> visible on the air.
> 
> The iwm driver still has a copy of code from Linux that sends DTIM TSF
> information to the firmware. I believe this depends on Linux mac80211
> behaviour details and is bogus with our stack, and we should just let
> firmware handle TSF synchronization details by itself (and just look
> at those glories comments...)
> 
> Also, clear in_assoc when going down, as it effects early behaviour
> when coming up, before association (found by Imre).
> 
> I'm now getting much better results when switching between networks
> with the 8260. Doesn't cause problems on 7260 and 7265.
> 
> ok?

Sorry, the previous diff was missing a chunk and won't build.

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.88
diff -u -p -r1.88 if_iwm.c
--- if_iwm.c19 Jun 2016 12:05:25 -  1.88
+++ if_iwm.c20 Jun 2016 10:36:47 -
@@ -5723,58 +5723,14 @@ iwm_mvm_mac_ctxt_cmd_fill_sta(struct iwm
struct iwm_mac_data_sta *ctxt_sta, int force_assoc_off)
 {
struct ieee80211_node *ni = >in_ni;
-   unsigned dtim_period, dtim_count;
struct ieee80211com *ic = >sc_ic;
 
-   /* will this work? */
-   dtim_period = ic->ic_dtim_period;
-   dtim_count = ic->ic_dtim_count;
-   DPRINTF(("dtim %d %d\n", dtim_period, dtim_count));
-
-   /* We need the dtim_period to set the MAC as associated */
-   if (in->in_assoc && dtim_period && !force_assoc_off) {
-   uint64_t tsf;
-   uint32_t dtim_offs;
-
-   /*
-* The DTIM count counts down, so when it is N that means N
-* more beacon intervals happen until the DTIM TBTT. Therefore
-* add this to the current time. If that ends up being in the
-* future, the firmware will handle it.
-*
-* Also note that the system_timestamp (which we get here as
-* "sync_device_ts") and TSF timestamp aren't at exactly the
-* same offset in the frame -- the TSF is at the first symbol
-* of the TSF, the system timestamp is at signal acquisition
-* time. This means there's an offset between them of at most
-* a few hundred microseconds (24 * 8 bits + PLCP time gives
-* 384us in the longest case), this is currently not relevant
-* as the firmware wakes up around 2ms before the TBTT.
-*/
-   dtim_offs = dtim_count * ni->ni_intval;
-   /* convert TU to usecs */
-   dtim_offs *= 1024;
-
-   /* XXX: byte order? */
-   memcpy(, ni->ni_tstamp, sizeof(tsf));
-
-   ctxt_sta->dtim_tsf = htole64(tsf + dtim_offs);
-   ctxt_sta->dtim_time = htole64(ni->ni_rstamp + dtim_offs);
-
-   DPRINTF(("DTIM TBTT is 0x%llx/0x%x, offset %d\n",
-   (long long)le64toh(ctxt_sta->dtim_tsf),
-   le32toh(ctxt_sta->dtim_time), dtim_offs));
-
-   ctxt_sta->is_assoc = htole32(1);
-   } else {
-   ctxt_sta->is_assoc = htole32(0);
-   }
-
+   ctxt_sta->is_assoc = htole32(0);
ctxt_sta->bi = htole32(ni->ni_intval);
ctxt_sta->bi_reciprocal = htole32(iwm_mvm_reciprocal(ni->ni_intval));
-   ctxt_sta->dtim_interval = htole32(ni->ni_intval * dtim_period);
+   ctxt_sta->dtim_interval = htole32(ni->ni_intval * ic->ic_dtim_period);
ctxt_sta->dtim_reciprocal =
-   htole32(iwm_mvm_reciprocal(ni->ni_intval * dtim_period));
+   htole32(iwm_mvm_reciprocal(ni->ni_intval * ic->ic_dtim_period));
 
/* 10 = CONN_MAX_LISTEN_INTERVAL */
ctxt_sta->listen_interval = htole32(10);
@@ -6877,6 +6833,7 @@ iwm_stop(struct ifnet *ifp, int disable)
 {
struct iwm_softc *sc = ifp->if_softc;
struct ieee80211com *ic = >sc_ic;
+   struct iwm_node *in = (void *)ic->ic_bss;
 
sc->sc_flags &= ~IWM_FLAG_HW_INITED;
sc->sc_flags |= IWM_FLAG_STOPPED;
@@ -6884,6 +6841,9 @@ iwm_stop(struct ifnet *ifp, int disable)
ic->ic_scan_lock = IEEE80211_SCAN_UNLOCKED;
ifp->if_flags &= ~IFF_RUNNING;
ifq_clr_oactive(>if_snd);
+
+   in->in_phyctxt = NULL;
+   in->in_assoc = 0;
 
task_del(systq, >init_task);
task_del(sc->sc_nswq, >newstate_task);

fix iwm association problems

[Stefan Sperling]

I found that my 8260 iwm(4) device has trouble associating to my 5 GHz AP,
which runs OpenBSD with athn(4) in hostap mode. Most of the time it won't
even get a DHCP lease. Some frames it believes it has sent are not even
visible on the air.

The iwm driver still has a copy of code from Linux that sends DTIM TSF
information to the firmware. I believe this depends on Linux mac80211
behaviour details and is bogus with our stack, and we should just let
firmware handle TSF synchronization details by itself (and just look
at those glories comments...)

Also, clear in_assoc when going down, as it effects early behaviour
when coming up, before association (found by Imre).

I'm now getting much better results when switching between networks
with the 8260. Doesn't cause problems on 7260 and 7265.

ok?

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.88
diff -u -p -r1.88 if_iwm.c
--- if_iwm.c19 Jun 2016 12:05:25 -  1.88
+++ if_iwm.c20 Jun 2016 10:15:35 -
@@ -5723,58 +5723,14 @@ iwm_mvm_mac_ctxt_cmd_fill_sta(struct iwm
struct iwm_mac_data_sta *ctxt_sta, int force_assoc_off)
 {
struct ieee80211_node *ni = >in_ni;
-   unsigned dtim_period, dtim_count;
struct ieee80211com *ic = >sc_ic;
 
-   /* will this work? */
-   dtim_period = ic->ic_dtim_period;
-   dtim_count = ic->ic_dtim_count;
-   DPRINTF(("dtim %d %d\n", dtim_period, dtim_count));
-
-   /* We need the dtim_period to set the MAC as associated */
-   if (in->in_assoc && dtim_period && !force_assoc_off) {
-   uint64_t tsf;
-   uint32_t dtim_offs;
-
-   /*
-* The DTIM count counts down, so when it is N that means N
-* more beacon intervals happen until the DTIM TBTT. Therefore
-* add this to the current time. If that ends up being in the
-* future, the firmware will handle it.
-*
-* Also note that the system_timestamp (which we get here as
-* "sync_device_ts") and TSF timestamp aren't at exactly the
-* same offset in the frame -- the TSF is at the first symbol
-* of the TSF, the system timestamp is at signal acquisition
-* time. This means there's an offset between them of at most
-* a few hundred microseconds (24 * 8 bits + PLCP time gives
-* 384us in the longest case), this is currently not relevant
-* as the firmware wakes up around 2ms before the TBTT.
-*/
-   dtim_offs = dtim_count * ni->ni_intval;
-   /* convert TU to usecs */
-   dtim_offs *= 1024;
-
-   /* XXX: byte order? */
-   memcpy(, ni->ni_tstamp, sizeof(tsf));
-
-   ctxt_sta->dtim_tsf = htole64(tsf + dtim_offs);
-   ctxt_sta->dtim_time = htole64(ni->ni_rstamp + dtim_offs);
-
-   DPRINTF(("DTIM TBTT is 0x%llx/0x%x, offset %d\n",
-   (long long)le64toh(ctxt_sta->dtim_tsf),
-   le32toh(ctxt_sta->dtim_time), dtim_offs));
-
-   ctxt_sta->is_assoc = htole32(1);
-   } else {
-   ctxt_sta->is_assoc = htole32(0);
-   }
-
+   ctxt_sta->is_assoc = htole32(0);
ctxt_sta->bi = htole32(ni->ni_intval);
ctxt_sta->bi_reciprocal = htole32(iwm_mvm_reciprocal(ni->ni_intval));
-   ctxt_sta->dtim_interval = htole32(ni->ni_intval * dtim_period);
+   ctxt_sta->dtim_interval = htole32(ni->ni_intval * ic->ic_dtim_period);
ctxt_sta->dtim_reciprocal =
-   htole32(iwm_mvm_reciprocal(ni->ni_intval * dtim_period));
+   htole32(iwm_mvm_reciprocal(ni->ni_intval * ic->ic_dtim_period));
 
/* 10 = CONN_MAX_LISTEN_INTERVAL */
ctxt_sta->listen_interval = htole32(10);
@@ -6884,6 +6840,9 @@ iwm_stop(struct ifnet *ifp, int disable)
ic->ic_scan_lock = IEEE80211_SCAN_UNLOCKED;
ifp->if_flags &= ~IFF_RUNNING;
ifq_clr_oactive(>if_snd);
+
+   in->in_phyctxt = NULL;
+   in->in_assoc = 0;
 
task_del(systq, >init_task);
task_del(sc->sc_nswq, >newstate_task);

Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

[Brent Cook]

Hi,

This is a patch from Cesar Pereida, removing support for
DSA_FLAG_NO_EXP_CONSTTIME by making DSA always operate in constant time.

See https://github.com/libressl-portable/openbsd/pull/61 for more
details.

ok?

diff --git a/src/lib/libssl/src/crypto/dsa/dsa.h 
b/src/lib/libssl/src/crypto/dsa/dsa.h
index 909096d..d2d1d5f 100644
--- a/src/lib/libssl/src/crypto/dsa/dsa.h
+++ b/src/lib/libssl/src/crypto/dsa/dsa.h
@@ -89,12 +89,8 @@
 #endif

 #define DSA_FLAG_CACHE_MONT_P  0x01
-#define DSA_FLAG_NO_EXP_CONSTTIME   0x02 /* new with 0.9.7h; the built-in 
DSA
-  * implementation now uses 
constant time
-  * modular exponentiation for 
secret exponents
-  * by default. This flag causes 
the
-  * faster variable sliding window 
method to
-  * be used for all exponents.
+#define DSA_FLAG_NO_EXP_CONSTTIME   0x00 /* Does nothing. Previously this 
switched off
+  * constant time behaviour.
   */

 /* If this flag is set the DSA method is FIPS compliant and can be used
diff --git a/src/lib/libssl/src/crypto/dsa/dsa_key.c 
b/src/lib/libssl/src/crypto/dsa/dsa_key.c
index 2968fa2..e01bacb 100644
--- a/src/lib/libssl/src/crypto/dsa/dsa_key.c
+++ b/src/lib/libssl/src/crypto/dsa/dsa_key.c
@@ -104,18 +104,18 @@ dsa_builtin_keygen(DSA *dsa)
pub_key=dsa->pub_key;

{
-   BIGNUM local_prk;
-   BIGNUM *prk;
+   BIGNUM *prk = BN_new();

-   if ((dsa->flags & DSA_FLAG_NO_EXP_CONSTTIME) == 0) {
-   BN_init(_prk);
-   prk = _prk;
-   BN_with_flags(prk, priv_key, BN_FLG_CONSTTIME);
-   } else
-   prk = priv_key;
+   if (prk == NULL)
+   goto err;
+
+   BN_with_flags(prk, priv_key, BN_FLG_CONSTTIME);

-   if (!BN_mod_exp(pub_key, dsa->g, prk, dsa->p, ctx))
+   if (!BN_mod_exp(pub_key, dsa->g, prk, dsa->p, ctx)) {
+   BN_free(prk);
goto err;
+   }
+   BN_free(prk);
}

dsa->priv_key = priv_key;
@@ -130,4 +130,4 @@ err:
BN_CTX_free(ctx);
return ok;
 }
-#endif
+#endif
\ No newline at end of file
diff --git a/src/lib/libssl/src/crypto/dsa/dsa_ossl.c 
b/src/lib/libssl/src/crypto/dsa/dsa_ossl.c
index 726e6c7..4a3b417 100644
--- a/src/lib/libssl/src/crypto/dsa/dsa_ossl.c
+++ b/src/lib/libssl/src/crypto/dsa/dsa_ossl.c
@@ -83,46 +83,6 @@ static DSA_METHOD openssl_dsa_meth = {
.finish = dsa_finish
 };

-/*
- * These macro wrappers replace attempts to use the dsa_mod_exp() and
- * bn_mod_exp() handlers in the DSA_METHOD structure. We avoid the problem of
- * having a the macro work as an expression by bundling an "err_instr". So;
- *
- * if (!dsa->meth->bn_mod_exp(dsa, r,dsa->g,,dsa->p,ctx,
- * dsa->method_mont_p)) goto err;
- *
- * can be replaced by;
- *
- * DSA_BN_MOD_EXP(goto err, dsa, r, dsa->g, , dsa->p, ctx,
- * dsa->method_mont_p);
- */
-
-#define DSA_MOD_EXP(err_instr,dsa,rr,a1,p1,a2,p2,m,ctx,in_mont) \
-do { \
-   int _tmp_res53; \
-   if ((dsa)->meth->dsa_mod_exp) \
-   _tmp_res53 = (dsa)->meth->dsa_mod_exp((dsa), (rr), \
-   (a1), (p1), (a2), (p2), (m), (ctx), (in_mont)); \
-   else \
-   _tmp_res53 = BN_mod_exp2_mont((rr), (a1), \
-   (p1), (a2), (p2), (m), (ctx), (in_mont)); \
-   if (!_tmp_res53) \
-   err_instr; \
-} while(0)
-
-#define DSA_BN_MOD_EXP(err_instr,dsa,r,a,p,m,ctx,m_ctx) \
-do { \
-   int _tmp_res53; \
-   if ((dsa)->meth->bn_mod_exp) \
-   _tmp_res53 = (dsa)->meth->bn_mod_exp((dsa), (r), \
-   (a), (p), (m), (ctx), (m_ctx)); \
-   else \
-   _tmp_res53 = BN_mod_exp_mont((r), (a), (p), (m), \
-   (ctx), (m_ctx)); \
-   if (!_tmp_res53) \
-   err_instr; \
-} while(0)
-
 const DSA_METHOD *
 DSA_OpenSSL(void)
 {
@@ -222,7 +182,7 @@ static int
 dsa_sign_setup(DSA *dsa, BN_CTX *ctx_in, BIGNUM **kinvp, BIGNUM **rp)
 {
BN_CTX *ctx;
-   BIGNUM k, kq, *K, *kinv = NULL, *r = NULL;
+   BIGNUM k, *kinv = NULL, *r = NULL;
int ret = 0;

if (!dsa->p || !dsa->q || !dsa->g) {
@@ -231,7 +191,6 @@ dsa_sign_setup(DSA *dsa, BN_CTX *ctx_in, BIGNUM **kinvp, 
BIGNUM **rp)
}

BN_init();
-   BN_init();

if (ctx_in == NULL) {
if ((ctx = BN_CTX_new()) == NULL)
@@ -248,6 +207,8 @@ dsa_sign_setup(DSA *dsa, BN_CTX *ctx_in, BIGNUM **kinvp, 
BIGNUM **rp)
goto err;
} while (BN_is_zero());

+ 

iwm tx rate fixes

[Stefan Sperling]

iwm(4) should always send multicast frames at the lowest rate.
We probably got lucky and frames were still sent at a compatible rate
via the LQ retry table. But it is better to have an "IS_MULTICAST" check
like other drivers do.

On 5GHz, iwm(4) passes the wrong rate to BPF. This is a cosmetic issue.
E.g. "tcpdump -n -i iwm0 -y IEEE802_11 -v" will show "1 Mbit/s" for
multicast frames, which is wrong (should be 6Mbit/s on 5Ghz).

In iwm_setrates(), don't bother looping over CCK rates if we're on a 5 GHz
channel. CCK rates aren't valid on 5GHz channels. We didn't add them, so
this is not a bug, but we might as well exit the loop early.

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.88
diff -u -p -r1.88 if_iwm.c
--- if_iwm.c19 Jun 2016 12:05:25 -  1.88
+++ if_iwm.c20 Jun 2016 07:44:58 -
@@ -4376,7 +4376,8 @@ iwm_tx_fill_cmd(struct iwm_softc *sc, st
tx->rts_retry_limit = IWM_RTS_DFAULT_RETRY_LIMIT;
tx->data_retry_limit = IWM_DEFAULT_TX_RETRY;
 
-   if (type != IEEE80211_FC0_TYPE_DATA) {
+   if (IEEE80211_IS_MULTICAST(wh->i_addr1) ||
+   type != IEEE80211_FC0_TYPE_DATA) {
/* for non-data, use the lowest supported rate */
ridx = (IEEE80211_IS_CHAN_5GHZ(ni->ni_chan)) ?
IWM_RIDX_OFDM : IWM_RIDX_CCK;
@@ -4393,7 +4394,8 @@ iwm_tx_fill_cmd(struct iwm_softc *sc, st
ridx = iwm_mcs2ridx[ni->ni_txmcs];
return _rates[ridx];
}
-   ridx = 0;
+   ridx = (IEEE80211_IS_CHAN_5GHZ(ni->ni_chan)) ?
+   IWM_RIDX_OFDM : IWM_RIDX_CCK;
for (i = 0; i < nrates; i++) {
if (iwm_rates[i].rate == (ni->ni_txrate &
IEEE80211_RATE_VAL)) {
@@ -6124,7 +6126,7 @@ iwm_setrates(struct iwm_node *in)
struct iwm_softc *sc = IC2IFP(ic)->if_softc;
struct iwm_lq_cmd *lq = >in_lq;
struct ieee80211_rateset *rs = >ni_rates;
-   int i, ridx, j, tab = 0;
+   int i, ridx, ridx_min, j, tab = 0;
struct iwm_host_cmd cmd = {
.id = IWM_LQ_CMD,
.len = { sizeof(in->in_lq), },
@@ -6148,7 +6150,9 @@ iwm_setrates(struct iwm_node *in)
 * legacy/HT are assumed to be marked with an 'invalid' PLCP value.
 */
j = 0;
-   for (ridx = IWM_RIDX_MAX; ridx >= 0; ridx--) {
+   ridx_min = (IEEE80211_IS_CHAN_5GHZ(ni->ni_chan)) ?
+   IWM_RIDX_OFDM : IWM_RIDX_CCK;
+   for (ridx = IWM_RIDX_MAX; ridx >= ridx_min; ridx--) {
if (j >= nitems(lq->rs_table))
break;
tab = 0;

Re: umb(4) man page tweaks

[Gerhard Roth]

On Mon, 20 Jun 2016 08:50:05 +0200 Gerhard Roth  wrote:
> Hallo Stefan,
> 
> danke, dass Du Dich darum kuemmerst.
> 
> ok gerhard@

Sorry for the German. This mail was intended to go to Stefan only and not
the mailing list. My mistake.

Gerhard

> 
> 
> On Sun, 19 Jun 2016 15:03:13 +0200 Stefan Sperling  wrote:
> > Some information in the umb(4) man page seems to be outdated (IPV4 gateway
> > handling), or doesn't really belong in a man page ("please hack the driver
> > to add a device to a blacklist").
> > 
> > Also try to shorten the page a bit and move information about troublesome
> > devices to CAVEATS.
> > 
> > Index: umb.4
> > ===
> > RCS file: /cvs/src/share/man/man4/umb.4,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 umb.4
> > --- umb.4   15 Jun 2016 19:39:34 -  1.1
> > +++ umb.4   19 Jun 2016 12:58:24 -
> > @@ -26,44 +26,27 @@
> >  The
> >  .Nm
> >  driver provides support for USB MBIM devices.
> > -Those devices establish connections via celluar networks such as
> > -GPRS, UMTS, and LTE.
> >  .Pp
> > -The
> > -.Nm
> > -device appears as a regular point-to-point network interface,
> > +MBIM devices establish connections via cellular networks such as
> > +GPRS, UMTS, and LTE.
> > +They appear as a regular point-to-point network interface,
> >  transporting raw IP frames.
> >  .Pp
> >  Required configuration parameters like PIN and APN have to be set
> > -via
> > +with
> >  .Xr ifconfig 8 .
> >  Once the SIM card has been unlocked with the correct PIN, it
> > -will remain in this state until the device is power-cycled.
> > +will remain in this state until the MBIM device is power-cycled.
> >  In case the device is connected to an "always-on" USB port,
> > -it is possible to connect to a provider without entering the
> > -PIN again even afer a reboot of the system.
> > -.Pp
> > -If a default gateway route is configured for the
> > -.Nm
> > -network interface, the driver will modify the destination IP address
> > -dynamically, according to the information sent by the network provider.
> > +it may be possible to connect to a provider without entering the
> > +PIN again even if the system was rebooted.
> >  .Sh HARDWARE
> > -The following devices are known to be supported by the
> > -.Nm
> > -driver:
> > +The following devices should work:
> >  .Pp
> >  .Bl -tag -width Ds -offset indent -compact
> >  .It Tn Sierra Wireless EM8805
> >  .It Tn Sierra Wireless MC8305
> >  .El
> > -.Pp
> > -There are probably a lot more devices that also work flawlessly.
> > -If some devices fail to provide a confirming MBIM implementation,
> > -their vendor and product IDs should be added to the driver's blacklist
> > -manually.
> > -Since most devices offer multiple interfaces, blacklisted ones will
> > -probably be attached by some other driver, such as
> > -.Xr umsm 4 .
> >  .Sh SEE ALSO
> >  .Xr intro 4 ,
> >  .Xr netintro 4 ,
> > @@ -78,4 +61,8 @@ probably be attached by some other drive
> >  .Sh CAVEATS
> >  The
> >  .Nm
> > -driver currently does not support IPv6 addresses.
> > +driver does not support IPv6.
> > +.Pp
> > +Devices which fail to provide a confirming MBIM implementation will
> > +probably be attached by some other driver, such as
> > +.Xr umsm 4 .

Re: umb(4) man page tweaks

[Gerhard Roth]

Hallo Stefan,

danke, dass Du Dich darum kuemmerst.

ok gerhard@


On Sun, 19 Jun 2016 15:03:13 +0200 Stefan Sperling  wrote:
> Some information in the umb(4) man page seems to be outdated (IPV4 gateway
> handling), or doesn't really belong in a man page ("please hack the driver
> to add a device to a blacklist").
> 
> Also try to shorten the page a bit and move information about troublesome
> devices to CAVEATS.
> 
> Index: umb.4
> ===
> RCS file: /cvs/src/share/man/man4/umb.4,v
> retrieving revision 1.1
> diff -u -p -r1.1 umb.4
> --- umb.4 15 Jun 2016 19:39:34 -  1.1
> +++ umb.4 19 Jun 2016 12:58:24 -
> @@ -26,44 +26,27 @@
>  The
>  .Nm
>  driver provides support for USB MBIM devices.
> -Those devices establish connections via celluar networks such as
> -GPRS, UMTS, and LTE.
>  .Pp
> -The
> -.Nm
> -device appears as a regular point-to-point network interface,
> +MBIM devices establish connections via cellular networks such as
> +GPRS, UMTS, and LTE.
> +They appear as a regular point-to-point network interface,
>  transporting raw IP frames.
>  .Pp
>  Required configuration parameters like PIN and APN have to be set
> -via
> +with
>  .Xr ifconfig 8 .
>  Once the SIM card has been unlocked with the correct PIN, it
> -will remain in this state until the device is power-cycled.
> +will remain in this state until the MBIM device is power-cycled.
>  In case the device is connected to an "always-on" USB port,
> -it is possible to connect to a provider without entering the
> -PIN again even afer a reboot of the system.
> -.Pp
> -If a default gateway route is configured for the
> -.Nm
> -network interface, the driver will modify the destination IP address
> -dynamically, according to the information sent by the network provider.
> +it may be possible to connect to a provider without entering the
> +PIN again even if the system was rebooted.
>  .Sh HARDWARE
> -The following devices are known to be supported by the
> -.Nm
> -driver:
> +The following devices should work:
>  .Pp
>  .Bl -tag -width Ds -offset indent -compact
>  .It Tn Sierra Wireless EM8805
>  .It Tn Sierra Wireless MC8305
>  .El
> -.Pp
> -There are probably a lot more devices that also work flawlessly.
> -If some devices fail to provide a confirming MBIM implementation,
> -their vendor and product IDs should be added to the driver's blacklist
> -manually.
> -Since most devices offer multiple interfaces, blacklisted ones will
> -probably be attached by some other driver, such as
> -.Xr umsm 4 .
>  .Sh SEE ALSO
>  .Xr intro 4 ,
>  .Xr netintro 4 ,
> @@ -78,4 +61,8 @@ probably be attached by some other drive
>  .Sh CAVEATS
>  The
>  .Nm
> -driver currently does not support IPv6 addresses.
> +driver does not support IPv6.
> +.Pp
> +Devices which fail to provide a confirming MBIM implementation will
> +probably be attached by some other driver, such as
> +.Xr umsm 4 .

Re: simpler audioctl

[Alexandre Ratchov]

On Sun, Jun 19, 2016 at 05:56:38PM +0200, Sebastien Marie wrote:
> 
> Just one point about the man page:
> 
>  Test if the hardware supports 24-bit encoding and 44100Hz sample rate:
> 
>$ audioctl -f /dev/audio0 encoding=s24 rate=44100
> 
> "Test" is somehow incorrect as if the device supports it, the values
> will be changed: so it is more than just testing.

Correct, what about the following:

Request the hardware to use signed 24-bit samples and
44100Hz sample rate:

$ audioctl -f /dev/audio0 encoding=s24 rate=44100

Note the use of /dev/audio0 to force negotiation with the
hardware.  If above parameters are not supported by the
hardware, then supported ones will be selected instead.