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

assume it's a draft until proper tests are in progress

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

LGTM. Would be good to add arm group for review and smoke test this change

correct comments wording

address reviewer comments

addresses commiter's suggestions

Hi! Any comments/remarks to the updated version?

In D27666#734447, @lattera-gmail.com wrote:

In D27666#734443, @mw wrote:

Hi,

I'm refreshing the discussion. The current status is following:

3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

It seems like a problem with the underlying AS{L}R implementation. HardenedBSD has not needed to make any changes to any application since it completed its PaX-inspired ASLR implementation in 2015. If applications experience issues with FreeBSD's AS{L}R implementation, it'd be safe to assume a problem with the AS{L}R implementation, not the application.

In D27666#734443, @mw wrote:

Hi,

I'm refreshing the discussion. The current status is following:

3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

I'm refreshing the discussion. The current status is following:

1. PIE enabled by default in 64-builds.
2. Ports' exp-run issues are fixed (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214864)
3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

Initialize RGB offsets along with palette.

Address reviewer's comments

I tested this patch with D31232 few weeks ago on the Blackbird and it looks good to me once it's approved.

• Address reviewer's comments

In D31804#717525, @dim wrote:

Let's do this for now to get the PowerPC builds working again. But also be aware that the bisected upstream commit is only exposing an underlying issue: most likely the root cause is in the PowerPC backend.

Let's do this for now to get the PowerPC builds working again. But also be aware that the bisected upstream commit is only exposing an underlying issue: most likely the root cause is in the PowerPC backend.

In D31698#715220, @fbsd-phab_maskray.me wrote:

This is not suitable for the upstream. The root cause behind dso_local needs to be found and fixed.

Glad to see you solve the last piece of this puzzle!

This is not suitable for the upstream. The root cause behind dso_local needs to be found and fixed.

I wouldn't say "reverts LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a", but something like "amends LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a", as we're adding code here. But otherwise, LGTM!

Abandoned in favor of D31698

In D31646#713731, @emaste wrote:

Move logic to BROKEN_OPTIONS as suggested by @jhibbits

This will work for src itself, but I think it won't work with ports that use /usr/share/mk?

Move logic to BROKEN_OPTIONS as suggested by @jhibbits

In D31646#713717, @emaste wrote:

is there a PR to reference here?

Move logic to BROKEN_OPTIONS as suggested by @jhibbits

is there a PR to reference here?

Great job luporl!

I no longer have access to any operational old-PowerMacs. (And never had access to any other example types of PowerPC/Power hardware.) As such, I'll no longer be involved in powerpc64 or 32-bit powerpc activities.

This approach of auto detecting the correct frame buffer physical address based on Vendor ID looks good.
It would help to make FreeBSD graphics work out of the box for Blackbird and Talos II machines, instead of forcing the user to figure out the physical address of its VGA adapter and pass it to the kernel manually, or else the system just hangs.
Ideally, Petitboot should fix it on their side, but I don't know if it will happen anytime soon, since Linux isn't affected, because it just talks directly to ASPEED video device, instead of relying on the framebuffer info exposed in the device tree.

D31232 fixes OFWFB with radix. After it lands it should be safe to make radix default.

After discussion with @imp , we decided to try the "reroot" approach instead. It appears to be generic solution for other modules as well, and can be used on other platforms.
A new review entry will be created when it's ready for review.

For some reason this breaks the boot with VGA console on Blackbird.
I'm using D30626 locally, but reverted it as well. With D30626 reverted and adding kernel parameter 'hw.ofwfb.physaddr=0x000600c280000000' the kernel hangs as well with no output.

Looks fine to me.

In D30793#692367, @imp wrote:

That is, I'd rather see ZFS64

include GENERIC64
options ZFS

etc

That is, I'd rather see ZFS64

include GENERIC64
options ZFS

etc

I'd really rather we didn't do this... I don't think it's a good idea....

It ended up being not entirely necessary due to the linker behavior of forcing required sections into whatever segment is a natural fit for them, unless we explicitly break it with /DISCARD/.

Is this still needed? We've had ifuncs for a year now, with no problems.

Seems to work fine on my G4.