[ping] dump -U by default
Hi,
Here is a patch that eliminate the -U flag for dump and make usage of
DUID in /etc/dumpdates the default. It also correct old style entries so
nothing has to be done for the admin :)
Index: dump.8
===
RCS file: /cvs/src/sbin/dump/dump.8,v
retrieving revision 1.48
diff -u -p -r1.48 dump.8
--- dump.8 17 Jul 2014 19:58:05 - 1.48
+++ dump.8 7 Apr 2015 11:28:33 -
@@ -40,7 +40,7 @@
.Sh SYNOPSIS
.Nm dump
.Bk -words
-.Op Fl 0123456789acnSUuWw
+.Op Fl 0123456789acnSuWw
.Op Fl B Ar records
.Op Fl b Ar blocksize
.Op Fl d Ar density
@@ -229,13 +229,6 @@ The
flag is mutually exclusive from the
.Fl u
flag.
-.It Fl U
-Use the
-.Xr disklabel 8
-UID instead of the device name when updating
-.Pa /etc/dumpdates
-and when searching for the date of the latest
-lower-level dump.
.It Fl u
Update the file
.Pa /etc/dumpdates
@@ -244,7 +237,9 @@ The format of
.Pa /etc/dumpdates
is human readable, consisting of one
free format record per line:
-filesystem name,
+filesystem name (defaults to
+.Xr disklabel 8
+UID when possible),
increment level
and
.Xr ctime 3
Index: dump.h
===
RCS file: /cvs/src/sbin/dump/dump.h,v
retrieving revision 1.22
diff -u -p -r1.22 dump.h
--- dump.h 3 Sep 2014 02:34:34 - 1.22
+++ dump.h 7 Apr 2015 11:28:33 -
@@ -60,7 +60,6 @@ char *duid; /* duid of the disk being d
char lastlevel; /* dump level of previous dump */
char level; /* dump level of this dump */
intuflag; /* update flag */
-intUflag; /* use duids in dumpdates flag */
intdiskfd; /* disk file descriptor */
inttapefd; /* tape file descriptor */
intpipeout;/* true = output to standard output */
Index: itime.c
===
RCS file: /cvs/src/sbin/dump/itime.c,v
retrieving revision 1.19
diff -u -p -r1.19 itime.c
--- itime.c 16 Jan 2015 06:39:57 - 1.19
+++ itime.c 7 Apr 2015 11:28:33 -
@@ -125,7 +125,7 @@ getdumptime(void)
int i;
char *fname;
- fname = Uflag ? duid : disk;
+ fname = duid ? duid : disk;
#ifdef FDEBUG
msg(Looking for name %s in dumpdates = %s for level = %c\n,
fname, dumpdates, level);
@@ -139,7 +139,8 @@ getdumptime(void)
* and older date
*/
ITITERATE(i, ddp) {
- if (strncmp(fname, ddp-dd_name, sizeof(ddp-dd_name)) != 0)
+ if ((strncmp(fname, ddp-dd_name, sizeof(ddp-dd_name)) != 0)
+ (strncmp(disk, ddp-dd_name, sizeof(ddp-dd_name)) != 0))
continue;
if (ddp-dd_level = level)
continue;
@@ -165,7 +166,7 @@ putdumptime(void)
quit(cannot rewrite %s: %s\n, dumpdates, strerror(errno));
fd = fileno(df);
(void) flock(fd, LOCK_EX);
- fname = Uflag ? duid : disk;
+ fname = duid ? duid : disk;
free((char *)ddatev);
ddatev = 0;
nddates = 0;
@@ -176,8 +177,10 @@ putdumptime(void)
quit(fseek: %s\n, strerror(errno));
spcl.c_ddate = 0;
ITITERATE(i, dtwalk) {
- if (strncmp(fname, dtwalk-dd_name,
- sizeof(dtwalk-dd_name)) != 0)
+ if ((strncmp(fname, dtwalk-dd_name,
+sizeof(dtwalk-dd_name)) != 0)
+ (strncmp(disk, dtwalk-dd_name,
+sizeof(dtwalk-dd_name)) != 0))
continue;
if (dtwalk-dd_level != level)
continue;
Index: main.c
===
RCS file: /cvs/src/sbin/dump/main.c,v
retrieving revision 1.54
diff -u -p -r1.54 main.c
--- main.c 20 Jan 2015 18:22:20 - 1.54
+++ main.c 7 Apr 2015 11:28:33 -
@@ -115,7 +115,7 @@ main(int argc, char *argv[])
usage();
obsolete(argc, argv);
- while ((ch = getopt(argc, argv, 0123456789aB:b:cd:f:h:ns:ST:UuWw)) !=
-1)
+ while ((ch = getopt(argc, argv, 0123456789aB:b:cd:f:h:ns:ST:uWw)) !=
-1)
switch (ch) {
/* dump level */
case '0': case '1': case '2': case '3': case '4':
@@ -183,10 +183,6 @@ main(int argc, char *argv[])
lastlevel = '?';
break;
- case 'U':
- Uflag = 1; /* use duids */
- break;
-
case 'u': /* update /etc/dumpdates */
uflag = 1;
break;
@@ -394,11 +390,9 @@ main(int argc, char *argv[])
}
if (ioctl(diskfd, DIOCGDINFO, (char *)lab) 0)
err(1, ioctl (DIOCGDINFO));
- if (!Uflag)
-
Re: autoinstall(8) tweaks
Am 15.04.2015 01:20 schrieb Ryan McBride: On other systems where I don't know how the data will grow, I typically configure them with something close to the auto layout, but a smaller /home, and leave the remaining disk empty. When I get a feel for what the data usage is in /var/daemon or /home or /usr/local, I can expand /home or create a new partition and migrate the data. Wouldnt that be just the point? Keep the auto-layout in big mode as it is but do not assign all remains to /home but only x/% GB and leave the remains of the disk unallocated. + default secure splitted mountpoints untouched + no need to fuzz with the installer + less burden on post install by shrinking/redoing /home to gather space for /var/foobar or whatever + speeds the install-time on large disks ;-) - new heuristics for xGB /home needed 2ct or less.
Re: [NEW] Driver for the Araneus Alea II USB TRNG
Martin Pieuchot m...@openbsd.org writes:
On 14/04/15(Tue) 15:22, attila wrote:
Martin Pieuchot m...@openbsd.org writes:
static const struct usb_devno ualea_devs[] = {
{ USB_VENDOR_ARANEUS, USB_PRODUCT_ARANEUS_ALEA }
};
Is it possible to match your device based on the content of the device
descriptor instead of whitelisting IDs? Whitelisting means that if the
company produce a compatible device with a new ID we'll need to modify
the driver.
Sadly, I don't think it is possible... you mean by looking at
bDeviceClass/bDeviceSubClass/bDeviceProtocol? He only gives me zeroes
[...]
Perhaps I am misunderstanding; is there something else in there I
could/should match on? I've changed the attach routine in the updated
version to check vendor/product/iface, at least.
I was thinking at bInterfaceClass and bInterfaceProtocol but when they
are both to vendor defined (255), matching against the ID is the right
thing to do.
I looked and it appears that M_ZERO is used when allocating the memory
for all of these structures, so I take it that explicit zeroing of
things when tearing down is neither required nor desired? I removed
this kind of thing from ualea.c because it looked like it wasn't
necessary.
That's right.
I'm attaching the updated driver.
Thank you for the critique. I suppose I need to write a man page for
this as well... working on it.
Perfect, I'll put it in tree together with your driver :)
Man page attached. I am also attaching an updated copy of the driver
(only copyright changed).
Thanks so much for your help. I look forward to contributing more.
Pax, -A
--
att...@stalphonsos.com | http://trac.haqistan.net/~attila
keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E AC29 9677 D0A6 E6CC 1EDB
.\ $OpenBSD$
.\
.\ Copyright (c) 2007 Marc Balmer mbal...@openbsd.org
.\ Copyright (c) 2015 attila att...@stalphonsos.com
.\
.\ Permission to use, copy, modify, and distribute this software for any
.\ purpose with or without fee is hereby granted, provided that the above
.\ copyright notice and this permission notice appear in all copies.
.\
.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\
.Dd $Mdocdate$
.Dt UALEA 4
.Os
.Sh NAME
.Nm ualea
.Nd Araneus Alea II USB TRNG
.Sh SYNOPSIS
.Cd ualea* at uhub?
.Sh DESCRIPTION
The
.Nm
driver provides support for the Araneus Alea II, a USB true random
number generator (TRNG).
It delivers 100kbit/sec of hardware-generated entropy.
.Nm
reads raw entropy from the Alea II and uses
.Xr add_true_randomness 9
to add it to the system entropy pool.
.Pp
The product documentation states that the USB interface used by the
Alea II is the same as that used by its predecessor the Alea I;
theoretically this means that the Alea I should work but this has not
been tested.
.Sh SEE ALSO
.Xr intro 4 ,
.Xr usb 4 ,
.Xr add_true_randomness 9 ,
.Sh HISTORY
The
.Nm
driver first appeared in
.Ox 5.7 .
.Sh AUTHORS
The
.Nm
driver was written by
.An attila Aq Mt att...@stalphonsos.com .
/* $OpenBSD$ */
/*
* Copyright (c) 2006 Alexander Yurchenko gra...@openbsd.org
* Copyright (c) 2007 Marc Balmer mbal...@openbsd.org
* Copyright (C) 2015 Sean Levy att...@stalphonsos.com
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/*
* Alea II TRNG. Produces 100kbit/sec of entropy by black magic
*
* Product information in English can be found here:
* http://www.araneus.fi/products/alea2/en/
*/
#include sys/param.h
#include sys/systm.h
#include sys/device.h
#include sys/kernel.h
#include sys/timeout.h
#include dev/usb/usb.h
#include dev/usb/usbdevs.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
#include dev/rndvar.h
#define ALEA_IFACE 0
#define ALEA_MSECS 100
#define ALEA_READ_TIMEOUT 1000
#define ALEA_BUFSIZ ((1024/8)*100) /* 100 kbits */
#define DEVNAME(_sc)
PATCH: clarifying iked.conf man
Hello, iked.conf's man page is a bit fuzzy on how local and peer ip defaults are set. This patch below attempts to fix that. Also, can you take a look at my previous nat-on-ipsec-on-iked patchset ? see http://marc.info/?l=openbsd-techm=142662971007779w=2 Cheers, Index: iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.38 diff -u -p -r1.38 iked.conf.5 --- iked.conf.5 28 Feb 2015 21:51:57 - 1.38 +++ iked.conf.5 15 Apr 2015 15:02:21 - @@ -334,23 +334,21 @@ see the file .It Ic local Ar localip Ic peer Ar remote The .Ic local -parameter specifies the address or FQDN of the local endpoint. -Unless the gateway is multi-homed or uses address aliases, -this option is generally not needed. -.Pp -The +and .Ic peer -parameter specifies the address or FQDN of the remote endpoint. -For host-to-host connections where +parameters specify the address or FQDN of the local and remote +endpoints respectively. +If neither are specified, their default values are equal to +.Ar src +and .Ar dst -is identical to -.Ar remote , -this option is generally not needed as it will be set to -.Ar dst -automatically. -If it is not specified or if the keyword -.Ar any -is given, the default peer is used. +for +.Ar localip +and +.Ar remote +respectively. When only one is specified, the other +defaults to +.Ar any . .It Xo .Ic ikesa .Ic auth Ar algorithm
pkg_* new functionality: arch, version expansion
was requested by sthen@
works with pkg.conf and PKG_PATH, similar sequences as for dpb:
%a - architecture
%c - either snapshots or version number
%v - always version number.
please test/comment
just tried it after rewriting:
installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/%c/packages/%a/
in pkg.conf
Index: OpenBSD/PackingElement.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm,v
retrieving revision 1.239
diff -u -p -r1.239 PackingElement.pm
--- OpenBSD/PackingElement.pm 25 Feb 2015 16:37:15 - 1.239
+++ OpenBSD/PackingElement.pm 15 Apr 2015 15:53:09 -
@@ -1750,6 +1750,15 @@ sub stringize($)
my ($machine_arch, $arch);
+sub arch
+{
+ if (!defined $arch) {
+ my $cmd = OpenBSD::Paths-uname. -m;
+ chomp($arch = `$cmd`);
+ }
+ return $arch;
+}
+
sub check
{
my ($self, $forced_arch) = @_;
@@ -1768,11 +1777,7 @@ sub check
chomp($machine_arch = `$cmd`);
}
return 1 if $ok eq $machine_arch;
- if (!defined $arch) {
- my $cmd = OpenBSD::Paths-uname. -m;
- chomp($arch = `$cmd`);
- }
- return 1 if $ok eq $arch;
+ return 1 if $ok eq arch();
}
return;
}
Index: OpenBSD/PackageRepository/Installed.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/Installed.pm,v
retrieving revision 1.29
diff -u -p -r1.29 Installed.pm
--- OpenBSD/PackageRepository/Installed.pm 15 Jun 2014 23:49:51 -
1.29
+++ OpenBSD/PackageRepository/Installed.pm 15 Apr 2015 15:53:09 -
@@ -26,6 +26,40 @@ use warnings;
package OpenBSD::PackageRepositoryBase;
+my ($version, $current);
+
+sub expand_locations
+{
+ my ($class, $string, $state) = @_;
+ if ($string eq '%a') {
+ require OpenBSD::PackingElement;
+ return OpenBSD::PackingElement::Arch::arch();
+ } else {
+ if (!defined $version) {
+ require OpenBSD::Paths;
+ open my $cmd, '-|',
+ OpenBSD::Paths-sysctl, '-n', 'kern.version';
+ my $line = $cmd;
+ close($cmd);
+ if ($line =~ m/^OpenBSD (\d\.\d)(\S*)\s/) {
+ $version = $1;
+ if ($2 eq '-current') {
+ $current = 'snapshots';
+ } else {
+ $current = $version;
+ }
+ } else {
+ $state-fatal(Can't figure out version);
+ }
+ }
+ if ($string eq '%c') {
+ return $current;
+ } else {
+ return $version;
+ }
+ }
+}
+
sub parse_url
{
my ($class, $r, $state) = @_;
@@ -40,6 +74,7 @@ sub parse_url
$$r = '';
}
+ $path =~ s/\%[vac]/$class-expand_locations($, $state)/ge;
$path .= '/' unless $path =~ m/\/$/;
bless { path = $path, state = $state }, $class;
}
Re: [ping] dump -U by default
On Wed, Apr 15, 2015 at 5:48 AM, Manuel Giraud man...@ledu-giraud.fr wrote: Here is a patch that eliminate the -U flag for dump and make usage of DUID in /etc/dumpdates the default. It also correct old style entries so nothing has to be done for the admin :) Yeah, I've started using this and it looks good so far. Just a couple corner cases to verify tonight and presuming it looks good I'll commit tonight. Once everything supports duids, the installer can be switched to use DUID by default, without asking the question about non-DUID use. That would be mainly in support of older machines -- we want their return keys to last longer.
Re: [ping] dump -U by default
On Wed, Apr 15, 2015 at 5:48 AM, Manuel Giraud man...@ledu-giraud.fr wrote: Here is a patch that eliminate the -U flag for dump and make usage of DUID in /etc/dumpdates the default. It also correct old style entries so nothing has to be done for the admin :) Yeah, I've started using this and it looks good so far. Just a couple corner cases to verify tonight and presuming it looks good I'll commit tonight. Philip Guenther
Re: File protection, second attempt
On 15 April 2015 at 13:29, kanonenvogel@gmail.com
kanonenvogel@gmail.com wrote:
On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote:
Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
Underlying uvm calls are not mp safe
True.
and not protected by KERNEL_LOCK() calls.
They are, see pool_allocator_alloc.
Re: pkg_* new functionality: arch, version expansion
On 04/15/15 17:56, Marc Espie wrote:
was requested by sthen@
works with pkg.conf and PKG_PATH, similar sequences as for dpb:
%a - architecture
%c - either snapshots or version number
%v - always version number.
please test/comment
just tried it after rewriting:
installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/%c/packages/%a/
in pkg.conf
Index: OpenBSD/PackingElement.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm,v
retrieving revision 1.239
diff -u -p -r1.239 PackingElement.pm
--- OpenBSD/PackingElement.pm 25 Feb 2015 16:37:15 - 1.239
+++ OpenBSD/PackingElement.pm 15 Apr 2015 15:53:09 -
@@ -1750,6 +1750,15 @@ sub stringize($)
my ($machine_arch, $arch);
+sub arch
+{
+ if (!defined $arch) {
+ my $cmd = OpenBSD::Paths-uname. -m;
+ chomp($arch = `$cmd`);
+ }
+ return $arch;
+}
+
sub check
{
my ($self, $forced_arch) = @_;
@@ -1768,11 +1777,7 @@ sub check
chomp($machine_arch = `$cmd`);
}
return 1 if $ok eq $machine_arch;
- if (!defined $arch) {
- my $cmd = OpenBSD::Paths-uname. -m;
- chomp($arch = `$cmd`);
- }
- return 1 if $ok eq $arch;
+ return 1 if $ok eq arch();
}
return;
}
Index: OpenBSD/PackageRepository/Installed.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/Installed.pm,v
retrieving revision 1.29
diff -u -p -r1.29 Installed.pm
--- OpenBSD/PackageRepository/Installed.pm 15 Jun 2014 23:49:51 -
1.29
+++ OpenBSD/PackageRepository/Installed.pm 15 Apr 2015 15:53:09 -
@@ -26,6 +26,40 @@ use warnings;
package OpenBSD::PackageRepositoryBase;
+my ($version, $current);
+
+sub expand_locations
+{
+ my ($class, $string, $state) = @_;
+ if ($string eq '%a') {
+ require OpenBSD::PackingElement;
+ return OpenBSD::PackingElement::Arch::arch();
+ } else {
+ if (!defined $version) {
+ require OpenBSD::Paths;
+ open my $cmd, '-|',
+ OpenBSD::Paths-sysctl, '-n', 'kern.version';
+ my $line = $cmd;
+ close($cmd);
+ if ($line =~ m/^OpenBSD (\d\.\d)(\S*)\s/) {
+ $version = $1;
+ if ($2 eq '-current') {
+ $current = 'snapshots';
I've seen at least -beta versions short before release locks. Not
sure if there are -alpha too? Those should be treated
same way as snapshots, I think.
+ } else {
+ $current = $version;
+ }
+ } else {
+ $state-fatal(Can't figure out version);
+ }
+ }
+ if ($string eq '%c') {
+ return $current;
+ } else {
+ return $version;
+ }
+ }
+}
+
sub parse_url
{
my ($class, $r, $state) = @_;
@@ -40,6 +74,7 @@ sub parse_url
$$r = '';
}
+ $path =~ s/\%[vac]/$class-expand_locations($, $state)/ge;
$path .= '/' unless $path =~ m/\/$/;
bless { path = $path, state = $state }, $class;
}
Re: Multiple cmsghdrs in msghdr
On 4/15/15 5:37 AM, Otto Moerbeek wrote: On Wed, Apr 15, 2015 at 11:32:11AM +0200, Mark Kettenis wrote: Date: Tue, 14 Apr 2015 21:26:25 -0400 From: William Orr w...@worrbase.com Hey, I was debugging a few CPython test failures yesterday, and I noticed that attaching multiple cmsg structures causes unp_internalize to return EINVAL. I've looked in unix(4) and sendmsg(2), and this caveat isn't documented anywhere. I looked at other OSes, and Linux supports this, FreeBSD fails in interesting ways and OS X returns E2BIG. Is this behavior intentional, and the documentation is missing this failure mode? Or is the behavior unintentional? I'm happy to submit a patch for either, I just want to know which behavior is intended. The behaviour is intentional. The additional complexity of supporting multiple cmsghdrs has caused many bugs (and associated security issues) in the past. The alignment fuckups in various OSes make it hard to use this functionality in a portable way anyway. And we only support SCM_RIGHTS, so there is no real reason to use multiple cmsghdrs in your code. Plus it *is* possible to send multiple fd's in one message. -Otto Yeah, I was wondering why this was allowed on some OSes in the first place, since it seems redundant. Once I'm not in an airport, I'll submit a docs patch just so that it's clear. re: CPython's test suite, I have a patch in the queue that only enables this behavior on Linux. Thanks, William Orr signature.asc Description: OpenPGP digital signature
Re: Multiple cmsghdrs in msghdr
On Wed, Apr 15, 2015 at 11:21 AM, William Orr w...@worrbase.com wrote: On 4/15/15 5:37 AM, Otto Moerbeek wrote: On Wed, Apr 15, 2015 at 11:32:11AM +0200, Mark Kettenis wrote: Date: Tue, 14 Apr 2015 21:26:25 -0400 From: William Orr w...@worrbase.com ... Is this behavior intentional, and the documentation is missing this failure mode? Or is the behavior unintentional? I'm happy to submit a patch for either, I just want to know which behavior is intended. The behaviour is intentional. The additional complexity of supporting multiple cmsghdrs has caused many bugs (and associated security issues) in the past. The alignment fuckups in various OSes make it hard to use this functionality in a portable way anyway. And we only support SCM_RIGHTS, so there is no real reason to use multiple cmsghdrs in your code. Plus it *is* possible to send multiple fd's in one message. Yeah, I was wondering why this was allowed on some OSes in the first place, since it seems redundant. Once I'm not in an airport, I'll submit a docs patch just so that it's clear. re: CPython's test suite, I have a patch in the queue that only enables this behavior on Linux. If CPython exposes the raw C APIs, then it would be good to patch their docs too, to indicate that multiple fds should be passed in one cmsg and not as separate cmsgs... Philip Guenther
inteldrm/radeondrm running -current
Hi folks, Earlier today, I committed a diff that includes a check that the drm ioctls return a proper error code. If you see something like: drmioctl: cmd 0xXX errno -YY in your dmesg or on your console, please let me know. Thanks, Mark
Re: pkg_* new functionality: arch, version expansion
On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ?
Re: File protection, second attempt
On 15 Apr 2015, at 19:45, Mike Belopuhov m...@belopuhov.com wrote:
On 15 April 2015 at 13:29, kanonenvogel@gmail.com
kanonenvogel@gmail.com wrote:
On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote:
Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
Underlying uvm calls are not mp safe
True.
and not protected by KERNEL_LOCK() calls.
They are, see pool_allocator_alloc.
Ok I see.
But pool_get() calls msleep() which is quite similar to tlseep() but lacks the
'kernel_lock is locked' assert. Except ktrace related calls those functions
look mp safe, and my system didn't crash without this assertion.
Assertion KASSERT(timo || __mp_lock_held(kernel_lock)) looks
here. Also system has didn't crash with unlocked tsleep()
and wakeup() calls.
getnanotime() and friends functions are mp safe too.
0001-Wrong-assertion-from-tsleep-removed.patch
Description: Binary data
0002-Pipe-locks.patch
Description: Binary data
Re: inteldrm/radeondrm running -current
On Wed, Apr 15, 2015, at 11:56 PM, Mark Kettenis wrote: Hi folks, Earlier today, I committed a diff that includes a check that the drm ioctls return a proper error code. If you see something like: drmioctl: cmd 0xXX errno -YY in your dmesg or on your console, please let me know. Thanks, Mark Hi Mark, The only intel drm messages I receive on my current snapshot (Apr 14) are (1 - see below). I see an Apr 15 snapshot on NYC*BUG though I doubt there's a way to test if your patch is included there and probably better to wait a couple of days before updating? I'm running: inteldrm0 at vga1 drm0 at inteldrm0 error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10 error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns inteldrm0: 1366x768 the shop claims the intel card is: 'Intel HD Graphics 4400' ATI Radeon HD 8500M rev 0x00 at pci3 dev 0 function 0 not configured 1) error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 Regards, Adam
On github now
Well, I’ve put /usr/src/sys subtree from 5.7 with my patches on guthub. I would really like to get it more traction on that. https://github.com/Kanonenvogel/openbsd-sys-5.7-smp
Re: Multiple cmsghdrs in msghdr
Always fun, cmsg structures. Anyway, I'll try to find some info on
this (maybe Stevens has something to say here).
But your experiments indicate that various Unixes do not agree, so
it's probably better to avoid sending multiple cmsg structures. Or
there is a subtle error in the way you build your messages...
-Otto
On Tue, Apr 14, 2015 at 09:26:25PM -0400, William Orr wrote:
Hey,
I was debugging a few CPython test failures yesterday, and I noticed
that attaching multiple cmsg structures causes unp_internalize to return
EINVAL.
I've looked in unix(4) and sendmsg(2), and this caveat isn't documented
anywhere.
I looked at other OSes, and Linux supports this, FreeBSD fails in
interesting ways and OS X returns E2BIG.
Is this behavior intentional, and the documentation is missing this
failure mode? Or is the behavior unintentional? I'm happy to submit a
patch for either, I just want to know which behavior is intended.
For reference, the code that returns EINVAL follows:
int
unp_internalize(struct mbuf *control, struct proc *p)
{
struct filedesc *fdp = p-p_fd;
struct cmsghdr *cm = mtod(control, struct cmsghdr *);
struct file **rp, *fp;
int i, error;
int nfds, *ip, fd, neededspace;
/*
* Check for two potential msg_controllen values because
* IETF stuck their nose in a place it does not belong.
*/
if (cm-cmsg_type != SCM_RIGHTS || cm-cmsg_level != SOL_SOCKET ||
!(cm-cmsg_len == control-m_len ||
control-m_len == CMSG_ALIGN(cm-cmsg_len)))
return (EINVAL);
...
My super-awful test, also follows:
#include sys/socket.h
#include sys/types.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include err.h
#include string.h
void
child(int sock)
{
struct msghdr msg;
memset(msg, 0, sizeof(msg));
recvmsg(sock, msg, 0);
printf(controllen: %zu\n, msg.msg_controllen);
printf(control: %p\n, msg.msg_control);
}
void
parent(int sock)
{
int fds[] = { -1, -1 };
struct msghdr msg;
struct cmsghdr *cmsg;
union {
struct cmsghdr hdr;
unsigned charbuf[2 * CMSG_SPACE(sizeof(int))];
} cmsgbuf;
char sfn[30];
memset(msg, 0, sizeof(msg));
for (int i = 0; i sizeof(fds); i++) {
(void)strlcpy(sfn, /tmp/worrtest.XX, sizeof(sfn));
if ((fds[i] = mkstemp(sfn)) == -1) {
err(1, mkstemp);
}
}
msg.msg_control = cmsgbuf.buf;
msg.msg_controllen = sizeof(cmsgbuf.buf);
cmsg = CMSG_FIRSTHDR(msg);
cmsg-cmsg_len = CMSG_LEN(sizeof(int));
cmsg-cmsg_level = SOL_SOCKET;
cmsg-cmsg_type = SCM_RIGHTS;
*(int *)CMSG_DATA(cmsg) = fds[0];
cmsg = CMSG_NXTHDR(msg, cmsg);
cmsg-cmsg_len = CMSG_LEN(sizeof(int));
cmsg-cmsg_level = SOL_SOCKET;
cmsg-cmsg_type = SCM_RIGHTS;
*(int *)CMSG_DATA(cmsg) = fds[1];
if (sendmsg(sock, msg, 10240) == -1)
err(1, sendmsg);
}
int
main(void)
{
int sock[] = {-1, -1};
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sock) == -1)
err(1, socket);
switch (fork()) {
case 0:
child(sock[0]);
exit(0);
case -1:
err(1, fork);
default:
parent(sock[1]);
exit(0);
}
}
Thanks,
William Orr
Re: Multiple cmsghdrs in msghdr
Date: Tue, 14 Apr 2015 21:26:25 -0400 From: William Orr w...@worrbase.com Hey, I was debugging a few CPython test failures yesterday, and I noticed that attaching multiple cmsg structures causes unp_internalize to return EINVAL. I've looked in unix(4) and sendmsg(2), and this caveat isn't documented anywhere. I looked at other OSes, and Linux supports this, FreeBSD fails in interesting ways and OS X returns E2BIG. Is this behavior intentional, and the documentation is missing this failure mode? Or is the behavior unintentional? I'm happy to submit a patch for either, I just want to know which behavior is intended. The behaviour is intentional. The additional complexity of supporting multiple cmsghdrs has caused many bugs (and associated security issues) in the past. The alignment fuckups in various OSes make it hard to use this functionality in a portable way anyway. And we only support SCM_RIGHTS, so there is no real reason to use multiple cmsghdrs in your code.
Re: Multiple cmsghdrs in msghdr
On Wed, Apr 15, 2015 at 11:32:11AM +0200, Mark Kettenis wrote: Date: Tue, 14 Apr 2015 21:26:25 -0400 From: William Orr w...@worrbase.com Hey, I was debugging a few CPython test failures yesterday, and I noticed that attaching multiple cmsg structures causes unp_internalize to return EINVAL. I've looked in unix(4) and sendmsg(2), and this caveat isn't documented anywhere. I looked at other OSes, and Linux supports this, FreeBSD fails in interesting ways and OS X returns E2BIG. Is this behavior intentional, and the documentation is missing this failure mode? Or is the behavior unintentional? I'm happy to submit a patch for either, I just want to know which behavior is intended. The behaviour is intentional. The additional complexity of supporting multiple cmsghdrs has caused many bugs (and associated security issues) in the past. The alignment fuckups in various OSes make it hard to use this functionality in a portable way anyway. And we only support SCM_RIGHTS, so there is no real reason to use multiple cmsghdrs in your code. Plus it *is* possible to send multiple fd's in one message. -Otto
Re: autoinstall(8) tweaks
On Wed, Apr 15, 2015 at 08:20:15AM +0900, Ryan McBride wrote: On Thu, Apr 09, 2015 at 04:27:17AM -0600, Theo de Raadt wrote: But it seems people are expected to build a custom bsd.rd if they want something different so I'll bow out of this conversation. No, the situation is that less than 1% of the user community apparently have a secret usage case, but never manage to explain it. I manage a bunch of OpenBSD proxies that I would like to be able to build from scratch using automated tools; everything is in place (ansible) except for the base OpenBSD install as I need a separate /var/squid partition to prevent cache / log disasters from filling /var; similar concerns would apply to many other data / log-heavy daemons. On other systems where I don't know how the data will grow, I typically configure them with something close to the auto layout, but a smaller /home, and leave the remaining disk empty. When I get a feel for what the data usage is in /var/daemon or /home or /usr/local, I can expand /home or create a new partition and migrate the data. The default allocation is actually easy to rework right after a fresh install, as /usr/src, /usr/obj and /home are at the end. Ssh as root, kill /usr/src, /usr/obj and /home, optionally extend /usr/local, and then repartition as you wish. As for swap and /tmp, you can move /tmp to the end, at worst you will lose 4G worth of disk space you can add to swap. And if you need more than 2x RAM swap, you have bigger problems than partitioning. Other reasons to want non-auto partitioning like include: - simpler dump/restore Yeah, embrace failure is what all the cool kids do these days. Except that this kind of non-management just sweeps problems under the rug so they can mature into propers monsters ready to gnaw at your skull at the worst possible moment. - moving certain parts of hier(7) onto a different device (you can do this as a post-install task if they are empty, but it becomes a pain if it's something that's part of base) A place where the latter can be quite useful is on a virtualised guest, where you can easily make one storage device persistant, and another ephemeral across reboots. Which part of baseXX, compXX, manXX, gameXX, xbaseXX, xfontXX, xservXX or xshareXX would fall under such a case ? None. Yes, all of this can be done manually, but basically any place I would care to work at is moving towards complete automation of system installs (for *hack*Cloud*spit*, Continuous Delivery, DR, or just plain old laziness). It would be really nice if the OpenBSD installer would handle this in a sane fashion. Do you want me to write an ansible playbook to run a handful of shell commands over ssh ? Cheers, -- Vincent Gross
Re: [NEW] Driver for the Araneus Alea II USB TRNG
On 14/04/15(Tue) 15:22, attila wrote:
Martin Pieuchot m...@openbsd.org writes:
static const struct usb_devno ualea_devs[] = {
{ USB_VENDOR_ARANEUS, USB_PRODUCT_ARANEUS_ALEA }
};
Is it possible to match your device based on the content of the device
descriptor instead of whitelisting IDs? Whitelisting means that if the
company produce a compatible device with a new ID we'll need to modify
the driver.
Sadly, I don't think it is possible... you mean by looking at
bDeviceClass/bDeviceSubClass/bDeviceProtocol? He only gives me zeroes
[...]
Perhaps I am misunderstanding; is there something else in there I
could/should match on? I've changed the attach routine in the updated
version to check vendor/product/iface, at least.
I was thinking at bInterfaceClass and bInterfaceProtocol but when they
are both to vendor defined (255), matching against the ID is the right
thing to do.
I looked and it appears that M_ZERO is used when allocating the memory
for all of these structures, so I take it that explicit zeroing of
things when tearing down is neither required nor desired? I removed
this kind of thing from ualea.c because it looked like it wasn't
necessary.
That's right.
I'm attaching the updated driver.
Thank you for the critique. I suppose I need to write a man page for
this as well... working on it.
Perfect, I'll put it in tree together with your driver :)
Pax, -A
--
att...@stalphonsos.com | http://trac.haqistan.net/~attila
keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E AC29 9677 D0A6 E6CC 1EDB
/*$OpenBSD$ */
/*
* Copyright (c) 2006 Alexander Yurchenko gra...@openbsd.org
* Copyright (c) 2007 Marc Balmer mbal...@openbsd.org
* Copyright (C) 2015 attila att...@stalphonsos.com
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/*
* Alea II TRNG. Produces 100kbit/sec of entropy by black magic
*
* Product information in English can be found here:
* http://www.araneus.fi/products/alea2/en/
*/
#include sys/param.h
#include sys/systm.h
#include sys/device.h
#include sys/kernel.h
#include sys/timeout.h
#include dev/usb/usb.h
#include dev/usb/usbdevs.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
#include dev/rndvar.h
#define ALEA_IFACE0
#define ALEA_MSECS100
#define ALEA_READ_TIMEOUT 1000
#define ALEA_BUFSIZ ((1024/8)*100) /* 100 kbits */
#define DEVNAME(_sc) ((_sc)-sc_dev.dv_xname)
struct ualea_softc {
struct device sc_dev;
struct usbd_device *sc_udev;
struct usbd_pipe *sc_pipe;
struct timeout sc_timeout;
struct usb_task sc_task;
struct usbd_xfer *sc_xfer;
int *sc_buf;
};
int ualea_match(struct device *, void *, void *);
void ualea_attach(struct device *, struct device *, void *);
int ualea_detach(struct device *, int);
void ualea_task(void *);
void ualea_timeout(void *);
struct cfdriver ualea_cd = {
NULL, ualea, DV_DULL
};
const struct cfattach ualea_ca = {
sizeof(struct ualea_softc),
ualea_match,
ualea_attach,
ualea_detach
};
int
ualea_match(struct device *parent, void *match, void *aux)
{
struct usb_attach_arg *uaa = aux;
if (uaa-iface == NULL)
return (UMATCH_NONE);
if ((uaa-vendor == USB_VENDOR_ARANEUS)
(uaa-product == USB_PRODUCT_ARANEUS_ALEA)
(uaa-ifaceno == ALEA_IFACE))
return (UMATCH_VENDOR_PRODUCT);
return (UMATCH_NONE);
}
void
ualea_attach(struct device *parent, struct device *self, void *aux)
{
struct ualea_softc *sc = (struct ualea_softc *)self;
struct usb_attach_arg *uaa = aux;
usb_interface_descriptor_t *id;
usb_endpoint_descriptor_t *ed;
int ep_ibulk = -1;
usbd_status error;
int i;
sc-sc_udev = uaa-device;
id = usbd_get_interface_descriptor(uaa-iface);
for (i = 0; i id-bNumEndpoints; i++) {
ed = usbd_interface2endpoint_descriptor(uaa-iface, i);
if (ed == NULL) {
printf(%s: failed to get endpoint %d descriptor\n,
DEVNAME(sc), i);
return;
}
if
Re: File protection, second attempt
On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote:
Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
Underlying uvm calls are not mp safe and not protected by KERNEL_LOCK() calls.
