[TriEmbed] Article from FreeBSD Foundation Journal

[Scott Hall]

https://freebsdfoundation.org/our-work/journal/browser-based-edition/embedded-2/27494/
<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffreebsdfoundation.org%2Four-work%2Fjournal%2Fbrowser-based-edition%2Fembedded-2%2F27494%2F&data=05%7C02%7Cshall%40gilero.com%7C4899815f9e9744cc1b1808de0553c4d3%7C74762914b36b4d208b7a5969c28e9289%7C0%7C0%7C638954054517954735%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=26jUez7hvf8LZfRA5eSzvHrp7wlocLgQ66NdMtbzZKI%3D&reserved=0>

Subject matter relates heavily to embedded systems, middleware library use
and retrofitting, serializing data structures for IPC, and translation
look-aside buffers.  From the top of the webpage:



*Journal > Browser Based Edition > Embedded
<https://freebsdfoundation.org/our-work/journal/browser-based-edition/embedded-2/>
>
CHERIoT*



*CHERIoT*

*By David Chisnall*



*CHERI* <https://cheri-cpu.org/> is a set of architectural extensions that
provide fine-grained memory safety for everything from assembly code on up.
CHERI, like Capsicum, is a capability system. In a capability system, every
action must be accompanied by a capability, an unforgeable token of
authority, that authorizes the action.



The *CHERI* <https://cheri-cpu.org/> project has always had a close
relationship with FreeBSD. It began from observing that Capsicum-based
compartmentalization was great for new code but retrofitting it to existing
libraries (with one process per library instance) was difficult for two
reasons:



First, libraries want to share complex data structures, which imposes a lot
of serialization overhead when turning the interfaces into messages sent
over some inter-procedural communication (IPC) channel. A function call in
a normal library would simply share a data structure by passing a pointer
to an object. A privilege-separated library would need to authorize
everything moved between the caller and callee. Libraries also often want
long-term sharing, which imposes additional synchronization overhead.



Second, processes are isolated using a memory management unit (MMU), which
provides a virtual-memory abstraction with mappings from addresses in a
virtual address space to the underlying physical memory. Modern MMUs are
fast because they have a translation look-aside buffer (TLB), a fast cache
of translations. The TLB caches virtual to physical address translations.
If a single page is shared between ten processes, it will take ten TLB
entries. MMUs are great for isolation but poor for sharing.



These two problems led to the general observation: Isolation is easy,
sharing is hard.

-- 
Scott G. Hall
Raleigh, NC, USA
scottghall1 at gmail.com
*Although kindness is rarely a job, no matter what you do it's always an
option.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20251007/1fd26449/attachment.htm>