Re: sendsyslog kernel buffer

2021-03-08 Thread Theo de Raadt
Vitaliy Makkoveev wrote: > > On Mon, Mar 08, 2021 at 01:37:51AM +0300, Vitaliy Makkoveev wrote: > >> I wonder they were not buffered. But does it make sense to drop the > >> most recent messages? > > > > The oldest message should be kept. In my experience you get most > > information why

Re: sendsyslog kernel buffer

2021-03-08 Thread Vitaliy Makkoveev
> On 8 Mar 2021, at 23:20, Alexander Bluhm wrote: > > I hope to have addressed all issues. > > On Sun, Mar 07, 2021 at 11:50:24AM +, Visa Hankala wrote: >> This copyin() can also result in copying the buffer from userspace twice. >> This might not be a problem with log data though. > >

Re: sendsyslog kernel buffer

2021-03-08 Thread Theo de Raadt
Alexander Bluhm wrote: > I hope to have addressed all issues. > > On Sun, Mar 07, 2021 at 11:50:24AM +, Visa Hankala wrote: > > This copyin() can also result in copying the buffer from userspace twice. > > This might not be a problem with log data though. > > Is double copyin a problem? I

Re: sendsyslog kernel buffer

2021-03-08 Thread Alexander Bluhm
I hope to have addressed all issues. On Sun, Mar 07, 2021 at 11:50:24AM +, Visa Hankala wrote: > This copyin() can also result in copying the buffer from userspace twice. > This might not be a problem with log data though. Is double copyin a problem? I think error != EFAULT should catch all

xenodm : don't add authorizations for tcp connections by default

2021-03-08 Thread Matthieu Herrb
Hi, If you look at the output of "xauth list" on you favourite OpenBSD machine you might get a bit scared, especially if you have an IPv6 enabled network or if you used to travel and connect to various networks. Most of the lines are there to allow TCP connexions to the IP adresss of the machine

Re: safer sigcode page filling

2021-03-08 Thread Theo de Raadt
Miod Vallat wrote: > > It would be better if it contained "trap" instructions. We still don't > > have an ideal way of doing that tho. > > That would work, but that would make the code a bit more complicated. > And I'm not sure it's worth doing anyway. Running into an unmapped page > will

Re: safer sigcode page filling

2021-03-08 Thread Miod Vallat
> I guess the rest of the page contains 0? No, it contains a truncated copy of the sigcode. > It would be better if it contained "trap" instructions. We still don't > have an ideal way of doing that tho. That would work, but that would make the code a bit more complicated. And I'm not sure

Re: safer sigcode page filling

2021-03-08 Thread Theo de Raadt
I see I misunderstood, and this does what is desired. Miod Vallat wrote: > The code responsible for filling a page with repeated copies of the > signal trampoline code assumes that PAGE_SIZE % sigfillsz == 0. > > While this is true on all currently supported OpenBSD platforms, this > might not

Re: safer sigcode page filling

2021-03-08 Thread Theo de Raadt
I guess the rest of the page contains 0? It would be better if it contained "trap" instructions. We still don't have an ideal way of doing that tho. Miod Vallat wrote: > The code responsible for filling a page with repeated copies of the > signal trampoline code assumes that PAGE_SIZE %

safer sigcode page filling

2021-03-08 Thread Miod Vallat
The code responsible for filling a page with repeated copies of the signal trampoline code assumes that PAGE_SIZE % sigfillsz == 0. While this is true on all currently supported OpenBSD platforms, this might not be the case in the future (and isn't the case on some no-longer official platforms).

Re: Fix bgpd problem with local announcements

2021-03-08 Thread Florian Obser
this looks reasonable and fixes my problem OK florian On Mon, Mar 08, 2021 at 01:01:34PM +0100, Claudio Jeker wrote: > The last commit introduced an error in prefix_eligible(). For nexthops the > logic is not quite right since a NULL nexthop is actually fine. These > nexhops are created for local

Fix bgpd problem with local announcements

2021-03-08 Thread Claudio Jeker
The last commit introduced an error in prefix_eligible(). For nexthops the logic is not quite right since a NULL nexthop is actually fine. These nexhops are created for local announcements (unless their nexthop is overridden). -- :wq Claudio Index: rde_decide.c

Re: Read `ps_single' once

2021-03-08 Thread Claudio Jeker
On Mon, Mar 08, 2021 at 12:11:54PM +0100, Martin Pieuchot wrote: > On 08/03/21(Mon) 11:57, Claudio Jeker wrote: > > On Mon, Mar 08, 2021 at 11:06:44AM +0100, Martin Pieuchot wrote: > > > On 05/03/21(Fri) 11:30, Martin Pieuchot wrote: > > > > On 04/03/21(Thu) 11:45, Mark Kettenis wrote: > > > > > >

Re: Read `ps_single' once

2021-03-08 Thread Martin Pieuchot
On 08/03/21(Mon) 11:57, Claudio Jeker wrote: > On Mon, Mar 08, 2021 at 11:06:44AM +0100, Martin Pieuchot wrote: > > On 05/03/21(Fri) 11:30, Martin Pieuchot wrote: > > > On 04/03/21(Thu) 11:45, Mark Kettenis wrote: > > > > > Date: Thu, 4 Mar 2021 11:19:23 +0100 > > > > > From: Martin Pieuchot > >

Re: Read `ps_single' once

2021-03-08 Thread Claudio Jeker
On Mon, Mar 08, 2021 at 11:06:44AM +0100, Martin Pieuchot wrote: > On 05/03/21(Fri) 11:30, Martin Pieuchot wrote: > > On 04/03/21(Thu) 11:45, Mark Kettenis wrote: > > > > Date: Thu, 4 Mar 2021 11:19:23 +0100 > > > > From: Martin Pieuchot > > > > > > > > On 04/03/21(Thu) 11:01, Mark Kettenis

Re: single_thread_clear() w/o KERNEL_LOCK()

2021-03-08 Thread Claudio Jeker
On Mon, Mar 08, 2021 at 11:07:01AM +0100, Martin Pieuchot wrote: > On 04/03/21(Thu) 10:44, Martin Pieuchot wrote: > > single_thread_clear() manipulates the same data structures as > > single_thread_set() and, as such, doesn't need the KERNEL_LOCK(). > > > > However cursig() does need some sort of

Re: single_thread_clear() w/o KERNEL_LOCK()

2021-03-08 Thread Martin Pieuchot
On 04/03/21(Thu) 10:44, Martin Pieuchot wrote: > single_thread_clear() manipulates the same data structures as > single_thread_set() and, as such, doesn't need the KERNEL_LOCK(). > > However cursig() does need some sort of serialization to ensure that > per-process data structures like signals,

Re: Read `ps_single' once

2021-03-08 Thread Martin Pieuchot
On 05/03/21(Fri) 11:30, Martin Pieuchot wrote: > On 04/03/21(Thu) 11:45, Mark Kettenis wrote: > > > Date: Thu, 4 Mar 2021 11:19:23 +0100 > > > From: Martin Pieuchot > > > > > > On 04/03/21(Thu) 11:01, Mark Kettenis wrote: > > > > > Date: Thu, 4 Mar 2021 10:54:48 +0100 > > > > > From: Patrick