Re: Implement a watchdog

2014-12-11 Thread Matt Dainty
* sven falempin sven.falem...@gmail.com [2014-12-10 12:32:15]:
 On Wed, Dec 10, 2014 at 9:31 AM, Stuart Henderson st...@openbsd.org wrote:
  On 2014/12/10 09:15, sven falempin wrote:
  http://lxr.free-electrons.com/source/drivers/hwmon/nct6775.c
 
  https://github.com/groeck/nct6775
 
  So i guess the first step is to detect the chip
 
  You'll also need somewhere (files) to put the detection. Maybe look at
  the commit from when tcpcib was added as an example.
 
  It might be somewhat similar to the Winbond superio chips (Nuvoton is
  a spin off company).
 
  On Wed, Dec 10, 2014 at 8:32 AM, sven falempin sven.falem...@gmail.com 
  wrote:
   I guess the chip used is obviously this one :
  
   Nuvoton NCT6106D
  
   spec : 
   https://download.nuvoton.com/NuvotonMOSS/DownloadService/Member/DocumentsInfo.aspx?tp_GUID=DA00-NCT6106D
 
  The watchdog part of this appears to use the same registers as NCT5104D
  in the pcengines APU.
 
 Well the sequence to configure is the same in the doc
 
 
 7.1.1 Enter the Extended Function Mode
 To place the chip into the Extended Function Mode, two successive
 writes of 0x87 must be applied to Extended
 Function Enable Registers (EFERs, i.e. 2Eh or 4Eh).
 
 
 I am not sure i understand, is this a pci device or a isa device ?

Have a look at the wbsio(4) driver. There's already a constant defined for
the NCT6776 so you probably just need to add the missing ID(s) and go from
there.

Matt



page fault at resume, possibly caused by java/jenkins

2014-12-11 Thread frantisek holop

i think this page fault is triggered by jenkins
during resume.

login: kernel: page fault trap, code=0
Stopped at  in_selectsrc+0xd8:  movl 0xf0(%esi),%ebx
ddb{0} trace
in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at in_selectsrc+0xd8

udp_output(d8cfabfc,d80b6900,d80b6700,0,0) at udp_output+0xf8
sosend(d7f881c8,d80b6700,f617ce90,d80b6900,0) at sosend+0x44b
sendit(d84f4b40,103,f617cef4,0,f617cf80) at sendit+0x1e1
sys_sendto(d84f4b40,f617cf60,f617cf80,d0568b5a,d84f4b40) at sys_sendto+0x6c
syscall() at syscall+0x144
--- syscall (number 259) ---
0x2:
ddb{0}


screenshots:
obiit.org/f/pagefault0.jpg
obiit.org/f/pagefault1.jpg

the running java process is jenkins.
i cannot reproduce it all the time, but now it has
happened twice: suspend at the end of the day,
go to sleep, next day resume, page fault.
both times when i was using jenkins.

i can provide more information when it happens again,
just let me know what exactly...

-f
-- 
let me show you the world in my eyes.



Re: Implement a watchdog

2014-12-11 Thread Mark Kettenis
 Date: Thu, 11 Dec 2014 05:08:11 -0500
 From: Matt Dainty m...@bodgit-n-scarper.com
 
 * sven falempin sven.falem...@gmail.com [2014-12-10 12:32:15]:
  On Wed, Dec 10, 2014 at 9:31 AM, Stuart Henderson st...@openbsd.org wrote:
   On 2014/12/10 09:15, sven falempin wrote:
   http://lxr.free-electrons.com/source/drivers/hwmon/nct6775.c
  
   https://github.com/groeck/nct6775
  
   So i guess the first step is to detect the chip
  
   You'll also need somewhere (files) to put the detection. Maybe look at
   the commit from when tcpcib was added as an example.
  
   It might be somewhat similar to the Winbond superio chips (Nuvoton is
   a spin off company).
  
   On Wed, Dec 10, 2014 at 8:32 AM, sven falempin sven.falem...@gmail.com 
   wrote:
I guess the chip used is obviously this one :
   
Nuvoton NCT6106D
   
spec : 
https://download.nuvoton.com/NuvotonMOSS/DownloadService/Member/DocumentsInfo.aspx?tp_GUID=DA00-NCT6106D
  
   The watchdog part of this appears to use the same registers as NCT5104D
   in the pcengines APU.
  
  Well the sequence to configure is the same in the doc
  
  
  7.1.1 Enter the Extended Function Mode
  To place the chip into the Extended Function Mode, two successive
  writes of 0x87 must be applied to Extended
  Function Enable Registers (EFERs, i.e. 2Eh or 4Eh).
  
  
  I am not sure i understand, is this a pci device or a isa device ?
 
 Have a look at the wbsio(4) driver. There's already a constant defined for
 the NCT6776 so you probably just need to add the missing ID(s) and go from
 there.

Yes indeed.  That's the correct thing to do.  According to the
datasheet the Chip ID is 0x10, but we have found that recent Nuvoton
datasheets often lie about this, so you might want to enable the
printf in wbsio_probe() to see what the real chip ID is.

Looks like the chip has a hardware monitoring function as well.  Might
be possible to add support for this to lm(4).

I believe somebody wrote a diff to add watchdog support for this
family of chips at some point.  A bit of a problem is that on some of
these chips the watchdog timer signal is multiplexed on one of the
GPIO pins and that pin is often configurable.  Which pin to use (or
whether the watchdog works at all) depends on the motherboard layout.
And the pin that works on your motherboard might be the self destruct
button on some other motherboard.  That's why we didn't pursue this
any further at the time.  Things might be a bit saner for your chip
though.

Cheers,

Mark



Re: page fault at resume, possibly caused by java/jenkins

2014-12-11 Thread Martin Pieuchot
On 11/12/14(Thu) 11:31, frantisek holop wrote:
 i think this page fault is triggered by jenkins
 during resume.
 login: kernel: page fault trap, code=0
 Stopped at  in_selectsrc+0xd8:  movl 0xf0(%esi),%ebx
 ddb{0} trace
 in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at 
 in_selectsrc+0xd8
 
 udp_output(d8cfabfc,d80b6900,d80b6700,0,0) at udp_output+0xf8
 sosend(d7f881c8,d80b6700,f617ce90,d80b6900,0) at sosend+0x44b
 sendit(d84f4b40,103,f617cef4,0,f617cf80) at sendit+0x1e1
 sys_sendto(d84f4b40,f617cf60,f617cf80,d0568b5a,d84f4b40) at sys_sendto+0x6c
 syscall() at syscall+0x144
 --- syscall (number 259) ---
 0x2:
 ddb{0}
 
 
 screenshots:
 obiit.org/f/pagefault0.jpg
 obiit.org/f/pagefault1.jpg
 
 the running java process is jenkins.
 i cannot reproduce it all the time, but now it has
 happened twice: suspend at the end of the day,
 go to sleep, next day resume, page fault.
 both times when i was using jenkins.
 
 i can provide more information when it happens again,
 just let me know what exactly...

Well... what's your dmesg?

What's your network configuration, more explicitly are you using any USB
device and how? 

What kind of test is jenkins running?  How is it multicast related?



Re: Binary code patching and paravirtualization

2014-12-11 Thread Jonathan Gray
On Wed, Dec 10, 2014 at 12:32:02AM +0100, Stefan Fritsch wrote:
 Hi,
 
 in summer, I posted some paravirt patches for amd64. In response to the 
 comments I received then, I have created some infrastructure to binary 
 patch kernel code during boot. In order to get some feedback, I am posting 
 the whole paravirt  code patching diff here. Also, KVM users may be 
 interested in trying it (hi Antoine ;).
 
 For the codepatching part, the most interesting files are codepatch.c and 
 codepatch.h.  In copy.S and cpu.c, I convert the code patching already 
 done for SMAP to the new infrastructure (if someone has a machine with 
 SMAP support, testing would be nice).

There aren't so many machines with SMAP commercially released only
a handful of 2 in 1 devices with Core M processors.

You should be able to test with the qemu support added by Intel however.
ie
qemu-system-x86_64 -cpu qemu64,+smap
or
qemu-system-x86_64 -cpu Broadwell

 
 The basic approach is to create macros that surround a to-be-patched code 
 part and store pointer, length, and a tag in a dedicated section. Then 
 there are functions to replace all code parts with a specific tag. Does 
 this part of the diff look sensible?

What about i386?  Though not included in your diff we can't assume
the various multi byte nop sequences are valid there.

The Intel instruction set reference says:
The multi-byte NOP instruction performs no operation on supported
processors and generates undefined opcode exception on processors that
do not support the multi-byte NOP instruction.

It seems in practice they are supported on everything after
686/pentium pro?

Though the code doing the patching could do a cpuid check.



Re: page fault at resume, possibly caused by java/jenkins

2014-12-11 Thread frantisek holop
Martin Pieuchot, 11 Dec 2014 11:59:
 On 11/12/14(Thu) 11:31, frantisek holop wrote:
  i think this page fault is triggered by jenkins
  during resume.
  login: kernel: page fault trap, code=0
  Stopped at  in_selectsrc+0xd8:  movl 0xf0(%esi),%ebx
  ddb{0} trace
  in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at 
  in_selectsrc+0xd8
  
  udp_output(d8cfabfc,d80b6900,d80b6700,0,0) at udp_output+0xf8
  sosend(d7f881c8,d80b6700,f617ce90,d80b6900,0) at sosend+0x44b
  sendit(d84f4b40,103,f617cef4,0,f617cf80) at sendit+0x1e1
  sys_sendto(d84f4b40,f617cf60,f617cf80,d0568b5a,d84f4b40) at sys_sendto+0x6c
  syscall() at syscall+0x144
  --- syscall (number 259) ---
  0x2:
  ddb{0}
  
  
  screenshots:
  obiit.org/f/pagefault0.jpg
  obiit.org/f/pagefault1.jpg
  
  the running java process is jenkins.
  i cannot reproduce it all the time, but now it has
  happened twice: suspend at the end of the day,
  go to sleep, next day resume, page fault.
  both times when i was using jenkins.
  
  i can provide more information when it happens again,
  just let me know what exactly...
 
 Well... what's your dmesg?

sorry. attached.

 What's your network configuration, more explicitly are you using any USB
 device and how? 
 
 What kind of test is jenkins running?  How is it multicast related?

run0 usb dongle + dhclient through a home router,
with one special route added that is forwarded through
a linux box (on the same home router network) which
is connected to a vpn in a different country.
it is added like this:

# route add 192.168.10.2 $LINUX_IP

jenkins is running a shell script, that is running
tests on the 192.168.10.2 web site accessible only
through the vpn.  the tests are simple selenium tests
recorded through the firefox plugin.  a quick google
reveals that jenkins itself might be using some
udp/multicast functionality:
https://wiki.jenkins-ci.org/display/JENKINS/Auto-discovering+Jenkins+on+the+network

-f


