Linking for convenience, a cgit range that inclues the four commits: https://cgit.freebsd.org/src/log/?qt=range&q=7f4e724829e556fc646056669c2af3551b7e8724...67af9aba6b144789734289443a5f90a3ca716dbe

In D30332#691452, @pitwuu_gmail.com wrote:

In D30332#691205, @dchagin wrote:

Im don't understand what do you mean, I mean that musl it's a separate brand, see Elf_Brandinfo and linux_sysvec.c,
and only for musl brand we should change cmp_requeue, for glibc brand cmp_requeue should return EINVAL

Well. No. Musl doesn't have different brands for the elf files, only the path of the interp differs, and in any case we are a Linuxulator, not a glibculator, it's better to just remain agnostic of the userland and let it sort itself out like is expected of the kernel.

If there's a quirk for some ancient glibc version then make that a knob somewhere or break it in favour of modern (read from this decade) versions.

In D30332#691205, @dchagin wrote:

Im don't understand what do you mean, I mean that musl it's a separate brand, see Elf_Brandinfo and linux_sysvec.c,
and only for musl brand we should change cmp_requeue, for glibc brand cmp_requeue should return EINVAL

Im don't understand what do you mean, I mean that musl it's a separate brand, see Elf_Brandinfo and linux_sysvec.c,
and only for musl brand we should change cmp_requeue, for glibc brand cmp_requeue should return EINVAL

FWIW, splice: https://reviews.freebsd.org/D30597

we have so many such unfinished things

In D30378#684094, @trasz wrote:

FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono

Why do we need it? All the BSD's seem to exist without splice() just fine?

The most pressing issue is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.

https://wiki.freebsd.org/Linuxulator#Roadmap, pi is not the key, we have so many important holes

It's literally the second item on that list, for example pulseaudio hard crashes because it's not there. I have started but it's pretty hard, I wonder if anyone can help?

FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono.

In D30378#684088, @dchagin wrote:

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

some time ago I wrote splice emulation via dofileread/dofilewrite ) but I abandoned it because I think we need a native splice() and tee() implementation. feel free to as arch@ about it:)

In D30378#684088, @dchagin wrote:

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

some time ago I wrote splice emulation via dofileread/dofilewrite ) but I abandoned it because I think we need a native splice() and tee() implementation. feel free to as arch@ about it:)

The most pressing issue is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.

https://wiki.freebsd.org/Linuxulator#Roadmap, pi is not the key, we have so many important holes

I don't think they are even usable, since the core file is in FreeBSD format that linux gdb can't parse, and confuse the freebsd gdb because it's a linux process/elf.

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

In D30378#684071, @dchagin wrote:

In D30378#684069, @pitwuu_gmail.com wrote:

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

we have so many such unfinished things, like arm linuxulator, splice sys call....

In D30378#684069, @pitwuu_gmail.com wrote:

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

In D30378#684066, @emaste wrote:

Is there a way to config git to do that by default? It's annoying to do every time.

I'm not sure, although I also suspect you don't want it when generating a patch for your own review, not for upload to Phabricator. There is a tool in the tree, tools/tools/git/git-arc, which can take care of submitting phab reviews for you.

Is there a way to config git to do that by default? It's annoying to do every time.

In D30378#683157, @emaste wrote:

For future uploads please include full context by using e.g. git show -U99999 <hash> - see https://wiki.freebsd.org/Phabricator for details

hi, what is the purpose for this? it will be used read only. so what is the program depend on it?

For future uploads please include full context by using e.g. git show -U99999 <hash> - see https://wiki.freebsd.org/Phabricator for details

In D28154#680209, @kib wrote:

Do we have an agreement there?

I think that switching the defaults, if ever, should be done by separate change indeed.

Do we have an agreement there?

All kinds of cases, tbh - from sudo apt update, to Chromium, which (for some reason) depends on a setuid helper.

In D28154#677706, @trasz wrote:

I've tested this patch for both 64, and 32-bit Linux binaries, for both suid and sgid bit, and it works just fine.

One nit, though: I'd strongly prefer the sysctl to be enabled by default, ie to permit suid/sgid by default. Otherwise it will break some pretty common use cases.

Switch to allow by default

I've tested this patch for both 64, and 32-bit Linux binaries, for both suid and sgid bit, and it works just fine.

Sure, I'll test it.

Rebase.
Add some explanation to man page.

In D28154#676439, @trasz wrote:

Note that I'm not in any way opposed to this change.

Also, there's now a review which shows what I've meant with NO_NEW_PRIVS flag: https://reviews.freebsd.org/D30130. It reuses a part of this patch, but is otherwise orthogonal.

Note that I'm not in any way opposed to this change.

Fully support this change and motivation, propose to add a short description to the linux(4) manual about sysctl

Also: I wonder if we could start allowing chroot(2) for non-root users, as long as the calling process has the NO_NEW_PRIVS flag set.

I'm not convinced about the environment, tbh. Can you give some specific example of what we don't provide, that could affect security of suid binaries?

Motivation is provided by the notes in the referenced PR. Briefly, convincing argument for me was that we do not provide environment that would be expected by the linux setuid binaries, so assumptions made during coding of them could be broken by us unknowingly. More, I should add that it is possible that user break them due to our /compat/linux+normal freebsd fs fallback setup.

I'm not sure this is all that useful, to be honest. What's the usage scenario? Why would one globally disable suid for Linux binaries?

Make changes on source file instead of file in destination location (/etc/rc.d/linux). Use sysctl-variable for all occurences of hardcoded path of /compat/linux.