I do not understand why people continue parroting this performance nonsense.
Memory copying is on the order of 100 gigabytes per second. You can do 80 full payload copys and still out-pace a dog-slow 10 gigabit per second connection. If your bottleneck is memory copying you are either doing something very wrong and doing way too many copys or congratulations you have implemented one of the fastest network stacks.
Supervisor calls are also very fast, on the order of 100 ns up to maybe 1 us with all the Spectre mitigations. Even if you did something as stupid as one supervisor call per packet, you would still be getting on the order of 10 Gbps at the long end there and 100 Gbps at the short end. Which, again, means congratulations are in order because you have implemented one of the fastest network stacks. If you do batching and add just 10 us (us, not ms) of latency then that entire cost is so small as to be irrelevant. You are going to bottleneck on your memory copying first.
Network stacks are so slow almost entirely due to poor protocol design and poor protocol implementation. Usually both.
Oh, so when they advertise “Your Data, Forever and Secure”[1] in big bold letters on their homepage with total disregard for the truth of that statement they are just committing fraud. Got it.
> All social artifacts are stored in Git, and signed using public-key cryptography. Radicle verifies the authenticity and authorship of all data for you.
They're clearly not talking about privacy there.
Is it embarrassing that their private feature was broken? Sure. But it's for the most part a publishing platform. Protecting users against a network adversary who wan't to know what they're publishing isn't exactly core functionality.
Oh indeed, if we just redefine words in the fine print then we can commit fraud with impunity.
Please enlighten me how that blurb supports the common reading of the claim: Your data, … secure. Note that and is a additive conjunction, so the components can be safely examined separately.
A regular person would assume that means your data is secure against tampering and disclosure. If you then say: “lol, jk we do not do anything related to securing your data” in the fine print then in a reasonable society you should be required to remove that more prominent false large print.
You can always go back and reword your large print to be more accurate without making deceptive claims to your benefit. Weird how the deception is always beneficial.
Security is an umbrella term. You can't just assume that secure things are private--you have to make the determination in context with whatever kind of thing it is.
The primary goals of a system like radicle are:
- spread the word
- don't let anybody alter it
If you ask if it's secure, you should assume you'll get an answer related to those purposes.
If you got a sunburn while standing in line for a water slide, you wouldn't say that the slide is unsafe, even though being burned is a hell of a departure from "safety". You'd have to be a little more specific.
all of these start with “unauthorized access” to define this term. can you please explain how open access to private repositories is not unauthorized access and how you can’t expect your data moving to private repositories to be private?
> Information security's primary focus is the balanced protection of data confidentiality, integrity, and availability
..and radicle.dev does nothing to suggest confidentiality is a focus. Words like "private" or "encrypted" don't appear on their front page.
When I saw this, I was surprised because I didn't even know they supported private repos. I just don't understand why you'd want private repositories on a peer to peer protocol. The whole point is to get away from all of the problematic things that stem from having a single point of control/failure and the hierarchies that follow therefrom. Private repositories means that you're re-implementing the very problems that you're presumably using something like Radicle to get away from, now at the application layer instead. If you can tolerate having an admin that may later be unavailable or untrustworthy such that you're locked out, why not just use github?
It's like private blog posts on wordpress. Yeah, if the feature is in there it should work but projects like these encapsulate a certain perspective, and if they're run by a small number of technologists who clearly in it because they care, then I think it's reasonable to evaluate their success based on whether they address the primary problem they're up against, not whether they have a bug in some feature they tacked on as an afterthought.
Anybody can set up encryption on a link. Shame on them for forgetting to do that, but radicle has much more ambitious goals. If they need more help than they're getting for some of the mundane stuff, well I'm not going to judge them too harshly for that.
> The problem isn’t that we lack the capability to make secure computers.
Depends on the "we". "We" have the capability to make secure computers like how "we" have the capability to make EUV lithography machines. There exists a relatively small number of people and organizations in the world who can do so. Microsoft does not have that capability. Google does not have that capability. Linux does not have that capability. Amazon does not have that capability. Apple does not have that capability. Cisco does not have that capability. IBM does not have that capability. etc. All of those organizations have tried for literal decades, thumped their chests about how they have awesome security year after year, and yet have totally and utterly failed despite their best efforts.
Acquiring the capability to do so is difficult and challenging and requires years to invent if you start right this very second and know what you need to do, which these organizations emphatically do not. We need security at scale and fast. The only way forward is to scale up working solutions rather than letting the bozos who put us in this spot fail at scale with yet another promise that this time for sure they will solve the problem they have repeatedly failed at for decades.
> Microsoft does not have that capability. Google does not have that capability. Linux does not have that capability. Amazon does not have that capability. Apple does not have that capability. Cisco does not have that capability. IBM does not have that capability. etc
This is all by choice. They could easily have that capsbility, very unlike EUV.
Part of the argument (aiui) is that there is no way that culture could ever change to producing secure systems. There are too many weaknesses embedded in the organizational structure.
Yeah, just like a lot of organizational change, one approach would probably be to put together a small Skunkworks-type team to nail it on one specific product. Existence proofs have, in my experience, a pretty powerful effect on the naysayers.
Oh, Microsoft can just figure out how to make unhackable systems, they just choose not to. They spend all of those billions of dollars per year on security and spent all of those decades on failed attempts as a prank.
You really think that if they could have they would not have, even just for bragging rights? Or are we going with that it is some kind of task demanding enormous expenditure even though the organizations that have made secure systems are infinitesimally small in comparison?
Microsoft has spent orders of magnitude more money and time than the organizations that have succeeded and the result of their efforts is Windows. That says everything you need to know about their capabilitys.
Multiple literal trillion dollars organizations have spent literal decades failing at it. You are really underselling the capability gap.
If windows was reimplemented as a capability based microkernel like sel4, it would be far more secure. Run drivers in their own isolated processes. Do interprocess communication between them via capabilities and shared memory. Remove all ambient authority from programs. All the programs a user launches stop automatically inheriting all of that user's permissions.
There's no secret knowledge required to do this. The SeL4 team has written extensive documentation of how they did it. They also opensourced their kernel implementation, with correctness proofs for the whole thing.
The reason windows hasn't done it is the cost. You'd have to rewrite half of the NT kernel and refactor everything else. All existing windows drivers would need to be rewritten. If you forced windows userland use a capability based system, you'd essentially be inventing a new way to write windows programs. You'd need to document that, and write a compatibility layer for legacy programs. And solve some UX problems. It would be terribly inconvenient for everyone. Oh, and some programs would run slower as a result.
They could do it if they wanted to. But microsoft just doesn't care about security as much as they care about performance and compatibility. Linux is the same.
The big irony is that security would be a lot cheaper for microsoft if they designed the NT kernel to be more like sel4. Microsoft has to spend millions on security every year because any tiny bug in the kernel (including in drivers) might result in the whole OS being compromised. In a microkernel, a buggy driver is nowhere near as dangerous.
Your knowledge is out of date: Windows has supported capabilities from the start of NT and does run a lot drivers in isolated processes, along with most OS services. It has done for years. It has the most sophisticated IPC framework of any OS (DCOM) which is integrated with the operating system kernel's security frameworks, and used pervasively both internally and by apps. And Microsoft has created a new way to write Windows programs in which apps are expected to advertise the capabilities they need (see WinRT and MSIX). This is also over 15 years old.
macOS does the same but with more developer adoption. Apps don't have the ambient capabilities of the user and must advertise what they need via entitlements embedded in the binaries, or get permission just in time.
Which is all very good, and modern platforms are much more secure than they once were. Yet "capabilities" as a silver bullet are academic overpromises. This article I wrote is more about language/runtime level capabilities but OS capabilities are not much better.
SeL4 isn't secure because of One Weird Trick that others would adopt if only if they could be made to care enough, it's "secure" because it hardly does anything, which is why nobody uses it and why it has no impact on real world computer security.
The hard part of desktop security is not changing the operating system. The hard part is getting app developers to care. Most security features added to operating systems are ignored by developers, which is why Apple forces you to adopt some of them as the price of admission to the app store. If they didn't nobody would use them, as can be seen for apps distributed outside of the app store. The reason is security is a market for lemons. Nobody can see the result of security investments so it's irrational to invest. SeL4 has no solution.
> Your knowledge is out of date: Windows has supported capabilities from the start of NT and does run a lot drivers in isolated processes, along with most OS services.
Thanks! I quickly googled this point before posting earlier to make sure I was still right. Gemini helpfully told me that yes indeed, drivers in windows run in the kernel's main process. Thanks, AI.
> This article I wrote is more about language/runtime level capabilities but OS capabilities are not much better.
I think I responded to this article at the time. I still find this article somewhat confusing and unconvincing. For example, you conflate Java's SecurityManager with capability systems, even though it seems more like an permission based access control system. Then you point out many of its weaknesses. To what end? What conclusion about capability systems am I supposed to draw from a criticism of this quite different security model?
A capability is not a permission flag. Unlike your example, a good capability system would generally pass all HTTP requests to a given endpoint through a single capability object. You wouldn't need different caps for each HTTP method like SecurityManager apparently requires. It's like file handles. You don't create several different file handles to interact with the same file, one for reading, one for writing and so on. We just open the file once, with whatever options are needed. Then the file descriptor can be passed into any function which needs to access that file. And whatever code receives the file descriptor doesn't know if they're talking to an actual file, or some in-memory object or something else. Just like a virtual object.
You also say this:
> File descriptors are a kind of capability provided by the kernel, but a rather odd and inflexible kind. They aren’t a great example of object capabilities.
Huh? File descriptors are often treated as the canonical example of object capabilities. This comment makes me wonder if we're even talking about the same thing. At the risk of being indelicate, are you sure you know what capabilities are? Can you give a definition of object capabilities which doesn't describe file descriptors?
The point about god objects lands. I also agree that trying to retrofit a language like java to make modules unable to share memory is difficult. But many aspects of language design work like this. Consider garbage collectors. Before GC languages existed, I could write the same article talking about the difficulties of hacking a GC into C. But that wouldn't teach me anything about how well a GC would work in a language like Java or Ruby.
Anyway, the main advantage of capabilities is the ability to split programs out into sub-modules such that a compromise or bug in one part of the system doesn't lead to the entire system failing. We can argue about whether bringing this into the language runtime is a good idea. But I feel pretty confident that this sort of separation is a good idea at the systems level, helping with security and reliability. We can look at Chrome, SeL4, Erlang and - apparently - windows for examples. Even if they don't all think of this as a capability based problem.
The SecurityManager exists in complement with Java capabilities. You could, in theory, use the Java language with a different standard library and implement a pure object capability system, as the language rules allow for that (if you disable reflection). But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code.
Consider the most common task the SecurityManager was deployed for: stopping plugins calling System.exit() by accident. One might say, the right to exit the process should be an object capability. OK. But then where does that object come from? Java programs start at main() and it doesn't receive an object.
You'd need a new design where you pass in a god object to main(), which in turn has properties giving access to a ProcessExiter interface or something similar, and then any code that genuinely needs to exit the process would need to request it in the function arguments, threading it down the stack. You'd get an explosion of types. A simple permissions DSL is much easier to write and reason about, and it gets out of the way when you don't want sandboxing.
Why would you want all HTTP requests to flow through a single capability object? I think it's pretty common to want to let code do GETs but not POSTs. You end up wanting pretty fine grained permissions in a lot of real scenarios.
File descriptors are poor object capabilities because the interface they implement is fixed by the OS, except then there's a weird ioctl escape hatch that isn't properly typed, reflectable, wrappable or interposable. To see what can go wrong with this, consider a recent fix to the Codex sandbox on macOS:
The sandbox forbids writing to a file descriptor except, oops, someone at Apple forgot about the F_TRANSFEREXTENTS ioctl which is still allowed on a read only fd. It should be possible to do what is expected here and just pass in a read only fd where all you can do is call read() and maybe seek(), or perhaps pass in an fd where a specific ioctl is the only thing you can do, but POSIX has no concept of this.
A good example of an object capability system would be Mojo, which I describe in the essay. You can create objects representing capabilities and pass them between sandboxes, in an unforgeable way.
We live in a golden era of prototyping so if you wanted to make a language where everything is a capability passed into main(), you could. The code doesn't have to be executable, you could just mock out some realistic programs and see how the code feels. My guess is you'd need a lot of language features to hide the explicit object capabilities away for ergonomic reasons and it'd end up feeling a lot like a SecurityManager based system.
> But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code.
This might be the core contention. I don't know if using actual capabilities in a language would have problematically bad ergonomics. You'd probably be passing more arguments to functions. But haskell seems to manage ok despite needing to pass IO to functions that need it. Capabilities seem similarly inconvenient. I think I'd need to see it tried. I agree - I might need to try it myself.
> Consider the most common task the SecurityManager was deployed for: stopping plugins calling System.exit() by accident. One might say, the right to exit the process should be an object capability.
I don't think this is a great example. Caps are generally for resources outside of your program or module scope. A program already has the capability to exit, so that wouldn't be something you would pass in from outside of the program.
> Java programs start at main() and it doesn't receive an object.
I agree that retrofitting caps into an existing language like java would be difficult and inconvenient. Passing a "god cap" to main() is the easy part! The hard part is just how much of the standard library implicitly depends on ambient authority. I've thought about doing this in rust, and concluded that I'd probably need to fork rust's std library.
> You'd get an explosion of types.
I've never heard of that stopping java programmers before.
The way SeL4 handles this is to have a generic call() interface for capabilities. It's very simple, and it would work fine in this example.
> Why would you want all HTTP requests to flow through a single capability object?
Capabilities are a combination of resource + access rights over that resource. If I wanted to give a module access to a REST endpoint, I'd make a cap representing that endpoint. The resource is the URL base (eg "example.com/foo/bar"). And I'd also specify access rights (eg only HEAD+GET, or HEAD+GET+POST or whatever makes sense). Then pass that object around to any modules which need access. I'd even keep the URL prefix private in the capability object. The capability object would only expose methods for http_get(), http_head(), http_post() and so on. This design would be more or less impossible to misuse. And it would be super handy for unit testing and dev environments.
It's not "one capability for everything" and it's not "a million fine-grained access rights". You want one cap per semantic resource, just like one fd per open file. If you want to refine the granted permissions, just reimplement the same interface with a different implementation of http_get() and friends. (Or, simpler: just wrap your existing RESTEndpoint class with another class which adds your extra checks).
> except then there's a weird ioctl escape hatch that isn't properly typed,
This is a flaw of the unix syscall API. In comparison, SeL4 only has 9 syscalls (plus 2 for debugging). The syscalls just let you call capabilities, and have your capabilities be called by other processes. And yield(). That's all the syscalls on sel4.
Because everything runs through that same API, it's trivial to stub out or replace capabilities provided by different components. Eg, any program can reimplement the filesystem API if it wants to. No need for FUSE, or special loopback mounting or anything like that. Because the filesystem is just a userland process which doesn't have access to the kernel's memory, there are no ioctls that you can accidentally forget to sandbox. The only special thing about the filesystem is that it holds a capability to do raw IO on the block device. (And that cap, in turn, is provided by another userland process.)
> My guess is you'd need a lot of language features to hide the explicit object capabilities away for ergonomic reasons
Yeah, I think that's our big disagreement. You seem to think that hiding object capabilities would be a necessary design choice. I think using caps directly would be much more ergonomic than a SecurityManager style design because custom caps can just be implemented in normal code. And caps are better because they encapsulate a resource, not just access control rights.
> > But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code.
>
> This might be the core contention. I don't know if using actual capabilities in a language would have problematically bad ergonomics. You'd probably be passing more arguments to functions. But haskell seems to manage ok despite needing to pass IO to functions that need it. Capabilities seem similarly inconvenient. I think I'd need to see it tried. I agree - I might need to try it myself.
One of the common objections I hear to Bluefin is "isn't it too inconvenient to pass around capabilities everywhere?". Perhaps surprisingly, no, I haven't found it remotely inconvenient. I find it liberating, actually.
Ah yes, the parable of the bear. There are a million people stuck in a valley and two bears. You do not need to outrun the bears, you just need to outrun at least two other people. But it turns out one of those bears is male and the other is female. So next year there are more bears, but you still just need to outrun a few people. Then one day, there are 1 million bears and they eat you all. Very inspiring story.
Software security has just been a fun time of ignoring the exponentially growing number of bears for the last few decades so you can continue to use systems unfit for the threat landscape because they are cheap.
Almost all marketing is actively detrimental to the world. Marketing that is intentionally truthful and intentionally avoids over-promising is actually of value to the world. Marketing where in a court of law they would not go: "Technically your honor..." and backpedal on everything they say using tortured interpretations that would make a genie blush.
The problem is that a vanishingly small amount of marketing is that way, and when done is mostly the purview of good hard-working individuals with no "marketing" experience. Almost all marketing is intentionally deceptive and fraudulent where the entire goal is to say something that only a genie would agree is technically correct, while intentionally focus grouping until every single member of the focus group believes you said something other than what your lawyers would say. That is pure, intentional, pre-meditated deception and fraud. That should be advertising fraud.
"Technically your honor" should be a instant loss in the courts. The more time you spend crafting your message, the more accurate it should be required to be. If your focus group does not think you said what your lawyers are going to say, "Go directly to jail. Do not pass Go." If your target demographic does not overwhelmingly think you said what your lawyers are going to say, that had better be a case where all the money you spent on crafting the message and the proportionally expensive preventative measures failed.
Allowing deception and fraud is the harm that suppresses good, hard-working, honest individuals and companys and replaces them with liars and cheats making the whole world poorer.
The label has not lost its meaning. Everybody knows what it means and wants it, just almost everybody “selling it” is claiming it without regard for the truth of their claim for their own financial gain. In polite society that is called lying and fraud.
People accept a surprising amount of unreliability.
For example, I've been using SharePoint to modify excel files at scale.
We kept running into issues with cache that we would write to a file, the service would respond with success, but then when we read the file, it shows the old cached value, not the new one we just WROTE! And there was no reliable way to check when the newly written value had been completely flushed using that API.
Microsoft will call this 'optimized'. They'll say that caching is good; it's a feature, not a bug!
But really, it's unreliable! It's not doing the job it claims to do.
> Musk has a bachelor's degree in physics from the University of Pennsylvania.
Clarification, Musk bought a B.A. in physics. In the Paypal S-1 in 2002, [1] Paypal's lawyers claimed that he graduated with a B.S. in Physics and B.S. in Economics in 1995.
Yet the actual degrees subpoenaed from UPenn indicate a B.A. in Physics and B.S. in Economics in 1997, two years later. He could not even remember the year he graduated or the degree he received just 5/7 years after their purported completion. I have yet to meet a single person who actually graduated from college who can not accurately recollect the year of their graduation, have you?
Most likely he did this because he was in the USA on a student visa and dropping out of UPenn in 1995 made him a illegal immigrant which his brother, Kimbal Musk, corroborated in a interview [2].
Small counterpoint: I'm 42 years old, and I would have to look at my resume to see what year I graduated college. By time I graduated I was already working full time, had a contracting company on the side, and had a family. College was just a thing that was happening, another job, it wasn't a huge life-defining event. I remember the people I met and the projects I worked on, but there's no way I'd be able to accurately tell you the exact year it was over. (I just checked the resume, I was off by 2. Yikers.)
Really, your lawyer asks you what year you graduated for a legal filing and you would give the wrong year? Not even bother to go check, just fly by the seat of your pants?
That is because you do not need to clear the field at the end of a critical section. It contains the contiguous instruction range where it fires so there is no problem with leaving it active forever unless you have another critical section where you want to use it.
No explicit memory barrier is required anywhere as the value is only read in supervisor mode and a privilege switch implicitly issues a LS-LS barrier on all major architectures. Even if you did not want to rely on that, you would only need a single S-LS barrier when you store the control structure the very first time.
> That is because you do not need to clear the field at the end of a critical section. It contains the contiguous instruction range where it fires so there is no problem with leaving it active forever unless you have another critical section where you want to use it.
Aha! So, to take advantage of that, a memory allocator uses the same abort handler for all operations?
That just sounds like bad tracing implementations. A good tracing implementation should be able to drive gigabytes per second of trace logs to memory. If you are generating it slow enough to allow actual offload then you should be in the 1—10% range even if you are saturating your offload.
You should, of course, upper bound this overhead by switching to a full time travel debugging solution, thus tracing everything, when you get to the 10-30% range.
The only way you get to “majority” is if your trace implementation is slower than time travel debugging and provides less information, but then why choose something worse in every dimension.
I'm just reporting from the trenches here. I think you are suggesting that everyone is aware of and capable of using state-of-the-art (from 20 years ago) tracing schemes like XRay[1], when in reality they are not. Most projects would be well-served by any basic profiler but even profiling is apparently for wizards, because I've seen a lot of projects that will resort to manually annotating functions with OTel trace spans, which are ~millions of times more expensive than function calls. Even eBPF uprobe/uretprobe is 100x more expensive than XRay, at a minimum. HotSpot's JFR is like a miracle compared to what people suffer through to diagnose Rust+Tokio.
It's worth pointing out though that just tracing function calls isn't good enough for the kinds of stackless coroutines that run in async Rust tasks. You need a way of mapping between the async tasks and the compiler emitted traces.
The difference is nobody in the C++ community believes that a dominant asynchronous executor library exists, and there is not a pervasive belief that it would be helpful.
The "C++ community", if it even exists, barely believes in sharing code let alone any library being "dominant." They'd have to agree on a build system first, after all.
But honestly that's a mischaracterization of the situation in Rust. Tokio is popular for networked service backends. If that's the wheelhouse you're in then yea it might look "dominant."
You can share with header files and respective (shared) object files regardless of the build system you're using.
Likewise you could just share the source. None of this needs a build system.
I was just being a bit sardonic because the C++ ecosystem is so fragmented that something like tokio couldn't really exist. It would be one of three executors in boost, abseil, or folly, and you would never see the kind of downstream ecosystem build on top of them because C++ shops are allergic to external dependencies.
Any organisation that cares about security should be allergic to external dependencies, that is why companies like Nexus and JFrog exist, with companies paying to keep internal repos infrastructure in shape.
One just doesn't install willy nilly from the Internet into the CI/CD pipeline.
Well, they do, and then spend a few late nights when there is a bunch of CVE to fix.
Using an artifactory instance as the origin is not functionally different from installing something 'willy nilly' from the internet. It addresses a narrow range of threats while predominantly being more reliable and faster than public repositories.
It doesn't fix the actual problems with C++, which is that it's significantly more difficult to get and use external dependencies because of the compilation and linkage model of C++ libraries.
If C++ were as easy to build and link as modern programming languages you'd see the same kinds of tools as cargo, and the same kinds of ecosystem evolution as rust, like tokio. But you don't, because C++ code sucks to build, package, distribute, update, and reuse.
(I'm aware/have used conan/meson/vcpkg/etc - doesn't change my opinion).
It surely does, because in most companies that care about security it isn't a mirror, rather the only third party packages that developers are allowed to use beyond the standard library.
Additionally, making new packages available for consumption requires approval from IT and possibly legal, before they become available for consumption.
What is hard is people educated in scripting languages not wanting to learn about toolchains.
The moment Rust depends on other programming languages, we get a build.rs spaghetti file, depending on the knowledge of those writing it, or people throwing away Cargo altogether, and replacing it with Bazel, buck2 and co.
Huh, it seems xray puts blank trampolines all over your binary? That sounds pretty nifty but I would expect it to be pretty language agnostic, ish? Adding support should be doable for Rust as well, right? Anyways, pretty nifty.
I am by no means an expert, but I've recently improved performance for some code and used tracy. They have rust bindings as well. It's pretty cool and it seems to be low overhead. Wonder if I can couple it with something like xray? Tracy is more the tracing library + tracing interpretations/aquisition tool.
Edit: apparently rust already supports xray natively on the nightly.
Memory copying is on the order of 100 gigabytes per second. You can do 80 full payload copys and still out-pace a dog-slow 10 gigabit per second connection. If your bottleneck is memory copying you are either doing something very wrong and doing way too many copys or congratulations you have implemented one of the fastest network stacks.
Supervisor calls are also very fast, on the order of 100 ns up to maybe 1 us with all the Spectre mitigations. Even if you did something as stupid as one supervisor call per packet, you would still be getting on the order of 10 Gbps at the long end there and 100 Gbps at the short end. Which, again, means congratulations are in order because you have implemented one of the fastest network stacks. If you do batching and add just 10 us (us, not ms) of latency then that entire cost is so small as to be irrelevant. You are going to bottleneck on your memory copying first.
Network stacks are so slow almost entirely due to poor protocol design and poor protocol implementation. Usually both.
reply