I think this is fine as is.
There's no need to check for nfs in the middle of a string, unless there's some use case I'm unaware of...

In D33603#796461, @alfredo wrote:

I like the idea! However I burned an DVD for a PowerBook G4 and I only see the regular disc icon.
What's your device model? (based on other sources your patch looks correct. Maybe my firmware is too old for this feature)

Seems legit

I like the idea! However I burned an DVD for a PowerBook G4 and I only see the regular disc icon.
What's your device model? (based on other sources your patch looks correct. Maybe my firmware is too old for this feature)

It really needs someone familiar with bootstrapping to review this.
(Except for being the nfs case, it really has nothing to do with nfs.)

@rmacklem, 'vfs.root.mountroot' is used as a kernel parameter to specify (or override) where is the root filesystem to be mounted and its partition type. It's usually something like "vfs.root.mountroot=ufs:/dev/da0s1a" if you use a local disk, or "vfs.root.mountroot=nfs:192.168.0.1:/tftpboot/root" if using nfs.

use strncmp instead of strstr in order to match only the beginning of the string

Beyond changing strstr() to a check for "nfs:" at the beginning of the
string, as suggested by sjg@, I don't see a problem with this.

Anything new on this?

edit: commented on wrong revision

Suspending this since it requires changes to continue.
The OS revision part is now being discussed in D34429.

Abandoned due to https://cgit.freebsd.org/src/commit/?id=298c3e8d6b6405cbea13a7a1a1fbc1ad5a45c378

You may cherry pick https://github.com/llvm/llvm-project/commit/53fc5d9b9a0110f097c6e9f7aa3bff3621eaf268 to avoid the local changes.

Or maybe not, I can see some ARM configs also have this, along with comment [KEEP THIS!].

sys/powerpc/conf/MPC85XXSPE also includes COMPAT_43. That should also be removed.

Looks good.

add ports package versions and adjust comments

looking better! Thanks for splitting out the style changes.
Just a couple of bits of feedback for comments.

• style change commited with hash 8d1ab5ad8449e6f51f081e261ed6202a0483a595
• removed COMPAT_FREEBSD8 from config files, since it doesn't exist.

Makes sense. In that case, I think this is good

In D33421#755638, @imp wrote:

Also, I thought that we broke powerpc bin-compat with ELFv2. if so, all these lists are way too long :)

I'd be sorely tempted to commit the style changes separately.
Also, I thought that we broke powerpc bin-compat with ELFv2. if so, all these lists are way too long :)

updated after discussion on IRC

Thanks, I'm gonna make the commit :)

Patch updated with @pauamma_gundo.com comments. Thanks!

@pauamma_gundo.com fixes

Thanks for updating this!

Nice!

Finished full tests (configure petitboot autoboot, install disc1.iso and boot).

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