The WASI folks seem fine upstreaming patches. Might be nice to make clean pull requests for these projects after we resolve Brook's comment.

In D25150#554652, @mmacy wrote:

I'm a bit confused. The counter descriptions are just copied from Linux. If you're just copying from there, just add them as is. If you're doing something new then add them as a different file.

Some counters from the Linux repo appear to be undocumented at the moment and I left those out. Also they seem to think some of these are available on earlier platforms but I don't see that in the documentation nor can I test it.

• Adding missing counters for Zen+ and Zen2

Most of it is in Linux's amdzen2 files should I just merge those under a new name? Seems weird they didn't use versioning. Do you have a better plan how to deal with these? (Also is the Linux tree the correct source for these json files?)

Could you clarify if these files are synced from Linux or generated from the manuals? I wanted to add a few counters that appear in the documentation but are missing from both the Intel and FreeBSD definitions. What would be the best way should we add definitions to the existing files in the correct place or create a new file to track these additions?

In D20366#440218, @delphij wrote:

In D20366#440204, @ali_mashtizadeh.com wrote:

This version does not change the default, but allows users to change the parameters.

But can't one already use e.g. $6$rounds=100000$xxxxx$ as salt? Or are you talking about something different?

This version does not change the default, but allows users to change the parameters.

• strn -> strl

• Fix man page

• Making requested changes

In the Kitchener/Waterloo hackathon we discussed the plan as three parts

