Relevant PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259969

Removed the clamping.

Added newline after variable declaration.

Some style changes.

Added struct proc *p helper variable.

Ping. Any remarks?

Ping. Any comments? (Also for D31898)

Ping. Any remarks?

Add kern.usrstack fallback if kern.stacktop was not found.

Abandoning this, I created D31897 and D31898, which add a different sysctl and modify libthr to use it.

• Made sv_stackgap return the size of the stack gap.
• Moved vm_stkgap assignment into exec_stackgap().
• Changed vm_stkgap type to vm_size_t
• Modified a comment to mention that stack gap size is in bytes.

Do you have any remarks about this version of the diff (and also D31692)?

This requires D31516.

Updated setrlimit to automatically adjust stack rlim_cur value by the stack gap size. This also works, however now the rlim_max is properly respected. Ntpd also doesn't crash.

In D31516#711576, @cy wrote:

I have reverted (locally) the NTP mitigation commits. This patch totally resolves the NTP issues. The code looks good. Good to go from this perspective.

Secondly, firefox still segfaults (unless procctl (proccontrol -m aslr -s disable firefox) is used. I think this might be a juxtaposed issue.

Ping. Does the patch look good? It's needed for D29553.

Ping. Does the patch look good? It's needed for D29553.

Ping. Does the patch look good? It's needed for D29553.

In D29553#673797, @cy wrote:

I will do a little more testing and commit.

So, I've looked at this more and setting the stack size to 4096 pages should technically also resolve this problem. I tested this restarting the daemon multiple times and in my case it worked. However, the problem will occur randomly due to random nature of stack gap randomization. By default, the maximum size of stack gap is 15.36MiB on amd64, I'm not sure about other platforms. The default value of kern.elf64.aslr.stack_gap is 3, so in case of amd64, where the default stack limit is equal to 512MiB, that gives us the 15.36MiB number. I used 4096 as this means that we are setting the stack limit to 16MiB, which should leave enough stack for ntpd to work - I think that 15.56MiB is needed (15.36 of stack gap and 200K taken from the fact that we were limiting this to 200K previously), but I rounded this up to 16MiB.

In D29832#673048, @cy wrote:

In D29832#672594, @kib wrote:

Does ntpd still mlocall(2) itself? Issue there, I believe, is that all this memory, including gap, is wired.

Why not disable stack gap instead, with elfctl -e +noaslrstkgap ntpd (I think this is the right syntax)?

We already disable stack gap at line 447 of ntpd.c. Upstream inserted this patch after we applied it locally.

I re-opened D29553. I'm leaving this up as I don't know which will be the accepted method for solving the problem.

Re-opening this. As mentioned in D29832, @kib prefers this version.

In D29832#672594, @kib wrote:

Does ntpd still mlocall(2) itself? Issue there, I believe, is that all this memory, including gap, is wired.

Why not disable stack gap instead, with elfctl -e +noaslrstkgap ntpd (I think this is the right syntax)?

D29832 changes the default stack size for ntpd, so I'm abandoning this revision. What do you think about D29550, D29551 and D29552?

Yes, this could be resolved by changing the default stack resource limit from 200KiB to around 16MiB (maximum stack gap that can be created with default settings is 15.36MiB - 3% of default 512MiB stack resource limit). In that case the stack gap would actually exist, so any benefits resulting from it would still be there. Of course, the disadvantage of this approach is the increased resource utilization but that is expected with ASLR anyway. Also, if anyone changes the default stack limit to a lower value, this could result in segfault for them, so I think that information about that should be included somewhere in documentation.

I created D29550, D29551, D29552 and D29553, which allow us to disable stack gap for ntpd during build.

D29551 and D29552 are required for this to work.

My initial tests did not show any problems, but I only checked some basic functions of the server, for example CGI was not tested. This server is quite minimal, so testing reasonable part of this should not take long. Hopefully, the maintainer will tell us more about that. If not, I'll setup something and test this myself. Disabling PIE entirely, just because it does not build, may be an overkill here.

It seems that the maintainer doesn't have an account here. I'll send an email directly.

I have looked at *.mk files and if I am not mistaken it seems that there is currently no clean way of having a separate default option for PIE for base, as the __DEFAULT_YES_OPTIONS from bsd.opts.mk takes precedence and moving this option from bsd.opts.mk will leave us with no MK_PIE defined.

Added a comment indicating that PIE is incompatible with -mno-abicalls. Thanks, @emaste.

In D27025#603548, @lwhsu wrote:

Does it make sense also report to the upstream? https://github.com/jemalloc/jemalloc

Replace SOC_NXP_LS1046 with SOC_NXP_LS.

Replace SOC_NXP_LS1046A with SOC_NXP_LS.

Add ls1046_gpio device in kernel config. Replace SOC_NXP_LS1046 with SOC_NXP_LS.

Replace SOC_NXP_LS1046 with SOC_NXP_LS.

Added comment about 1:1 sysclk and coreclk divider nodes.

I'll change it in all the patches to SOC_NXP_LS.

Modified to work with new version of D24351

Modified driver to use clock id for lookup instead of names.
Modified the way sysclk and coreclk are created - currently
should follow bindings. The clock sources for PLLs are now
selected by driver automatically depending on the presence
of coreclk.

Moved to dev/iicbus/rtc/ directory.

Moved to dev/iicbus/gpio directory.

Hi, if you have any more comments or remarks, please let me know. Thanks.

Hi, if you have any more comments or remarks, please let me know. Thanks.

Hi, if you have any more comments or remarks, please let me know. Thanks.

Hi, if you have any more comments or remarks, please let me know. Thanks.

Hi, if you have any more comments or remarks, please let me know. Thanks.

Hi, if you have any more comments or remarks, please let me know. Thanks.

Hi, if you have any more comments or remarks, please let me know. Thanks.

Added pin_access_32 and pin_config_32 functions.
Changed get_name function to generate "pin <pin_number>" as name.
Additional minor fixes.

Added vf_i2c as driver name in files.arm64

Removed "All rights reserved" from copyright notice.
Added clock enabling in attach function.

Each PLL has multiple dividers. For each PLL single PLL node is created
and fixed factor clock nodes are created for each divider that the PLL has.
So only a single PLL node exists, but there are multiple divider nodes.

Thanks, I'll prepare patch in the coming days.

The controller is actually connected to platform PLL, which
is always enabled, but since the controller might be used in
different SoC in the future, I'll add clock enabling.

In D24466#538161, @manu wrote:

Do you know how different this controller is compared to the other fsl ahci controller ? (like ls208x etc ...)
If it's very different the file should be renamed.

Add dependency on SOC_NXP_LS1046A option.

Renamed file to rx8803.

Removed code that needed interrupts to start before executing.

The problem was with dts file not conforming to device tree documentation. Abandoning.

Added bus_release_resources call and dependency on SOC_NXP_LS1046A.

Added SOC_NXP_LS1046A dependency.

I modified the driver to use the modified QorIQ clockgen classes.
Also added dependency on SOC_NXP_LS104A.