LGTM

bectl depends on ZFS or it have a separate knob?

It would be better to keep the master.passwd and other sensitive core file in it's place, and create a base file or base system metapackage, which pulls out the files from the proper place..

This is still wrong.

@emaste : could you please coordinate this upstreaming?

Probably it would be nice to rethink the linker file layout for amd64, since there are lot of parts merged into text, what is not NX naturally.

You can see the problem here: https://github.com/freebsd/freebsd/blob/master/sys/amd64/amd64/pmap.c#L7921

Nevermind, it's handled.

Do you plan to backport the fix for 11-STABLE too? If so, do you plan to MFC all of the vmmeter refactor - which moves vmmeter counters into separate counter_t from PCPU - or with extending the PCPU structure?

Could you please update the EVENTHANDLER(9) man page too?

Could you please update the EVENTHANDLER(9) man page too?

(When the diff got a positive review, please commit them.)

Make it more readable and consistent.

Updated diff.

Updated the limit to 4MB as proposed by kib@.

Seems like it successfully attaches:

Please commit this patch, this fixes FreeBSD PR 209580.

Sure, I plan to find time for check them. Thanks for the reminder.

Tested with these settings:

And add adrian@, gnn@ and glebius@ as reviewer?

Could you please reupload the patch with bigger context? git diff -U9999 for example?

Looks good to me, but not yet tested (I will at weekend.).

Adrian, could you please commit this change to HEAD?

Is there any chance to get this or similar changes before the 10.3 released?

Sponsored by HardenedBSD.

Cool! Thank you very much guys!

Hello guys!

Btw, when I'm there, is from the Intel side any plan to bring in to the tree newer wireless drivers drivers too?

Cool! Working fine with the following chips:

I will test the patch now.

I have an i219-V (not working) and an i211-at (working) adapter on my mobo (gigabyte h170n-wifi) , so feel free to ping me if you have a working or testable patch.

Is there any chance to get this patch into 10.3? As you have said, it would be nice to remove these programs from 11-CURRENT.

This patch is required to 10-STABLE? You marked this as MFC after 1 month, but this was never MFCd back.

Could you please commit the patch, if the diff fine?

Yes. We (HardenedBSD) already have this patch and working fine: https://github.com/HardenedBSD/hardenedBSD-stable/commit/1f4dbf94d059b9fd43944f73c890c94bedfbe6de

Any update on this change?

In D3933#81711, @jmg wrote:

• add /boot/entropy to install generation.. Also, be extra careful
• add quotes around the $i for more space protection..

I have done a basic test, and this looks good, I'll commit shortly..

In D3933#81686, @markm wrote:

This was on my TODO list. I wish I'd known it was this simple!

update one missing place

In D3001#77191, @pfg wrote:

In D3001#77190, @kib wrote:

In D3001#77189, @pfg wrote:

Private code can still disable relro, but I see your point.

Nevertheless, it still will be interesting to see, through the exp-run, how ports react to having relro by default.

You would only see a half of the interesting things, at best. Another half happens at runtime, which cannot be tested by an exp-run.

The toolchain will certainly be runtime tested, and some ports have testing targets.

I am also running it on my box. The question is .. what would be affected? Is there any particular port I should check?

In D3565#74326, @kib wrote:

Anything like this patch can only be considered if your 'aslr' implementation is ever found acceptable. Until it is not, the patch only adds bloat.