[{"content":"What I\u0026rsquo;m working on, reading, and thinking about — updated periodically. A page in the spirit of nownownow.com.\nWorking on Leading OpenTitan at Google — building secure, reliable provisioning across hardware and software for ChromeOS, data center, and beyond. Sharpening engineering practices and review culture across a multi-team, multi-org program. Reading and learning Capability-based hardware architectures — CHERI and CHERIoT. Memory-safe systems languages and how they interact with secure hardware. The leadership tradeoffs of running zero-to-one projects inside large organizations. Writing Posts on engineering, leadership, and the lessons of building real systems with real constraints. On the near-term radar: secure provisioning at scale, capability hardware in production, engineering leadership at the staff and principal level. Outside work Strength training and running, with an eye on long-term resilience. Time with family, two cats, and the occasional guitar session. Looking for ways to stay grounded in the AI moment without losing curiosity. Last updated: April 2026.\n","permalink":"https://moidx.com/now/","summary":"\u003cp\u003e\u003cem\u003eWhat I\u0026rsquo;m working on, reading, and thinking about — updated periodically.\nA page in the spirit of \u003ca href=\"https://nownownow.com/about\"\u003enownownow.com\u003c/a\u003e.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"working-on\"\u003eWorking on\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eLeading \u003cstrong\u003eOpenTitan\u003c/strong\u003e at Google — building secure, reliable provisioning\nacross hardware and software for ChromeOS, data center, and beyond.\u003c/li\u003e\n\u003cli\u003eSharpening engineering practices and review culture across a multi-team,\nmulti-org program.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"reading-and-learning\"\u003eReading and learning\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eCapability-based hardware architectures — CHERI and CHERIoT.\u003c/li\u003e\n\u003cli\u003eMemory-safe systems languages and how they interact with secure hardware.\u003c/li\u003e\n\u003cli\u003eThe leadership tradeoffs of running zero-to-one projects inside large\norganizations.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"writing\"\u003eWriting\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePosts on engineering, leadership, and the lessons of building real systems\nwith real constraints.\u003c/li\u003e\n\u003cli\u003eOn the near-term radar: secure provisioning at scale, capability hardware\nin production, engineering leadership at the staff and principal level.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"outside-work\"\u003eOutside work\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eStrength training and running, with an eye on long-term resilience.\u003c/li\u003e\n\u003cli\u003eTime with family, two cats, and the occasional guitar session.\u003c/li\u003e\n\u003cli\u003eLooking for ways to stay grounded in the AI moment without losing curiosity.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cem\u003eLast updated: April 2026.\u003c/em\u003e\u003c/p\u003e","title":"Now"},{"content":"The world is changing rapidly. Artificial Intelligence is becoming deeply embedded in our daily lives. Strangely, rather than pushing me toward constant motion, this wave of transformation has helped me slow down. It\u0026rsquo;s made me more present, more attuned to the small, essential joys: spending time with my family, sharing a quiet morning with my cats, or revisiting a favorite song on my guitar.\nSome things are undeniably faster now. But not everything, at least not yet. And maybe not ever. This tension between acceleration and presence has made me more deliberate about how I live. I train at the gym not just for today, but to preserve strength and mobility as I age. I run, not only for fitness, but to meditate.\nI\u0026rsquo;ve started to think differently about my kids\u0026rsquo; paths, too. I\u0026rsquo;m not rushing my son into a corporate job. Maybe he can try building something first and see where it goes. My daughter is preparing for college, but I encourage her to leave space for exploration. Check fewer boxes. Spend more time discovering what lights her up. This doesn\u0026rsquo;t mean I don\u0026rsquo;t support their ambition. On the contrary, I love watching them work hard and enjoy the journey.\nAs for the future? I don\u0026rsquo;t know what\u0026rsquo;s coming as AI continues to evolve. Today, we use it to augment our work. It helps us write better documentation, maintain legacy codebases, and prototype systems. We\u0026rsquo;re experimenting with multi-agent setups where one agent drafts a design document, while another implements code. It\u0026rsquo;s like emulating a team of junior engineers.\nBut make no mistake, we\u0026rsquo;re still hiring junior engineers. The goal is to accelerate their learning, to help them develop the kind of intuition that takes years to build. Intuition that comes from designing, debugging, maintaining systems and collaborating with other humans.\nRight now, AI is a tool. But will that always be true?\nI suspect not. Someday, AI may surpass even our most talented engineers. At that point, the narrative of AI as \u0026ldquo;just a tool\u0026rdquo; might no longer hold. A new world will open up. We don\u0026rsquo;t yet know what it will look like.\nUntil then, I\u0026rsquo;ll keep strumming that old song. I\u0026rsquo;ll lift the weights, run the trail, and sit quietly with the cats. Because even as we race toward the future, being present is what keeps us grounded.\n","permalink":"https://moidx.com/posts/staying_grounded/","summary":"\u003cp\u003eThe world is changing rapidly. Artificial Intelligence is becoming deeply\nembedded in our daily lives. Strangely, rather than pushing me toward constant\nmotion, this wave of transformation has helped me slow down. It\u0026rsquo;s made me more\npresent, more attuned to the small, essential joys: spending time with my\nfamily, sharing a quiet morning with my cats, or revisiting a favorite song on\nmy guitar.\u003c/p\u003e\n\u003cp\u003eSome things are undeniably faster now. But not everything, at least not yet. And\nmaybe not ever. This tension between acceleration and presence has made me more\ndeliberate about how I live. I train at the gym not just for today, but to\npreserve strength and mobility as I age. I run, not only for fitness, but to\nmeditate.\u003c/p\u003e","title":"Staying Grounded"},{"content":" Cover image taken from the cheriot-ibex GitHub project..\nEver found yourself staring at a debugger, chasing a memory corruption bug that seems to defy logic? Or maybe you\u0026rsquo;ve sunk countless hours hardening C/C++ code against the ever-present threats of buffer overflows and use-after-free vulnerabilities? If you\u0026rsquo;re an embedded systems developer, you\u0026rsquo;ve likely been there. These memory safety issues aren\u0026rsquo;t just annoyances; they\u0026rsquo;re prime vectors for security exploits. But what if we could tackle these problems at their very root – right down in the hardware?\nThat\u0026rsquo;s where CHERI (Capability Hardware Enhanced RISC Instructions) enters the scene. It\u0026rsquo;s not just another software patch or a new programming language. CHERI is a set of architectural extensions poised to change the way we approach pointers and memory access. This post is a quick dive into CHERI. We\u0026rsquo;ll unpack its core ideas, see how it ticks under the hood, explore its implications for C/C++, its synergy with Rust, and discuss the practicalities of bringing this tech into the real world of embedded systems.\nDisclaimer: I am not an expert in CHERI. This document captures notes of my current understanding of CHERI and its potential use cases. See the references section at the end of the document if you are looking for more in-depth material.\nPointers and Their Pitfalls In C and C++, pointers are the workhorses giving us incredible power and direct memory control. But, as the saying goes, \u0026ldquo;with great power comes great responsibility.\u0026rdquo; And let\u0026rsquo;s be frank, that responsibility can be a heavy lift.\nThe classic C/C++ pointer is, at its heart, just a number – a memory address. This elegant simplicity is also its Achilles\u0026rsquo; heel:\nSpatial Unsafety: It\u0026rsquo;s all too easy to write past an array or buffer\u0026rsquo;s end. This is your classic buffer overflow. The fallout? Corrupted adjacent data, trashed program state, or, in a security nightmare, overwritten return addresses enabling attackers to hijack control flow. Temporal Unsafety: Ever used a pointer to memory that\u0026rsquo;s already been free()\u0026rsquo;d? That\u0026rsquo;s a \u0026ldquo;dangling pointer.\u0026rdquo; The memory it once pointed to might now hold entirely different data. Using that old pointer can lead to bizarre crashes, subtle data corruption, or, you guessed it, exploitable security holes. Memory safety issues are a significant concern, accounting for a large percentage of patched security vulnerabilities. While software-based solutions can be challenging, impact performance, or have limitations, CHERI offers a hardware-level solution.\nCHERI Capabilities: Hardware-Backed Pointers How does CHERI intend to solve these problems? Instead of raw memory addresses, CHERI introduces a richer concept: capabilities.\nThink of a capability not just as a signpost, but as a special key fob. This fob doesn\u0026rsquo;t just show where the door (memory location) is; it also dictates:\nWhich specific doors it can open (the bounds of the memory region). What you\u0026rsquo;re allowed to do once inside – just look (read), redecorate (write), or even host a party (execute) (the permissions). And crucially, this key fob is unforgeable. You can\u0026rsquo;t just whip one up or easily tamper with an existing one to gain more access. In a CHERI system, every C/C++ pointer, including implicit ones like the stack or global pointer, becomes a hardware-enforced capability. It\u0026rsquo;s a shift from \u0026ldquo;here\u0026rsquo;s an address, good luck!\u0026rdquo; to \u0026ldquo;here\u0026rsquo;s an authorized way to access this specific memory for these specific purposes.\u0026rdquo; (read more: in-depth intro).\nAnatomy of a CHERI Capability A CHERI capability is more than an address; it\u0026rsquo;s a bundle of hardware-enforced information. While the exact bit-layout can vary (e.g., 64-bit CHERI vs. embedded-focused CHERIoT), the core concepts hold.\nSince I am mostly interested in embedded security applications, such as secure enclaves or Root of Trust (RoT) technology, I will be focusing more on the CHERIoT implementation details. The document will use the term CHERI to refer to high level CHERI concerpts and CHERIoT or cheriot-ibex to refer to the CHERIoT implementation based on the Ibex RISC-V 32IMC processor.\nHere\u0026rsquo;s a conceptual look at a CHERIoT (CHERI for IoT) capability:\n+--------+ | Tag | +--------+ | v +------------------+ | | | +--------+ | | | Perm | | | +--------+ | | | | | v | | +--------+ | | | Type | | Capability | +--------+ | Metadata | | | | v | | +--------+ | | | Bounds | | | +--------+ | | | +------------------+ | v +------------------+ | Address | +------------------+ | v +------------------+ | Memory Range | +------------------+ Figure 1: A conceptual illustration of CHERI capability components and their relation to a memory region.\nLet\u0026rsquo;s dissect these parts:\nAddress: The familiar part – the current memory address the capability points to. Bounds (Base and Top/Length): This is key for memory safety. Every capability knows the exact range it can access, defined by a \u0026lsquo;base\u0026rsquo; and \u0026rsquo;top\u0026rsquo; address (or base and length). Try to step outside these bounds, even by a byte? You will get a hardware trap. No more silent corruption. This is your hardware-enforced spatial memory safety. Embedded Note: In space-constrained systems, bounds are often compressed. Instead of full base/top addresses, it might store the current address and use a floating-point-like encoding for distances to base/top. This saves bits but means larger regions might need specific alignment for precise representation. Permissions: This field dictates what the capability can do. Think of it as the fine print: Load (Read): Permission to read data. Store (Write): Permission to write data. Execute: Permission to fetch and run instructions (crucial for W^X). Load/Store Capability: A meta-permission: can this capability load/store other capabilities? Vital for preventing data buffers from being treated as holding powerful pointers. Global: Governs the capability itself. A \u0026ldquo;global\u0026rdquo; capability can be stored anywhere. A \u0026ldquo;non-global\u0026rdquo; one (like for a stack variable) might only be storable in restricted regions (like the stack, which would need \u0026ldquo;store-local\u0026rdquo; permission). This enforces pointer scoping. Seal/Unseal: For advanced security via \u0026ldquo;sealing.\u0026rdquo; Tag Bit: The magic that makes capabilities unforgeable. It\u0026rsquo;s an extra, invisible bit. Hardware sets it to \u0026lsquo;valid\u0026rsquo; only for legitimate capabilities. Tamper with a capability in memory via ordinary data writes, or if an operation invalidates it? The hardware automatically clears the tag. Load a potential capability? The CPU checks the tag. No tag? Just data. Trying to use data as a capability will result in a hardware trap. You can\u0026rsquo;t just conjure a valid, tagged capability. Type (Object Type for Sealing): Usually zero for a normal, usable (unsealed) capability. Non-zero means it\u0026rsquo;s sealed. Sealing: Puts a capability in a tamper-proof envelope. Once sealed, you can\u0026rsquo;t use it to access memory or change its attributes without the hardware zapping its tag. It\u0026rsquo;s an opaque token. To use it, you need another special capability with permit-unseal and a matching \u0026ldquo;object type.\u0026rdquo; Powerful for secure handles and protecting things like return addresses. Together, these make CHERI capabilities rich, hardware-enforced descriptors of memory access rights.\nAdditional details on Tag and Type fields: CHERI\u0026rsquo;s Hardware Root of Trust Security experts will rightly ask: \u0026ldquo;How can we trust the tag bit and type field against software tampering?\u0026rdquo; The answer: their protection is architectural, enforced by hardware, not just a software convention.\nThe following sections use CHERIoT as a particular implementation example.\nThe Tag Bit The tag bit is the cornerstone of unforgeability.\nHardware Exclusive Generation: Tags are set by hardware only: during initial capability creation (e.g., by a system loader) or when deriving a new capability from a valid one via privileged CHERI instructions. Standard software instructions cannot arbitrarily set a tag. Tags in Memory: A Parallel, Protected World: CHERIoT capabilities (e.g., 65 bits: 64 for data + 1 tag) store the tag in dedicated tag memory (tag RAM) paralleling main data RAM. For every capability-sized chunk in main memory, there\u0026rsquo;s a corresponding tag bit in tag RAM. Standard data store instructions (SW in RISC-V) cannot directly write to tag memory. If a data write targets a location holding a valid capability, the memory controller hardware automatically clears the corresponding tag bit. Only CHERI-specific capability store instructions can write both the capability data and set its tag to valid. This hardware gatekeeping prevents software from forging capabilities by simply overwriting memory. Tags on the Move: Propagation and Invalidation: When loading a capability, both data and tag are fetched. No tag? The loaded value is invalid in the CPU register. Tags propagate with valid CHERI operations. Any operation invalidating a capability (invalid derivation, bounds violation, data overwrite) makes the hardware clear the tag. All or Nothing: Atomic Operations: Capability (data + tag) movements between registers and memory are architecturally atomic, preventing race conditions. The Type Field The type field is key to CHERI\u0026rsquo;s sealing mechanism, creating opaque, tamper-proof pointers.\nPurpose: A non-zero type makes a capability sealed. It can\u0026rsquo;t directly access memory or have its attributes changed without invalidating its tag. It\u0026rsquo;s an opaque token. Storage: The type field (e.g., 3 bits in CHERIoT) is part of the 64-bit capability metadata in main memory. Integrity via the Tag: The type field\u0026rsquo;s security, like all capability metadata, is guaranteed by the tag bit. When sealing, the object type is set. If software then tries to modify any part of this sealed capability in memory with a standard data write (SW), the hardware sees it as a data overwrite and clears the tag. The tampered capability becomes untagged and invalid. Unsealing requires another capability with permit-unseal and a matching type. Security Claims For a CHERIoT system:\nHardware Enforcement: Tag unforgeability and integrity are enforced by the CHERIoT architecture, implemented in the cheriot-ibex load store unit. Segregated Tag Pathway: Tag management is out-of-band for normal software. Standard instructions clear tags on overwrite; CHERI-specific instructions manage them via privileged hardware paths. Deterministic Behavior: Misuse or forgery attempts lead to deterministic hardware traps, not exploitable undefined behavior. While microarchitectural details (like tag RAM layout or sealing) are deeper in the design, the CHERIoT architectural guarantees upheld by cheriot-ibex provide a robust hardware root of trust for capability integrity.\nHow CHERI Actually Delivers on Memory Safety \u0026amp; Security With capabilities boasting bounds, permissions, and unforgeable tags, how does this translate to a safer embedded world? It\u0026rsquo;s all about what the hardware prevents.\nSpatial Memory Safety: If capability p is for a 10-integer array, accessing p[10] (out of bounds) violates p\u0026rsquo;s hardware-enforced bounds. The processor traps immediately. Temporal Memory Safety: When memory is freed, CHERIoT systems can use a load filter and a revoker. The load filter checks a shadow bitmap on capability load; if the memory is stale (freed), the loaded capability\u0026rsquo;s tag is cleared. A background revoker scans memory, clearing tags of capabilities pointing to deallocated regions. So, using a capability to freed memory likely means using an untagged (invalid) one, causing a trap. Pointer Provenance: Capabilities are unforgeable and only derivable from other valid capabilities. You can\u0026rsquo;t just cast an integer to a pointer and roam free. All valid capabilities trace back to an initial, system-granted set. Principle of Least Privilege: Software gets only the permissions it needs. Pass a read-only capability to a function needing only to read, even if the original was read-write. Hardware enforces this. Intentional Use: Privileged operations require intentional use of the specific authorizing capability, thwarting \u0026ldquo;confused deputy\u0026rdquo; attacks. Additional details on CHERIoT While CHERI is a general architecture, CHERIoT is its lean, mean incarnation for resource-constrained embedded/IoT devices.\nCompressed Bounds: CHERIoT uses clever encodings for bounds, saving memory. Smart Permission Encoding: For 32-bit addresses (64-bit capabilities + tag), CHERIoT intelligently packs permissions, sometimes using primary/dependent distinctions. Some theoretical combinations might not be expressible, but practical security is maintained. No Half Measures (No Hybrid Mode): CHERIoT generally mandates all-capability pointers, assuming full recompilation for simplicity and stronger guarantees. Built for Compartmentalization: CHERI capabilities underpin CHERIoT\u0026rsquo;s software compartmentalization. Firmware can be divided into secure, isolated \u0026ldquo;compartments\u0026rdquo; that communicate via hardware-mediated entry points, with hardware sanitizing state on transitions. Why Isn\u0026rsquo;t CHERI Everywhere? With such compelling benefits, why isn\u0026rsquo;t CHERI in every chip? The path from research to widespread adoption is a marathon, especially for fundamental changes to CPU memory handling. It\u0026rsquo;s a classic \u0026ldquo;chicken and egg\u0026rdquo; scenario involving the entire hardware and software ecosystem (history lesson).\nThe Silicon-Software Interlock: Silicon Vendors: Need strong market demand and a mature software ecosystem (compilers, OS, debuggers) before investing heavily in CHERI-enabled silicon. Software Ecosystem: Toolchain and OS developers are wary of committing major resources to an architecture without readily available commercial hardware for testing and validation. Ecosystem Inertia and Investment: Legacy Code: Vast C/C++ codebases need recompilation. While CHERI aims for high source compatibility, some porting effort is inevitable, especially for low-level code. This is particularly true for RoT software. Learning Curve: Developers need to learn new concepts and tools. Cost: Initial hardware redesign and software porting costs can be daunting without clear market pull. Most people will say that switching to Rust is cheaper. More on this later. Standardization and Maturation: Full industry standardization and a mature software ecosystem take time and collaborative effort. Initiatives like the CHERI Alliance are vital in fostering this. A Path Forward: Enabling a Platform TLDR; The most pragmatic approach is to enable a hardware platform that supports hybrid modes of operation. Once the hardware is available, it will be easier to upstream toolchain changes and enable software teams to eavaluate the technology. In the particular case for CHERIoT, hybrid doesn\u0026rsquo;t mean running software with legacy pointers and capabilities; rather, it means giving developers the option to enable CHERI as a runtime option. For example, the first mutable instruction fetched by the processor can be configure to execute in CHERI or regular RISC-V 32IMC mode of execution.\nHybrid CHERI architectures – CPUs supporting both legacy and capability modes – offer a pragmatic solution.\nBackward Compatibility: They run existing, unmodified software, lowering the entry barrier. Facilitating Toolchain Development: Hybrid cores prototyped in research projects provide crucial platforms for maturing the CHERI software ecosystem. This incremental path de-risks the transition, building software support and demonstrating value, which encourages more hardware adoption. Research silicon like Microsoft\u0026rsquo;s CHERIoT-Ibex and other CHERI-enabled products like those from Codasip are key.\nPractical Considerations: Area Overhead of CHERIoT on Ibex So, CHERIoT is powerful, but what\u0026rsquo;s the silicon cost? The paper \u0026ldquo;Area Comparison of CHERIoT and PMP in Ibex\u0026rdquo; (Riedel et al., arXiv:2505.08541v1) offers insights by comparing CHERIoT and traditional Physical Memory Protection (PMP) on the Ibex RISC-V core.\nCore-Level Impact For a baseline Ibex core (~57 kGE - kilo Gate Equivalents):\nPMP (16 regions): Added ~24 kGE (a 42% core overhead), mainly from PMP checking logic and CSRs. CHERIoT: Added ~33 kGE (a 57.5% core overhead). Key contributors: CHERI-specific logic (~16 kGE), more CSRs, a doubled register file, and enhanced LSU/WB stages. CHERIoT-Ibex was ~11% larger than PMP-Ibex, largely due to the register file.\nThe Bigger Picture: System-on-Chip (SoC) A 40-60% core increase sounds like a lot, but in an SoC (like OpenTitan Earl Grey), the CPU is often a small part. Most area goes to memory, peripherals, and accelerators.\nThe baseline Ibex might be just 1.4% of the total SoC area. Adding PMP to Ibex: estimated SoC area increase of ~0.6%. Adding CHERIoT: core extension (~0.8% SoC area) + memory system changes (tags, wider bus, ~0.2% SoC area) = total ~1% SoC area increase. Area Conclusion While CHERIoT has a larger core-level overhead than PMP (57.5% vs 42.1% in the study), its SoC impact is modest (~1%). Given CHERIoT\u0026rsquo;s vastly superior fine-grained spatial/temporal memory safety and compartmentalization, this is often a justifiable trade-off for security-critical systems.\nRust and CHERI: A \u0026ldquo;Belt and Suspenders\u0026rdquo; Security Win? Rust\u0026rsquo;s ownership and borrowing system offers strong compile-time memory safety. So, if your stack is all Rust, is CHERI still useful? Maybe?\nWhy CHERI and Rust? Guarding unsafe Frontiers: Rust\u0026rsquo;s unsafe blocks bypass some compile-time checks for low-level code or FFI (as discussed in CHERI outreach and explored at FOSDEM). CHERI provides a runtime hardware backstop here. Fortifying the Foreign Function Interface (FFI) Wall: When Rust calls C/assembly, CHERI can enforce memory safety on the non-Rust side and ensure data passed via capabilities has hardware-enforced restricted permissions (explained well on the CHERIoT blog). Safety Net for Compiler/Runtime Bugs: Though rare, bugs here could compromise memory safety. CHERI offers an independent hardware defense (see Cambridge CHERI research). Hardware-Powered Compartments: CHERI enables hardware-enforced isolation between Rust modules or third-party crates, limiting blast radius. Enhanced unsafe Semantics: CHERI can potentially offload some runtime checks (like slice bounds) to hardware and inherently includes pointer provenance. Use Case: Securing a C/Assembly Crypto Library A C/assembly crypto library (like OpenTitan\u0026rsquo;s) is a prime candidate for CHERI protection within a Rust stack. Rewriting such intricate, hardware-tied code in Rust is a massive task and might negate security/performance tuning.\nCHERI helps by:\nMemory Safety for Unsafe Code: Compiling the C/assembly library for CHERI means its internal memory errors become hardware traps. Asset Isolation – Protecting Keys: Crypto Compartment: Run the library in its own CHERI compartment, granted minimal capabilities to access crypto hardware and its private key storage. Key Capabilities: Keys are represented by highly restricted capabilities held exclusively by this compartment, perhaps only usable by specific crypto accelerator instructions, not for general read/write. No Direct Key Exposure: Rust code calls the crypto compartment, passing data. The compartment uses its internal, private key capabilities. Key material never leaves. Tamper-Proof Handles: For multiple key contexts, the library gives Rust opaque, sealed capabilities as handles. Only the crypto compartment can unseal them. Resilience: If other system parts are compromised, keys remain protected by hardware-enforced capability isolation. Hybrid Approach: Rust for Logic, CHERI-C/Assembly for Sensitive Cores Using Rust for general logic and CHERI-C/assembly for critical cores (like a crypto library) offers:\nRust\u0026rsquo;s Strengths: Productivity, modern features, compile-time safety for most code. Secure Enclaves: C/assembly gets a hardware-enforced sandbox. Hardened FFI: Calls between Rust and C/assembly cross a CHERI protection boundary; capabilities are checked. Asset Protection: Sensitive data in C/assembly compartments is locked down. This pragmatic model leverages Rust\u0026rsquo;s safety for new code while securely incorporating essential, hard-to-replace low-level components, underpinned by CHERI\u0026rsquo;s hardware security.\nWhat This Means for C/C++ Developers For C/C++ developers, CHERI mostly works behind the scenes via a CHERI-aware compiler. Key changes:\nUndefined Behavior Becomes Deterministic Faults: Many pointer errors (out-of-bounds, null dereference) become precise hardware traps. This is huge for debugging and thwarts exploits. ABI Adapts: The Application Binary Interface defines how capabilities are used for function calls, returns, and system calls. CHERIoT, for instance, uses a trusted \u0026ldquo;switcher\u0026rdquo; to manage inter-compartment calls, clearing registers and adjusting stack capabilities for isolation. CHERI Toolchain: You\u0026rsquo;ll use a CHERI-enabled compiler (LLVM/Clang, potentially GCC). Builtins (for the Curious): CHERI C provides intrinsics for direct capability manipulation (bounds, permissions, sealing/unsealing) for low-level or specialized code. Essentially, CHERI offers a hardware safety net for C/C++, catching common memory errors.\nContext for Security Experts CHERI represents a fundamental shift in secure system design:\nMitigates Common Exploits: Directly undermines memory corruption exploits like stack smashing, heap corruption, and many ROP/JOP attacks, thanks to capability integrity and sealed pointers (see CHERI overview papers). Stronger than MPU/MMU Alone: Offers fine-grained, intra-process memory safety and robust compartmentalization beyond traditional process-level isolation. Foundation for Secure IPC/FFI: Sealed capabilities enable secure inter-component communication with tamper-proof handles. Auditability by Design: CHERIoT\u0026rsquo;s build system can report capabilities granted to compartments, enabling automated security policy verification. Revocation Trade-offs: Direct capability storage simplifies common operations but makes broad revocation more complex than indirection-based systems. CHERIoT uses load filters and revocation sweeps for heap temporal safety. CHERI moves many memory safety duties from fallible software to infallible hardware enforcement.\nClosing Thoughts CHERI and CHERIoT are serious, long-term efforts to build a more secure digital foundation. By baking memory safety and least privilege into hardware, CHERI offers a powerful alternative to the endless cycle of software patches.\nFor embedded developers, this means more secure, robust, and reliable systems, even with C/C++. As CHERI-enabled hardware (like cheriot-ibex) and toolchains mature, our approach to embedded security is set for a significant, welcome transformation – moving from memory safety as a constant battle to an inherent platform property.\nThere are still several challenges ahead in brining this technology to real products, most dealing with engineering cost and use case alignment. Use cases moving to Rust are currently not as interested in CHERI as they see it as a very expensive with not clear ROI. There is also skepticism about the technology being mature enough due to lack of upstream toolchain support and commercial grade silicon.\nHowever, interest in some industries such as automotive and mobile is growing, as CHERI provides interesting isolation guarantees. There are pre-certified applications in these fields for which it is probably easier to migrate them to CHERI than it is to re-write them in memory safe programming languages.\nTime will tell. The next couple of years will be very interesting to watch in this space.\nFurther Reading If this dive into CHERI has piqued your interest, here are some excellent resources:\nThe CHERI Website (University of Cambridge): The official home for CHERI research, packed with papers, presentations, and detailed specifications. Start with their CHERI FAQ and the Introduction to CHERI technical report. \u0026ldquo;Area Comparison of CHERIoT and PMP in Ibex\u0026rdquo; by Riedel et al. (arXiv:2505.08541v1): The research paper on area overhead. Microsoft\u0026rsquo;s CHERIoT and cheriot-ibex Resources: Public repositories/documentation from Microsoft Research (e.g., github.com/microsoft/cheriot-ibex). lowRISC and OpenTitan: Context on the Ibex core and secure silicon. (lowrisc.org, opentitan.org). CHERI Alliance: Industry initiative for CHERI adoption. (cheri-alliance.org). \u0026ldquo;Strengthening memory safety in Rust: exploring CHERI capabilities for a safe language\u0026rdquo; by Nicholas Wei Sheng Sim: Dissertation on Rust \u0026amp; CHERI. (nw0.github.io/cheri-rust.pdf). Relevant Blog Posts and Articles: \u0026ldquo;How to talk to your parents about hardware memory safety\u0026rdquo; (CHERIoT Platform Blog: cheriot.org/cheri/2024/08/06/how-to-talk-about-CHERI.html) \u0026ldquo;CHERI Myths: CHERI is incompatible with safety-critical systems\u0026rdquo; (CHERIoT Platform Blog: cheriot.org/cheri/myths/2024/11/25/cheri-myths-safety-critical.html) \u0026ldquo;CHERI: Hardware-Enabled C/C++ Memory Protection at Scale\u0026rdquo; (University of Cambridge: www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20240419-ieeesp-cheri-memory-safety.pdf) \u0026ldquo;A Rusty CHERI - The path to hardware capabilities in Rust\u0026rdquo; (FOSDEM 2023: archive.fosdem.org/2023/schedule/event/rust_a_rusty_cheri_the_path_to_hardware_capabilities_in_rust/) This list should give you plenty to explore :)\n","permalink":"https://moidx.com/posts/cheri/","summary":"\u003cblockquote\u003e\n\u003cp\u003eCover image taken from the \u003ca href=\"https://github.com/microsoft/cheriot-ibex\"\u003echeriot-ibex\u003c/a\u003e GitHub project..\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eEver found yourself staring at a debugger, chasing a memory corruption bug that seems to defy logic? Or maybe you\u0026rsquo;ve sunk countless hours hardening C/C++ code against the ever-present threats of buffer overflows and use-after-free vulnerabilities? If you\u0026rsquo;re an embedded systems developer, you\u0026rsquo;ve likely been there. These memory safety issues aren\u0026rsquo;t just annoyances; they\u0026rsquo;re prime vectors for security exploits. But what if we could tackle these problems at their very root – right down in the hardware?\u003c/p\u003e","title":"Wondering About CHERI/CHERIoT?"},{"content":"Congratulations! You\u0026rsquo;ve successfully navigated interviews, completed team matching, and finally landed your first tech job. Starting fresh in a professional environment can feel overwhelming—I certainly felt that way when I began my journey as a hardware engineer at Motorola in 2007. Remember, everyone starts somewhere. Whether you\u0026rsquo;re fresh out of school or transitioning from another field, your first year sets the foundation for your career.\nThis guide shares practical insights from my experiences, intended to help you confidently navigate your first steps in tech.\nUnderstand Your New Environment Map Your Team, Org, and Company Your team is part of a larger ecosystem. When I joined Google, clearly understanding how my team\u0026rsquo;s work fit into the broader company strategy significantly influenced my career trajectory. Early clarity helps prioritize tasks and ensures your personal development aligns with strategic goals.\nKey Questions to Start With:\nWhat are the team\u0026rsquo;s core products and services? Who are the key decision-makers? Which projects closely align with organizational priorities? Evaluate Project Alignment Not all projects carry equal weight. Early in my career, I learned the importance of aligning my efforts with organizational goals, especially when switching from hardware to software roles. Projects closely tied to organizational priorities offer stability and valuable growth opportunities. Conversely, riskier projects should be approached with caution.\nFrom experience: Engage in high-risk projects only if there\u0026rsquo;s strong executive sponsorship, clear timelines, and a clearly defined value proposition.\nEssential Technical Skills Technical skills vary by role, but these foundational competencies have consistently proven valuable across different stages of my career:\nContinuous and Proactive Learning The technology industry evolves quickly, and staying ahead requires continuous learning. Quickly absorbing new information, effectively navigating technical documentation, and understanding architectural trade-offs are essential. Stay curious, regularly explore new technologies, and actively engage with your team to maximize your learning.\nDebugging Expertise Developing robust debugging skills across multiple abstraction levels (hardware, software, system-level) has consistently enhanced my productivity and effectiveness. Prioritize honing these skills.\nSystematic Testing Effective testing practices were pivotal in maintaining quality and scalability, particularly during complex projects like OpenTitan at Google.\nDigestible Artifacts Creating manageable, easy-to-review contributions greatly improved collaboration and overall code quality throughout my career. Planning and strategizing your changes beforehand ensures minimal disruption to the existing codebase.\nMonitoring and Logging Developing proficiency with monitoring, logging, and alerting systems dramatically enhanced operational reliability and reduced downtime across projects I\u0026rsquo;ve managed.\nSeek Mentorship Mentorship significantly accelerated my professional growth. Most companies offer structured mentorship programs, but also actively seek mentors within your immediate team or broader organization. Engage your manager to facilitate connections.\nMentorship Best Practices:\nRegularly schedule check-ins. Come prepared with specific, actionable questions. Foster genuine relationships through reciprocal support. Overcome Social Anxiety and Improve Communication Technical expertise alone is insufficient. Although I\u0026rsquo;ve personally struggled with social anxiety, consistently working on communication skills has profoundly enhanced my career. Improvement is ongoing, so patience and persistence are key.\nStrategies that helped me:\nRegularly engage in small, low-stakes interactions. Embrace public speaking opportunities, even when uncomfortable. Incrementally push your comfort zone. Navigate Ambiguity Wisely Ambiguity is minimal in early roles but becomes increasingly prevalent as you advance to senior positions. Developing the skill to systematically reduce ambiguity at personal, team, organizational, and company levels has been crucial to my career growth. This ability ensures clarity and enhances decision-making effectiveness.\nCalibrate Expectations Proactively understanding career ladder expectations for both your current and future roles is vital. Initially, aligning your projects closely with current-level expectations is appropriate. As you aim for promotion, increasingly focus your projects towards expectations of the next career level.\nAdditionally, ensure your work remains relevant to your team and organization. If your tasks feel misaligned, actively investigate why. Is your team laying strategic foundations for future organizational growth, or are you potentially misaligned with your career objectives?\nJournal Your Journey Maintaining a structured journal profoundly improved my career progression. Regularly mapping planned tasks against career ladder expectations has consistently aligned my efforts with desired competencies. This practice simplifies performance reviews by clearly summarizing key contributions. Reflecting on peer and managerial feedback further deepens self-awareness and guides continuous improvement.\nRecommended Journaling Practices:\nClearly align your tasks and achievements with career ladder expectations. Regularly document key accomplishments for straightforward performance summaries. Consistently reflect on feedback received and detail actionable responses. Your first tech job isn\u0026rsquo;t just about immediate tasks—it\u0026rsquo;s about laying a strong foundation for a fulfilling, evolving career. Stay curious, proactive, and adaptable. These principles have consistently driven my professional growth in Engineering.\nEnjoy your journey!\n","permalink":"https://moidx.com/posts/first_job_tips/","summary":"\u003cp\u003eCongratulations! You\u0026rsquo;ve successfully navigated interviews, completed team matching, and finally landed your first tech job. Starting fresh in a professional environment can feel overwhelming—I certainly felt that way when I began my journey as a hardware engineer at Motorola in 2007. Remember, everyone starts somewhere. Whether you\u0026rsquo;re fresh out of school or transitioning from another field, your first year sets the foundation for your career.\u003c/p\u003e\n\u003cp\u003eThis guide shares practical insights from my experiences, intended to help you confidently navigate your first steps in tech.\u003c/p\u003e","title":"Thriving in Your First Tech Job"},{"content":"I\u0026rsquo;ve been in this game for almost two decades — from debugging pre-silicon firmware with an oscilloscope in hand, to leading 40+ engineers across organizations to deliver production silicon. I\u0026rsquo;ve shipped chips, built secure boot flows, led zero-to-one projects, and steered open-source hardware like OpenTitan into Google\u0026rsquo;s data center infrastructure.\nBut if I\u0026rsquo;m being honest, leadership can feel like a climb to a ledge — and some days, it feels like the only way down is to jump.\nThe Climb Early on, the work is pure. You chase bugs, polish code, build things for the sheer satisfaction of seeing them work. You\u0026rsquo;re deep in the craft, focused, fulfilled.\nThen, the scope expands. You move from writing functions to designing systems, from fixing issues to shaping roadmaps. You lead people. You become the one others rely on.\nAnd with that, the stakes grow. Visibility increases. So does impact. And so does the height of the ledge. You begin to wonder — is the next escalation, the next impossible deadline, the one that pushes you too far?\nThe Fracture Point I didn\u0026rsquo;t notice burnout creeping in. It was a slow erosion of the joy I used to feel. I found myself numb during moments when we should\u0026rsquo;ve been celebrating. The calendar filled with meetings, and the real work shifted to late nights.\nMy health deteriorated. I gained more than 30 pounds. Some nights, I genuinely thought I might be on the verge of a heart attack. My body was waving red flags, but I was too buried in politics, execution, and expectations to see it.\nStill, I kept going. Not out of ego, but because I didn\u0026rsquo;t want to let my team down. The challenge has always been how to become replaceable — to enable scale, to empower others, to move on to the next challenge. I\u0026rsquo;ve never chased credit, just progress.\nEventually, my creativity dulled. My journal turned hollow. That\u0026rsquo;s when I knew something had to change.\nRebuilding Recovery wasn\u0026rsquo;t about quitting — it was about rebalancing. I started carving out time for hands-on work again, not out of obligation, but because I missed it. I reconnected with the joy of building.\nI also committed to being more present. I made time for my wife, my kids, my friends — even my cats. I practiced being there for the people who had been there for me all along.\nI got serious about my health. I tracked what I ate, upped my protein, cut the occasional drink. I started powerlifting — and I love it. It\u0026rsquo;s technical, it\u0026rsquo;s challenging, and most importantly, it\u0026rsquo;s something I get to learn and do alongside others.\nThrough it all, I reconnected with the parts of me that aren\u0026rsquo;t tied to any role or title. The human underneath the engineer.\nWhere I Am Now I still lead. I still build. Product delivery is in my DNA. But I now focus on multiplying value — not just through my own hands, but through the force multipliers around me: open source communities, industry partners, cross-functional allies, and of course, my own team.\nI\u0026rsquo;ve learned how to stay passionate without letting attachment take over. I give everything I have to the work, but I no longer let my sense of worth ride on its outcome. I love my projects — deeply — but just like my kids, I want them to grow up and live their own lives.\nI lean heavily on my support network — not just my peers and teammates, but also the leadership around me: directors, VPs, people I\u0026rsquo;ve built trust with over years. Those relationships are more than just strategic — they\u0026rsquo;re how I stay grounded and feel supported.\nAnd yes, I still work hard. Too hard, by some standards. Maybe still unsustainably at times. But this is who I am. I\u0026rsquo;ve learned to shape my life around that intensity, to make it sustainable — because this isn\u0026rsquo;t a sprint — it\u0026rsquo;s a marathon.\nTo all the engineers and leaders out there: your path matters. Leadership can be isolating — that\u0026rsquo;s just part of the deal sometimes. But it\u0026rsquo;s worth trying to stay connected. Keep building bridges. Lean on your people. Ask for help when you need it. And above all, keep perspective.\nStay sharp. Stay human.\n","permalink":"https://moidx.com/posts/burnout/","summary":"\u003cp\u003eI\u0026rsquo;ve been in this game for almost two decades — from debugging pre-silicon\nfirmware with an oscilloscope in hand, to leading 40+ engineers across\norganizations to deliver production silicon. I\u0026rsquo;ve shipped chips, built secure\nboot flows, led zero-to-one projects, and steered open-source hardware like\nOpenTitan into Google\u0026rsquo;s data center infrastructure.\u003c/p\u003e\n\u003cp\u003eBut if I\u0026rsquo;m being honest, leadership can feel like a climb to a ledge — and\nsome days, it feels like the only way down is to jump.\u003c/p\u003e","title":"The Cost of Climbing the Ledge: Leadership, Engineering, and Burnout"},{"content":"I\u0026rsquo;m a Staff Software Engineer at Google and a longtime builder of secure, reliable, and scalable systems.\nOver the years, I’ve led projects across the full stack of root-of-trust hardware, from early architecture and security design to production silicon and deployment at scale. These days, I’m leading OpenTitan at Google — working across hardware and software to support security and provisioning for ChromeOS, data centers, and more.\nOutside of work, I write about engineering, leadership, and the lessons I’ve learned from building real systems with real constraints.\n📝 You can check out my blog here or find me on GitHub and LinkedIn.\n","permalink":"https://moidx.com/about/","summary":"\u003cp\u003eI\u0026rsquo;m a Staff Software Engineer at Google and a longtime builder of\nsecure, reliable, and scalable systems.\u003c/p\u003e\n\u003cp\u003eOver the years, I’ve led projects across the full stack of root-of-trust hardware,\nfrom early architecture and security design to production silicon and deployment\nat scale. These days, I’m leading OpenTitan at Google — working across hardware and\nsoftware to support security and provisioning for ChromeOS, data centers, and more.\u003c/p\u003e\n\u003cp\u003eOutside of work, I write about engineering, leadership, and the lessons I’ve\nlearned from building real systems with real constraints.\u003c/p\u003e","title":"Hi, I'm Miguel O"},{"content":"I write about engineering, leadership, and building secure, scalable systems — and the personal lessons along the way.\nIf that sounds interesting, drop your email below and get new posts straight to your inbox.\n","permalink":"https://moidx.com/subscribe/","summary":"\u003cp\u003eI write about engineering, leadership, and building secure, scalable systems —\nand the personal lessons along the way.\u003c/p\u003e\n\u003cp\u003eIf that sounds interesting, drop your email below and get new posts straight\nto your inbox.\u003c/p\u003e\n\u003c!-- ConvertKit Embed --\u003e\n\u003cdiv style=\"margin-top: 2rem;\"\u003e\n  \u003cscript async data-uid=\"ed8fa3b739\" src=\"https://moidx.kit.com/ed8fa3b739/index.js\"\u003e\u003c/script\u003e\n\u003c/div\u003e","title":"Stay in the Loop"}]