Re: libtls: Secure default cipher list and dtls support
On Fr, 2014-11-28 at 03:42 +1100, Joel Sing wrote: > On Thu, 27 Nov 2014, Manuel Schoelling wrote: > [...] > > I also noticed that libtls is currently supporting SOCK_STREAM (TLS) > > connections only. Is the support of SOCK_DGRAM (DTLS) connections within > > the scope of this library and would patches be accepted? > > I do not have any objection to supporting datagram sockets, however it is not > a primary interest/focus and there are many things that would likely get > implemented prior to looking at it. That said, if you have a use case for it > and can make it fit with the API, we'll happy review diffs. I implemented DTLS support now and it fits quite well to the current API. A few days ago I opened a pull request on github [1] since I've seen that other patches were applied to libressl in the same manner. If you guys prefer patches via mailing list let me know. It would be great to get some feedback to the patch, to hear what I can improve it and to see what the chances are for you to apply this patch. Thanks! Manuel [1] https://github.com/libressl-portable/openbsd/pull/17
Re: Kernel does not compile with option LOCKDEBUG
On Sat, 10 Jan 2015 19:39:19 -0800
Philip Guenther wrote:
> On Mon, 5 Jan 2015, Helg wrote:
> > The man page for LOCK(9) says that if the kernel option LOCKDEBUG is
> > enabled, additional facilities are provided to assist in determining
> > deadlock occurrences.
> >
> > I created a copy of /sys/arch/amd64/conf/GENERIC and added option
> > LOCKDEBUG. Executing config and then make clean && make results in
> > warnings like:
> >
> > implicit declaration of function '__mp_lock'
> >
> > Adding includes for in the offending files resolves the
> > problem but this just doesn't seem right.
> >
> > Does anyone have any suggestions?
>
> Yeah, don't use it. It used to be a lot more when there were still traces
> of the original "simplelocks" in the tree, but the code to do more with
> LOCKDEBUG was ripped out as those no-ops were felt to be more misleading
> than helpful.
>
> It's dead, Jim, let's bury LOCKDEBUG.
>
> oks?
>
>
> Philip
>
> Index: sys/arch/i386/i386/trap.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/trap.c,v
> retrieving revision 1.119
> diff -u -p -r1.119 trap.c
> --- sys/arch/i386/i386/trap.c 2 Dec 2014 18:13:10 - 1.119
> +++ sys/arch/i386/i386/trap.c 11 Jan 2015 03:33:48 -
> @@ -381,11 +381,6 @@ trap(struct trapframe *frame)
> case T_PAGEFLT: /* allow page faults in kernel mode */
> if (p == 0 || p->p_addr == 0)
> goto we_re_toast;
> -#ifdef LOCKDEBUG
> - /* If we page-fault while in scheduler, we're doomed. */
> - if (__mp_lock_held(&sched_lock))
> - goto we_re_toast;
> -#endif
>
> pcb = &p->p_addr->u_pcb;
> #if 0
> Index: sys/sys/sched.h
> ===
> RCS file: /cvs/src/sys/sys/sched.h,v
> retrieving revision 1.37
> diff -u -p -r1.37 sched.h
> --- sys/sys/sched.h 17 Oct 2014 01:51:39 - 1.37
> +++ sys/sys/sched.h 11 Jan 2015 03:33:48 -
> @@ -183,7 +183,7 @@ void remrunqueue(struct proc *);
> yield();\
> } while (0)
>
> -#if defined(MULTIPROCESSOR) || defined(LOCKDEBUG)
> +#if defined(MULTIPROCESSOR)
> #include
>
> /*
> @@ -215,7 +215,7 @@ do {
> \
> splx(s);\
> } while (/* CONSTCOND */ 0)
>
> -#else /* ! MULTIPROCESSOR || LOCKDEBUG */
> +#else /* ! MULTIPROCESSOR */
>
> #define SCHED_ASSERT_LOCKED() splassert(IPL_SCHED);
> #define SCHED_ASSERT_UNLOCKED() /* nothing */
> @@ -225,7 +225,7 @@ do {
> \
> #define SCHED_LOCK(s) s = splsched()
> #define SCHED_UNLOCK(s) splx(s)
>
> -#endif /* MULTIPROCESSOR || LOCKDEBUG */
> +#endif /* MULTIPROCESSOR */
>
> #endif /* _KERNEL */
> #endif /* _SYS_SCHED_H_ */
> Index: share/man/man9/lock.9
> ===
> RCS file: /cvs/src/share/man/man9/lock.9,v
> retrieving revision 1.22
> diff -u -p -r1.22 lock.9
> --- share/man/man9/lock.9 9 Jul 2014 14:16:10 - 1.22
> +++ share/man/man9/lock.9 11 Jan 2015 03:33:48 -
> @@ -57,10 +57,6 @@ single process.
> It also allows upgrading a shared-access lock to an
> exclusive-access lock, as well as downgrading an exclusive-access lock
> to a shared-access lock.
> -.Pp
> -If the kernel option LOCKDEBUG is enabled, additional facilities
> -are provided to record additional lock information.
> -These facilities are provided to assist in determining deadlock occurrences.
> .Sh FUNCTIONS
> The functions which operate on locks are:
> .Bl -tag -width Ds
There's another documentation bug on this man page. The flags parameter
to lockinit can only be 0. If you set it to anything other than this
you end up with a failed KASSERT.
--
Helg
Re: [PATCH] ukbd.c update for older macbook airs
Hey, any interest?
On 12/12/2014 08:29 PM, William Orr wrote:
> Hey,
>
> On some macbook airs, the function keys have different functionality when the
> Fn key is pressed. I've added an additional munge function to handle these
> particular cases.
>
> Thanks,
> William Orr
>
> Index: sys/dev/usb/ukbd.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
> retrieving revision 1.69
> diff -u -b -w -p -r1.69 ukbd.c
> --- sys/dev/usb/ukbd.c11 Dec 2014 18:39:27 - 1.69
> +++ sys/dev/usb/ukbd.c13 Dec 2014 04:18:55 -
> @@ -180,6 +180,7 @@ struct ukbd_translation {
> void ukbd_gdium_munge(void *, uint8_t *, u_int);
> #endif
> void ukbd_apple_munge(void *, uint8_t *, u_int);
> +void ukbd_apple_mba_munge(void *, uint8_t *, u_int);
> void ukbd_apple_iso_munge(void *, uint8_t *, u_int);
> uint8_t ukbd_translate(const struct ukbd_translation *, size_t,
> uint8_t);
>
> @@ -244,13 +245,29 @@ ukbd_attach(struct device *parent, struc
> if (hid_locate(desc, dlen, HID_USAGE2(HUP_APPLE, HUG_FN_KEY),
> uha->reportid, hid_input, &sc->sc_apple_fn, &qflags)) {
> if (qflags & HIO_VARIABLE) {
> + /* Older Macbook Air's have different fn key
> layouts */
> if (iso)
> sc->sc_munge = ukbd_apple_iso_munge;
> - else
> + else {
> + switch (uha->uaa->product) {
> + case
> USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
> + case
> USB_PRODUCT_APPLE_WELLSPRING4A_ISO:
> + case
> USB_PRODUCT_APPLE_WELLSPRING4A_JIS:
> + case
> USB_PRODUCT_APPLE_WELLSPRING4_ANSI:
> + case
> USB_PRODUCT_APPLE_WELLSPRING4_ISO:
> + case
> USB_PRODUCT_APPLE_WELLSPRING4_JIS:
> + case
> USB_PRODUCT_APPLE_WELLSPRING_ANSI:
> + case
> USB_PRODUCT_APPLE_WELLSPRING_ISO:
> + case
> USB_PRODUCT_APPLE_WELLSPRING_JIS:
> + sc->sc_munge =
> ukbd_apple_mba_munge;
> + break;
> + default:
> sc->sc_munge = ukbd_apple_munge;
> }
> }
> }
> + }
> + }
>
> if (uha->uaa->vendor == USB_VENDOR_TOPRE &&
> uha->uaa->product == USB_PRODUCT_TOPRE_HHKB) {
> @@ -478,6 +495,52 @@ ukbd_apple_munge(void *vsc, uint8_t *ibu
> { 67, 127 },/* F10 -> audio mute */
> { 68, 129 },/* F11 -> audio lower */
> { 69, 128 },/* F12 -> audio raise */
> +#endif
> + { 79, 77 }, /* right -> end */
> + { 80, 74 }, /* left -> home */
> + { 81, 78 }, /* down -> page down */
> + { 82, 75 } /* up -> page up */
> + };
> +
> + if (!hid_get_data(ibuf, ilen, &sc->sc_apple_fn))
> + return;
> +
> + spos = ibuf + kbd->sc_keycodeloc.pos / 8;
> + epos = spos + kbd->sc_nkeycode;
> +
> + for (pos = spos; pos != epos; pos++) {
> + xlat = ukbd_translate(apple_fn_trans,
> + nitems(apple_fn_trans), *pos);
> + if (xlat != 0)
> + *pos = xlat;
> + }
> +}
> +
> +void
> +ukbd_apple_mba_munge(void *vsc, uint8_t *ibuf, u_int ilen)
> +{
> + struct ukbd_softc *sc = vsc;
> + struct hidkbd *kbd = &sc->sc_kbd;
> + uint8_t *pos, *spos, *epos, xlat;
> +
> + static const struct ukbd_translation apple_fn_trans[] = {
> + { 40, 73 }, /* return -> insert */
> + { 42, 76 }, /* backspace -> delete */
> +#ifdef notyet
> + { 58, 0 }, /* F1 -> screen brightness down */
> + { 59, 0 }, /* F2 -> screen brightness up */
> + { 60, 0 }, /* F3 */
> + { 61, 0 }, /* F4 */
> + { 62, 0 }, /* F5 */
> + { 63, 0 }, /* F6 -> audio back */
> + { 64, 0 }, /* F7 -> audio pause/play */
> + { 65, 0 }, /* F8 -> audio next */
> +#endif
> + { 66, 127 },/* F9 -> audio mute */
> + { 67, 129 },/* F10 -> audio lower */
> + { 68, 128 },/* F11 -> audio raise */
> +#ifdef notyet
> + { 69, 0 }, /* F12 -> eject */
> #endif
> { 79, 77 }, /* right -> end */
> { 80, 74 }, /* left -> home */
>
signature.asc
Descri
Re: [PATCH] ukbd.c update for older macbook airs
> On Jan 13, 2015, at 9:15 AM, William Orr wrote:
>
> Hey, any interest?
>
> On 12/12/2014 08:29 PM, William Orr wrote:
>> Hey,
>>
>> On some macbook airs, the function keys have different functionality when the
>> Fn key is pressed. I've added an additional munge function to handle these
>> particular cases.
>>
>> Thanks,
>> William Orr
>>
>> Index: sys/dev/usb/ukbd.c
>> ===
>> RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
>> retrieving revision 1.69
>> diff -u -b -w -p -r1.69 ukbd.c
>> --- sys/dev/usb/ukbd.c 11 Dec 2014 18:39:27 - 1.69
>> +++ sys/dev/usb/ukbd.c 13 Dec 2014 04:18:55 -
>> @@ -180,6 +180,7 @@ struct ukbd_translation {
>> void ukbd_gdium_munge(void *, uint8_t *, u_int);
>> #endif
>> void ukbd_apple_munge(void *, uint8_t *, u_int);
>> +voidukbd_apple_mba_munge(void *, uint8_t *, u_int);
>> void ukbd_apple_iso_munge(void *, uint8_t *, u_int);
>> uint8_t ukbd_translate(const struct ukbd_translation *, size_t,
>> uint8_t);
>>
>> @@ -244,13 +245,29 @@ ukbd_attach(struct device *parent, struc
>> if (hid_locate(desc, dlen, HID_USAGE2(HUP_APPLE, HUG_FN_KEY),
>> uha->reportid, hid_input, &sc->sc_apple_fn, &qflags)) {
>> if (qflags & HIO_VARIABLE) {
>> +/* Older Macbook Air's have different fn key
>> layouts */
Not sure that comment belongs here
>> if (iso)
>> sc->sc_munge = ukbd_apple_iso_munge;
>> -else
>> +else {
>> +switch (uha->uaa->product) {
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING4A_ISO:
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING4A_JIS:
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING4_ANSI:
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING4_ISO:
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING4_JIS:
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING_ANSI:
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING_ISO:
>> +case
>> USB_PRODUCT_APPLE_WELLSPRING_JIS:
Any special remaping for *ISO (e.g. one that was done for FOUNTAIN_ISO and
GEYSER_ISO)?
Remaping for JIS?
>> +sc->sc_munge =
>> ukbd_apple_mba_munge;
>> +break;
>> +default:
>> sc->sc_munge = ukbd_apple_munge;
That code probably can be restructured to support multiple types (ISO, JIS and
ANSI) for multiple keyboard versions (WELLSPRING*/FOUNTAIN/GEYSER)
>> }
>> }
>> }
>> +}
>> +}
>>
>> if (uha->uaa->vendor == USB_VENDOR_TOPRE &&
>> uha->uaa->product == USB_PRODUCT_TOPRE_HHKB) {
>> @@ -478,6 +495,52 @@ ukbd_apple_munge(void *vsc, uint8_t *ibu
>> { 67, 127 },/* F10 -> audio mute */
>> { 68, 129 },/* F11 -> audio lower */
>> { 69, 128 },/* F12 -> audio raise */
>> +#endif
>> +{ 79, 77 }, /* right -> end */
>> +{ 80, 74 }, /* left -> home */
>> +{ 81, 78 }, /* down -> page down */
>> +{ 82, 75 } /* up -> page up */
>> +};
>> +
>> +if (!hid_get_data(ibuf, ilen, &sc->sc_apple_fn))
>> +return;
>> +
>> +spos = ibuf + kbd->sc_keycodeloc.pos / 8;
>> +epos = spos + kbd->sc_nkeycode;
>> +
>> +for (pos = spos; pos != epos; pos++) {
>> +xlat = ukbd_translate(apple_fn_trans,
>> +nitems(apple_fn_trans), *pos);
>> +if (xlat != 0)
>> +*pos = xlat;
>> +}
there are 3 instances of similar code there now. maybe should be moved to a
function.
>> +}
>> +
>> +void
>> +ukbd_apple_mba_munge(void *vsc, uint8_t *ibuf, u_int ilen)
>> +{
>> +struct ukbd_softc *sc = vsc;
>> +struct hidkbd *kbd = &sc->sc_kbd;
>> +uint8_t *pos, *spos, *epos, xlat;
>> +
>> +static const struct ukbd_translation apple_fn_trans[] = {
apple_fn_mba_trans?
>> +{ 40, 73 }, /* return -> insert */
>> +{ 42, 76 }, /* backspace -> delete */
>> +#ifdef notyet
>> +{ 58, 0 }, /* F1 -> screen brightness down */
>> +{ 59, 0 }, /* F2 -> screen brightness up */
>> +{ 60, 0 }, /* F3 */
>> +{ 61, 0 }, /* F4 */
>> +{ 62, 0 }, /* F5 */
>> +{ 63, 0 }, /* F6 -> audio bac
ntpd: switch drift file to ppm
Here's a patch to switch the drift file from an unscaled frequency
offset to ppm. The latter format is compatible with that of ntp.org.
This allows easy switching between ntpd daemons. (I asked PHK and
ntimed will probably not have a drift file at all.)
Old drift files are handled automagically. All values greater than
a threshold will be interpreted as ppm. I picked 5e-3 (== 5000 ppm)
as the cut-off value, because that's the maximum adjtime() can
handle and you are unlikely to find a higher frequency offset. In
fact, the combination of ntp.org and ntp_adjtime() cannot correct
offsets higher then 500 ppm. Conversely, offsets smaller than
0.005 ppm (== 5e-9) are improbable. This compatibility handling
will be removed in a year.
Index: ntpd.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
retrieving revision 1.84
diff -u -p -r1.84 ntpd.c
--- ntpd.c 13 Jan 2015 02:28:56 - 1.84
+++ ntpd.c 13 Jan 2015 18:21:49 -
@@ -474,6 +474,8 @@ ntpd_settime(double d)
log_info("set local clock to %s (offset %fs)", buf, d);
}
+#define PPM_THRESHOLD 5e-3
+
void
readfreq(void)
{
@@ -494,9 +496,15 @@ readfreq(void)
if (adjfreq(NULL, ¤t) == -1)
log_warn("adjfreq failed");
else if (current == 0) {
- if (fscanf(fp, "%le", &d) == 1)
+ if (fscanf(fp, "%lf", &d) == 1) {
+ if (d > PPM_THRESHOLD || d < -PPM_THRESHOLD)
+ /* drift file in ppm */
+ d /= 1e6;
+ else
+ log_debug("assuming unscaled frequency "
+ "offset in drift file");
ntpd_adjfreq(d, 0);
- else
+ } else
log_warnx("can't read %s", DRIFTFILE);
}
fclose(fp);
@@ -505,8 +513,9 @@ readfreq(void)
int
writefreq(double d)
{
- int r;
FILE *fp;
+ double ppm;
+ int r;
static int warnonce = 1;
fp = fopen(DRIFTFILE, "w");
@@ -518,7 +527,8 @@ writefreq(double d)
return 0;
}
- fprintf(fp, "%e\n", d);
+ ppm = d * 1e6;
+ fprintf(fp, "%.3f\n", ppm);
r = ferror(fp);
if (fclose(fp) != 0 || r != 0) {
if (warnonce) {
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: ntpd: switch drift file to ppm
Wonderful strategy.
ok deraadt
> Here's a patch to switch the drift file from an unscaled frequency
> offset to ppm. The latter format is compatible with that of ntp.org.
> This allows easy switching between ntpd daemons. (I asked PHK and
> ntimed will probably not have a drift file at all.)
>
> Old drift files are handled automagically. All values greater than
> a threshold will be interpreted as ppm. I picked 5e-3 (== 5000 ppm)
> as the cut-off value, because that's the maximum adjtime() can
> handle and you are unlikely to find a higher frequency offset. In
> fact, the combination of ntp.org and ntp_adjtime() cannot correct
> offsets higher then 500 ppm. Conversely, offsets smaller than
> 0.005 ppm (== 5e-9) are improbable. This compatibility handling
> will be removed in a year.
>
>
> Index: ntpd.c
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 ntpd.c
> --- ntpd.c13 Jan 2015 02:28:56 - 1.84
> +++ ntpd.c13 Jan 2015 18:21:49 -
> @@ -474,6 +474,8 @@ ntpd_settime(double d)
> log_info("set local clock to %s (offset %fs)", buf, d);
> }
>
> +#define PPM_THRESHOLD5e-3
> +
> void
> readfreq(void)
> {
> @@ -494,9 +496,15 @@ readfreq(void)
> if (adjfreq(NULL, ¤t) == -1)
> log_warn("adjfreq failed");
> else if (current == 0) {
> - if (fscanf(fp, "%le", &d) == 1)
> + if (fscanf(fp, "%lf", &d) == 1) {
> + if (d > PPM_THRESHOLD || d < -PPM_THRESHOLD)
> + /* drift file in ppm */
> + d /= 1e6;
> + else
> + log_debug("assuming unscaled frequency "
> + "offset in drift file");
> ntpd_adjfreq(d, 0);
> - else
> + } else
> log_warnx("can't read %s", DRIFTFILE);
> }
> fclose(fp);
> @@ -505,8 +513,9 @@ readfreq(void)
> int
> writefreq(double d)
> {
> - int r;
> FILE *fp;
> + double ppm;
> + int r;
> static int warnonce = 1;
>
> fp = fopen(DRIFTFILE, "w");
> @@ -518,7 +527,8 @@ writefreq(double d)
> return 0;
> }
>
> - fprintf(fp, "%e\n", d);
> + ppm = d * 1e6;
> + fprintf(fp, "%.3f\n", ppm);
> r = ferror(fp);
> if (fclose(fp) != 0 || r != 0) {
> if (warnonce) {
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: ntpd: switch drift file to ppm
> Date: Tue, 13 Jan 2015 19:36:58 +0100
> From: Christian Weisgerber
>
> Here's a patch to switch the drift file from an unscaled frequency
> offset to ppm. The latter format is compatible with that of ntp.org.
> This allows easy switching between ntpd daemons. (I asked PHK and
> ntimed will probably not have a drift file at all.)
>
> Old drift files are handled automagically. All values greater than
> a threshold will be interpreted as ppm. I picked 5e-3 (== 5000 ppm)
> as the cut-off value, because that's the maximum adjtime() can
> handle and you are unlikely to find a higher frequency offset. In
> fact, the combination of ntp.org and ntp_adjtime() cannot correct
> offsets higher then 500 ppm. Conversely, offsets smaller than
> 0.005 ppm (== 5e-9) are improbable. This compatibility handling
> will be removed in a year.
Does this in any way force a write of the drift file or are you
relying on ntpd deciding that it has a better estimate of the drift somewhere
in the next year?
> Index: ntpd.c
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 ntpd.c
> --- ntpd.c13 Jan 2015 02:28:56 - 1.84
> +++ ntpd.c13 Jan 2015 18:21:49 -
> @@ -474,6 +474,8 @@ ntpd_settime(double d)
> log_info("set local clock to %s (offset %fs)", buf, d);
> }
>
> +#define PPM_THRESHOLD5e-3
> +
> void
> readfreq(void)
> {
> @@ -494,9 +496,15 @@ readfreq(void)
> if (adjfreq(NULL, ¤t) == -1)
> log_warn("adjfreq failed");
> else if (current == 0) {
> - if (fscanf(fp, "%le", &d) == 1)
> + if (fscanf(fp, "%lf", &d) == 1) {
> + if (d > PPM_THRESHOLD || d < -PPM_THRESHOLD)
> + /* drift file in ppm */
> + d /= 1e6;
> + else
> + log_debug("assuming unscaled frequency "
> + "offset in drift file");
> ntpd_adjfreq(d, 0);
> - else
> + } else
> log_warnx("can't read %s", DRIFTFILE);
> }
> fclose(fp);
> @@ -505,8 +513,9 @@ readfreq(void)
> int
> writefreq(double d)
> {
> - int r;
> FILE *fp;
> + double ppm;
> + int r;
> static int warnonce = 1;
>
> fp = fopen(DRIFTFILE, "w");
> @@ -518,7 +527,8 @@ writefreq(double d)
> return 0;
> }
>
> - fprintf(fp, "%e\n", d);
> + ppm = d * 1e6;
> + fprintf(fp, "%.3f\n", ppm);
> r = ferror(fp);
> if (fclose(fp) != 0 || r != 0) {
> if (warnonce) {
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
>
lid suspend
The kernel default has been changed so that machines (with lids) will suspend automatically if the lid is closed. The installer no longer asks the question (which in 5.6 defaulted to yes). This choice will allow suspend/resume to be tested & improved even further. It is already prompting some developers to look into more sophisticated heuristics, and we'll see where that goes. Anyone who wants it off, echo machdep.lidsuspend=0 >> /etc/sysctl.conf or sysctl machdep.lidsuspend=0
Re: ntpd: switch drift file to ppm
Mark Kettenis: > Does this in any way force a write of the drift file or are you > relying on ntpd deciding that it has a better estimate of the > drift somewhere in the next year? ntpd always updates the drift file when it adjusts the frequency, and it always adjusts the frequency when it is synced. There is no "if (new != old)" check. Also, an old-format drift file is simply too small by a million, i.e., it will essentially set the frequency adjustment to about 0. ntpd will soon recover from that. Hmm, I guess we could skip the compatibility handling completely and just let ntpd re-discover the drift. Starting with an adjustment scaled by 1e-6 is essentially the same as starting with 0 on a newly installed machine. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: ntpd: switch drift file to ppm
> Date: Tue, 13 Jan 2015 21:27:25 +0100 > From: Christian Weisgerber > > Mark Kettenis: > > > Does this in any way force a write of the drift file or are you > > relying on ntpd deciding that it has a better estimate of the > > drift somewhere in the next year? > > ntpd always updates the drift file when it adjusts the frequency, > and it always adjusts the frequency when it is synced. There is > no "if (new != old)" check. > > Also, an old-format drift file is simply too small by a million, > i.e., it will essentially set the frequency adjustment to about 0. > ntpd will soon recover from that. > > Hmm, I guess we could skip the compatibility handling completely > and just let ntpd re-discover the drift. Starting with an adjustment > scaled by 1e-6 is essentially the same as starting with 0 on a newly > installed machine. Heh. Sounds plausible.
Re: ntpd: switch drift file to ppm
> > Hmm, I guess we could skip the compatibility handling completely > > and just let ntpd re-discover the drift. Starting with an adjustment > > scaled by 1e-6 is essentially the same as starting with 0 on a newly > > installed machine. > > Heh. Sounds plausible. Smaller diff. Wouldn't work the other way around :-)
libevent errata
Patches are now available for 5.5 and 5.6 which fix libevent.
5.5 errata 20 and 5.6 errata 15:
Fix CVE-2014-6272 in libevent 1.4 event buffer handling. OpenBSD
base uses it for the programs: cu tmux ftp-proxy httpd ldapd relayd
tftp-proxy tftpd
Links:
http://www.openbsd.org/errata55.html
http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/020_libevent.patch.sig
and
http://www.openbsd.org/errata56.html
http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/015_libevent.patch.sig
untrusted comment: signature from openbsd 5.6 base private key
RWR0EANmo9nqhpu5mEMdLuZ056ynwx+qvxaVbodk7LsWqC0UCch3P2Ll0uGzfyJl/FSN9KH7tQgwwjbPwyss35EQNAlUAULiYgU=
OpenBSD 5.6 errata 15, Jan 8, 2015
Fix CVE-2014-6272 in libevent 1.4 event buffer handling. OpenBSD
base uses it for the programs: cu tmux ftp-proxy httpd ldapd relayd
tftp-proxy tftpd
A defect in the Libevent evbuffer API leaves some programs that
pass insanely large inputs to evbuffers open to a possible heap
overflow or infinite loop.
Apply patch using:
signify -Vep /etc/signify/openbsd-56-base.pub -x 015_libevent.patch.sig \
-m - | (cd /usr/src && patch -p0)
Then build and install libevent
cd /usr/src/lib/libevent
make obj
make
make install
Index: lib/libevent/buffer.c
===
RCS file: /mount/cvsdev/cvs/openbsd/src/lib/libevent/buffer.c,v
retrieving revision 1.19
diff -u -p -r1.19 buffer.c
--- lib/libevent/buffer.c 17 Jul 2010 17:16:47 - 1.19
+++ lib/libevent/buffer.c 7 Jan 2015 19:11:19 -
@@ -53,6 +53,7 @@
#include
#include
+#include
#include
#include
#include
@@ -145,7 +146,8 @@ evbuffer_add_vprintf(struct evbuffer *bu
va_list aq;
/* make sure that at least some space is available */
- evbuffer_expand(buf, 64);
+ if (evbuffer_expand(buf, 64) < 0)
+ return (-1);
for (;;) {
size_t used = buf->misalign + buf->off;
buffer = (char *)buf->buffer + buf->off;
@@ -351,26 +353,38 @@ evbuffer_align(struct evbuffer *buf)
int
evbuffer_expand(struct evbuffer *buf, size_t datlen)
{
- size_t need = buf->misalign + buf->off + datlen;
+ size_t used = buf->misalign + buf->off;
+
+ assert(buf->totallen >= used);
/* If we can fit all the data, then we don't have to do anything */
- if (buf->totallen >= need)
+ if (buf->totallen - used >= datlen)
return (0);
+ /* If we would need to overflow to fit this much data, we can't
+* do anything. */
+ if (datlen > SIZE_MAX - buf->off)
+ return (-1);
/*
* If the misalignment fulfills our data needs, we just force an
* alignment to happen. Afterwards, we have enough space.
*/
- if (buf->misalign >= datlen) {
+ if (buf->totallen - buf->off >= datlen) {
evbuffer_align(buf);
} else {
void *newbuf;
size_t length = buf->totallen;
+ size_t need = buf->off + datlen;
if (length < 256)
length = 256;
- while (length < need)
- length <<= 1;
+ if (need < SIZE_MAX / 2) {
+ while (length < need) {
+ length <<= 1;
+ }
+ } else {
+ length = need;
+ }
if (buf->orig_buffer != buf->buffer)
evbuffer_align(buf);
@@ -387,10 +401,10 @@ evbuffer_expand(struct evbuffer *buf, si
int
evbuffer_add(struct evbuffer *buf, const void *data, size_t datlen)
{
- size_t need = buf->misalign + buf->off + datlen;
+ size_t used = buf->misalign + buf->off;
size_t oldoff = buf->off;
- if (buf->totallen < need) {
+ if (buf->totallen - used < datlen) {
if (evbuffer_expand(buf, datlen) == -1)
return (-1);
}
Re: ntpd: switch drift file to ppm
On 2015-01-13, Theo de Raadt wrote:
>> > Hmm, I guess we could skip the compatibility handling completely
>> > and just let ntpd re-discover the drift.
>>
>> Heh. Sounds plausible.
>
> Smaller diff.
I started with 2.679024e-05 in ntpd.drift and pretty soon got this:
adjusting clock frequency by 25.510055 to 25.510082ppm
Here's the small diff:
Index: ntpd.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
retrieving revision 1.84
diff -u -p -r1.84 ntpd.c
--- ntpd.c 13 Jan 2015 02:28:56 - 1.84
+++ ntpd.c 13 Jan 2015 20:57:13 -
@@ -494,9 +494,10 @@ readfreq(void)
if (adjfreq(NULL, ¤t) == -1)
log_warn("adjfreq failed");
else if (current == 0) {
- if (fscanf(fp, "%le", &d) == 1)
+ if (fscanf(fp, "%lf", &d) == 1) {
+ d /= 1e6; /* scale from ppm */
ntpd_adjfreq(d, 0);
- else
+ } else
log_warnx("can't read %s", DRIFTFILE);
}
fclose(fp);
@@ -518,7 +519,7 @@ writefreq(double d)
return 0;
}
- fprintf(fp, "%e\n", d);
+ fprintf(fp, "%.3f\n", d * 1e6); /* scale to ppm */
r = ferror(fp);
if (fclose(fp) != 0 || r != 0) {
if (warnonce) {
--
Christian "naddy" Weisgerber na...@mips.inka.de
[patch] xdm doesn't clear wtmp/utmp entry after log out
Hi, I've noticed this issue for sometime now. I was hoping one of the Xorg updates would fix it, so finally I decided to read some man pages, specifically sessreg. Evidently the Xservers path is not correct (or has changed) in OBSD's install. No longer found at: /usr/X11R6/lib/X11/xdm/Xservers is at: /etc/X11/xdm/Xservers [pre-patch] Log into X using xdm, then log out. Alt+Ctrl+F1 login and run last as such: $ last -5 sidster : Tue Jan 13 12:01 still logged in sidster ttyC0 Sat Jan 10 16:35 still logged in reboot~ Sat Jan 10 16:35 shutdown ~ Sat Jan 10 16:34 root ttyC0 Sat Jan 10 16:28 - shutdown (00:06) [post-patch below (loally modified files)] Same procedure as above: $ last -5 sidster : Tue Jan 13 13:23 - 13:24 (00:00) sidster : Tue Jan 13 12:01 - 13:23 (01:22) sidster ttyC0 Sat Jan 10 16:35 still logged in reboot~ Sat Jan 10 16:35 shutdown ~ Sat Jan 10 16:34 This is on: kern.version=OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Index: GiveConsole === RCS file: /cvs/obsd/xenocara/app/xdm/config/GiveConsole,v retrieving revision 1.4 diff -u -p -u -p -r1.4 GiveConsole --- GiveConsole 18 Nov 2013 20:39:48 - 1.4 +++ GiveConsole 13 Jan 2015 21:26:24 - @@ -11,4 +11,4 @@ chown $USER /dev/console if [ -c /dev/drm0 ]; then chown $USER /dev/drm0 fi -/usr/X11R6/bin/sessreg -a -l $DISPLAY -u none -x /usr/X11R6/lib/X11/xdm/Xservers $USER +/usr/X11R6/bin/sessreg -a -l $DISPLAY -u none -x /etc/X11/xdm/Xservers $USER Index: TakeConsole === RCS file: /cvs/obsd/xenocara/app/xdm/config/TakeConsole,v retrieving revision 1.4 diff -u -p -u -p -r1.4 TakeConsole --- TakeConsole 18 Nov 2013 20:39:48 - 1.4 +++ TakeConsole 13 Jan 2015 21:26:24 - @@ -8,4 +8,4 @@ chown root /dev/console if [ -c /dev/drm0 ]; then chown root /dev/drm0 fi -/usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp -x /usr/X11R6/lib/X11/xdm/Xservers $USER +/usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp -x /etc/X11/xdm/Xservers $USER
Re: spamd-setup bug parsing non-CIDR IPs
Ignore this diff for now, it is not correct. - todd
elantech-v4 clickpad support
Currently pms and the wsconscomm module of the synaptics driver offer a
somewhat limited support for Elantech clickpads with hardware version 4.
Above all, I missed the options of performing click-and-drag operations
with two fingers and of using a "soft button area" for the emulation of
right button clicks (tap-and-drag and two-finger tapping are no
alternatives for me, usually I don't enable tapping).
I have written two patches that provide these options (I'm using them
on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware
and firmware is identified as "Elantech Clickpad, version 4, firmware
0x461f02"). There is, however, an open question concerning wsconscomm.
If someone is interested in testing and using the patches, or in
assessing whether they can be useful for the OpenBSD project, some
explanations might help.
Two-finger scrolling and click-and-drag actions on clickpads require
that the multitouch input is filtered or "translated" into coherent
sequences of coordinate pairs. The pms patch - which I have added
below - implements a simple filter that checks the motion deltas and
ensures that if there is at least one finger moving on the clickpad, a
moving one will be tracked. Some care is needed when the input "slot"
changes, but this works well even within the infrastructure of wscons,
which doesn't define and handle "MT" events.
The problem with wsconscomm is related to the X/Linux way of handling
multitouches. If I understand it correctly, it produces MT events with
slot data as well as standard events with coordinates for "pointer
control", and the latter are determined by the "oldest" touch. That
mechanism is sufficient if two fingers are moving in parallel, but it
cannot cover the click-and-drag case because usually only one finger
is moving, and it is not necessarily the one that has touched the
clickpad first. This might be the reason why the synaptics driver
implements an additional mapping. It accumulates the motion deltas
of the multitouch slots in a special coordinate pair. As long as no
button is pressed, the pair isn't used, and its values will be
synchronized with the standard coordinates. When clickpad support is
enabled ("$ synclient ClickPad=1") and a button is down, the
"cumulative" values will be used. This makes the cursor movement
independent of the order of touches (and you can create, e.g., a
diagonal cursor movement by combining a horizontal and a vertical
finger movement).
It seems that the current development version of the synaptics driver
applies the cumulative coordinates to two-finger-scrolling as well
(independently of clickpad support).
In OpenBSD wsconscomm updates the cumulative coordinates when no
button is being pressed, but it does nothing with them otherwise. If
clickpad support is enabled, this has the effect that the X cursor
"freezes" as long as the clickpad button is down, and no click-and-
drag operation - not even the one-finger variant - is possible (for
this reason I couldn't use soft button areas, which require the
clickpad support).
As wsconscomm doesn't deal with MT events, couldn't it simply always
keep the coordinates in sync? To make click-and-drag work in my
installation I have applied the following patch to wsconscomm.c:
diff --git a/wsconscomm.c b/wsconscomm.c
index 0e0c81d..a6540db 100644
--- a/wsconscomm.c
+++ b/wsconscomm.c
@@ -131,12 +131,6 @@ WSConsReadHwState(InputInfoPtr pInfo,
struct wscons_event event;
Bool v;
-/* Reset cumulative values if buttons were not previously pressed */
-if (!hw->left && !hw->right && !hw->middle) {
-hw->cumulative_dx = hw->x;
-hw->cumulative_dy = hw->y;
-}
-
while (WSConsReadEvent(pInfo, &event)) {
switch (event.type) {
case WSCONS_EVENT_MOUSE_UP:
@@ -186,9 +180,11 @@ WSConsReadHwState(InputInfoPtr pInfo,
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
hw->x = event.value;
+hw->cumulative_dx = hw->x;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Y:
hw->y = priv->maxy - event.value + priv->miny;
+hw->cumulative_dy = hw->y;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
hw->z = event.value;
Please note that this patch might "unmask" an inconsistent treatment
of multitouches. For example, if I use it without applying the pms
patch, an attempt to click-and-drag can lead to jumps of the cursor
and inverted vertical movements. Could something similar happen with
other hardware where clickpad support would make sense? And if this
is the case, could the change in wsconscomm be restricted in a
reasonable way?
If the pms patch is applied without changing wsconscomm, it would only
fix minor flaws in the clickpad behaviour (currently it is possible to
produce a "tap" by putting two fingers on the clickpad and lifting them
successively within a tap interval; two-finger scrolling may start with
a jump).
The diffs are agains
ldomd in rc scripts on ${MACHINE} != "sparc64" / machine-independent login.conf
Hi all,
While browsing through '/etc', I have stumbled upon ldomd(8) rc.d(8) script:
/etc/rc.d/ldomd
and two entries referring to it:
- one in rc(8):
start_daemon ldomd sshd snmpd ldpd ripd ospfd ospf6d bgpd ifstated
- and one in rc.conf(8):
ldomd_flags=NO # for normal use: ""
Given that ldomd is sparc64-only, shouldn't the file and the entries be
only available on that architecture?
While looking into the above I have also noticed that login.conf(5) is
machine-dependent, even though it is identical an *all* architectures -
it is only different on alpha where the timestamp is off by one second
(or two characters):
< # $OpenBSD: login.conf,v 1.2 2014/04/22 11:03:39 reyk Exp $
---
> # $OpenBSD: login.conf,v 1.2 2014/04/22 11:03:40 reyk Exp $
I have prepared a diff which addresses both of the above (ldomd and
login.conf) but if you think that it is an overkill to make rc and
rc.conf machine-dependent, then feel free to only use the part which
makes login.conf machine-independent.
Since the diff is massive (15k+), I wouldn't dare including it here in
full but am adding the diff to the Makefile at the very least:
Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.400
diff -u -p -r1.400 Makefile
--- etc/Makefile3 Dec 2014 20:13:49 - 1.400
+++ etc/Makefile13 Jan 2015 22:50:40 -
@@ -31,10 +31,10 @@ kernels: bootblocks ${ALL_KERNELS}
BINOWN= root
BINGRP= wheel
MUTABLE=changelist csh.cshrc csh.login csh.logout daily \
- etc.${MACHINE}/disktab etc.${MACHINE}/login.conf ftpusers \
- gettytab group ksh.kshrc locate.rc mailer.conf man.conf \
- moduli monthly netstart networks newsyslog.conf \
- pf.os protocols rc rc.conf rpc services shells syslog.conf weekly
+ etc.${MACHINE}/disktab login.conf ftpusers gettytab group ksh.kshrc \
+ locate.rc mailer.conf man.conf moduli monthly netstart networks \
+ newsyslog.conf pf.os protocols etc.${MACHINE}/rc \
+ etc.${MACHINE}/rc.conf rpc services shells syslog.conf weekly
# -rw-r--r--
EXAMPLES=chio.conf dhclient.conf dhcpd.conf exports ftpchroot hosts.lpd \
@@ -52,12 +52,15 @@ EXAMPLES_600=bgpd.conf dvmrpd.conf hosta
# -r-xr-xr-x
RCDAEMONS=amd apmd bgpd bootparamd cron dhcpd dhcrelay dvmrpd ftpd ftpproxy \
- hostapd hotplugd httpd identd ifstated iked inetd isakmpd iscsid \
- ldapd ldattach ldomd ldpd lockd lpd mopd mountd mrouted nfsd \
- npppd nsd ntpd ospf6d ospfd pflogd portmap rarpd rbootd relayd \
- ripd route6d rtadvd sasyncd sensorsd slowcgi smtpd sndiod \
- snmpd spamd spamlogd sshd statd syslogd tftpd tftpproxy unbound \
- watchdogd wsmoused xdm ypbind ypldap yppasswdd ypserv
+ hostapd hotplugd httpd identd ifstated iked inetd isakmpd iscsid ldapd \
+ ldattach ldpd lockd lpd mopd mountd mrouted nfsd npppd nsd ntpd ospf6d \
+ ospfd pflogd portmap rarpd rbootd relayd ripd route6d rtadvd sasyncd \
+ sensorsd slowcgi smtpd sndiod snmpd spamd spamlogd sshd statd syslogd \
+ tftpd tftpproxy unbound watchdogd wsmoused xdm ypbind ypldap yppasswdd \
+ ypserv
+.if ${MACHINE} == "sparc64"
+RCDAEMONS+= ldomd
+.endif
MISETS=base${OSrev}.tgz comp${OSrev}.tgz man${OSrev}.tgz
game${OSrev}.tgz
The remaining commands should be something along the lines of:
cd /usr/src/etc # using /usr/src as the source directory
cp etc.alpha/login.conf .
for i in etc.* ; do rm $i/login.conf
cp rc rc.conf etc.sparc64
# edit rc and rc.conf and removed references to ldomd
for i in etc.* ; do cp -i rc rc.conf $i ; done # ignoring etc.sparc64
rm rc rc.conf
# and obviously the necessary cvs add/remove, etc.
I hope all of the above makes sense :^)
Cheers,
Raf
remove .Tn from /sys
On Jan 13 07:02:30, schwa...@cvs.openbsd.org wrote: > CVSROOT: /cvs > Module name: src > Changes by: schwa...@cvs.openbsd.org2015/01/13 07:02:30 > > Modified files: > lib/libc/stdio : fgetln.3 fgetwln.3 fopen.3 fputs.3 funopen.3 >printf.3 tmpnam.3 > > Log message: > remove .Tn from stdio manuals; Kaspars Bankovskis found one of these This removes the .Tn markup from what O grepped in /usr/srs/sys Jan Index: arch/aviion/stand/a2coff/a2coff.8 === RCS file: /cvs/src/sys/arch/aviion/stand/a2coff/a2coff.8,v retrieving revision 1.4 diff -u -p -r1.4 a2coff.8 --- arch/aviion/stand/a2coff/a2coff.8 20 Oct 2013 07:40:43 - 1.4 +++ arch/aviion/stand/a2coff/a2coff.8 13 Jan 2015 23:21:00 - @@ -37,9 +37,7 @@ .Nm a2coff converts standalone binaries, such as kernels or boot blocks, from .Xr elf 5 -format to COFF format, suitable for booting from the -.Tn Data General -.Tn AViiON -PROMs. +format to COFF format, suitable for booting +from the Data General AViiON PROMs. .Sh SEE ALSO .Xr elf 5 Index: arch/hppa/stand/mkboot/mkboot.8 === RCS file: /cvs/src/sys/arch/hppa/stand/mkboot/mkboot.8,v retrieving revision 1.9 diff -u -p -r1.9 mkboot.8 --- arch/hppa/stand/mkboot/mkboot.8 31 May 2007 19:20:03 - 1.9 +++ arch/hppa/stand/mkboot/mkboot.8 13 Jan 2015 23:21:00 - @@ -41,11 +41,8 @@ .Sh DESCRIPTION Creates the LIF file containing the bootstrap .Ar program -and possibly other programs to be used by the -.Tn HP 9000/700 -and -.Tn HP 9000/800 -systems. +and possibly other programs to be used +by the HP 9000/700 and HP 9000/800 systems. .Pp An argument to the .Fl l Index: arch/hppa64/stand/mkboot/mkboot.8 === RCS file: /cvs/src/sys/arch/hppa64/stand/mkboot/mkboot.8,v retrieving revision 1.3 diff -u -p -r1.3 mkboot.8 --- arch/hppa64/stand/mkboot/mkboot.8 31 May 2007 19:20:03 - 1.3 +++ arch/hppa64/stand/mkboot/mkboot.8 13 Jan 2015 23:21:00 - @@ -41,11 +41,8 @@ .Sh DESCRIPTION Creates the LIF file containing the bootstrap .Ar program -and possibly other programs to be used by the -.Tn HP 9000/700 -and -.Tn HP 9000/800 -systems. +and possibly other programs to be used +by the HP 9000/700 and HP 9000/800 systems. .Pp An argument to the .Fl l Index: arch/sparc/stand/installboot/installboot.8 === RCS file: /cvs/src/sys/arch/sparc/stand/installboot/installboot.8,v retrieving revision 1.12 diff -u -p -r1.12 installboot.8 --- arch/sparc/stand/installboot/installboot.8 20 Oct 2013 07:40:42 - 1.12 +++ arch/sparc/stand/installboot/installboot.8 13 Jan 2015 23:21:00 - @@ -71,9 +71,8 @@ The second-stage program commonly reside The utility .Pa /usr/mdec/binstall can be used to properly copy the second-stage bootprogram to its destination. -This script takes care of post-processing that is required on -.Pf non- Tn Openboot -machines. +This script takes care of post-processing +that is required on non-Openboot machines. .Pp The options are as follows: .Bl -tag -width flag @@ -86,9 +85,8 @@ can be one of .Dq sun4c or .Dq sun4m . -Sun 4c models with -.Tn Openboot -PROMs need the header to be present, while Sun 4 systems with the +Sun 4c models with Openboot PROMs need the header to be present, +while Sun 4 systems with the .Dq old monitor interface require the header to be stripped off. This is normally taken care of by
syslogd TCP reconnect
Hi,
When the connection to a TCP syslog server fails or the TCP connection
terminates, try to reconnect after an increasing timeout.
ok?
bluhm
Index: usr.sbin/syslogd/syslogd.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.140
diff -u -p -r1.140 syslogd.c
--- usr.sbin/syslogd/syslogd.c 8 Jan 2015 20:22:47 - 1.140
+++ usr.sbin/syslogd/syslogd.c 13 Jan 2015 22:32:36 -
@@ -135,6 +135,7 @@ struct filed {
/* @proto46://[hostname]:servname\0 */
struct sockaddr_storage f_addr;
struct bufferevent *f_bufev;
+ int f_reconnectwait;
} f_forw; /* forwarding address */
charf_fname[MAXPATHLEN];
struct {
@@ -265,7 +266,9 @@ void udp_readcb(int, short, void *);
voidunix_readcb(int, short, void *);
int tcp_socket(struct filed *);
voidtcp_readcb(struct bufferevent *, void *);
+voidtcp_writecb(struct bufferevent *, void *);
voidtcp_errorcb(struct bufferevent *, short, void *);
+voidtcp_connectcb(int, short, void *);
voiddie_signalcb(int, short, void *);
voidmark_timercb(int, short, void *);
voidinit_signalcb(int, short, void *);
@@ -716,6 +719,18 @@ tcp_readcb(struct bufferevent *bufev, vo
}
void
+tcp_writecb(struct bufferevent *bufev, void *arg)
+{
+ struct filed*f = arg;
+
+ /*
+* Successful write, connection to server is good, reset wait time.
+*/
+ dprintf("loghost \"%s\" successful write\n", f->f_un.f_forw.f_loghost);
+ f->f_un.f_forw.f_reconnectwait = 0;
+}
+
+void
tcp_errorcb(struct bufferevent *bufev, short event, void *arg)
{
struct filed*f = arg;
@@ -731,20 +746,67 @@ tcp_errorcb(struct bufferevent *bufev, s
f->f_un.f_forw.f_loghost, strerror(errno));
dprintf("%s\n", ebuf);
+ /* The SIGHUP handler may also close the socket, so invalidate it. */
close(f->f_file);
- if ((f->f_file = tcp_socket(f)) == -1) {
- /* XXX reconnect later */
- bufferevent_free(bufev);
- f->f_type = F_UNUSED;
- } else {
- /* XXX The messages in the output buffer may be out of sync. */
- bufferevent_setfd(bufev, f->f_file);
- bufferevent_enable(f->f_un.f_forw.f_bufev, EV_READ);
- }
+ f->f_file = -1;
+
+ /*
+* XXX The messages in the output buffer may be out of sync.
+* Here we should clear the buffer or at least remove partial
+* messages from the beginning.
+*/
+ tcp_connectcb(-1, 0, f);
+
+ /* Log the connection error to the fresh buffer after reconnecting. */
logmsg(LOG_SYSLOG|LOG_WARNING, ebuf, LocalHostName, ADDDATE);
}
void
+tcp_connectcb(int fd, short event, void *arg)
+{
+ struct filed*f = arg;
+ struct bufferevent *bufev = f->f_un.f_forw.f_bufev;
+ struct timeval to;
+ int s;
+
+ if ((event & EV_TIMEOUT) == 0 && f->f_un.f_forw.f_reconnectwait > 0)
+ goto retry;
+
+ /* Avoid busy reconnect loop, delay until successful write. */
+ if (f->f_un.f_forw.f_reconnectwait == 0)
+ f->f_un.f_forw.f_reconnectwait = 1;
+
+ if ((s = tcp_socket(f)) == -1)
+ goto retry;
+
+ dprintf("tcp connect callback: success, event %#x\n", event);
+ bufferevent_setfd(bufev, s);
+ bufferevent_setcb(bufev, tcp_readcb, tcp_writecb, tcp_errorcb, f);
+ /*
+* Although syslog is a write only protocol, enable reading from
+* the socket to detect connection close and errors.
+*/
+ bufferevent_enable(bufev, EV_READ|EV_WRITE);
+ f->f_file = s;
+
+ return;
+
+ retry:
+ f->f_un.f_forw.f_reconnectwait <<= 1;
+ if (f->f_un.f_forw.f_reconnectwait > 600)
+ f->f_un.f_forw.f_reconnectwait = 600;
+ to.tv_sec = f->f_un.f_forw.f_reconnectwait;
+ to.tv_usec = 0;
+
+ dprintf("tcp connect callback: retry, event %#x, wait %d\n",
+ event, f->f_un.f_forw.f_reconnectwait);
+ bufferevent_setfd(bufev, -1);
+ /* We can reuse the write event as bufferevent is disabled. */
+ evtimer_set(&bufev->ev_write, tcp_connectcb, f);
+ evtimer_add(&bufev->ev_write, &to);
+}
+
+void
usage(void)
{
@@ -1712,22 +1774,16 @@ cfline(char *line, char *prog)
}
f->f_type = F_FORWUDP;
} else if (strncmp(proto, "tcp", 3) == 0) {
- int s;
-
- if ((s = tcp_socket(f)) == -1)
- break;
- if ((f->f_un.f_forw.f_bufev = bufferevent_new(s,
-
Re: ldomd in rc scripts on ${MACHINE} != "sparc64" / machine-independent login.conf
On Tue, Jan 13, 2015 at 23:24, Raf Czlonka wrote: > While looking into the above I have also noticed that login.conf(5) is > machine-dependent, even though it is identical an *all* architectures - > it is only different on alpha where the timestamp is off by one second > (or two characters): login.conf is supposed to be machine dependent, although we haven't made much use of this facility to date.
Re: elantech-v4 clickpad support
Ulf Brosziewski t-online.de> writes: > I have written two patches that provide these options (I'm using them > on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware > and firmware is identified as "Elantech Clickpad, version 4, firmware > 0x461f02"). There is, however, an open question concerning wsconscomm. Should I try on bios0: ASUSTeK COMPUTER INC. X200CA pms0: Elantech Clickpad, version 4, firmware 0x361f01 or it is somewhat another hardware/firmware?
Re: ldomd in rc scripts on ${MACHINE} != "sparc64" / machine-independent login.conf
> On Tue, Jan 13, 2015 at 23:24, Raf Czlonka wrote:
>
> > While looking into the above I have also noticed that login.conf(5) is
> > machine-dependent, even though it is identical an *all* architectures -
> > it is only different on alpha where the timestamp is off by one second
> > (or two characters):
>
> login.conf is supposed to be machine dependent, although we haven't
> made much use of this facility to date.
Sigh.
It would be nice to have % values, based on something we know about
the architecture ("memory", "speed", "grooviness"). The entire
translation model to create MD files is sufficiently weak that noone
will build anything to leverage it. On the other hand, if we made it
too capable (turing complete hah), people would over-leverage it,
creating a nightmare that puts people off. Some more balanced model
is needed, and this MD:MI split is not it.
amd64 kernel W^X
Mike Larkin has been slow at informing the world, despite my prodding. Probably started working on something else cool... So.. I am going to take it upon myself to sing praise to him, and hopefully he'll let me off lightly! Over the last two months Mike modified the amd64 kernel to follow the W^X principles. It started as a humble exercise to fix the .rodata segment, and kind of went crazy. As a result, no part of the kernel address space is writeable and executable simultaneously. At least that is the idea, modulo mistakes. Final attention to detail (which some of you experienced in buggy drafts in snapshots) was to make the MP and ACPI trampolines follow W^X, furthermore they are unmapped when not required. Some further amd64-specific page attribute improvements snuck in. Too complicated to describe simply. I followed along for the ride and improved the situation on other architectures, mostly MI improvements so the right requests would be made to the MD layers. Final picture is many architectures were improved, but amd64 and sparc64 look the best due to MMU features available to service the W^X model. The entire safety model is also improved by a limited form of kernel ASLR (the code segment does not move around yet, but data and page table ASLR is fairly good. There are some known pages, but hopefully fewer in the future).
Re: amd64 kernel W^X
On Jan 14, 2015 7:57 AM, "Theo de Raadt" wrote: > > Mike Larkin has been slow at informing the world, despite my prodding. > Probably started working on something else cool... > > So.. I am going to take it upon myself to sing praise to him, and > hopefully he'll let me off lightly! > > Over the last two months Mike modified the amd64 kernel to follow the > W^X principles. It started as a humble exercise to fix the .rodata > segment, and kind of went crazy. As a result, no part of the kernel > address space is writeable and executable simultaneously. At least > that is the idea, modulo mistakes. Final attention to detail (which > some of you experienced in buggy drafts in snapshots) was to make the > MP and ACPI trampolines follow W^X, furthermore they are unmapped when > not required. > > Some further amd64-specific page attribute improvements snuck in. Too > complicated to describe simply. > > I followed along for the ride and improved the situation on other > architectures, mostly MI improvements so the right requests would be > made to the MD layers. Final picture is many architectures were > improved, but amd64 and sparc64 look the best due to MMU features > available to service the W^X model. The entire safety model is also > improved by a limited form of kernel ASLR (the code segment does not > move around yet, but data and page table ASLR is fairly good. There > are some known pages, but hopefully fewer in the future). > That's an amazing feat ! Well done Mike !!
Re: elantech-v4 clickpad support
On 01/14/2015 02:03 AM, Alexey Suslikov wrote: Ulf Brosziewski t-online.de> writes: I have written two patches that provide these options (I'm using them on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware and firmware is identified as "Elantech Clickpad, version 4, firmware 0x461f02"). There is, however, an open question concerning wsconscomm. Should I try on bios0: ASUSTeK COMPUTER INC. X200CA pms0: Elantech Clickpad, version 4, firmware 0x361f01 or it is somewhat another hardware/firmware? Only the "hardware version" should play a role here, so this would make sense.
Re: amd64 kernel W^X
On Tue, Jan 13, 2015 at 08:57:09PM -0700, Theo de Raadt wrote: > Mike Larkin has been slow at informing the world, despite my prodding. > Probably started working on something else cool... > > So.. I am going to take it upon myself to sing praise to him, and > hopefully he'll let me off lightly! > > Over the last two months Mike modified the amd64 kernel to follow the > W^X principles. It started as a humble exercise to fix the .rodata > segment, and kind of went crazy. As a result, no part of the kernel > address space is writeable and executable simultaneously. At least > that is the idea, modulo mistakes. Final attention to detail (which > some of you experienced in buggy drafts in snapshots) was to make the > MP and ACPI trampolines follow W^X, furthermore they are unmapped when > not required. > > Some further amd64-specific page attribute improvements snuck in. Too > complicated to describe simply. > > I followed along for the ride and improved the situation on other > architectures, mostly MI improvements so the right requests would be > made to the MD layers. Final picture is many architectures were > improved, but amd64 and sparc64 look the best due to MMU features > available to service the W^X model. The entire safety model is also > improved by a limited form of kernel ASLR (the code segment does not > move around yet, but data and page table ASLR is fairly good. There > are some known pages, but hopefully fewer in the future). > Thanks Theo for the encouragement along the way. It did indeed start with .rodata, but then we ended up fixing a ton more; probably a dozen different places needed tightening up. i386 is next, but that requires a PAE paging model and compatible CPU. I've got the PAE mode booting but it's not ready for prime time yet. -ml
Re: amd64 kernel W^X
On Tue, Jan 13, 2015 at 11:38 PM, Mike Larkin wrote: > i386 is next, but that requires a PAE paging model and compatible CPU. > I've got the PAE mode booting but it's not ready for prime time yet.
Re: amd64 kernel W^X
On Tue, Jan 13, 2015 at 11:36 PM, Philip Guenther wrote: > On Tue, Jan 13, 2015 at 11:38 PM, Mike Larkin wrote: >> i386 is next, but that requires a PAE paging model and compatible CPU. >> I've got the PAE mode booting but it's not ready for prime time yet. Hmm, once PAE is working well, maybe we can kill off non-PAE i386 support and reduce the set of non-W^X systems we monitor. There's some horrid code in ld.so that should be running in the fields behind the barn... Philip Guenther