OpenBSD 5.6-current (GENERIC.MP) #598: Tue Dec  9 00:45:47 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz (GenuineIntel 686-class) 1.67 
GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
real mem  = 2137341952 (2038MB)
avail mem = 2090082304 (1993MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/31/11, BIOS32 rev. 0 @ 0xfd690, SMBIOS 
rev. 2.4 @ 0xe0010 (67 entries)
bios0: vendor LENOVO version 7BETD8WW (2.19 ) date 03/31/2011
bios0: LENOVO 1705CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT 
SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz (GenuineIntel 686-class) 1.67 
GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 97 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 42T4629 serial   327 type LION oem SANYO
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
bios0: ROM list: 0xc/0xea00! 0xcf000/0x1000 0xd/0x1000 0xdc000/0x4000! 
0xe/0x1!
cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03
vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 

Re: upd(4) buggy firmware

2014-12-11 Thread Martin Pieuchot
On 09/12/14(Tue) 10:57, David Higgs wrote:
 On Dec 8, 2014, at 6:07 PM, Martin Pieuchot mpieuc...@nolizard.org wrote:
 
  On 08/12/14(Mon) 09:35, David Higgs wrote:
  On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot mpieuc...@nolizard.org 
  wrote:
  [...]
  Now I'd like to finish the transition that started with the import of
  upd(4) and move away from the actual 1 reportID = 1 driver model.
  Because in the end they are all sharing the same USB device actually
  represented by an uhidev(4) instance.  So I'll ride the refactoring
  needed by your buggy firmware to also change that.  Since all the
  uhidev_*_report() will be modified, we can also pass a pointer to
  the uhidev(4) device instead of one of its children.  Is it clearer?
  
  Sounds great to me.
  
  As promised, here's a second and last diff that changes the various
  uhidev_*_report() functions to provide the transfered length to the
  caller if requested.
  
  The *get* variant now also handles the first byte required for non-0
  reportID.
  
  And last but not least, it includes the hack from apcupsd to deal with
  buggy firmwares like yours.
  
  Could you try it and let me know how it goes?
 
 Seems to work just fine on my -current VM after adding the diff below (I 
 didn’t try without).  See my previous email in this thread for other comments 
 re: your diff.

Thanks for all your comments.  I though a bit more about this change and
decided to:

  - Simply return the number of bytes written/read upon success and -1
otherwise (à la read/write).  This allows us to remove some usages
of usbd_status when we are not directly manipulating a xfer
object.

  - Always consider a short transfer for SET requests as failures.

So the diff below includes your changes to upd(4) that I'll commit
separately if you're ok.

Concerning your remark about the USB_SET_IMMED ioctl(2), it doesn't
really matter, this interface is not used and should be removed.

Index: ucycom.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ucycom.c,v
retrieving revision 1.29
diff -u -p -r1.29 ucycom.c
--- ucycom.c12 Jul 2014 20:26:33 -  1.29
+++ ucycom.c11 Dec 2014 09:50:14 -
@@ -453,13 +453,9 @@ ucycom_param(void *addr, int portno, str
report[2] = (baud  16)  0xff;
report[3] = (baud  24)  0xff;
report[4] = cfg;
-   err = uhidev_set_report(sc-sc_hdev, UHID_FEATURE_REPORT,
-   sc-sc_hdev.sc_report_id, report, sc-sc_flen);
-   if (err != 0) {
-   DPRINTF((ucycom_param: uhidev_set_report %d %s\n,
-   err, usbd_errstr(err)));
+   if (uhidev_set_report(sc-sc_hdev.sc_parent, UHID_FEATURE_REPORT,
+   sc-sc_hdev.sc_report_id, report, sc-sc_flen) != sc-sc_flen)
return EIO;
-   }
sc-sc_baud = baud;
return (err);
 }
@@ -553,10 +549,10 @@ ucycom_set(void *addr, int portno, int r
 void
 ucycom_get_cfg(struct ucycom_softc *sc)
 {
-   int err, cfg, baud;
+   int cfg, baud;
uint8_t report[5];
 
-   err = uhidev_get_report(sc-sc_hdev, UHID_FEATURE_REPORT,
+   uhidev_get_report(sc-sc_hdev.sc_parent, UHID_FEATURE_REPORT,
sc-sc_hdev.sc_report_id, report, sc-sc_flen);
cfg = report[4];
baud = (report[3]  24) + (report[2]  16) + (report[1]  8) + 
report[0];
Index: ugold.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ugold.c,v
retrieving revision 1.6
diff -u -p -r1.6 ugold.c
--- ugold.c 29 Apr 2014 12:53:33 -  1.6
+++ ugold.c 11 Dec 2014 09:50:14 -
@@ -260,6 +260,9 @@ ugold_refresh(void *arg)
 int
 ugold_issue_cmd(struct ugold_softc *sc, uint8_t *cmd, int len)
 {
-   return uhidev_set_report_async(sc-sc_hdev, UHID_OUTPUT_REPORT,
-   sc-sc_hdev.sc_report_id, cmd, len);
+   int actlen;
+
+   actlen = uhidev_set_report_async(sc-sc_hdev.sc_parent,
+   UHID_OUTPUT_REPORT, sc-sc_hdev.sc_report_id, cmd, len);
+   return (actlen != len);
 }
Index: uhid.c
===
RCS file: /home/ncvs/src/sys/dev/usb/uhid.c,v
retrieving revision 1.58
diff -u -p -r1.58 uhid.c
--- uhid.c  12 Jul 2014 18:48:52 -  1.58
+++ uhid.c  11 Dec 2014 09:50:14 -
@@ -259,21 +259,17 @@ uhid_do_read(struct uhid_softc *sc, stru
 {
int s;
int error = 0;
-   int extra;
size_t length;
u_char buffer[UHID_CHUNK];
-   usbd_status err;
 
DPRINTFN(1, (uhidread\n));
if (sc-sc_state  UHID_IMMED) {
DPRINTFN(1, (uhidread immed\n));
-   extra = sc-sc_hdev.sc_report_id != 0;
-   err = uhidev_get_report(sc-sc_hdev, UHID_INPUT_REPORT,
-   sc-sc_hdev.sc_report_id, buffer,
-   sc-sc_hdev.sc_isize + extra);
-   if (err)
+   if (uhidev_get_report(sc-sc_hdev.sc_parent,
+

Re: upd(4) buggy firmware

2014-12-11 Thread Mark Kettenis
 Date: Thu, 11 Dec 2014 12:22:56 +0100
 From: Martin Pieuchot mpieuc...@nolizard.org
 
 Index: ucycom.c
 ===
 RCS file: /home/ncvs/src/sys/dev/usb/ucycom.c,v
 retrieving revision 1.29
 diff -u -p -r1.29 ucycom.c
 --- ucycom.c  12 Jul 2014 20:26:33 -  1.29
 +++ ucycom.c  11 Dec 2014 09:50:14 -
 @@ -453,13 +453,9 @@ ucycom_param(void *addr, int portno, str
   report[2] = (baud  16)  0xff;
   report[3] = (baud  24)  0xff;
   report[4] = cfg;
 - err = uhidev_set_report(sc-sc_hdev, UHID_FEATURE_REPORT,
 - sc-sc_hdev.sc_report_id, report, sc-sc_flen);
 - if (err != 0) {
 - DPRINTF((ucycom_param: uhidev_set_report %d %s\n,
 - err, usbd_errstr(err)));
 + if (uhidev_set_report(sc-sc_hdev.sc_parent, UHID_FEATURE_REPORT,
 + sc-sc_hdev.sc_report_id, report, sc-sc_flen) != sc-sc_flen)
   return EIO;
 - }
   sc-sc_baud = baud;
   return (err);
  }
 @@ -553,10 +549,10 @@ ucycom_set(void *addr, int portno, int r
  void
  ucycom_get_cfg(struct ucycom_softc *sc)
  {
 - int err, cfg, baud;
 + int cfg, baud;
   uint8_t report[5];
  
 - err = uhidev_get_report(sc-sc_hdev, UHID_FEATURE_REPORT,
 + uhidev_get_report(sc-sc_hdev.sc_parent, UHID_FEATURE_REPORT,
   sc-sc_hdev.sc_report_id, report, sc-sc_flen);
   cfg = report[4];
   baud = (report[3]  24) + (report[2]  16) + (report[1]  8) + 
 report[0];

Doesn't this mean that if you get a short reply, you'll be looking
at stack garbage?  Don't think that is a good idea...



LibreSSL: 'openssl' apps cleanup

2014-12-11 Thread Dmitry Eremin-Solenikov
Hello,

For the historic reasons there is a significant amount of duplicated
functionality.
For example one can use openssl rsa/dsa/ec to create/modify private/public keys
or it's possible to just use a generic openssl genpkey/pkey interface. I'd like
to suggest to clean up the first set of commands in favour of a
generic implementation.

What do you think?

-- 
With best wishes
Dmitry



Re: upd(4) buggy firmware

2014-12-11 Thread Martin Pieuchot
On 11/12/14(Thu) 12:48, Mark Kettenis wrote:
  Date: Thu, 11 Dec 2014 12:22:56 +0100
  From: Martin Pieuchot mpieuc...@nolizard.org
  
  Index: ucycom.c
  ===
  RCS file: /home/ncvs/src/sys/dev/usb/ucycom.c,v
  retrieving revision 1.29
  diff -u -p -r1.29 ucycom.c
  --- ucycom.c12 Jul 2014 20:26:33 -  1.29
  +++ ucycom.c11 Dec 2014 09:50:14 -
  @@ -453,13 +453,9 @@ ucycom_param(void *addr, int portno, str
  report[2] = (baud  16)  0xff;
  report[3] = (baud  24)  0xff;
  report[4] = cfg;
  -   err = uhidev_set_report(sc-sc_hdev, UHID_FEATURE_REPORT,
  -   sc-sc_hdev.sc_report_id, report, sc-sc_flen);
  -   if (err != 0) {
  -   DPRINTF((ucycom_param: uhidev_set_report %d %s\n,
  -   err, usbd_errstr(err)));
  +   if (uhidev_set_report(sc-sc_hdev.sc_parent, UHID_FEATURE_REPORT,
  +   sc-sc_hdev.sc_report_id, report, sc-sc_flen) != sc-sc_flen)
  return EIO;
  -   }
  sc-sc_baud = baud;
  return (err);
   }
  @@ -553,10 +549,10 @@ ucycom_set(void *addr, int portno, int r
   void
   ucycom_get_cfg(struct ucycom_softc *sc)
   {
  -   int err, cfg, baud;
  +   int cfg, baud;
  uint8_t report[5];
   
  -   err = uhidev_get_report(sc-sc_hdev, UHID_FEATURE_REPORT,
  +   uhidev_get_report(sc-sc_hdev.sc_parent, UHID_FEATURE_REPORT,
  sc-sc_hdev.sc_report_id, report, sc-sc_flen);
  cfg = report[4];
  baud = (report[3]  24) + (report[2]  16) + (report[1]  8) + 
  report[0];
 
 Doesn't this mean that if you get a short reply, you'll be looking
 at stack garbage?  Don't think that is a good idea...

I agree.  But that is already the case... well sort of because this
functions is never called.  I'll fix that :)



Re: LibreSSL: 'openssl' apps cleanup

2014-12-11 Thread Stuart Henderson
On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
 Hello,
 
 For the historic reasons there is a significant amount of duplicated
 functionality.
 For example one can use openssl rsa/dsa/ec to create/modify private/public 
 keys
 or it's possible to just use a generic openssl genpkey/pkey interface. I'd 
 like
 to suggest to clean up the first set of commands in favour of a
 generic implementation.
 
 What do you think?

The old interfaces are still very widely used, both in text
(books/guides/documentation) on handling keys, and directly used in
programs (to pick a couple: ikectl, easyrsa)

I dislike having two separate implementations in code that do basically
the same thing so perhaps they could be consolidated somehow, but
think the old command-line options would need to set things up to
call common code and work as before; removing them will cause
widespread difficulty.



Re: LibreSSL 2.1.2 linking issues

2014-12-11 Thread Lukas Tribus
 Many Lolz.. Lukas you just made my day..

 They've been misused that way, and more than once, by more than one
 project. This is why we really want it to be just a string, and
 strongly discourage people from using it in the way it has been
 abused.

 ... we could always change it so the string is wheezy, dopy, sneezy,
 drippy, or whatever for each release ;)

 Lukaz, is this the world you want:

 /* The following test is suggested by Richard Levitte */
 if (((OPENSSL_VERSION_NUMBER ^ SSLeay())  0xff0f)

 Yes, it is. Because you are asking for it.

I don't think it is. I'm perfectly fine with freezing OPENSSL_VERSION_NUMBER
and LIBRESSL_VERSION_NUMBER forever and ever.

I asked to bump the string in OPENSSL_VERSION_TEXT, which is currently
set to LibreSSL 2.1, but apparently that is just as bad. Of that I was not
aware.

Well then, let me ask you this: Why not drop the version in
OPENSSL_VERSION_TEXT altogether and simply set it to LibreSSL? That
way there is no confusion about what to expect from its content while
still permitting applications accessing it to build.


FYI: boringssl dropped this symbol completely, which means it breaks
the build of applications accessing it. That I believe is too intrusive in
the LibreSSL case.


It looks like serious packaging (of portable) should explicitly look at
major/minor in ssl/shlib_version then, instead of the actual libressl release,
just as its done in ports (afaik).



Lukas

  



Re: Implement a watchdog

2014-12-11 Thread sven falempin
Thank you all,

I grep(ed) -r NCT6 in sys and didn't find wbsio, I guess those
christmass holydays will be much welcome !

Does the wbsio detect the watchdog in the apu card ?

On Thu, Dec 11, 2014 at 5:56 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
 Date: Thu, 11 Dec 2014 05:08:11 -0500
 From: Matt Dainty m...@bodgit-n-scarper.com

 * sven falempin sven.falem...@gmail.com [2014-12-10 12:32:15]:
  On Wed, Dec 10, 2014 at 9:31 AM, Stuart Henderson st...@openbsd.org 
  wrote:
   On 2014/12/10 09:15, sven falempin wrote:
   http://lxr.free-electrons.com/source/drivers/hwmon/nct6775.c
  
   https://github.com/groeck/nct6775
  
   So i guess the first step is to detect the chip
  
   You'll also need somewhere (files) to put the detection. Maybe look at
   the commit from when tcpcib was added as an example.
  
   It might be somewhat similar to the Winbond superio chips (Nuvoton is
   a spin off company).
  
   On Wed, Dec 10, 2014 at 8:32 AM, sven falempin 
   sven.falem...@gmail.com wrote:
I guess the chip used is obviously this one :
   
Nuvoton NCT6106D
   
spec : 
https://download.nuvoton.com/NuvotonMOSS/DownloadService/Member/DocumentsInfo.aspx?tp_GUID=DA00-NCT6106D
  
   The watchdog part of this appears to use the same registers as NCT5104D
   in the pcengines APU.
 
  Well the sequence to configure is the same in the doc
 
  
  7.1.1 Enter the Extended Function Mode
  To place the chip into the Extended Function Mode, two successive
  writes of 0x87 must be applied to Extended
  Function Enable Registers (EFERs, i.e. 2Eh or 4Eh).
  
 
  I am not sure i understand, is this a pci device or a isa device ?

 Have a look at the wbsio(4) driver. There's already a constant defined for
 the NCT6776 so you probably just need to add the missing ID(s) and go from
 there.

 Yes indeed.  That's the correct thing to do.  According to the
 datasheet the Chip ID is 0x10, but we have found that recent Nuvoton
 datasheets often lie about this, so you might want to enable the
 printf in wbsio_probe() to see what the real chip ID is.

 Looks like the chip has a hardware monitoring function as well.  Might
 be possible to add support for this to lm(4).

 I believe somebody wrote a diff to add watchdog support for this
 family of chips at some point.  A bit of a problem is that on some of
 these chips the watchdog timer signal is multiplexed on one of the
 GPIO pins and that pin is often configurable.  Which pin to use (or
 whether the watchdog works at all) depends on the motherboard layout.
 And the pin that works on your motherboard might be the self destruct
 button on some other motherboard.  That's why we didn't pursue this
 any further at the time.  Things might be a bit saner for your chip
 though.

 Cheers,

 Mark



-- 
-
() ascii ribbon campaign - against html e-mail
/\



Re: LibreSSL: 'openssl' apps cleanup

2014-12-11 Thread Dmitry Eremin-Solenikov
2014-12-11 15:40 GMT+03:00 Stuart Henderson st...@openbsd.org:
 On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
 Hello,

 For the historic reasons there is a significant amount of duplicated
 functionality.
 For example one can use openssl rsa/dsa/ec to create/modify private/public 
 keys
 or it's possible to just use a generic openssl genpkey/pkey interface. I'd 
 like
 to suggest to clean up the first set of commands in favour of a
 generic implementation.

 What do you think?

 The old interfaces are still very widely used, both in text
 (books/guides/documentation) on handling keys, and directly used in
 programs (to pick a couple: ikectl, easyrsa)

 I dislike having two separate implementations in code that do basically
 the same thing so perhaps they could be consolidated somehow, but
 think the old command-line options would need to set things up to
 call common code and work as before; removing them will cause
 widespread difficulty.

Should LibreSSL start the process of deprecating them? Add a warning,
start updating users and docs?

-- 
With best wishes
Dmitry



Re: Implement a watchdog

2014-12-11 Thread Stuart Henderson
On 2014/12/11 07:41, sven falempin wrote:
 Thank you all,
 
 I grep(ed) -r NCT6 in sys and didn't find wbsio, I guess those
 christmass holydays will be much welcome !
 
 Does the wbsio detect the watchdog in the apu card ?

No, as the manual says, Only the hardware monitoring function is
currently supported, and at present, and this driver doesn't attach
on the APU.



Re: LibreSSL: 'openssl' apps cleanup

2014-12-11 Thread Stuart Henderson
On 2014/12/11 16:42, Dmitry Eremin-Solenikov wrote:
 2014-12-11 15:40 GMT+03:00 Stuart Henderson st...@openbsd.org:
  On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
  Hello,
 
  For the historic reasons there is a significant amount of duplicated
  functionality.
  For example one can use openssl rsa/dsa/ec to create/modify private/public 
  keys
  or it's possible to just use a generic openssl genpkey/pkey interface. I'd 
  like
  to suggest to clean up the first set of commands in favour of a
  generic implementation.
 
  What do you think?
 
  The old interfaces are still very widely used, both in text
  (books/guides/documentation) on handling keys, and directly used in
  programs (to pick a couple: ikectl, easyrsa)
 
  I dislike having two separate implementations in code that do basically
  the same thing so perhaps they could be consolidated somehow, but
  think the old command-line options would need to set things up to
  call common code and work as before; removing them will cause
  widespread difficulty.
 
 Should LibreSSL start the process of deprecating them? Add a warning,
 start updating users and docs?

Good luck!

Google for openssl genrsa says About 108,000 results, the same
search on github We've found 40,410 code results.



5.5 - 5.6 in www/stable.html

2014-12-11 Thread Raf
Hi all,

I've just noticed one more page in need of 5.5 - 5.6 update - diff
below.

Regards,

Raf

Index: www/stable.html
===
RCS file: /cvs/www/stable.html,v
retrieving revision 1.36
diff -u -p -r1.36 stable.html
--- www/stable.html 4 Sep 2014 01:17:10 -   1.36
+++ www/stable.html 11 Dec 2014 13:10:10 -
@@ -85,12 +85,12 @@ Instructions for getting the patch branc
 described in the bGetting Started/b section of the
 a href=anoncvs.html#startingAnonCVS documentation/a.
 Note that patch branches do not help to upgrade from one release of
-OpenBSD to another, e.g. to go from 5.4 to 5.5.  They only provide
+OpenBSD to another, e.g. to go from 5.5 to 5.6.  They only provide
 a means for staying up to date with the patches within a given release.
 
 p
 Do not attempt to go from one release to another via source.
-Instead, please visit the a href=faq/upgrade55.htmlupgrade guide/a.
+Instead, please visit the a href=faq/upgrade56.htmlupgrade guide/a.
 Also, you cannot go backwards, from -current back to -stable, because of
 library versioning problems and other changes.
 



Re: page fault at resume, possibly caused by java/jenkins

2014-12-11 Thread Martin Pieuchot
On 11/12/14(Thu) 12:37, frantisek holop wrote:
   login: kernel: page fault trap, code=0
   Stopped at  in_selectsrc+0xd8:  movl 0xf0(%esi),%ebx
   ddb{0} trace
   in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at 
   in_selectsrc+0xd8
   
   udp_output(d8cfabfc,d80b6900,d80b6700,0,0) at udp_output+0xf8
   sosend(d7f881c8,d80b6700,f617ce90,d80b6900,0) at sosend+0x44b
   sendit(d84f4b40,103,f617cef4,0,f617cf80) at sendit+0x1e1
   sys_sendto(d84f4b40,f617cf60,f617cf80,d0568b5a,d84f4b40) at 
   sys_sendto+0x6c
   syscall() at syscall+0x144
   --- syscall (number 259) ---
   0x2:
   ddb{0}
 
 run0 usb dongle + dhclient through a home router,
 with one special route added that is forwarded through
 a linux box (on the same home router network) which
 is connected to a vpn in a different country.
 it is added like this:
 
 # route add 192.168.10.2 $LINUX_IP
 
 jenkins is running a shell script, that is running
 tests on the 192.168.10.2 web site accessible only
 through the vpn.  the tests are simple selenium tests
 recorded through the firefox plugin.  a quick google
 reveals that jenkins itself might be using some
 udp/multicast functionality:
 https://wiki.jenkins-ci.org/display/JENKINS/Auto-discovering+Jenkins+on+the+network

Could you try the diff below and let me know if it improves the
situation?  It should prevent your kernel to panic.  Even though,
more work might be required to have working socket w/ multicast
using USB devices upon resume.

What's happening is simply a use after free because there's no way to
invalidate multicast options attached to a pcb when an interface is
detached.  I which multicast would have been implemented using route
entries instead of this hack...

Change below works around this problem by using interface indexes.

Index: net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.306
diff -u -p -r1.306 if.c
--- net/if.c8 Dec 2014 10:46:14 -   1.306
+++ net/if.c11 Dec 2014 13:09:23 -
@@ -533,11 +533,6 @@ do { \
 #endif
 #undef IF_DETACH_QUEUES
 
-   /*
-* XXX transient ifp refs?  inpcb.ip_moptions.imo_multicast_ifp?
-* Other network stacks than INET?
-*/
-
/* Remove the interface from the list of all interfaces.  */
TAILQ_REMOVE(ifnet, ifp, if_list);
if (ISSET(ifp-if_xflags, IFXF_TXREADY))
Index: net/if_pfsync.c
===
RCS file: /home/ncvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.212
diff -u -p -r1.212 if_pfsync.c
--- net/if_pfsync.c 23 Nov 2014 07:39:02 -  1.212
+++ net/if_pfsync.c 11 Dec 2014 13:09:23 -
@@ -1354,7 +1354,7 @@ pfsyncioctl(struct ifnet *ifp, u_long cm
if (imo-imo_num_memberships  0) {
in_delmulti(imo-imo_membership[
--imo-imo_num_memberships]);
-   imo-imo_multicast_ifp = NULL;
+   imo-imo_ifidx = 0;
}
splx(s);
break;
@@ -1379,7 +1379,7 @@ pfsyncioctl(struct ifnet *ifp, u_long cm
 
if (imo-imo_num_memberships  0) {

in_delmulti(imo-imo_membership[--imo-imo_num_memberships]);
-   imo-imo_multicast_ifp = NULL;
+   imo-imo_ifidx = 0;
}
 
if (sc-sc_sync_if 
@@ -1401,7 +1401,7 @@ pfsyncioctl(struct ifnet *ifp, u_long cm
return (ENOBUFS);
}
imo-imo_num_memberships++;
-   imo-imo_multicast_ifp = sc-sc_sync_if;
+   imo-imo_ifidx = sc-sc_sync_if-if_index;
imo-imo_multicast_ttl = PFSYNC_DFLTTL;
imo-imo_multicast_loop = 0;
}
Index: net/if_vxlan.c
===
RCS file: /home/ncvs/src/sys/net/if_vxlan.c,v
retrieving revision 1.17
diff -u -p -r1.17 if_vxlan.c
--- net/if_vxlan.c  5 Dec 2014 15:50:04 -   1.17
+++ net/if_vxlan.c  11 Dec 2014 13:09:23 -
@@ -179,8 +179,9 @@ vxlan_multicast_cleanup(struct ifnet *if
 {
struct vxlan_softc  *sc = (struct vxlan_softc *)ifp-if_softc;
struct ip_moptions  *imo = sc-sc_imo;
-   struct ifnet*mifp = imo-imo_multicast_ifp;
+   struct ifnet*mifp;
 
+   mifp = if_get(imo-imo_ifidx);
if (mifp != NULL) {
if (sc-sc_ahcookie != NULL) {
hook_disestablish(mifp-if_addrhooks, sc-sc_ahcookie);
@@ -200,7 +201,7 @@ vxlan_multicast_cleanup(struct ifnet *if
 
if (imo-imo_num_memberships  0) {
in_delmulti(imo-imo_membership[--imo-imo_num_memberships]);
-   imo-imo_multicast_ifp 

Re: LibreSSL 2.1.2 linking issues

2014-12-11 Thread Brent Cook
On Thu, Dec 11, 2014 at 6:41 AM, Lukas Tribus luky...@hotmail.com wrote:
 Many Lolz.. Lukas you just made my day..

 They've been misused that way, and more than once, by more than one
 project. This is why we really want it to be just a string, and
 strongly discourage people from using it in the way it has been
 abused.

 ... we could always change it so the string is wheezy, dopy, sneezy,
 drippy, or whatever for each release ;)

 Lukaz, is this the world you want:

 /* The following test is suggested by Richard Levitte */
 if (((OPENSSL_VERSION_NUMBER ^ SSLeay())  0xff0f)

 Yes, it is. Because you are asking for it.

 I don't think it is. I'm perfectly fine with freezing OPENSSL_VERSION_NUMBER
 and LIBRESSL_VERSION_NUMBER forever and ever.

 I asked to bump the string in OPENSSL_VERSION_TEXT, which is currently
 set to LibreSSL 2.1, but apparently that is just as bad. Of that I was not
 aware.

 Well then, let me ask you this: Why not drop the version in
 OPENSSL_VERSION_TEXT altogether and simply set it to LibreSSL? That
 way there is no confusion about what to expect from its content while
 still permitting applications accessing it to build.

I like that idea. That makes it consistently correct, rather than a
broken clock that's right twice a day.


 FYI: boringssl dropped this symbol completely, which means it breaks
 the build of applications accessing it. That I believe is too intrusive in
 the LibreSSL case.


 It looks like serious packaging (of portable) should explicitly look at
 major/minor in ssl/shlib_version then, instead of the actual libressl release,
 just as its done in ports (afaik).

For API/ABI compatibility, yes. I guess the only thing we haven't
addressed is security updates, which is probably why you wanted the
string in the first place. Does pkg-config --modversion openssl
scratch the itch properly for cases not using OS packages?

All of the ops shops I've worked at just made their own local apt or
yum package repos, so there wasn't any need to use package-specific
commands to determine what versions were installed. I guess in the
openssl(1) case, it has a longer history than most packages.


 Lukas





[PATCH] Use the individual library versions in LibreSSL pc files

2014-12-11 Thread Brent Cook
Previously, they were all using the portable package version, rather
than the individual library versions. openssl(1)'s pc file represents
the LibreSSL-portable release however.

$ pkg-config --modversion libtls
1:0:0
$ pkg-config --modversion openssl
2.1.2
$ pkg-config --modversion libssl
30:0:0
$ pkg-config --modversion libcrypto
30:3:0
---
 libcrypto.pc.in | 2 +-
 libssl.pc.in| 2 +-
 libtls.pc.in| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libcrypto.pc.in b/libcrypto.pc.in
index 4e886b9..f44e3aa 100644
--- a/libcrypto.pc.in
+++ b/libcrypto.pc.in
@@ -7,7 +7,7 @@ includedir=@includedir@
 
 Name: LibreSSL-libssl
 Description: Secure Sockets Layer and cryptography libraries
-Version: @VERSION@
+Version: @LIBCRYPTO_VERSION@
 Requires:
 Conflicts:
 Libs: -L${libdir} -lcrypto
diff --git a/libssl.pc.in b/libssl.pc.in
index 43b8bb7..1800264 100644
--- a/libssl.pc.in
+++ b/libssl.pc.in
@@ -7,7 +7,7 @@ includedir=@includedir@
 
 Name: LibreSSL-libssl
 Description: Secure Sockets Layer and cryptography libraries
-Version: @VERSION@
+Version: @LIBSSL_VERSION@
 Requires:
 Requires.private: libcrypto
 Conflicts:
diff --git a/libtls.pc.in b/libtls.pc.in
index 19e6b32..64d7457 100644
--- a/libtls.pc.in
+++ b/libtls.pc.in
@@ -7,7 +7,7 @@ includedir=@includedir@
 
 Name: LibreSSL-libtls
 Description: Secure communications using the TLS socket protocol.
-Version: @VERSION@
+Version: @LIBTLS_VERSION@
 Requires:
 Requires.private: libcrypto libssl
 Conflicts:
-- 
2.2.0



Re: LibreSSL: 'openssl' apps cleanup

2014-12-11 Thread Bob Beck
Short answer Dmitry: No.

Doing so doesn't solve a real problem, and creates many others. Sure
we might not like it ourselves and would never build new software this
way, but removing this legacy at this stage would only break things
for no benefit.  (We're very happy to break things when there is a
real benefit)

On Thu, Dec 11, 2014 at 5:42 AM, Dmitry Eremin-Solenikov
dbarysh...@gmail.com wrote:
 2014-12-11 15:40 GMT+03:00 Stuart Henderson st...@openbsd.org:
 On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
 Hello,

 For the historic reasons there is a significant amount of duplicated
 functionality.
 For example one can use openssl rsa/dsa/ec to create/modify private/public 
 keys
 or it's possible to just use a generic openssl genpkey/pkey interface. I'd 
 like
 to suggest to clean up the first set of commands in favour of a
 generic implementation.

 What do you think?

 The old interfaces are still very widely used, both in text
 (books/guides/documentation) on handling keys, and directly used in
 programs (to pick a couple: ikectl, easyrsa)

 I dislike having two separate implementations in code that do basically
 the same thing so perhaps they could be consolidated somehow, but
 think the old command-line options would need to set things up to
 call common code and work as before; removing them will cause
 widespread difficulty.

 Should LibreSSL start the process of deprecating them? Add a warning,
 start updating users and docs?

 --
 With best wishes
 Dmitry




Reduce OPENSSL_VERSION_TEXT to LibreSSL

2014-12-11 Thread Brent Cook
To reduce reliance on this string, and to make it more consistently
correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
to say the bare minimum.

There are better, more portable and consistent mechanisms for
determining the installed versions of packages, such as the OS package
manager, versions on user-generated packages, or the pkg-config tool.

If an app wants to statically link LibreSSL and emit the version at the
command line, it should use pkg-config to generate its own strings (and
that should work for all libraries, not just OpenSSL/LibreSSL).

This has never matched the shared library version numbers anyway.  

Index: opensslv.h
===
RCS file: /cvs/src/lib/libssl/src/crypto/opensslv.h,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 opensslv.h
--- opensslv.h  14 Oct 2014 13:12:35 -  1.28
+++ opensslv.h  11 Dec 2014 14:05:39 -
@@ -4,7 +4,7 @@
 
 #define LIBRESSL_VERSION_NUMBER0x2000L
 #define OPENSSL_VERSION_NUMBER 0x2000L
-#define OPENSSL_VERSION_TEXT   LibreSSL 2.1
+#define OPENSSL_VERSION_TEXT   LibreSSL
 #define OPENSSL_VERSION_PTEXT   part of  OPENSSL_VERSION_TEXT
 
 #define SHLIB_VERSION_HISTORY 



Re: no allocbuf in buffercache

2014-12-11 Thread Jason McIntyre
On Wed, Dec 10, 2014 at 06:15:04PM +0200, Kaspars Bankovskis wrote:
 allocbuf was removed in 1.88 of sys/kern/vfs_bio.c
 
 but not from manpages
 

fixed, but couple of comments inline:

 Index: distrib/sets/lists/comp/mi
 ===
 RCS file: /cvs/src/distrib/sets/lists/comp/mi,v
 retrieving revision 1.1117
 diff -u -p -r1.1117 mi
 --- distrib/sets/lists/comp/mi9 Dec 2014 18:35:05 -   1.1117
 +++ distrib/sets/lists/comp/mi10 Dec 2014 15:55:52 -
 @@ -6022,7 +6022,6 @@
  ./usr/share/man/man9/add_true_randomness.9
  ./usr/share/man/man9/add_tty_randomness.9
  ./usr/share/man/man9/addlog.9
 -./usr/share/man/man9/allocbuf.9
  ./usr/share/man/man9/aml_evalname.9
  ./usr/share/man/man9/aml_evalnode.9
  ./usr/share/man/man9/aml_find_node.9

no need to do this. it happens by magic.

 Index: share/man/man9/Makefile
 ===
 RCS file: /cvs/src/share/man/man9/Makefile,v
 retrieving revision 1.223
 diff -u -p -r1.223 Makefile
 --- share/man/man9/Makefile   24 Nov 2014 12:43:54 -  1.223
 +++ share/man/man9/Makefile   10 Dec 2014 15:57:25 -
 @@ -70,7 +70,7 @@ MLINKS+=buffercache.9 bread.9 buffercach
   buffercache.9 bwrite.9 buffercache.9 bawrite.9 \
   buffercache.9 bdwrite.9 buffercache.9 getblk.9 \
   buffercache.9 geteblk.9 buffercache.9 incore.9 \
 - buffercache.9 allocbuf.9 buffercache.9 brelse.9 \
 + buffercache.9 buffercache.9 brelse.9 \
   buffercache.9 biodone.9 buffercache.9 biowait.9
  MLINKS+=bufq_init.9 bufq_switch.9 bufq_init.9 bufq_destroy.9 \
   bufq_init.9 bufq_queue.9 bufq_init.9 bufq_dequeue.9 \

the mlink format is like normal link, so source target. so the new
line above should be:

+buffercache.9 brelse.9

jmc

 Index: share/man/man9/buffercache.9
 ===
 RCS file: /cvs/src/share/man/man9/buffercache.9,v
 retrieving revision 1.9
 diff -u -p -r1.9 buffercache.9
 --- share/man/man9/buffercache.9  11 Jun 2013 16:42:05 -  1.9
 +++ share/man/man9/buffercache.9  10 Dec 2014 15:58:38 -
 @@ -115,7 +115,6 @@
  .Nm getblk ,
  .Nm geteblk ,
  .Nm incore ,
 -.Nm allocbuf ,
  .Nm brelse ,
  .Nm biodone ,
  .Nm biowait
 @@ -144,8 +143,6 @@
  .Ft struct buf *
  .Fn incore struct vnode *vp daddr_t blkno
  .Ft void
 -.Fn allocbuf struct buf *bp int size
 -.Ft void
  .Fn brelse struct buf *bp
  .Ft void
  .Fn biodone struct buf *bp
 @@ -296,16 +293,6 @@ Note that
  .Fn incore
  doesn't mark the buffer as busy unlike
  .Fn getblk .
 -.\ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 -.It Fn allocbuf bp size
 -Expand or contract the actual memory allocated to a buffer.
 -If the buffer shrinks, the truncated part of the data
 -is lost, so it is up to the caller to have written
 -it out
 -.Em first
 -if needed; this routine will not start a write.
 -If the buffer grows, it is the caller's responsibility to fill out
 -the buffer's additional contents.
  .\ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  .It Fn brelse bp
  Unlock a buffer by clearing the
 



Re: typos

2014-12-11 Thread Jason McIntyre
On Wed, Dec 10, 2014 at 12:21:21PM +0200, Kaspars Bankovskis wrote:
 Index: vfs_bio.c
 ===
 RCS file: /cvs/src/sys/kern/vfs_bio.c,v
 retrieving revision 1.163
 diff -u -p -r1.163 vfs_bio.c
 --- vfs_bio.c 8 Oct 2014 07:33:14 -   1.163
 +++ vfs_bio.c 9 Dec 2014 21:25:27 -
 @@ -86,7 +86,7 @@ long lodirtypages;  /* dirty page co
  long hidirtypages;  /* dirty page count high water mark */
  long targetpages;/* target number of pages for cache size */
  long buflowpages;/* smallest size cache allowed */
 -long bufhighpages;   /* largerst size cache allowed */
 +long bufhighpages;   /* largest size cache allowed */
  long bufbackpages;   /* minimum number of pages we shrink when asked to */
  
  vsize_t bufkvm;
 @@ -959,7 +959,7 @@ buf_get(struct vnode *vp, daddr_t blkno,
* We insert the buffer into the hash with B_BUSY set
* while we allocate pages for it. This way any getblk
* that happens while we allocate pages will wait for
 -  * this buffer instead of starting its own guf_get.
 +  * this buffer instead of starting its own buf_get.
*
* But first, we check if someone beat us to it.
*/
 

fixed, thanks.
jmc



Re: no allocbuf in buffercache

2014-12-11 Thread Kaspars Bankovskis
On Thu, Dec 11, 2014 at 02:31:32PM +, Jason McIntyre wrote:
 fixed, but couple of comments inline:

OK, thanks for corrections, will keep in mind.



Re: LibreSSL: 'openssl' apps cleanup

2014-12-11 Thread Brent Cook
On Thu, Dec 11, 2014 at 6:51 AM, Stuart Henderson st...@openbsd.org wrote:
 On 2014/12/11 16:42, Dmitry Eremin-Solenikov wrote:
 2014-12-11 15:40 GMT+03:00 Stuart Henderson st...@openbsd.org:
  On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
  Hello,
 
  For the historic reasons there is a significant amount of duplicated
  functionality.
  For example one can use openssl rsa/dsa/ec to create/modify 
  private/public keys
  or it's possible to just use a generic openssl genpkey/pkey interface. 
  I'd like
  to suggest to clean up the first set of commands in favour of a
  generic implementation.
 
  What do you think?
 
  The old interfaces are still very widely used, both in text
  (books/guides/documentation) on handling keys, and directly used in
  programs (to pick a couple: ikectl, easyrsa)
 
  I dislike having two separate implementations in code that do basically
  the same thing so perhaps they could be consolidated somehow, but
  think the old command-line options would need to set things up to
  call common code and work as before; removing them will cause
  widespread difficulty.

 Should LibreSSL start the process of deprecating them? Add a warning,
 start updating users and docs?

 Good luck!

 Google for openssl genrsa says About 108,000 results, the same
 search on github We've found 40,410 code results.


Maybe it would be better to direct energy toward simpler, TLS-focused
app altogether to live along-side the openssl(1) app, in the vein of
libtls?  There certainly would be demand for an app that:

1. makes all modern, common use cases easy and obvious how to use:
   (generate/sign/verify/dump certs, benchmark, netcat-style TLS client, server)
2. uses regular getopt-style arguments
3. makes something like setting up a local CA and generating a
self-signed key as easy as reading the manpage
4. is a good example of library usage and coding style

I believe boringssl has something called 'bssl'.  What about calling
it 'tis'? Maybe I should stop talking about it and get coding (though
don't let me stop you!)...



Re: Reduce OPENSSL_VERSION_TEXT to LibreSSL

2014-12-11 Thread Mark Kettenis
 Date: Thu, 11 Dec 2014 08:15:06 -0600
 From: Brent Cook bust...@gmail.com
 
 To reduce reliance on this string, and to make it more consistently
 correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
 to say the bare minimum.
 
 There are better, more portable and consistent mechanisms for
 determining the installed versions of packages, such as the OS package
 manager, versions on user-generated packages, or the pkg-config tool.

So what will 'openssl version' print after this change?



Re: Reduce OPENSSL_VERSION_TEXT to LibreSSL

2014-12-11 Thread Bob Beck
Absolutely yes.

On Thu, Dec 11, 2014 at 7:15 AM, Brent Cook bust...@gmail.com wrote:
 To reduce reliance on this string, and to make it more consistently
 correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
 to say the bare minimum.

 There are better, more portable and consistent mechanisms for
 determining the installed versions of packages, such as the OS package
 manager, versions on user-generated packages, or the pkg-config tool.

 If an app wants to statically link LibreSSL and emit the version at the
 command line, it should use pkg-config to generate its own strings (and
 that should work for all libraries, not just OpenSSL/LibreSSL).

 This has never matched the shared library version numbers anyway.

 Index: opensslv.h
 ===
 RCS file: /cvs/src/lib/libssl/src/crypto/opensslv.h,v
 retrieving revision 1.28
 diff -u -p -u -p -r1.28 opensslv.h
 --- opensslv.h  14 Oct 2014 13:12:35 -  1.28
 +++ opensslv.h  11 Dec 2014 14:05:39 -
 @@ -4,7 +4,7 @@

  #define LIBRESSL_VERSION_NUMBER0x2000L
  #define OPENSSL_VERSION_NUMBER 0x2000L
 -#define OPENSSL_VERSION_TEXT   LibreSSL 2.1
 +#define OPENSSL_VERSION_TEXT   LibreSSL
  #define OPENSSL_VERSION_PTEXT   part of  OPENSSL_VERSION_TEXT

  #define SHLIB_VERSION_HISTORY 




Re: Reduce OPENSSL_VERSION_TEXT to LibreSSL

2014-12-11 Thread Bob Beck
likely whatever we change it to print.  but we should catch that.

On Thu, Dec 11, 2014 at 8:34 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
 Date: Thu, 11 Dec 2014 08:15:06 -0600
 From: Brent Cook bust...@gmail.com

 To reduce reliance on this string, and to make it more consistently
 correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
 to say the bare minimum.

 There are better, more portable and consistent mechanisms for
 determining the installed versions of packages, such as the OS package
 manager, versions on user-generated packages, or the pkg-config tool.

 So what will 'openssl version' print after this change?




Re: Reduce OPENSSL_VERSION_TEXT to LibreSSL

2014-12-11 Thread Bob Beck
i.e. if we want the openssl command to report someting specific we
put it in there, not a globally visible string that will be used for
the wrong things.

On Thu, Dec 11, 2014 at 8:37 AM, Bob Beck b...@openbsd.org wrote:
 likely whatever we change it to print.  but we should catch that.

 On Thu, Dec 11, 2014 at 8:34 AM, Mark Kettenis mark.kette...@xs4all.nl 
 wrote:
 Date: Thu, 11 Dec 2014 08:15:06 -0600
 From: Brent Cook bust...@gmail.com

 To reduce reliance on this string, and to make it more consistently
 correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
 to say the bare minimum.

 There are better, more portable and consistent mechanisms for
 determining the installed versions of packages, such as the OS package
 manager, versions on user-generated packages, or the pkg-config tool.

 So what will 'openssl version' print after this change?




Re: page fault at resume, possibly caused by java/jenkins

2014-12-11 Thread Mike Belopuhov
On 11 December 2014 at 14:16, Martin Pieuchot mpieuc...@nolizard.org wrote:
 On 11/12/14(Thu) 12:37, frantisek holop wrote:
   login: kernel: page fault trap, code=0
   Stopped at  in_selectsrc+0xd8:  movl 0xf0(%esi),%ebx
   ddb{0} trace
   in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at 
   in_selectsrc+0xd8
  
   udp_output(d8cfabfc,d80b6900,d80b6700,0,0) at udp_output+0xf8
   sosend(d7f881c8,d80b6700,f617ce90,d80b6900,0) at sosend+0x44b
   sendit(d84f4b40,103,f617cef4,0,f617cf80) at sendit+0x1e1
   sys_sendto(d84f4b40,f617cf60,f617cf80,d0568b5a,d84f4b40) at 
   sys_sendto+0x6c
   syscall() at syscall+0x144
   --- syscall (number 259) ---
   0x2:
   ddb{0}

 run0 usb dongle + dhclient through a home router,
 with one special route added that is forwarded through
 a linux box (on the same home router network) which
 is connected to a vpn in a different country.
 it is added like this:

 # route add 192.168.10.2 $LINUX_IP

 jenkins is running a shell script, that is running
 tests on the 192.168.10.2 web site accessible only
 through the vpn.  the tests are simple selenium tests
 recorded through the firefox plugin.  a quick google
 reveals that jenkins itself might be using some
 udp/multicast functionality:
 https://wiki.jenkins-ci.org/display/JENKINS/Auto-discovering+Jenkins+on+the+network

 Could you try the diff below and let me know if it improves the
 situation?  It should prevent your kernel to panic.  Even though,
 more work might be required to have working socket w/ multicast
 using USB devices upon resume.

 What's happening is simply a use after free because there's no way to
 invalidate multicast options attached to a pcb when an interface is
 detached.  I which multicast would have been implemented using route
 entries instead of this hack...

 Change below works around this problem by using interface indexes.


Makes sense to me.  OK mikeb



Re: Reduce OPENSSL_VERSION_TEXT to LibreSSL

2014-12-11 Thread Mark Kettenis
 From: Bob Beck b...@openbsd.org
 Date: Thu, 11 Dec 2014 08:39:15 -0700
 
 i.e. if we want the openssl command to report someting specific we
 put it in there, not a globally visible string that will be used for
 the wrong things.

I think you guys are trying to hard to prevent people to shoot
themselves in the foot.  As long as OpenSSL includes a version number
there, people will try this anyway.  Shrug.



Re: upd(4) buggy firmware

2014-12-11 Thread David Higgs
On Thu, Dec 11, 2014 at 6:22 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
 Thanks for all your comments.  I though a bit more about this change and
 decided to:

   - Simply return the number of bytes written/read upon success and -1
 otherwise (à la read/write).  This allows us to remove some usages
 of usbd_status when we are not directly manipulating a xfer
 object.

   - Always consider a short transfer for SET requests as failures.

 So the diff below includes your changes to upd(4) that I'll commit
 separately if you're ok.

 Concerning your remark about the USB_SET_IMMED ioctl(2), it doesn't
 really matter, this interface is not used and should be removed.


Aside from what kettenis@ already saw, I also notice that
uhidev_use_rdesc and ukbd_set_leds don't check their set_report calls,
but that was the case in the previous code too.

Other than that, the diff looks good and runs my UPS fine.  Commit in
whatever chunks you deem appropriate.

Thanks.

--david



Re: Binary code patching and paravirtualization

2014-12-11 Thread Stefan Fritsch
On Thursday 11 December 2014 22:20:06, Jonathan Gray wrote:
 On Wed, Dec 10, 2014 at 12:32:02AM +0100, Stefan Fritsch wrote:
  For the codepatching part, the most interesting files are
  codepatch.c and codepatch.h.  In copy.S and cpu.c, I convert the
  code patching already done for SMAP to the new infrastructure (if
  someone has a machine with SMAP support, testing would be nice).
 
 There aren't so many machines with SMAP commercially released only
 a handful of 2 in 1 devices with Core M processors.
 
 You should be able to test with the qemu support added by Intel
 however. ie
 qemu-system-x86_64 -cpu qemu64,+smap
 or
 qemu-system-x86_64 -cpu Broadwell

thanks for the info. I will try that.

 
  The basic approach is to create macros that surround a
  to-be-patched code part and store pointer, length, and a tag in a
  dedicated section. Then there are functions to replace all code
  parts with a specific tag. Does this part of the diff look
  sensible?
 
 What about i386?  Though not included in your diff we can't assume
 the various multi byte nop sequences are valid there.
 
 The Intel instruction set reference says:
 The multi-byte NOP instruction performs no operation on supported
 processors and generates undefined opcode exception on processors
 that do not support the multi-byte NOP instruction.
 
 It seems in practice they are supported on everything after
 686/pentium pro?
 
 Though the code doing the patching could do a cpuid check.

As first step, I would only commit amd64 support. If that works, we 
can split it into MI and MD parts and add support for other 
architectures. But the functions to replace code with NOPs or a 
function call will always be MD. When those are implemented for i386, 
one can include appropriate cpuid checks. But as there is no place to 
put MD code that is used by both amd64 and i386, there will probably 
be two similar but independent implementations for those two archs. Or 
do you see a better way?




Re: skgpio crash on i386 (#604)

2014-12-11 Thread Miod Vallat
 Hi,
 
 I'm encountering system crash during boot with latest snapshot.  Turns
 out that it works fine when I disable skgpio through UKC.

Try this.

Index: skgpio.c
===
RCS file: /cvs/src/sys/dev/isa/skgpio.c,v
retrieving revision 1.1
diff -u -p -r1.1 skgpio.c
--- skgpio.c10 Dec 2014 05:42:25 -  1.1
+++ skgpio.c11 Dec 2014 20:20:36 -
@@ -89,8 +89,9 @@ skgpio_match(struct device *parent, void
struct isa_attach_args *ia = aux;
bus_space_handle_t ioh;
 
-   if (strcmp(hw_vendor, Soekris Engineering) ||
-   strcmp(hw_prod, net6501))
+   if (hw_vendor == NULL || hw_prod == NULL ||
+   strcmp(hw_vendor, Soekris Engineering) != 0 ||
+   strcmp(hw_prod, net6501) != 0)
return (0);
 
if (ia-ia_iobase != SKGPIO_BASE || bus_space_map(ia-ia_iot,



Re: skgpio crash on i386 (#604)

2014-12-11 Thread Tobias Stoeckmann
On Thu, Dec 11, 2014 at 08:21:12PM +, Miod Vallat wrote:
  Hi,
  
  I'm encountering system crash during boot with latest snapshot.  Turns
  out that it works fine when I disable skgpio through UKC.
 
 Try this.

Okay tobias@, too. ;)

The system boots nicely again, thanks!



Re: Binary code patching and paravirtualization

2014-12-11 Thread Alexey Suslikov
Stefan Fritsch sf at sfritsch.de writes:

 --- a/sys/arch/amd64/include/specialreg.h
 +++ b/sys/arch/amd64/include/specialreg.h
  at  at  -158,6 +158,7  at  at 
  #define  CPUIDECX_AVX0x1000  /* Advanced Vector Extensions 
*/
  #define  CPUIDECX_F16C   0x2000  /* 16bit fp conversion  */
  #define  CPUIDECX_RDRAND 0x4000  /* RDRAND instruction  */
 +#define  CPUIDECX_HYPERV 0x8000  /* Hypervisor present */

Is this flag standardized? Last time I have tried to push this, there
was an objection based on reserved for future use status of this flag.

See http://marc.info/?l=openbsd-bugsm=136907278229145w=2

If it is a standard nowadays, could CPUIDECX_HYPERV be committed as a
separate chunk?

Cheers,
Alexey



Re: Binary code patching and paravirtualization

2014-12-11 Thread Mark Kettenis
 From: Alexey Suslikov alexey.susli...@gmail.com
 Date: Thu, 11 Dec 2014 20:51:14 + (UTC)
 
 Stefan Fritsch sf at sfritsch.de writes:
 
  --- a/sys/arch/amd64/include/specialreg.h
  +++ b/sys/arch/amd64/include/specialreg.h
   at  at  -158,6 +158,7  at  at 
   #defineCPUIDECX_AVX0x1000  /* Advanced Vector Extensions 
 */
   #defineCPUIDECX_F16C   0x2000  /* 16bit fp conversion  */
   #defineCPUIDECX_RDRAND 0x4000  /* RDRAND instruction  */
  +#defineCPUIDECX_HYPERV 0x8000  /* Hypervisor present */
 
 Is this flag standardized? Last time I have tried to push this, there
 was an objection based on reserved for future use status of this flag.
 
 See http://marc.info/?l=openbsd-bugsm=136907278229145w=2

Well, that thread started out with a questionable workaround for a
hypervisor bug.  That may have have influenced the debate about the
flag a bit.

You can be almost certain that Intel and AMD will not use that
reserved bit for anything else.  The Linux KVM virtualization business
is too important for them.  And if Microsoft Hyper-V or VMWare ESX
sets that bit as well, this becomes an absolute certainty.

That said:

 If it is a standard nowadays, could CPUIDECX_HYPERV be committed as a
 separate chunk?

I prefer the CPUIDECX_HV name used in the diff you posted in:

  http://marc.info/?l=openbsd-bugsm=136906997828078w=2

We print these flags, and they're already taking up a significant part
of dmesg real estate.

Cheers,

Mark



Re: Binary code patching and paravirtualization

2014-12-11 Thread Theo de Raadt
  From: Alexey Suslikov alexey.susli...@gmail.com
  Date: Thu, 11 Dec 2014 20:51:14 + (UTC)
  
  Stefan Fritsch sf at sfritsch.de writes:
  
   --- a/sys/arch/amd64/include/specialreg.h
   +++ b/sys/arch/amd64/include/specialreg.h
at  at  -158,6 +158,7  at  at 
#define  CPUIDECX_AVX0x1000  /* Advanced Vector Extensions 
  */
#define  CPUIDECX_F16C   0x2000  /* 16bit fp conversion  */
#define  CPUIDECX_RDRAND 0x4000  /* RDRAND instruction  */
   +#define  CPUIDECX_HYPERV 0x8000  /* Hypervisor present */
  
  Is this flag standardized? Last time I have tried to push this, there
  was an objection based on reserved for future use status of this flag.
  
  See http://marc.info/?l=openbsd-bugsm=136907278229145w=2
 
 Well, that thread started out with a questionable workaround for a
 hypervisor bug.  That may have have influenced the debate about the
 flag a bit.
 
 You can be almost certain that Intel and AMD will not use that
 reserved bit for anything else.  The Linux KVM virtualization business
 is too important for them.  And if Microsoft Hyper-V or VMWare ESX
 sets that bit as well, this becomes an absolute certainty.
 
 That said:
 
  If it is a standard nowadays, could CPUIDECX_HYPERV be committed as a
  separate chunk?
 
 I prefer the CPUIDECX_HV name used in the diff you posted in:
 
   http://marc.info/?l=openbsd-bugsm=136906997828078w=2
 
 We print these flags, and they're already taking up a significant part
 of dmesg real estate.

Completely agree..



feed l4 information into trunk(4) hash

2014-12-11 Thread Stuart Henderson
I'm wondering what reception this will get. It feeds TCP/UDP port
numbers into the hash for trunk(4) load balancing, so connections
between a single pair of hosts will get distributed across NICs.
Taken from FreeBSD r232629, they also added SIOC[CS]LAGGHASH ioctls
so that the hash type can be configured in ifconfig (l2/l3/l4),
I haven't done that but could if there's no general objection to
this.

This method is used on some switches too (e.g. trunk-load-balance
L4-based on HP 2530 and 5400zl).

Index: if_trunk.c
===
RCS file: /cvs/src/sys/net/if_trunk.c,v
retrieving revision 1.93
diff -u -p -r1.93 if_trunk.c
--- if_trunk.c  4 Dec 2014 00:01:53 -   1.93
+++ if_trunk.c  11 Dec 2014 23:45:20 -
@@ -978,12 +978,23 @@ trunk_hashmbuf(struct mbuf *m, SIPHASH_K
int off;
struct ether_header *eh;
 #ifdef INET
-   struct ip *ip, ipbuf;
+   struct ip *ip;
+   u_int32_t *ports;
+   int iphlen;
 #endif
 #ifdef INET6
u_int32_t flow;
struct ip6_hdr *ip6, ip6buf;
 #endif
+   union {
+#ifdef INET
+   struct ip ip;
+#endif
+#ifdef INET6
+   struct ip6_hdr ip6;
+#endif
+   uint32_t port;
+} buf;
SIPHASH_CTX ctx;
 
SipHash24_Init(ctx, key);
@@ -1013,10 +1024,25 @@ trunk_hashmbuf(struct mbuf *m, SIPHASH_K
 #ifdef INET
case ETHERTYPE_IP:
if ((ip = (struct ip *)
-   trunk_gethdr(m, off, sizeof(*ip), ipbuf)) == NULL)
+   trunk_gethdr(m, off, sizeof(*ip), buf)) == NULL)
return (p);
SipHash24_Update(ctx, ip-ip_src, sizeof(struct in_addr));
SipHash24_Update(ctx, ip-ip_dst, sizeof(struct in_addr));
+
+   /* l4 hash */
+   switch (ip-ip_p) {
+   case IPPROTO_TCP:
+   case IPPROTO_UDP:
+   iphlen = ip-ip_hl  2;
+   if (iphlen  sizeof(*ip))
+   break;
+   off += iphlen;
+   ports = (u_int32_t *) trunk_gethdr(m, off, 
sizeof(*ports), buf);
+   if (ports == NULL)
+   break;
+   SipHash24_Update(ctx, ports, sizeof(*ports));
+   break;
+   }
break;
 #endif
 #ifdef INET6



upd(4) status

2014-12-11 Thread David Higgs
Now that my upd(4) is working (thanks to all involved), I’m looking to improve 
behavior a bit.  Let’s add some state transitions to the sensors.

Feedback is welcome.

--david


## before
[vm@vm usb]$ sysctl hw.sensors.upd0
hw.sensors.upd0.indicator0=Off (Charging), OK
hw.sensors.upd0.indicator1=Off (Discharging), OK
hw.sensors.upd0.indicator2=On (ACPresent), OK
hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
hw.sensors.upd0.indicator4=On (BatteryPresent), OK
hw.sensors.upd0.percent0=100.00% (RemainingCapacity), OK
hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK

## AC power loss
[vm@vm usb]$ sysctl hw.sensors.upd0
hw.sensors.upd0.indicator0=Off (Charging), OK
hw.sensors.upd0.indicator1=On (Discharging), WARNING
hw.sensors.upd0.indicator2=Off (ACPresent), WARNING
hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
hw.sensors.upd0.indicator4=On (BatteryPresent), OK
hw.sensors.upd0.percent0=95.00% (RemainingCapacity), OK
hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK

## AC power restored
[vm@vm usb]$ sysctl hw.sensors.upd0 
hw.sensors.upd0.indicator0=On (Charging), WARNING
hw.sensors.upd0.indicator1=Off (Discharging), OK
hw.sensors.upd0.indicator2=On (ACPresent), OK
hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
hw.sensors.upd0.indicator4=On (BatteryPresent), OK
hw.sensors.upd0.percent0=97.00% (RemainingCapacity), OK
hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK


Index: upd.c
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.12
diff -u -p -r1.12 upd.c
--- upd.c   11 Dec 2014 18:50:32 -  1.12
+++ upd.c   12 Dec 2014 00:32:09 -
@@ -324,6 +324,7 @@ upd_update_sensors(struct upd_softc *sc,
struct upd_sensor   *sensor;
ulong   hdata, batpres;
ulong   adjust;
+   enum sensor_status  status;
int i;
 
sensor = upd_lookup_sensor(sc, HUP_BATTERY, HUB_BATTERY_PRESENT);
@@ -346,6 +347,10 @@ upd_update_sensors(struct upd_softc *sc,
}
}
 
+   adjust = 1;
+   status = SENSOR_S_OK;
+   hdata = hid_get_data(buf, len, sensor-hitem.loc);
+
switch (HID_GET_USAGE(sensor-hitem.usage)) {
case HUB_REL_STATEOF_CHARGE:
case HUB_ABS_STATEOF_CHARGE:
@@ -353,15 +358,28 @@ upd_update_sensors(struct upd_softc *sc,
case HUB_FULLCHARGE_CAPACITY:
adjust = 1000; /* scale adjust */
break;
+   case HUB_CHARGING:
+   case HUB_DISCHARGING:
+   if (hdata)
+   status = SENSOR_S_WARN;
+   break;
+   case HUB_BATTERY_PRESENT:
+   if (!hdata)
+   status = SENSOR_S_CRIT;
+   break;
+   case HUP_SHUTDOWN_IMMINENT:
+   if (hdata)
+   status = SENSOR_S_CRIT;
+   break;
+   case HUB_AC_PRESENT:
+   if (!hdata)
+   status = SENSOR_S_WARN;
default:
-   adjust = 1; /* no scale adjust */
break;
}
 
-   hdata = hid_get_data(buf, len, sensor-hitem.loc);
-
sensor-ksensor.value = hdata * adjust;
-   sensor-ksensor.status = SENSOR_S_OK;
+   sensor-ksensor.status = status;
sensor-ksensor.flags = ~SENSOR_FINVALID;
DPRINTF((%s: hidget data: %lu\n,
sc-sc_sensordev.xname, hdata));




Improve upd(4) battery present check

2014-12-11 Thread David Higgs
First, I think the BatteryPresent check has a signedness problem.  Second, I 
think that it should check for sensor validity too, so it doesn’t use stale 
values if BatteryPresent somehow goes straight from present to invalid.

This diff should fix both things, in theory.  Compiled and running without 
adverse effects.  I did not pull apart my UPS while it’s actively running to 
confirm, though.

--david

Index: upd.c
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.12
diff -u -p -r1.12 upd.c
--- upd.c   11 Dec 2014 18:50:32 -  1.12
+++ upd.c   12 Dec 2014 02:11:09 -
@@ -322,12 +322,14 @@ upd_update_sensors(struct upd_softc *sc,
 int repid)
 {
struct upd_sensor   *sensor;
-   ulong   hdata, batpres;
+   ulong   hdata;
ulong   adjust;
-   int i;
+   int i, batpres = 0;
 
sensor = upd_lookup_sensor(sc, HUP_BATTERY, HUB_BATTERY_PRESENT);
-   batpres = sensor ? sensor-ksensor.value : -1;
+   if (sensor  !(sensor-ksensor.flags  SENSOR_FINVALID) 
+   sensor-ksensor.value)
+   batpres = 1;
 
for (i = 0; i  sc-sc_num_sensors; i++) {
sensor = sc-sc_sensors[i];
@@ -336,7 +338,7 @@ upd_update_sensors(struct upd_softc *sc,
 
/* invalidate battery dependent sensors */
if (HID_GET_USAGE_PAGE(sensor-hitem.usage) == HUP_BATTERY 
-   batpres = 0) {
+   !batpres) {
/* exception to the battery sensor itself */
if (HID_GET_USAGE(sensor-hitem.usage) !=
HUB_BATTERY_PRESENT) {




random and time

2014-12-11 Thread Theo de Raadt
Has anyone given any thought to the impact of 1300+ software
packages using the practice of

srand(time(NULL));

in an increasingly NTP-syncronized world?


From the code I've been reading, I am certain some folk have looked
into it.



Want to help upstream software improve their random?

2014-12-11 Thread Theo de Raadt
In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number generator.

At some later point, deterministic numbers are taken out using rand(),
random(), drand48(), lrand48(), mrand48(), or srand48(), or some
derivative function inside the program itself, and used for WHO KNOWS
WHAT PURPOSE.

I did not audit what the numbers are being used for.

Quite likely some numbers are just used to help hashing.  Some could
be used to print pretty pictures.  But in xulrunner?  In the zip password
creator? In postgresql, or say in openldap (a network related thing)?

It is doubtful they are all fine.

For the benefit of other projects who haven't taken the same steps as
OpenBSD, it would be nice if some people helped out these pieces of
software.

EMBOSS-6.0.1srand((unsigned) time(tm));
ORBit2-2.14.19  srand (t.tv_sec ^ t.tv_usec ^ getpid () ^ getuid ());
apr-util-1.5.3srand((unsigned int)(((time_now  32) ^ time_now)  
0x));
apr-util-1.5.3srand((unsigned int)apr_time_now());
aqualung-0.9beta11  srand(time(0));
aqualung-0.9beta11  srand(time(NULL));
audacious-3.5.2srand (time (NULL));
audacious-plugins-3.5.2srand(time(NULL));
audacity-1.3.9   srand(time(0));
audacity-1.3.9   srand(time(NULL));
audacity-1.3.9srand( (unsigned int) time(NULL) );
birda-1.1srandom(t.tv_sec^t.tv_usec);
boost-1.53.0std::srand( runtime_config::random_seed() );
boost-1.53.0  srand(time(0));
boost-1.53.0generator() { srand(time(0)); }
boost-1.53.0generator() { srand(time(0)); }
boost-1.53.0std::srand(time(0) + world.rank());
boost-1.53.0std::srand(time(0) + world.rank());
boost-1.53.0  srand(time(0) + world.rank());
boost-1.53.0  srand(time(0) + world.rank());
boost-1.53.0  std::srand(time(0) + world.rank());
boost-1.53.0  std::srand(time(0) + world.rank());
boost-1.53.0srand( time(NULL) );
boost-1.53.0srand( time( NULL ) );
boost-1.53.0srand ( time(NULL) );
boost-1.53.0std::srand(static_castunsigned(std::time(0)));
boost-1.53.0std::srand(static_castunsigned(std::time(0)));
boost-1.53.0  srand(time(0));
boost-1.53.0  srand(time(0));
boost-1.53.0std::srand((unsigned int)std::time(NULL));
boost-1.53.0srand(time(0));
bullet-2.81//   srand(time(NULL) / 30);
bullet-2.81 srand((unsigned)time(NULL)); // Seed it...
bullet-2.81 srand ( time ( 0x0 ) );
c3270-3.3.11.6  srand(time(NULL));
c3270-3.3.11.6  srandom(time(NULL));
c3270-3.3.11.6  srand(time(NULL));
c3270-3.3.11.6  srandom(time(NULL));
c3270-3.3.11.6  srand(time(NULL));
c3270-3.3.11.6  srandom(time(NULL));
c3270-3.3.11.6  srand(time(NULL));
c3270-3.3.11.6  srandom(time(NULL));
c3270-3.3.11.6  srand(time(NULL));
c3270-3.3.11.6  srandom(time(NULL));
c3270-3.3.11.6  srand(time(NULL));
c3270-3.3.11.6  srandom(time(NULL));
caps-plugins-0.4.4  srandom (tv.tv_sec ^ tv.tv_usec);
celestia-1.6.1  std::srand(std::time(NULL));
celestia-1.6.1  std::srand(time(NULL));
celestia-1.6.1srandom(time(NULL));
celt-0.11.1   srand(time(NULL));
celt07-0.7.1   srand(time(NULL));
cgdb-0.6.8srand(time(NULL));
clementine-1.2.3  srandom((int)[[NSDate date] timeIntervalSince1970]);
clementine-1.2.3srandom(time(NULL));
clementine-1.2.3srand ( time ( NULL ) );
clementine-1.2.3  qsrand((time.tv_sec * 1000) + (time.tv_usec / 1000));
cmake-3.0.2srand((unsigned)time(0));
cmake-3.0.2  srand((unsigned int)time(NULL)+randomizer++); /* seed */
codeblocks-13.12srand( time(NULL) );
codeblocks-13.12inline void ini_random() { srand(time(0)); };
codeblocks-13.12srand((unsigned)time(0));
codeblocks-13.12srand(time(nullptr));
codeworker-4.5.4if (iSeed = 0) srand((unsigned) iSeed);
codeworker-4.5.4else srand((unsigned) time(NULL));
db-3.1.17   srand((u_int)time(NULL));
db-3.1.17   srand(getpid() | time(NULL));
db-3.1.17   srand((unsigned int)time(NULL));
db-4.6.21   srand((u_int)time(NULL));
db-4.6.21   srand(getpid() | time(NULL));
db-4.6.21   srand((unsigned int)time(NULL));
db-4.6.21   srand((u_int)time(NULL) % (u_int)getpid());
db-4.6.21   srand((u_int)(time(NULL) | getpid()));
db-4.6.21   srand((u_int)(time(NULL) | getpid()));
deadbeef-0.6.2srand (time (NULL));
deadbeef-0.6.2//srand ((uint) ::time(NULL));
deadbeef-0.6.2  srand(time(NULL));
deadbeef-0.6.2  fixed random playback bug caused by libsidplay2 calling 
srand(time(NULL))
festival-1.95beta#define seed_random() srand((unsigned)time(NULL))
festival-1.95beta#define seed_random() srandom(time(NULL));
festival-1.95betasrand(time(NULL));
flac-1.3.0  srand((unsigned)time(0));
flac-1.3.0  srand((unsigned)time(0));
flac-1.3.0  srand((unsigned)time(0));
fldigi-3.21.83//srand(time(NULL));
fritzing-0.9.0  srand ( time(NULL) );
fritzing-0.9.0srand((unsigned)(time(NULL) ^ ZCR_SEED2));
giblib-1.2.4   srand(getpid() 

Re: Want to help upstream software improve their random?

2014-12-11 Thread Devin Ceartas

On 12 Dec 2014, at 5:02, Theo de Raadt wrote:


In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number generator.

At some later point, deterministic numbers are taken out using rand(),
random(), drand48(), lrand48(), mrand48(), or srand48(), or some
derivative function inside the program itself, and used for WHO KNOWS
WHAT PURPOSE.

I did not audit what the numbers are being used for.

Quite likely some numbers are just used to help hashing.  Some could
be used to print pretty pictures.  But in xulrunner?  In the zip 
password

creator? In postgresql, or say in openldap (a network related thing)?

It is doubtful they are all fine.

For the benefit of other projects who haven't taken the same steps as
OpenBSD, it would be nice if some people helped out these pieces of
software.

EMBOSS-6.0.1srand((unsigned) time(tm));

[...]

What you say makes sense. Is there a best practice alternative you 
suggest or did I miss that? Perhaps just some better initiation value, 
preferably not all from the same place?




devin
--
contact info: http://nacredata.com/devin
gpg public key: http://www.nacredata.com/public_key.txt
Use unique, strong passwords! https://www.nacredata.com/password.php



Re: Want to help upstream software improve their random?

2014-12-11 Thread Theo de Raadt
 On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
 
  In all of these code blocks are a well-known piece of information
  (same time on your machine as everywhere else) is being used to seed a
  deterministic number generator.
 
  At some later point, deterministic numbers are taken out using rand(),
  random(), drand48(), lrand48(), mrand48(), or srand48(), or some
  derivative function inside the program itself, and used for WHO KNOWS
  WHAT PURPOSE.
 
  I did not audit what the numbers are being used for.
 
  Quite likely some numbers are just used to help hashing.  Some could
  be used to print pretty pictures.  But in xulrunner?  In the zip 
  password
  creator? In postgresql, or say in openldap (a network related thing)?
 
  It is doubtful they are all fine.
 
  For the benefit of other projects who haven't taken the same steps as
  OpenBSD, it would be nice if some people helped out these pieces of
  software.
 
  EMBOSS-6.0.1srand((unsigned) time(tm));
 [...]
 
 What you say makes sense. Is there a best practice alternative you 
 suggest or did I miss that? Perhaps just some better initiation value, 
 preferably not all from the same place?

These code sequences do not need deterministic values.  They actually
want non-deterministic values.  Steps are like this:

 1. Remove the srand(), srandom(), srand48(), seed48(),
lcong48() calls.

 2. Replace all rand(), random(), lrand48(), mrand48() calls with
arc4random()

 3. If the calls use %, consider using arcrandom_uniform() instead.

 4. If it loops to fill a buffer, use arc4random_buf()

 5. Replace drand48() with arc4random and some floating point, but
be careful.  drand48() is very rare.

Now, talk to the upstream projects.  They will reject your changes
because Linux lacks arc4random().

Basically, only Linux and Solaris lack arc4random().  All the other
platforms have it.

There are libraries available which provide arc4random() on Linux, so
maybe you find an upstream software provider who is willing to create
a dependency on such a library on Linux.

Lots of software is doing precisely that, so don't be afraid.



Re: Want to help upstream software improve their random?

2014-12-11 Thread Devin Ceartas
On 12 Dec 2014, at 5:43, Theo de Raadt wrote:

 On 12 Dec 2014, at 5:02, Theo de Raadt wrote:

 In all of these code blocks are a well-known piece of information
 (same time on your machine as everywhere else) is being used to seed a
 deterministic number generator.

 At some later point, deterministic numbers are taken out using rand(),
 random(), drand48(), lrand48(), mrand48(), or srand48(), or some
 derivative function inside the program itself, and used for WHO KNOWS
 WHAT PURPOSE.

 I did not audit what the numbers are being used for.

 Quite likely some numbers are just used to help hashing.  Some could
 be used to print pretty pictures.  But in xulrunner?  In the zip
 password
 creator? In postgresql, or say in openldap (a network related thing)?

 It is doubtful they are all fine.

 For the benefit of other projects who haven't taken the same steps as
 OpenBSD, it would be nice if some people helped out these pieces of
 software.

 EMBOSS-6.0.1srand((unsigned) time(tm));
 [...]

 What you say makes sense. Is there a best practice alternative you
 suggest or did I miss that? Perhaps just some better initiation value,
 preferably not all from the same place?

 These code sequences do not need deterministic values.  They actually
 want non-deterministic values.  Steps are like this:

1. Remove the srand(), srandom(), srand48(), seed48(),
   lcong48() calls.

2. Replace all rand(), random(), lrand48(), mrand48() calls with
   arc4random()

3. If the calls use %, consider using arcrandom_uniform() instead.

4. If it loops to fill a buffer, use arc4random_buf()

5. Replace drand48() with arc4random and some floating point, but
   be careful.  drand48() is very rare.

 Now, talk to the upstream projects.  They will reject your changes
 because Linux lacks arc4random().

 Basically, only Linux and Solaris lack arc4random().  All the other
 platforms have it.

 There are libraries available which provide arc4random() on Linux, so
 maybe you find an upstream software provider who is willing to create
 a dependency on such a library on Linux.

 Lots of software is doing precisely that, so don't be afraid.

Got it. Thanks. 


devin
--
contact info: http://nacredata.com/devin
gpg public key: http://www.nacredata.com/public_key.txt
Use unique, strong passwords! https://www.nacredata.com/password.php



Re: Want to help upstream software improve their random?

2014-12-11 Thread Eugene Yunak
On 11 December 2014 at 21:43, Theo de Raadt dera...@cvs.openbsd.org wrote:

  On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
 
   In all of these code blocks are a well-known piece of information
   (same time on your machine as everywhere else) is being used to seed a
   deterministic number generator.
  
   At some later point, deterministic numbers are taken out using rand(),
   random(), drand48(), lrand48(), mrand48(), or srand48(), or some
   derivative function inside the program itself, and used for WHO KNOWS
   WHAT PURPOSE.
  
   I did not audit what the numbers are being used for.
  
   Quite likely some numbers are just used to help hashing.  Some could
   be used to print pretty pictures.  But in xulrunner?  In the zip
   password
   creator? In postgresql, or say in openldap (a network related thing)?
  
   It is doubtful they are all fine.
  
   For the benefit of other projects who haven't taken the same steps as
   OpenBSD, it would be nice if some people helped out these pieces of
   software.
  
   EMBOSS-6.0.1srand((unsigned) time(tm));
  [...]
 
  What you say makes sense. Is there a best practice alternative you
  suggest or did I miss that? Perhaps just some better initiation value,
  preferably not all from the same place?

 These code sequences do not need deterministic values.  They actually
 want non-deterministic values.  Steps are like this:

  1. Remove the srand(), srandom(), srand48(), seed48(),
 lcong48() calls.

  2. Replace all rand(), random(), lrand48(), mrand48() calls with
 arc4random()

  3. If the calls use %, consider using arcrandom_uniform() instead.

  4. If it loops to fill a buffer, use arc4random_buf()

  5. Replace drand48() with arc4random and some floating point, but
 be careful.  drand48() is very rare.

 Now, talk to the upstream projects.  They will reject your changes
 because Linux lacks arc4random().

 Basically, only Linux and Solaris lack arc4random().  All the other
 platforms have it.

 There are libraries available which provide arc4random() on Linux, so
 maybe you find an upstream software provider who is willing to create
 a dependency on such a library on Linux.

 Lots of software is doing precisely that, so don't be afraid.


Thank you. Are there any specific good libraries you know of?


-- 
The best the little guy can do is what
the little guy does right


Re: Want to help upstream software improve their random?

2014-12-11 Thread Theo de Raadt
  There are libraries available which provide arc4random() on Linux, so
  maybe you find an upstream software provider who is willing to create
  a dependency on such a library on Linux.
 
  Lots of software is doing precisely that, so don't be afraid.
 
 
 Thank you. Are there any specific good libraries you know of?

libbsd will do.  It is not the best body of code for this, it is
really old.  It will hopefully improve.  In any case for these purposes
it is more than good enough.



Re: Want to help upstream software improve their random?

2014-12-11 Thread Bryan Steele
On Thu, Dec 11, 2014 at 09:52:46PM -0800, Eugene Yunak wrote:
 Thank you. Are there any specific good libraries you know of?
 
 
 -- 
 The best the little guy can do is what
 the little guy does right

LibreSSL :-)

-Bryan.



Re: Want to help upstream software improve their random?

2014-12-11 Thread Theo de Raadt
 On Thu, Dec 11, 2014 at 09:52:46PM -0800, Eugene Yunak wrote:
  Thank you. Are there any specific good libraries you know of?
 
 
 LibreSSL :-)

Indeed, if a system has LibreSSL, you will find the arc4random
family in -lcrypto.