LGTM

Why is a shim required? All arguments are extended to 64-bits as part of the combat layer. There would be an issue if len were an off_t, but it's a size_t. The only pointers point to off_t's which are always 64-bit and thus require no special handling.

This looks like it provides a viable update path. As you say, libc may have some edge case issues, but it does look like it does the job of letting people upgrade without a reinstall from media. What do you think about about timing this change? It seems like it should happen close to the ELFv2 switch so people get the whole thing out of the way at once.

• Detect old auxargs constant and translate them (from bdragon@).
• Put freebsd_fixup_old_auxargs under #ifdef powerpc.

OK, I wasn't sure exactly how the bits in rtld were going to go. It doesn't look like this is going to be as much help as I'd hoped.

• Use the correct AT_COUNT value, not the CheriBSD one.

Did you apply a manual bump of __FreeBSD_version and P_OSREL_POWERPC_NEW_AUX_ARGS? That part of the patch is now out of date.

I found this in our CheriBSD diffs. I'm not sure how @arichardson ran into it.

NetBSD just committed these changes and some others just now. I'm waiting for cvsweb to update so I can check what was actually committed.

Submitted upstream: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54382

While we should probably just do in amd, these are easy fixes and there's no upstream conflicts to worry about (last am-utils release in 2014 and their git server don't seem to host a repo.

It seems deeply weird that a program would set these flags with mprotect, but this change seems fine (modulo changing the error to EINVAL).

• Call __sys_nmount from the mount wrapper.

LGTM

I've addressed the main technical concerns (other then which syscall implementation to call). If we agree to move forward with this patch I can address style(9), but don't want to spend the time unless it's going to land in FreeBSD.

• Explain magic numbers in comments.
• Make supported_fs static.
• Use nitems() rather then a NULL terminated array.

mips64 (with CHERI) boots with this patch applied.

If we can actually get rid of amd that would be sufficient for my local uses, but I doubt it's the only consumer.

I've glanced at the mips bits and the manpage updates and they look ok.

LGTM

I'd eventually like to move mount(2) under COMPATXX, but that's probably a long road. I've talked to one storage vendor who hasn't migrated their internal filesystem to nmount yet which suggests there are more.

In D18880#447409, @emaste wrote:

In D18880#447406, @brooks wrote:

One last thing before I commit this version. I'm trying to decide if I care about being able to detect PROT_MAX(PROT_NONE) and mostly leaning towards "no, use MAP_GUARD instead". Any alternative views?

IMO "use MAP_GUARD" is fine and if we really need to we can revisit after we have some experience with arbitrary software.