RFC 5071 DHCP options

2015-08-28 Thread Nathanael Rensen
I use dhcpd(8) to boot some boxes with PXELINUX. The numbered options work
but dhcpd.conf(5) is easier to maintain with names. These options are
defined in RFC 5071.

Nathanael

Index: sbin/dhclient/tables.c
===
RCS file: /cvs/src/sbin/dhclient/tables.c,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 tables.c
--- sbin/dhclient/tables.c  21 Jan 2014 03:07:50 -  1.18
+++ sbin/dhclient/tables.c  27 Aug 2015 09:13:26 -
@@ -269,9 +269,9 @@ const struct option dhcp_options[256] = 
/* 206 */ { "option-206", "X" },
/* 207 */ { "option-207", "X" },
/* 208 */ { "option-208", "X" },
-   /* 209 */ { "option-209", "X" },
-   /* 210 */ { "option-210", "X" },
-   /* 211 */ { "option-211", "X" },
+   /* 209 */ { "config-file", "t" },
+   /* 210 */ { "path-prefix", "t" },
+   /* 211 */ { "reboot-time", "L" },
/* 212 */ { "option-212", "X" },
/* 213 */ { "option-213", "X" },
/* 214 */ { "option-214", "X" },
Index: usr.sbin/dhcpd/dhcp-options.5
===
RCS file: /cvs/src/usr.sbin/dhcpd/dhcp-options.5,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 dhcp-options.5
--- usr.sbin/dhcpd/dhcp-options.5   2 Jun 2015 16:02:45 -   1.21
+++ usr.sbin/dhcpd/dhcp-options.5   27 Aug 2015 09:13:29 -
@@ -176,6 +176,10 @@ This option does the same as
 .Ic classless-static-routes ,
 but uses option code 249 instead of 121,
 since Windows XP and Windows Server 2003 ignore option 121.
+.It Ic option config-file Ar string ;
+This option specifies the configuration file for the PXELINUX boot loader.
+This is typically used in conjuction with the path-prefix option.
+See RFC 5071 for details.
 .It Ic option cookie-servers Ar ip-address Oo , Ar ip-address ... Oc ;
 The
 .Ic cookie-servers
@@ -453,6 +457,11 @@ Path MTU Discovery as defined in RFC 119
 The table is formatted as a list of 16-bit unsigned integers,
 ordered from smallest to largest.
 The minimum MTU value cannot be smaller than 68.
+.It Ic option path-prefix Ar string ;
+This option specifies the path prefix for a PXELINUX boot loader
+configuration file.
+This is typically used in conjuction with the config-file option.
+See RFC 5071 for details.
 .It Ic option perform-mask-discovery Ar flag ;
 This option specifies whether or not the client should perform subnet mask
 discovery using ICMP.
@@ -472,6 +481,10 @@ The
 .Ic pop-server
 option specifies a list of POP3 servers available to the client.
 Servers should be listed in order of preference.
+.It Ic option reboot-time Ar uint32 ;
+This option determines how long the PXELINUX boot loader waits to connect
+to a TFTP server before rebooting.
+See RFC 5071 for details.
 .It Ic option relay-agent-information Ar string ;
 This is a "container" option for specific agent-supplied sub-options.
 See RFC 3046 for details.
