fifos & kqueue

This is similar to the socket & kqueue diff I just sent. Check for NOTE_SUBMIT hint in order to protect `so_state', `so_snd' and `so_rcv'. ok? Index: miscfs//fifofs/fifo_vnops.c === RCS file:

sblock() & solock() ordering

I'd like to enforce the following "lock" ordering: always hold the socket lock when calling sblock(). This would allow me to protect `so_state' in sosend() when setting the SS_ISSENDING bit. Diff below implements that. It also gets rid of sbsleep() and uses sosleep() instead. ok? Index:

Re: ports framework change: readme and rc generation

On Mon, Jun 26, 2017 at 12:36:16PM +0200, Marc Espie wrote: > I need to get this thru my next bulk. > This should work around several existing issues. > > First, PKGDIR must exist. Creating it during fake is no longer possible, > because this doesn't work with dpb in privsep mode. > > Having

sockets & kqueue

Now that we have a mechanism to check when to lock the socket inside a kqueue filter, let's use it. Diff below protects `so_qlen', `so_state' and `so_snd.sb_lowat' which are accessed in tcp_input(). ok? Index: kern/uipc_socket.c

Re: ports framework change: readme and rc generation

On Mon, Jun 26, 2017 at 01:46:05PM +0200, Landry Breuil wrote: > On Mon, Jun 26, 2017 at 12:36:16PM +0200, Marc Espie wrote: > > I need to get this thru my next bulk. > > This should work around several existing issues. > > > > First, PKGDIR must exist. Creating it during fake is no longer

Re: [PATCH] ffs: always assign random inode generation numbers

On Sun, 25 Jun 2017 14:34:40 -0400, "Ted Unangst" wrote: > will this cause problems if a number repeats? we've seen problems with that > before, where you get a sequence like 4, 7, 4 and then bad things happen. Yes, that is why it currently just increments. A linear congruential generator like

NET_LOCK() -> solock()

The NET_LOCK() is not always required, let solock() decided. ok? Index: miscfs/fifofs/fifo_vnops.c === RCS file: /cvs/src/sys/miscfs/fifofs/fifo_vnops.c,v retrieving revision 1.54 diff -u -p -r1.54 fifo_vnops.c ---

Re: sockets & kqueue

On Mon, 26 Jun 2017 16:07:00 +0200, Martin Pieuchot wrote: > Now that we have a mechanism to check when to lock the socket inside a > kqueue filter, let's use it. > > Diff below protects `so_qlen', `so_state' and `so_snd.sb_lowat' which > are accessed in tcp_input(). One comment inline,

Re: pf fragment drop stale

Hello, On Mon, Jun 26, 2017 at 05:51:08PM +0200, Alexander Bluhm wrote: > On Mon, Jun 26, 2017 at 10:29:24AM +0200, Alexandr Nedvedicky wrote: > > > +#define PF_FRAG_STALE200 /* Limit fragments per second per > > > connection */ > > > I did not get how we arrived to 'Limit

Re: fifos & kqueue

On Mon, 26 Jun 2017 16:09:30 +0200, Martin Pieuchot wrote: > This is similar to the socket & kqueue diff I just sent. > > Check for NOTE_SUBMIT hint in order to protect `so_state', `so_snd' > and `so_rcv'. OK millert@ - todd

Re: pf fragment drop stale

On Mon, Jun 26, 2017 at 10:29:24AM +0200, Alexandr Nedvedicky wrote: > > +#define PF_FRAG_STALE 200 /* Limit fragments per second per > > connection */ > I did not get how we arrived to 'Limit fragments per second per > connection.' Actually I was looking at markus@'s algorithm

Re: [PATCH] ffs: always assign random inode generation numbers

On Mon, 26 Jun 2017 08:50:30 -0600, "Todd C. Miller" wrote: > On Sun, 25 Jun 2017 14:34:40 -0400, "Ted Unangst" wrote: > > > will this cause problems if a number repeats? we've seen problems with that > > before, where you get a sequence like 4, 7, 4 and then bad things happen. > > Yes, that is

