Linking glibc in fully static mode is mostly unsupported. While such binaries
can easily be produced, conflicting symbols will often make them crash at
runtime. This happens because glibc will always (try to) load some dynamically
linked libraries, even when statically linked. This includes things like the
resolver, unicode/locale handling and others.
Internally at Google, this is not a concern due to the way glibc is being built
there. But in order to make all of our tests run in the open-source version of
this code, we need to change strategy a bit.
As a rule of thumb, glibc can safely be linked statically if a program is
resonably simple and does not use any networking of locale dependent
facilities. Calling syscalls directly instead of the corresponding libc
wrappers works as well, of course.
This change adjusts linker flags and sandbox policies to be more compatible
with regular Linux distributions.
Tested:
- `ctest -R '[A-Z].*'` (all SAPI/Sandbox2 tests)
PiperOrigin-RevId: 429025901
Change-Id: I46b677d9eb61080a8fe868002a34a77de287bf2d
- Link `zipe.c` statically (safe)
- Update policy to allow any use of `stat()`
PiperOrigin-RevId: 428971638
Change-Id: Ib0f5f496ea2389582986b41a8830592e6c1d4390
This is mainly so that the structure of the examples follows what we do
internally (not having separate directories).
PiperOrigin-RevId: 402298115
Change-Id: I0f542607b88597572de39532364816f80a076697
These were previously dependent on an internal-only testing target.
For now, this only works with Bazel, but should enable us to have better test coverage in GitHub actions.
Eventually, all of these shell-based tests should be converted to `cc_test`s.
PiperOrigin-RevId: 400713615
Change-Id: I1cabb5b72977987ef4a1803480f699b58c4d56e9
This was missing a friend declaration in order to actually compile.
It's now being used in the "stringop" example, so we test it as well.
Drive-by:
- Do not copy the proto's bytes the constructor, but use `std::move`
PiperOrigin-RevId: 387774353
Change-Id: Ic8824af911ac744e2e68130e1f4673c4dddd4939
Depending on architecture and optimization level, the compiler may choose to
not generate full stack frames, even with no-inline and no tail-call
attributes.
PiperOrigin-RevId: 372339987
Change-Id: I42043131bbb6092ff234e80ae9047f7a2bf31161
This fixes tests for PPC, where the tail-call optimization would consistently
remove 'violate()' from the stack trace.
PiperOrigin-RevId: 371103794
Change-Id: Ifb1a7d588a455041a6b0f3c763276ed44de47e60
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
Only externally visible changes should be a few changed includes as well as
some formatting changes.
PiperOrigin-RevId: 353226662
Change-Id: Iebf5be13774efcbd94c5d5a17b9b27e47275b229
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
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
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
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
Bazel 3.x now requires specifying `commit`, `tag` or `branch` in its
`git_repository` rule.
PiperOrigin-RevId: 320572176
Change-Id: I81048d997f595202f4dfbd3c1e9c8321240a28a3
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
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
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
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>
These where inadvertently introduced in an internal cleanup change.
This change also removes a C++17-ism in var_proto.h. To make things easier for
downstream projects, we should stick to C++11 for the time being.
PiperOrigin-RevId: 271117700
Change-Id: I4eaacec88be16e1a561d3f77a61acce0a1af0b9d