Index: usr.sbin/dhcpd/tables.c
===
RCS file: /cvs/src/usr.sbin/dhcpd/tables.c,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 tables.c
--- usr.sbin/dhcpd/tables.c 27 Jun 2015 14:29:39 -  1.11
+++ usr.sbin/dhcpd/tables.c 27 Aug 2015 09:13:29 -
@@ -271,9 +271,9 @@ struct option dhcp_options[256] = {
{ "option-206", "X",&dhcp_universe, 206 },
{ "option-207", "X",&dhcp_universe, 207 },
{ "option-208", "X",&dhcp_universe, 208 },
-   { "option-209", "X",&dhcp_universe, 209 },
-   { "option-210", "X",&dhcp_universe, 210 },
-   { "option-211", "X",&dhcp_universe, 211 },
+   { "config-file", "t",   &dhcp_universe, 209 },
+   { "path-prefix", "t",   &dhcp_universe, 210 },
+   { "reboot-time", "L",   &dhcp_universe, 211 },
{ "option-212", "X",&dhcp_universe, 212 },
{ "option-213", "X",&dhcp_universe, 213 },
{ "option-214", "X",&dhcp_universe, 214 },



Should PIE be mentioned in security.html?

2015-08-28 Thread Rob Pierce
Not sure about its location in the list.

Index: security.html
===
RCS file: /cvs/www/security.html,v
retrieving revision 1.422
diff -u -p -r1.422 security.html
--- security.html   2 Jul 2015 05:49:04 -   1.422
+++ security.html   29 Aug 2015 03:59:35 -
@@ -158,6 +158,7 @@ written somewhere, but perhaps not taken
   Chroot jailing
   New uids
   ProPolice
+  Position-independent executables (PIE)
   ... and others
 
 



synaptics touchpads: w mode and resolution

2015-08-28 Thread Ulf Brosziewski


Some weeks ago a change was made in pms to support Synaptics touchpads
that don't provide W mode. I assume that only fairly old models are
concerned, and that the variant in the patch below is more accurate. It
only fakes W values where necessary.

The patch contains a second change, a check whether the resolution query
was successful. According to the "Synaptics PS/2 Interfacing Guide", bit
7 of the second response byte will be set in case of success. It seems
that if it isn't set, the other bytes are garbage or have an unknown
meaning.

Unfortunately I only have that old model - with firmware 4.1 - for
testing. Could someone confirm that newer models aren't affected by
these changes?


Index: dev/pckbc/pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.65
diff -u -p -r1.65 pms.c
--- dev/pckbc/pms.c 23 Aug 2015 04:45:23 -  1.65
+++ dev/pckbc/pms.c 28 Aug 2015 18:04:45 -
@@ -949,8 +949,10 @@ synaptics_get_hwinfo(struct pms_softc *s
return (-1);
}

-   syn->res_x = SYNAPTICS_RESOLUTION_X(syn->resolution);
-   syn->res_y = SYNAPTICS_RESOLUTION_Y(syn->resolution);
+   if (syn->resolution & 0x8000) {
+   syn->res_x = SYNAPTICS_RESOLUTION_X(syn->resolution);
+   syn->res_y = SYNAPTICS_RESOLUTION_Y(syn->resolution);
+   }
syn->min_x = SYNAPTICS_XMIN_BEZEL;
syn->min_y = SYNAPTICS_YMIN_BEZEL;
syn->max_x = (syn->dimension) ?
@@ -1163,30 +1165,21 @@ pms_proc_synaptics(struct pms_softc *sc)

w = ((sc->packet[0] & 0x30) >> 2) | ((sc->packet[0] & 0x04) >> 1) |
((sc->packet[3] & 0x04) >> 2);
+   z = sc->packet[2];

-   /*
-* Conform to the encoding understood by
-* /usr/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c
-*/
-   switch (w) {
-   case 0:
-   /* fingerwidth 5, numfingers 2 */
-   break;
-   case 1:
-   /* fingerwidth 5, numfingers 3 */
-   break;
-   case 5:
-   /* fingerwidth 5, numfingers 1 */
-   break;
-   case 4:
-   case 8:
-   /* fingerwidth 4, numfingers 1 */
-   w = 4;
-   break;
-   default:
-   break;
+   if ((syn->capabilities & SYNAPTICS_CAP_EXTENDED) == 0) {
+   /*
+* Emulate W mode for models that don't provide it. Bit 3
+* of the w-input signals a touch ("finger"), Bit 2 and
+* the "gesture" bits 1-0 can be ignored.
+*/
+   if (w & 8)
+   w = 4;
+   else
+   z = w = 0;
}

+
if ((syn->capabilities & SYNAPTICS_CAP_PASSTHROUGH) && w == 3) {
synaptics_sec_proc(sc);
return;
@@ -1203,7 +1196,6 @@ pms_proc_synaptics(struct pms_softc *sc)
sc->packet[4];
y = ((sc->packet[3] & 0x20) << 7) | ((sc->packet[1] & 0xf0) << 4) |
sc->packet[5];
-   z = sc->packet[2];

buttons = ((sc->packet[0] & sc->packet[3]) & 0x01) ?
WSMOUSE_BUTTON(1) : 0;



Re: squid 3.5/trunk and SSLv3 removal

2015-08-28 Thread Joel Sing
On Friday 28 August 2015 13:19:17 Stuart Henderson wrote:
> Any suggestions as to what might be needed here, can the SSLv3_method
> just be replaced with SSLv23_method?

Yes, that should be fine. The code is parsing an SSLv3/TLS client hello message 
and it is then mapping the ciphersuites to libssl ciphers. I'm guessing the 
reason for using SSLv3_method() here is to avoid picking up SSLv2 ciphers. Fun 
fact - due to what is effectively a design flaw, the ciphers returned from 
SSLv3_method() include TLS1.0 and TLS1.2 ciphers...

> http://bazaar.launchpad.net/~squid/squid/3.5/view/head:/src/ssl/bio.cc#L1009
> |   ciphers += 2;
> |   if (ciphersLen) {
> |   
> |   const SSL_METHOD *method = SSLv3_method();
> 
>
> 
> |   const int cs = method->put_cipher_by_char(NULL, NULL);
> |   assert(cs > 0);
> |   for (size_t i = 0; i < ciphersLen; i += cs) {
> |   
> |   const SSL_CIPHER *c = method->get_cipher_by_char((ciphers +
> |   i));
> |   if (c != NULL) {
> |   
> |   if (!clientRequestedCiphers.empty())
> |   
> |   clientRequestedCiphers.append(":");
> |   
> |   clientRequestedCiphers.append(c->name);
> |   
> |   } else
> |   
> |   unknownCiphers = true;
> |   
> |   }
> |   
> |   }
> |   debugs(83, 7, "Ciphers requested by client: " <<
> |   clientRequestedCiphers);



Re: syslogd host matches ip

2015-08-28 Thread Alexander Bluhm
On Fri, Aug 28, 2015 at 06:11:02PM +0200, Alexander Bluhm wrote:
> The +host feature allows to select log messages from a specific
> host.  Normally syslogd does a reverse lookup on the sender's
> address.  If that fails or if syslogd has been started with the -n
> option, the +host is matched with the IP.  Unfortunatelty IP addresses
> consist of characters that are not allowed in syslog.conf.  So take
> the list of valid characters from FreeBSD.

Add _ to the list to help people with broken hostnames.
Suggested by sven falempin.

ok?

bluhm

Index: usr.sbin/syslogd/syslogd.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.179
diff -u -p -r1.179 syslogd.c
--- usr.sbin/syslogd/syslogd.c  27 Aug 2015 17:53:35 -  1.179
+++ usr.sbin/syslogd/syslogd.c  28 Aug 2015 17:48:16 -
@@ -2053,12 +2053,14 @@ init(void)
continue;
}
for (i = 0; i < NAME_MAX; i++) {
-   if (!isalnum((unsigned char)p[i]) &&
-   p[i] != '-' && p[i] != '+')
+   if (!isalnum((unsigned char)*p) &&
+   *p != '-' && *p != '+' && *p != '.' &&
+   *p != ',' && *p != ':' && *p != '%' &&
+   *p != '_')
break;
-   hostblock[i] = p[i];
+   hostblock[i] = *p++;
}
-   hostblock[i] = 0;
+   hostblock[i] = '\0';
continue;
}
 



LibreSSL 2.2.3 Prerelease available for testing

2015-08-28 Thread Brent Cook
We have put together a prerelease of LibreSSL 2.2.3. This release
primarily targets a bug that causes connections with some SSL clients
to fail during the initial handshake. Preliminary release notes and a
tarball are available at the following link:

https://github.com/libressl-portable/portable/releases/tag/v2.2.3



syslogd host matches ip

2015-08-28 Thread Alexander Bluhm
Hi,

The +host feature allows to select log messages from a specific
host.  Normally syslogd does a reverse lookup on the sender's
address.  If that fails or if syslogd has been started with the -n
option, the +host is matched with the IP.  Unfortunatelty IP addresses
consist of characters that are not allowed in syslog.conf.  So take
the list of valid characters from FreeBSD.

ok?

bluhm

Index: usr.sbin/syslogd/syslogd.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.179
diff -u -p -r1.179 syslogd.c
--- usr.sbin/syslogd/syslogd.c  27 Aug 2015 17:53:35 -  1.179
+++ usr.sbin/syslogd/syslogd.c  28 Aug 2015 16:07:43 -
@@ -2053,12 +2053,13 @@ init(void)
continue;
}
for (i = 0; i < NAME_MAX; i++) {
-   if (!isalnum((unsigned char)p[i]) &&
-   p[i] != '-' && p[i] != '+')
+   if (!isalnum((unsigned char)*p) &&
+   *p != '-' && *p != '+' && *p != '.' &&
+   *p != ',' && *p != ':' && *p != '%')
break;
-   hostblock[i] = p[i];
+   hostblock[i] = *p++;
}
-   hostblock[i] = 0;
+   hostblock[i] = '\0';
continue;
}
 



