Support libunwind #2
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signal the significant changes that are happening around ptrace usage by bumping the major version up. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The ptrace logic was largely built around the assumption of execing a single static binary and that's it. But there's nothing stopping it from also forking & creating children. Today, that means children do not get tracked for problems. One major known issue is that the sandbox env is frozen upon launch. So once we switch to ptrace mode, it's not possible for traced code to disable sandboxing or otherwise reconfigure it. Currently that shouldn't be a big deal as we assume the main execution environment (i.e. bash) is dynamic, and that's where the env will be tweaked, but we'll have to address this before we can deploy ptrace more. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This allows traced children to change their sandox settings on the fly and the out-of-process tracer will react accordingly. We don't try to read the environ all the time as it's kind of impossible to know where the tracee is storing it (since it can point |environ| anywhere). This means turning the sandbox on/off won't work in the current process, only in forked children. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This code has been buggy since it was first added years ago -- it would read the right value out of the config file, but then always just set $SANDBOX_VERBOSE to it instead of the right env var. This prevented the basic loading of sandbox settings from sandbox.conf. Bug: https://bugs.gentoo.org/821403 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This was added as part of running multiple tracers in parallel in the hopes (hack) it would make logs less intermingled. Unfortunately, it didn't really accomplish that, and it upsets `file` when verbose output is enabled due to file's own seccomp filter (which doesn't have fsync). We could add this to file's seccomp filter (since it's a pretty benign syscall), but easier to just drop it at this point since it's not all that useful. Bug: https://bugs.gentoo.org/821403 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The YAMA ptrace_scope knob restricts access to different ptrace calls depending on the capabilities the current process holds. For now, do not try to ptrace processes when the YAMA level is incompatible with the capabilities that we have. This means we basically cannot protect against processes when they get into this state, so for now, we release them rather than abort. Bug: https://bugs.gentoo.org/771360 Bug: https://bugs.gentoo.org/821403 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Looks like gcc is inconsistent in when it chokes on this code: > a label can only be part of a statement and a declaration is not a statement Hoist the decl up to the top of scope to avoid the issue. Bug: https://bugs.gentoo.org/821433 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
There's no way we can support level 3+ since the kernel blocks it, so give up and inform the user their setup is incompatible. Bug: https://bugs.gentoo.org/771360 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Since we can't trace static children under certain YAMA ptrace_scope settings, skip tests that rely on that functionality. Closes: https://bugs.gentoo.org/821418 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This works around problems when a 64bit qemu is emulating a 32bit architecture. LFS has been present since glibc-2.2 and kernel 2.4. Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
I incorrectly dropped this as unused a while back, but the bashrc hook definitely still relies on it for checking portage settings. I think I got confused by the interaction with SANDBOX_TESTING. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
These messages aren't super useful to most people, nor are needed on every invocation, so put them behind a debug knob to reduce log spam.x Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Current versions of portage don't write these variables to the env file, so manually set them up ourselves. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This reverts commit 19c215f. We do not want different LFS interfaces being used in different modules as it makes debugging a nightmare when different functions think basic structures have different layouts & sizes. This also doesn't address the LFS issues sandbox has when code still crashes in libsandbox itself when checking accesses. Bug: https://bugs.gentoo.org/681892 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This is faster than using stat since it doesn't have to gather all the metadata, and should avoid LFS issues as a result. Bug: https://bugs.gentoo.org/583282 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Since this is only used by sandbox, and is not usable by libsandbox, move it out of libsbutil. Leave a note behind for possible future macros too. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We don't need to support glibc versions that predate Linux-2.6. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Only copy in files that define the macros we need and not ones that reference the macros. This avoids copying a lot unused files in. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Realistically we aren't even testing with older than C11 compilers, but one thing at a time. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Make sure we use 64-bit FS interfaces when accessing the FS. This is needed not only to stat or open large files, but even files with 64-bit inodes. Bug: https://bugs.gentoo.org/583282 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Now that we use 64-bit stat & lstat explicitly everywhere, we don't
need these dynamic redirects for 64-bit wrappers. The off_t define
is only used by one file anymore too, but we can inline that.
That leaves the SB64 define which we use inconsistently in places.
In some 64-bit modules that include the 32-bit, we use SB64 to switch
between the 64-bit & 32-bit APIs. In other places, the 64-bit file
is responsible for redefining the few relevant APIs. Let's switch
all the files away from SB64 and to defining the single thing that
the 64-bit module needs directly. It's either the same or fewer LOC
this way, and doesn't seem any more or less difficult to maintain.
The __64_{pre,post}.h & SB64 define weren't easily discoverable.
Bug: https://bugs.gentoo.org/583282
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Sheng Yu <syu.os@protonmail.com>
|
Don't you need explicit |
|
You mean use AC_SEARCH_LIBS for libunwind and not the header? |
Nah, both. Use header to determine if it's available and libs to see if you need to link anything for it to work (I suspect clang + compiler-rt will require libunwind). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Sheng Yu syu.os@protonmail.com