date:20141208

On 04/12/14(Thu) 01:15, Alexander Bluhm wrote:
 On Wed, Nov 26, 2014 at 03:21:43PM +0100, Martin Pieuchot wrote:
  @@ -5459,7 +5448,6 @@ pf_routable(struct pf_addr *addr, sa_fam
   
  /* Perform uRPF check if passed input interface */
  ret = 0;
  -   rt = ro.ro_rt;
  do {
  if (rt-rt_ifp-if_type == IFT_CARP)
  ifp = rt-rt_ifp-if_carpdev;
  @@ -5473,8 +5461,8 @@ pf_routable(struct pf_addr *addr, sa_fam
  } else
  ret = 0;
   out:
  -   if (ro.ro_rt != NULL)
  -   rtfree(ro.ro_rt);
  +   if (rt != NULL)
  +   rtfree(rt);
  return (ret);
   }
   
 
 The loop is setting rt to rt_mpath_next(rt) so you will free a
 different route entry in the end.

Thanks for spotting that.  Updated diff below keep the previous logic.

  @@ -5711,13 +5693,12 @@ pf_route6(struct mbuf **m, struct pf_rul
   struct pf_state *s)
   {
  struct mbuf *m0;
  -   struct route_in6 ip6route;
  -   struct route_in6*ro;
  -   struct sockaddr_in6 *dst;
  +   struct sockaddr_in6 *dst, sin6;
  struct ip6_hdr  *ip6;
  struct ifnet*ifp = NULL;
  struct pf_addr   naddr;
  struct pf_src_node  *sns[PF_SN_MAX];
  +   unsigned int rtableid;
 
 The variable rtableid is not really used.

Indeed, that was already the case, new version without this variable.

Is it ok?

Index: net/pf.c
===
RCS file: /home/ncvs/src/sys/net/pf.c,v
retrieving revision 1.896
diff -u -p -r1.896 pf.c
--- net/pf.c20 Nov 2014 13:54:24 -  1.896
+++ net/pf.c8 Dec 2014 11:02:48 -
@@ -2952,42 +2952,36 @@ pf_calc_mss(struct pf_addr *addr, sa_fam
 {
 #ifdef INET
struct sockaddr_in  *dst;
-   struct route ro;
 #endif /* INET */
 #ifdef INET6
struct sockaddr_in6 *dst6;
-   struct route_in6 ro6;
 #endif /* INET6 */
struct rtentry  *rt = NULL;
+   struct sockaddr_storage  ss;
int  hlen;
u_int16_tmss = tcp_mssdflt;
 
+   memset(ss, 0, sizeof(ss));
+
switch (af) {
 #ifdef INET
case AF_INET:
hlen = sizeof(struct ip);
-   bzero(ro, sizeof(ro));
-   dst = (struct sockaddr_in *)ro.ro_dst;
+   dst = (struct sockaddr_in *)ss;
dst-sin_family = AF_INET;
dst-sin_len = sizeof(*dst);
dst-sin_addr = addr-v4;
-   ro.ro_tableid = rtableid;
-   ro.ro_rt = rtalloc(ro.ro_dst, RT_REPORT, ro.ro_tableid);
-   rt = ro.ro_rt;
+   rt = rtalloc(sintosa(dst), RT_REPORT, rtableid);
break;
 #endif /* INET */
 #ifdef INET6
case AF_INET6:
hlen = sizeof(struct ip6_hdr);
-   bzero(ro6, sizeof(ro6));
-   dst6 = (struct sockaddr_in6 *)ro6.ro_dst;
+   dst6 = (struct sockaddr_in6 *)ss;
dst6-sin6_family = AF_INET6;
dst6-sin6_len = sizeof(*dst6);
dst6-sin6_addr = addr-v6;
-   ro6.ro_tableid = rtableid;
-   ro6.ro_rt = rtalloc(sin6tosa(ro6.ro_dst), RT_REPORT,
-   ro6.ro_tableid);
-   rt = ro6.ro_rt;
+   rt = rtalloc(sin6tosa(dst6), RT_REPORT, rtableid);
break;
 #endif /* INET6 */
}
@@ -5396,25 +5390,22 @@ int
 pf_routable(struct pf_addr *addr, sa_family_t af, struct pfi_kif *kif,
 int rtableid)
 {
+   struct sockaddr_storage  ss;
struct sockaddr_in  *dst;
int  ret = 1;
int  check_mpath;
 #ifdef INET6
struct sockaddr_in6 *dst6;
-   struct route_in6 ro;
-#else
-   struct route ro;
 #endif
-   struct rtentry  *rt;
+   struct rtentry  *rt, *rt0 = NULL;
struct ifnet*ifp;
 
check_mpath = 0;
-   bzero(ro, sizeof(ro));
-   ro.ro_tableid = rtableid;
+   memset(ss, 0, sizeof(ss));
switch (af) {
 #ifdef INET
case AF_INET:
-   dst = (struct sockaddr_in *)ro.ro_dst;
+   dst = (struct sockaddr_in *)ss;
dst-sin_family = AF_INET;
dst-sin_len = sizeof(*dst);
dst-sin_addr = addr-v4;
@@ -5430,7 +5421,7 @@ pf_routable(struct pf_addr *addr, sa_fam
 */
if (IN6_IS_SCOPE_EMBED(addr-v6))
goto out;
-   dst6 = ro.ro_dst;
+   dst6 = (struct sockaddr_in6 *)ss;
dst6-sin6_family = AF_INET6;
dst6-sin6_len = sizeof(*dst6);
dst6-sin6_addr = addr-v6;
@@ -5444,10 +5435,8 @@ pf_routable(struct pf_addr *addr, sa_fam
if (kif != NULL  kif-pfik_ifp-if_type ==

Re: Behavior of changing routes on OpenBSD 5.6

On 04/12/14(Thu) 00:26, Alexander Bluhm wrote:
 On Wed, Nov 26, 2014 at 12:58:35PM +0100, Martin Pieuchot wrote:
  @@ -761,7 +754,17 @@ report:
  error = EDQUOT;
  goto flush;
  }
  -   ifa = info.rti_ifa;
  +   /*
  +* new gateway could require new ifaddr, ifp;
  +* flags may also be different; ifp may be specified
  +* by ll sockaddr when protocol address is ambiguous
  +*/
  +   if (newgate || info.rti_info[RTAX_IFP] != NULL ||
  +   info.rti_info[RTAX_IFA] != NULL) {
 
 rt_getifa() may also use RTAX_DST to set rti_ifa.  So I think there
 should be a || info.rti_info[RTAX_DST] != NULL in the condition.

Except that here we are dealing with RTM_CHANGE and RTAX_DST is used to
find the route entry we're about to modify.  So if you pass a different
destination, the kernel won't find any route and the code will fail
earlier.

So ok?

Re: Soekris net6501 GPIO LED support

2014-12-08 Thread Jonathan Gray

On Fri, Dec 05, 2014 at 01:32:08PM -0500, Matt Dainty wrote:
 * Jonathan Gray j...@jsg.id.au [2014-12-05 10:16:41]:
  Perhaps a driver name change to reflect that this is to interface to the
  fpga on the soekris?
 
 This is tcpcib(4) all over again ;-)
 
 NetBSD committed this driver as soekrisgpio but I thought that might be a
 bit too long. Any opinions or suggestions?

Well any name that includes gpio that isn't taken should be fine.
It doesn't seem that soekris have a particular name for the interface
(or any actual documentation of it...).

Re: upd(4) buggy firmware

On Sat, Dec 6, 2014 at 8:57 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
 The ohci(4) diff is almost fine, USBD_SHORT_XFER should only be set in
 usbd_transfer_complete() so the HCD should only set the status to
 USBD_NORMAL_COMPLETION, see below.

 Concerning your broken firmware, what we should do is change the
 uhidev_*_report() function to somehow return the number of transferred
 bytes (actlen).  Since this involves calling usbd_do_request_flag() and
 update all the consumers of this API, here's a first step.

 Could you test the diff below and tell me if it still works for you?
 You'll still need your upd(4) diff.  If that works, I'll commit it and
 send a second diff to deal with your broken firmware.

Seems to work fine when patched against -stable.  (Sorry, I'd rather
not update this box to -current, unless necessary for some later
diff).

Since uhidev_set_report didn't change, why did wacom behavior need
tweaking?  I don't own this peripheral...

--david

Re: upd(4) buggy firmware

On 08/12/14(Mon) 09:02, David Higgs wrote:
 On Sat, Dec 6, 2014 at 8:57 AM, Martin Pieuchot mpieuc...@nolizard.org 
 wrote:
  The ohci(4) diff is almost fine, USBD_SHORT_XFER should only be set in
  usbd_transfer_complete() so the HCD should only set the status to
  USBD_NORMAL_COMPLETION, see below.
 
  Concerning your broken firmware, what we should do is change the
  uhidev_*_report() function to somehow return the number of transferred
  bytes (actlen).  Since this involves calling usbd_do_request_flag() and
  update all the consumers of this API, here's a first step.
 
  Could you test the diff below and tell me if it still works for you?
  You'll still need your upd(4) diff.  If that works, I'll commit it and
  send a second diff to deal with your broken firmware.
 
 Seems to work fine when patched against -stable.  (Sorry, I'd rather
 not update this box to -current, unless necessary for some later
 diff).

Stable should be fine.  Does this include the ohci(4) diff?

 Since uhidev_set_report didn't change, why did wacom behavior need
 tweaking?  I don't own this peripheral...

Because it was using usb_set_report() instead of uhidev_set_report() and
doing the reportID dance by itself.

Now I'd like to finish the transition that started with the import of
upd(4) and move away from the actual 1 reportID = 1 driver model.
Because in the end they are all sharing the same USB device actually
represented by an uhidev(4) instance.  So I'll ride the refactoring
needed by your buggy firmware to also change that.  Since all the 
uhidev_*_report() will be modified, we can also pass a pointer to
the uhidev(4) device instead of one of its children.  Is it clearer?

Martin

Re: upd(4) buggy firmware

On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
 On 08/12/14(Mon) 09:02, David Higgs wrote:
 On Sat, Dec 6, 2014 at 8:57 AM, Martin Pieuchot mpieuc...@nolizard.org 
 wrote:
  The ohci(4) diff is almost fine, USBD_SHORT_XFER should only be set in
  usbd_transfer_complete() so the HCD should only set the status to
  USBD_NORMAL_COMPLETION, see below.
 
  Concerning your broken firmware, what we should do is change the
  uhidev_*_report() function to somehow return the number of transferred
  bytes (actlen).  Since this involves calling usbd_do_request_flag() and
  update all the consumers of this API, here's a first step.
 
  Could you test the diff below and tell me if it still works for you?
  You'll still need your upd(4) diff.  If that works, I'll commit it and
  send a second diff to deal with your broken firmware.

 Seems to work fine when patched against -stable.  (Sorry, I'd rather
 not update this box to -current, unless necessary for some later
 diff).

 Stable should be fine.  Does this include the ohci(4) diff?

Yes, I replaced my ohci(4) tweak with your full diff, while keeping my
changes to upd(4).

 Since uhidev_set_report didn't change, why did wacom behavior need
 tweaking?  I don't own this peripheral...

 Because it was using usb_set_report() instead of uhidev_set_report() and
 doing the reportID dance by itself.

Whoops, you're right.  I missed that there was a different function prefix.

 Now I'd like to finish the transition that started with the import of
 upd(4) and move away from the actual 1 reportID = 1 driver model.
 Because in the end they are all sharing the same USB device actually
 represented by an uhidev(4) instance.  So I'll ride the refactoring
 needed by your buggy firmware to also change that.  Since all the
 uhidev_*_report() will be modified, we can also pass a pointer to
 the uhidev(4) device instead of one of its children.  Is it clearer?

Sounds great to me.

--david

next LibreSSL-portable release coming soon

2014-12-08 Thread Brent Cook

We spent the weekend buttoning up features and closing issues with
LibreSSL-portable.
All features and fixes for the next release are now landed in the github mirror:

https://github.com/libressl-portable/portable

Please test if you can. Thanks!

 - Brent

Call for testing of watchdog devices

2014-12-08 Thread Mike Belopuhov

Hi,

We plan to remove shutdown hooks for good and need to convert
all drivers implementing a watchdog(4) device to the config_*
framework namely implementing the activate method with a
DVACT_POWERDOWN action handler fleshed out.

This is the diff I came up with.  wdog_shutdown will now check
that the registered watchdog is the one we're disabling.

This compiles on amd64, i386 and sparc64, works fine on glxpcib
(the only one we have access to).

Here's a list of drivers that get changed:
 
 armv7/omap/omdog
 armv7/sunxi/sxidog

 i386/esm
 i386/elansc
 i386/geodesc

 sgi/imc

 sparc64/lom
 sparc64/pmc

 ipmi (not enabled)

 fins, it, schsio, viasio

 berkwdt, glxpcib, ichwdt, pwdog, tcpcib, wdt

Tests and OK's are welcome.


diff --git sys/arch/armv7/omap/omdog.c sys/arch/armv7/omap/omdog.c
index a8fb5d4..166bc11 100644
--- sys/arch/armv7/omap/omdog.c
+++ sys/arch/armv7/omap/omdog.c
@@ -55,18 +55,19 @@ struct omdog_softc {
 };
 
 struct omdog_softc *omdog_sc;
 
 void   omdog_attach(struct device *, struct device *, void *);
+intomdog_activate(struct device *, int);
 void   omdog_start(struct omdog_softc *);
 void   omdog_stop(struct omdog_softc *);
 void   omdog_sync(struct omdog_softc *);
 intomdog_cb(void *, int);
 void   omdog_reset(void);
 
 struct cfattachomdog_ca = {
-   sizeof (struct omdog_softc), NULL, omdog_attach
+   sizeof (struct omdog_softc), NULL, omdog_attach, NULL, omdog_activate
 };
 
 struct cfdriver omdog_cd = {
NULL, omdog, DV_DULL
 };
@@ -93,10 +94,24 @@ omdog_attach(struct device *parent, struct device *self, 
void *args)
 #ifndef SMALL_KERNEL
wdog_register(omdog_cb, sc);
 #endif
 }
 
+int
+omdog_activate(struct device *self, int act)
+{
+   switch (act) {
+   case DVACT_POWERDOWN:
+#ifndef SMALL_KERNEL
+   wdog_shutdown(self);
+#endif
+   break;
+   }
+
+   return (0);
+}
+
 void
 omdog_start(struct omdog_softc *sc)
 {
/* Write the enable sequence data h followed by h */
bus_space_write_4(sc-sc_iot, sc-sc_ioh, WSPR, 0x);
diff --git sys/arch/armv7/sunxi/sxidog.c sys/arch/armv7/sunxi/sxidog.c
index ab327dd..c59660f 100644
--- sys/arch/armv7/sunxi/sxidog.c
+++ sys/arch/armv7/sunxi/sxidog.c
@@ -64,18 +64,20 @@ struct sxidog_softc {
 };
 
 struct sxidog_softc *sxidog_sc = NULL; /* for sxidog_reset() */
 
 void sxidog_attach(struct device *, struct device *, void *);
+int sxidog_activate(struct device *, int);
 int sxidog_callback(void *, int);
 #if 0
 int sxidog_intr(void *);
 #endif
 void sxidog_reset(void);
 
 struct cfattachsxidog_ca = {
-   sizeof (struct sxidog_softc), NULL, sxidog_attach
+   sizeof (struct sxidog_softc), NULL, sxidog_attach,
+   NULL, sxidog_activate
 };
 
 struct cfdriver sxidog_cd = {
NULL, sxidog, DV_DULL
 };
diff --git sys/arch/i386/i386/esm.c sys/arch/i386/i386/esm.c
index 54f9f6d..40a278b 100644
--- sys/arch/i386/i386/esm.c
+++ sys/arch/i386/i386/esm.c
@@ -43,10 +43,11 @@ int esmdebug = 3;
 #define DPRINTFN(n,x...)   /* n: x */
 #endif
 
 intesm_match(struct device *, void *, void *);
 void   esm_attach(struct device *, struct device *, void *);
+intesm_activate(struct device *, int);
 
 enum esm_sensor_type {
ESM_S_UNKNOWN, /* XXX */
ESM_S_INTRUSION,
ESM_S_TEMP,
@@ -122,11 +123,12 @@ struct esm_softc {
int sc_wdog_period;
volatile intsc_wdog_tickle;
 };
 
 struct cfattach esm_ca = {
-   sizeof(struct esm_softc), esm_match, esm_attach
+   sizeof(struct esm_softc), esm_match, esm_attach,
+   NULL, esm_activate
 };
 
 struct cfdriver esm_cd = {
NULL, esm, DV_DULL
 };
@@ -272,10 +274,22 @@ esm_attach(struct device *parent, struct device *self, 
void *aux)
timeout_add_sec(sc-sc_timeout, 1);
}
 }
 
 int
+esm_activate(struct device *self, int act)
+{
+   switch (act) {
+   case DVACT_POWERDOWN:
+   wdog_shutdown(self);
+   break;
+   }
+
+   return (0);
+}
+
+int
 esm_watchdog(void *arg, int period)
 {
struct esm_softc*sc = arg;
struct esm_wdog_propprop;
struct esm_wdog_state   state;
diff --git sys/arch/i386/pci/elan520.c sys/arch/i386/pci/elan520.c
index bf077dd..b97476b 100644
--- sys/arch/i386/pci/elan520.c
+++ sys/arch/i386/pci/elan520.c
@@ -68,10 +68,11 @@ struct elansc_softc {
struct timecounter  sc_tc;
 } *elansc;
 
 intelansc_match(struct device *, void *, void *);
 void   elansc_attach(struct device *, struct device *, void *);
+intelansc_activate(struct device *, int);
 void   elansc_update_cpuspeed(void);
 void   elansc_setperf(int);
 intelansc_cpuspeed(int *);
 
 void   elansc_wdogctl(struct elansc_softc *, int, uint16_t);
@@ -84,11 +85,12 @@ voidelansc_gpio_pin_write(void *, int, int);
 void   elansc_gpio_pin_ctl(void *, int, int);
 
 u_int

Re: tcpdump follows incorrect alignment requirement rules

2014-12-08 Thread Mike Belopuhov

On Wed, Dec 03, 2014 at 14:56 +0100, Mike Belopuhov wrote:
 bpf aligns data following the datalink header (e.g. ethernet)
 on the BPF_ALIGNMENT boundary.  Since rev1.41 of bpf.h it's
 uint32_t instead of a long.  And also since then almost all
 packets become unaligned from the tcpdump perspective and
 require costly copies into the internal buffer.  Neither IP
 header (struct ip) nor IPv6 (struct ip6_hdr) have fields
 larger than 32 bits and therefore alignment requirements for
 them are at most 32 bit.
 
 I've successfully tested this diff on sparc64 and amd64.
 
 OK?
 

Still looking for OKs.

 diff --git usr.sbin/tcpdump/print-ip.c usr.sbin/tcpdump/print-ip.c
 index 1839869..60946a1 100644
 --- usr.sbin/tcpdump/print-ip.c
 +++ usr.sbin/tcpdump/print-ip.c
 @@ -368,11 +368,11 @@ ip_print(register const u_char *bp, register u_int 
 length)
   /*
* If the IP header is not aligned, copy into abuf.
* This will never happen with BPF.  It does happen with raw packet
* dumps from -r.
*/
 - if ((intptr_t)ip  (sizeof(long)-1)) {
 + if ((intptr_t)ip  (sizeof(u_int32_t)-1)) {
   static u_char *abuf = NULL;
   static int didwarn = 0;
   int clen = snapend - bp;
  
   if (clen  snaplen)
 diff --git usr.sbin/tcpdump/print-ip6.c usr.sbin/tcpdump/print-ip6.c
 index cca8495..ea3a9b3 100644
 --- usr.sbin/tcpdump/print-ip6.c
 +++ usr.sbin/tcpdump/print-ip6.c
 @@ -70,11 +70,11 @@ ip6_print(register const u_char *bp, register u_int 
 length)
   /*
* The IP header is not word aligned, so copy into abuf.
* This will never happen with BPF.  It does happen with
* raw packet dumps from -r.
*/
 - if ((intptr_t)ip6  (sizeof(long)-1)) {
 + if ((intptr_t)ip6  (sizeof(u_int32_t)-1)) {
   static u_char *abuf = NULL;
   static int didwarn = 0;
   int clen = snapend - bp;
   if (clen  snaplen)
   clen = snaplen;

Re: operations on nd_prefix list must take rdomain into account

2014-12-08 Thread Mike Belopuhov

Ping.

On Fri, Nov 28, 2014 at 13:40 +0100, Mike Belopuhov wrote:
 Still looking for OK's.
 
 On Wed, Nov 26, 2014 at 18:24 +0100, Mike Belopuhov wrote:
  More rdomain checks are needed to be able to use the same subnet
  in a back to back connection between IPv6 rdomains as pointed out
  by mpi@.
  
  OK?
  
  diff --git sys/netinet6/nd6.c sys/netinet6/nd6.c
  index 9616187..d704cd6 100644
  --- sys/netinet6/nd6.c
  +++ sys/netinet6/nd6.c
  @@ -1264,10 +1264,13 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet 
  *ifp)
  s = splsoftnet();
  /* First purge the addresses referenced by a prefix. */
  LIST_FOREACH_SAFE(pr, nd_prefix, ndpr_entry, npr) {
  struct in6_ifaddr *ia6, *ia6_next;
   
  +   if (pr-ndpr_ifp-if_rdomain != ifp-if_rdomain)
  +   continue;
  +
  if (IN6_IS_ADDR_LINKLOCAL(pr-ndpr_prefix.sin6_addr))
  continue; /* XXX */
   
  /* do we really have to remove addresses as well? */
  TAILQ_FOREACH_SAFE(ia6, in6_ifaddr, ia_list, ia6_next) 
  {
  @@ -1282,10 +1285,13 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet 
  *ifp)
   * Purging the addresses might remove the prefix as well.
   * So run the loop again to access only prefixes that have
   * not been freed already.
   */
  LIST_FOREACH_SAFE(pr, nd_prefix, ndpr_entry, npr) {
  +   if (pr-ndpr_ifp-if_rdomain != ifp-if_rdomain)
  +   continue;
  +
  if (IN6_IS_ADDR_LINKLOCAL(pr-ndpr_prefix.sin6_addr))
  continue; /* XXX */
   
  prelist_remove(pr);
  }
  diff --git sys/netinet6/nd6_rtr.c sys/netinet6/nd6_rtr.c
  index bfc9c9f..e46b3b4 100644
  --- sys/netinet6/nd6_rtr.c
  +++ sys/netinet6/nd6_rtr.c
  @@ -1690,10 +1690,13 @@ nd6_prefix_onlink(struct nd_prefix *pr)
   * interface, and the prefix has already installed the interface route.
   * Although such a configuration is expected to be rare, we explicitly
   * allow it.
   */
  LIST_FOREACH(opr, nd_prefix, ndpr_entry) {
  +   if (opr-ndpr_ifp-if_rdomain != ifp-if_rdomain)
  +   continue;
  +
  if (opr == pr)
  continue;
   
  if ((opr-ndpr_stateflags  NDPRF_ONLINK) == 0)
  continue;
  @@ -1826,10 +1829,13 @@ nd6_prefix_offlink(struct nd_prefix *pr)
   * the interface route (see comments in nd6_prefix_onlink).
   * If there's one, try to make the prefix on-link on the
   * interface.
   */
  LIST_FOREACH(opr, nd_prefix, ndpr_entry) {
  +   if (opr-ndpr_ifp-if_rdomain != ifp-if_rdomain)
  +   continue;
  +
  if (opr == pr)
  continue;
   
  if ((opr-ndpr_stateflags  NDPRF_ONLINK) != 0)
  continue;

Make dhclient not use lease files

2014-12-08 Thread Jurjen Oskam

Hi,

My (residential) ISP assigns me an IP address using DHCP. The lease time is 7
days or so. I just put dhcp in hostname.re1 and everything works, except for
a minor annoyance.

When re1 goes down (e.g. because of a reboot) the ISP *requires* a successful
DHCP exchange to occur before it enables the link on a layer 3 level. It does
not matter whether there still is a valid lease or not: after re1 goes down,
there *has* to be a DHCP exchange otherwise the link won't work.

What makes this worse is that the DHCP server does not always immediately
respond after re1 comes back up. It regularly happens that dhclient concludes
that the DHCP server is unreachable, finds that it still has a valid lease
in the lease file, and it'll use that. The problem with this is that dhclient
doesn't seem to try to contact the server anymore. With long lease times, it
could take days for dhclient to try to renew the lease.

I've tried using timeout 0 in dhclient.conf, but that only causes dhclient
to immediately using the lease from the lease file (after trying to reacquire
its previous address for ten seconds). Using an arbitrarily high timeout
value doesn't seem right.

The retry setting doesn't seem to help in this case: by default it's set to
5 minutes, but in my testing I noticed that once dhclient is bound to a lease
from the lease file, this setting doesn't seem to be used anymore. 


Perhaps I've missed something, but I concluded that in my scenario lease
files are never useful. I modified dhclient to accept a new option called
no-lease-file in dhclient.conf. A diff against -current is below. I've
tested it lightly on a laptop, and it seems to work OK. I've been using
roughly the same diff against -stable for a day or two.


Index: sbin/dhclient/clparse.c
===
RCS file: /cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.90
diff -u -p -r1.90 clparse.c
--- sbin/dhclient/clparse.c 3 Nov 2014 22:06:39 -   1.90
+++ sbin/dhclient/clparse.c 8 Dec 2014 10:07:39 -
@@ -67,6 +67,7 @@ read_client_conf(void)
new_parse(path_dhclient_conf);
 
/* Set some defaults. */
+   config-use_lease_file = 1;
config-link_timeout = 10;
config-timeout = 60;
config-select_interval = 0;
@@ -153,6 +154,7 @@ read_client_leases(void)
  * TOK_BACKOFF_CUTOFF number |
  * TOK_INITIAL_INTERVAL number |
  * interface-declaration |
+ * TOK_NO_LEASE_FILE |
  * TOK_LEASE client-lease-statement |
  * TOK_ALIAS client-lease-statement |
  * TOK_REJECT reject-statement
@@ -240,6 +242,10 @@ parse_client_statement(FILE *cfile)
break;
case TOK_INTERFACE:
parse_interface_declaration(cfile);
+   break;
+   case TOK_NO_LEASE_FILE:
+   config-use_lease_file = 0;
+   parse_semi(cfile);
break;
case TOK_LEASE:
parse_client_lease_statement(cfile, 1);
Index: sbin/dhclient/conflex.c
===
RCS file: /cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.29
diff -u -p -r1.29 conflex.c
--- sbin/dhclient/conflex.c 5 May 2014 18:02:49 -   1.29
+++ sbin/dhclient/conflex.c 8 Dec 2014 10:07:39 -
@@ -352,6 +352,7 @@ static const struct keywords {
{ media,  TOK_MEDIA },
{ medium, TOK_MEDIUM },
{ next-server,TOK_NEXT_SERVER },
+   { no-lease-file,  TOK_NO_LEASE_FILE },
{ option, TOK_OPTION },
{ prepend,TOK_PREPEND },
{ rebind, TOK_REBIND },
Index: sbin/dhclient/dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.343
diff -u -p -r1.343 dhclient.c
--- sbin/dhclient/dhclient.c8 Dec 2014 02:04:58 -   1.343
+++ sbin/dhclient/dhclient.c8 Dec 2014 10:07:39 -
@@ -549,15 +549,17 @@ main(int argc, char *argv[])
close(tailfd);
}
 
-   if ((fd = open(path_dhclient_db,
-   O_RDONLY|O_EXLOCK|O_CREAT|O_NOFOLLOW, 0640)) == -1)
-   error(can't open and lock %s: %s, path_dhclient_db,
-   strerror(errno));
-   read_client_leases();
-   if ((leaseFile = fopen(path_dhclient_db, w)) == NULL)
-   error(can't open %s: %s, path_dhclient_db, strerror(errno));
-   rewrite_client_leases();
-   close(fd);
+   if (config-use_lease_file) {
+   if ((fd = open(path_dhclient_db,
+   O_RDONLY|O_EXLOCK|O_CREAT|O_NOFOLLOW, 0640)) == -1)
+   error(can't open and lock %s: %s, path_dhclient_db,
+   strerror(errno));
+   read_client_leases();
+

Re: Soekris net6501 GPIO LED support

2014-12-08 Thread Matt Dainty

* Jonathan Gray j...@jsg.id.au [2014-12-08 08:08:19]:
 
 Well any name that includes gpio that isn't taken should be fine.

I went with soekrisgpio(4) as there are longer driver names in the tree,
(acpithinkpad(4) seems to hold that record from my quick scan) so rather
than try and come up with some witty contraction I picked that.

 It doesn't seem that soekris have a particular name for the interface
 (or any actual documentation of it...).

No, I'm struggling to find where I found the programming interface for it,
I can't find it in the manual. It must've come from the mailing list.

Revised patch below.

Matt

Index: share/man/man4/gpio.4
===
RCS file: /cvs/src/share/man/man4/gpio.4,v
retrieving revision 1.22
diff -u -p -r1.22 gpio.4
--- share/man/man4/gpio.4   21 Jan 2014 11:02:00 -  1.22
+++ share/man/man4/gpio.4   8 Dec 2014 16:34:26 -
@@ -30,6 +30,7 @@
 .Cd gpio* at omgpio? Pq armv7
 .Cd gpio* at pcagpio?
 .Cd gpio* at pcaled?
+.Cd gpio* at soekrisgpio? Pq amd64, i386
 .Cd gpio0 at voyager? Pq loongson
 .Pp
 .Fd #include sys/types.h
Index: share/man/man4/isa.4
===
RCS file: /cvs/src/share/man/man4/isa.4,v
retrieving revision 1.72
diff -u -p -r1.72 isa.4
--- share/man/man4/isa.418 Mar 2014 22:36:31 -  1.72
+++ share/man/man4/isa.48 Dec 2014 16:34:26 -
@@ -222,6 +222,8 @@ PCMCIA controllers
 PC (ISA) keyboard controller driver
 .It Xr pcppi 4
 PC (ISA) control and timer port driver
+.It Xr soekrisgpio 4
+Soekris net6501 GPIO and LEDs driver
 .It Xr vga 4
 VGA graphics driver for wscons
 .El
Index: share/man/man4/man4.amd64/Makefile
===
RCS file: /cvs/src/share/man/man4/man4.amd64/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- share/man/man4/man4.amd64/Makefile  27 May 2012 12:24:33 -  1.15
+++ share/man/man4/man4.amd64/Makefile  8 Dec 2014 16:34:26 -
@@ -1,7 +1,7 @@
 #  $OpenBSD: Makefile,v 1.15 2012/05/27 12:24:33 jsg Exp $
 
 MAN=   amdpcib.4 apm.4 autoconf.4 bios.4 cpu.4 intro.4 ioapic.4 \
-   mem.4 mpbios.4 nvram.4 mtrr.4 pctr.4 tcpcib.4
+   mem.4 mpbios.4 nvram.4 mtrr.4 pctr.4 soekrisgpio.4 tcpcib.4
 
 MLINKS+= mem.4 kmem.4
 MANSUBDIR=amd64
Index: share/man/man4/man4.amd64/soekrisgpio.4
===
RCS file: share/man/man4/man4.amd64/soekrisgpio.4
diff -N share/man/man4/man4.amd64/soekrisgpio.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.amd64/soekrisgpio.4 8 Dec 2014 16:34:26 -
@@ -0,0 +1,57 @@
+.\ $OpenBSD$
+.\
+.\ Copyright (c) 2014 Matt Dainty m...@bodgit-n-scarper.com
+.\
+.\ Permission to use, copy, modify, and distribute this software for any
+.\ purpose with or without fee is hereby granted, provided that the above
+.\ copyright notice and this permission notice appear in all copies.
+.\
+.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\
+.Dd $Mdocdate$
+.Dt SOEKRISGPIO 4 amd64
+.Os
+.Sh NAME
+.Nm soekrisgpio
+.Nd Soekris net6501 GPIO and LEDs
+.Sh SYNOPSIS
+.Cd soekrisgpio0 at isa? port 0x680
+.Cd gpio* at soekrisgpio?
+.Sh DESCRIPTION
+The
+.Nm
+driver provides support for the GPIO and LEDs as implemented by the Xilinx
+Spartan FGPA integrated into the Soekris net6501 programmed with the default
+bitstream found in the BIOS.
+.Pp
+Two standard
+.Xr gpio 4
+interfaces are provided, one for the 16 real pins which can be configured as
+either inputs or outputs and another with 2 output-only pins that map
+to the error and ready LEDs respectively.
+Both may be used with
+.Xr gpioctl 8 .
+.Sh SEE ALSO
+.Xr intro 4 ,
+.Xr isa 4 ,
+.Xr gpio 4 ,
+.Xr gpioctl 8
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Ox 5.7 .
+.Sh AUTHORS
+The
+.Nm
+driver was written by
+.An Matt Dainty Aq m...@bodgit-n-scarper.com .
+.Sh BUGS
+If the Xilinx FPGA is programmed with a different bistream, the driver will
+likely not function.
Index: share/man/man4/man4.i386/Makefile
===
RCS file: /cvs/src/share/man/man4/man4.i386/Makefile,v
retrieving revision 1.72
diff -u -p -r1.72 Makefile
--- share/man/man4/man4.i386/Makefile   27 May 2012 12:24:33 -  1.72
+++ share/man/man4/man4.i386/Makefile   8 Dec 2014 16:34:26 -
@@ -7,7 +7,7 @@ MAN=amdpcib.4 amdmsr.4 apm.4 autoconf.4
ichpcib.4 intro.4 ioapic.4 \

Small diff ...

2014-12-08 Thread David Carlier

Following small discussion I had with tedu@ this is just small diff, just
for the sake of C standard correctness ... dropping some arithmetic
pointer with void pointers ...

Hopes it might find some interest/usefullness ...

Thanks in advance.


Index: gnu/gcc/gcc/unwind-dw2.c
===
RCS file: /cvs/src/gnu/gcc/gcc/unwind-dw2.c,v
retrieving revision 1.2
diff -u -p -r1.2 unwind-dw2.c
--- gnu/gcc/gcc/unwind-dw2.c7 May 2010 22:06:10 -1.2
+++ gnu/gcc/gcc/unwind-dw2.c8 Dec 2014 17:03:58 -
@@ -1528,9 +1528,9 @@ uw_install_context_1 (struct _Unwind_Con

   /* We adjust SP by the difference between CURRENT and TARGET's CFA.
*/
   if (STACK_GROWS_DOWNWARD)
-return target_cfa - current-cfa + target-args_size;
+return (unsigned char *)target_cfa - (unsigned char *)current-cfa +
target-args_size;
   else
-return current-cfa - target_cfa - target-args_size;
+return (unsigned char *)current-cfa - (unsigned char *)target_cfa -
target-args_size;
 }
   return 0;
 }
Index: lib/librthread/rthread_np.c
===
RCS file: /cvs/src/lib/librthread/rthread_np.c,v
retrieving revision 1.14
diff -u -p -r1.14 rthread_np.c
--- lib/librthread/rthread_np.c9 Aug 2014 03:29:35 -1.14
+++ lib/librthread/rthread_np.c8 Dec 2014 17:04:00 -
@@ -66,7 +66,7 @@ pthread_stackseg_np(pthread_t thread, st
 #ifdef MACHINE_STACK_GROWS_UP
 sinfo-ss_sp = thread-stack-base;
 #else
-sinfo-ss_sp = thread-stack-base + thread-stack-len;
+sinfo-ss_sp = (unsigned char *)thread-stack-base +
thread-stack-len;
 #endif
 sinfo-ss_size = thread-stack-len;
 if (thread-stack-guardsize != 1)
Index: libexec/ld.so/util.c
===
RCS file: /cvs/src/libexec/ld.so/util.c,v
retrieving revision 1.35
diff -u -p -r1.35 util.c
--- libexec/ld.so/util.c14 Jul 2014 03:54:50 -1.35
+++ libexec/ld.so/util.c8 Dec 2014 17:04:00 -
@@ -72,16 +72,17 @@ void
 _dl_randombuf(void *buf, size_t buflen)
 {
 size_t chunk;
+unsigned char *pbuf = buf;

 while (buflen != 0) {
 if (buflen  256)
 chunk = 256;
 else
 chunk = buflen;
-if (_dl_getentropy(buf, chunk) != 0)
+if (_dl_getentropy(pbuf, chunk) != 0)
 _dl_exit(8);
 buflen -= chunk;
-buf += chunk;
+pbuf += chunk;
 }
 }

Index: usr.sbin/nsd/difffile.c
===
RCS file: /cvs/src/usr.sbin/nsd/difffile.c,v
retrieving revision 1.1.1.15
diff -u -p -r1.1.1.15 difffile.c
--- usr.sbin/nsd/difffile.c16 Sep 2014 16:54:03 -1.1.1.15
+++ usr.sbin/nsd/difffile.c8 Dec 2014 17:04:01 -
@@ -716,10 +716,10 @@ delete_RR(namedb_type* db, const dname_t
 rrset-rr_count-1])
 zone-nsec3_param = rrset-rrs[rrnum];
 else
-zone-nsec3_param =
-(void*)zone-nsec3_param
--(void*)rrs_orig +
-(void*)rrset-rrs;
+zone-nsec3_param = (void*)(
+(char*)zone-nsec3_param
+-(char*)rrs_orig +
+(char*)rrset-rrs);
 }
 #endif /* NSEC3 */
 rrset-rr_count --;
@@ -817,8 +817,8 @@ add_RR(namedb_type* db, const dname_type
 assert(zone-nsec3_param = rrs_old 
 zone-nsec3_param  rrs_old+rrset-rr_count);
 /* in this order to make sure no overflow/underflow*/
-zone-nsec3_param = (void*)zone-nsec3_param -
-(void*)rrs_old + (void*)rrset-rrs;
+zone-nsec3_param = (void*)((char *)zone-nsec3_param -
+(char*)rrs_old + (char*)rrset-rrs);
 }
 #endif /* NSEC3 */
 }

Index: usr.sbin/nsd/udb.h
===
RCS file: /cvs/src/usr.sbin/nsd/udb.h,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 udb.h
--- usr.sbin/nsd/udb.h16 Sep 2014 16:54:00 -1.1.1.3
+++ usr.sbin/nsd/udb.h8 Dec 2014 17:04:01 -
@@ -54,7 +54,7 @@ typedef uint64_t udb_void;
 /** convert relptr to usable pointer */
 #define UDB_REL(base, relptr) ((base) + (relptr))
 /** from system pointer to relative pointer */
-#define UDB_SYSTOREL(base, ptr) ((udb_void)((void*)(ptr) - (base)))
+#define UDB_SYSTOREL(base, ptr) ((udb_void)((ptr) - (base)))

 /** MAX 2**x exponent of alloced chunks, for 1Mbytes.  The smallest
  * chunk is 16bytes (8preamble+8data), so 0-3 is unused. */
Index: usr.sbin/nsd/xfrd-tcp.c
===
RCS file: /cvs/src/usr.sbin/nsd/xfrd-tcp.c,v
retrieving revision 1.9
diff -u -p -r1.9 xfrd-tcp.c
--- usr.sbin/nsd/xfrd-tcp.c16 Sep 2014 17:01:38 -1.9

Re: clang++ and a modern C++ library

2014-12-08 Thread Dave Huseby

 I tried with llvm-3.5.20140228p18 (the clang package), g++-4.9.2 and
 libstdc++-4.8.3, the next command:
 
 clang++ -std=c++11 -I/usr/local/include -I/usr/local/include/c++/4.9.2
 -I/usr/local/include/c++/4.9.2/x86_64-unknown-openbsd5.6 -I/usr/include
 -L/usr/local/lib/gcc-lib/amd64-unknown-openbsd5.6/3.3.6 -L/usr/local/lib
 -nostdinc++ -lestdc++ test.cc
 
 Apparently everything works fine.

Alright, let me update my scripts and give this a shot.

--dave

Re: Small diff ...

On Mon, Dec 08, 2014 at 17:18, David Carlier wrote:
 Following small discussion I had with tedu@ this is just small diff, just
 for the sake of C standard correctness ... dropping some arithmetic
 pointer with void pointers ...
 
 Hopes it might find some interest/usefullness ...

Thanks.

 Index: gnu/gcc/gcc/unwind-dw2.c

I don't think we want to mess with gcc.

 Index: lib/librthread/rthread_np.c

Fixed.

 Index: libexec/ld.so/util.c

I'll let somebody else take this one, but I think it's right.

 Index: usr.sbin/nsd/difffile.c
 Index: usr.sbin/nsd/udb.h

All the nsd diffs should be sent to them.

 Index: usr.sbin/nsd/xfrd-tcp.c
 ===
 RCS file: /cvs/src/usr.sbin/nsd/xfrd-tcp.c,v
 retrieving revision 1.9
 diff -u -p -r1.9 xfrd-tcp.c
 --- usr.sbin/nsd/xfrd-tcp.c16 Sep 2014 17:01:38 -1.9
 +++ usr.sbin/nsd/xfrd-tcp.c8 Dec 2014 17:04:01 -
 @@ -40,7 +40,7 @@ xfrd_pipe_cmp(const void* a, const void*
 if(x-num_unused != y-num_unused)
 return x-num_unused - y-num_unused;
 /* different pipelines are different still, even with same numunused*/
 -return (int)(a - b);
 +return (int)((char *)a - (char *)b);
 }
 
 xfrd_tcp_set_t* xfrd_tcp_set_create(struct region* region)

This by the way looks wrong. 64 bit pointers can be too far away for
this to work. It needs to be expanded to if (a  b) return 1 ...

Actually, it doesn't always even work for 32 bits. If a is more than
2B greater than b, it will return less than, not greater. The same is
true for integers and pointers. (a - b) is a dangerous sort idiom.

Re: Soekris net6501 GPIO LED support

On Mon, Dec 08, 2014 at 11:52, Matt Dainty wrote:
 * Jonathan Gray j...@jsg.id.au [2014-12-08 08:08:19]:

 Well any name that includes gpio that isn't taken should be fine.
 
 I went with soekrisgpio(4) as there are longer driver names in the tree,
 (acpithinkpad(4) seems to hold that record from my quick scan) so rather
 than try and come up with some witty contraction I picked that.

skgpio should be sufficient.

Re: next LibreSSL-portable release coming soon

2014-12-08 Thread Adam Wolk

Hi Brent,

I did a compile and run the tests on Archlinux 64-bit.
 - no compiler warnings
 - all tests passed (results below)

I also took a look at the pages generated in man for tls_init.3,
openssl.3  ssl.3 - they all look fine (no visible glitches).

Please let me know if I can do more tests (ie. guiding me to a specific
part of library/executable).

[mulander@koparo portable]$ uname -a
Linux koparo 3.17.4-1-ARCH #1 SMP PREEMPT Fri Nov 21 21:14:42 CET 2014
x86_64 GNU/Linux

[mulander@koparo portable]$ gcc --version
gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

[mulander@koparo portable]$ ./apps/openssl version
LibreSSL 2.1

Tested on commit: commit cfbc62e686f020f3db6b2aa4e86cc19b662c3597


Testsuite summary for libressl 2.1.2

# TOTAL: 44
# PASS:  44
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Regards,
-- 
  Adam Wolk
  adam.w...@koparo.com

On Mon, Dec 8, 2014, at 03:54 PM, Brent Cook wrote:
 We spent the weekend buttoning up features and closing issues with
 LibreSSL-portable.
 All features and fixes for the next release are now landed in the github
 mirror:
 
 https://github.com/libressl-portable/portable
 
 Please test if you can. Thanks!
 
  - Brent

sensorsd.conf(5) indicator parsing

As per an earlier thread on misc@, this fixes sensorsd.conf(5) parsing of 
SENSOR_INDICATOR values.  Since parsing as integers was both undocumented and 
confusing, it is no longer supported.  Also, bail on error if the high/low 
values don’t create a valid range.

This mimics existing behavior, but still isn't very intuitive.  I.e. 
“low=Off:high=On” will always be “within” user limits.  Should indicators 
limits behave differently?

Feedback is welcome.

--david

Index: sensorsd.c
===
RCS file: /cvs/src/usr.sbin/sensorsd/sensorsd.c,v
retrieving revision 1.53
diff -u -p -r1.53 sensorsd.c
--- sensorsd.c  29 Jun 2014 00:58:45 -  1.53
+++ sensorsd.c  8 Dec 2014 19:45:45 -
@@ -723,6 +723,8 @@ parse_config_sdlim(struct sdlim_t *sdlim
if (cgetstr(buf, high, ebuf)  0)
ebuf = NULL;
p-upper = get_val(ebuf, 1, p-type);
+   if (p-lower  p-upper)
+   errx(1, %s: incorrect sensor range, node);
if (cgetstr(buf, command, ebuf)  0)
ebuf = NULL;
if (ebuf)
@@ -749,7 +751,7 @@ get_val(char *buf, int upper, enum senso
}
 
val = strtod(buf, p);
-   if (buf == p)
+   if (buf == p  type != SENSOR_INDICATOR)
err(1, incorrect value: %s, buf);
 
switch(type) {
@@ -780,6 +782,13 @@ get_val(char *buf, int upper, enum senso
rval = val * 1000.0;
break;
case SENSOR_INDICATOR:
+   if (strcmp(buf, On) == 0)
+   rval = 1;
+   else if (strcmp(buf, Off) == 0)
+   rval = 0;
+   else
+   errx(1, incorrect value: %s, buf);
+   break;
case SENSOR_INTEGER:
case SENSOR_DRIVE:
case SENSOR_ANGLE:

Violating randomization standards

2014-12-08 Thread Theo de Raadt

I have spent the last week researching all the uses of the srand(),
srandom(), and srand48() subsystems in the ports tree.

These three APIs are standardized into C89, POSIX, XPG42, etc.  Rather
unfortunate, since they suck, and their existance suckers developers
into doing the wrong thing.

The long standing problem is they have always contained a gigantic lie
in their names.  They are not random, not in any sense.  All three
subsystems produce deterministic results.  The reasons for this are
history not known to me, but it might even be linked to Dual_EC_DRBG.

A basic explanation of the APIs is needed.  All three work the same
way, just substitute rand/random/rand48 below:

- A seed is provided by calling srand()
- Subsequent calls to rand() will pull a value
  and rotate the determinisic algorithm forward

This API is used in two patterns:
1. Under the assumption it provides good random numbers.
   This is the primary usage case by most developers.
   This is their expectation.
2. A 'seed' can be re-provided at a later time, allowing
   replay of a previous random sequence, oh wait, I mean
   a deterministic sequence...

The standards mandate both uses, and lull people into believing
that this is good practice.  Increasingly people have become aware that this
is bull, and then they invent their own which are just as bad.

I started my audit of the ports tree for rand() and random() use, as
indicated by the linker.  I found 1221 ports out of 8800 used them.

Differentiating pattern 1 from pattern 2 involved looking at the seed
being given to the subsystem.  If the software tried to supply a good
seed, and had no framework for re-submitting a seed for reuse, then
it was clear it wanted good random numbers.  Those ports could be
eliminated from consideration, since they indicated they wanted good
random numbers.

This left only 41 ports for consideration.  Generally, these are doing
reseeding for reproduceable effects during benchmarking.  Further
analysis may show some of these ports do not need determinism, but if
there is any doubt they can be mindlessly modified as described below.

Late in the game, I started my audit for rand48.  That adds another 64
ports.  This is the newest in the family of APIs.  The same principle
follows.

I want to squeeze in a point about the software fetching random
numbers.  In general, the codeblocks where access to random numbers is
done lacks crafstmanship.  It is obvious that only a few pieces of
software in this set were written by people who understand the
consequences.  As an exercise, I did a grep for ports that use
arc4random().  Those automatically fell into a higher catagory of
quality.  A few even include their own versions.

The semantic change being done is to have these random subsystems
operate in strong random mode, unless a srand_deterministic(seed)
function is called to indicate preference for the unsafe mode.

Regarding impact of such changes.

First off, 96.5% of the ports using random are fixed in a trivial
fashion, because they suddenly get strong random.

Some of those 1285 ports are libraries, so I estimate around half of
the packages will be affected.  They will suddenly see strong
randomization where they did not before.  There may be a few broken
because the have a deeply hidden dependency on determinism.  Sorry,
but that is what it is going to take.


First here is one of the changed manual pages, then the diff after.

RAND(3)Library Functions ManualRAND(3)

NAME
 rand, rand_r, srand, srand_deterministic - bad pseudo-random number
 generator

SYNOPSIS
 #include stdlib.h

 void
 srand(unsigned int seed);

 void
 srand_deterministic(unsigned int seed);

 int
 rand(void);

 int
 rand_r(unsigned int *seed);

DESCRIPTION
 Standards insist that this interface return deterministic results.
 Unsafe usage is very common, so OpenBSD changed the subsystem to return
 non-deterministic results by default.

 To satisfy portable code, srand() may be called to initialize the
 subsystem.  In OpenBSD the seed variable is ignored, and strong random
 number results will be provided from arc4random(3.) In other systems, the
 seed variable primes a simplistic deterministic algorithm.

 If the standardized behavior is required srand_deterministic() can be
 substituted for srand(), then subsequent rand() calls will return results
 using the deterministic algorithm.

 The rand() function returns a result in the range of 0 to RAND_MAX.  By
 default, this result comes from arc4random(3).  If srand_deterministic()
 was called, the result will be computed using the deterministic
 algorithm.

 The rand_r() is a thread-safe version of rand().  Storage for the seed
 must be provided through the seed argument, and needs to have been
 initialized by the

Re: Violating randomization standards

2014-12-08 Thread patrick keshishian

Hello,

Small comment below.

On Mon, Dec 08, 2014 at 01:55:47PM -0700, Theo de Raadt wrote:
 I have spent the last week researching all the uses of the srand(),
 srandom(), and srand48() subsystems in the ports tree.
[...]
 RAND(3)Library Functions ManualRAND(3)
 
 NAME
  rand, rand_r, srand, srand_deterministic - bad pseudo-random number
  generator
 
 SYNOPSIS
  #include stdlib.h
 
  void
  srand(unsigned int seed);
 
  void
  srand_deterministic(unsigned int seed);
 
  int
  rand(void);
 
  int
  rand_r(unsigned int *seed);
 
 DESCRIPTION
  Standards insist that this interface return deterministic results.
  Unsafe usage is very common, so OpenBSD changed the subsystem to return
  non-deterministic results by default.
 
  To satisfy portable code, srand() may be called to initialize the
  subsystem.  In OpenBSD the seed variable is ignored, and strong random
  number results will be provided from arc4random(3.) In other systems, the
  seed variable primes a simplistic deterministic algorithm.
 
  If the standardized behavior is required srand_deterministic() can be
  substituted for srand(), then subsequent rand() calls will return results
  using the deterministic algorithm.
 
  The rand() function returns a result in the range of 0 to RAND_MAX.  By
  default, this result comes from arc4random(3).  If srand_deterministic()
  was called, the result will be computed using the deterministic
  algorithm.
 
  The rand_r() is a thread-safe version of rand().  Storage for the seed
  must be provided through the seed argument, and needs to have been
  initialized by the caller.  It always operates using the deterministic
  algorithm.
 
 SEE ALSO
  arc4random(3), rand48(3), random(3)
 
 STANDARDS
  The rand() function conforms to ANSI X3.159-1989 (``ANSI C89'').
 
  The rand_r() function conforms to IEEE Std 1003.1-2008 (``POSIX.1'').
 
  The srand() function does not conform to ANSI X3.159-1989 (``ANSI C89''),
  intentionally.
 
  The srand_deterministic() function is an OpenBSD extension.
 
 HISTORY
  The functions rand() and srand() first appeared in Version 3 ATT UNIX.
 
 OpenBSD 5.6November 25, 2014   OpenBSD 5.6
[...]
 Index: lib/libc/stdlib/rand.c
 ===
 RCS file: /cvs/src/lib/libc/stdlib/rand.c,v
 retrieving revision 1.10
 diff -u -p -u -r1.10 rand.c
 --- lib/libc/stdlib/rand.c1 Aug 2013 19:42:08 -   1.10
 +++ lib/libc/stdlib/rand.c8 Dec 2014 03:50:34 -
 @@ -30,6 +30,7 @@
  #include sys/types.h
  #include stdlib.h
  
 +static int rand_deterministic;
  static u_int next = 1;
  
  int
 @@ -47,6 +48,8 @@ __warn_references(rand_r,
  int
  rand(void)
  {
 + if (rand_deterministic)
 + return (arc4random() % ((u_int)RAND_MAX + 1));

I think, based on man page change you sent, the if()
statement should check for '0 == rand_deterministic'
No?

--patrick


   return (rand_r(next));
  }
  
 @@ -58,10 +61,12 @@ __warn_references(rand,
  void
  srand(u_int seed)
  {
 - next = seed;
 + rand_deterministic = 0;
  }
  
 -#if defined(APIWARN)
 -__warn_references(srand,
 -warning: srand() seed choices are invariably poor);
 -#endif
 +void
 +srand_deterministic(u_int seed)
 +{
 + rand_deterministic = 1;
 + next = seed;
 +}

Re: Violating randomization standards

2014-12-08 Thread Jonas 'Sortie' Termansen

On 12/08/2014 09:55 PM, Theo de Raadt wrote:
 Index: lib/libc/stdlib/mrand48.c
 ===
 RCS file: /cvs/src/lib/libc/stdlib/mrand48.c,v
 retrieving revision 1.3
 diff -u -p -u -r1.3 mrand48.c
 --- lib/libc/stdlib/mrand48.c 8 Aug 2005 08:05:37 -   1.3
 +++ lib/libc/stdlib/mrand48.c 8 Dec 2014 03:13:07 -
 @@ -19,6 +19,8 @@ extern unsigned short __rand48_seed[3];
  long
  mrand48(void)
  {
 + if (__rand48_deterministic == 0)
 + return arc4random();
   __dorand48(__rand48_seed);
   return ((long) __rand48_seed[2]  16) + (long) __rand48_seed[1];
  }

POSIX says mrand48 is meant to return signed integers in the interval
[-2^31,2^31), but this code returns an unsigned 32-bit integer value.

Re: Violating randomization standards

2014-12-08 Thread Todd C. Miller

On Tue, 09 Dec 2014 00:00:01 +0100, Jonas 'Sortie' Termansen wrote:

 POSIX says mrand48 is meant to return signed integers in the interval
 [-2^31,2^31), but this code returns an unsigned 32-bit integer value.

Which gets cast to a signed integer in that same range...

 - todd

Re: upd(4) buggy firmware

On 08/12/14(Mon) 09:35, David Higgs wrote:
 On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot mpieuc...@nolizard.org 
 wrote:
  [...]
  Now I'd like to finish the transition that started with the import of
  upd(4) and move away from the actual 1 reportID = 1 driver model.
  Because in the end they are all sharing the same USB device actually
  represented by an uhidev(4) instance.  So I'll ride the refactoring
  needed by your buggy firmware to also change that.  Since all the
  uhidev_*_report() will be modified, we can also pass a pointer to
  the uhidev(4) device instead of one of its children.  Is it clearer?
 
 Sounds great to me.

As promised, here's a second and last diff that changes the various
uhidev_*_report() functions to provide the transfered length to the
caller if requested.

The *get* variant now also handles the first byte required for non-0
reportID.

And last but not least, it includes the hack from apcupsd to deal with
buggy firmwares like yours.

Could you try it and let me know how it goes?

Index: ucycom.c
===
RCS file: /cvs/src/sys/dev/usb/ucycom.c,v
retrieving revision 1.29
diff -u -p -r1.29 ucycom.c
--- ucycom.c12 Jul 2014 20:26:33 -  1.29
+++ ucycom.c8 Dec 2014 22:54:53 -
@@ -453,8 +453,8 @@ ucycom_param(void *addr, int portno, str
report[2] = (baud  16)  0xff;
report[3] = (baud  24)  0xff;
report[4] = cfg;
-   err = uhidev_set_report(sc-sc_hdev, UHID_FEATURE_REPORT,
-   sc-sc_hdev.sc_report_id, report, sc-sc_flen);
+   err = uhidev_set_report(sc-sc_hdev.sc_parent, UHID_FEATURE_REPORT,
+   sc-sc_hdev.sc_report_id, report, sc-sc_flen, NULL);
if (err != 0) {
DPRINTF((ucycom_param: uhidev_set_report %d %s\n,
err, usbd_errstr(err)));
@@ -553,11 +553,11 @@ ucycom_set(void *addr, int portno, int r
 void
 ucycom_get_cfg(struct ucycom_softc *sc)
 {
-   int err, cfg, baud;
+   int cfg, baud;
uint8_t report[5];
 
-   err = uhidev_get_report(sc-sc_hdev, UHID_FEATURE_REPORT,
-   sc-sc_hdev.sc_report_id, report, sc-sc_flen);
+   uhidev_get_report(sc-sc_hdev.sc_parent, UHID_FEATURE_REPORT,
+   sc-sc_hdev.sc_report_id, report, sc-sc_flen, NULL);
cfg = report[4];
baud = (report[3]  24) + (report[2]  16) + (report[1]  8) + 
report[0];
DPRINTF((ucycom_configure: device reports %d baud, %d-%c-%d (%d)\n, 
baud,
Index: ugold.c
===
RCS file: /cvs/src/sys/dev/usb/ugold.c,v
retrieving revision 1.6
diff -u -p -r1.6 ugold.c
--- ugold.c 29 Apr 2014 12:53:33 -  1.6
+++ ugold.c 8 Dec 2014 22:54:53 -
@@ -260,6 +260,6 @@ ugold_refresh(void *arg)
 int
 ugold_issue_cmd(struct ugold_softc *sc, uint8_t *cmd, int len)
 {
-   return uhidev_set_report_async(sc-sc_hdev, UHID_OUTPUT_REPORT,
-   sc-sc_hdev.sc_report_id, cmd, len);
+   return uhidev_set_report_async(sc-sc_hdev.sc_parent,
+   UHID_OUTPUT_REPORT, sc-sc_hdev.sc_report_id, cmd, len, NULL);
 }
Index: uhid.c
===
RCS file: /cvs/src/sys/dev/usb/uhid.c,v
retrieving revision 1.58
diff -u -p -r1.58 uhid.c
--- uhid.c  12 Jul 2014 18:48:52 -  1.58
+++ uhid.c  8 Dec 2014 22:54:53 -
@@ -259,7 +259,6 @@ uhid_do_read(struct uhid_softc *sc, stru
 {
int s;
int error = 0;
-   int extra;
size_t length;
u_char buffer[UHID_CHUNK];
usbd_status err;
@@ -267,13 +266,12 @@ uhid_do_read(struct uhid_softc *sc, stru
DPRINTFN(1, (uhidread\n));
if (sc-sc_state  UHID_IMMED) {
DPRINTFN(1, (uhidread immed\n));
-   extra = sc-sc_hdev.sc_report_id != 0;
-   err = uhidev_get_report(sc-sc_hdev, UHID_INPUT_REPORT,
-   sc-sc_hdev.sc_report_id, buffer,
-   sc-sc_hdev.sc_isize + extra);
+   err = uhidev_get_report(sc-sc_hdev.sc_parent,
+   UHID_INPUT_REPORT, sc-sc_hdev.sc_report_id, buffer,
+   sc-sc_hdev.sc_isize, NULL);
if (err)
return (EIO);
-   return (uiomove(buffer+extra, sc-sc_hdev.sc_isize, uio));
+   return (uiomove(buffer, sc-sc_hdev.sc_isize, uio));
}
 
s = splusb();
@@ -346,8 +344,9 @@ uhid_do_write(struct uhid_softc *sc, str
return (EINVAL);
error = uiomove(sc-sc_obuf, size, uio);
if (!error) {
-   err = uhidev_set_report(sc-sc_hdev, UHID_OUTPUT_REPORT,
-   sc-sc_hdev.sc_report_id, sc-sc_obuf, size);
+   err = uhidev_set_report(sc-sc_hdev.sc_parent,
+   UHID_OUTPUT_REPORT, sc-sc_hdev.sc_report_id, sc-sc_obuf,
+   size, NULL);
if (err)
error = EIO;
}
@@ -375,9

Re: Violating randomization standards

2014-12-08 Thread Jonas 'Sortie' Termansen

On 12/09/2014 12:06 AM, Todd C. Miller wrote:
 Which gets cast to a signed integer in that same range...

Except long is larger than 32 bits on 64-bit platforms.

siphash in bgpd

bgpd seemed like a good place to try out the new siphash functions.

Three hash tables are pretty straight forward conversions. Diff below.

rde_rib.c nexthop_hash uses hash32 for ipv6, and a simple xor hash for
ipv4. I left that alone as the diff would be more than mechanical.

red_update.c up_generate also uses hash32 to generate a hint for the
RB tree. I left that alone as well.

Index: rde_attr.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_attr.c,v
retrieving revision 1.92
diff -u -p -r1.92 rde_attr.c
--- rde_attr.c  8 Oct 2014 16:15:37 -   1.92
+++ rde_attr.c  8 Dec 2014 23:45:33 -
@@ -17,7 +17,6 @@
  */
 
 #include sys/types.h
-#include sys/hash.h
 #include sys/queue.h
 
 #include netinet/in.h
@@ -26,6 +25,7 @@
 #include stdlib.h
 #include stdio.h
 #include string.h
+#include siphash.h
 
 #include bgpd.h
 #include rde.h
@@ -99,6 +99,8 @@ struct attr_table {
u_int32_thashmask;
 } attrtable;
 
+SIPHASH_KEY attrtablekey;
+
 #define ATTR_HASH(x)   \
attrtable.hashtbl[(x)  attrtable.hashmask]
 
@@ -107,6 +109,7 @@ attr_init(u_int32_t hashsize)
 {
u_int32_t   hs, i;
 
+   arc4random_buf(attrtablekey, sizeof(attrtablekey));
for (hs = 1; hs  hashsize; hs = 1)
;
attrtable.hashtbl = calloc(hs, sizeof(struct attr_list));
@@ -316,6 +319,7 @@ struct attr *
 attr_alloc(u_int8_t flags, u_int8_t type, const void *data, u_int16_t len)
 {
struct attr *a;
+   SIPHASH_CTX ctx;
 
a = calloc(1, sizeof(struct attr));
if (a == NULL)
@@ -324,9 +328,7 @@ attr_alloc(u_int8_t flags, u_int8_t type
 
flags = ~ATTR_DEFMASK; /* normalize mask */
a-flags = flags;
-   a-hash = hash32_buf(flags, sizeof(flags), HASHINIT);
a-type = type;
-   a-hash = hash32_buf(type, sizeof(type), a-hash);
a-len = len;
if (len != 0) {
if ((a-data = malloc(len)) == NULL)
@@ -338,8 +340,12 @@ attr_alloc(u_int8_t flags, u_int8_t type
} else
a-data = NULL;
 
-   a-hash = hash32_buf(len, sizeof(len), a-hash);
-   a-hash = hash32_buf(a-data, a-len, a-hash);
+   SipHash24_Init(ctx, attrtablekey);
+   SipHash24_Update(ctx, flags, sizeof(flags));
+   SipHash24_Update(ctx, type, sizeof(type));
+   SipHash24_Update(ctx, len, sizeof(len));
+   SipHash24_Update(ctx, a-data, a-len);
+   a-hash = SipHash24_End(ctx);
LIST_INSERT_HEAD(ATTR_HASH(a-hash), a, entry);
 
return (a);
@@ -351,12 +357,16 @@ attr_lookup(u_int8_t flags, u_int8_t typ
struct attr_list*head;
struct attr *a;
u_int32_thash;
+   SIPHASH_CTX ctx;
 
flags = ~ATTR_DEFMASK; /* normalize mask */
-   hash = hash32_buf(flags, sizeof(flags), HASHINIT);
-   hash = hash32_buf(type, sizeof(type), hash);
-   hash = hash32_buf(len, sizeof(len), hash);
-   hash = hash32_buf(data, len, hash);
+
+   SipHash24_Init(ctx, attrtablekey);
+   SipHash24_Update(ctx, flags, sizeof(flags));
+   SipHash24_Update(ctx, type, sizeof(type));
+   SipHash24_Update(ctx, len, sizeof(len));
+   SipHash24_Update(ctx, data, len);
+   hash = SipHash24_End(ctx);
head = ATTR_HASH(hash);
 
LIST_FOREACH(a, head, entry) {
@@ -402,6 +412,8 @@ struct aspath_table {
u_int32_thashmask;
 } astable;
 
+SIPHASH_KEY astablekey;
+
 #define ASPATH_HASH(x) \
astable.hashtbl[(x)  astable.hashmask]
 
@@ -464,6 +476,7 @@ aspath_init(u_int32_t hashsize)
LIST_INIT(astable.hashtbl[i]);
 
astable.hashmask = hs - 1;
+   arc4random_buf(astablekey, sizeof(astablekey));
 }
 
 void
@@ -500,8 +513,8 @@ aspath_get(void *data, u_int16_t len)
memcpy(aspath-data, data, len);
 
/* link */
-   head = ASPATH_HASH(hash32_buf(aspath-data, aspath-len,
-   HASHINIT));
+   head = ASPATH_HASH(SipHash24(astablekey, aspath-data,
+   aspath-len));
LIST_INSERT_HEAD(head, aspath, entry);
}
aspath-refcnt++;
@@ -831,7 +844,7 @@ aspath_lookup(const void *data, u_int16_
struct aspath   *aspath;
u_int32_thash;
 
-   hash = hash32_buf(data, len, HASHINIT);
+   hash = SipHash24(astablekey, data, len);
head = ASPATH_HASH(hash);
 
LIST_FOREACH(aspath, head, entry) {
Index: rde_rib.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_rib.c,v
retrieving revision 1.139
diff -u -p -r1.139 rde_rib.c
--- rde_rib.c   8 Oct 2014 16:15:37 -   1.139
+++ rde_rib.c   8 Dec 2014 23:51:23 -
@@ -22,6 +22,7 @@
 
 #include stdlib.h
 #include string.h
+#include siphash.h
 
 #include bgpd.h
 #include

Re: Violating randomization standards

On Tue, Dec 09, 2014 at 00:00, Jonas 'Sortie' Termansen wrote:
 On 12/08/2014 09:55 PM, Theo de Raadt wrote:
 Index: lib/libc/stdlib/mrand48.c
 ===
 RCS file: /cvs/src/lib/libc/stdlib/mrand48.c,v
 retrieving revision 1.3
 diff -u -p -u -r1.3 mrand48.c
 --- lib/libc/stdlib/mrand48.c8 Aug 2005 08:05:37 -   1.3
 +++ lib/libc/stdlib/mrand48.c8 Dec 2014 03:13:07 -
 @@ -19,6 +19,8 @@ extern unsigned short __rand48_seed[3];
  long
  mrand48(void)
  {
 +if (__rand48_deterministic == 0)
 +return arc4random();
  __dorand48(__rand48_seed);
  return ((long) __rand48_seed[2]  16) + (long) __rand48_seed[1];
  }
 
 POSIX says mrand48 is meant to return signed integers in the interval
 [-2^31,2^31), but this code returns an unsigned 32-bit integer value.

Fixed. Thanks. (I think.) :)

Re: next LibreSSL-portable release coming soon

2014-12-08 Thread Nicolai

On Mon, Dec 08, 2014 at 08:54:08AM -0600, Brent Cook wrote:

 https://github.com/libressl-portable/portable
 
 Please test if you can. Thanks!

Looks good on an amd64 Ubuntu 14.04 machine with gcc 4.8.2:

TOTAL: 44
PASS:  44
SKIP:  0
XFAIL: 0
FAIL:  0
XPASS: 0
ERROR: 0

Nicolai

LibreSSL 2.1.2 released

2014-12-08 Thread Brent Cook

We have released LibreSSL 2.1.2, which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon.

This release greatly improves performance, interoperability and portability,
while continuing to be easy to build and integrate into your software projects.

This release includes:

* Two important cipher suites, GOST and Camellia, have been reworked or
reenabled, providing better interoperability with systems around the world.

* A preview version of the libtls library, a modern and simplified interface
for secure client and server communications, is now packaged and can be
built optionally for testing. Feedback welcome.

* Initial support for Microsoft Windows 32-bit and 64-bit flavors
has been added for mingw-w64 targets. This can be used to generate native
libraries that are usable in other Windows development environments as
well.

* Assembly acceleration of various algorithms for ELF (Linux, BSD, Solaris)
and OS X systems are enabled for x86_64 CPUs. More optimizations may be
enabled in later releases. These optimizations are disabled with the
--disable-asm configure flag.

* The arc4random_buf(3) calls on FreeBSD and OS X are now replaced with
the OpenBSD versions. This fixes current problems with seeding and fork
safety until these OS's built-in implementations can be improved.
See these code commits for details:

https://github.com/libressl-portable/portable/commit/8abf8e1e1577f51deb5c3bc01f076205f1bfb268

https://github.com/libressl-portable/portable/commit/0aeb93b9fc9ecf0f9c2e98444545de485168823d

The LibreSSL project also continues improvement of the codebase to reflect
modern, safe programming practices.

We welcome feedback and improvements from the broader community.
Thanks to all of the contributors who helped make this release possible.

Re: upd(4) buggy firmware