Re: readelf on mips64

2015-08-28 Thread Visa Hankala
On Fri, Aug 28, 2015 at 12:00:41PM +0200, Mark Kettenis wrote:
> As Theo and I noticed yesterday:
> 
>   $ readelf -a /usr/lib/libc.a
>   readelf: Error: /usr/lib/libc.a: invalid archive string table offset 0
> 
> Turns out that on mips64 binutils creates IRIX-style "64-bit" archives
> which allegedly can be larger than 4GB.  The difference is apparently
> in the archive map where offsets are 64-bit instead of 32-bit.  Since
> readelf simply skips over the map and reads the archive members
> sequentially all we have to do is recognize "/SYM64/" as a valid
> header and skip over it.
> 
> ok?

ok visa@

> Index: readelf.c
> ===
> RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/binutils/readelf.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 readelf.c
> --- readelf.c 25 May 2015 14:56:27 -  1.6
> +++ readelf.c 28 Aug 2015 09:55:35 -
> @@ -9121,7 +9121,8 @@ process_archive (char *file_name, FILE *
>return 1;
>  }
>  
> -  if (memcmp (arhdr.ar_name, "/   ", 16) == 0)
> +  if (memcmp (arhdr.ar_name, "/   ", 16) == 0
> +  || memcmp (arhdr.ar_name, "/SYM64/ ", 16) == 0)
>  {
>/* This is the archive symbol table.  Skip it.
>FIXME: We should have an option to dump it.  */
> 



Re: diff - more satosin/sintosa

2015-08-28 Thread David Hill
3rd update.

Thanks to Kent for testing. 

===
RCS file: /cvs/src/sys/net/if_gif.c,v
retrieving revision 1.77
diff -u -p -r1.77 if_gif.c
--- sys/net/if_gif.c17 Jul 2015 18:05:59 -  1.77
+++ sys/net/if_gif.c28 Aug 2015 13:06:21 -
@@ -339,17 +339,17 @@ gif_ioctl(struct ifnet *ifp, u_long cmd,
case SIOCSLIFPHYADDR:
switch (cmd) {
case SIOCSIFPHYADDR:
-   src = (struct sockaddr *)
-   &(((struct in_aliasreq *)data)->ifra_addr);
-   dst = (struct sockaddr *)
-   &(((struct in_aliasreq *)data)->ifra_dstaddr);
+   src = sintosa(
+   &(((struct in_aliasreq *)data)->ifra_addr));
+   dst = sintosa(
+   &(((struct in_aliasreq *)data)->ifra_dstaddr));
break;
 #ifdef INET6
case SIOCSIFPHYADDR_IN6:
-   src = (struct sockaddr *)
-   &(((struct in6_aliasreq *)data)->ifra_addr);
-   dst = (struct sockaddr *)
-   &(((struct in6_aliasreq *)data)->ifra_dstaddr);
+   src = sin6tosa(
+   &(((struct in6_aliasreq *)data)->ifra_addr));
+   dst = sin6tosa(
+   &(((struct in6_aliasreq *)data)->ifra_dstaddr));
break;
 #endif
case SIOCSLIFPHYADDR:
@@ -432,10 +432,10 @@ gif_ioctl(struct ifnet *ifp, u_long cmd,
 
/* can't configure multiple multi-dest interfaces */
 #define multidest(x) \
-   (((struct sockaddr_in *)(x))->sin_addr.s_addr == INADDR_ANY)
+   ((satosin((x)))->sin_addr.s_addr == INADDR_ANY)
 #ifdef INET6
 #define multidest6(x) \
-   (IN6_IS_ADDR_UNSPECIFIED(&((struct sockaddr_in6 *)(x))->sin6_addr))
+   (IN6_IS_ADDR_UNSPECIFIED(&(satosin6((x)))->sin6_addr))
 #endif
if (dst->sa_family == AF_INET &&
multidest(dst) && multidest(sc2->gif_pdst)) {
@@ -501,8 +501,8 @@ gif_ioctl(struct ifnet *ifp, u_long cmd,
break;
 #ifdef INET6
case SIOCGIFPSRCADDR_IN6:
-   dst = (struct sockaddr *)
-   &(((struct in6_ifreq *)data)->ifr_addr);
+   dst = sin6tosa(
+   &(((struct in6_ifreq *)data)->ifr_addr));
size = sizeof(((struct in6_ifreq *)data)->ifr_addr);
break;
 #endif /* INET6 */
@@ -531,8 +531,7 @@ gif_ioctl(struct ifnet *ifp, u_long cmd,
break;
 #ifdef INET6
case SIOCGIFPDSTADDR_IN6:
-   dst = (struct sockaddr *)
-   &(((struct in6_ifreq *)data)->ifr_addr);
+   dst = sin6tosa(&(((struct in6_ifreq *)data)->ifr_addr));
size = sizeof(((struct in6_ifreq *)data)->ifr_addr);
break;
 #endif /* INET6 */
Index: sys/net/if_tun.c
===
RCS file: /cvs/src/sys/net/if_tun.c,v
retrieving revision 1.151
diff -u -p -r1.151 if_tun.c
--- sys/net/if_tun.c20 Jul 2015 22:54:29 -  1.151
+++ sys/net/if_tun.c28 Aug 2015 13:06:21 -
@@ -446,12 +446,12 @@ tuninit(struct tun_softc *tp)
if (ifa->ifa_addr->sa_family == AF_INET6) {
struct sockaddr_in6 *sin;
 
-   sin = (struct sockaddr_in6 *)ifa->ifa_addr;
+   sin = satosin6(ifa->ifa_addr);
if (!IN6_IS_ADDR_UNSPECIFIED(&sin->sin6_addr))
tp->tun_flags |= TUN_IASET;
 
if (ifp->if_flags & IFF_POINTOPOINT) {
-   sin = (struct sockaddr_in6 *)ifa->ifa_dstaddr;
+   sin = satosin6(ifa->ifa_dstaddr);
if (sin &&
!IN6_IS_ADDR_UNSPECIFIED(&sin->sin6_addr))
tp->tun_flags |= TUN_DSTADDR;
Index: sys/net/pipex.c
===
RCS file: /cvs/src/sys/net/pipex.c,v
retrieving revision 1.73
diff -u -p -r1.73 pipex.c
--- sys/net/pipex.c 24 Aug 2015 14:00:28 -  1.73
+++ sys/net/pipex.c 28 Aug 2015 13:06:22 -
@@ -2959,10 +2959,9 @@ pipex_sockaddr_hash_key(struct sockaddr 
 {
switch (sa->sa_family) {
case AF_INET:
-   return ntohl(((struct sockaddr_in *)sa)->sin_addr.s_addr);
+   return ntohl(satosin(sa)->sin_addr.s_addr);
case AF_INET6:
-   return ntohl(((struct sockaddr_in6 *)sa)->sin6_addr
-  

squid 3.5/trunk and SSLv3 removal

2015-08-28 Thread Stuart Henderson
Any suggestions as to what might be needed here, can the SSLv3_method
just be replaced with SSLv23_method?

http://bazaar.launchpad.net/~squid/squid/3.5/view/head:/src/ssl/bio.cc#L1009

|   ciphers += 2;
|   if (ciphersLen) {
|   const SSL_METHOD *method = SSLv3_method();
   
|   const int cs = method->put_cipher_by_char(NULL, NULL);
|   assert(cs > 0);
|   for (size_t i = 0; i < ciphersLen; i += cs) {
|   const SSL_CIPHER *c = method->get_cipher_by_char((ciphers + i));
|   if (c != NULL) {
|   if (!clientRequestedCiphers.empty())
|   clientRequestedCiphers.append(":");
|   clientRequestedCiphers.append(c->name);
|   } else
|   unknownCiphers = true;
|   }
|   }
|   debugs(83, 7, "Ciphers requested by client: " << 
clientRequestedCiphers);



Introducing rtvalid(9)

2015-08-28 Thread Martin Pieuchot
Multiples routing entry issues, including my recent rtalloc(9) rewrite,
led me to believe that we need a simple way to check if a (cached) route
is still valid.  So let me introduce rtvalid(9):

 The rtvalid() function checks if the route entry rt is still valid and
 can be used.  Cached entries that are no longer valid should be released
 by calling rtfree().

Currently rtvalid(9) prevent you to use a !RTF_UP route or a entry
attached to a stall ifa.  In the short term I'd like to extend it
to include the validity of next hop in order to perform ARP or NDP
resolution for RTF_GATEWAY routes. 

I did not convert all the tree yet and some conversions might be more
tricky than I though.  So I'd like to commit the function first then
commit the conversion on a case-by-case basis.  So feel free to ok some
parts of it.

Index: share/man/man9/Makefile
===
RCS file: /cvs/src/share/man/man9/Makefile,v
retrieving revision 1.238
diff -u -p -r1.238 Makefile
--- share/man/man9/Makefile 14 Aug 2015 05:25:29 -  1.238
+++ share/man/man9/Makefile 28 Aug 2015 10:36:02 -
@@ -332,7 +332,7 @@ MLINKS+=rt_timer_add.9 rt_timer_queue_cr
rt_timer_add.9 rt_timer_queue_change.9 \
rt_timer_add.9 rt_timer_queue_destroy.9 \
rt_timer_add.9 rt_timer_remove_all.9
-MLINKS+=rtalloc.9 rtalloc_mpath.9 rtalloc.9 rtfree.9
+MLINKS+=rtalloc.9 rtalloc_mpath.9 rtalloc.9 rtvalid.9 rtalloc.9 rtfree.9
 MLINKS+=rtable_add.9 rtable_exists.9 rtable_add.9 rtable_get.9 \
rtable_add.9 rtable_l2.9 rtable_add.9 rtable_l2set.9
 MLINKS+=rtlabel_id2name.9 rtlabel_name2id.9 \
Index: share/man/man9/rtalloc.9
===
RCS file: /cvs/src/share/man/man9/rtalloc.9,v
retrieving revision 1.3
diff -u -p -r1.3 rtalloc.9
--- share/man/man9/rtalloc.95 Dec 2014 16:55:53 -   1.3
+++ share/man/man9/rtalloc.928 Aug 2015 10:36:18 -
@@ -1,6 +1,6 @@
 .\" $OpenBSD: rtalloc.9,v 1.3 2014/12/05 16:55:53 schwarze Exp $
 .\"
-.\" Copyright (c) 2014 Martin Pieuchot
+.\" Copyright (c) 2014-2015 Martin Pieuchot
 .\"
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
@@ -20,6 +20,7 @@
 .Sh NAME
 .Nm rtalloc ,
 .Nm rtalloc_mpath ,
+.Nm rtvalid,
 .Nm rtfree
 .Nd routing entry interface
 .Sh SYNOPSIS
@@ -30,6 +31,8 @@
 .Fn rtalloc "struct sockaddr *dst" "int flags" "unsigned int rtableid"
 .Ft struct rtentry *
 .Fn rtalloc_mpath "struct sockaddr *dst" "uint32_t *src" "unsigned int 
rtableid"
+.Ft int
+.Fn rtvalid "struct rtentry *rt"
 .Ft void
 .Fn rtfree "struct rtentry *rt"
 .Sh DESCRIPTION
@@ -65,6 +68,14 @@ but selects a multipath routing entry co
 when possible.
 .Pp
 The
+.Fn rtvalid
+function checks if the route entry
+.Fa rt
+is still valid and can be used.
+Cached entries that are no longer valid should be released by calling
+.Fn rtfree .
+.Pp
+The
 .Fn rtfree
 function releases a reference to the routing entry
 .Fa rt ,
@@ -72,9 +83,13 @@ freeing it if the reference count drops 
 .Sh CONTEXT
 .Fn rtalloc ,
 .Fn rtalloc_mpath ,
+.Fn rtvalid ,
 and
 .Fn rtfree
 can be called during autoconf, from process context, or from interrupt context.
+.Sh RETURN VALUES
+.Fn rtvalid
+returns 1 if the route entry is valid, otherwise 0.
 .Sh SEE ALSO
 .Xr route 4 ,
 .Xr rtrequest1 9
Index: sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.936
diff -u -p -r1.936 pf.c
--- sys/net/pf.c19 Aug 2015 21:22:41 -  1.936
+++ sys/net/pf.c28 Aug 2015 09:40:40 -
@@ -2949,11 +2949,11 @@ pf_calc_mss(struct pf_addr *addr, sa_fam
 #endif /* INET6 */
}
 
-   if (rt && rt->rt_ifp) {
+   if (rtvalid(rt)) {
mss = rt->rt_ifp->if_mtu - hlen - sizeof(struct tcphdr);
mss = max(tcp_mssdflt, mss);
-   rtfree(rt);
}
+   rtfree(rt);
mss = min(mss, offer);
mss = max(mss, 64); /* sanity - at least max opt space */
return (mss);
Index: sys/net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.225
diff -u -p -r1.225 route.c
--- sys/net/route.c 24 Aug 2015 22:11:33 -  1.225
+++ sys/net/route.c 28 Aug 2015 10:16:43 -
@@ -297,6 +297,25 @@ rtable_exists(u_int id)/* verify table 
return (1);
 }
 
+/*
+ * Returns 1 if the cached ``rt'' entry is still valid, 0 otherwise.
+ */
+int
+rtvalid(struct rtentry *rt)
+{
+   if (rt == NULL)
+   return (0);
+
+   if ((rt->rt_flags & RTF_UP) == 0)
+   return (0);
+
+   /* Routes attached to stall ifas should be freed. */
+   if (rt->rt_ifa == NULL || rt->rt_ifa->ifa_ifp == NULL)
+   return (0);
+
+   return (1

readelf on mips64

2015-08-28 Thread Mark Kettenis
As Theo and I noticed yesterday:

  $ readelf -a /usr/lib/libc.a
  readelf: Error: /usr/lib/libc.a: invalid archive string table offset 0

Turns out that on mips64 binutils creates IRIX-style "64-bit" archives
which allegedly can be larger than 4GB.  The difference is apparently
in the archive map where offsets are 64-bit instead of 32-bit.  Since
readelf simply skips over the map and reads the archive members
sequentially all we have to do is recognize "/SYM64/" as a valid
header and skip over it.

ok?


Index: readelf.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/binutils/readelf.c,v
retrieving revision 1.6
diff -u -p -r1.6 readelf.c
--- readelf.c   25 May 2015 14:56:27 -  1.6
+++ readelf.c   28 Aug 2015 09:55:35 -
@@ -9121,7 +9121,8 @@ process_archive (char *file_name, FILE *
   return 1;
 }
 
-  if (memcmp (arhdr.ar_name, "/   ", 16) == 0)
+  if (memcmp (arhdr.ar_name, "/   ", 16) == 0
+  || memcmp (arhdr.ar_name, "/SYM64/ ", 16) == 0)
 {
   /* This is the archive symbol table.  Skip it.
 FIXME: We should have an option to dump it.  */



Re: Using tame() in userland

2015-08-28 Thread Marc Espie
   have a much more stringent one for tsort.

Index: tsort.c
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/tsort/tsort.c,v
retrieving revision 1.26
diff -u -p -r1.26 tsort.c
--- tsort.c 29 Jul 2015 10:42:37 -  1.26
+++ tsort.c 28 Aug 2015 08:03:59 -
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* The complexity of topological sorting is O(e), where e is the
  * size of input.  While reading input, vertices have to be identified,
@@ -798,6 +799,43 @@ find_longest_cycle(struct array *h, stru
 
 #define plural(n) ((n) > 1 ? "s" : "")
 
+static void
+TAME(int flags, const char *wl[])
+{
+   if (tame(flags, wl) != 0)
+   err(1, "untamed program");
+}
+
+static void 
+compute_whitelist(int argc, char *argv[], char *args[])
+{
+   int c;
+   int i = 0;
+
+   while ((c = getopt(argc, argv, "h:flqrvw")) != -1) {
+   switch(c) {
+   case 'h':
+   args[i++] = optarg;
+   /*FALLTHRU*/
+   case 'f':
+   case 'l':
+   case 'q':
+   case 'r':
+   case 'v':
+   case 'w':
+   break;
+   default:
+   usage();
+   }
+   }
+   argc -= optind;
+   argv += optind;
+   if (argc == 1)
+   args[i++] = argv[0];
+   args[i] = NULL;
+   optind = optreset = 1;
+}
+
 int
 main(int argc, char *argv[])
 {
@@ -806,6 +844,10 @@ main(int argc, char *argv[])
warn_flag, hints_flag, verbose_flag;
unsigned intorder;
 
+   char *args[3];
+
+   compute_whitelist(argc, argv, args);
+   TAME(TAME_STDIO|TAME_RPATH, args);
order = 0;
 
reverse_flag = quiet_flag = long_flag =
@@ -863,6 +905,7 @@ main(int argc, char *argv[])
FILE *f;
 
f = fopen(argv[0], "r");
+   TAME(TAME_STDIO, NULL);
if (f == NULL)
err(EX_NOINPUT, "Can't open file %s", argv[1]);
order = read_pairs(f, &pairs, reverse_flag, argv[1], order,
@@ -871,6 +914,7 @@ main(int argc, char *argv[])
break;
}
case 0:
+   TAME(TAME_STDIO, NULL);
order = read_pairs(stdin, &pairs, reverse_flag, "stdin",
order, hints_flag == 2);
break;
@@ -878,6 +922,7 @@ main(int argc, char *argv[])
usage();
}
 
+   TAME(TAME_RW, NULL);
{
struct arrayaux;/* Unrefed nodes/cycle reporting.  */
struct arrayremaining;



Re: [patch] fix sdmmc bug affecting strictly sector-addressable eMMC chips

2015-08-28 Thread ian kremlin
> Nice work!  I wonder why you chose to be so conservative (or arbitrary)
> about the "after 50 failed attempts" condition. :)

My reasoning is that after 50 failed CMD1s, either two things are the
case: The card will only initialize with the sector bit set, or it is
a high capacity device taking a long time to become ready. In either
of these cases, the card will be block/sector addressed anyway.

> Since sector mode is supported by the host software, shouldn't we always
> set the MMC_OCR_SECTOR_MODE bit and check the returned OCR value to see
> if the card also supports sector mode addressing?
>
> Related thread: http://marc.info/?l=linux-mmc&m=129419687808618

That is a good point. I'll fix that.



Re: [patch] fix sdmmc bug affecting strictly sector-addressable eMMC chips

2015-08-28 Thread Uwe Stuehler
On Fri, Aug 28, 2015 at 02:13:44AM -0400, kremlin wrote:
> sdmmc gives up configuring the card after 100 failed CMD1 commands. My
> patch starts asserting the MMC_OCR_SECTOR_MODE bit after 50 failed
> attempts. This fixes the bug on my BBB with Micron chip:

Nice work!  I wonder why you chose to be so conservative (or arbitrary)
about the "after 50 failed attempts" condition. :)

Since sector mode is supported by the host software, shouldn't we always
set the MMC_OCR_SECTOR_MODE bit and check the returned OCR value to see
if the card also supports sector mode addressing?

Related thread: http://marc.info/?l=linux-mmc&m=129419687808618

Cheers,
Uwe