Waiting for 'high priority' events with kqueue
Hi, I'm working on adding support for "high priority" events to a user space event library. Conceptually, I need the equivalent of poll() with POLLPRI, but via kqueue. FreeBSD and Apple OSX provide this via the 'EV_OOBAND' flag to EV_SET. However, OpenBSD (and NetBSD) do not. Is there a way to wait for "high priority" events with kqueue on OpenBSD? I had a read through various kernel sources, but didn't manage to find anything. Could OpenBSD add support for the EV_OOBAND flag? Who is responsible for these sorts of things? -- Daurnimator PS, I'm not an OpenBSD user myself, I'm just trying to keep a cross-platform library cross-platform. PPS, I'm not subscribed to the list, please ensure you Cc me on replies.
PF support for IPv6 Extension Headers
Folks, What's the level f support of PF wrt IPv6 Extension Headers? pf.conf(5) talks about an implicit block rule for packets employing the routing header, but I've not been able to find anything about e.g., * Filtering packets on a per-EH-type-occurrence (e.g. "block packets that contain a Destination Options Header") * Filtering packets base on the EH size * Filtering packets based on the number of EHs they contain (e.g., drop the packet if it employs more than 5 EHs) etc. Thoughts? Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
explicit_bzero in pkcs5_pbkdf2
The intermediate values calculated in hmac_sha1 as part of pkcs5_pbkdf2 are not zeroed afterwards, so we leak a single-hashed version of the key on the stack in tk[]. Also, the correct RFC defining this is RFC 2104 - HMAC: Keyed-Hashing for Message Authentication not RFC 2202 - Test Cases for HMAC-MD5 and HMAC-SHA-1 >From RFC 2104, section 4, paragraph 2: "We stress that the stored intermediate values need to be treated and protected the same as secret keys." So it's not just best-practice dictating that these should be bzeroed. Here is a patch for the same code in libutil and libsa. Index: lib/libutil/pkcs5_pbkdf2.c === RCS file: /cvs/src/lib/libutil/pkcs5_pbkdf2.c,v retrieving revision 1.9 diff -u -p -d -r1.9 pkcs5_pbkdf2.c --- lib/libutil/pkcs5_pbkdf2.c 5 Feb 2015 12:59:57 - 1.9 +++ lib/libutil/pkcs5_pbkdf2.c 10 Jun 2015 19:59:09 - @@ -28,7 +28,7 @@ #defineMINIMUM(a,b) (((a) < (b)) ? (a) : (b)) /* - * HMAC-SHA-1 (from RFC 2202). + * HMAC-SHA-1 (from RFC 2104). */ static void hmac_sha1(const u_int8_t *text, size_t text_len, const u_int8_t *key, @@ -67,6 +67,10 @@ hmac_sha1(const u_int8_t *text, size_t t SHA1Update(&ctx, k_pad, SHA1_BLOCK_LENGTH); SHA1Update(&ctx, digest, SHA1_DIGEST_LENGTH); SHA1Final(digest, &ctx); + + explicit_bzero(&ctx, sizeof(ctx)); + explicit_bzero(k_pad, sizeof(k_pad)); + explicit_bzero(tk, sizeof(tk)); } /* Index: sys/lib/libsa/hmac_sha1.c === RCS file: /cvs/src/sys/lib/libsa/hmac_sha1.c,v retrieving revision 1.1 diff -u -p -d -r1.1 hmac_sha1.c --- sys/lib/libsa/hmac_sha1.c 9 Oct 2012 12:36:50 - 1.1 +++ sys/lib/libsa/hmac_sha1.c 10 Jun 2015 19:58:39 - @@ -23,7 +23,7 @@ #include "hmac_sha1.h" /* - * HMAC-SHA-1 (from RFC 2202). + * HMAC-SHA-1 (from RFC 2104). */ void hmac_sha1(const u_int8_t *text, size_t text_len, const u_int8_t *key, @@ -62,4 +62,8 @@ hmac_sha1(const u_int8_t *text, size_t t SHA1Update(&ctx, k_pad, SHA1_BLOCK_LENGTH); SHA1Update(&ctx, digest, SHA1_DIGEST_LENGTH); SHA1Final(digest, &ctx); + + explicit_bzero(&ctx, sizeof(ctx)); + explicit_bzero(k_pad, sizeof(k_pad)); + explicit_bzero(tk, sizeof(tk)); }
Re: Simple upd(4) sensors
On Wed, Jun 10, 2015 at 5:23 AM, Martin Pieuchot wrote: > On 02/06/15(Tue) 22:36, David Higgs wrote: > > Here are some new sensors for upd(4) devices. All exist on my device > except AtRateTimeToEmpty, which still seemed a logical addition given that > AtRateTimeToFull is already present. > > - AtRateTimeToEmpty > > - RunTimeToEmpty > > - NeedReplacement > > - Overload > > Nice. > > > If anyone had an AtRate sensor, it was probably producing meaningless > output. The relevant spec [0] indicates that these are in minutes, and my > device appears to be using seconds; the (previously unscaled) sensor value > expects nanoseconds! > > [0] http://www.usb.org/developers/hidpage/pdcv10.pdf > > > > And lastly, the NeedReplacement report has nothing to do with the System > Management Bus (SMB), so rename the constant. Nothing else in the tree > appears to use it, so hopefully this is safe. > > > > Feedback and lsusb -v output is welcome, as usual. > > Have you got any feedback from upd(4) users? > > Not as of yet. Theo reminded me that upd(4) usability needs to improve, so before I add any more sensors I will next be looking into man page updates and/or improved sensor status (e.g. WARN, CRITICAL) so that you need less configuration voodoo to get useful behavior out of sensorsd(8). Let me know if these new sensors should wait, in which case I can cut a separate diff for the other fixes and build upon that instead. --david
Re: [patch]rcs: xstrdup just wrappes strdup
On Wed, May 20, 2015 at 10:55:34AM +0200, Fritjof Bornebusch wrote:
> On Tue, May 19, 2015 at 08:57:06PM +0200, Fritjof Bornebusch wrote:
> > Hi,
> >
> > xstrdup just wrappes strdup, so there is no need to call xmalloc and
> > strlcpy instead.
> >
>
Ping
> Use err() instead of errx(), so errno will be printed additionally.
> Thanks to Tim.
>
> > Regards,
> > --F.
> >
> >
>
> Regards,
> --F.
>
> >
>
>
> Index: xmalloc.c
> ===
> RCS file: /cvs/src/usr.bin/rcs/xmalloc.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 xmalloc.c
> --- xmalloc.c 26 Mar 2015 15:17:30 - 1.8
> +++ xmalloc.c 20 May 2015 08:53:01 -
> @@ -76,13 +76,11 @@ xfree(void *ptr)
> char *
> xstrdup(const char *str)
> {
> - size_t len;
> char *cp;
>
> - len = strlen(str) + 1;
> - cp = xmalloc(len);
> - if (strlcpy(cp, str, len) >= len)
> - errx(1, "xstrdup: string truncated");
> + if ((cp = strdup(str)) == NULL)
> + err(1, "xstrdup: copy string failed");
> +
> return cp;
> }
>
pgp1q6Ck8BKwd.pgp
Description: PGP signature
Double free in trunk(4)
During clone/destroy stress tests on pseudo-interfaces I found a double
free easily reproducible with dhclient(8) running on top of a trunk(4).
The problem comes from trunk_ether_delmulti() which is almost identical
to carp's version except that it always free "mc".
So when you do "# ifconfig trunk0 destroy" the kernel first brings the
interface down and generates a routing message. dhclient(8) receives
this message and removes the address it's configured on trunk0 and with
it the "default multicast group". If dhclient(8) lose the race, it will
fail to remove the multicast address but it will free "mc"!
Then ifconfig's thread which was asleep in trunk_ether_purgemulti() ->
trunk_ioctl_allports() wakes up and tries to free "mc" a second time:
uvm_fault(0xd5647bd0, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at trunk_ether_purgemulti+0xc2:movl0x104(%edx),%eax
ddb> tr
trunk_ether_purgemulti(d131b800,d131b800,0,d041d091,0) at trunk_ether_purgemult
i+0xc2
trunk_clone_destroy(d131b800,0,f3766dec,d1064e94,f3766ef4) at trunk_clone_destr
oy+0x16
ifioctl(d54d10f0,80206979,f3766e84,d54a42dc,2) at ifioctl+0x232
sys_ioctl(d54a42dc,f3766f60,f3766f80,d0566f17,d54a42dc) at sys_ioctl+0x257
syscall() at syscall+0x247
Here's a simple fix that also reduces the differences with carp's
version. ok?
Index: net/if_trunk.c
===
RCS file: /cvs/src/sys/net/if_trunk.c,v
retrieving revision 1.101
diff -u -p -r1.101 if_trunk.c
--- net/if_trunk.c 9 Jun 2015 14:50:14 - 1.101
+++ net/if_trunk.c 10 Jun 2015 15:30:10 -
@@ -857,18 +857,20 @@ trunk_ether_delmulti(struct trunk_softc
if ((error = ether_delmulti(ifr, &tr->tr_ac)) != ENETRESET)
return (error);
- if ((error = trunk_ioctl_allports(tr, SIOCDELMULTI,
- (caddr_t)ifr)) != 0) {
+ /* We no longer use this multicast address. Tell parent so. */
+ error = trunk_ioctl_allports(tr, SIOCDELMULTI, (caddr_t)ifr);
+ if (error == 0) {
+ SLIST_REMOVE(&tr->tr_mc_head, mc, trunk_mc, mc_entries);
+ free(mc, M_DEVBUF, sizeof(*mc));
+ } else {
/* XXX At least one port failed to remove the address */
if (tr->tr_ifflags & IFF_DEBUG) {
printf("%s: failed to remove multicast address "
- "on all ports\n", tr->tr_ifname);
+ "on all ports (%d)\n", tr->tr_ifname, error);
}
+ (void)ether_addmulti(ifr, &tr->tr_ac);
}
- SLIST_REMOVE(&tr->tr_mc_head, mc, trunk_mc, mc_entries);
- free(mc, M_DEVBUF, 0);
-
return (0);
}
@@ -886,7 +888,7 @@ trunk_ether_purgemulti(struct trunk_soft
trunk_ioctl_allports(tr, SIOCDELMULTI, (caddr_t)ifr);
SLIST_REMOVE(&tr->tr_mc_head, mc, trunk_mc, mc_entries);
- free(mc, M_DEVBUF, 0);
+ free(mc, M_DEVBUF, sizeof(*mc));
}
}
LibreSSL & 2038 problem
Hi folks, I read that 64-bit time issues have been fixed in LibreSSL, and that it is 2038 ready. We need to create certificates on 64-bit systems using RFC3779 that are valid beyond year 2038. RFC3779 support was removed in LibreSSL, back in release 2.1.4. I was wondering if there would be argument against bringing back RFC3779 ? Kind regards, //Logan C-x-C-c
Re: samba4 slow startup, shared libs?
On 2015/06/05 13:27, Mark Kettenis wrote: > > Date: Fri, 5 Jun 2015 11:15:38 +0100 > > From: Stuart Henderson > > > > net/samba4 is in the ports tree but not currently enabled in the build, > > we're still only using samba 3.x for various reasons, but unfortunately > > samba 3 is getting decreasingly useful as more Windows setups move to > > newer versions. > > > > One of the issues is that startup of samba4 on OpenBSD is very slow > > indeed, seemingly before control is transferred to the program. From > > the LD_DEBUG output with timestamps (using the very handy ts(1) from > > "moreutils"): > > > > # LD_DEBUG=1 smbd -D 2>&1 | ts %.s > > <..snip..> > > 1433498513.546306 examining: '/usr/local/lib/libhogweed.so.1.1' > > 1433498513.546323 loading: libnettle.so.1.2 required by > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546339 loading: libgmp.so.9.0 required by > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546354 linking dep /usr/local/lib/libnettle.so.1.2 as child of > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546370 linking dep /usr/local/lib/libgmp.so.9.0 as child of > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546386 examining: '/usr/local/lib/libgmp.so.9.0' > > 1433498584.125659 flags /usr/libexec/ld.so = 0x0 > > 1433498584.125783 obj /usr/libexec/ld.so has smbd as head > > 1433498584.149165 relocation took 0.023504 > > 1433498584.149215 StartEnd Type Open Ref > > GrpRef Name > > 1433498584.149249 04bec650 04bec691 exe 10 0 > >smbd > > 1433498584.149272 04c19b74e000 04c19bb6 rlib 0107 0 > > /usr/lib/libpthread.so.19.0 > > 1433498584.149293 04c18f3df000 04c18f812000 rlib 075 0 > > /usr/local/lib/libsamba-util.so.0.0 > > <..snip..> > > > > - a 74 second delay after "examining: '/usr/local/lib/libgmp.so.9.0'". > > Does anyone have suggestions for finding out what's going on here? > > Full text snipped from the above is at > > http://junkpile.org/samba4-lddebug.txt > > My first guess would have been that it is spending a lot of time on > initial relocations. But the line: > > 1433498584.149165 relocation took 0.023504 > > pretty much rules that out. My suggestion would be to add a few more > DL_DEB() statements inside of ld.so/loader.c:_dl_boot(), starting just > after the _dl_load_dep_libs() call in that function and try to narrow > it down. > The part taking the biggest chunk of time is _dl_cache_grpsym_list() with its recursive calls (64 seconds). 1433936487.139917 _dl_cache_grpsym_list: 1433936551.414114 _dl_cache_grpsym_list:done ctors for libpthread are fairly slow too (35 seconds) but I think that's out of ld.so's hands. ... 1433936551.538493 _dl_debug_state done 1433936551.538508 doing ctors obj 0x138a43269400 @0x138a74fe0ca0: [/usr/lib/libpthread.so.19.0] 1433936587.157910 doing ctors obj 0x138ae5e30800 @0x138af0447f80: [/usr/local/lib/samba/libreplace.so.0.0] ...
Re: don't error for duplicate identical type definitions
> Any objections?
Considering I am the one who requested it, obviously no objection :-)
I've successfully tested this with ports that used to need ports/lang/gcc/4.9 .
So as far as I am concerned, OK for me.
> Index: c-decl.c
> ===
> RCS file: /OpenBSD/src/gnu/gcc/gcc/c-decl.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 c-decl.c
> --- c-decl.c 29 Apr 2010 18:37:37 - 1.2
> +++ c-decl.c 2 May 2015 14:35:28 -
> @@ -1285,9 +1285,17 @@ diagnose_mismatched_decls (tree newdecl,
>if (DECL_IN_SYSTEM_HEADER (newdecl) || DECL_IN_SYSTEM_HEADER (olddecl))
> return true; /* Allow OLDDECL to continue in use. */
>
> - error ("redefinition of typedef %q+D", newdecl);
> - locate_old_decl (olddecl, error);
> - return false;
> + if (pedantic)
> + {
> + pedwarn ("redefinition of typedef %q+D", newdecl);
> + if (flag_pedantic_errors)
> + {
> + locate_old_decl (olddecl, error);
> + return false;
> + }
> + }
> +
> + return true;
> }
>
>/* Function declarations can either be 'static' or 'extern' (no
>
--
Antoine
Re: Simple upd(4) sensors
On 02/06/15(Tue) 22:36, David Higgs wrote:
> Here are some new sensors for upd(4) devices. All exist on my device except
> AtRateTimeToEmpty, which still seemed a logical addition given that
> AtRateTimeToFull is already present.
> - AtRateTimeToEmpty
> - RunTimeToEmpty
> - NeedReplacement
> - Overload
Nice.
> If anyone had an AtRate sensor, it was probably producing meaningless output.
> The relevant spec [0] indicates that these are in minutes, and my device
> appears to be using seconds; the (previously unscaled) sensor value expects
> nanoseconds!
> [0] http://www.usb.org/developers/hidpage/pdcv10.pdf
>
> And lastly, the NeedReplacement report has nothing to do with the System
> Management Bus (SMB), so rename the constant. Nothing else in the tree
> appears to use it, so hopefully this is safe.
>
> Feedback and lsusb -v output is welcome, as usual.
Have you got any feedback from upd(4) users?
> --- a/upd.c
> +++ b/upd.c
> @@ -66,7 +66,13 @@ static struct upd_usage_entry upd_usage_
> { HUP_BATTERY, HUB_DISCHARGING,
> SENSOR_INDICATOR,"Discharging" },
> { HUP_BATTERY, HUB_ATRATE_TIMETOFULL,
> - SENSOR_TIMEDELTA,"AtRateTimeToFull" }
> + SENSOR_TIMEDELTA,"AtRateTimeToFull" },
> + { HUP_BATTERY, HUB_ATRATE_TIMETOEMPTY,
> + SENSOR_TIMEDELTA,"AtRateTimeToEmpty" },
> + { HUP_BATTERY, HUB_RUNTIMETO_EMPTY,
> + SENSOR_TIMEDELTA,"RunTimeToEmpty" },
> + { HUP_BATTERY, HUB_NEED_REPLACEMENT,
> + SENSOR_INDICATOR,"NeedReplacement" },
> };
> static struct upd_usage_entry upd_usage_roots[] = {
> { HUP_BATTERY, HUB_BATTERY_PRESENT,
> @@ -75,7 +81,9 @@ static struct upd_usage_entry upd_usage_
> { HUP_POWER,HUP_SHUTDOWN_IMMINENT,
> SENSOR_INDICATOR,"ShutdownImminent" },
> { HUP_BATTERY, HUB_AC_PRESENT,
> - SENSOR_INDICATOR,"ACPresent" }
> + SENSOR_INDICATOR,"ACPresent" },
> + { HUP_POWER,HUP_OVERLOAD,
> + SENSOR_INDICATOR,"Overload" },
> };
> #define UPD_MAX_SENSORS (nitems(upd_usage_batdep) +
> nitems(upd_usage_roots))
>
> @@ -410,6 +418,12 @@ upd_sensor_update(struct upd_softc *sc,
> case HUB_FULLCHARGE_CAPACITY:
> adjust = 1000; /* scale adjust */
> break;
> + case HUB_ATRATE_TIMETOFULL:
> + case HUB_ATRATE_TIMETOEMPTY:
> + case HUB_RUNTIMETO_EMPTY:
> + /* spec says minutes, not seconds */
> + adjust = 10LL;
> + break;
> default:
> adjust = 1; /* no scale adjust */
> break;
> --- a/usbhid.h
> +++ b/usbhid.h
> @@ -213,7 +213,7 @@ struct usb_hid_descriptor {
> #define HUB_CONDITIONING_FLAG0x0048
> #define HUB_ATRATE_OK0x0049
> #define HUB_SMB_ERROR_CODE 0x004a
> -#define HUB_SMB_NEED_REPLACE 0x004b
> +#define HUB_NEED_REPLACEMENT 0x004b
> #define HUB_ATRATE_TIMETOFULL0x0060
> #define HUB_ATRATE_TIMETOEMPTY 0x0061
> #define HUB_AVERAGE_CURRENT 0x0062
>
>
teach binutils about more arm barrier options
The barrier instructions were introduced with armv7, armv6 had
coprocessor style barriers.
The un/unst options are listed under "alternative values of option are
supported for DMB and DSB, but ARM recommends that you do not use them"
in the documentation.
This also allows non "sy"/0xf options for dmb instructions instead
of only dsb.
Index: gas/config/tc-arm.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/gas/config/tc-arm.c,v
retrieving revision 1.3
diff -u -p -r1.3 tc-arm.c
--- gas/config/tc-arm.c 22 Aug 2012 14:39:43 - 1.3
+++ gas/config/tc-arm.c 10 Jun 2015 07:01:20 -
@@ -4661,6 +4661,7 @@ do_barrier (void)
if (inst.operands[0].present)
{
constraint ((inst.instruction & 0xf0) != 0x40
+ && (inst.instruction & 0xf0) != 0x50
&& inst.operands[0].imm != 0xf,
"bad barrier type");
inst.instruction |= inst.operands[0].imm;
@@ -6555,6 +6556,7 @@ do_t_barrier (void)
if (inst.operands[0].present)
{
constraint ((inst.instruction & 0xf0) != 0x40
+ && (inst.instruction & 0xf0) != 0x50
&& inst.operands[0].imm != 0xf,
"bad barrier type");
inst.instruction |= inst.operands[0].imm;
@@ -8826,10 +8828,20 @@ static const struct asm_cond conds[] =
static struct asm_barrier_opt barrier_opt_names[] =
{
- { "sy", 0xf },
- { "un", 0x7 },
- { "st", 0xe },
- { "unst", 0x6 }
+ { "oshld", 0x1 },
+ { "oshst", 0x2 },
+ { "osh", 0x3 },
+ { "nshld", 0x5 },
+ { "nshst", 0x6 },
+ { "unst", 0x6 },
+ { "nsh", 0x7 },
+ { "un",0x7 },
+ { "ishld", 0x9 },
+ { "ishst", 0xa },
+ { "ish", 0xb },
+ { "ld",0xd },
+ { "st",0xe },
+ { "sy",0xf }
};
/* Table of ARM-format instructions. */
Index: opcodes/arm-dis.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/opcodes/arm-dis.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 arm-dis.c
--- opcodes/arm-dis.c 24 Apr 2011 20:14:49 - 1.1.1.1
+++ opcodes/arm-dis.c 10 Jun 2015 07:01:22 -
@@ -1951,10 +1951,18 @@ print_insn_arm (bfd_vma pc, struct disas
case 'U':
switch (given & 0xf)
{
- case 0xf: func(stream, "sy"); break;
- case 0x7: func(stream, "un"); break;
+ case 0x1: func(stream, "oshld"); break;
+ case 0x2: func(stream, "oshst"); break;
+ case 0x3: func(stream, "osh"); break;
+ case 0x5: func(stream, "nshld"); break;
+ case 0x6: func(stream, "nshst"); break;
+ case 0x7: func(stream, "nsh"); break;
+ case 0x9: func(stream, "ishld"); break;
+ case 0xa: func(stream, "ishst"); break;
+ case 0xb: func(stream, "ish"); break;
+ case 0xd: func(stream, "ld"); break;
case 0xe: func(stream, "st"); break;
- case 0x6: func(stream, "unst"); break;
+ case 0xf: func(stream, "sy"); break;
default:
func(stream, "#%d", (int)given & 0xf);
break;
@@ -2713,10 +2721,18 @@ print_insn_thumb32 (bfd_vma pc, struct d
case 'U':
switch (given & 0xf)
{
- case 0xf: func(stream, "sy"); break;
- case 0x7: func(stream, "un"); break;
+ case 0x1: func(stream, "oshld"); break;
+ case 0x2: func(stream, "oshst"); break;
+ case 0x3: func(stream, "osh"); break;
+ case 0x5: func(stream, "nshld"); break;
+ case 0x6: func(stream, "nshst"); break;
+ case 0x7: func(stream, "nsh"); break;
+ case 0x9: func(stream, "ishld"); break;
+ case 0xa: func(stream, "ishst"); break;
+ case 0xb: func(stream, "ish"); break;
+ case 0xd: func(stream, "ld"); break;
case 0xe: func(stream, "st"); break;
- case 0x6: func(stream, "unst"); break;
+ case 0xf: func(stream, "sy"); break;
default:
func(stream, "#%d", (int)given & 0xf);
break;
