Using C++17 means we can get rid of many `#ifdef`s by using `if constexpr`.
This way, we ensure that both branches compile and still retain zero runtime
overhead.
Note that open source builds of Sandboxed API do not ship with sanitizer
configurations yet. This will be added in follow-up changes.
PiperOrigin-RevId: 354932160
Change-Id: I3678dffc47ea873919f0a8c01f3a7d999fc29a5b
Also accept `absl::string_view` and `absl::Span<const std::string>` arguments.
Drive-by:
- Move using declaration into namespace
PiperOrigin-RevId: 354271016
Change-Id: Iadd873377e51cac7fa3800aab1f9e85ff94bd4e9
Only externally visible changes should be a few changed includes as well as
some formatting changes.
PiperOrigin-RevId: 353226662
Change-Id: Iebf5be13774efcbd94c5d5a17b9b27e47275b229
This change should make it less confusing where utility code comes from.
Having it in two places made sense when we were debating whether to publish
Sandbox2 separately, but not any longer.
Follow-up changes will move `sandbox2/util.h` and rename the remaining
`sandbox2/util` folder.
PiperOrigin-RevId: 351601640
Change-Id: I6256845261f610e590c25e2c59851cc51da2d778
This also allows to install `libclang1` instead of `libclang1-dev` as
one of the build dependencies on Ubuntu/Debian.
Signed-off-by: Christian Blichmann <cblichmann@google.com>
This change enables support for 32-bit ARM, as used by embedded controllers and older phones.
Note: This does not support 32-bit sandboxees on AArch64. Both sandboxee and host code must have the same bitness.
PiperOrigin-RevId: 347835193
Change-Id: I6395882677530f9862f118d2dc10230a61049836
Because any change that touches continuous integration needs a companion o.O
PiperOrigin-RevId: 347769780
Change-Id: I20525aaac2ce41c48f619b641baa31e880432e50
- Ubuntu 18.04 ships with GCC 7, which needs `std::move()` when returning an `absl::StatusOr<>`
- Ignore C++ AST nodes of type `cindex.TypeKind.UNEXPOSED` in Python generator
- Remove default values in `ubuntu-cmake.yml`
PiperOrigin-RevId: 347605109
Change-Id: Ibe167249ecf4ef1af1654d63c2e067fc02e5782d
This allows resource-constrained environments to benefit from the
space savings of dynamic linking. This is not meant to be used in
the general case.
PiperOrigin-RevId: 347398828
Change-Id: Ia634959148a31159878f48c44255dd733424a2b8
FS checks are an internal feature that has been deprecated for a while in
favor of user namespaces.
PiperOrigin-RevId: 347378761
Change-Id: I1d7956cecd6db47b2b96fdedaada0b2a36f9b112
The defined raw logging macros should be compatible with Abseil and
we can remove our version once Abseil releases theirs.
PiperOrigin-RevId: 347354273
Change-Id: I178a89cfd2e19bcd707a06fa9dfd7b767e2b654b
- Bazel: Use "incompatible" flag to fix fully static linking. The flag will
become the default in Bazel 4.0.
- Bazel: Deduplicate features into `FULLY_STATIC_FEATURES` variable
- CMake: Remove the testcase properties. `sapi::base` already sets
`POSITION_INDEPENDENT_CODE`. Note that `-pie` is incompatible with `-static`
and `-static-pie` requires GCC 8 and GLIBC 2.27.
PiperOrigin-RevId: 346952478
Change-Id: I7a317c90a3bec9691b13df1a00e3fddf4481df4d
The default policy causes immediate termination of a sandboxee that
calls `bpf`(2).
This does not allow for try-call use of `bpf()` to test for optional
features.
To support such try-call use cases, sandboxes would like to say:
```
sandbox2::PolicyBuilder builder;
builder.BlockSyscallWithErrno(__NR_bpf, EPERM);
```
but this doesn't work because the default policy unconditionally treats
`bpf()` as a sandbox violation.
Remove the bpf violation check from the policy if `bpf()` is explicitly
blocked with an errno.
PiperOrigin-RevId: 345239389
Change-Id: I7fcfd3a938c610c8679edf8e1fa0238b32cc9db4
The lookup is not on the hot path and this removes the SYSCALLS_UNUSED macros.
PiperOrigin-RevId: 344240762
Change-Id: I324bd798945851ac0b92e257206525eab4ec36e5
The semantics of the example remain unchanged. This change is in preparation
for the new Clang based header generator, which will parse most files in C++
mode. `ptrace`'s first argument cannot me implicitly converted from `int` in
C++.
PiperOrigin-RevId: 343280691
Change-Id: Ibc5318b19a48f1dad441e7dcdc318dc5ea6837f6
Updates syscall arguments mostly according to this list and more recent kernel sources:
https://chromium.googlesource.com/chromiumos/docs/+/master/constants/syscalls.md#x86_64-64_bit
The list includes some more syscalls that were recently added.
Follow-up changes will do the same for x86-32, POWER and AArch64.
PiperOrigin-RevId: 341016698
Change-Id: If1771fd37a47b227ca8f572704a64190e4621a38
No need for the smart pointer indirection when an `std::vector` can also hold
the BPF policy.
PiperOrigin-RevId: 340809220
Change-Id: I8a63567e8042d9ff875cba739e8552db87b6901a
If the sandboxer calls `IPC::EnableLogServer()` (and modifies the sandbox policy
accordingly), sandbox logs will be sent back to the sandboxer.
PiperOrigin-RevId: 340663308
Change-Id: I5e8d89314178dfd1b49fc25b8cd2dd02642be43a
This change allows us to emit forward declarations to classes that are
templated. For headers generated by the proto compiler this is sometimes
necessary.
Note:
- This will only emit types for a single level of template instantiations.
That is, template template arguments are not supported.
- Typedefs only occurring in template arguments will be fully desugared
and thus will not be available under their aliased name in the generated
API code. This is consistent with the Python based generator (which
does not emit these at all and relies on text extraction).
Signed-off-by: Christian Blichmann <cblichmann@google.com>
This change includes a small refactoring to remember which types the generator
has already seen during header generations. Otherwise we may loop indefinitely
on certain complex types. One such type is `std::FILE` in Clang's libc++.
PiperOrigin-RevId: 335589238
Change-Id: I5bbe03b6c7fc89c743163f5534075d7912ed4e58
- Use a `constexpr inline` string constant for the forkserver env var
- Add annotation for the comms channel mutex
PiperOrigin-RevId: 335395005
Change-Id: Ic058c19c3704f182aa7ed7b8e8964b2fc5082800
We need to add the `oss-internship-2020` and `examples/hello_sapi`
directories to `.bazelignore`, so that `bazel build ...` works on a clean
working copy. This is because the Bazel builds in these directories use their
own `WORKSPACE.bazel` and this does not nest well, leading to all kinds of
hard to debug errors.
PiperOrigin-RevId: 333728800
Change-Id: Ie2e68dd39bf6f8eb21af29d8ae3ae12971b408db
Ignore cursors with types that are not implemented in python bindings
PiperOrigin-RevId: 333708345
Change-Id: I618a61c960247a9bdf89bc56dcac92e2d37b3220
- Support multiple input files
- Better testability
- Support for the `--sapi_isystem` argument, same as the Python generator
PiperOrigin-RevId: 333686891
Change-Id: I3e618165c1bd58bb755e1193617fb0737c29ee77
The Bazel build already queries the current toolchain for its system include
directories. This change brings feature parity and is necessary for systems
with unusual include locations.
PiperOrigin-RevId: 332195812
Change-Id: Ie81d614d21e90b4bd9edf2084ef80bf0d85dd750
This is a work in progress:
- Syscall tables need work
- Only tested on real hardware using one of our test hosts
As a drive-by, this change also enables the open source version to function on
POWER.
Another side-effect of this change is that the default policies no longer
check for different host architectures at runtime. On x86_64, we do not need
to check for PPC or AArch64 specifice and vice versa.
PiperOrigin-RevId: 331137472
Change-Id: Ic6d6be5cbe61d83dbe13d5a0be036871754b2eb8
This allows us to remove some uses of macros.
Related changes:
- Make it clear that we support hosting sandboxed binaries from 64-bit
processes only. CPU architectures are x86-64 and POWER64 (little endian).
- Introduced CPU architecture macros, abstracting away compiler specifics
PiperOrigin-RevId: 330918134
Change-Id: Ife7ad5f14723eec9f68055127b0583b8aecd38dd
This removes our own fork of `absl::StatusOr<>`. Sandboxed API still includes
a custom matcher for Googletest, as that is not open source yet. For
compatibility, the `statusor.h` header is still retained and now aliases
`sapi::StatusOr<>` to `absl::StatusOr<>`.
PiperOrigin-RevId: 329916309
Change-Id: I0544b73a9e312dce499bc4128c28457e04ab9929
- Use default initialization
- Rely on `static_assert()` and use `if constexpr` when checking SAPI
variable type
- Small style fixes
PiperOrigin-RevId: 322107281
Change-Id: I48cf43f354b60e31e6207552dbbfa16e3acd5615
- Drop `delim` argument from the `GetStackTrace()` family of functions.
We only ever used plain spaces.
- Use an `std::vector<std::string>` for the symbolized stack frames and
adjust the unwind proto accordingly.
This change now prints each stack frame on its own line while skipping
duplicate ones:
```
I20200717 11:47:16.811381 3636246 monitor.cc:326] Stack trace: [
I20200717 11:47:16.811415 3636246 monitor.cc:337] map:/lib/x86_64-linux-gnu/libc-2.30.so+0xceee7(0x7fb871602ee7)
I20200717 11:47:16.811420 3636246 monitor.cc:337] Rot13File+0x130(0x55ed24615995)
I20200717 11:47:16.811424 3636246 monitor.cc:337] ffi_call_unix64+0x55(0x55ed2461f2dd)
I20200717 11:47:16.811429 3636246 monitor.cc:337] map:[stack]+0x1ec80(0x7ffee4257c80)
I20200717 11:47:16.811455 3636246 monitor.cc:339] (last frame repeated 196 times)
I20200717 11:47:16.811460 3636246 monitor.cc:347] ]
```
PiperOrigin-RevId: 322089140
Change-Id: I05b0de2f4118fed90fe920c06bbd70ea0d1119e2
Initializing `absl::Span`s like by assigning them from a temporary
array leaves them pointing to invalid data. Due to the way the linker
initializes these constant tables, _most_ of them will still be valid
_most_ of the time, leading to crashes when running sandboxees with the
`--sandbox2_danger_danger_permit_all_and_log` option.
PiperOrigin-RevId: 321112099
Change-Id: I891118da08cbb6000b3e2e275618bc4edaa1d020
Bazel 3.x now requires specifying `commit`, `tag` or `branch` in its
`git_repository` rule.
PiperOrigin-RevId: 320572176
Change-Id: I81048d997f595202f4dfbd3c1e9c8321240a28a3
Otherwise ExecuteProcess is implicitly `[[noreturn]]` and this
might cause policy violations in `__asan_handle_no_return`
for ASAN builds.
PiperOrigin-RevId: 319203128
Change-Id: I5c8ba71ce88261f803aa3f16730eccea0d803dd1
--
fd2e99fa87c34f2fb1a20052c030ad7a4139b4e1 by Christian Blichmann <mail@blichmann.eu>:
Support LLVM >= 7.0.1 in Clang based header generator
This change glosses over small API changes introduced since LLVM/Clang
7.0.1, which ships with Debian Stable "Buster". Ubuntu 18.04 LTS "Bionic"
also shipped this (and subsequently updated to version 9).
Hence, compiling the generator should now work on all reasonable Debian
based distributions.
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/sandboxed-api/pull/44 from cblichmann:20200609-llvm-version-compat fd2e99fa87c34f2fb1a20052c030ad7a4139b4e1
PiperOrigin-RevId: 315637014
Change-Id: I6585041d8bebade15e44c057b1a69287bbc0e733
The "hello_sapi" example lives in a different WORKSPACE as it is intended to
show how to embed SAPI in your own projects. However, this is not compatible
with simply running `bazel build //sandboxed_api/...` after checkout.
This change simply replace `copts = ["-I."]` with `includes = ["."]`, so that
generated headers can be found reliably, regardless of how the example is
compiled.
PiperOrigin-RevId: 313782756
Change-Id: Iac26e828146b01545c81d9500f5f68fa0f2d4ddf
- Extract dependent types directly from the Clang AST and re-serialize
back into compilable code
- Collect types and emit diagnostics
- Format generated code
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
This change contains a "hello world"-style example library to be
sandboxed. It consists of a stand-alone CMake and Bazel project that
uses Sandboxed API as its dependency.
To use Sandboxed API in an external project, it should be enough to
copy the files in the `sandboxed_api/examples/hello_sapi` directory
as a starting point.
When using SAPI from an external project via CMake, the small zlib patch
cannot be found during the config phase.
This change also fixes an oversight in that the tests depend on some of
the example code.
Regardless embedding code should set `SAPI_ENABLE_EXAMPLES` to `OFF`.
Disabling tests by setting `SAPI_ENABLE_TESTS` to `OFF` stays optional.
PiperOrigin-RevId: 311290454
Change-Id: Ibe105895859b793b20f47c89b1a9e11cbfef2e2f
Build macros in earlier versions of Bazel (pre-1.0) needed to specify
targets in a different format, depending from where they were
included/expanded at build time.
For example, a `sapi_library()` macro invocation in one of the directories
under `examples`, always needed to depend on the SAPI main library as
`//sandboxed_api:sapi`. When using SAPI from another Bazel project, the
same macro would have needed to depend on
`@com_google_sandboxed_api//sandboxed_api:sapi`. The `sapi_library()`
macro was thus checking the repository name and conditionally changed
the dependencies. This approach is brittle and as of Bazel 3.1.0 no
longer works.
This CL simple removes the conditional prefix and unconditionally uses
`@com_google_sandboxed_api`.
Tested on Bazel 1.2.1, 2.2.0 and 3.1.0
Similar to what the Bazel build does, this change adds zlib as an additional
dependency when `SAPI_ENABLE_EXAMPLES` is set to `ON`.
PiperOrigin-RevId: 309203959
Change-Id: I201a9e6415789afb1e058bc48cebbc0fc0004fe9
BoringSSL (which is the crypto library used by most Google products) is starting to use madvise(_, _, MADV_WIPEONFORK) to protect random-number state from being duplicated by fork(). This causes extra madvise calls that sandboxes need to permit in order to continue functioning.
PiperOrigin-RevId: 309173849
Change-Id: I007dacc1ff1fd0ccc138caaa08735cfe5bc78234
Fixes some template issues that could lead to code not compiling when it
otherwise should.
PiperOrigin-RevId: 308809964
Change-Id: I9f2f9d4aff5f1a9cb967fb705a86fd7f49114f7a
The underlying issue is with a Copybara transform and the internal Blaze BUILD file.
PiperOrigin-RevId: 308787839
Change-Id: I32af664b3eac4c925d39f50b967756198eff23f3
Note: This intentionally omits perfect-forwarding value assignments. This
avoids overly complex template expressions. The regular assignments are still
efficient.
PiperOrigin-RevId: 304159053
Change-Id: I3460f46ca5779a0619cf90ae22625de8fad7669c
Drive-by:
- Make Bazel config action more robust
- Disable dependency tracking in libunwind configure
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
When embedding SAPI in an external CMake project, the version of
`protobuf_generate_cpp` that we lifted from upstream protobuf produces
the wrong generated file paths.
For example, given this project structure:
```
/parent/
+-- myproject/
+-- myproject_build/ <- CMake build directory
+-- sandboxed-api/ <- Checkout from GitHub
```
And a CMake file in `myproject/CMakeLists.txt` that embeds SAPI like
this:
```
cmake_minimum_required(VERSION 3.12)
project(SandboxedTest LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_subdirectory(
${PROJECT_SOURCE_DIR}/../sandboxed-api
${PROJECT_BINARY_DIR}/sandboxed-api
)
```
Then `protobuf_generate_cpp` correctly invokes the protoc compiler to
generate
`/parent/myproject_build/sandboxed-api/sandboxed_api/proto_arg.proto.pb.cc'.
However, the path of the generated source file that is passed to the C++
compiler will be
`/parent/myproject_build/sandboxed-api/sandboxed_api/../../myproject_build/sandboxed-api/sandboxed_api/proto_arg.pb.cc`.
Note the duplicated project build directory component in the
canonicalized version:
`/parent/myproject_build/myproject_build/sandboxed-api/sandboxed_api/proto_arg.pb.cc`.
This change simple omits the computation of any relative file paths and
simply uses `_pb_PROTOC_OUT_DIR` which defauls to
`CMAKE_CURRENT_BINARY_DIR`, which should always contain the correct
path.
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
Created documentation for network proxy. fixed 2 things in documentation (namespaces are enabled by default for a while).
PiperOrigin-RevId: 300321016
Change-Id: Id9c54b29551e8d3b70e814e2fdbfee594126aa90
Currently we extract all functions from the compilation unit - it doesn't really make sense as it will try to process functions in included files too.
As we require sapi_in flag, we have information which files are of interest.
This change stores the top path in _TranslationUnit and uses it when looking for function definitions to filter only functions from the path we provided.
PiperOrigin-RevId: 297342507
Change-Id: Ie411321d375168f413f9f153a606c1113f55e79a
The next release contains one major change: for function parameter annotations,
pytype will no longer treat (x: X = None) as equivalent to
(x: Optional[X] = None). This pytype behavior was based on an outdated version
of the type-checking spec. Annotations that were relying on the behavior now
need to explicitly declare themselves as Optional.
PiperOrigin-RevId: 297065077
Change-Id: Iade679e5928bb3839485e8b8571945456ba6e982
Sending -1 as fd will fail and take forkserver down.
This should not happen normally so turned it into a check.
PiperOrigin-RevId: 285391908
Change-Id: Idbb05004c36cb0be57be1bd26df1c57cecfb0019
- Same upstream dependency versions for CMake and Bazel
- Use maybe() from build_defs to conditionally define Bazel repositories
PiperOrigin-RevId: 282331418
Change-Id: I8a7db84a1d3115f3c1f31cc1dfcc8c29fe391a62
Practically all current compilers fully support C++17 by now, with the exception of `filesystem` (which we won't use).
PiperOrigin-RevId: 281494879
Change-Id: Ia0ef650ede4e5907e4a6421b8ad11743c8bae88f
This addresses a latency issue - chroot_fs_refs called inside pivot_root
in the kernel can take several milliseconds on machines with many threads
running.
This might not always reduce latency for custom forkservers, as additional
fork can be more costly than pivot_root.
PiperOrigin-RevId: 281306284
Change-Id: If503ac76a70e5438e94caf708d79cb0219c66def
The previous one was not quite correct in cases where the outside binary path
did not match the inside path. This should be fixed with this.
PiperOrigin-RevId: 276075886
Change-Id: I1c7c4fa0191960437a2d2360b805c7098b1407c9
Caused failures if root is mounted as nodev, nosuid etc.
Root is pivoted and unmounted right after this anyhow.
PiperOrigin-RevId: 273707731
Change-Id: I75f1edaf2877c096e4f5bb7dc1b2bb8eb5c437a3
