Alright, we have a real Fostin hero standing in for Lewis, Pierre Emmanuel again.
We have two more heroes at the back who have also obviously fixed the audio.
Thank you very much as well.
Take it away please.
Hello again. I'm still not Lewis, and I'm still not the original speaker.
The talk will be even worse than the first one. Let's talk about the hardware pointer on the Cherry architecture.
Before we get started, we'll cover what we'll be talking about.
We'll be talking about mirror safety, capabilities, the Cherry design, digital security by design, as well as CyberLife Connect project.
We'll then talk about the motivation, the Cherry and the rest, as well as the implementation and the different challenges and problems we found during this walk.
So, mirror safety.
Accessing memory pointer, what could go wrong? You're probably your read and answer if you're doing some rest, but is rest even safe about this?
So, the problem with rest is once you tag a code with unsafe or something or you're in unsafe context, the hardware will not back you up.
You will simply let you access to the hardware if you're lucky, you have a kernel which will give you a page fault, but that's all.
So, the hardware will not protect you against user-free, out-of-bound data-scored, everything.
But you may already know rest and it helps us. I mean, safe rest is cool.
There might still be something that could go wrong.
So, what are capabilities? Capabilities are some kind of metadata that we embed at the assembly level with pointers.
This means every pointer will have a big field of metadata, whether it could be written, read or even just used and how could it be used?
And the second part of the pointer will be the address itself.
So, we can encode in this metadata bound permission in validation states, all those kind of things.
And the helpers catch code that behaves badly even when a compiler thinks it is valid.
So, let's talk about Cherry.
So, Cherry is a project from Cambridge University.
Cherry isn't an architecture itself. Cherry is more of a specification.
It's a set of specifications for an hardware extension.
It allows the creation of a capability-based system and the specification covers all capabilities required in order to make code cycle.
So, I was talking about this metadata.
So, here you can see in this slide the encoding of metadata on the Cherry specification.
We've got the permission, the type as well as the bound of the address in order to check any out of bound or array indexing or things like this.
And you've got the 64-bit address behind it.
Okay.
One note, pure cap on hybrid mode.
Cherry provides two modes.
Pure cap basically is every pointer as metadata.
Every pointer is 128 bits.
And the hybrid mode is here in order to ensure compatibility with order, not just not order, but capability-less systems.
Okay.
So, here you've got an example for an instruction with capabilities.
So, it takes an address and it raises an exception if permissions are not correct or something is wrong.
For example, let's say on the previous slide.
Okay.
So, we've got bound set here.
This means we can use a pointer for an array on set bound and if we are trying to access this array out of bound, the machine will trap and give us an exception.
Digital security by design.
What is it?
So, in the Kingdom Government Initiative, that want to expand the use of Cherry out of academia to the industry.
Zephend, multiple work to demonstrate the application of Cherry and make it work in the real world in the industry.
Initially, it revolved only around Morello.
You may not know Morello.
So, Morello is an extension for our system, ARM.
Recently, they focused more on architecture such as Rix-Fi, for example.
CyberHiveConnect.
CyberHiveConnect is a security-critical application within the rest.
It's one to implement end-to-end encryption of a mesh network.
So, yeah, here you've got an example.
This application is a security-critical application.
And it is with a mesh network and end-to-end encryption.
So, this means obviously there should not be vulnerabilities.
Okay.
So, why Cherry and Rust?
So, Rust already provided the different restrictions.
Some restrictions cannot be provided by Rust.
For example, there are runtime enforcements that are provided by Rust,
but that slows down the flow.
You may have seen out-of-bound checks on your arrays when you index an array.
You may have seen that kind of thing.
And this kind of code is slow, but if you replace this kind of code with Cherry-based extension in switching,
it can now be faster on an extension to access an array out-of-bound.
We'll simply trap.
You don't have to end-to-end it yourself.
You just have to end-to-end the trap.
So, when you need to connect an application with Rust code,
for example, with the FFI, for instance, a function interface,
you may be safer because the Cherry extension will be here to back you up
and provide you the correct pointers.
And you who are sure that the pointer you'll be using in Rust won't come from nowhere
or aren't a pointer or whatever.
So, yeah, unsafe can become in some way safer.
Here's an example.
We've got an array.
We converted it to pointer.
We make a string, and we try to read the same line and pass a number.
And then, at the end, we try to add the index to the pointer.
And as you may have seen, we are using the safe code.
And the Rust compiler won't catch any of this because we told him to do so.
So, here, Cherry might help us.
And Cherry will provide an exception on this when we want to go out of bound in the array.
Lewis provided two new targets for the Rust compiler, more or less known pure cap
and more or less known through the PUDESD pure cap.
As you may have seen, both are pure cap.
This means those are not compatible with AI breadmode.
This means those implementation are not compatible with standard pointer.
As we may say it, all pointers should have capabilities enabled.
So, here, we have a new type of pointer.
It's coming in Rust 5.
And all those files are available in the repository right here.
There was different implementation challenges.
We should provide a new pointer type with capabilities.
There is something that's made the created debate a few months,
slash years ago, is the size type.
You size in Rust, what should it represent?
Should it cover the entire addressable space?
Should it be able to contain a whole pointer?
That kind of thing.
So, we chose to represent only the address part of the pointer within the size.
Layout and address space differs for pointer on capabilities.
More on that later.
And we generate, we have to generate some cherry specific interesting for LLven and AI.
Again, as I said, your size is not UN pointer.
Okay.
So, I should have been a demo but I haven't one.
So, well, enjoy the screenshots.
Okay, so here we get the segmentation fault when we make an out of bound access in our array,
even if we don't hit a numlap page, for example.
So, that's cool.
I'll give the slide.
Yeah.
Sorry.
Okay, future walk.
Future walk.
So, what will the WIS concentrate on in your studio?
It will add more cherry targets.
Hopefully, yeah, more possibly some hybrid model for the targets.
We want the rest test suite to pass.
For now, we have only 50% of the tests in the USC that pass,
and refactor the code, document the code, and rebase on a newer version of Rust
because right now it's on Rust 1.67.
So, yeah.
And Lewis would like to begin upstreaming his walk.
Well, thank you.
And sorry again for this whole talk.
If you've got questions, I may be able to answer those questions,
but to be fair, probably not.
Thank you.
What other targets are you looking for, then?
Are there other targets besides Morello, which actually implement Cherry today?
I'm sorry, you didn't hear.
Are there actually targets which implement Cherry today besides the arm Morello thing you showed?
I don't know.
I mean, RISC talked about some RISC-5 extension, but a journey behind them might be able to answer.
So thank you.
I'm one of Pierre Emmanuel's colleagues.
There are a number of RISC-5 implementations out there.
Code of SIP demonstrated by the RISC-5 summit and Microsoft,
and I believe low risk also have ones as well.
So RISC-5 is actually running ahead of ARM, if anything.
But is there RISC-5 implantations so far virtualized,
or are there any boards which support Cherry?
I'm sorry.
Regarding RISC-5 implementation, are there so far any boards which support Cherry,
like RISC-5 Cherry, or is it mostly virtualized QM environment?
I suspect these have only ever been made by the development teams as demonstrators on FPGAs,
but Code of SIP certainly intend to be able to ship stuff to their customers,
and I think before too long there'll be hardware available.
You have a slide about GDP.
Do you have GDP support for someone who prints one of these pointers,
like the semantics of the, you know, the extra-secretful bits and bits?
If we take a look at, in fact, if we take a look at Lewis Walk,
the capabilities are stored in address space 200, if it makes sense.
So there is some kind of support, but I believe it's more axe than real thing.
I'm not sure, as I said, really, I don't know much.
So just to follow up, so I believe there is a reasonable support for GDP and Cherry on Cherry BSD,
and it displays all the things you need within the GDP.
Any more questions?
If not, then let's thank our speaker again.