Re: acme-client -t switch?

[Devin Reade]

--On Thursday, March 09, 2017 06:13:38 PM +0100 Sebastian Benoit 
 wrote:



Stuart Henderson(s...@spacehopper.org) on 2017.03.07 21:56:56 +:



Since this came up.. what does anyone think about adding the original
version back to ports? (personally, I could do with moving things away
from the python version, but I need dns-01..)


I'm planing on re-introducing the [-t switch] functinality.


What direction are you planning on going with that?  Using the model
that Kristaps is using in the git version where challenges are provided
on stdout to another program?  Or using something closer to the original
implementation where acme-client executes an arbitrary program when
it needs to do the challenge?

I think the stdout mechanism would be cleaner as that way an extension
only needs to integrate by calling acme-client, not integrating both
caller and callee.  It would also reduce the differences between the
versions.

Devin

Re: acme-client -t switch?

[Devin Reade]

Expanding on my previous email, it looks like the git version of
acme-client has a different implementation than what was implemented
in the version first committed (and later removed) from the OpenBSD
CVS sources.  The latter (CVS) version was calling "doas sh ..."
whereas the former (git) version writes challenges to stdout which
can then be processed by the invoking program.  Looking at the logs,
it appears the git version is a reworking of the functionality.

For the record, I was asking about introducing the mechanism (stdout)
currently used by the git version.

Devin

acme-client -t switch?

[Devin Reade]

So I was looking to use acme-client's "-t" switch to orchestrate the
creation of certificates for non-HTTPS use and off-machine use.
However I see that it was removed in main.c version 1.15 in the
OpenBSD source tree.

