- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 31 2019
May 30 2019
May 28 2019
May 27 2019
May 25 2019
May 24 2019
In D20366#440204, @ali_mashtizadeh.com wrote:This version does not change the default, but allows users to change the parameters.
In D20366#439970, @ali_mashtizadeh.com wrote:In the Kitchener/Waterloo hackathon we discussed the plan as three parts
- (This patch) allow users to overwrite the default parameters through login.conf
Ping?
Rebase and minor fixup.
May 23 2019
(also see D15713)
May 22 2019
Looks good to me overall, but please remove the warn (see comment inline for reasoning).
May 21 2019
Looks good to me in principal.
May 19 2019
May 16 2019
May 15 2019
May 14 2019
+markj and bz@ for the DTrace probe.
May 13 2019
I think this can go independently with other changes: is there some reason that you would like to wait instead of proceeding?
May 12 2019
May 11 2019
May 10 2019
May 9 2019
Warner -- can you commit this change?
May 8 2019
Committed as rS347244.
I think the change as-is is fine.
I'll commit this after a universe build.
LGTM in principle
May 6 2019
No objection from me.
Apr 21 2019
Apr 18 2019
(I'm not against with the overall plan, but see my comments about use of hash function inline).
Apr 17 2019
Apr 16 2019
For a stopgap fix I think it's fine. Note that it's probably better to derive __stack_chk_guard from SHA512 of something that we change often (e.g. __FreeBSD_version) concatenate with something that potentially varies, like getcyclecount(), for the fallback guard data: these are not secure random numbers, but would make it harder for an attacker to develop more generic smashing attack.
Apr 15 2019
I'm in favor of this change; please consider this as an explicit "accepted" if nobody objects in a week.
The code changes looks good to me -- and thanks for working on this!
Apr 12 2019
In D19713#427179, @mindal_semihalf.com wrote:In D19713#427028, @delphij wrote:I don't really know the internals of this driver (ideally this should be done by someone who is familiar with it), but are we sure that the write method is always called before a read? Also, if the discard callout is fired, should the owner tid be reset (because the contents is now discarded)?
If the write method hasn't been called before a read then there will be nothing in the buffer and the read will fail - as pending_data_length equals 0.
Essentially the way it works is that write is used to do the entire communication with TPM and read just copies the response to userspace.
As for the discard callout, since it also clears the buffer read would fail either way and tid is not checked in write, as it is used only to restrict access to buffer contents which is empty when a write is performed.
Apr 11 2019
I don't really know the internals of this driver (ideally this should be done by someone who is familiar with it), but are we sure that the write method is always called before a read? Also, if the discard callout is fired, should the owner tid be reset (because the contents is now discarded)?
Apr 6 2019
Noticed a few minor issues, please see comment inline. Overall I think the change is good.
Apr 5 2019
Apr 4 2019
Apr 3 2019
Mar 31 2019
LGTM, thanks!
Mar 29 2019
The shutdown script change LGTM, but I insist that libexec/save-entropy/save-entropy.sh line 83 should be removed as explained in previous comment.
In D19742#423456, @cem wrote:In D19742#423197, @delphij wrote:I think a 'fsync saved-entropy.1 .' should be sufficient.
We don't really care if the renames were not persistent until the new entropy is saved,
Sure, if that is the power-fail/crash behavior of un-fsynced renames. But I don't believe that model is accurate. There is no requirement that the underlying filesystem order the dirent writes in a way that matches this observable behavior; the only requirement is that it is persisted by fsync.
FS&K §9.6.2 is clear, "All updates to the seed file must be atomic" and goes into more detail in §9.6.5.
I think you should separate most of the read_random() -> arc4random_buf() change out because in most cases the code should use the latter exclusively, especially places where the return value of read_random() were not tested because it would be a strict improvement to the status quo.
I think a 'fsync saved-entropy.1 .' should be sufficient.
Mar 28 2019
In D19706#422829, @ota_j.email.ne.jp wrote:I need to understand better kernel malloc/free as they take 1 extra argument compare to stdlib.h.
Mar 27 2019
Hi, first of all, kudos for taking on this! The change looks mostly Ok to me except a few minor issues commented inline.
Mar 23 2019
Why is the partition index changed from 1 to 2? (The change looks otherwise fine to me).
Mar 22 2019
Thanks! LGTM (note that discard_buffer_callout should probably also be drained, but it's unrelated to this change).
Mar 21 2019
I have noticed a few minor issues and have commented inline.
Mar 7 2019
(Note that randomdev_getkey() have similar issue and should be fixed too, feel free to fix it prior to commit)
Looks good to me in principle and I like the fact that fortuna.c no longer cares about the keystream context internals.
Mar 1 2019
Feb 25 2019
Abandoned in favor of D19216.
Sorry, this looks good to me & thanks!
Feb 19 2019
Feb 13 2019
Ah I didn't realized that we haven't upstreamed it & thanks for forward-porting it for so many years...
Feb 7 2019
Feb 5 2019
Jan 29 2019
Jan 28 2019
In D18920#405658, @oshogbo wrote:Is this some common pattern?