For go specifically, I find ko-build handy. It builds on the host (leveraging go crosscompilation and taking advantage of caches) and outputs a Docker image.
> How to manage pointer+offset address integrity/legality inside the kernel (for instance) has a proof by examples a-plenty in the other code
Let me provide some context here. These annotations aren’t there to help the compiler/linter. They exist to aid external tooling. Kernel can load BPF programs (JIT-compiled bytecode). BPF can invoke kernel functions and also some kernel entities can be implemented or augmented with BPF.
It is paramount to ensure that types are compatible at the boundaries and that constraints such as RCU locking are respected.
Kernel build records type info in a BTF blob. Some aspects aren’t captured in the type system, such as rcu facet, this is what the annotations are used for. The verifier relies on the BTF.
I do occasionally attempt to edit patch files produced by git-format-patch. Frequently I end up with corrupt patch. Still curious how to fix those numbers.
Hardly. For starters, wasm doesn’t guarantee that a piece of code terminates in bound time. There are further security guarantees in ebpf such as any lock acquired must be released.
Thank you for bpftrace! It was a vital aid for kernel spelunking. Very excited to see vmtest. I did a similar tool in the past [1] but never achieved this level of polish.
> “Chrome 12 [an old version] was the best Chrome", but since I’ve come to see underneath that for me what I wanted was a fast tight browser, and once I had that, pretty much by definition most subsequent work was just gonna make it worse.
Sorry, but I’m failing to see how rootless containers are relevant.
Having multiple user accounts is a legit use case - think e.g. a shared device. A typical Linux package manager’s install is a privileged operation. Homebrew on the other hand gives the user that had originally installed it write permissions to certain directories. This strategy enables sudo-less brew install for the specific user and prevent it from being used by anyone else.
Homebrew the package manager is quite popular but that doesn’t indicate that it is engineered well. For instance, it doesn’t work with multiple user accounts which is such a trivial thing!
This is an impressive effort. I would love to see ignore rules for the particular editors and ideS added to project .gitignore files less frequently though.
Which editor someone uses is a private matter. Don’t commit it to public repositories. There’s local gitignore for that.
As of today, vector’s iterator is just a pointer. You need more than just a pointer to detect out of bounds accesses. It makes old binaries incompatible with new binaries. It also means that you can’t mix and match, it must be either a or b.
Hence you can’t make the change incrementally, which is a big risk.
Concerning Linux distributions, I seriously doubt if they have resources to assess the performance impact across the wide range of software.
Concerning performance impact, we end up with more instructions and more memory accesses and increased register pressure. This has a chance to make things slower.
This is unfortunately ABI-altering, therefore it won’t be possible to selectively enable for projects that want it. It’s a distribution that has either to bite the bullet and say “we are going to pessimize all C++ software”, or err on the safe side and leave it disabled.
The warning about pointer arithmetic is most likely suppressable per compilation unit (for things like tagged pointers).