#cheriot — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #cheriot, aggregated by home.social.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
First Post! Uh, I mean, First CHERIoT Silicon!
We have our first chips back! It is very exciting! Spatial and temporal memory safety, fine-grained compartmentalisation, and also a load of other big chips on a board, so you can play 'Where's ICENI?' on the board picture!
-
First Post! Uh, I mean, First CHERIoT Silicon!
We have our first chips back! It is very exciting! Spatial and temporal memory safety, fine-grained compartmentalisation, and also a load of other big chips on a board, so you can play 'Where's ICENI?' on the board picture!
-
First Post! Uh, I mean, First CHERIoT Silicon!
We have our first chips back! It is very exciting! Spatial and temporal memory safety, fine-grained compartmentalisation, and also a load of other big chips on a board, so you can play 'Where's ICENI?' on the board picture!
-
First Post! Uh, I mean, First CHERIoT Silicon!
We have our first chips back! It is very exciting! Spatial and temporal memory safety, fine-grained compartmentalisation, and also a load of other big chips on a board, so you can play 'Where's ICENI?' on the board picture!
-
First Post! Uh, I mean, First CHERIoT Silicon!
We have our first chips back! It is very exciting! Spatial and temporal memory safety, fine-grained compartmentalisation, and also a load of other big chips on a board, so you can play 'Where's ICENI?' on the board picture!
-
This probably deserves its own post:
We've just open sourced a tool that Tim Hutt wrote for #debugging #CHERIoT things. The tool consumes a CPU trace from CHERIoT Ibex and exposes a gdbserver protocol interface. You can then use CHERIoT lldb to step forwards and backwards in your trace.
-
This probably deserves its own post:
We've just open sourced a tool that Tim Hutt wrote for #debugging #CHERIoT things. The tool consumes a CPU trace from CHERIoT Ibex and exposes a gdbserver protocol interface. You can then use CHERIoT lldb to step forwards and backwards in your trace.
-
This probably deserves its own post:
We've just open sourced a tool that Tim Hutt wrote for #debugging #CHERIoT things. The tool consumes a CPU trace from CHERIoT Ibex and exposes a gdbserver protocol interface. You can then use CHERIoT lldb to step forwards and backwards in your trace.
-
This probably deserves its own post:
We've just open sourced a tool that Tim Hutt wrote for #debugging #CHERIoT things. The tool consumes a CPU trace from CHERIoT Ibex and exposes a gdbserver protocol interface. You can then use CHERIoT lldb to step forwards and backwards in your trace.
-
This probably deserves its own post:
We've just open sourced a tool that Tim Hutt wrote for #debugging #CHERIoT things. The tool consumes a CPU trace from CHERIoT Ibex and exposes a gdbserver protocol interface. You can then use CHERIoT lldb to step forwards and backwards in your trace.
-
@cheri_alliance has posted about the Secure Horizons event in Duxford next week, which will be a great event for people who want to understand how CHERI (and, especially, CHERIoT) can make regulator compliance easier for secure IoT devices (as well as actually making them more secure).
Registration is still open and some SCI folks will be there!
-
@cheri_alliance has posted about the Secure Horizons event in Duxford next week, which will be a great event for people who want to understand how CHERI (and, especially, CHERIoT) can make regulator compliance easier for secure IoT devices (as well as actually making them more secure).
Registration is still open and some SCI folks will be there!
-
@cheri_alliance has posted about the Secure Horizons event in Duxford next week, which will be a great event for people who want to understand how CHERI (and, especially, CHERIoT) can make regulator compliance easier for secure IoT devices (as well as actually making them more secure).
Registration is still open and some SCI folks will be there!
-
@cheri_alliance has posted about the Secure Horizons event in Duxford next week, which will be a great event for people who want to understand how CHERI (and, especially, CHERIoT) can make regulator compliance easier for secure IoT devices (as well as actually making them more secure).
Registration is still open and some SCI folks will be there!
-
@cheri_alliance has posted about the Secure Horizons event in Duxford next week, which will be a great event for people who want to understand how CHERI (and, especially, CHERIoT) can make regulator compliance easier for secure IoT devices (as well as actually making them more secure).
Registration is still open and some SCI folks will be there!
-
Shout out to the folks maintaining the pq-code-package repos. I’ve been building their ML-KEM and ML-DSA implementations for CHERIooT and they’ve been an absolute delight to work with. I don’t think I’ve ever had better interactions with a F/OSS project (though I have had a few that were as good).
Don’t worry, I’m not touching any of the crypto code…
-
Shout out to the folks maintaining the pq-code-package repos. I’ve been building their ML-KEM and ML-DSA implementations for CHERIooT and they’ve been an absolute delight to work with. I don’t think I’ve ever had better interactions with a F/OSS project (though I have had a few that were as good).
Don’t worry, I’m not touching any of the crypto code…
-
Shout out to the folks maintaining the pq-code-package repos. I’ve been building their ML-KEM and ML-DSA implementations for CHERIooT and they’ve been an absolute delight to work with. I don’t think I’ve ever had better interactions with a F/OSS project (though I have had a few that were as good).
Don’t worry, I’m not touching any of the crypto code…
-
Shout out to the folks maintaining the pq-code-package repos. I’ve been building their ML-KEM and ML-DSA implementations for CHERIooT and they’ve been an absolute delight to work with. I don’t think I’ve ever had better interactions with a F/OSS project (though I have had a few that were as good).
Don’t worry, I’m not touching any of the crypto code…
-
Shout out to the folks maintaining the pq-code-package repos. I’ve been building their ML-KEM and ML-DSA implementations for CHERIooT and they’ve been an absolute delight to work with. I don’t think I’ve ever had better interactions with a F/OSS project (though I have had a few that were as good).
Don’t worry, I’m not touching any of the crypto code…
-
Mostly when I talk about #CHERIoT, I'm talking about the security, because that's the biggest and most obvious feature.
But since I've ranted a bit recently about Free Software things that don't empower users, I wanted to take a minute to write about how CHERIoT RTOS and is built on the principles that I think can provide maintainable systems.
The CHERIoT software is designed around compartments, which are somewhat like MULTICS shared libraries. They are isolated things that can own some mutable state and expose entry points, which are functions. Code in one compartment can invoke code in another compartment by simply calling a function that the other compartment exposes. This is a security domain transition. The callee has access to objects that were passed by reference, but there is no implicit sharing (and the hardware lets you share read-only view of data structures, or share for the duration of the call, and so on).
This model means that a lot of things that you run on the platform are tiny. This include the RTOS itself. There are four core bits of the RTOS:
- The switcher, which is the equivalent of the kernel, and is around 350 instructions. This is the most privileged part of the system and implements the fundamental bits of the programming model that are too complex to put in hardware. It is carefully co-designed with the hardware architecture though, and we expect very few users will ever modify it. We're working to formally verify it.
- The scheduler is trusted for availability, but not for confidentiality and integrity. It is just another compartment. We provide a simple fixed-priority scheduler with priority inheriting futexes. We think it's a nice design for embedded systems, but if you want to build your own scheduler you really just need to implement the function that the switcher calls that says 'this is the thread that was interrupted, go and talk to the interrupt controller and figure out which new thread you want to run now' and the futex APIs.
- The heap allocator. This owns the region of memory used for the heap and works with the hardware to enforce spatial and temporal safety. We provide an implementation of this in C++, some folks at UBC are working on a reimplementation in Rust using Verus. If this is slower / bigger, we'll support both, if it's as good then we'll probably replace ours.
The RTOS also contains a bunch of optional shared libraries and makes it easy to wrap other components. For example, we have a network stack that puts BearSSL, the FreeRTOS TCP/IP stack, and the FreeRTOS MQTT libraries in compartments and adds a control-plane compartment that manages authorisation for socket creation and firewall control, a firewall compartment, and a DNS resolver compartment.
Most of these are small. If you want to replace BearSSL with WolfSSL or something similar, that should be easy. If you don't want to use it at all, that's fine too, you can replace the entire network stack with something different if you want to.
The goal is to have a load of building blocks that device vendors and end users can easily reuse if they want to, but that they can easily replace with their own things if they don't like ours.
We built an auditing framework that makes it easy to add CI-time or code-signing-time checks to enforce rules like 'only the firewall can talk to the network interface device directly' or 'only the TLS compartment may call the TCP send and receive functions'. We did this to support the conflicting requirements of proposed right-to-repair legislation (which should give end users the right to modify the software on their device) and other safety regulations (which may restrict the ability to modify things like the code talking to software-defined radio, or the safety-critical parts of a medical device). This enables people who build on the platform to create devices that empower their end users, even in domains where allowing replacement of the firmware may be illegal.
-
Mostly when I talk about #CHERIoT, I'm talking about the security, because that's the biggest and most obvious feature.
But since I've ranted a bit recently about Free Software things that don't empower users, I wanted to take a minute to write about how CHERIoT RTOS and is built on the principles that I think can provide maintainable systems.
The CHERIoT software is designed around compartments, which are somewhat like MULTICS shared libraries. They are isolated things that can own some mutable state and expose entry points, which are functions. Code in one compartment can invoke code in another compartment by simply calling a function that the other compartment exposes. This is a security domain transition. The callee has access to objects that were passed by reference, but there is no implicit sharing (and the hardware lets you share read-only view of data structures, or share for the duration of the call, and so on).
This model means that a lot of things that you run on the platform are tiny. This include the RTOS itself. There are four core bits of the RTOS:
- The switcher, which is the equivalent of the kernel, and is around 350 instructions. This is the most privileged part of the system and implements the fundamental bits of the programming model that are too complex to put in hardware. It is carefully co-designed with the hardware architecture though, and we expect very few users will ever modify it. We're working to formally verify it.
- The scheduler is trusted for availability, but not for confidentiality and integrity. It is just another compartment. We provide a simple fixed-priority scheduler with priority inheriting futexes. We think it's a nice design for embedded systems, but if you want to build your own scheduler you really just need to implement the function that the switcher calls that says 'this is the thread that was interrupted, go and talk to the interrupt controller and figure out which new thread you want to run now' and the futex APIs.
- The heap allocator. This owns the region of memory used for the heap and works with the hardware to enforce spatial and temporal safety. We provide an implementation of this in C++, some folks at UBC are working on a reimplementation in Rust using Verus. If this is slower / bigger, we'll support both, if it's as good then we'll probably replace ours.
The RTOS also contains a bunch of optional shared libraries and makes it easy to wrap other components. For example, we have a network stack that puts BearSSL, the FreeRTOS TCP/IP stack, and the FreeRTOS MQTT libraries in compartments and adds a control-plane compartment that manages authorisation for socket creation and firewall control, a firewall compartment, and a DNS resolver compartment.
Most of these are small. If you want to replace BearSSL with WolfSSL or something similar, that should be easy. If you don't want to use it at all, that's fine too, you can replace the entire network stack with something different if you want to.
The goal is to have a load of building blocks that device vendors and end users can easily reuse if they want to, but that they can easily replace with their own things if they don't like ours.
We built an auditing framework that makes it easy to add CI-time or code-signing-time checks to enforce rules like 'only the firewall can talk to the network interface device directly' or 'only the TLS compartment may call the TCP send and receive functions'. We did this to support the conflicting requirements of proposed right-to-repair legislation (which should give end users the right to modify the software on their device) and other safety regulations (which may restrict the ability to modify things like the code talking to software-defined radio, or the safety-critical parts of a medical device). This enables people who build on the platform to create devices that empower their end users, even in domains where allowing replacement of the firmware may be illegal.
-
Mostly when I talk about #CHERIoT, I'm talking about the security, because that's the biggest and most obvious feature.
But since I've ranted a bit recently about Free Software things that don't empower users, I wanted to take a minute to write about how CHERIoT RTOS and is built on the principles that I think can provide maintainable systems.
The CHERIoT software is designed around compartments, which are somewhat like MULTICS shared libraries. They are isolated things that can own some mutable state and expose entry points, which are functions. Code in one compartment can invoke code in another compartment by simply calling a function that the other compartment exposes. This is a security domain transition. The callee has access to objects that were passed by reference, but there is no implicit sharing (and the hardware lets you share read-only view of data structures, or share for the duration of the call, and so on).
This model means that a lot of things that you run on the platform are tiny. This include the RTOS itself. There are four core bits of the RTOS:
- The switcher, which is the equivalent of the kernel, and is around 350 instructions. This is the most privileged part of the system and implements the fundamental bits of the programming model that are too complex to put in hardware. It is carefully co-designed with the hardware architecture though, and we expect very few users will ever modify it. We're working to formally verify it.
- The scheduler is trusted for availability, but not for confidentiality and integrity. It is just another compartment. We provide a simple fixed-priority scheduler with priority inheriting futexes. We think it's a nice design for embedded systems, but if you want to build your own scheduler you really just need to implement the function that the switcher calls that says 'this is the thread that was interrupted, go and talk to the interrupt controller and figure out which new thread you want to run now' and the futex APIs.
- The heap allocator. This owns the region of memory used for the heap and works with the hardware to enforce spatial and temporal safety. We provide an implementation of this in C++, some folks at UBC are working on a reimplementation in Rust using Verus. If this is slower / bigger, we'll support both, if it's as good then we'll probably replace ours.
The RTOS also contains a bunch of optional shared libraries and makes it easy to wrap other components. For example, we have a network stack that puts BearSSL, the FreeRTOS TCP/IP stack, and the FreeRTOS MQTT libraries in compartments and adds a control-plane compartment that manages authorisation for socket creation and firewall control, a firewall compartment, and a DNS resolver compartment.
Most of these are small. If you want to replace BearSSL with WolfSSL or something similar, that should be easy. If you don't want to use it at all, that's fine too, you can replace the entire network stack with something different if you want to.
The goal is to have a load of building blocks that device vendors and end users can easily reuse if they want to, but that they can easily replace with their own things if they don't like ours.
We built an auditing framework that makes it easy to add CI-time or code-signing-time checks to enforce rules like 'only the firewall can talk to the network interface device directly' or 'only the TLS compartment may call the TCP send and receive functions'. We did this to support the conflicting requirements of proposed right-to-repair legislation (which should give end users the right to modify the software on their device) and other safety regulations (which may restrict the ability to modify things like the code talking to software-defined radio, or the safety-critical parts of a medical device). This enables people who build on the platform to create devices that empower their end users, even in domains where allowing replacement of the firmware may be illegal.
-
Mostly when I talk about #CHERIoT, I'm talking about the security, because that's the biggest and most obvious feature.
But since I've ranted a bit recently about Free Software things that don't empower users, I wanted to take a minute to write about how CHERIoT RTOS and is built on the principles that I think can provide maintainable systems.
The CHERIoT software is designed around compartments, which are somewhat like MULTICS shared libraries. They are isolated things that can own some mutable state and expose entry points, which are functions. Code in one compartment can invoke code in another compartment by simply calling a function that the other compartment exposes. This is a security domain transition. The callee has access to objects that were passed by reference, but there is no implicit sharing (and the hardware lets you share read-only view of data structures, or share for the duration of the call, and so on).
This model means that a lot of things that you run on the platform are tiny. This include the RTOS itself. There are four core bits of the RTOS:
- The switcher, which is the equivalent of the kernel, and is around 350 instructions. This is the most privileged part of the system and implements the fundamental bits of the programming model that are too complex to put in hardware. It is carefully co-designed with the hardware architecture though, and we expect very few users will ever modify it. We're working to formally verify it.
- The scheduler is trusted for availability, but not for confidentiality and integrity. It is just another compartment. We provide a simple fixed-priority scheduler with priority inheriting futexes. We think it's a nice design for embedded systems, but if you want to build your own scheduler you really just need to implement the function that the switcher calls that says 'this is the thread that was interrupted, go and talk to the interrupt controller and figure out which new thread you want to run now' and the futex APIs.
- The heap allocator. This owns the region of memory used for the heap and works with the hardware to enforce spatial and temporal safety. We provide an implementation of this in C++, some folks at UBC are working on a reimplementation in Rust using Verus. If this is slower / bigger, we'll support both, if it's as good then we'll probably replace ours.
The RTOS also contains a bunch of optional shared libraries and makes it easy to wrap other components. For example, we have a network stack that puts BearSSL, the FreeRTOS TCP/IP stack, and the FreeRTOS MQTT libraries in compartments and adds a control-plane compartment that manages authorisation for socket creation and firewall control, a firewall compartment, and a DNS resolver compartment.
Most of these are small. If you want to replace BearSSL with WolfSSL or something similar, that should be easy. If you don't want to use it at all, that's fine too, you can replace the entire network stack with something different if you want to.
The goal is to have a load of building blocks that device vendors and end users can easily reuse if they want to, but that they can easily replace with their own things if they don't like ours.
We built an auditing framework that makes it easy to add CI-time or code-signing-time checks to enforce rules like 'only the firewall can talk to the network interface device directly' or 'only the TLS compartment may call the TCP send and receive functions'. We did this to support the conflicting requirements of proposed right-to-repair legislation (which should give end users the right to modify the software on their device) and other safety regulations (which may restrict the ability to modify things like the code talking to software-defined radio, or the safety-critical parts of a medical device). This enables people who build on the platform to create devices that empower their end users, even in domains where allowing replacement of the firmware may be illegal.
