C++ as an ocap language?

[Stewart Webb]

Hi all,

I'm wondering if there has been much research done on C++'s object model and how well it does or doesn't work as an ocap model? I figured this might be a good place to ask if anyone has any pointers (ha!) on things to look at. (Or perhaps references instead ;) )

I'm aware of Cap'n Proto existing as something that can provide some form of capability model, and that "it's a C++ library". But this model seems to be strongly based on an environment set up as part of the design of Cap'n Proto as a library and protocol, as opposed to anything explicitly part of C++ as a programming language. I'm more specifically wondering about the language level. An issue that I think I came across somewhere in some initial searching is C++ class extension could break ocap guarantees (if malicious code just extended an existing class to override functionality).

For context, I am in the tail end of a research project looking at ocap languages to map/adapt to the seL4 microkernel (which has its own capability system for resource management). About half of the research has been trying to adapt the Pony language (or in practice rather its runtime more specifically) to an seL4 environment, as Pony can give ocap guarantees as part of its language, but the other half is more broadly looking at various ocap languages out there and their tradeoffs when it comes to implementing them in the very minimal environment provided by seL4. Pony was my eventual top candidate for looking at because it compiles straight to machine code via LLVM, with the only other dependency being a linked runtime library that's implemented in C - this made it the best performance candidate for building systems stuff ontop of a microkernel like seL4, and one with dependencies that seemed the easiest to port into the C programming environment that seL4 development entails. Hence also my interest in anything that's been done with C++.

Cheers,

Stewart Webb

(CompSci Masters student @ University of Melbourne)

[Mike Stay]

The biggest impediment to C++ as an ocap language is memory safety.
Here's a project that claims to guarantee memory safety if you program
in a statically checkable subset of C++:
https://github.com/node-dot-cpp/memory-safe-cpp

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/4b5738b1-69d9-4f2e-9bd0-62bf413f423fn%40googlegroups.com.



--
Mike Stay - meta...@gmail.com
https://math.ucr.edu/~mike
https://reperiendi.wordpress.com

[Stewart Webb]

Ah of course, I can't believe I didn't even think of the memory safety problem. (Hence my interest in finding any research others have already done!)

Thanks for the link, this seems interesting

[Rob Meijer]

Don't think runtime C++ code has the potential to be fully ocap. Compile time C++ though might hold promise. I can imagine there might be a capability secure subset of C++ TMP.

As for non-TMP cap discipline, maybe this old post on private constructors and delegated friendship is helpful: https://cap-talk.mail.eros-os.narkive.com/O4BMvXzi/coding-style-in-c-isolating-the-bad-parts-with-private-constructors-and-friends

--

[Stewart Webb]

Amazing, thanks Rob - this looks exactly in line with the kind of thing I'm looking for. (And fun to spot that my supervisor Toby contributed to the thread/discussion back then too!)

[Jonathan S. Shapiro]

On Wed, Sep 14, 2022 at 10:47 PM Rob Meijer <pib...@gmail.com> wrote:

I can imagine there might be a capability secure subset of C++ TMP.

The empty set is a secure ocap subset of all programming languages…

[Ben Laurie]

But not actually a programming language...

 

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNO2KdFkkYMgwoFRGe_MPsOSFRtceJxzoi9-6gV8yD8Ww%40mail.gmail.com.

[Matt Rice]

On Tue, Sep 20, 2022 at 8:06 AM 'Ben Laurie' via cap-talk
<cap-...@googlegroups.com> wrote:
>
>
>
> On Tue, 20 Sept 2022 at 04:15, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:
>>
>> On Wed, Sep 14, 2022 at 10:47 PM Rob Meijer <pib...@gmail.com> wrote:
>>>
>>> I can imagine there might be a capability secure subset of C++ TMP.
>>
>>
>> The empty set is a secure ocap subset of all programming languages…
>
>
> But not actually a programming language...
>

The preprocessor is not a programming language in the Turing sense,
yet it still violates aspects of capability discipline...

[Jonathan S. Shapiro]

Picky, picky…🤣

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CABrd9SQkx61C6B_DtEiu3-_pz7WTZ5AbGRB0Y2Vxj5RigfQnNA%40mail.gmail.com.