I'll do the commit. Thanks to Greg for writing this and to everyone who helped to review it!

Who is going to do the actual commit? I'm happy to do it if no-one else wants to? Whoever does it has csprng@ green-light.

Last nit can be done pre-commit or I can whack it post-commit; ok from lua perspective.

Is this ready to be committed? I'm happy to do it myself but markm said he was going to commit (prior to the latest round of changes) -- don't want to commit prematurely if you're still waiting for something.

Yep, I've had basically the exact same opinion as @delphij about the copyright. Let's go with Intel.

So seems like it's easier to just do it all in core.lua, which is where lots of config accesses are anyway.

In D20780#766778, @greg_unrelenting.technology wrote:

err, I have not addressed the "isUEFIBoot" thing and the "This file needs a copyright / license at the top" thing…

err, I have not addressed the "isUEFIBoot" thing and the "This file needs a copyright / license at the top" thing…

Thanks! Can you also MFC it to stable/13 after a week?

In D20780#766643, @cperciva wrote:

Is this waiting for anything else before it gets committed?

Is this waiting for anything else before it gets committed?

I did a minor edit on the proposed commit message to clarify some things (sorry I do not have it as a diff)

In D27666#745003, @mw wrote:

Altough I agree it should be safe to enable ASLR 32-bit, for now I'd stay with 64-bit only - please remember that after a discussion it was decided to compile only 64-bit executables "WITH_PIE".

In D27666#744977, @kib wrote:

In D27666#744939, @emaste wrote:

I might write are not changed at this time to suggest this is not necessarily a final decision (in fact, it's not really a decision at all, 32-bit is probably not relevant enough to spend much effort on).

For 32bit, it might make sense to enable ASLR for 32bit binaries on 64bit host, still. That said, i386 kernel provides almost full 4G for UVA, so it might make sense to enable there as well, but lets limit the change to 64bit kernels, indeed.

In D27666#744939, @emaste wrote:

I might write are not changed at this time to suggest this is not necessarily a final decision (in fact, it's not really a decision at all, 32-bit is probably not relevant enough to spend much effort on).

In D27666#744939, @emaste wrote:

As a result, although the tests on 32-bit architectures with ASLR enabled were
mostly on par with what was observed on 64-bit ones, the defaults for the
former are not changed. Also, for the sake of safety keep the feature disabled for 32-bit
executables on 64-bit machines, too.

I might write are not changed at this time to suggest this is not necessarily a final decision (in fact, it's not really a decision at all, 32-bit is probably not relevant enough to spend much effort on).

As a result, although the tests on 32-bit architectures with ASLR enabled were
mostly on par with what was observed on 64-bit ones, the defaults for the
former are not changed. Also, for the sake of safety keep the feature disabled for 32-bit
executables on 64-bit machines, too.

In D27666#744905, @kib wrote:

Yes, leave it. I think it is verbose but explicit so that more people can notice that if pointed to.

Yes, leave it. I think it is verbose but explicit so that more people can notice that if pointed to.

In D27666#744903, @kib wrote:

I suggest also dropping the

In case any change in the OS behavior is observed, that can be possibly
caused by this patch, it is recommended to use freebsd-bugs@freebsd.org
mailing list for reporting and discussing the encountered issue. Also,

wording.

I suggest also dropping the

In case any change in the OS behavior is observed, that can be possibly
caused by this patch, it is recommended to use freebsd-bugs@freebsd.org
mailing list for reporting and discussing the encountered issue. Also,

wording.

I think it is better to provide short and concise list of potential issues with ASLR, like this:

• changed ABI due to modified layout of address space
• address space fragmentation
• non-reproducable address space layout between runs
• harder debugging
• some debuggers automatically disable ASLR for spawned targets, making target' environment different between debug and non-debug runs

Limit setting of __elfN(pie_aslr_enabled) for only 64-bit PIE binaries.

Fix typo.

Typo to fix on commit but otherwise looks fine to me

Hi! Any comments/remarks to the updated version?

Collect all PPIs since they indeed could be different on different CPUs

(Though we're not at all set up to be able to handle that if that's true...)

I don't think there's any requirement that each CPU use the same PPI, unlike for the FDT bindings where that's an assumption made by both Linux and FreeBSD?