On Mon, 16 May 2022, Luke Small wrote:
> Yeah, I see your point.
>
> I suppose it depends on how conservative you want to be and whether
> you want to supply options to people like getchar_unlocked when it
> isn’t essential.
>
> It could be made manually fork-safe if I could make a simple feature
this narrows the scope of the KERNEL_LOCK in kbind(2) so the syscall
argument checks can be done without the kernel lock.
care is taken to allow the pc/cookie checks to run without any lock by
being careful with the order of the checks. all modifications to the
pc/cookie state are serialised by th
Yeah, I see your point.
I suppose it depends on how conservative you want to be and whether you
want to supply options to people like getchar_unlocked when it isn’t
essential.
It could be made manually fork-safe if I could make a simple feature where
“arc4random_uniform_unlocked(0);” with a 0 upp
On 2022/05/16 15:13, Luke Small wrote:
> If you’re not running a threaded program, my function wouldn’t be “less
> safe.”
>
> I’d imagine that 99% of programs aren’t multithreaded.
code is reused in different places. non threaded programs are sometimes
turned into threaded programs and when that
No...am I incorrect, especially on OpenBSD?
Of course since you made such a remark, you seem like the kind of fellow
that would put the nail in the coffin for spite.
...now I sound like an asshole.
On Mon, May 16, 2022 at 4:00 PM Theo de Raadt wrote:
> hey luke you know you sound like an assho
hey luke you know you sound like an asshole right?
Luke Small wrote:
> If you’re not running a threaded program, my function wouldn’t be “less
> safe.”
>
> I’d imagine that 99% of programs aren’t multithreaded.
>
> On Mon, May 16, 2022 at 1:01 PM wrote:
>
> > > There is the specifically non
If you’re not running a threaded program, my function wouldn’t be “less
safe.”
I’d imagine that 99% of programs aren’t multithreaded.
On Mon, May 16, 2022 at 1:01 PM wrote:
> > There is the specifically non-threadsafe call getchar_unlocked() on
> OpenBSD
> > which is presumably available for pe
Hi,
The diff below switches unix(4) sockets locking from one global
`unp_lock' rwlock(9) to per-socket `so_lock' rwlock(9). I already posted
this diff to tech@. Also this diff was tested in the snaps without any
issue. This version was updated to be against the most recent sources.
I want to push
Hi
What's the status on this? Anthing required from my side? I have
reattached the patch (with the changes Theo suggested).
Best,
Martin
On Mon, May 09, 2022 at 08:39:38PM +0200, Martin Vahlensieck wrote:
> On Mon, May 09, 2022 at 10:42:29AM -0600, Theo de Raadt wrote:
> > Martin Vahlensieck
Philip Guenther wrote in
:
|On Sun, 15 May 2022, Steffen Nurpmeso wrote:
|> Stuart Henderson wrote in
|...
|>|what's the perceived problem you're wanting to solve? and does that
|>|problem actually exist in the first place?
|>
|> The problem is that if have a low upper bound then modulo wi
Luke Small on Sun, May 15 2022:
> The current implementation is nothing more than a naive arc4random() %
> upper_bound which trashes initial arc4random() calls it doesn’t like,
Yes, that's exactly what it is.
> The whole transformation by modulus of perfectly decent random data
> seems so awkward
On Sun, May 15, 2022 at 08:46:00PM -0600, Theo de Raadt wrote:
> You'll turn into a smurf before you finish auditing xterm perfectly.
Should be in fortune ;)
12 matches
Mail list logo
