- User Since
- Jul 9 2015, 9:56 PM (334 w, 5 d)
Mon, Nov 29
Seems ok in principle.
At a minimum, you have rdseed (rdrand). But I expect there are other non-ethernet sources present as well.
Fri, Nov 19
The problem is that in some use cases we might not have a lot of entropy good sources, with the ethernet being the only good candidate.
Wed, Nov 17
Consider just disabling Ethernet entropy collection instead. In fact, I thought it was off by default in approximately the 13 timeframe.
Tue, Nov 16
Mon, Nov 15
Sat, Nov 13
Fortuna doesn't specify the 100ms sleep behavior, as far as I can tell. Removing it seems reasonable to me.
Oct 29 2021
This change should come with a motivational ministat graph.
Oct 25 2021
I meant fundamentally bad idea. Very little work should happen in interrupt context. Taking a global lock and running AES in software is somewhat expensive.
Oct 13 2021
I don't believe anything should be consuming random in interrupt contexts. Could you elaborate on the scenario / bug?
Sep 27 2021
Sep 25 2021
Address of packed member? How?
Sep 21 2021
Lgtm, thanks for driving this.
Let’s re-remove read_rate_increment but otherwise it’s looking good to me.
Sep 20 2021
Sep 19 2021
Sep 18 2021
I hadn’t seen the patch moving the stack buffer to the softc when I wrote my earlier remarks. I still think we should be polling less volume.
As mentioned earlier in the stack I don’t think this mitigation is great.
I don’t think this is a great mitigation for random - the pending request will still be written in guest memory, and we need the queue completion to know when we can free the memory.
Aug 30 2021
Aug 12 2021
LTO builds can see across CUs. I don’t know of any particular pass that would eliminate this, though.
Aug 11 2021
It's not exactly a false positive, although poisoning the output as uninitialized is sort of unhelpful. Are we confident the compiler isn't eliminating access to it (due to UB) outside of KMSAN? In the abstract, I think we would prefer to eliminate bypass_before_seeding.
Aug 6 2021
Jul 29 2021
Jul 28 2021
Oops. Use C89-style comments per style(9).
Add comment explaining the cast.
This would only happen if you have multiple competing dhcp servers on a subnet, right? Edit: not dhcp, oops. Still, kind of surprising we’re getting multiple ARP responses?
Jul 27 2021
Jul 24 2021
Jul 23 2021
May 11 2021
Is there a way we could make MB_CUR_MAX or __mb_cur_max suck less, in a more general way? Like, isn't it basically always four or one?
May 1 2021
I think the idea is very reasonable and could be done in a way that preserves the safety of the sandbox, at least for fstyp. I don't think the popen approach makes sense. There may be a lot of work required to sandbox the suggested consumer (mount).
Apr 12 2021
Nice cleanup. I didn't review the man page language updates super thoroughly, but the parts I skimmed looked good.
Apr 1 2021
Mar 31 2021
Mar 23 2021
Nice find. I'd encourage using prng32_bounded instead, but I don't think this is mechanically wrong.
Mar 16 2021
Mar 9 2021
Seems reasonable to me!
Generally seems good to me.
Mar 3 2021
Certainly not a regression :-)
Mar 2 2021
Is 128 a reasonable chunk here? How does it relate to the internal buffering of FILE?
Mar 1 2021
Two small issues remaining, but otherwise I think it's in good shape
Feb 28 2021
Feb 23 2021
Feb 18 2021
Still accepted from earlier
Outside of ossl_chacha20.c, everything looks fine.
Hm, it is little endian, but I'm not confident about the two sentences prior.
Feb 17 2021
Feb 16 2021
Feb 15 2021
The analysis makes sense and the fix looks fine to me. You could allocate two fds and check socketpair against both (instead of just low) in the final test, but I don't think there's much marginal value in that. (Frankly, I'm not a fan of unix' must-assign-lowest-fd behavior in general, but we have to abide by it.)
Feb 13 2021
Feb 12 2021
In the commit summary, is this a typo?
Feb 8 2021
No objection in principle, but the diff is basically unreviewable as-is for me; it's like 90% autoconf generated shell.
Feb 2 2021
Feb 1 2021
Looks great to me!
Jan 29 2021
Jan 28 2021
That's true, but it's possible for callers to depend on the instantaneous result being correct because some external synchronization guarantees that the result is stable. For instance, some lock might serialize calls to getblk() for a particular vnode, so holding that lock ensures that incore() returns a stable result. I'm worried about false negatives caused by reassignbuf() in cases like this.
I think the idea here is that CRC32 is part of SSE4.2, which is part of the base feature set of amd64. If you're hitting SIGILL in QEMU in amd64 mode, that suggests QEMU's amd64 emulation is somewhat invalid. However, it's certainly optional on at least some early models of i386.