> On Mon 26/06/2017 14:35, Theo de Raadt wrote:
> > There is a diff in snapshots which does kernel relinking during
> > install or upgrade.
> >
> > Really amazing...
>
> Works as advertised, assuming that compXX is installed. The relinking bit uses
> strip, which is part of the compiler collectio
On Mon, Jun 26, 2017 at 02:35:55PM -0600, Theo de Raadt wrote:
> There is a diff in snapshots which does kernel relinking during
> install or upgrade.
>
> Really amazing...
>
This does sound amazing! Upgrade time
On Mon 26/06/2017 14:35, Theo de Raadt wrote:
> There is a diff in snapshots which does kernel relinking during
> install or upgrade.
>
> Really amazing...
Works as advertised, assuming that compXX is installed. The relinking bit uses
strip, which is part of the compiler collection.
Does it make
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.
>
> It
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
parent/ch
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 reused
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
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
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
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 21:17:
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 appea
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 N
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
tra
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
> ===
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 &
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 soreceive(
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
There is a diff in snapshots which does kernel relinking during
install or upgrade.
Really amazing...
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 s
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
>> > before, where you get a sequen
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
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, otherwis
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 fragments
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 and
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
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 w
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: sys/so
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: /cvs/src/sys/miscfs/fifofs/fifo_vnops.c,
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
===
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
--- miscfs/fifofs/fifo
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 possib
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 PKG
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 miss
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, th
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 of
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 t
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 */
37 matches
Mail list logo
