Building WITHOUT_OPENSSL doesn't make it far enough to test wpa build, libradius needs a little love:

Commit message in my D30159 branch (--pretty-fuller):

If you don't mind, I'll make the two minor corrections and commit it. Is that ok?

This is certainly an improvement over the original.

In D29553#673827, @dgr_semihalf.com wrote:

In D29553#673797, @cy wrote:

I will do a little more testing and commit.

OK, just a reminder that without D29550, D29551 and D29552 this will not work. Currently there is no infrastructure in FreeBSD build system to use elfctl during build and those patches add that.

In D29832#673803, @dgr_semihalf.com wrote:

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.

I will do a little more testing and commit.

The work around works on my sandbox machine today but does not on the laptop when PIE is enabled on both. Without PIE and with ASLR there is no need for the workaround.

This is probably the only solution, as it works with PIE enabled, regardless of whether ASLR is enabled or not. See discussion at D29832.

Having done a couple of reboots since enabling PIE and increasing stack to 200, now after this last reboot about an hour ago it now fails regardless of how much stack I give it (even obscene amounts). Increasing stack to 200, 1024, 20000, 200000, all of which I've tried, will not work after this latest reboot.

Juxtapositioned to this is that enabling PIE causes firefox to segfault but that's for another review.

Adjusting the stack to 200, like OpenBSD does, resolves this issue when PIE is enabled.

Ok, I can finally reproduce the problem with kern.elf64.aslr.pie_enable=1. PIE introduces a new set of problems that were not addressed by procctl() at the time.

In D29832#673302, @dgr_semihalf.com wrote:

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.

Currently, ntpd does not start when ASLR is enabled, which means that calling procctl does not help. However, either disabling stackgap with elfctl or significantly increasing the stack limit help with this issue.

This is already done at line 447 of ntpd.c. Why do we need this?

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)?