In D45569#1039675, @brd wrote:If 95% (or 99% or whatever) of our users don't need this, is it worth imposing this somewhat confusing question on the rest?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Thu, Jun 13
Thu, Jun 13
Wed, Jun 12
Wed, Jun 12
Why not change the text of the question to ‘are you dual booting Windows on this computer?’
Fri, May 17
Fri, May 17
May 1 2024
May 1 2024
After this change, ktrace output is littered with 'CAP system call not allowed: $SYSCALL' on systems w/o capsicum enabled
Apr 5 2024
Apr 5 2024
It looks as if this landed without a man page?
Mar 2 2024
Mar 2 2024
Mar 1 2024
Mar 1 2024
Nov 2 2023
Nov 2 2023
Oct 6 2023
Oct 6 2023
I created this patch to make the Capsicumization experience less intimidating for inexperienced developers. Both David and Mariusz may not be the target audience for this change
Oct 4 2023
Oct 4 2023
It's doable in principle, but in practice dtrace's inability to resolve backtraces in the face of fork/exec makes it mostly unusable
Sep 29 2023
Sep 29 2023
Are these events exposed to DTrace? When sandboxing, the thing I really want is a stack trace in userspace at the point where the violation happened. If so, it would be great to include a script that logged them. Ideally with an option of an explicit start marker so you can put in a fake cap_enter and be told what you still need to fix.
Sep 28 2023
Sep 28 2023
To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.
Sep 27 2023
Sep 27 2023
Capsicum-related syscall changes from 2014 on, for reference:
Sep 26 2023
Sep 26 2023
theraven added inline comments to D41936: libc: Rewrite quick_exit() and at_quick_exit() using C11 atomics..
Sep 25 2023
Sep 25 2023
This looks like it fixes the capsicum bits. I believe we're still missing correct auditing events. In kern_{read,write}*, these are handled in dofile{read,write} but, since copy_file_range bypasses these calls, they need to be added explicitly.
Ensure that copy_file_range(2), like pread(2)/pwrite(2), requires the CAP_SEEK capability due to its offset argument.
This alignment prevents unauthorized file offset manipulations by processes.
Sep 23 2023
Sep 23 2023
theraven added inline comments to D41936: libc: Rewrite quick_exit() and at_quick_exit() using C11 atomics..
Sep 22 2023
Sep 22 2023
theraven added inline comments to D41936: libc: Rewrite quick_exit() and at_quick_exit() using C11 atomics..
theraven added a comment to D41936: libc: Rewrite quick_exit() and at_quick_exit() using C11 atomics..
One way out would be to atomic_swap the head to NULL.
theraven added inline comments to D41936: libc: Rewrite quick_exit() and at_quick_exit() using C11 atomics..
theraven added a comment to D41936: libc: Rewrite quick_exit() and at_quick_exit() using C11 atomics..
Is there a reason to write new code that uses atomics and not use C11 atomics? We’ve had support for them for several releases now and it makes code much harder for new developers to understand if it uses nonstandard features for things that are part of the standard.
Aug 23 2023
Aug 23 2023
It looks as if this landed without a man page?
Aug 17 2023
Aug 17 2023
Aug 10 2023
Aug 10 2023
Jun 26 2023
Jun 26 2023
Thanks. You can enable fwcfg by -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd,fwcfg=qemu. You can also add additional item with the -f option. It has the same syntax like the -fwcfg option of qemu (https://www.qemu.org/docs/master/specs/fw_cfg.html#externally-provided-items).
Jun 25 2023
Jun 25 2023
Thanks. I've implemented a NetBSD-compatible kernel interface and tested it with the NetBSD FUSE filesystem:
Jun 13 2023
Jun 13 2023
Yes, exactly. It looks as if NetBSD has such a driver (https://man.netbsd.org/qemufwcfg.4), along with a FUSE FS the shared files into the filesystem. If anyone is working on such a thing for FreeBSD, it would be helpful, otherwise I will have a go next time I have some spare time.
Do you have plans to add the guest part of this device? Currently, Podman uses this mechanism to pass configuration information (specifically, accounts to create and ssh keys) to VMs that it creates to run containers. It would be possible to add an alternative mechanism for FreeBSD (though it’s not clear what that mechanism should be) but if there’s an existing device to grab this config and provide it to userspace that someone is working on then that would be much easier to use.
Mar 22 2023
Mar 22 2023
This looks fine to me. Assuming I'm reading the code correctly, this change is only for targets where int64_t is long, so there should be no change in any C++ / ObjC name mangling as a result of this. It's a bit curious that we explicitly define it as a fixed-width type for 32-bit targets but long for 64-bit prior to this change, did I do that?
Feb 9 2023
Feb 9 2023
12 is getting close to EOL, 14 is close to release, so it's too late for a back-port to 12 to matter to me.
Feb 8 2023
Feb 8 2023
I've rebased this, addressed reviewer comments (except the one that wants me to change some whitespace in a way that I don't fully understand), and tested it again with the Verona process-sandbox code.
- Address some reviewer comments.
LGTM. I thought we had those functions, but I've never seen any code in the wild using them, so if we don't then we should get rid of any reference to them.
Aug 17 2022
Aug 17 2022
The goal is to have tcmalloc natively working with full capacity and without further patching.
Aug 16 2022
Aug 16 2022
I would still like to see a design document and some design review before this is added. This feature in Linux has been quite controversial. I can see a case for copying a Linux feature that is widely used, or for adding a feature in the Linuxulator that is needed by certain workloads, but this doesn't seem to meet either of those requirements (not widely used, not being added to the Linux ABI layer here, only as a native syscall).
Jul 15 2022
Jul 15 2022
Fantastic, thanks!
Jul 14 2022
Jul 14 2022
theraven added a comment to D35815: Remove unnecessary const and volatile qualifiers from __fp_type_select().
This is because the controlling expression always undergoes lvalue
conversion first, dropping any cv-qualifiers
Apr 1 2022
Apr 1 2022
In D33248#764167, @kib wrote:Don't you want to have core dumped for unhandled SIGCAP?
Mar 9 2022
Mar 9 2022
Ah, sorry, I thought these were additional changes. Looking more carefully, these all seem to be things that we've done upstream already.
Please can you raise a PR upstream that adds a macro to select between the two ABIs, so that we're not carrying a diff in the FreeBSD version?
Jan 7 2022
Jan 7 2022
Are there any other blockers to committing this? @markj, please can you approve if not?
Dec 19 2021
Dec 19 2021
It's still not clear what the purpose of this is. It's not added to the Linux ABI. If we're adding a new FreeBSD syscall, there should be some design review or at least motivating use cases. Linux' rseq is mostly useless (far less useful than a lightweight userspace interrupt delivery mechanism or a resume-from-context-switch handler) and is *only* vaguely useful on Linux in combination with the fact that Linux has a lightweight get-CPU system call implemented in the VDSO that is cheaper than a CPUID (which is a serialising instruction and generally costs more than the saving of most of the win from doing per-CPU instead of per-thread things).
Dec 7 2021
Dec 7 2021
- Fix comma splice.
Dec 6 2021
Dec 6 2021
In D33248#752692, @markj wrote:FWIW, I tried the tests for your process_sandbox (with this patch applied of course) and one test consistently fails:
markj@biggie> ./test-onebitsem-child
- Address code review comments.
Dec 3 2021
Dec 3 2021
- Fix copy-and-paste fail.
Oct 18 2021
Oct 18 2021
Again, this is clearly outside the design space of rseq.
Oct 16 2021
Oct 16 2021
In D32505#733678, @kib wrote:Lets limit the discussion to rseq(2) and not to some future hypothetical design needed for CheriBSD (which is not FreeBSD).
In D32505#733659, @kib wrote:In D32505#733654, @theraven wrote:
- For allocator hardening, we'd like to ensure that signals delivered while executing in the allocator don't expose internal allocator state, so we'd like a mechanism somewhat closer to Windows structured exception handling that allows signals to be redirected based on a specific IP range.
Why should this be done in kernel? More, I believe that Windows does not do it in kernel either. Last time I looked (I admit it was very long time ago) they have a single upcall from kernel to userspace for all that stuff. It is usermode duty to interpret signal source + find the corresponding entry in the exceptions ranges table and do the unwind.
More, I think that there is a strong reason why kernel should not do that. You probably need to distinguish between sync and async signals, and further classify them based on si_code before even taking the look at the unwinding, so that only the events you are prepared for, like GC barriers or whatever you know about, started your specific actions. Kernel should not know about all that details.
@brooks, can you take a look at this from a CheriABI perspective? The current version uses the Linux convention of assuming that uint64_t is a sensible type for memory addresses. We probably can't do that in CheriABI because it would allow you to register a jump address that would make other code jump to your handler (or, conversely, it may prevent you from setting a range in some situations where there's a PCC change in between the rseq setup and the destination).
Oct 12 2021
Oct 12 2021
Oct 11 2021
Oct 11 2021
Thanks for doing this, it will make porting our work to FreeBSD easier. There are some missing man pages (both for the new pmap interfaces and for the syscall).
Jul 17 2021
Jul 17 2021
Abandoning: This is probably not the right approach and @jhb is working on something similar so I'll wait for his version.
Jul 16 2021
Jul 16 2021
theraven committed rGcf98bc28d39d: Pass the syscall number to capsicum permission-denied signals (authored by theraven).
Pass the syscall number to capsicum permission-denied signals
Jul 10 2021
Jul 10 2021
theraven committed rGd2b558281aad: Revert "Pass the syscall number to capsicum permission-denied signals" (authored by theraven).
Revert "Pass the syscall number to capsicum permission-denied signals"
@brooks, this should also be useful for combining CHERI coprocesses with Capsicum (coprocesses are currently created with vfork + coexecve).
theraven committed rG3a522ba1bc85: Pass the syscall number to capsicum permission-denied signals (authored by theraven).
Pass the syscall number to capsicum permission-denied signals
Jun 25 2021
Jun 25 2021
theraven updated the diff for D30635: Pass the syscall number to capsicum permission-denied signals.
- Propagate the field on fork.
theraven updated the diff for D30635: Pass the syscall number to capsicum permission-denied signals.
- Add missing siginfo(3) documentation.
- Propagate the field on fork.
theraven updated the diff for D29185: Pass the syscall number to capsicum permission-denied signals.
- Add missing siginfo(3) documentation.
Jun 4 2021
Jun 4 2021
Let's try option 2 and see if it works :-)
I've never used git send-mail, how does it interact with Phabricator? If I do a rebase / squash to produce a single commit, is that sufficient? You should be able to then arc patch and git push.
Thanks. Please can you commit if you're happy with it?
theraven updated the diff for D29185: Pass the syscall number to capsicum permission-denied signals.
- Use less-ambiguous terminology.
theraven updated the diff for D30635: Pass the syscall number to capsicum permission-denied signals.
- Use less-ambiguous terminology.
Can rfork (or pdfork / vfork / whatever) both fail with a capsicum violation *and* create a new struct proc and return in the child context with a signal? That should be the only case where you need to duplicate the original_code field into the child.
12-STABLE version is D30635.
Thanks. I think I'm happy for this version to land in main if reviewers are and I'll work on a version for 12- and 13-stable.
theraven updated the diff for D29185: Pass the syscall number to capsicum permission-denied signals.
- Reorder original_code to fit in padding for 64-bit archs.
Mar 16 2021
Mar 16 2021
theraven added inline comments to D29185: Pass the syscall number to capsicum permission-denied signals.
In D29185#655877, @kib wrote:In D29185#655872, @theraven wrote:By themself, syscall_args are not used by anything but syscall entry code (and some ptrace bits). But the structure is embedded into struct thread, and layout of struct thread must be stable.
Are the syscall_args structures part of the stable KBI? This won't quite cleanly apply to older versions of FreeBSD because at least on x86 the system call entry code has been cleaned up to remove some code duplication, but I am running on 12-STABLE with a version of this that doesn't correctly handle the syscall / __syscall syscalls and it would be great to be able to MFC as much as possible, even if we can't get full support without the KBI change.
theraven updated the diff for D29185: Pass the syscall number to capsicum permission-denied signals.
- Add missing architecture support, address reviewer comments.
Mar 12 2021
Mar 12 2021
Sorry, this version does work, I had only updated one of the places in the code using it to check si_syscall and so the test was failing yesterday.
theraven updated the diff for D29185: Pass the syscall number to capsicum permission-denied signals.
Add amd64 paths to preserve the original system call number.
When do you need this? Isn't this kind of introspection warrants a use of real debugger which can deduce all the data from debugging information?
Mar 11 2021
Mar 11 2021
I appear to be setting the field in the siginfo structure incorrectly in the new version, but it's now the end of the day for me so I will try to debug this tomorrow.
@emaste, sorry, I don't think I understand this comment.
theraven updated the diff for D29185: Pass the syscall number to capsicum permission-denied signals.
Updated based on @kib's feedback.
@kib, thank you, that also mirrors what Linux does for seccomp violation signals. I will update the diff to reflect that.
Mar 10 2021
Mar 10 2021
Feb 1 2021
Feb 1 2021
Thanks, I'll see if I can chase this down later. My commit bit lapsed, please can you land it?
Yes it should be strdup'ed somewhere but I am surprised that it works. Look at the start of load_object(): if name != NULL, it searches for existing loaded object with the specified name.
Thanks. I can confirm that this change also fixes this problem:
Jun 18 2020
Jun 18 2020
For snmalloc, we use this call in the Linux PAL. On FreeBSD, we use mmap to map a new anonymous memory object over the old one, which has the same behaviour. We don't do this on shared memory mappings, but for sandboxing use cases we do need some equivalent mechanism (i.e. something that can zero a large range of shared memory, without requiring the OS to actually allocate physical pages for all of the zeroes). On Linux, we can do this with fallocate on the underlying memory object (I think we can do it with mem_fd objects, we can definitely do it in tmpfs). I am not sure what the correct mechanism for doing this in FreeBSD is.
May 5 2020
May 5 2020
theraven added inline comments to D8188: Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation.
Feb 24 2020
Feb 24 2020
Feb 14 2020
Feb 14 2020
This looks fine, but please submit it as a GitHub PR so that it goes through CI (I can't imagine it failing).
Jan 15 2020
Jan 15 2020