Re: [PATCH] ffs: always assign random inode generation numbers

On Mon, Jun 26, 2017 at 5:45 PM, Todd C. Miller wrote: > On Mon, 26 Jun 2017 08:50:30 -0600, "Todd C. Miller" wrote: > >> On Sun, 25 Jun 2017 14:34:40 -0400, "Ted Unangst" wrote: >> >> > will this cause problems if a number repeats? we've seen problems with that >> >

no depends for perl

Probably the most intricate yet. This is not entirely new, since I had to split manpages already a long time ago. The trick is to keep the "Configure stuff" in the main Makefile.bsd-wrapper, and put everything else in Makefile.bsd-wrapper1... I hope I haven't forgotten any small piece, but it

Re: sockets & kqueue

On Mon, Jun 26, 2017 at 10:28:42AM -0600, Todd C. Miller wrote: > On Mon, 26 Jun 2017 16:07:00 +0200, Martin Pieuchot wrote: > > + } else if (((so->so_state & SS_ISCONNECTED) == 0) && > > + (so->so_proto->pr_flags & PR_CONNREQUIRED)) { > > + rv = 0; > > + } if (kn->kn_sfflags &

Re: fifos & kqueue

On Mon, Jun 26, 2017 at 04:09:30PM +0200, Martin Pieuchot wrote: > This is similar to the socket & kqueue diff I just sent. > > Check for NOTE_SUBMIT hint in order to protect `so_state', `so_snd' > and `so_rcv'. > > ok? OK bluhm@ > > Index: miscfs//fifofs/fifo_vnops.c >

kernel relinking at install/upgrade time

There is a diff in snapshots which does kernel relinking during install or upgrade. Really amazing...

[patch] Remove duplicate include in file.c

Remove duplicate include in file.c. - Matthew Martin diff --git file.c file.c index 6304a38c18f..f7a2f56cb64 100644 --- file.c +++ file.c @@ -34,7 +34,6 @@ #include #include #include -#include #include #include #include

Re: pf_purge_thread() w/o KERNEL_LOCK()

On Mon, Jun 26, 2017 at 11:38:35AM +0200, Martin Pieuchot wrote: > The NET_LOCK() is currently what guarantees that accesses to PF data > structures are serialized. So we can drop the KERNEL_LOCK() in the > pf_purge_thread() to reduce contention. > > While here use rwsleep(9) instead of calling

Re: [patch] dhcpd.h

found some more unused #defines Index: dhcpd.h === RCS file: /cvs/src/usr.sbin/dhcpd/dhcpd.h,v retrieving revision 1.64 diff -u -p -u -r1.64 dhcpd.h --- dhcpd.h24 Apr 2017 14:58:36 -1.64 +++ dhcpd.h26 Jun 2017

Re: Remove extra newline from examples in softraid(4) manual

On Tue, Jun 27, 2017 at 12:55:52AM +0300, corsah wrote: > > Hello, > Editor commands for disklabel can be properly terminated with just "q\n" > and do not require the additional newline. The second "\n" was included > when printf replaced echo, which had been adding an extra by default. > It

dhcp-options(5) conflict with dhcpd.conf(5)

I found the following conflict between dhcp-options(5) and dhcpd.conf(5). From dhcpd.conf: As you can see in Example 2, it's legal to specify host addresses in parameters as hostnames rather than as numeric IP addresses. If a given hostname resolves to more than one IP address (for

Re: lock(1): use crypt_checkpass(3) for one-off keys

Scott Cheloha wrote: > Hi, > > Using strcmp(3) to check a password is just asking for a timing > attack. > > I admit that setting up such an attack on a custom lock(1) key at, > say, a physical terminal would be cumbersome, so maybe this is just > paranoia. > > However, passwords *do* get

tweak {event,evtimer,signal}_pending manpage

the timeval argument is not const. esp since thats how the remaining time is provided to the caller. ok? Index: event.3 === RCS file: /cvs/src/lib/libevent/event.3,v retrieving revision 1.52 diff -u -p -r1.52 event.3 --- event.3

lock(1): use crypt_checkpass(3) for one-off keys

Hi, Using strcmp(3) to check a password is just asking for a timing attack. I admit that setting up such an attack on a custom lock(1) key at, say, a physical terminal would be cumbersome, so maybe this is just paranoia. However, passwords *do* get reused all the time, so I think it makes sense

Remove extra newline from examples in softraid(4) manual

Hello, Editor commands for disklabel can be properly terminated with just "q\n" and do not require the additional newline. The second "\n" was included when printf replaced echo, which had been adding an extra by default. It appears that disklabel will even interpret the last command with zero

Re: sblock() & solock() ordering

On Mon, Jun 26, 2017 at 04:15:50PM +0200, Martin Pieuchot wrote: > I'd like to enforce the following "lock" ordering: always hold the > socket lock when calling sblock(). I was already wondering wether the "panic: receive 1" seen by stsp@ may be caused by an additional sleeping point in

Attempt to simplify file(1)

OpenBSD's file(1) implementation was written by nicm@, first introduced in 5.8, the inital design included a privileged parent process which forked an unprivileged child which would handle potentially unsafe file parsing. It also had 'sandboxing' using systrace(4), which required complex

Re: Attempt to simplify file(1)

On Tue, Jun 27, 2017 at 12:26:08AM -0400, Bryan Steele wrote: > OpenBSD's file(1) implementation was written by nicm@, first introduced > in 5.8, the inital design included a privileged parent process which > forked an unprivileged child which would handle potentially unsafe > file parsing. > >

Re: pf fragment drop stale

Hello, looks good to me, though I still need better explanation for PF_FRAG_STALE. The current comment seems bit misleading to me. > #define PFTM_TS_DIFF_VAL 30 /* Allowed TS diff */ > > +#define PF_FRAG_STALE200 /* Limit fragments per second per > connection */

Re: [PATCH] ffs: always assign random inode generation numbers

On Sun, Jun 25, 2017 at 11:21:50PM -0600, Theo de Raadt wrote: On Sun, Jun 25, 2017 at 10:47:08PM -0600, Theo de Raadt wrote: >> :-) Speaking of signed integers, does it really need to be signed? > >Perhaps not. Anyone know for sure? > >Of course this number should probably exclude 0 in it's

