Seems reasonable to me: this is now completely irrelevant for x86, and yet completely insufficient for the trouble that will be encountered migrating e.g. MIPS from GCC to Clang

Sounds good.

In D20757#451657, @trasz wrote:

fanotify_init(2)           2.6.37
fanotify_mark(2)           2.6.37

prlimit64(2)               2.6.36

We have those.

I see the following after 2.6.32 and up to and including 3.2, with uninteresting ports (e.g. m68k) excluded:

recvmmsg(2)                2.6.33
prlimit64(2)               2.6.36
fanotify_init(2)           2.6.37
fanotify_mark(2)           2.6.37
clock_adjtime(2)           2.6.39
name_to_handle_at(2)       2.6.39
open_by_handle_at(2)       2.6.39
syncfs(2)                  2.6.39

rebase

Overall looks reasonable, a few small alpha ordering nits.

@imp asked on IRC what would happen if run on a kernel without the kern.build_id sysctl - it would report:

volta% usr.bin/uname/obj/uname -b
uname: sysctlbyname: No such file or directory

@imp asked on IRC what would happen if uname was run on a kernel without the kern.build_id sysctl - it would report:

volta% usr.bin/uname/obj/uname -b
uname: sysctlbyname: No such file or directory

FWIW I have sent links to this change to OpenBSD, NetBSD and DragonFly BSD developers.

@rgrimes would you help coordinate with re@?

We should perhaps use "Reported by:" instead of "Security:" for the xen link

Ideally we'd commit changes upstream and then import a new version with a latency of several days or a week or so but that process seems to be somewhat slow right now so I'm fine with just committing to FreeBSD and then having @markj or me work on upstreaming changes in batches.

Presumably _dwarf_strtab_init is guaranteed to be called?

Also is it the case that /bin/echo 1 1 1 1 1... consistently fails with some number of 1s and runs successfully with other cases? Like 1 1 1 works, 1 1 1 1 fails, 1 1 1 1 1 works?

Do you have more details about working/non-working versions? I.e., what glibc version works?

LGTM once dependencies are resolved, of course.

Do we have a list of syscalls/interfaces by kernel version anywhere?

Note that Git can internally store a generation count (tree height) and if that's a suitable proxy for us that can be instantaneous to calculate, however within a given branch a given generation count does not necessarily identify a unique commit.

LGTM

From another NetBSD commit:

In D18880#447418, @brooks wrote:

I think it's also something we can easily add later, just swipe another bit from the top half.

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?

In D18880#447397, @brooks wrote:

It wouldn't be too hard to implement that instead if it seems like the right thing to do. It would do what I need for CHERI. Unfortunately, it lacks a way to downgrade max_prot later in mprotect(). We don't have any examples of the latter, but it does seem like something that could be useful in a JIT that avoids flipping back and forth between W and X.

Interesting, NetBSD has a related change from 2017: https://github.com/NetBSD/src/commit/6508f5143a1028fc68b4de2151c3a33f65eece53
They list "extra" perms that may be added later rather than the full list.

Yea, that's recent to reuse boot1's makefile for gptboot, but have the FAT stuff not done. It's not supposed to be a user controlled knob. If you want *THAT* then you could add a MK_LOADER_EFIFAT_BLOBS and have it default to NO.

In D20562#447320, @emaste wrote:

Are they already unhooked from install?

In D20562#447315, @bcran wrote:

I'm not sure it's worth moving them, but I can commit the OptionalObsoleteFiles.inc and ObsoleteFiles.inc changes if you think that makes sense.

In D20562#445313, @bcran wrote:

In D20562#445261, @andrew wrote:

Is there a way to build the efi fs this without root? I build images in a Jenkins instance to test FreeBSD/arm64 on various simulators and would prefer to not need to give the Jenkins user sudo access.

There's a review from July 2018 at D16438 to add msdos support to makefs, but it seems to have stalled. But otherwise, root access will be needed.

LGTM

Would be good to put some reference to determining the appropriate bogomips value, either as a comment in the code if there's something reasonable you can link to, or in the commit message if you just found this case by observation (e.g., something like "on the same hardware I noticed that Linux's real bogomips value was twice that that we reported" if that's the case).

Minor point, I wouldn't call this "silently ignored" - the console message will be gone but we still return error, except a different error.

Mentor approval for commit.

LGTM

In D18038#446790, @reg wrote:

Fails with WITHOUT_CAPSICUM...

Related links courtesy of Ed Vielmetti:
https://bugzilla.tianocore.org/show_bug.cgi?id=625
https://github.com/tianocore/edk2/commit/6d73863b5464f382af2a17b2c2ec1abc550d0af5

With @markj's KASSERT change the panic at startup is fixed and now the existing mmap_test tests pass (with and without imply_prot_max).

Testing in my wipbsd branch worked on Cirrus-CI for the basic QEMU smoke test but failed on packet.net with the full system:

Some straightforward ad-hoc testing looks good.

I've imported the update into my testing tree (after encountering the boot failure on the previous version) and it works fine.

Spleen fonts from https://www.cambus.net/spleen-monospaced-bitmap-fonts/
Requires vtfontcvt changes from D20650

Correct typo (; instead of , in variable definition)

Can use spleen font for testing.