installer - tar: Operation not permitted
While trying to make a fresh install with the from the Oct 12th miniroot58.fs, while installing the sets I get a bunch of: tar: Unable to set file uid/gid of ./blah/blah: Operation not permitted tar: Unable to set file uid/gid of ./...: Operation not permitted tar: Unable to set file uid/gid of ./etc/nsd/nsd.conf: Operation not permitted Installation of base58.tgz failed. Continue anyway? [no] I confirmed it worked fine with the Oct 11th miniroot. Looks like there were 3 commits to bin/pax in that timeframe, not sure which ones the snapshot was built with, but at some point it broke.
Re: Remove links to www@
On Thu, Jun 25, 2015 at 07:01:29AM +, Pavel Plamenov wrote: There are some leftover links to www@, which is gone. I sent an almost identical diff over a year ago: https://www.marc.info/?l=openbsd-miscm=139627200904849w=2 I think this is the right direction.
wc(1) SIGINFO - show count so far
SIGINFO is awesome, but it's even better when it actually does
something relevant.
This makes it print the total counts so far to stderr.
Useful? Feature creep? You decide.
Index: wc.c
===
RCS file: /cvs/src/usr.bin/wc/wc.c,v
retrieving revision 1.17
diff -u -p -d -r1.17 wc.c
--- wc.c16 Jan 2015 06:40:14 - 1.17
+++ wc.c25 Jun 2015 14:49:21 -
@@ -32,6 +32,9 @@
#include sys/param.h /* MAXBSIZE */
#include sys/stat.h
#include sys/file.h
+
+#include errno.h
+#include signal.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -41,18 +44,23 @@
#include unistd.h
#include util.h
+int64_tlinect, wordct, charct;
int64_ttlinect, twordct, tcharct;
intdoline, doword, dochar, humanchar;
intrval;
extern char *__progname;
+volatile sig_atomic_t wants_info = 0;
-void print_counts(int64_t, int64_t, int64_t, char *);
-void format_and_print(long long);
+void handler(int);
+ssize_treread(int, void *, size_t);
+void print_counts(FILE *, int64_t, int64_t, int64_t, char *);
+void format_and_print(FILE *, long long);
void cnt(char *);
int
main(int argc, char *argv[])
{
+ struct sigaction act;
int ch;
setlocale(LC_ALL, );
@@ -90,6 +98,13 @@ main(int argc, char *argv[])
if (!doline !doword !dochar)
doline = doword = dochar = 1;
+ memset(act, 0, sizeof(act));
+ act.sa_handler = handler;
+ sigemptyset(act.sa_mask);
+ /* SA_RESTART specifically not set */
+ if (sigaction(SIGINFO, act, NULL) == -1)
+ err(1, sigaction);
+
if (!*argv) {
cnt((char *)NULL);
} else {
@@ -100,19 +115,43 @@ main(int argc, char *argv[])
} while(*++argv);
if (dototal)
- print_counts(tlinect, twordct, tcharct, total);
+ print_counts(stdout, tlinect, twordct, tcharct,
+ total);
}
exit(rval);
}
void
+handler(int sig __unused)
+{
+ wants_info = 1;
+}
+
+ssize_t
+reread(int d, void *buf, size_t nbytes)
+{
+ ssize_t len;
+
+restart:
+ len = read(d, buf, nbytes);
+ if (wants_info) {
+ print_counts(stderr, linect + tlinect, wordct + twordct,
+ charct + tcharct, total so far);
+ wants_info = 0;
+ }
+ if (len == -1 errno == EINTR)
+ goto restart;
+
+ return len;
+}
+
+void
cnt(char *file)
{
u_char *C;
short gotsp;
int len;
- int64_t linect, wordct, charct;
struct stat sbuf;
int fd;
u_char buf[MAXBSIZE];
@@ -135,7 +174,7 @@ cnt(char *file)
* the word count requires some logic.
*/
if (doline) {
- while ((len = read(fd, buf, MAXBSIZE)) 0) {
+ while ((len = reread(fd, buf, MAXBSIZE)) 0) {
charct += len;
for (C = buf; len--; ++C)
if (*C == '\n')
@@ -165,7 +204,7 @@ cnt(char *file)
|| ifmt == S_IFDIR) {
charct = sbuf.st_size;
} else {
- while ((len = read(fd, buf, MAXBSIZE))
0)
+ while ((len = reread(fd, buf,
MAXBSIZE)) 0)
charct += len;
if (len == -1) {
warn(%s, file);
@@ -177,7 +216,7 @@ cnt(char *file)
} else {
/* Do it the hard way... */
gotsp = 1;
- while ((len = read(fd, buf, MAXBSIZE)) 0) {
+ while ((len = reread(fd, buf, MAXBSIZE)) 0) {
/*
* This loses in the presence of multi-byte characters.
* To do it right would require a function to return a
@@ -211,7 +250,7 @@ cnt(char *file)
}
}
- print_counts(linect, wordct, charct, file);
+ print_counts(stdout, linect, wordct, charct, file);
/*
* Don't bother checking doline, doword, or dochar -- speeds
@@ -228,30 +267,30 @@ cnt(char *file)
}
void
-format_and_print(long long v)
+format_and_print(FILE *f, long long v)
{
if (humanchar) {
char result[FMT_SCALED_STRSIZE];
(void)fmt_scaled(v, result);
- (void)printf(%7s, result);
+ (void)fprintf(f, %7s, result);
} else {
- (void)printf( %7lld, v);
+ (void)fprintf(f, %7lld, v);
}
}
void
-print_counts(int64_t lines, int64_t words, int64_t chars, char *name)
+print_counts(FILE *f,
Re: explicit_bzero in pkcs5_pbkdf2
I now realize this may have been ignored simply because the clock on the sending machine was horribly off and many people sort mail by date. So... Should this go in? Am I missing something? On Thu, Apr 30, 2015 at 06:03:23PM -0400, Jean-Philippe Ouellet wrote: The intermediate values calculated in hmac_sha1 as part of pkcs5_pbkdf2 are not zeroed afterwards, so we leak a single-hashed version of the key on the stack in tk[]. Also, the correct RFC defining this is RFC 2104 - HMAC: Keyed-Hashing for Message Authentication not RFC 2202 - Test Cases for HMAC-MD5 and HMAC-SHA-1 From RFC 2104, section 4, paragraph 2: We stress that the stored intermediate values need to be treated and protected the same as secret keys. So it's not just best-practice dictating that these should be bzeroed. Here is a patch for the same code in libutil and libsa. Index: lib/libutil/pkcs5_pbkdf2.c === RCS file: /cvs/src/lib/libutil/pkcs5_pbkdf2.c,v retrieving revision 1.9 diff -u -p -d -r1.9 pkcs5_pbkdf2.c --- lib/libutil/pkcs5_pbkdf2.c5 Feb 2015 12:59:57 - 1.9 +++ lib/libutil/pkcs5_pbkdf2.c10 Jun 2015 19:59:09 - @@ -28,7 +28,7 @@ #define MINIMUM(a,b) (((a) (b)) ? (a) : (b)) /* - * HMAC-SHA-1 (from RFC 2202). + * HMAC-SHA-1 (from RFC 2104). */ static void hmac_sha1(const u_int8_t *text, size_t text_len, const u_int8_t *key, @@ -67,6 +67,10 @@ hmac_sha1(const u_int8_t *text, size_t t SHA1Update(ctx, k_pad, SHA1_BLOCK_LENGTH); SHA1Update(ctx, digest, SHA1_DIGEST_LENGTH); SHA1Final(digest, ctx); + + explicit_bzero(ctx, sizeof(ctx)); + explicit_bzero(k_pad, sizeof(k_pad)); + explicit_bzero(tk, sizeof(tk)); } /* Index: sys/lib/libsa/hmac_sha1.c === RCS file: /cvs/src/sys/lib/libsa/hmac_sha1.c,v retrieving revision 1.1 diff -u -p -d -r1.1 hmac_sha1.c --- sys/lib/libsa/hmac_sha1.c 9 Oct 2012 12:36:50 - 1.1 +++ sys/lib/libsa/hmac_sha1.c 10 Jun 2015 19:58:39 - @@ -23,7 +23,7 @@ #include hmac_sha1.h /* - * HMAC-SHA-1 (from RFC 2202). + * HMAC-SHA-1 (from RFC 2104). */ void hmac_sha1(const u_int8_t *text, size_t text_len, const u_int8_t *key, @@ -62,4 +62,8 @@ hmac_sha1(const u_int8_t *text, size_t t SHA1Update(ctx, k_pad, SHA1_BLOCK_LENGTH); SHA1Update(ctx, digest, SHA1_DIGEST_LENGTH); SHA1Final(digest, ctx); + + explicit_bzero(ctx, sizeof(ctx)); + explicit_bzero(k_pad, sizeof(k_pad)); + explicit_bzero(tk, sizeof(tk)); }
Re: httpd rewrites with Lua's pattern matching
On Sat, Jun 20, 2015 at 03:01:18PM +0200, Reyk Floeter wrote: there is some great interest in getting support for rewrites What do people think of something like our tftpd(8)'s -r -r socket Issue filename rewrite requests to the specified UNIX domain socket. tftpd will write lines in the format IP OP filename, terminated by a newline, where IP is the client's IP address, and OP is one of read or write. tftpd expects replies in the format filename terminated by a newline. All rewrite requests from the daemon must be answered (even if it is with the original filename) before the TFTP request will continue. By default tftpd does not use filename rewriting. I was working on a patch to bring it to httpd but ran out of free time. Thought I'd pass the idea by you anyway. I think it's a sweet spot of a minimum incrase in complexity and maximum incrase in flexibility. Then people could plug in whatever they wanted: be it trivial string substitutions, guaranteed safe regexes with re2[1], potentially unsafe regexes with pcre, or even database lookups or whatever. [1]: https://swtch.com/~rsc/regexp/regexp3.html Reyk: Sorry for the duplicate, meant to reply to the list.
pkg_info: print used repos
This adds a -p option to pkg_info to show the PackageRepositorys
being used.
Inspired by trying to parse /etc/pkg.conf with some awk and quickly
realized that was the wrong way to solve my problem. I then wrote
some perl that reached into OpenBSD:: internals, but concluded it'd
be much cleaner for external consumers to just invoke pkg_info.
Index: pkg_info.1
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg_info.1,v
retrieving revision 1.50
diff -u -p -d -r1.50 pkg_info.1
--- pkg_info.1 8 Sep 2014 01:27:55 - 1.50
+++ pkg_info.1 23 Jun 2015 22:05:53 -
@@ -24,7 +24,7 @@
.Sh SYNOPSIS
.Nm pkg_info
.Bk -words
-.Op Fl AaCcdfIKLMmPqRSstUv
+.Op Fl AaCcdfIKLMmPpqRSstUv
.Op Fl E Ar filename
.Op Fl e Ar pkg-name
.Op Fl l Ar str
@@ -151,6 +151,8 @@ Show the
.Xr pkgpath 7
for each package.
You can easily build a subdirlist with this.
+.It Fl p
+Show the actual package paths being used.
.It Fl Q Ar query
Show all packages in $PKG_PATH which match the given
.Ar query .
Index: OpenBSD/PackageRepositoryList.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepositoryList.pm,v
retrieving revision 1.29
diff -u -p -d -r1.29 PackageRepositoryList.pm
--- OpenBSD/PackageRepositoryList.pm3 Feb 2015 10:26:29 - 1.29
+++ OpenBSD/PackageRepositoryList.pm23 Jun 2015 22:06:49 -
@@ -100,4 +100,14 @@ sub print_without_src
return join(':', @l);
}
+sub print
+{
+ my $self = shift;
+ my @l = ();
+ for my $repo (@{$self-{l}}) {
+ push(@l, $repo-url);
+ }
+ return join(\n, @l);
+}
+
1;
Index: OpenBSD/PkgInfo.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgInfo.pm,v
retrieving revision 1.35
diff -u -p -d -r1.35 PkgInfo.pm
--- OpenBSD/PkgInfo.pm 6 Apr 2015 12:19:35 - 1.35
+++ OpenBSD/PkgInfo.pm 23 Jun 2015 22:05:53 -
@@ -557,7 +557,7 @@ sub parse_and_run
}
};
$state-{no_exports} = 1;
- $state-handle_options('cCdfF:hIKLmPQ:qr:RsSUe:E:Ml:aAt',
+ $state-handle_options('cCdfF:hIKLmpPQ:qr:RsSUe:E:Ml:aAt',
'[-AaCcdfIKLMmPqRSstUv] [-D nolock][-E filename] [-e pkg-name] ',
'[-l str] [-Q query] [-r pkgspec] [pkg-name] [...]');
@@ -610,6 +609,13 @@ sub parse_and_run
is_installed($p) ? #1 (installed) : #1, $p);
}
+ return 0;
+ }
+
+ if ($state-opt('p')) {
+ require OpenBSD::PackageLocator;
+ OpenBSD::PackageLocator-build_default_path($state);
+ $state-say(OpenBSD::PackageLocator-default_path()-print());
return 0;
}
PackageRepositoryList - kill dead code
This is no longer used anywhere, and even crashes if you try to call it.
Besides, OpenBSD::PackageRepository::Source was removed almost a year ago.
Index: PackageRepositoryList.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepositoryList.pm,v
retrieving revision 1.29
diff -u -p -d -r1.29 PackageRepositoryList.pm
--- PackageRepositoryList.pm3 Feb 2015 10:26:29 - 1.29
+++ PackageRepositoryList.pm23 Jun 2015 21:51:18 -
@@ -89,15 +89,4 @@ sub match_locations
return [];
}
-sub print_without_src
-{
- my $self = shift;
- my @l = ();
- for my $repo (@$self) {
- next if $repo-isa(OpenBSD::PackageRepository::Source);
- push(@l, $repo-url);
- }
- return join(':', @l);
-}
-
1;
Remove broken and wrong PKG_PATH output from pkg_info -vQ
The idea was to print the package repository used followed by the stuff
found in it, but that doesn't work:
$ pkg_info -vQ foo
Use of uninitialized value $ENV{PKG_PATH} in concatenation (.) or string at
/usr/libdata/perl5/OpenBSD/PkgInfo.pm line 604.
PKG_PATH=
foo2zjs-20140627
foobillard-3.0ap0
fookebox-0.7.1p1
foomatic-db-4.0.20150415
foomatic-db-engine-4.0.12p0
The value it was trying to print is wrong anyway since PackageRepositoryList
is influenced by more than just $ENV, and isn't necessarily a single value
anyway since pkg.conf can have
installpath = repo1
installpath += repo2
and rarely actually is a single value since we implicitly prepend file:./
This patch removes the broken behavior. I plan to separately introduce
a more robust way of enumerating the used package repositories in a
following patch.
Index: PkgInfo.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgInfo.pm,v
retrieving revision 1.35
diff -u -p -d -r1.35 PkgInfo.pm
--- PkgInfo.pm 6 Apr 2015 12:19:35 - 1.35
+++ PkgInfo.pm 23 Jun 2015 19:59:26 -
@@ -601,7 +601,6 @@ sub parse_and_run
if ($state-opt('Q')) {
require OpenBSD::Search;
- print PKG_PATH=$ENV{PKG_PATH}\n if $state-verbose;
my $partial =
OpenBSD::Search::PartialStem-new($state-opt('Q'));
my $r = $state-repo-match_locations($partial);
Re: RAM encryption and key storing in CPU
The overhead is somewhat high, and it's considered broken anyway: https://www.acsac.org/2012/openconf/modules/request.php?module=oc_proceedingsaction=view.phpa=Acceptid=237type=4 P.S. Sorry for breaking threading, my mail setup is currently a mess.
explicit_bzero in pkcs5_pbkdf2
The intermediate values calculated in hmac_sha1 as part of pkcs5_pbkdf2 are not zeroed afterwards, so we leak a single-hashed version of the key on the stack in tk[]. Also, the correct RFC defining this is RFC 2104 - HMAC: Keyed-Hashing for Message Authentication not RFC 2202 - Test Cases for HMAC-MD5 and HMAC-SHA-1 From RFC 2104, section 4, paragraph 2: We stress that the stored intermediate values need to be treated and protected the same as secret keys. So it's not just best-practice dictating that these should be bzeroed. Here is a patch for the same code in libutil and libsa. Index: lib/libutil/pkcs5_pbkdf2.c === RCS file: /cvs/src/lib/libutil/pkcs5_pbkdf2.c,v retrieving revision 1.9 diff -u -p -d -r1.9 pkcs5_pbkdf2.c --- lib/libutil/pkcs5_pbkdf2.c 5 Feb 2015 12:59:57 - 1.9 +++ lib/libutil/pkcs5_pbkdf2.c 10 Jun 2015 19:59:09 - @@ -28,7 +28,7 @@ #defineMINIMUM(a,b) (((a) (b)) ? (a) : (b)) /* - * HMAC-SHA-1 (from RFC 2202). + * HMAC-SHA-1 (from RFC 2104). */ static void hmac_sha1(const u_int8_t *text, size_t text_len, const u_int8_t *key, @@ -67,6 +67,10 @@ hmac_sha1(const u_int8_t *text, size_t t SHA1Update(ctx, k_pad, SHA1_BLOCK_LENGTH); SHA1Update(ctx, digest, SHA1_DIGEST_LENGTH); SHA1Final(digest, ctx); + + explicit_bzero(ctx, sizeof(ctx)); + explicit_bzero(k_pad, sizeof(k_pad)); + explicit_bzero(tk, sizeof(tk)); } /* Index: sys/lib/libsa/hmac_sha1.c === RCS file: /cvs/src/sys/lib/libsa/hmac_sha1.c,v retrieving revision 1.1 diff -u -p -d -r1.1 hmac_sha1.c --- sys/lib/libsa/hmac_sha1.c 9 Oct 2012 12:36:50 - 1.1 +++ sys/lib/libsa/hmac_sha1.c 10 Jun 2015 19:58:39 - @@ -23,7 +23,7 @@ #include hmac_sha1.h /* - * HMAC-SHA-1 (from RFC 2202). + * HMAC-SHA-1 (from RFC 2104). */ void hmac_sha1(const u_int8_t *text, size_t text_len, const u_int8_t *key, @@ -62,4 +62,8 @@ hmac_sha1(const u_int8_t *text, size_t t SHA1Update(ctx, k_pad, SHA1_BLOCK_LENGTH); SHA1Update(ctx, digest, SHA1_DIGEST_LENGTH); SHA1Final(digest, ctx); + + explicit_bzero(ctx, sizeof(ctx)); + explicit_bzero(k_pad, sizeof(k_pad)); + explicit_bzero(tk, sizeof(tk)); }
minor dd(1) posix-compliance
POSIX says the truncated things are record(s) not block(s):
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html
That's what it's historically been too:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/dd.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/bin/dd/dd.c
It sounds odd since bs= implies block sizes, not record sizes, so
perhaps there's a reason to not want to change it? Idk...
If it is to be changed, perhaps it makes sense to change the last
remaining blocks for odd length swabs (a few lines above this one)
too for consistency.
Index: misc.c
===
RCS file: /cvs/src/bin/dd/misc.c,v
retrieving revision 1.18
diff -u -p -r1.18 misc.c
--- misc.c 12 Feb 2014 01:18:36 - 1.18
+++ misc.c 17 Mar 2015 02:04:46 -
@@ -83,8 +83,8 @@ summary(void)
}
if (st.trunc) {
(void)snprintf(buf[2], sizeof(buf[2]),
- %zu truncated %s\n,
-st.trunc, (st.trunc == 1) ? block : blocks);
+ %zu truncated %s\n,
+st.trunc, (st.trunc == 1) ? record : records);
iov[i].iov_base = buf[2];
iov[i++].iov_len = strlen(buf[2]);
}
sigaction.2 consistency
We use async-signal-safe (not async-signal safe) elsewhere, and so does POSIX. http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html Index: sigaction.2 === RCS file: /cvs/src/lib/libc/sys/sigaction.2,v retrieving revision 1.61 diff -u -p -r1.61 sigaction.2 --- sigaction.2 31 Aug 2014 01:42:36 - 1.61 +++ sigaction.2 15 Sep 2014 04:30:54 - @@ -463,7 +463,7 @@ and .Dv SA_SIGINFO flags are options commonly found in other operating systems. The following functions are either reentrant or not interruptible -by signals and are async-signal safe. +by signals and are async-signal-safe. Therefore applications may invoke them, without restriction, from signal-catching functions: .Pp
Re: Refactoring process-local file descriptor data
On Wed, Sep 03, 2014 at 03:31:50PM -0500, Kent R. Spillner wrote:
Need to re-roll for -current?
Yep, sorry. I knew the the dup3 changes would break it when I saw them
go in but I've been busy with classes and stuff.
Here's a new version. This one considerably less tested than previous
versions, I just made sure it still built and that build built itself
too.
Capsicum is still blocking on this patch (or one like it).
Any/all feedback welcome.
On Thu, Jul 10, 2014 at 04:13:38PM -0400, Jean-Philippe Ouellet wrote:
This diff adds another struct between filedesc and file to store
process-local per-descriptor information. Currently, the only thing in
this struct is the file pointer and some flags, however I have another
patch on top of this that adds capsicum capabilities to it. (And
another that uses mallocarray(9) where applicable. One thing at a time.)
The data is currently stored in one big allocation with all the file *s
in front, and all the flags after. When that allocation grows, there are
two copies and two zeroings. This is fine when we only have two fields
(fd_ofiles and fd_ofileflags), but adding more is ugly.
Instead, I propose we have a struct for each file descriptor table entry
(filedescent) and put the files, flags, and capabilities in that.
The immediate impact is some memory waste due to padding (3 or 7 bytes
per file descriptor, depending on the arch), however once capabilities
are added it will be negligible. I discussed it with matthew@ and
guenther@ and concluded this was the saner way. For what it's worth,
FreeBSD and NetBSD have done the same thing.
I've been running different versions of this for about a month or so,
no issues noticed so far.
A similar earlier version was reviewed by matthew@ and guenther@.
Index: sys/filedesc.h
===
RCS file: /cvs/src/sys/sys/filedesc.h,v
retrieving revision 1.28
diff -u -p -r1.28 filedesc.h
--- sys/filedesc.h 15 May 2014 03:52:25 - 1.28
+++ sys/filedesc.h 7 Sep 2014 19:04:20 -
@@ -34,9 +34,6 @@
#include sys/rwlock.h
/*
- * This structure is used for the management of descriptors. It may be
- * shared by multiple processes.
- *
* A process is initially started out with NDFILE descriptors stored within
* this structure, selected to be enough for typical applications based on
* the historical limit of 20 open files (and the usage of descriptors by
@@ -56,22 +53,33 @@
#define NDHISLOTS(x) (NDREDUCE(NDREDUCE(x)))
#define NDLOSLOTS(x) (NDHISLOTS(x) NDENTRYSHIFT)
+/*
+ * File wrapper for per-process per-file data.
+ */
+struct filedescent {
+ struct file *fde_file; /* file structure for open file */
+ charfde_flags; /* process-local file flags */
+};
+
+/*
+ * This structure is used for the management of descriptors. It may be
+ * shared by multiple processes.
+ */
struct filedesc {
- struct file **fd_ofiles; /* file structures for open files */
- char*fd_ofileflags; /* per-process open file flags */
+ struct filedescent *fd_fdents; /* per-process file wrappers */
struct vnode *fd_cdir; /* current directory */
struct vnode *fd_rdir; /* root directory */
int fd_nfiles; /* number of open files allocated */
int fd_openfd; /* number of files currently open */
u_int *fd_himap; /* each bit points to 32 fds */
u_int *fd_lomap; /* bitmap of free fds */
- int fd_lastfile;/* high-water mark of fd_ofiles */
+ int fd_lastfile;/* high-water mark of fd_fdents */
int fd_freefile;/* approx. next free file */
u_short fd_cmask; /* mask for file creation */
u_short fd_refcnt; /* reference count */
struct rwlock fd_lock; /* lock for the file descs; must be */
- /* held when writing to fd_ofiles, */
- /* fd_ofileflags, or fd_{hi,lo}map */
+ /* held when writing to fd_fdents */
+ /* or fd_{hi,lo}map */
int fd_knlistsize; /* size of knlist */
struct klist *fd_knlist; /* list of attached knotes */
@@ -91,8 +99,7 @@ struct filedesc0 {
* These arrays are used when the number of open files is
* = NDFILE, and are then pointed to by the pointers above.
*/
- struct file *fd_dfiles[NDFILE];
- charfd_dfileflags[NDFILE];
+ struct filedescent fd_dfdents[NDFILE];
/*
* There arrays are used when the number of open files is
* = 1024, and are then pointed to by the pointers above.
Index: kern/kern_descrip.c
Re: Refactoring process-local file descriptor data
Ping?
On Sun, Jul 13, 2014 at 03:45:44PM -0400, Jean-Philippe Ouellet wrote:
Updated for mallocarray() and free(size).
On Thu, Jul 10, 2014 at 04:13:38PM -0400, Jean-Philippe Ouellet wrote:
This diff adds another struct between filedesc and file to store
process-local per-descriptor information. Currently, the only thing in
this struct is the file pointer and some flags, however I have another
patch on top of this that adds capsicum capabilities to it. (And
another that uses mallocarray(9) where applicable. One thing at a time.)
The data is currently stored in one big allocation with all the file *s
in front, and all the flags after. When that allocation grows, there are
two copies and two zeroings. This is fine when we only have two fields
(fd_ofiles and fd_ofileflags), but adding more is ugly.
Instead, I propose we have a struct for each file descriptor table entry
(filedescent) and put the files, flags, and capabilities in that.
The immediate impact is some memory waste due to padding (3 or 7 bytes
per file descriptor, depending on the arch), however once capabilities
are added it will be negligible. I discussed it with matthew@ and
guenther@ and concluded this was the saner way. For what it's worth,
FreeBSD and NetBSD have done the same thing.
I've been running different versions of this for about a month or so,
no issues noticed so far.
A similar earlier version was reviewed by matthew@ and guenther@.
Index: sys/filedesc.h
===
RCS file: /cvs/src/sys/sys/filedesc.h,v
retrieving revision 1.28
diff -u -p -r1.28 filedesc.h
--- sys/filedesc.h 15 May 2014 03:52:25 - 1.28
+++ sys/filedesc.h 13 Jul 2014 19:40:01 -
@@ -34,9 +34,6 @@
#include sys/rwlock.h
/*
- * This structure is used for the management of descriptors. It may be
- * shared by multiple processes.
- *
* A process is initially started out with NDFILE descriptors stored within
* this structure, selected to be enough for typical applications based on
* the historical limit of 20 open files (and the usage of descriptors by
@@ -56,22 +53,33 @@
#define NDHISLOTS(x) (NDREDUCE(NDREDUCE(x)))
#define NDLOSLOTS(x) (NDHISLOTS(x) NDENTRYSHIFT)
+/*
+ * File wrapper for per-process per-file data.
+ */
+struct filedescent {
+ struct file *fde_file; /* file structure for open file */
+ charfde_flags; /* process-local file flags */
+};
+
+/*
+ * This structure is used for the management of descriptors. It may be
+ * shared by multiple processes.
+ */
struct filedesc {
- struct file **fd_ofiles; /* file structures for open files */
- char*fd_ofileflags; /* per-process open file flags */
+ struct filedescent *fd_fdents; /* per-process file wrappers */
struct vnode *fd_cdir; /* current directory */
struct vnode *fd_rdir; /* root directory */
int fd_nfiles; /* number of open files allocated */
int fd_openfd; /* number of files currently open */
u_int *fd_himap; /* each bit points to 32 fds */
u_int *fd_lomap; /* bitmap of free fds */
- int fd_lastfile;/* high-water mark of fd_ofiles */
+ int fd_lastfile;/* high-water mark of fd_fdents */
int fd_freefile;/* approx. next free file */
u_short fd_cmask; /* mask for file creation */
u_short fd_refcnt; /* reference count */
struct rwlock fd_lock; /* lock for the file descs; must be */
- /* held when writing to fd_ofiles, */
- /* fd_ofileflags, or fd_{hi,lo}map */
+ /* held when writing to fd_fdents */
+ /* or fd_{hi,lo}map */
int fd_knlistsize; /* size of knlist */
struct klist *fd_knlist; /* list of attached knotes */
@@ -91,8 +99,7 @@ struct filedesc0 {
* These arrays are used when the number of open files is
* = NDFILE, and are then pointed to by the pointers above.
*/
- struct file *fd_dfiles[NDFILE];
- charfd_dfileflags[NDFILE];
+ struct filedescent fd_dfdents[NDFILE];
/*
* There arrays are used when the number of open files is
* = 1024, and are then pointed to by the pointers above.
Index: kern/kern_descrip.c
===
RCS file: /cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.112
diff -u -p -r1.112 kern_descrip.c
--- kern/kern_descrip.c 13 Jul 2014 15:29:04 - 1.112
+++ kern/kern_descrip.c 13 Jul 2014 19:40:01 -
@@ -123,7 +123,7 @@ int
find_last_set(struct filedesc *fd, int last
Re: PATCH: overflow behavior in malloc(9)
On Mon, Jul 21, 2014 at 06:59:12AM +, Doug Hogan wrote: -objects and checks for arithmetic overflow. +objects and calls +.Xr panic 9 +on arithmetic overflow. That is misleading in the M_CANFAIL case. I'm not terribly good at wording things, but I suggest something more like this instead: Index: malloc.9 === RCS file: /cvs/src/share/man/man9/malloc.9,v retrieving revision 1.56 diff -u -p -r1.56 malloc.9 --- malloc.912 Jul 2014 18:51:10 - 1.56 +++ malloc.922 Jul 2014 06:48:28 - @@ -97,16 +97,14 @@ or .Dv M_WAITOK must be specified. .It Dv M_CANFAIL -In the +If using +.Fn mallocarray +and arithmetic would overflow, or if .Dv M_WAITOK -case, if not enough memory is available, return +is also specified and not enough memory is available, then .Dv NULL -instead of calling +is returned instead of calling .Xr panic 9 . -.Dv M_CANFAIL -has no effect if -.Dv M_NOWAIT -is specified. .It Dv M_ZERO Causes .Fn malloc
Re: PATCH: further kernel malloc - mallocarray
For the cases where it's more than just nitems * sizeof(item),
maybe it wouldn't be a bad idea to have something like:
static __inline int
MULT_OVERFLOWS(int x, int y)
{
const intmax_t max = 1UL sizeof(size_t) * 4;
return ((x = max || y = max) x 0 SIZE_MAX / x y);
}
(or maybe a macro version) in some public header someplace,
and associated assertions it where applicable.
Index: sys/dev/ic/mfi.c
- sc-sc_bbu_status = malloc(sizeof(*sc-sc_bbu_status) *
- sizeof(mfi_bbu_indicators), M_DEVBUF, M_WAITOK | M_ZERO);
+ sc-sc_bbu_status = mallocarray(sizeof(mfi_bbu_indicators),
+ sizeof(*sc-sc_bbu_status), M_DEVBUF, M_WAITOK | M_ZERO);
If we're not converting (numeric constant) * sizeof(foo) because it's
cheaper not to and realistically impossible to overflow anyway, then
I think we shouldn't convert sizeof() * sizeof() for the same reason.
Tedu:
- shellargp = malloc(4 * sizeof(char *), M_EXEC, M_WAITOK);
+ shellargp = mallocarray(4, sizeof(char *), M_EXEC, M_WAITOK);
Theo:
As for the final diff, I've been giving up on the known constant
scenario. It seems expensive.
Tedu:
Meh. :) I think they can be changed back if necessary; in the mean
time it makes it easier to see what's done and what remains.
Theo:
It is an extra register window on sparc and sparc64.
const static - static const
The C standard mandates that static be first.
From ISO/IEC 9899:1999 and 9899:201x,
6.11.5 - Storage-class specifiers:
The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is
an obsolescent feature.
and -Wextra complains:
warning: 'static' is not at beginning of declaration
Index: sys/crypto/sha2.c
===
RCS file: /cvs/src/sys/crypto/sha2.c,v
retrieving revision 1.8
diff -u -p -r1.8 sha2.c
--- sys/crypto/sha2.c 11 Jan 2011 15:42:05 - 1.8
+++ sys/crypto/sha2.c 14 Jul 2014 15:31:53 -
@@ -167,7 +167,7 @@ void SHA512Transform(SHA2_CTX *, const u
/*** SHA-XYZ INITIAL HASH VALUES AND CONSTANTS /
/* Hash constant words K for SHA-256: */
-const static u_int32_t K256[64] = {
+static const u_int32_t K256[64] = {
0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL,
0x3956c25bUL, 0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL,
0xd807aa98UL, 0x12835b01UL, 0x243185beUL, 0x550c7dc3UL,
@@ -187,7 +187,7 @@ const static u_int32_t K256[64] = {
};
/* Initial hash value H for SHA-256: */
-const static u_int32_t sha256_initial_hash_value[8] = {
+static const u_int32_t sha256_initial_hash_value[8] = {
0x6a09e667UL,
0xbb67ae85UL,
0x3c6ef372UL,
@@ -199,7 +199,7 @@ const static u_int32_t sha256_initial_ha
};
/* Hash constant words K for SHA-384 and SHA-512: */
-const static u_int64_t K512[80] = {
+static const u_int64_t K512[80] = {
0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL,
0xb5c0fbcfec4d3b2fULL, 0xe9b5dba58189dbbcULL,
0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
@@ -243,7 +243,7 @@ const static u_int64_t K512[80] = {
};
/* Initial hash value H for SHA-384 */
-const static u_int64_t sha384_initial_hash_value[8] = {
+static const u_int64_t sha384_initial_hash_value[8] = {
0xcbbb9d5dc1059ed8ULL,
0x629a292a367cd507ULL,
0x9159015a3070dd17ULL,
@@ -255,7 +255,7 @@ const static u_int64_t sha384_initial_ha
};
/* Initial hash value H for SHA-512 */
-const static u_int64_t sha512_initial_hash_value[8] = {
+static const u_int64_t sha512_initial_hash_value[8] = {
0x6a09e667f3bcc908ULL,
0xbb67ae8584caa73bULL,
0x3c6ef372fe94f82bULL,
Index: lib/libc/crypt/bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.44
diff -u -p -r1.44 bcrypt.c
--- lib/libc/crypt/bcrypt.c 17 May 2014 15:18:06 - 1.44
+++ lib/libc/crypt/bcrypt.c 14 Jul 2014 15:31:53 -
@@ -231,10 +231,10 @@ bcrypt_checkpass(const char *pass, const
/*
* internal utilities
*/
-const static u_int8_t Base64Code[] =
+static const u_int8_t Base64Code[] =
./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789;
-const static u_int8_t index_64[128] = {
+static const u_int8_t index_64[128] = {
255, 255, 255, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255, 255, 255,
Index: lib/libc/net/res_random.c
===
RCS file: /cvs/src/lib/libc/net/res_random.c,v
retrieving revision 1.20
diff -u -p -r1.20 res_random.c
--- lib/libc/net/res_random.c 12 Nov 2013 07:00:24 - 1.20
+++ lib/libc/net/res_random.c 14 Jul 2014 15:31:53 -
@@ -87,7 +87,7 @@ struct prf_ctx {
};
#define PFAC_N 3
-const static u_int16_t pfacts[PFAC_N] = {
+static const u_int16_t pfacts[PFAC_N] = {
2,
3,
2729
Re: const static - static const
On Mon, Jul 14, 2014 at 11:44:30AM -0400, Jean-Philippe Ouellet wrote:
The C standard mandates that static be first.
Of course I forgot something... This is the hunk that made me
notice in the first place. Found while porting signify to osx.
Index: lib/libc/hash/sha2.c
===
RCS file: /cvs/src/lib/libc/hash/sha2.c,v
retrieving revision 1.17
diff -u -p -r1.17 sha2.c
--- lib/libc/hash/sha2.c8 Jan 2014 06:14:57 - 1.17
+++ lib/libc/hash/sha2.c15 Jul 2014 04:18:06 -
@@ -171,7 +171,7 @@
/*** SHA-XYZ INITIAL HASH VALUES AND CONSTANTS /
/* Hash constant words K for SHA-224 and SHA-256: */
-const static u_int32_t K256[64] = {
+static const u_int32_t K256[64] = {
0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL,
0x3956c25bUL, 0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL,
0xd807aa98UL, 0x12835b01UL, 0x243185beUL, 0x550c7dc3UL,
@@ -191,7 +191,7 @@ const static u_int32_t K256[64] = {
};
/* Initial hash value H for SHA-224: */
-const static u_int32_t sha224_initial_hash_value[8] = {
+static const u_int32_t sha224_initial_hash_value[8] = {
0xc1059ed8UL,
0x367cd507UL,
0x3070dd17UL,
@@ -203,7 +203,7 @@ const static u_int32_t sha224_initial_ha
};
/* Initial hash value H for SHA-256: */
-const static u_int32_t sha256_initial_hash_value[8] = {
+static const u_int32_t sha256_initial_hash_value[8] = {
0x6a09e667UL,
0xbb67ae85UL,
0x3c6ef372UL,
@@ -215,7 +215,7 @@ const static u_int32_t sha256_initial_ha
};
/* Hash constant words K for SHA-384 and SHA-512: */
-const static u_int64_t K512[80] = {
+static const u_int64_t K512[80] = {
0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL,
0xb5c0fbcfec4d3b2fULL, 0xe9b5dba58189dbbcULL,
0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
@@ -259,7 +259,7 @@ const static u_int64_t K512[80] = {
};
/* Initial hash value H for SHA-512 */
-const static u_int64_t sha512_initial_hash_value[8] = {
+static const u_int64_t sha512_initial_hash_value[8] = {
0x6a09e667f3bcc908ULL,
0xbb67ae8584caa73bULL,
0x3c6ef372fe94f82bULL,
@@ -272,7 +272,7 @@ const static u_int64_t sha512_initial_ha
#if !defined(SHA2_SMALL)
/* Initial hash value H for SHA-384 */
-const static u_int64_t sha384_initial_hash_value[8] = {
+static const u_int64_t sha384_initial_hash_value[8] = {
0xcbbb9d5dc1059ed8ULL,
0x629a292a367cd507ULL,
0x9159015a3070dd17ULL,
Re: improve srandomdev
On Sun, Jul 13, 2014 at 04:03:53PM +0200, Brent Cook wrote:
On Jul 13, 2014, at 3:58 PM, Ted Unangst t...@tedunangst.com wrote:
@@ -411,6 +404,9 @@ static long
random_l(void)
{
int32_t i;
+
+ if (use_arc4random)
+ return arc4random() 0x7fff;
return arc4random() % ((unsigned)RAND_MAX + 1) ?
No. RAND_MAX is for rand() not random().
From posix for random():
The random() function shall use a non-linear additive feedback
random-number generator employing a default state array size of
31 long integers to return successive pseudo-random numbers in
the range from 0 to 2^31 - 1.
From posix for rand():
The rand() function shall compute a sequence of pseudo-random
integers in the range [0, {RAND_MAX}]
Re: mallocarray() in sys/dev, first pass
On Sun, Jul 13, 2014 at 11:29:22AM -0600, dera...@cvs.openbsd.org wrote: - ldp = malloc(sizeof(*ldp) + (k-1), M_DEVBUF, M_NOWAIT); + ldp = mallocarray(k-1, sizeof(*ldp), M_DEVBUF, M_NOWAIT); Are you sure k-1 can never be small enough such that a*b is less than a+b?
Re: mallocarray() in sys/dev, first pass
And some cosmetic things: Index: ic/malo.c - ring-data = malloc(count * sizeof (struct malo_rx_data), M_DEVBUF, - M_NOWAIT); + ring-data = mallocarray(count, sizeof (struct malo_rx_data), + M_DEVBUF, M_NOWAIT); Might as well s/sizeof (/sizeof(/ while you're here. Index: ic/qla.c - sc-sc_ccbs = malloc(sizeof(struct qla_ccb) * sc-sc_maxcmds, + sc-sc_ccbs = mallocarray(sizeof(struct qla_ccb), sc-sc_maxcmds, Wrong order. Index: ic/qlw.c - sc-sc_ccbs = malloc(sizeof(struct qlw_ccb) * sc-sc_maxccbs, + sc-sc_ccbs = mallocarray(sizeof(struct qlw_ccb), sc-sc_maxccbs, Wrong order. Index: ic/rt2560.c @@ -388,8 +388,8 @@ rt2560_alloc_tx_ring(struct rt2560_softc - ring-data = malloc(count * sizeof (struct rt2560_tx_data), M_DEVBUF, - M_NOWAIT | M_ZERO); + ring-data = mallocarray(count, sizeof (struct rt2560_tx_data), + M_DEVBUF, M_NOWAIT | M_ZERO); sizeof ( @@ -532,8 +532,8 @@ rt2560_alloc_rx_ring(struct rt2560_softc - ring-data = malloc(count * sizeof (struct rt2560_rx_data), M_DEVBUF, - M_NOWAIT | M_ZERO); + ring-data = mallocarray(count, sizeof (struct rt2560_rx_data), + M_DEVBUF, M_NOWAIT | M_ZERO); sizeof ( Index: ic/rt2661.c @@ -473,8 +473,8 @@ rt2661_alloc_tx_ring(struct rt2661_softc - ring-data = malloc(count * sizeof (struct rt2661_tx_data), M_DEVBUF, - M_NOWAIT | M_ZERO); + ring-data = mallocarray(count, sizeof (struct rt2661_tx_data), + M_DEVBUF, M_NOWAIT | M_ZERO); sizeof ( @@ -614,8 +614,8 @@ rt2661_alloc_rx_ring(struct rt2661_softc - ring-data = malloc(count * sizeof (struct rt2661_rx_data), M_DEVBUF, - M_NOWAIT | M_ZERO); + ring-data = mallocarray(count, sizeof (struct rt2661_rx_data), + M_DEVBUF, M_NOWAIT | M_ZERO); sizeof ( Index: ic/siop.c - newcbd-cmds = malloc(sizeof(struct siop_cmd) * SIOP_NCMDPB, + newcbd-cmds = mallocarray(sizeof(struct siop_cmd), SIOP_NCMDPB, Wrong order. Index: pci/agp.c - segs = malloc(nseg * sizeof *segs, M_AGP, M_WAITOK); + segs = mallocarray(nseg, sizeof *segs, M_AGP, M_WAITOK); sizeof(*segs) Index: pci/hifn7751.c - ses = (struct hifn_session *)malloc((sesn + 1) * - sizeof(*ses), M_DEVBUF, M_NOWAIT); + ses = mallocarray((sesn + 1), sizeof(*ses), + M_DEVBUF, M_NOWAIT); useless () Index: pci/mpii.c - sc-sc_ccbs = malloc(sizeof(*ccb) * (sc-sc_max_cmds-1), + sc-sc_ccbs = mallocarray((sc-sc_max_cmds-1), sizeof(*ccb), mallocarray(sc-sc_max_cmds - 1, ... Index: pci/safe.c - ses = (struct safe_session *)malloc((sesn + 1) * + ses = mallocarray((sesn + 1), useless () Index: pci/ubsec.c - ses = (struct ubsec_session *)malloc((sesn + 1) * + ses = mallocarray((sesn + 1), useless ()
Re: Refactoring process-local file descriptor data
Updated for mallocarray() and free(size).
On Thu, Jul 10, 2014 at 04:13:38PM -0400, Jean-Philippe Ouellet wrote:
This diff adds another struct between filedesc and file to store
process-local per-descriptor information. Currently, the only thing in
this struct is the file pointer and some flags, however I have another
patch on top of this that adds capsicum capabilities to it. (And
another that uses mallocarray(9) where applicable. One thing at a time.)
The data is currently stored in one big allocation with all the file *s
in front, and all the flags after. When that allocation grows, there are
two copies and two zeroings. This is fine when we only have two fields
(fd_ofiles and fd_ofileflags), but adding more is ugly.
Instead, I propose we have a struct for each file descriptor table entry
(filedescent) and put the files, flags, and capabilities in that.
The immediate impact is some memory waste due to padding (3 or 7 bytes
per file descriptor, depending on the arch), however once capabilities
are added it will be negligible. I discussed it with matthew@ and
guenther@ and concluded this was the saner way. For what it's worth,
FreeBSD and NetBSD have done the same thing.
I've been running different versions of this for about a month or so,
no issues noticed so far.
A similar earlier version was reviewed by matthew@ and guenther@.
Index: sys/filedesc.h
===
RCS file: /cvs/src/sys/sys/filedesc.h,v
retrieving revision 1.28
diff -u -p -r1.28 filedesc.h
--- sys/filedesc.h 15 May 2014 03:52:25 - 1.28
+++ sys/filedesc.h 13 Jul 2014 19:40:01 -
@@ -34,9 +34,6 @@
#include sys/rwlock.h
/*
- * This structure is used for the management of descriptors. It may be
- * shared by multiple processes.
- *
* A process is initially started out with NDFILE descriptors stored within
* this structure, selected to be enough for typical applications based on
* the historical limit of 20 open files (and the usage of descriptors by
@@ -56,22 +53,33 @@
#define NDHISLOTS(x) (NDREDUCE(NDREDUCE(x)))
#define NDLOSLOTS(x) (NDHISLOTS(x) NDENTRYSHIFT)
+/*
+ * File wrapper for per-process per-file data.
+ */
+struct filedescent {
+ struct file *fde_file; /* file structure for open file */
+ charfde_flags; /* process-local file flags */
+};
+
+/*
+ * This structure is used for the management of descriptors. It may be
+ * shared by multiple processes.
+ */
struct filedesc {
- struct file **fd_ofiles; /* file structures for open files */
- char*fd_ofileflags; /* per-process open file flags */
+ struct filedescent *fd_fdents; /* per-process file wrappers */
struct vnode *fd_cdir; /* current directory */
struct vnode *fd_rdir; /* root directory */
int fd_nfiles; /* number of open files allocated */
int fd_openfd; /* number of files currently open */
u_int *fd_himap; /* each bit points to 32 fds */
u_int *fd_lomap; /* bitmap of free fds */
- int fd_lastfile;/* high-water mark of fd_ofiles */
+ int fd_lastfile;/* high-water mark of fd_fdents */
int fd_freefile;/* approx. next free file */
u_short fd_cmask; /* mask for file creation */
u_short fd_refcnt; /* reference count */
struct rwlock fd_lock; /* lock for the file descs; must be */
- /* held when writing to fd_ofiles, */
- /* fd_ofileflags, or fd_{hi,lo}map */
+ /* held when writing to fd_fdents */
+ /* or fd_{hi,lo}map */
int fd_knlistsize; /* size of knlist */
struct klist *fd_knlist; /* list of attached knotes */
@@ -91,8 +99,7 @@ struct filedesc0 {
* These arrays are used when the number of open files is
* = NDFILE, and are then pointed to by the pointers above.
*/
- struct file *fd_dfiles[NDFILE];
- charfd_dfileflags[NDFILE];
+ struct filedescent fd_dfdents[NDFILE];
/*
* There arrays are used when the number of open files is
* = 1024, and are then pointed to by the pointers above.
Index: kern/kern_descrip.c
===
RCS file: /cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.112
diff -u -p -r1.112 kern_descrip.c
--- kern/kern_descrip.c 13 Jul 2014 15:29:04 - 1.112
+++ kern/kern_descrip.c 13 Jul 2014 19:40:01 -
@@ -123,7 +123,7 @@ int
find_last_set(struct filedesc *fd, int last)
{
int off, i;
- struct file **ofiles = fd-fd_ofiles;
+ struct filedescent *fdents = fd
getentropy.2 incorrect arg type
It takes a void *, not a char *. Index: getentropy.2 === RCS file: /cvs/src/lib/libc/sys/getentropy.2,v retrieving revision 1.4 diff -u -p -r1.4 getentropy.2 --- getentropy.215 Jun 2014 07:24:19 - 1.4 +++ getentropy.213 Jul 2014 21:32:54 - @@ -23,7 +23,7 @@ .Sh SYNOPSIS .Fd #include unistd.h .Ft int -.Fn getentropy char *buf size_t buflen +.Fn getentropy void *buf size_t buflen .Sh DESCRIPTION .Nm fills a buffer with high-quality seed-grade entropy, which can
Re: mallocarray(9)
On Thu, Jul 10, 2014 at 12:02:40PM -0700, Matthew Dempsky wrote: -.Fn malloc unsigned long size int type int flags +.Fn malloc size_t size int type int flags +.Ft void * +.Fn malloc size_t nmemb size_t size int type int flags 2nd one should be mallocarray.
Refactoring process-local file descriptor data
This diff adds another struct between filedesc and file to store
process-local per-descriptor information. Currently, the only thing in
this struct is the file pointer and some flags, however I have another
patch on top of this that adds capsicum capabilities to it. (And
another that uses mallocarray(9) where applicable. One thing at a time.)
The data is currently stored in one big allocation with all the file *s
in front, and all the flags after. When that allocation grows, there are
two copies and two zeroings. This is fine when we only have two fields
(fd_ofiles and fd_ofileflags), but adding more is ugly.
Instead, I propose we have a struct for each file descriptor table entry
(filedescent) and put the files, flags, and capabilities in that.
The immediate impact is some memory waste due to padding (3 or 7 bytes
per file descriptor, depending on the arch), however once capabilities
are added it will be negligible. I discussed it with matthew@ and
guenther@ and concluded this was the saner way. For what it's worth,
FreeBSD and NetBSD have done the same thing.
I've been running different versions of this for about a month or so,
no issues noticed so far.
A similar earlier version was reviewed by matthew@ and guenther@.
Index: sys/filedesc.h
===
RCS file: /cvs/src/sys/sys/filedesc.h,v
retrieving revision 1.28
diff -u -p -r1.28 filedesc.h
--- sys/filedesc.h 15 May 2014 03:52:25 - 1.28
+++ sys/filedesc.h 10 Jul 2014 19:44:42 -
@@ -34,9 +34,6 @@
#include sys/rwlock.h
/*
- * This structure is used for the management of descriptors. It may be
- * shared by multiple processes.
- *
* A process is initially started out with NDFILE descriptors stored within
* this structure, selected to be enough for typical applications based on
* the historical limit of 20 open files (and the usage of descriptors by
@@ -56,22 +53,33 @@
#define NDHISLOTS(x) (NDREDUCE(NDREDUCE(x)))
#define NDLOSLOTS(x) (NDHISLOTS(x) NDENTRYSHIFT)
+/*
+ * File wrapper for per-process per-file data.
+ */
+struct filedescent {
+ struct file *fde_file; /* file structure for open file */
+ charfde_flags; /* process-local file flags */
+};
+
+/*
+ * This structure is used for the management of descriptors. It may be
+ * shared by multiple processes.
+ */
struct filedesc {
- struct file **fd_ofiles; /* file structures for open files */
- char*fd_ofileflags; /* per-process open file flags */
+ struct filedescent *fd_fdents; /* per-process file wrappers */
struct vnode *fd_cdir; /* current directory */
struct vnode *fd_rdir; /* root directory */
int fd_nfiles; /* number of open files allocated */
int fd_openfd; /* number of files currently open */
u_int *fd_himap; /* each bit points to 32 fds */
u_int *fd_lomap; /* bitmap of free fds */
- int fd_lastfile;/* high-water mark of fd_ofiles */
+ int fd_lastfile;/* high-water mark of fd_fdents */
int fd_freefile;/* approx. next free file */
u_short fd_cmask; /* mask for file creation */
u_short fd_refcnt; /* reference count */
struct rwlock fd_lock; /* lock for the file descs; must be */
- /* held when writing to fd_ofiles, */
- /* fd_ofileflags, or fd_{hi,lo}map */
+ /* held when writing to fd_fdents */
+ /* or fd_{hi,lo}map */
int fd_knlistsize; /* size of knlist */
struct klist *fd_knlist; /* list of attached knotes */
@@ -91,8 +99,7 @@ struct filedesc0 {
* These arrays are used when the number of open files is
* = NDFILE, and are then pointed to by the pointers above.
*/
- struct file *fd_dfiles[NDFILE];
- charfd_dfileflags[NDFILE];
+ struct filedescent fd_dfdents[NDFILE];
/*
* There arrays are used when the number of open files is
* = 1024, and are then pointed to by the pointers above.
Index: kern/kern_descrip.c
===
RCS file: /cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.110
diff -u -p -r1.110 kern_descrip.c
--- kern/kern_descrip.c 8 Jul 2014 17:19:25 - 1.110
+++ kern/kern_descrip.c 10 Jul 2014 19:44:42 -
@@ -123,7 +123,7 @@ int
find_last_set(struct filedesc *fd, int last)
{
int off, i;
- struct file **ofiles = fd-fd_ofiles;
+ struct filedescent *fdents = fd-fd_fdents;
u_int *bitmap = fd-fd_lomap;
off = (last - 1) NDENTRYSHIFT;
@@ -137,7 +137,7 @@ find_last_set(struct
disklabel(8) n command default partition
Hi,
When assigning mount points to an already-partitioned disk
without a its fstab handy, it's annoying to type the partition
letters one after another. (And sing the alphabet each time or
look at the output of 'p' for letters after 'f'. I blame hex.)
I could go back to preeschool and learn the alphabet, but this
seemed easier.
This patch makes the 'n' (set mount point) command provide the
lowest partition of a mountable type without a set mount-point
as the default in the partition-selection prompt.
It also addresses the fact that get_mp() hadn't been updated
in a while and wasn't aware that RAID partitions can't have
mount points.
Thoughts?
Index: sys/sys/disklabel.h
===
RCS file: /cvs/src/sys/sys/disklabel.h,v
retrieving revision 1.60
diff -u -p -r1.60 disklabel.h
--- sys/sys/disklabel.h 5 May 2014 13:32:15 - 1.60
+++ sys/sys/disklabel.h 15 Jun 2014 02:22:20 -
@@ -275,6 +275,10 @@ static char *dktypenames[] = {
#define FS_NTFS20 /* Windows/NT file system */
#define FS_UDF 21 /* UDF (DVD) filesystem */
+#define FS_ALLOWS_NAME(t) ((t) != FS_UNUSED (t) != FS_SWAP \
+(t) != FS_OTHER (t) != FS_BOOT \
+(t) != FS_RAID)
+
#ifdef DKTYPENAMES
static char *fstypenames[] = {
unused,
Index: sbin/disklabel/editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.286
diff -u -p -r1.286 editor.c
--- sbin/disklabel/editor.c 2 May 2014 23:17:29 - 1.286
+++ sbin/disklabel/editor.c 15 Jun 2014 02:22:20 -
@@ -933,12 +933,23 @@ void
editor_name(struct disklabel *lp, char *p)
{
struct partition *pp;
+ char buf[2];
int partno;
/* Change which partition? */
if (p == NULL) {
+ memset(buf, 0, sizeof(buf));
+ pp = lp-d_partitions[0];
+ for (partno = 0; partno MAXPARTITIONS; partno++, pp++) {
+ if (mountpoints[partno] == NULL
+ partno != RAW_PART
+ FS_ALLOWS_NAME(pp-p_fstype)) {
+ buf[0] = partno + 'a';
+ break;
+ }
+ }
p = getstring(partition to name,
- The letter of the partition to name, a - p., NULL);
+ The letter of the partition to name, a - p., buf);
}
if (p == NULL) {
fputs(Command aborted\n, stderr);
@@ -958,9 +969,7 @@ editor_name(struct disklabel *lp, char *
}
/* Not all fstypes can be named */
- if (pp-p_fstype == FS_UNUSED || pp-p_fstype == FS_SWAP ||
- pp-p_fstype == FS_BOOT || pp-p_fstype == FS_OTHER ||
- pp-p_fstype == FS_RAID) {
+ if (!FS_ALLOWS_NAME(pp-p_fstype)) {
fprintf(stderr, You cannot name a filesystem of type %s.\n,
fstypenames[lp-d_partitions[partno].p_fstype]);
return;
@@ -2166,9 +2175,7 @@ get_mp(struct disklabel *lp, int partno)
char *p;
int i;
- if (fstabfile pp-p_fstype != FS_UNUSED
- pp-p_fstype != FS_SWAP pp-p_fstype != FS_BOOT
- pp-p_fstype != FS_OTHER) {
+ if (fstabfile FS_ALLOWS_NAME(pp-p_fstype)) {
for (;;) {
p = getstring(mount point,
Where to mount this filesystem (ie: / /var /usr),
Re: mirrorlist file proposal
Eww... See distrib/notes/mirrors and installpath from pkg.conf(5).
Re: syncing libc and libkern
On Wed, Jun 04, 2014 at 08:02:06PM +, Miod Vallat wrote:
First, str{cat,cpy} were vehemently expunged from the kernel many years ago,
so stop trying to keep them around.
Index: lib/libc/Makefile.inc
Hello, this is libc you are butchering in. I'm afraid strcat and strcpy
are still required to be in libc by the current C and POSIX standards.
Yes, that's correct. This doesn't remove str{cat,cpy} from libc
(haha, I wish that were possible), only removes it from the list
of things that are to be copied from libc to libkern.
However, seeing as things are maintained separately (for good
reasons), perhaps copy-to-libkern itself should just be removed
since it's basically pointless at this point and hasn't been
used for about a decade.
syncing libc and libkern
Hello,
This came up when I was looking for the proper place to put code for dealing
with capsicum data structures which need to be handled by both userland and
the kernel.
FreeBSD's libc build system has tentacles that reach over and grab
sys/kern/subr_capability.c. That's not very elegant, I like how
our tree is nicely separated.
It seems the correct thing to do here is to put the shared part in libc,
list the file in KSRCS in lib/libc/Makefile.inc, and make copy-to-libkern.
This allows for only one copy to need to be maintained, and avoids hard
build-time dependency tentacles between lib/ and sys/.
(If this is not correct, let me know what's better.)
Unfortunately, libc and libkern haven't been kept in sync for many years
and I don't see a technical reason why not, so lets bring them together?
First, str{cat,cpy} were vehemently expunged from the kernel many years ago,
so stop trying to keep them around.
Index: lib/libc/Makefile.inc
===
RCS file: /cvs/src/lib/libc/Makefile.inc,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile.inc
--- lib/libc/Makefile.inc 12 May 2014 19:25:16 - 1.19
+++ lib/libc/Makefile.inc 3 Jun 2014 08:09:25 -
@@ -61,8 +61,8 @@ CFLAGS+=-DNLS
LIBKERN= ${LIBCSRCDIR}/../../sys/lib/libkern
-KSRCS= bcmp.c bzero.c ffs.c strcat.c strcmp.c strcpy.c strlen.c strncmp.c \
- strncpy.c strnlen.c htonl.c htons.c ntohl.c ntohs.c timingsafe_bcmp.c
+KSRCS= bcmp.c bzero.c ffs.c strcmp.c strlen.c strncmp.c strncpy.c \
+ strnlen.c htonl.c htons.c ntohl.c ntohs.c timingsafe_bcmp.c
.if (${MACHINE_CPU} != alpha)
KSRCS+=adddi3.c anddi3.c ashldi3.c ashrdi3.c cmpdi2.c divdi3.c
iordi3.c \
lshldi3.c lshrdi3.c moddi3.c muldi3.c negdi2.c notdi2.c qdivrem.c \
Next, __P is dead. Theo just removed the mention of it from style(9), and
this happens to be the last one in libc. It was removed from the libkern
copy 9 years ago, but that change never made it upstream to libc.
Index: lib/libc/quad/qdivrem.c
===
RCS file: /cvs/src/lib/libc/quad/qdivrem.c,v
retrieving revision 1.7
diff -u -p -r1.7 qdivrem.c
--- lib/libc/quad/qdivrem.c 8 Aug 2005 08:05:35 - 1.7
+++ lib/libc/quad/qdivrem.c 3 Jun 2014 08:09:19 -
@@ -51,7 +51,7 @@ typedef unsigned short digit;
typedef u_int digit;
#endif
-static void shl __P((digit *p, int len, int sh));
+static void shl(digit *p, int len, int sh);
/*
* __qdivrem(u, v, rem) returns u/v and, optionally, sets *rem to u%v.
bcmp(3) was cleaned up in libc, but that never propogated to libkern.
While here, remove a comment that doesn't belong in the MI version.
This does change the functionality a bit, but anything relying on undefined
behavior or specific value of non-zero here is fundamentally broken, and
I didn't see anything making such assumptions on a quick grep through sys/.
Index: sys/lib/libkern/bcmp.c
===
RCS file: /cvs/src/sys/lib/libkern/bcmp.c,v
retrieving revision 1.9
diff -u -p -r1.9 bcmp.c
--- sys/lib/libkern/bcmp.c 27 Oct 2009 23:59:35 - 1.9
+++ sys/lib/libkern/bcmp.c 3 Jun 2014 08:11:42 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: bcmp.c,v 1.9 2009/10/27 23:59:35 deraadt Exp $*/
+/* $OpenBSD: bcmp.c,v 1.9 2008/03/19 03:00:23 ray Exp $*/
/*
* Copyright (c) 1987 Regents of the University of California.
@@ -35,23 +35,18 @@
#include lib/libkern/libkern.h
#endif
-/*
- * bcmp -- vax cmpc3 instruction
- */
int
-bcmp(b1, b2, length)
- const void *b1, *b2;
- register size_t length;
+bcmp(const void *b1, const void *b2, size_t length)
{
- register char *p1, *p2;
+ char *p1, *p2;
if (length == 0)
- return(0);
+ return (0);
p1 = (char *)b1;
p2 = (char *)b2;
do
if (*p1++ != *p2++)
- break;
+ return (1);
while (--length);
- return(length);
+ return (0);
}
Index: lib/libc/string/bcmp.c
===
RCS file: /cvs/src/lib/libc/string/bcmp.c,v
retrieving revision 1.9
diff -u -p -r1.9 bcmp.c
--- lib/libc/string/bcmp.c 19 Mar 2008 03:00:23 - 1.9
+++ lib/libc/string/bcmp.c 3 Jun 2014 08:11:42 -
@@ -35,9 +35,6 @@
#include lib/libkern/libkern.h
#endif
-/*
- * bcmp -- vax cmpc3 instruction
- */
int
bcmp(const void *b1, const void *b2, size_t length)
{
{h,n}to{n,h}{l,s} and bswap32 have been broken up into different files in libc,
but I'm not sure how to properly break that up into MI/MD components for libkern
and include it in the right places without breaking anything, does somebody else
want to take a look?
Also, for future reference, would these patches be preferred in separate emails?
Re: USB suspend/resume race
On 26/05/14(Mon) 13:46, Martin Pieuchot wrote: I'd appreciate if people having troubles with suspend/resume could try this diff an report back. Fixes it for me! :D Many thanks. Previous diff was lacking the header chunk, please use this one instead. Was the corresponding commit missing the ehci.c changes from this diff on purpose?
gettytab(5) typo fix (and clearing console on (auto-)logout)
Found while trying to figure out how to be sure the console is always cleared at logout (and the resulting login prompt seemed like a pretty guaranteed-to-always-work place). If you have a cleaner way, perhaps one that is actually at logout and doesn't involve missing all the startup messages due to clearing right after them (and is just as reliable, and preferably just requires changing config files, not source), then by all means, please let me know. For now I've just added cl=\033[2J\033[;H to my gettytab's default entry, and it does more or less what I want. For the archives: I'm doing this in conjuction with ksh's TMOUT option. See ksh(1). Also note that I'm doing this for consoles (Ctrl+Meta+number) (not X11) which I find myself frequently forgetting I am logged into when I suspend my laptop (which auto-locks X, among other things). Relevant: http://marc.info/?t=11903938652 Index: gettytab.5 === RCS file: /cvs/src/libexec/getty/gettytab.5,v retrieving revision 1.22 diff -u -p -r1.22 gettytab.5 --- gettytab.5 10 Dec 2013 20:56:59 - 1.22 +++ gettytab.5 23 May 2014 10:15:22 - @@ -79,7 +79,7 @@ table. .It c2 Ta num Ta unused Ta TTY control flags to leave terminal as. .It ce Ta bool Ta false Ta Use CRT erase algorithm. .It ck Ta bool Ta false Ta Use CRT kill algorithm. -.It cl Ta str Ta Dv NULL Ta Screen clear sequence. +.It cl Ta str Ta Dv NULL Ta Screen clear sequence. .It co Ta bool Ta false Ta Console; add .Ql \en after login prompt.
Re: PATCH: acpibat - expose capacity as sensor
todd, can you put this in snaps so that we know if there's some fallout? I don't know if this is related or not, but running that snap I experienced the following crash while trying to shut down: (which I've never had before) http://i.imgur.com/4YFzdv0.jpg http://i.imgur.com/KR1hWtT.jpg http://i.imgur.com/yjaMsW4.jpg Unfortunately I forgot to trace the other cpus :( Probably not terribly helpful, but I thought I'd send it just in case. hw.sensors.cpu0.temp0=52.00 degC hw.sensors.cpu1.temp0=52.00 degC hw.sensors.cpu2.temp0=52.00 degC hw.sensors.cpu3.temp0=52.00 degC hw.sensors.acpitz0.temp0=59.00 degC (zone temperature) hw.sensors.acpibtn0.indicator0=On (lid open) hw.sensors.acpibat0.volt0=14.80 VDC (voltage) hw.sensors.acpibat0.volt1=16.40 VDC (current voltage) hw.sensors.acpibat0.power0=0.00 W (rate) hw.sensors.acpibat0.watthour0=40.49 Wh (last full capacity) hw.sensors.acpibat0.watthour1=2.02 Wh (warning capacity) hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat0.watthour3=40.02 Wh (remaining capacity), OK hw.sensors.acpibat0.raw0=0 (battery idle), OK hw.sensors.acpiac0.indicator0=On (power supply) hw.sensors.acpithinkpad0.fan0=3669 RPM hw.sensors.softraid0.drive0=online (sd1), OK OpenBSD 5.5-current (GENERIC.MP) #136: Mon May 19 09:40:42 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8255741952 (7873MB) avail mem = 8027213824 (7655MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (69 entries) bios0: vendor LENOVO version G6ET96WW (2.56 ) date 04/29/2013 bios0: LENOVO 3443CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT UEFI SSDT DBG2 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1896.03 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.69 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.69 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.69 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1, PSS acpicpu2 at acpi0: C2, C1, PSS acpicpu3 at acpi0: C2, C1, PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 acpitz0 at acpi0: critical temperature is 200 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 45N1071 serial 695 type LiP oem SMP acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 cpu0: Enhanced SpeedStep 1896 MHz: speeds: 2001, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core
make kernel build with EHCI_DEBUG
There are a bunch of nearby printfs which start with : ... without a devname. I'm not sure which one is preferred, so here's both ways. Index: ehci_cardbus.c === RCS file: /cvs/src/sys/dev/cardbus/ehci_cardbus.c,v retrieving revision 1.17 diff -u -p -r1.17 ehci_cardbus.c --- ehci_cardbus.c 15 Apr 2013 09:23:00 - 1.17 +++ ehci_cardbus.c 16 May 2014 17:47:18 - @@ -130,7 +130,7 @@ ehci_cardbus_attach(struct device *paren /* Disable interrupts, so we don't get any spurious ones. */ sc-sc.sc_offs = EREAD1(sc-sc, EHCI_CAPLENGTH); - DPRINTF((: offs=%d, devname, sc-sc.sc_offs)); + DPRINTF((%s: offs=%d, devname, sc-sc.sc_offs)); EOWRITE2(sc-sc, EHCI_USBINTR, 0); sc-sc_ih = cardbus_intr_establish(cc, cf, ca-ca_intrline, Index: ehci_cardbus.c === RCS file: /cvs/src/sys/dev/cardbus/ehci_cardbus.c,v retrieving revision 1.17 diff -u -p -r1.17 ehci_cardbus.c --- ehci_cardbus.c 15 Apr 2013 09:23:00 - 1.17 +++ ehci_cardbus.c 16 May 2014 18:05:38 - @@ -130,7 +130,7 @@ ehci_cardbus_attach(struct device *paren /* Disable interrupts, so we don't get any spurious ones. */ sc-sc.sc_offs = EREAD1(sc-sc, EHCI_CAPLENGTH); - DPRINTF((: offs=%d, devname, sc-sc.sc_offs)); + DPRINTF((: offs=%d, sc-sc.sc_offs)); EOWRITE2(sc-sc, EHCI_USBINTR, 0); sc-sc_ih = cardbus_intr_establish(cc, cf, ca-ca_intrline,
Re: malloc in libssl/src/apps
On Mon, May 05, 2014 at 07:31:34PM +1000, Joel Sing wrote: This one is calloc, not reallocarray, so unless I'm seriously missing something obvious here, it is indeed zero'd, no? Run the following before and after your change: Ah, yep. Can't believe I missed that (along with all the other obvious errors). I'm an idiot and this patch is full of shit, please ignore it completely. I'll go back to stuff I actually can do, and I'll be sure to read / test my changes while not half asleep before sending them in the future. Thanks to all for the feedback, and sorry for the noise.
Re: malloc in libssl/src/apps
On Sun, May 04, 2014 at 12:17:16PM -0600, Theo de Raadt wrote:
We are going to completely ignore diffs which change multiple idioms
at once.
Okay.
That is how mistakes get made.
Yep, more true than I realized.
Here's a simpler one:
Index: apps.c
===
RCS file: /cvs/src/lib/libssl/src/apps/apps.c,v
retrieving revision 1.45
diff -u -p -r1.45 apps.c
--- apps.c 3 May 2014 16:03:54 - 1.45
+++ apps.c 4 May 2014 19:35:59 -
@@ -209,13 +209,10 @@ chopup_args(ARGS * arg, char *buf, int *
*argc = 0;
*argv = NULL;
- i = 0;
if (arg-count == 0) {
arg-count = 20;
- arg-data = (char **)malloc(sizeof(char *) * arg-count);
+ arg-data = calloc(arg-count, sizeof(char *));
}
- for (i = 0; i arg-count; i++)
- arg-data[i] = NULL;
num = 0;
p = buf;
@@ -232,8 +229,7 @@ chopup_args(ARGS * arg, char *buf, int *
if (num = arg-count) {
char **tmp_p;
int tlen = arg-count + 20;
- tmp_p = (char **) realloc(arg-data,
- sizeof(char *) * tlen);
+ tmp_p = reallocarray(arg-data, tlen, sizeof(char *));
if (tmp_p == NULL)
return 0;
arg-data = tmp_p;
@@ -1836,9 +1832,9 @@ parse_name(char *subject, long chtype, i
* only become shorter */
char *buf = malloc(buflen);
size_t max_ne = buflen / 2 + 1; /* maximum number of name elements */
- char **ne_types = malloc(max_ne * sizeof(char *));
- char **ne_values = malloc(max_ne * sizeof(char *));
- int *mval = malloc(max_ne * sizeof(int));
+ char **ne_types = reallocarray(NULL, max_ne, sizeof(char *));
+ char **ne_values = reallocarray(NULL, max_ne, sizeof(char *));
+ int *mval = reallocarray(NULL, max_ne, sizeof(int));
char *sp = subject, *bp = buf;
int i, ne_num = 0;
Index: ca.c
===
RCS file: /cvs/src/lib/libssl/src/apps/ca.c,v
retrieving revision 1.48
diff -u -p -r1.48 ca.c
--- ca.c2 May 2014 17:06:46 - 1.48
+++ ca.c4 May 2014 19:36:00 -
@@ -2002,8 +2002,8 @@ again2:
row[DB_type][0] = 'V';
row[DB_type][1] = '\0';
- if ((irow = (char **)malloc(sizeof(char *) * (DB_NUMBER + 1))) ==
- NULL) {
+ irow = reallocarray(NULL, DB_NUMBER + 1, sizeof(char *));
+ if (irow == NULL) {
BIO_printf(bio_err, Memory allocation failure\n);
goto err;
}
@@ -2267,8 +2267,8 @@ do_revoke(X509 * x509, CA_DB * db, int t
row[DB_type][0] = 'V';
row[DB_type][1] = '\0';
- if ((irow = (char **)malloc(sizeof(char *) *
- (DB_NUMBER + 1))) == NULL) {
+ irow = reallocarray(NULL, DB_NUMBER + 1, sizeof(char *));
+ if (irow == NULL) {
BIO_printf(bio_err, Memory allocation failure\n);
goto err;
}
Index: ecparam.c
===
RCS file: /cvs/src/lib/libssl/src/apps/ecparam.c,v
retrieving revision 1.10
diff -u -p -r1.10 ecparam.c
--- ecparam.c 24 Apr 2014 12:22:22 - 1.10
+++ ecparam.c 4 May 2014 19:36:00 -
@@ -312,7 +312,7 @@ bad:
crv_len = EC_get_builtin_curves(NULL, 0);
- curves = malloc((int) (sizeof(EC_builtin_curve) * crv_len));
+ curves = reallocarray(NULL, crv_len, sizeof(EC_builtin_curve));
if (curves == NULL)
goto end;
Index: speed.c
===
RCS file: /cvs/src/lib/libssl/src/apps/speed.c,v
retrieving revision 1.38
diff -u -p -r1.38 speed.c
--- speed.c 2 May 2014 17:06:46 - 1.38
+++ speed.c 4 May 2014 19:36:00 -
@@ -2178,7 +2178,7 @@ do_multi(int multi)
int *fds;
static char sep[] = :;
- fds = malloc(multi * sizeof *fds);
+ fds = reallocarray(NULL, multi, sizeof(int));
for (n = 0; n multi; ++n) {
if (pipe(fd) == -1) {
fprintf(stderr, pipe failure\n);
Index: srp.c
===
RCS file: /cvs/src/lib/libssl/src/apps/srp.c,v
retrieving revision 1.10
diff -u -p -r1.10 srp.c
--- srp.c 24 Apr 2014 12:22:22 - 1.10
+++ srp.c 4 May 2014 19:36:00 -
@@ -176,7 +176,8 @@ update_index(CA_DB * db, BIO * bio, char
char **irow;
int i;
- if ((irow = (char **) malloc(sizeof(char *) * (DB_NUMBER + 1))) ==
NULL) {
+ irow = reallocarray(NULL, DB_NUMBER + 1,
Re: malloc in libssl/src/apps
On Sun, May 04, 2014 at 11:30:40PM +0200, Alexander Hall wrote: NULL theoretically could be != 0 Umm... short of something like: #undef NULL #define NULL I'm silly and want to break everything or something, I don't see when that'd be the case. According to ISO/IEC 9899:1999 TC3 (n1256) and the freely available draft of ISO/IEC 9899:201x (n1570), section 6.3.2.3, paragraph 3: [1] An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. So while it might not be cast to a pointer, it's still zero. And for what it's worth, POSIX does define it to be (void *)0 [2] The stddef.h header shall define the following macros: NULL Null pointer constant. The macro shall expand to an integer constant expression with the value 0 cast to type void *. [1] http://www.iso-9899.info/n1256.html#6.3.2.3p3 [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stddef.h.html Did I miss something again?
Re: malloc in libssl/src/apps
On Mon, May 05, 2014 at 11:12:00AM +1000, Joel Sing wrote:
- i = 0;
if (arg-count == 0) {
arg-count = 20;
- arg-data = (char **)malloc(sizeof(char *) * arg-count);
+ arg-data = calloc(arg-count, sizeof(char *));
}
- for (i = 0; i arg-count; i++)
- arg-data[i] = NULL;
This one is a change in behaviour - if arg-count is 0 then previously we
zeroed arg-data; now we do not.
This one is calloc, not reallocarray, so unless I'm seriously missing
something obvious here, it is indeed zero'd, no?
warning building libcrypto on amd64
Hello,
When building libcrypto on amd64 I get this warning:
(cd /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/md5 ; /usr/bin/perl
./asm/md5-x86_64.pl openbsd-elf) md5-x86_64.S
Use of uninitialized value $output in pattern match (m//) at
./asm/md5-x86_64.pl line 115.
Admittedly it's been a while since I've used perl for more than one-liners,
so there may be a better solution.
Index: md5-x86_64.pl
===
RCS file: /cvs/src/lib/libssl/src/crypto/md5/asm/md5-x86_64.pl,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 md5-x86_64.pl
--- md5-x86_64.pl 13 Apr 2014 15:16:34 - 1.1.1.3
+++ md5-x86_64.pl 25 Apr 2014 07:33:06 -
@@ -112,7 +112,7 @@ my $flavour = shift;
my $output = shift;
if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
-my $win64=0; $win64=1 if ($flavour =~ /[nm]asm|mingw64/ || $output =~
/\.asm$/);
+my $win64=0; $win64=1 if ($flavour =~ /[nm]asm|mingw64/ || (defined $output
$output =~ /\.asm$/));
$0 =~ m/(.*[\/\\])[^\/\\]+$/; my $dir=$1; my $xlate;
( $xlate=${dir}x86_64-xlate.pl and -f $xlate ) or
Re: libssl/src/apps don't cast {m,re}alloc
This doesn't fix the problems, only removes markers alerting us to audit it.
Memory management in these files is still missing integer overflow checks,
NULL return checks, and is full of crazy abominations like:
X509_NAME *
parse_name(char *subject, long chtype, int multirdn)
{
size_t buflen = strlen(subject) + 1;/* ...
char *buf = malloc(buflen);
size_t max_ne = buflen / 2 + 1; /* maximum number of name elements */
char **ne_types = malloc(max_ne * sizeof(char *));
char **ne_values = malloc(max_ne * sizeof(char *));
int *mval = malloc(max_ne * sizeof(int));
I'm working on a more complete patch which addresses these issues too.
more axeing at openssl
Hi,
Here's more fuel for the OpenSSL fire. Mostly just axeing at ifdefs,
trying to err on the conservitive side.
There's obviously *TONS* more to clean up, but I only had so much time
tonight. :)
BTW, libssl and libcrypto don't currently build because their Makefiles
still include some recently-killed files, and usr.sbin/openssl won't
build because of at least CRYPTO_malloc friends, and probably other
reasons.
Index: apps/apps.c
===
RCS file: /cvs/src/lib/libssl/src/apps/apps.c,v
retrieving revision 1.26
diff -u -p -r1.26 apps.c
--- apps/apps.c 16 Apr 2014 16:34:09 - 1.26
+++ apps/apps.c 17 Apr 2014 07:09:45 -
@@ -112,9 +112,7 @@
#include stdio.h
#include stdlib.h
#include string.h
-#if !defined(OPENSSL_SYSNAME_WIN32) !defined(NETWARE_CLIB)
#include strings.h
-#endif
#include sys/types.h
#include ctype.h
#include errno.h
@@ -141,11 +139,6 @@
#include apps.h
#undef NON_MAIN
-#ifdef _WIN32
-static int WIN32_rename(const char *from, const char *to);
-#define rename(from,to) WIN32_rename((from),(to))
-#endif
-
typedef struct {
const char *name;
unsigned long flag;
@@ -287,44 +280,6 @@ str2fmt(char *s)
return (FORMAT_UNDEF);
}
-#if defined(OPENSSL_SYS_MSDOS) || defined(OPENSSL_SYS_WIN32) ||
defined(OPENSSL_SYS_WIN16) || defined(OPENSSL_SYS_NETWARE)
-void
-program_name(char *in, char *out, int size)
-{
- int i, n;
- char *p = NULL;
-
- n = strlen(in);
- /* find the last '/', '\' or ':' */
- for (i = n - 1; i 0; i--) {
- if ((in[i] == '/') || (in[i] == '\\') || (in[i] == ':')) {
- p = (in[i + 1]);
- break;
- }
- }
- if (p == NULL)
- p = in;
- n = strlen(p);
-
- /* strip off trailing .exe if present. */
- if ((n 4) (p[n - 4] == '.')
- ((p[n - 3] == 'e') || (p[n - 3] == 'E'))
- ((p[n - 2] == 'x') || (p[n - 2] == 'X'))
- ((p[n - 1] == 'e') || (p[n - 1] == 'E')))
- n -= 4;
-
- if (n size - 1)
- n = size - 1;
-
- for (i = 0; i n; i++) {
- if ((p[i] = 'A') (p[i] = 'Z'))
- out[i] = p[i] - 'A' + 'a';
- else
- out[i] = p[i];
- }
- out[n] = '\0';
-}
-#else
void
program_name(char *in, char *out, int size)
{
@@ -337,7 +292,6 @@ program_name(char *in, char *out, int si
p = in;
BUF_strlcpy(out, p, size);
}
-#endif
int
chopup_args(ARGS *arg, char *buf, int *argc, char **argv[])
@@ -635,15 +589,6 @@ app_get_pass(BIO *err, char *arg, int ke
BIO_printf(err, Can't open file %s\n, arg +
5);
return NULL;
}
-#if !defined(_WIN32)
- /*
-* Under _WIN32, which covers even Win64 and CE, file
-* descriptors referenced by BIO_s_fd are not inherited
-* by child process and therefore below is not an option.
-* It could have been an option if bss_fd.c was operating
-* on real Windows descriptors, such as those obtained
-* with CreateFile.
-*/
} else if (!strncmp(arg, fd:, 3)) {
BIO *btmp;
i = atoi(arg + 3);
@@ -656,7 +601,6 @@ app_get_pass(BIO *err, char *arg, int ke
/* Can't do BIO_gets on an fd BIO so add a buffering
BIO */
btmp = BIO_new(BIO_f_buffer());
pwdbio = BIO_push(btmp, pwdbio);
-#endif
} else if (!strcmp(arg, stdin)) {
pwdbio = BIO_new_fp(stdin, BIO_NOCLOSE);
if (!pwdbio) {
@@ -2600,196 +2544,8 @@ next_protos_parse(unsigned short *outlen
}
#endif /* !OPENSSL_NO_TLSEXT !OPENSSL_NO_NEXTPROTONEG */
-/*
- * Platform-specific sections
- */
-#if defined(_WIN32)
-# ifdef fileno
-# undef fileno
-# define fileno(a) (int)_fileno(a)
-# endif
-
-# include windows.h
-# include tchar.h
-
-static int
-WIN32_rename(const char *from, const char *to)
-{
- TCHAR *tfrom = NULL, *tto;
- DWORD err;
- int ret = 0;
-
- if (sizeof(TCHAR) == 1) {
- tfrom = (TCHAR *)from;
- tto = (TCHAR *)to;
- }
- else/* UNICODE path */
- {
- size_t i, flen = strlen(from) + 1, tlen = strlen(to) + 1;
- tfrom = (TCHAR *)malloc(sizeof(TCHAR)*(flen + tlen));
- if (tfrom == NULL)
- goto err;
- tto = tfrom + flen;
-#if !defined(_WIN32_WCE) || _WIN32_WCE=101
- if (!MultiByteToWideChar(CP_ACP, 0, from, flen, (WCHAR *)tfrom,
flen))
-#endif
- for (i = 0;i flen;i++)tfrom[i] = (TCHAR)from[i];
-#if
Re: lock(1) timeout message deduplication
Thank you very much for the feedback.
On 3/14/14 9:38 AM, Ingo Schwarze wrote:
According to the sigaction(3) manual, volatile sig_atomic_t would
be better. If i understand correctly, overzealous compilers might
otherwise optimize checks away.
Dammit, of course. I should have caught that.
However, either way is incorrect. There is a race condition.
The ALRM signal may arrive after the if(done), but before the
call to readpassphrase(). Yes, that's narrow, but still.
In that case, the lock utility will sit at the Key: prompt
for good, even though a timeout was requested.
Then you just hit enter at the Key: prompt, and bang,
it says timeout and gives you the shell. Ouch.
Right. That's why I wasn't sure where to place the check.
Now I realize why the entire approach is incorrect.
That said, i consider having a lock(1) utility time out stupid
in the first place. It is conceptually insecure. Would anybody
be opposed to either of the following changes?
1) On timeout and before exiting, send a -HUP signal to the
process group [i.e. kill(0, SIGHUP)]. That way, you get the
terminal back on timeout, but without the login shell still
open.
The following is based on the assumption that you meant session
rather than process group [i.e. kill(getsid(), SIGHUP)]:
I don't think we should introduce such behavior because I can think
of several situations where it wouldn't work as expected (like w/
su), and it encourages the user to rely on functionality which has
certain caveats that they would probably ignore or forget, even if
well documented.
The possibility of behaving in unexpected ways is quite dangerous,
especially when you'd only notice after the timeout period,
and even more so when it directly leads to an attacker with a shell.
2) Make -n the default and silently ignore the -t option.
The lock(1) utility still won't become a model of robustness and
security, but at least a bit safer. Right now, it is horribly
insecure by default. Imagine an operator being called away from
the terminal, quickly typing lock. How easy is it to forget -n?
Now if the attacker manages to distract the operator for 15 minutes,
he gets the shell for free.
Well, lock(1) is part of the 2BSD legacy, one of the few tools
remaining from that time. But i think we shouldn't be awestruck
but still ensure a minimum level of sanity.
I'm in favor of that.
Following from that, what would you think of making -p default too
and providing a way to negate it if desired. The thinking is that
an inattentive operator may think to type lock while leaving his
workstation in a hurry, but may not notice or remember to enter a
password (because he is distracted and leaving). If we're going to
break backwards compatibility anyway, this seems like a more sane
default to me.
I certainly don't feel like setting up the usual pipe(2) to self
and a select(2) or poll(2) loop merely to correctly implement a
feature that's an awful idea in the first place...
How about just making the signal handler safe then? I think that's
the simplest approach. I should have tried that to begin with.
Would this do it? (applies on top of my first lock(1) patch
http://marc.info/?l=openbsd-techm=139465495417843q=raw )
--- lock.c.post-patch1 Mon Mar 17 13:10:43 2014
+++ lock.c Mon Mar 17 13:50:53 2014
@@ -61,8 +61,9 @@
#defineTIMEOUT 15
-void bye(int);
-void hi(void);
+void time_remaining(void);
+static size_t sigsafe_strlen(const char *);
+void do_timeout(int);
struct timeval timeout;
struct timeval zerotime;
@@ -165,7 +166,7 @@
(void)signal(SIGINT, SIG_IGN);
(void)signal(SIGQUIT, SIG_IGN);
(void)signal(SIGTSTP, SIG_IGN);
- (void)signal(SIGALRM, bye);
+ (void)signal(SIGALRM, do_timeout);
ntimer.it_interval = zerotime;
ntimer.it_value = timeout;
@@ -186,7 +187,7 @@
for (cnt = 0;;) {
if (!readpassphrase(Key: , s, sizeof(s), RPP_ECHO_OFF) ||
*s == '\0') {
- hi();
+ time_remaining();
continue;
}
if (usemine) {
@@ -220,7 +221,7 @@
}
void
-hi(void)
+time_remaining(void)
{
char buf[1024], buf2[1024];
time_t left;
@@ -237,12 +238,33 @@
(void) write(STDERR_FILENO, buf, strlen(buf));
}
+/*
+ * Duplicate of our libc's strlen. I don't like duplicating code, but POSIX
+ * doesn't guarantee strlen() is signal-safe, so we need to assume it may
+ * become unsafe in the future, maybe due to some crazy hardware-enhanced
+ * optimization that stores state or something...
+ */
+static size_t
+sigsafe_strlen(const char *str)
+{
+ const char *s;
+
+ for (s = str; *s; ++s)
+ ;
+ return (s - str);
+}
+
/*ARGSUSED*/
void
-bye(int signo)
+do_timeout(int signo)
{
+ extern char *__progname;
- if (!no_timeout)
- warnx(timeout);
+
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/12/14 11:15 PM, Loganaden Velvindron wrote: I've read about the file vulnerability, and capsicumization also came to mind. However, there was also a discussion when i was playing with capsicum and openssh, about the limits of capsicum. Capsicum doesn't prevent DoS, and we still need rlimit on FreeBSD in addition to capsicum. Yep, I consider it as an incremental improvement, not a complete solution. I would suggest that you come up with a regression plan to test the demons in base and the most popular one in ports. In this case, unbound was not capsicumised, but the changes made to the kernel affected unbound. I plan to build a src/regress/sys/kern/capsicum as I implement various functionality, but as for other services and such, I'm not sure how best to go about formally testing that. For larger integration-test stuff I generally just throw all my experimental code on all my production boxes and watch what happens. The more people who use those services the better because if something is broken I'll find out earlier and I can fix it. That's also the impression I got of how the pre-release testing cycle seems to work here. Also, please look into FreeBSD's regression test suite for capsicum. I'm aware of: http://svnweb.freebsd.org/base/head/tools/regression/security/cap_test/ http://svnweb.freebsd.org/base/head/tools/regression/capsicum/ https://github.com/google/capsicum-test is there something else? Good testing coverage is also very important Agreed. There's going to be a lot of follow-up to do. I would suggest that you contact the maintainers and see who is interested in getting capsicum into their demon. The response may be varied. I was going to wait until it's at a usable state before I solicit effort from others, otherwise it's just pointless discussion, but yes, that's the plan. In the mean time, I'll just shut up and hack. The patches will probably be peer reviewed by many people, as capsicum touches different areas of the kernel. This process will take time. Naturally. I'd expect nothing less! :)
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/13/14 2:39 AM, Loganaden Velvindron wrote: I'm not a mentor, but I'd be happy to help you in any way I can. You can send mails to tech@ for testing your diffs. Any chance you'd like to review my bootloader patch from last month then? http://marc.info/?l=openbsd-techm=139408992902933 I still haven't gotten any feedback. What I'm referring to here is that some developers are interested in capsicum, and others are less interested. If you plan on working on capsicum on say ntpd, then it would help to contact the maintainer of ntp and see if he's interested. If he is, then you can put it on your workplan for your gsoc. It doesn't help much if there is no interest in merging the code upstream IMHO. Please see this discussion for opensmtpd: https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html I see. OpenNTPD was actually one of the services I hilighted as a potentially good candidate in the short proposal thing I submitted as google's requirement. I hope that you will stick around after the gsoc :-) Oh, I've been around a while, mostly just lurking, and I don't plan on going anywhere. The question is more about finding time to contribute.
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/13/14 3:18 AM, Loganaden Velvindron wrote: On 3/13/14 10:57 AM, Jean-Philippe Ouellet wrote: On 3/13/14 2:39 AM, Loganaden Velvindron wrote: I'm not a mentor, but I'd be happy to help you in any way I can. You can send mails to tech@ for testing your diffs. Any chance you'd like to review my bootloader patch from last month then? I'm not a committer, but I can test your diff once I get back home. I have a sparc64 machine. It needs to powered on. Your best bet is asking a guy who hacks on Sparc64. Check out the commit logs to see who last hacked on that area. Ofwboot hasn't had many substantive changes in years. There was the early entropy stuff, PIE stuff, and some minor cleanups, but otherwise it's just been left alone. (as it should IMO. it's minimal and that's what I want. I consider this patch to reduce the complexity of the required booting infrastructure in general, as it eliminates the need for more daemons and stuff on your lan.) I was wondering whether I should bug kettenis@ about it since AFAIK he's the main sparc64 guy, but the part that I think maybe should change before it's considered for OKs is the ugly (although I'm pretty sure correct) NFS URL parsing code, which really anybody could look at as it isn't hardware-specific. Is it considered rude to bug specific people about patches? I assumed someone would step forward if they were interested, and if nobody was interested, then it didn't belong in the tree. I see. OpenNTPD was actually one of the services I hilighted as a potentially good candidate in the short proposal thing I submitted as google's requirement. Is that proposal available online ? No, but it didn't contain anything I haven't said in some form on tech@ by now anyway, except for the Provide a schedule estimate with dates and important milestones in two week increments. which I'm sure wasn't accurate anyway. signature.asc Description: OpenPGP digital signature
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/12/14 4:58 AM, tuchalia wrote: Hi all, I'm really interested in this possibility of porting the Capsicum framework to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or only work in the kernel implementation? I've used Capsicum during the last summer, but I only worked with the syscall API, that is, no Casper (something that can be fixed quickly). I know what I should I do with the Capsicum side (in the matter of getting some info to have a strong proposal) but I'm not sure about where to look when it comes to the OpenBSD side. Should I take a look at the process data structure, and how all this is implemented in the kernel? Should I take a look somewhere else? Also, do we have any IRC channel to discuss al this? Many thanks, I'm also interested in porting Capsicum, although so far all my emails about it have been off-list. I've already been in contact with dempsky@ (one of the listed mentors, and has previously done some work towards porting it) since before the OpenBSD Foundation announced it was applying for GSoC, and I submitted my application to Google when applications opened on the 10th. Hopefully I'll get accepted. If we both get accepted I think that could work well too, there's certainly enough work to do. We should just plan out what exactly we're each going to do to avoid stepping on each others' toes too much. Thankfully the API is already well defined thanks to FreeBSD so cooperating on different parts should be pretty easy, and it'd be nice to have another dedicated person to peer-review patches with.
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/12/14 4:58 AM, tuchalia wrote: Also, do we have any IRC channel to discuss al this? I've been wondering about that too, although I was never really active on any of the channels. Mindcry is dead, subcult is mostly non-english, freenode and efnet are mostly whiners. I vaguely remember something about silc, but if the unmaintained client is anything to judge by, that's dead now too. I don't mean to intrude, but I am curious where things happen now.
lock(1) timeout message deduplication
Hello,
When lock(1) receives SIGINT, SIGQUIT, or SIGTSTP, it calls hi()
twice, once because it's the signal handler, and once after
readpassphrase() errors because the read was interrupted.
Since hi() gets called when readpassphrase() fails anyway, this
patch ignores the signals instead of using hi() as a handler.
=== behavior before ===
$ lock
Key: [foo\n]
Again: [foo\n]
lock: /dev/ttyp0 on netboot.realconnect.net. timeout in 15 minutes
time now is Wed Mar 12 15:46:49 2014
Key: [asdf\n]
Key: [\n]
lock: type in the unlock key. timeout in 14:53 minutes
Key: [^C]
lock: type in the unlock key. timeout in 14:52 minutes
lock: type in the unlock key. timeout in 14:52 minutes
Key: [foo\n]
=== behavior after ===
$ obj/lock
Key: [foo\n]
Again: [foo\n]
lock: /dev/ttyp0 on netboot.realconnect.net. timeout in 15 minutes
time now is Wed Mar 12 15:47:03 2014
Key: [asdf\n]
Key: [\n]
lock: type in the unlock key. timeout in 14:54 minutes
Key: [^C]
lock: type in the unlock key. timeout in 14:53 minutes
Key: [foo\n]
Index: lock.c
===
RCS file: /cvs/src/usr.bin/lock/lock.c,v
retrieving revision 1.27
diff -u -p -r1.27 lock.c
--- lock.c 22 Aug 2013 04:43:40 - 1.27
+++ lock.c 12 Mar 2014 19:59:48 -
@@ -62,7 +62,7 @@
#defineTIMEOUT 15
void bye(int);
-void hi(int);
+void hi(void);
struct timeval timeout;
struct timeval zerotime;
@@ -162,9 +162,9 @@ main(int argc, char *argv[])
}
/* set signal handlers */
- (void)signal(SIGINT, hi);
- (void)signal(SIGQUIT, hi);
- (void)signal(SIGTSTP, hi);
+ (void)signal(SIGINT, SIG_IGN);
+ (void)signal(SIGQUIT, SIG_IGN);
+ (void)signal(SIGTSTP, SIG_IGN);
(void)signal(SIGALRM, bye);
ntimer.it_interval = zerotime;
@@ -186,7 +186,7 @@ main(int argc, char *argv[])
for (cnt = 0;;) {
if (!readpassphrase(Key: , s, sizeof(s), RPP_ECHO_OFF) ||
*s == '\0') {
- hi(0);
+ hi();
continue;
}
if (usemine) {
@@ -219,9 +219,8 @@ main(int argc, char *argv[])
exit(0);
}
-/*ARGSUSED*/
void
-hi(int signo)
+hi(void)
{
char buf[1024], buf2[1024];
time_t left;
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/12/14 4:58 AM, tuchalia wrote: Should l try to port also the Casper daemon to OpenBSD, or only work in the kernel implementation? Based on more private mail, I figured it'd be a good idea to make what I plan to work on public in case there are others interested so we can avoid stepping on each others' toes. I've been told that the OpenBSD project's main objective in supporting capsicum is to have stronger privsep in our default services (think ssh, etc.) and the first steps to support that are the relevant kernel changes, therefore that's what I plan to work on first. I wasn't planning on doing anything with casper, user angels, etc. and even porting libcapsicum was a 2ndary objective, at least not during this summer. There's also a ton of userland things besides daemons/services that could (probably should) be capsicumized. Just yesterday there was just a vuln reported by the debian folks in their file(1) that potentially allowed arbitrary code execution. I immediately checked our implementation and didn't see the same code that was patched, but our src/usr.bin/file/softmagic.c still contains a ton of logic which probably has at least one bug somewhere, and file(1) should be a fairly easily capsicumizable utility. Userland capsicumization is something that could very easily be done by multiple people since it's naturally separated into small chunks (per utility). I planned to focus on getting the primary kernel infrastructure in place this summer (because it's a somewhat large project, and it would definitely help to be sponsored by Google so I can focus on it) and then it'd be easier to work on userland stuff in small chunks of free time throughout the next school year. The reason I really want to work on Capsicum is because it addresses my primary concern with OpenBSD: the poor availability of post-exploit mitigation techniques, especially post-parallelism with sysjail. I haven't completely bought into what appears to me to be Robert Watson's greater vision of a realistic transition path towards capability-oriented operating systems, I mostly just want to improve the tools I use every day.
Re: lock(1) timeout message deduplication
On Wed, Mar 12, 2014 at 11:09:14PM +0100, Ingo Schwarze wrote:
I don't really like the warnx(3) call from the bye() ALRM handler
either, but that's a separate matter.
Me neither.
Maybe something like this instead? (although maybe the done check should
be someplace else?)
Index: lock.c
===
RCS file: /cvs/src/usr.bin/lock/lock.c,v
retrieving revision 1.27
diff -u -p -r1.27 lock.c
--- lock.c 22 Aug 2013 04:43:40 - 1.27
+++ lock.c 12 Mar 2014 23:02:36 -
@@ -61,13 +61,14 @@
#defineTIMEOUT 15
-void bye(int);
-void hi(int);
+void time_remaining(void);
+void do_timeout(int);
struct timeval timeout;
struct timeval zerotime;
time_t nexttime; /* keep the timeout time */
intno_timeout; /* lock terminal forever */
+sig_atomic_t done;
extern char *__progname;
@@ -162,10 +163,10 @@ main(int argc, char *argv[])
}
/* set signal handlers */
- (void)signal(SIGINT, hi);
- (void)signal(SIGQUIT, hi);
- (void)signal(SIGTSTP, hi);
- (void)signal(SIGALRM, bye);
+ (void)signal(SIGINT, SIG_IGN);
+ (void)signal(SIGQUIT, SIG_IGN);
+ (void)signal(SIGTSTP, SIG_IGN);
+ (void)signal(SIGALRM, do_timeout);
ntimer.it_interval = zerotime;
ntimer.it_value = timeout;
@@ -183,10 +184,15 @@ main(int argc, char *argv[])
__progname, ttynam, hostname, sectimeout, date);
}
- for (cnt = 0;;) {
+ for (cnt = 0, done = 0;;) {
+ if (done) {
+ if (!no_timeout)
+ warnx(timeout);
+ _exit(1);
+ }
if (!readpassphrase(Key: , s, sizeof(s), RPP_ECHO_OFF) ||
*s == '\0') {
- hi(0);
+ time_remaining();
continue;
}
if (usemine) {
@@ -219,9 +225,8 @@ main(int argc, char *argv[])
exit(0);
}
-/*ARGSUSED*/
void
-hi(int signo)
+time_remaining(void)
{
char buf[1024], buf2[1024];
time_t left;
@@ -240,10 +245,7 @@ hi(int signo)
/*ARGSUSED*/
void
-bye(int signo)
+do_timeout(int signo)
{
-
- if (!no_timeout)
- warnx(timeout);
- _exit(1);
+ done = 1;
}
Re: [patch] sparc64 ofwboot.net manual config
Based on the number of commits today, I'm going to go ahead and guess the tree was unlocked from release mode. Does anybody want to take a look at this now? I think it may be a good idea to refactor the URL parsing code to be easier to read, follow, and reason about. There are many ways I could do it, but I'm not sure what the cleanest approach would be. Any feedback is much appreciated. Original message with patch: http://marc.info/?l=openbsd-techm=139208386213686q=raw On 2/10/14 8:57 PM, Jean-Philippe Ouellet wrote: Hello, I patched the sparc64 bootloader to allow users to manually specify network config and where to load the kernel from via openfirmware parameters instead of always requiring rarp/bootparams/bootp. This enables remote bootstrapping of semi-recent sun boxes (like the T1000) on networks where you are unable to set up the required daemons. With this patch, the only thing required to bootstrap a server with blank disks is access to the remote management port, any tftp server to serve ofwboot.net, and any nfs server to serve the kernel. I'm not the first one to want to be able to do this, and I tried to make it behave as users expect: http://marc.info/?t=13712989785 Historically it made sense for ofwboot to assume the user already has the relevant daemons on the network because they were required to get ofwboot loaded in the first place, but at some point sun's firmware allowed people to specify network config and a tftp server/file to load. So, for newer machines all the daemons are an artificial requirement imposed only by OpenBSD's ofwboot. If someone happens to have a variety of sun hardware laying around, I'm particularly interested in the format and availability of the /options/network-boot-arguments ofw property across different firmware versions. I expect only newer boxes to have it at all; older ones still require rarp friends to load ofwboot in the first place, so these changes shouldn't affect them. I know you guys are busy with all the other stuff you're trying to fit in before 5.5, but if someone does find some time to test this and/or give some feedback it'd be much appreciated. This patch also includes various style(9), alphabetizing, and whitespace changes which are unrelated to the netbooting logic. I could put them in a separate diff if it helps. Patch stripped cause it's long, and the mail client I'm at right now tries to be too smart with long lines and screws up the formatting. original message at http://marc.info/?l=openbsd-techm=139208386213686
[patch] sparc64 ofwboot.net manual config
Hello,
I patched the sparc64 bootloader to allow users to manually specify
network config and where to load the kernel from via openfirmware
parameters instead of always requiring rarp/bootparams/bootp.
This enables remote bootstrapping of semi-recent sun boxes (like
the T1000) on networks where you are unable to set up the required
daemons. With this patch, the only thing required to bootstrap a
server with blank disks is access to the remote management port,
any tftp server to serve ofwboot.net, and any nfs server to serve
the kernel.
I'm not the first one to want to be able to do this, and I tried
to make it behave as users expect: http://marc.info/?t=13712989785
Historically it made sense for ofwboot to assume the user already
has the relevant daemons on the network because they were required
to get ofwboot loaded in the first place, but at some point sun's
firmware allowed people to specify network config and a tftp
server/file to load. So, for newer machines all the daemons are an
artificial requirement imposed only by OpenBSD's ofwboot.
If someone happens to have a variety of sun hardware laying around,
I'm particularly interested in the format and availability of the
/options/network-boot-arguments ofw property across different
firmware versions. I expect only newer boxes to have it at all;
older ones still require rarp friends to load ofwboot in the first
place, so these changes shouldn't affect them.
I know you guys are busy with all the other stuff you're trying to
fit in before 5.5, but if someone does find some time to test this
and/or give some feedback it'd be much appreciated.
This patch also includes various style(9), alphabetizing, and
whitespace changes which are unrelated to the netbooting logic. I
could put them in a separate diff if it helps.
Index: share/man/man8/man8.sparc64/boot_sparc64.8
===
RCS file: /cvs/src/share/man/man8/man8.sparc64/boot_sparc64.8,v
retrieving revision 1.13
diff -u -p -r1.13 boot_sparc64.8
--- share/man/man8/man8.sparc64/boot_sparc64.8 3 Jan 2010 16:43:46 -
1.13
+++ share/man/man8/man8.sparc64/boot_sparc64.8 11 Feb 2014 00:39:13 -
@@ -105,6 +105,26 @@ as soon as the kernel console has been i
Boot the system single-user.
The system will be booted multi-user unless this option is specified.
.El
+.Ss Specifying netboot configuration
+An alternative to setting up all the daemons described in
+.Xr diskless 8
+is to manually specify your configuration via
+.Tn Open Firmware
+parameters.
+To make this work, set the
+.Va host-ip ,
+.Va router-ip ,
+and
+.Va subnet-mask
+fields in the
+.Va network-boot-arguments
+parameter, and use an NFS URL of form
+.Pp
+.Dl nfs://1.2.3.4//var/nfs/bsd.rd -options
+.Pp
+as the
+.Va boot-file
+parameter.
.Ss Accessing the PROM during runtime
If the
.Xr sysctl 8
@@ -144,8 +164,9 @@ secondary bootstrap (usually also instal
network bootstrap
.El
.Sh SEE ALSO
-.Xr ddb 4 ,
.Xr boot_config 8 ,
+.Xr ddb 4 ,
+.Xr diskless 8 ,
.Xr halt 8 ,
.Xr init 8 ,
.Xr installboot 8 ,
Index: sys/arch/sparc64/stand/libsa/Makefile
===
RCS file: /cvs/src/sys/arch/sparc64/stand/libsa/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- sys/arch/sparc64/stand/libsa/Makefile 1 Jan 2013 18:49:33 -
1.9
+++ sys/arch/sparc64/stand/libsa/Makefile 11 Feb 2014 00:39:13 -
@@ -16,8 +16,9 @@ CFLAGS= ${CEXTRAFLAGS} ${AFLAGS} -O2 -D_
CPPFLAGS+= -D__INTERNAL_LIBSA_CREAD
# stand routines
-SRCS= alloc.c exit.c getfile.c gets.c globals.c \
- memcmp.c memcpy.c memset.c printf.c snprintf.c strerror.c strncpy.c
+SRCS= alloc.c exit.c getfile.c gets.c globals.c memcmp.c memcpy.c memset.c \
+ printf.c snprintf.c strchr.c strerror.c strncmp strncpy.c strrchr.c \
+ strsep.c
# io routines
SRCS+= close.c closeall.c dev.c disklabel.c dkcksum.c fstat.c ioctl.c lseek.c \
Index: sys/arch/sparc64/stand/ofwboot/Makefile
===
RCS file: /cvs/src/sys/arch/sparc64/stand/ofwboot/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- sys/arch/sparc64/stand/ofwboot/Makefile 30 Aug 2012 19:29:14 -
1.18
+++ sys/arch/sparc64/stand/ofwboot/Makefile 11 Feb 2014 00:39:13 -
@@ -18,14 +18,14 @@ SRCS= srt0.s Locore.c alloc.c boot.c el
ofdev.c vers.c
.PATH: ${S}/lib/libkern/arch/sparc64 ${S}/lib/libkern
-SRCS+= strlcpy.c strcmp.c strlcat.c strlen.c
+SRCS+= strcmp.c strlcat.c strlcpy.c strlen.c
CWARNFLAGS+= -Wno-main
AFLAGS+= -Wa,-Av9a
AFLAGS+= -x assembler-with-cpp -D_LOCORE -D__ELF__ -fno-pie
CFLAGS+= ${COPTS} -fno-pie
CPPFLAGS+= -D_STANDALONE -DSUN4U -nostdinc
-#CPPFLAGS+=-DNETIF_DEBUG
+#CPPFLAGS+=-DNETIF_DEBUG
BINMODE= 444
Index: sys/arch/sparc64/stand/ofwboot/boot.c
questions about boot-time entropy loading
Hello, While hacking on the sparc64 bootloader (patch in another mail) I had some questions about the recently added super-early entropy loading code. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/stand/ofwboot/boot.c.diff?r1=1.19;r2=1.20 From the commit message: Try to load entropy data from disk:/etc/random.seed Except it doesn't actually load it from disk, it loads it from whatever device you're loading the kernel from (in my case, the network). Other architectures may do the same. There are a few things I'm not sure about: 1) The way it's currently implemented, it causes two separate config-discovery attempts because it does a separate open/close of the device. If you're using bootp, it waits for the bootparams timeout twice, etc. However, I don't see a way to improve this that doesn't increase the complexity of the code too much, so (although it seems silly) perhaps it should stay that way. 2) I suspect that seeding your PRNG with data sent in the clear isn't a great idea in the first place. 3) If you're netbooting anyway, by the time you actually fetch the kernel you've already done a bunch of network operations. Wouldn't timing information from that be safer than some seed sent in the clear? 4) Could just be my lack of understanding, but I'm not sure that serving /etc/random.seed via NFS is a good idea. Wouldn't it need to be the same as the NFS server's? As far as I can tell, exports(5) doesn't allow you to export some arbitrary (not /etc) tree and have it appear to others as /etc. I really don't know what the best thing to do is, but it seems a bit odd in its current state.
Re: [patch] sparc64 ofwboot.net manual config
Here's some documentation of it for www/ I think there should also be some mention of this functionality in diskless(8), but I don't know where to put it, and I don't want to just .Xr it to boot_sparc64 because diskless is for all archs and none of the other boot_*s are referenced. Index: sparc64.html === RCS file: /cvs/www/sparc64.html,v retrieving revision 1.356 diff -u -p -r1.356 sparc64.html --- sparc64.html1 Nov 2013 21:36:17 - 1.356 +++ sparc64.html11 Feb 2014 01:06:40 - @@ -721,7 +721,12 @@ as well as network and diskless installs the ttbsd.rd/tt standalone miniroot over NFS. Refer to the a href=http://www.openbsd.org/cgi-bin/man.cgi?query=disklessamp;sektion=8;diskless(8)/a - manual page for details on how to setup a network boot environment. + manual page for details on how to setup a network boot environment in + general, and + a href=http://www.openbsd.org/cgi-bin/man.cgi?query=boot_sparc64amp;sektion=8amp;arch=sparc64;boot_sparc64(8)/a + for information about manually specifying network boot options on newer sparc64 + machines in such a way that does not require all the daemons described in + diskless(8). /ul p
ok to kill stdio.h in strsep.c?
It appeared in revision 1.3 (Update from lite2.) It's the only one in the string family that has it, and nothing from it is used. Index: strsep.c === RCS file: /cvs/src/lib/libc/string/strsep.c,v retrieving revision 1.6 diff -u -p -r1.6 strsep.c --- strsep.c8 Aug 2005 08:05:37 - 1.6 +++ strsep.c25 Jan 2014 06:41:18 - @@ -30,7 +30,6 @@ */ #include string.h -#include stdio.h /* * Get next token from string *stringp, where tokens are possibly-empty
NSD manpage in mdoc
A few days ago I saw a commit for NSD, I had never heard of it before, so naturally, I went to read the manpage, however it wasn't there. I looked at the cvs tree, and saw that there was a manpage, just not formatted for mandoc like all other manpages I've seen in OpenBSD, so I read up on mdoc and rewrote the manpage. As this is my first time converting anything from whatever that was (somethingroff?) to mdoc, so I have a few questions about what I did: - Did I handle the ip-addre...@port] argument properly? (I based it off of nc.1's [-x proxy_address[:port]], but Xo and Xc are depreciated so I avoided using them.) - Is Em appropriate for signals? - What should I do to the zonesdir: text? - Is it appropriate to have the license at the top of the manpage like that since there is a LICENSE file in the tree in the same directory as the manpage. - I removed the @version@ stuff found in the original manpage, is there anything I should replace it with? - I removed the options section as I cannot find an example of a new manpage in OpenBSD where there are separate description and options sections, the options seem to just be slapped on to the end of the description, was this the right thing to do? - Is there a way to specify that something is both a path and an argument (for chrootdir in chrootdir/dev/log in the -t description). - Why is -v for version and -V for verbosity instead of the other way around? - Was it correct to use /(hy instead of -? What about in the SEE ALSO section? - Is converting this stuff to mdoc format actually helpful and should I clean the rest of the manpages for NSD or am I wasting my time writing it and your time looking at it? Any enlightenment would be greatly appreciated. Here is my reformatted /src/usr.sbin/nsd/nsd.8 with a few minor grammatical changes: .\ Copyright (c) 2001-2006, NLnet Labs. All rights reserved. .\ .\ This software is open source. .\ .\ Redistribution and use in source and binary forms, with or without .\ modification, are permitted provided that the following conditions .\ are met: .\ .\ Redistributions of source code must retain the above copyright notice, .\ this list of conditions and the following disclaimer. .\ .\ Redistributions in binary form must reproduce the above copyright notice, .\ this list of conditions and the following disclaimer in the documentation .\ and/or other materials provided with the distribution. .\ .\ Neither the name of the NLNET LABS nor the names of its contributors may .\ be used to endorse or promote products derived from this software without .\ specific prior written permission. .\ .\ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS .\ AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED .\ TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR .\ PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE .\ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR .\ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF .\ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS .\ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN .\ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) .\ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE .\ POSSIBILITY OF SUCH DAMAGE. .\ .Dd $Mdocdate$ .Dt NSD 8 .Os .Sh NAME .Nm nsd .Nd Name Server Daemon .Sh SYNOPSIS .Nm .Bk -words .Op Fl 46dhv .Op Fl a Ar ip\(hyaddress Ns Oo Ar @port Oc .Op Fl c Ar configfile .Op Fl f Ar database .Op Fl I Ar nsid .Op Fl i Ar identity .Op Fl l Ar logfile .Op Fl N Ar server\(hycount .Op Fl n Ar noncurrent\(hytcp\(hycount .Op Fl P Ar pidfile .Op Fl p Ar port .Op Fl s Ar seconds .Op Fl t Ar chrootdir .Op Fl u Ar username .Op Fl V Ar level .Ek .Sh DESCRIPTION .Nm is a complete implementation of an authoritative DNS nameserver. Upon startup, .Nm will read the database specified with the .Fl f argument, put itself into the background, and answer queries on port 53 .Po or a different port as specified by .Fl p .Pc . .Ar database must be generated beforehand with .Xr zonec 8 . By default, .Nm will bind to all local interfaces available. Use .Fl a to specify a single particular interface address to be bound. If this option is given more than once, .Nm will bind its UDP and TCP sockets to all the specified ip\(hyaddresses separately. If IPv6 is enabled when .Nm is compiled, an IPv6 address can also be specified. .Pp The options are as follows: .Bl -tag -width Ds .It Fl 4 Only listen to IPv4 connections. .It Fl 6 Only listen to IPv6 connections. .It Fl a Ar ip\(hyaddress Ns Oo Ar @port Oc Listen to the specified .Fl ip\(hyaddress . The .Fl ip\(hyaddress must be specified in numeric format .Pq using the standard IPv4 or IPv6 notation . Optionally, a port number can be given. This flag can be specified multiple times to listen to multiple IP addresses. If
