LGTM, thanks!

Thanks! Please see my comment inline.

Thanks! This looks mostly good to me. I intend to commit this version with some minor tweaks after some testing in a day or two, so please yell if you don't agree with some change proposals (commented inline).

I think I have accepted back in April but let's make it an explicit one. Be sure to update the dates though.

In D20698#447294, @mat wrote:

I don't know about this, I think it is better to send an email that is ignored than silently doing things.

Committed as rS349151

For the microoptimization: Note that it's possible to avoid the additional branching by doing unlock in both cases, e.g.:

Actually, the delay/sleep is probably not necessary (releasing the lock is sufficient for another thread to race in).

LGTM but please amend the wmsg message to not exceed 6 characters (see comment inline) prior to commit.

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

2. (This patch) allow users to overwrite the default parameters through login.conf

Ping?

Rebase and minor fixup.

(also see D15713)

Looks good to me overall, but please remove the warn (see comment inline for reasoning).

Looks good to me in principal.

LGTM.

+markj and bz@ for the DTrace probe.

I think this can go independently with other changes: is there some reason that you would like to wait instead of proceeding?

Looks reasonable to me.

Warner -- can you commit this change?

Committed as rS347244.

I think the change as-is is fine.

I'll commit this after a universe build.

LGTM in principle

No objection from me.

(I'm not against with the overall plan, but see my comments about use of hash function inline).

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.

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!

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.