(I'm currently testing acme-client via git on OpenBSD 6.0.)

Would folks be amenable to patches that would allow re-introducing
this switch?

Although I'm open to suggestions/comments on the approach, my intent
was to create a perl program / modules for CPAN that would use acme-client
to support both the dns-01 challenge and shipping certificates to
other machines (think of the IMAPS use case, as an example).

Devin

acme-client missing man-page bug item?

[Devin Reade]

I'm testing a git-based version of acme-client on OpenBSD 6.0 at the
moment and visually comparing source with that in CVS, but this is
relevant to OpenBSD 6.1 so bear with me here.

In the git version in revokeproc.c about line 237 we see the following
comment following the "Parse the SAN line" text:

   we don't allowing removing domains from certificates

This behavior matches what I saw empirically, which is why I went
looking at the source.

Inspection of the OpenBSD CVS source, although it doesn't have that
comment, appears to follow the same logic.  I'm still wading through
the ACME protocol spec, but so far I've not seen anything that would
prohibit removal of the domain.

So my question is: Is this behavior something that should be mentioned
in the BUGS section of the man page?  Or am I missing something in the
protocol spec?

To be clear, this would exhibit itself if you took a running
configuration of:

   domain example.com {
   alternative names { secure.example.com www.example.com }
   ...
   }

and changed it to:

   domain example.com {
   alternative names { www.example.com }
   ...
   }


Devin

Re: Get PCI resources from ACPI

[Devin Reade]

dmesg diff, followed by full dmesg with 2nd patch applied.  No panic,
at least in the time it took to grab the dmesg and reboot.

Devin

1c1
< OpenBSD 5.9-beta (GENERIC.MP) #10: Fri Jan  8 09:00:37 MST 2016
---

OpenBSD 5.9-beta (GENERIC.MP) #11: Fri Jan  8 10:37:00 MST 2016

18c18
< cpu0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz, 3000.38 MHz
---

cpu0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz, 3000.35 MHz

32a33,38

bus 0
extent `pcimem' (0x0 - 0x), flags=0
 0x0 - 0x9
 0xc - 0xc
 0xe - 0x7f6f
 0x1 - 0x



OpenBSD 5.9-beta (GENERIC.MP) #11: Fri Jan  8 10:37:00 MST 2016
   r...@something.gno.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2120744960 (2022MB)
avail mem = 2052399104 (1957MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf06e0 (68 entries)
bios0: vendor American Megatrends Inc. version "0902" date 06/20/2008
bios0: ASUSTeK Computer INC. P5K-VM
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI OSFR
acpi0: wakeup devices P0P2(S4) P0P1(S4) UAR1(S4) PS2K(S4) EUSB(S4) USBE(S4) 
P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S4) USB1(S4) USB2(S4) 
USB3(S4) USB4(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz, 3000.35 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR

cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 333MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz, 2999.95 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR

cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
bus 0
extent `pcimem' (0x0 - 0x), flags=0
0x0 - 0x9
0xc - 0xc
0xe - 0x7f6f
0x1 - 0x
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 4 (P0P1)
acpiprt3 at acpi0: bus -1 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpiprt5 at acpi0: bus -1 (P0P7)
acpiprt6 at acpi0: bus 2 (P0P8)
acpiprt7 at acpi0: bus 1 (P0P9)
acpiprt8 at acpi0: bus 3 (P0P4)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM
acpibtn0 at acpi0: PWRB
cpu0: Enhanced SpeedStep 3000 MHz: speeds: 2997, 1998 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x02
inteldrm0 at pci0 dev 2 function 0 "Intel 82G33 Video" rev 0x02
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1024x768
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 82G33 Video" rev 0x02 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 2 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 2 int 18
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x02: msi
azalia0: codecs: Realtek ALC883
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 3
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
jmb0 at pci2 dev 0 function 0 "JMicron JMB368 IDE" rev 0x00
pciide0 at jmb0: DMA, channel 0 wired to native-PCI, channel 1 wired to 
native-PCI

pciide0: using apic 2 int 16 for native-PCI interrupt
atapiscsi0 at pciide0 channel 0 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 disabled (no drives)
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 1
mskc0 at pci3 dev 0 function 0 "Marvell Yukon 88E8056" rev 0x12, Yukon-2 EC 
Ultra rev. B0 (0x3): apic 2 int 17

msk0 at mskc0 port A: address 00:1d:60:a2:98:28
eephy0 at msk0 phy 0: 88E1149 Gigabit PHY, rev. 1
uhci3 at 

Re: onerng(4): new TRNG device

[Devin Reade]

Third submission, based on feedback from mpi@ and deraadt@.

* rename device to "uonerng"
* don't discard initial bytes from the device
* decrease buffer size to 128 and poll interval to 100ms
* feed the first buffer of data to the RNG as soon as the device is
  attached, before putting the task in the queue
* avoid DMA copy on read
* write device commands in-line, and remove onerng_write()
* addressed remaining aforementioned nits

Tested on:
5.8 stable on i386/GENERIC; and
5.9 beta snapshot (27 Dec 2015) on amd64/GENERIC.MP

Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.407
diff -u -p -r1.407 GENERIC
--- sys/arch/amd64/conf/GENERIC 7 Jan 2016 11:13:19 -   1.407
+++ sys/arch/amd64/conf/GENERIC 8 Jan 2016 02:55:13 -
@@ -184,6 +184,7 @@ usb*at ohci?
 uhub*  at usb? # USB Hubs
 uhub*  at uhub?# USB Hubs
 ualea* at uhub?# Araneus Alea II TRNG
+uonerng* at uhub?  # Moonbase Otago OneRNG
 umodem*at uhub?# USB Modems/Serial
 ucom*  at umodem?
 uvisor*at uhub?# Handspring Visor
Index: sys/arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.809
diff -u -p -r1.809 GENERIC
--- sys/arch/i386/conf/GENERIC  3 Jan 2016 05:50:00 -   1.809
+++ sys/arch/i386/conf/GENERIC  8 Jan 2016 02:55:25 -
@@ -233,6 +233,7 @@ usb*at ohci?
 uhub*  at usb? # USB Hubs
 uhub*  at uhub?# USB Hubs
 ualea* at uhub?# Araneus Alea II TRNG
+uonerng* at uhub?  # Moonbase Otago OneRNG
 umodem*at uhub?# USB Modems/Serial
 ucom*  at umodem?
 uvisor*at uhub?# Handspring Visor
Index: sys/dev/usb/files.usb
===
RCS file: /cvs/src/sys/dev/usb/files.usb,v
retrieving revision 1.124
diff -u -p -r1.124 files.usb
--- sys/dev/usb/files.usb   11 May 2015 06:46:22 -  1.124
+++ sys/dev/usb/files.usb   8 Jan 2016 02:56:08 -
@@ -175,6 +175,11 @@ device ualea
 attach ualea at uhub
 file   dev/usb/ualea.c ualea
 
+# Moonbase Otago OneRNG TRNG
+device uonerng
+attach uonerng at uhub
+file   dev/usb/uonerng.c   uonerng
+
 # Gude Expert mouseCLOCK DCF77 time signal station receiver
 device udcf
 attach udcf at uhub
Index: sys/dev/usb/uonerng.c
===
RCS file: sys/dev/usb/uonerng.c
diff -N sys/dev/usb/uonerng.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/dev/usb/uonerng.c   8 Jan 2016 02:56:08 -
@@ -0,0 +1,452 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (C) 2015 Devin Reade <g...@gno.org>
+ * Copyright (C) 2015 Sean Levy <att...@stalphonsos.com>
+ * Copyright (c) 2007 Marc Balmer <mbal...@openbsd.org>
+ * Copyright (c) 2006 Alexander Yurchenko <gra...@openbsd.org>
+ * Copyright (c) 1998 The NetBSD Foundation, Inc.
+ *
+ * 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.
+ */
+
+/*
+ * Moonbase Otago OneRNG TRNG.  Note that the encoded vendor for this
+ * device is OpenMoko as OpenMoko has made its device ranges available
+ * for other open source / open hardware vendors.
+ *
+ * Product information can be found here:
+ * http://onerng.info/onerng
+ *
+ * Based on the ualea(4), uow(4), and umodem(4) source code.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * The OneRNG is documented to provide ~350kbits/s of entropy at
+ * ~7.8 bits/byte, and when used at a lower rate providing close
+ * to 8 bits/byte.
+ *
+ * Although this driver is able to consume the data at the full rate,
+ * we tune this down to 10kbit/s as the OpenBSD RNG is better off
+ * with small amounts of input at a time so as to not saturate the
+ * input queue and mute other sources of entropy.
+ *
+ * Furthermore, unlike other implementations, for us there is no benefit
+ * to discarding

Re: onerng(4): new TRNG device

[Devin Reade]

Second submission, based on feedback from mpi@ and @deraadt.

* match is now on the device level
* attach now looks for interfaces by index (and verifies it gets
  the right ones) since it can no longer iterate over the device array
* added missing failure check
* fixed incorrect failure check
* removed extraneous comments and reduced verbosity

Tested on:
5.8 stable on i386/GENERIC; and
5.9 beta snapshot (27 Dec 2015) on amd64/GENERIC.MP

Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.406
diff -u -p -r1.406 GENERIC
--- sys/arch/amd64/conf/GENERIC 31 Dec 2015 13:06:49 -  1.406
+++ sys/arch/amd64/conf/GENERIC 7 Jan 2016 04:58:26 -
@@ -183,6 +183,7 @@ usb*at ohci?
 uhub*  at usb? # USB Hubs
 uhub*  at uhub?# USB Hubs
 ualea* at uhub?# Araneus Alea II TRNG
+onerng*at uhub?# Moonbase Otago OneRNG
 umodem*at uhub?# USB Modems/Serial
 ucom*  at umodem?
 uvisor*at uhub?# Handspring Visor
Index: sys/arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.809
diff -u -p -r1.809 GENERIC
--- sys/arch/i386/conf/GENERIC  3 Jan 2016 05:50:00 -   1.809
+++ sys/arch/i386/conf/GENERIC  7 Jan 2016 04:58:34 -
@@ -233,6 +233,7 @@ usb*at ohci?
 uhub*  at usb? # USB Hubs
 uhub*  at uhub?# USB Hubs
 ualea* at uhub?# Araneus Alea II TRNG
+onerng*at uhub?# Moonbase Otago OneRNG
 umodem*at uhub?# USB Modems/Serial
 ucom*  at umodem?
 uvisor*at uhub?# Handspring Visor
Index: sys/dev/usb/files.usb
===
RCS file: /cvs/src/sys/dev/usb/files.usb,v
retrieving revision 1.124
diff -u -p -r1.124 files.usb
--- sys/dev/usb/files.usb   11 May 2015 06:46:22 -  1.124
+++ sys/dev/usb/files.usb   7 Jan 2016 04:58:58 -
@@ -175,6 +175,11 @@ device ualea
 attach ualea at uhub
 file   dev/usb/ualea.c ualea
 
+# Moonbase Otago OneRNG TRNG
+device onerng
+attach onerng at uhub
+file   dev/usb/onerng.conerng
+
 # Gude Expert mouseCLOCK DCF77 time signal station receiver
 device udcf
 attach udcf at uhub
Index: sys/dev/usb/onerng.c
===
RCS file: sys/dev/usb/onerng.c
diff -N sys/dev/usb/onerng.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/dev/usb/onerng.c7 Jan 2016 04:58:58 -
@@ -0,0 +1,470 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (C) 2015 Devin Reade <g...@gno.org>
+ * Copyright (C) 2015 Sean Levy <att...@stalphonsos.com>
+ * Copyright (c) 2007 Marc Balmer <mbal...@openbsd.org>
+ * Copyright (c) 2006 Alexander Yurchenko <gra...@openbsd.org>
+ * Copyright (c) 1998 The NetBSD Foundation, Inc.
+ *
+ * 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.
+ */
+
+/*
+ * Moonbase Otago OneRNG TRNG.  Note that the encoded vendor for this
+ * device is OpenMoko as OpenMoko has made its device ranges available
+ * for other open source / open hardware vendors.
+ *
+ * Product information can be found here:
+ * http://onerng.info/onerng
+ *
+ * Based on the ualea(4), uow(4), and umodem(4) source code.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * The OneRNG is documented to provide ~350kbits/s of entropy at
+ * ~7.8 bits/byte, and when used at a lower rate providing close
+ * to 8 bits/byte.
+ *
+ * The current choice of ONERNG_BUFSIZ and ONERNG_MSECS gives us
+ * ~319kbits/s with about 3% system time on slow hardware and 0% st
+ * on fast hardware.
+ */
+#define ONERNG_BUFSIZ  2048
+#define ONERNG_MSECS   50
+
+#define ONERNG_TIMEOUT 1000/* ms */
+
+/*
+ * On attach, we extract and throw away this number of bytes before
+ * feeding bytes to the kernel.  This is a behavior that was in the origi

Re: onerng(4): new TRNG device

[Devin Reade]

Thanks for your feedback, Martin.  See below.

--On Monday, January 04, 2016 08:02:34 PM +0100 Martin Pieuchot 
<m...@openbsd.org> wrote:



On 04/01/16(Mon) 10:34, Devin Reade wrote:

This patch adds kernel support for the OneRNG hardware random number
generator, which is similar to ualea(4).  onerng(4) is configured to
deliver ~319kb/s of true randomness.


[snip]


+/*
+ * If ONERNG_MEASURE_RATE is defined, then we measure the rate at which
+ * we're able to provide random data to the kernel.  ONERNG_RATE_SECONDS
+ * is the sampling period at which we print the results.
+ */
+#ifdef ONERNG_MEASURE_RATE
+#define ONERNG_RATE_SECONDS 30
+#endif


Could you also keep the softc variables used for measuring the rate
under the same define?


I thought I did.  Those are sc_start, sc_cur, sc_counted_bytes, and
sc_timer_running.   The sc_discarded_bytes is not related to the
measuring logic, so it is outside of the #ifdef.  Did I miss something?


+/*
+ * OneRNG commands:
+ *   cmdO (cap-oh) Turn the device on
+ *   cmdo (lower-oh)   Turn the device off
+ *   cmdw  Flush entropy pool
+ *   cmdX  Extract firmware image (the cmd4 opmode should
+ *  be in effect during this operation)
+ *
+ * OneRNG operation modes:
+ *   cmd0 (zero)   Avalanche noise with whitener (default)
+ *   cmd1  Raw avalanche noise
+ *   cmd2  Avalanche noise and RF noise with whitener
+ *   cmd3  Raw avalanche noise and RF noise
+ *   cmd4  No noise
+ *   cmd5  No noise
+ *   cmd6  RF noise with whitener
+ *   cmd7  Raw RF noise
+ */


Rather than having a big comment you could do:

/*
 * Operation modes
 */
# define OP_RANDOM  "cmd0\n" /* Avalanche noise with whitener (default) */
# define OP_RAW "cmd1\n"  
...

Or simply include a link to the documentation and just define what you
need.


Unfortunately there isn't an obvious document at the original site
that lays out the various commands.  I needed to read the Linux source
to derive the command set.  That limits the usability of linking to the
original site for this purpose.

Since I don't give the option, under OpenBSD, of running in different
operating modes I decided that documenting it in the man page probably
wasn't appropriate, so that's why I left the command set description
in the source.

I could do a #define for each command with an inline comment, but that
would leave a bunch of unused #defines, which I thought would be more
evil than a single large comment.

I figured that documenting the entire set *somehow* was worthwhile.

With that additional context, what are your thoughts?


+/*
+ * Determine the index of data interface.  Place it into data_iface_idx
+ * (or -1 if it isn't found)
+ */
+void
+onerng_get_caps(struct usb_attach_arg *uaa, int ctl_iface_no,
+int *data_iface_idx /*, int *cm_cap, int *acm_cap*/)
+{


Drivers generally start with match, then attach,


ok


plus [onerng_get_caps()] seems useless, see below.


It gets invoked twice, once during match and once during attach.
During match, it acts as a concheck to ensure that both the control
and data interface exist, following the logic in umodem(4) from which
that function is derived.  During the attach phase, it is used to
determine the index of the data interface, again following the logic
in umodem(4).

See also the response for the onerng_match feedback, below.


+int
+onerng_match(struct device *parent, void *match, void *aux)
+{

[...]

+   /* There are two interfaces; only match on the control interface. */


If you want to use the two interfaces, match the whole device, but to me
it seems that you're not using the two of them.  What's the output of
"lsusb -v" for this device?


See the end of the email for the lsusb output.

Both are used. The control interface is used to clear RTS in
onerng_set_line_state().  The data interface is used to both set the
operating mode and to retrieve data.

An earlier version of the code (not submitted) matched on only vendor
and product, but I was seeing onerng_match being invoked twice; one for
the control interface and one for the data interface, so I was getting
two devices (onerng0 and onerng1).  By matching on the control interface
and then using it to retrieve the data interface from the parent device
(and thus returning UMATCH_VENDOR_PRODUCT), we only get one onerng0
device.


+int
+onerng_enable(struct onerng_softc *sc)
+{
+   onerng_rts(sc, 0);


What happens if the transfer fail?


In this case, the OneRNG won't produce output, but point taken; the
underlying result should be checked and returned.  If it fails, it
*should* deactivate the device.


+   /* Open pipes */
+   err = usbd_open_pipe(sc->sc_data_iface, ep_ibulk,
+   USBD_EXCLUSIVE_USE, >sc_inpipe);
+   if (err) {
+   printf("%s: failed to open bulk-in pipe: %s\n

onerng(4): new TRNG device

[Devin Reade]

This patch adds kernel support for the OneRNG hardware random number
generator, which is similar to ualea(4).  onerng(4) is configured to
deliver ~319kb/s of true randomness.

Since usbdevs.h and usbdevs_data.h are generated files, it's not clear
to me that they are supposed to be part of the patch, but they are
included none the less.

Tested on:
5.8 stable on i386/GENERIC; and
5.9 beta snapshot (27 Dec 2015) on amd64/GENERIC.MP


Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.406
diff -u -p -r1.406 GENERIC
--- sys/arch/amd64/conf/GENERIC 31 Dec 2015 13:06:49 -  1.406
+++ sys/arch/amd64/conf/GENERIC 4 Jan 2016 17:13:33 -
@@ -183,6 +183,7 @@ usb*at ohci?
 uhub*  at usb? # USB Hubs
 uhub*  at uhub?# USB Hubs
 ualea* at uhub?# Araneus Alea II TRNG
+onerng*at uhub?# Moonbase Otago OneRNG
 umodem*at uhub?# USB Modems/Serial
 ucom*  at umodem?
 uvisor*at uhub?# Handspring Visor
Index: sys/arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.808
diff -u -p -r1.808 GENERIC
--- sys/arch/i386/conf/GENERIC  29 Oct 2015 07:47:02 -  1.808
+++ sys/arch/i386/conf/GENERIC  4 Jan 2016 17:13:44 -
@@ -232,6 +232,7 @@ usb*at ohci?
 uhub*  at usb? # USB Hubs
 uhub*  at uhub?# USB Hubs
 ualea* at uhub?# Araneus Alea II TRNG
+onerng*at uhub?# Moonbase Otago OneRNG
 umodem*at uhub?# USB Modems/Serial
 ucom*  at umodem?
 uvisor*at uhub?# Handspring Visor
Index: sys/dev/usb/files.usb
===
RCS file: /cvs/src/sys/dev/usb/files.usb,v
retrieving revision 1.124
diff -u -p -r1.124 files.usb
--- sys/dev/usb/files.usb   11 May 2015 06:46:22 -  1.124
+++ sys/dev/usb/files.usb   4 Jan 2016 17:14:14 -
@@ -175,6 +175,11 @@ device ualea
 attach ualea at uhub
 file   dev/usb/ualea.c ualea
 
+# Moonbase Otago OneRNG TRNG
+device onerng
+attach onerng at uhub
+file   dev/usb/onerng.conerng
+
 # Gude Expert mouseCLOCK DCF77 time signal station receiver
 device udcf
 attach udcf at uhub
Index: sys/dev/usb/onerng.c
===
RCS file: sys/dev/usb/onerng.c
diff -N sys/dev/usb/onerng.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/dev/usb/onerng.c4 Jan 2016 17:14:14 -
@@ -0,0 +1,547 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (C) 2015 Devin Reade <g...@gno.org>
+ * Copyright (C) 2015 Sean Levy <att...@stalphonsos.com>
+ * Copyright (c) 2007 Marc Balmer <mbal...@openbsd.org>
+ * Copyright (c) 2006 Alexander Yurchenko <gra...@openbsd.org>
+ * Copyright (c) 1998 The NetBSD Foundation, Inc.
+ *
+ * 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.
+ */
+
+/*
+ * Moonbase Otago OneRNG TRNG.  Note that the encoded vendor for this
+ * device is OpenMoko as OpenMoko has made its device ranges available
+ * for other open source / open hardware vendors.
+ *
+ * Product information can be found here:
+ * http://onerng.info/onerng
+ *
+ * Based on the ualea(4), uow(4), and umodem(4) source code.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * The OneRNG is documented to provide ~350kbits/s of entropy at
+ * ~7.8 bits/byte, and when used at a lower rate providing close
+ * to 8 bits/byte.
+ *
+ * The current implementation was timed for different values of
+ * ONERNG_MSECS and ONERNG_BUFSIZ while running on a Thinkpad T42
+ * (Pentium M processor 1.8GHz).  The timing code is enabled by
+ * defining ONERNG_MEASURE_RATE. The results are below:
+ *
+ * ONERNG_BUFSIZ | ONERNG_MSECS | Rate | Approximate
+ *  |  | kb/s  | System Time
+ * 1024100   159   1.5%
+ * 1024 50   160   1.5%
+ *

Re: ignore inflight messages in daily output

[Devin Reade]

--On Sunday, January 03, 2016 01:22:34 PM + Stuart Henderson 
<st...@openbsd.org> wrote:



On 2016/01/02 18:05, Devin Reade wrote:

If mail is in the process of being sent (rather than sitting in
the queue) we probably shouldn't complain about it.  If something
like daily.local causes mail to be sent this can end up with a lot
of false positives.  (False in the sense that nothing is actually
wrong, so the system should be quite about it.)


I'm not sure about this... We don't exclude these for other MTAs and
it means you might miss a real delayed mail that is being reattempted
at the time daily(8) runs.


For years I've had a script run from daily.local that will, under some
circumstances, trigger an email to be sent (and not necessarily to the
same addresses that get root mail).  Maybe it was a timing issue, but
when sendmail was the default MTA, the fact that this message was
being sent was AFAIK not once reported by daily's mailq invocation.
It was only after switching to smptd that the reports started.

Right now the diff is matching against "|inflight|0|$".  If I changed
that to "|0|inflight|0|$", then it would only match against the first
attempted delivery for that message.  With such a change, would the
diff be acceptable?

My fallback position is to run the mentioned script via its own cron
entry at a different time, but I'd prefer to stick to daily.local.




Index: etc/daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.84
diff -u -p -r1.84 daily
--- etc/daily   30 Dec 2015 22:59:53 -  1.84
+++ etc/daily   2 Jan 2016 06:25:55 -
@@ -138,11 +138,15 @@ else
 fi

 # The first two regular expressions handle sendmail, the third postfix.
+# The fourth is for smtpd(8), and tries to allow for the possibility
that +# something invoked from /etc/daily.local has just sent mail which
is +# now in the process of being sent (and would thus often be a false
positive).
 # When the queue is empty, smtpd(8) and exim -bp keep silent.
 next_part "mail:"
 mailq | grep -v -e "^/var/spool/mqueue is empty$" \
-e "^[[:blank:]]*Total requests: 0$" \
-   -e "^Mail queue is empty$"
+   -e "^Mail queue is empty$" \
+   -e "|inflight|0|$"

 next_part "network:"
 if [ "X$VERBOSESTATUS" != X0 ]; then

ignore inflight messages in daily output

[Devin Reade]

If mail is in the process of being sent (rather than sitting in
the queue) we probably shouldn't complain about it.  If something
like daily.local causes mail to be sent this can end up with a lot
of false positives.  (False in the sense that nothing is actually
wrong, so the system should be quite about it.)


Index: etc/daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.84
diff -u -p -r1.84 daily
--- etc/daily   30 Dec 2015 22:59:53 -  1.84
+++ etc/daily   2 Jan 2016 06:25:55 -
@@ -138,11 +138,15 @@ else
 fi
 
 # The first two regular expressions handle sendmail, the third postfix.
+# The fourth is for smtpd(8), and tries to allow for the possibility that
+# something invoked from /etc/daily.local has just sent mail which is
+# now in the process of being sent (and would thus often be a false positive).
 # When the queue is empty, smtpd(8) and exim -bp keep silent.
 next_part "mail:"
 mailq | grep -v -e "^/var/spool/mqueue is empty$" \
-e "^[[:blank:]]*Total requests: 0$" \
-   -e "^Mail queue is empty$"
+   -e "^Mail queue is empty$" \
+   -e "|inflight|0|$"
 
 next_part "network:"
 if [ "X$VERBOSESTATUS" != X0 ]; then

what approach for TRNG?

[Devin Reade]

A while ago a posted a dmesg for a TRNG USB device (the MoonBase Otago
OneRNG) per
.

I'm looking at adding support for this device but haven't splunked too
much into the OpenBSD kernel before, and I'm looking for advice.

The OneRNG was manufactured to present itself as a modem and in the Linux
sample source code the (user space) process to first initialize the device
by echoing some commands to the device and then cat its output to rngd.

For the OpenBSD side, I found /usr/src/sys/dev/usb/ualea.c which is
another USB-based TRNG.  The model there would be to usbd_transfer(9)
from the device and then forward it via add_true_randomness(9).

However, because the OneRNG was manufactured to look like a modem,
the other possibility is to have it recognised in
/usr/src/sys/dev/usb/umodem.c.  If that's the case, though, it's
unclear to me what the mechanism should be to pull the data from the
OneRNG and give it to the kernel; presumably we don't want any
userspace code here.

Am I correct in assuming that the ualea mechanism is probabably the
right way to go?

Devin

Re: OpenSSH hole, April 9

[Devin Reade]

Quoting Theo de Raadt dera...@cvs.openbsd.org:


If tomorrow Damien or I had to announce a major OpenSSH hole, how
screwed would the Internet be?


Would you mind clarifying this a bit?  Was the post strictly a
(justified) comment about the lack of funding, or should we be
anticipating another announcement in addition to the existing OpenSSL
mess?

Devin

Re: OpenSSH hole, April 9

[Devin Reade]

Thanks for the clarification.

I would also like to thank whomever for the extra descriptive text on
the openssl patch issued the other day.  Having the clarification on
the (non)impact on OpenSSH right in the patch was good ...

Devin