1. Allan is working to port the improvements from OpenBSD bcrypt back to FreeBSD.
2. (This patch) allow users to overwrite the default parameters through login.conf
3. Work on importing Argon2 as an alternative (and maybe scrypt if there's interest)

• Update default rounds for bcrypt

Tinderbox passed

• Adding defines

• Update man page and remove from -a

Sample output:
root@skylake8:~ # uname -a
FreeBSD skylake8.rcs.uwaterloo.ca 13.0-CURRENT FreeBSD 13.0-CURRENT #9 da147860ca7(master)-dirty: Mon May 20 17:32:20 EDT 2019 ali@strange.rcs.uwaterloo.ca:/build/ali/obj/working/freebsd-dev/amd64.amd64/sys/GENERIC amd64 42e907d740dd9560a2dfd7187eee20e41e9fbd9f
root@skylake8:~ # uname -b
42e907d740dd9560a2dfd7187eee20e41e9fbd9f

• Addresses Ed Maste's feedback. This change allows the sysctl to return any build-id between 1 and 20 bytes.

• Updates and linker scripts for other archs

Hello Brooks,

Hello Brooks,

Refresh diff to head

Brooks & Konstantin if there's no objections I'm consolidating all the system call symbols for libsys/libc together. They have to be kept in sync to support library filtering otherwise it breaks. There's some fallout from that deduplication work, I'll wrap that up tomorrow.

Updated patch against head and lots of cleanup to amd64 and i386. Similar cleanup in progress on other platforms.

In D15054#320744, @kib wrote:

In D15054#320737, @ali_mashtizadeh.com wrote:

kib: I also wonder if we can push the logic into the ptrace code rather than making the trap code more complex. It seems other BSDs have pushed the behavior into the trap code. IIRC, they call into the arch specific code from sys_process.c to set/clear the trace flag. Noticed this when I was looking for the original patches.

I do not think that trying to move that into MI layer is feasible. The methods to manage single stepping are too arch-depended. IMO it is fine to have that logic in trap/machdep sendsig(). And, we do have ptrace_single_step()/ptrace_clear_single_step(), more, they are patched in the revision.

We should probably check in a few regression tests to verify the trace flag and fork+tracing behavior on x86. I can send you the ones I have if you want to use those.

It would be best if you create ATF tests and put them into review.

In D15054#320004, @jhb wrote:

Hmm, if this code works now then it might be relying on the existing semantics that stepping is auto-disabled and has to be re-enabled in the SIGTRAP handler to keep stepping? It's not clear. Linux does seem to jump through extra hoops to permit userland to set PSL_T. Linux also permits PSL_T to be set explicitly via PT_SETREGS which FreeBSD does not (and for which sbcl has an explicit hack). We should perhaps permit PT_SETREGS to change PSL_T in addition to these hoops. (In Linux there is a TIF_FORCED_TF flag that seems to function like TDB_STEP and Linux goes further out of its way to "hide" PSL_T from registers returned by PT_GETREGS if PSL_T is only set due to TDB_STEP and not explicitly by userland as well)

In D15054#319974, @jhb wrote:

Honestly, I'm not really sure how useful it is to try to let user processes set PSL_T themselves in user space. It's never worked in any version of FreeBSD and it is requiring several changes to accomodate. I would probably just go back to not preserving PSL_T on exec() and leave the existing handling of PSL_T for debug traps alone under the assumption that the only really sane way to use PSL_T is via a debugger using ptrace(). Are you aware of anything that wants to use PSL_T on itself without using ptrace()?

Rebase

Done

• Update copyright

Copy from my email regarding the proposed plan

• Remove the warning message

I noticed PSL_T flag is masked out in the trap and system call entry path. It only gets set again by ptrace(PT_STEP, ...). This appears to be intentional because of the way ptrace() is being used.

With this version of the code the functionality matches the documentation. We could remove the warn_references and leave the manual suggestion that this functionality has been replaced by ptrace. I left the warning from the NetBSD code but there's not much point if we have something that works.

In any case the changes look good. Just do something about the Linux compat files I listed as well.

• Ignore EBUSY errno

In D14995#315582, @rgrimes wrote:

In D14995#315560, @ali_mashtizadeh.com wrote:

So this doesn't get lost this is the original change in SVN. It dates back before FreeBSD 2.0

https://svnweb.freebsd.org/base/head/sys/i386/i386/machdep.c?r1=4193&r2=4201

I find that hard to believe, given that the cvs versions before 2.0 do not exist in svn, or ncvs, and should only exist in an offline repository called cvs.

Running make tinderbox. I've backout the kernel change and added the code to ignore EBUSY.

• Ignore EBUSY errno

Probably you should fix or remove the dead code in the linux compat layer as well.

Backout kernel as kib is taking care of this.

With LLDB I can single step across an exec so we must be setting the trap flag elsewhere for ptrace() to work.

So this doesn't get lost this is the original change in SVN. It dates back before FreeBSD 2.0

If nobody has used this in 23 years and it's not present in other platforms do we need this?

• Remove the dead expression from i386/amd64 machdep

In D14989#315532, @ali_mashtizadeh.com wrote:

Well I made a few test cases to verify to myself all the differences and it turns out exect() doesn't even work on 11. It generates a trace fault in the original image and then stops generating faults in the new image.

exec_setregs() zeros out the registers then tries to maintain the value of regs->tf_eflags. Nothing in eflags appears to be preserved.
https://github.com/freebsd/freebsd/blob/master/sys/amd64/amd64/machdep.c#L596
https://github.com/freebsd/freebsd/blob/master/sys/i386/i386/machdep.c#L1130

https://svnweb.freebsd.org/base/head/sys/i386/i386/machdep.c?r1=4193&r2=4201

Unless something else has changed it seems we have a 23 year old regression?

Well I made a few test cases to verify to myself all the differences and it turns out exect() doesn't even work on 11. It generates a trace fault in the original image and then stops generating faults in the new image.

@rgrimes With this version of the patch do we need to do anything about stable/11? The behavior now should most closely match the documentation.

I'm waiting for make tinderbox to complete.

• Address feedback

In D14989#315376, @kib wrote:

I must note that i386 and amd64 (both native and compat32) execve(2) syscalls explicitly support inheriting PSL_T from the previosly executing program to the new one. So exect() behaves as designed, assuming the tracing faults fo not kill the process.

The netbsd test suite contains a test for exect but that should go away whenever someone pulls the latest version.

This is the last bit of cleanup I sent a mail about this on the mailing list to look for objections. I will either today or tomorrow send all three of you a sketch of my plans for libsys.

• universe_i386_i386 ---

i386.i386 buildworld completed on Fri Apr 6 04:52:06 EDT 2018

• universe_i386_kernels ---
• universe_kernconf_i386_GENERIC ---
• universe_kernconf_i386_GENERIC-NODEBUG ---
• universe_kernconf_i386_LINT ---
• universe_kernconf_i386_LINT-NOINET ---
• universe_kernconf_i386_LINT-NOINET6 ---
• universe_kernconf_i386_LINT-NOIP ---
• universe_kernconf_i386_PAE ---
• universe_arm64_aarch64 ---

arm64.aarch64 buildworld completed on Fri Apr 6 04:57:10 EDT 2018

• universe_arm64_kernels ---
• universe_kernconf_arm64_GENERIC ---
• universe_kernconf_arm64_GENERIC-NODEBUG ---
• universe_kernconf_arm64_GENERIC-UP ---
• universe_amd64_done ---

amd64 completed on Fri Apr 6 05:16:08 EDT 2018

• universe_arm64_done ---

arm64 completed on Fri Apr 6 05:35:21 EDT 2018

• universe_i386_done ---

i386 completed on Fri Apr 6 05:43:02 EDT 2018

• universe_epilogue --- --------------------------------------------------------------

make universe completed on Fri Apr 6 05:43:02 EDT 2018

(started Thu Apr  5 20:37:43 EDT 2018)

Thanks for the comments I'll rework the diff