Re: Fix possible fault in sysctl_file()

On 20/06/17(Tue) 13:51, Gerhard Roth wrote: > Hi, > > file pointer may be incompletely initialized after falloc(). For example, > sys_socket() initializes 'f_flag', 'f_type', and 'f_ops' but may sleep > then in socreate() before assigning 'f_data'. > > That is why there is the FIF_LARVAL flag,

pf_purge_thread() w/o KERNEL_LOCK()

The NET_LOCK() is currently what guarantees that accesses to PF data structures are serialized. So we can drop the KERNEL_LOCK() in the pf_purge_thread() to reduce contention. While here use rwsleep(9) instead of calling NET_LOCK()/NET_UNLOCK() for every iteration. This way the thread won't go

Intel Microcode bug on Xeon e5V2 when hyperthreading enabled

Hello all, This May be relevant to the Developers working on VMM ... being aware of it may save you some time so as not to waste time on an intel microde bug the following is a quote from https://lists.debian.org/debian-devel/2017/06/msg00308.html This warning advisory is relevant for users

ports framework change: readme and rc generation

I need to get this thru my next bulk. This should work around several existing issues. First, PKGDIR must exist. Creating it during fake is no longer possible, because this doesn't work with dpb in privsep mode. Having PKGDIR not be a directory/pointing in the wrong location means you might