Archive for the ‘en-US’ Category

Stephen Sims, a veteran cybersecurity expert, navigates the evolving landscape of binary exploitation, a discipline long revered as the pinnacle of hacking challenges. His presentation at DEF CON 32 examines the impact of modern mitigations like Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), and newer technologies such as Control-flow Enforcement Technology (CET). Stephen explores how these defenses have reshaped the field, while emphasizing that the pursuit of novel exploitation techniques remains vibrant despite increasing complexities.

The Golden Era of Binary Exploitation

Stephen begins by reflecting on the historical significance of binary exploitation, where vulnerabilities in low-level languages like C++ enabled attackers to manipulate system memory. In the early 2000s, exploiting large applications was a hallmark of hacking prowess. However, Stephen notes that memory safety issues have prompted a shift toward safer languages like Rust, though these are not yet mature enough to fully replace C++. This transition has made exploitation more challenging but not obsolete.

Impact of Modern Mitigations

Delving into technical details, Stephen dissects key mitigations like DEP, which prevents code execution in data memory, and ASLR, which randomizes memory addresses. He also discusses CET, which enforces control-flow integrity, and Virtualization-Based Security (VBS), which isolates critical processes. These protections, often disabled by default on Windows to avoid breaking applications, have significantly raised the bar for attackers. Stephen illustrates their enforcement through practical examples, showing how they thwart traditional exploits.

Ethical and Legislative Challenges

Stephen addresses the ethical dilemmas facing researchers, noting that restrictive legislation, such as the Paul Maul Act, could push exploit development underground. He argues that the more researchers are constrained, the greater the risk of unethical markets flourishing. By sharing insights from past research, including contributions from Jeremy Tinder and Haroon Mir, Stephen underscores the need for responsible disclosure to balance innovation with security.

The Future of Exploitation

Concluding, Stephen likens modern exploit development to skateboarding legend Tony Hawk, where past techniques are now accessible to newcomers, enabling rapid advancement. He predicts that as bounties for zero-day exploits rise—some now fetching $500,000—the incentive to bypass mitigations will persist. Stephen encourages researchers to innovate ethically, leveraging open knowledge to uncover new vulnerabilities while navigating an increasingly fortified digital landscape.

Links:

• Stephen Sims on LinkedIn
• SANS Institute website

If you’re working with Elastic APM in a Java application, you might wonder when to use `@CaptureSpan` versus `@CaptureTransaction`. Both are powerful tools for observability, but they serve different purposes.
🔹 `@CaptureTransaction`:
Use this at the entry point of a request, typically at a controller, service method, or a background job. It defines the start of a transaction and allows you to trace how a request propagates through your system.
🔹 `@CaptureSpan`:
Use this to track sub-operations within a transaction, such as database queries, HTTP calls, or specific business logic. It helps break down execution time and pinpoint performance bottlenecks inside a transaction.

📌 Best Practices:

✅ Apply @CaptureTransaction at the highest-level method handling a request.
✅ Use @CaptureSpan for key internal operations you want to monitor.
✅ Avoid excessive spans—instrument only critical code paths to reduce overhead.

By balancing these annotations effectively, you can get detailed insights into your app’s performance while keeping APM overhead minimal.

While Python dominates in model training, Java is becoming increasingly vital for deploying and serving AI/ML models in production. Its performance, stability, and enterprise integration capabilities make it a strong contender.

Java Example: Real-time Object Detection with DL4J and OpenCV

[java]
import …

public class ObjectDetection {

public static void main(String[] args) {
String modelPath = "yolov3.weights";
String configPath = "yolov3.cfg";
String imagePath = "image.jpg";
Net net = Dnn.readNet(modelPath, configPath);
Mat image = imread(imagePath);
Mat blob = Dnn.blobFromImage(image, 1 / 255.0, new Size(416, 416), new Scalar(0, 0, 0), true, false);

net.setInput(blob);

MatVector detections = net.forward(); // Inference

// Process detections (bounding boxes, classes, confidence)
// … (complex logic for object detection results)
// Draw bounding boxes on the image
// … (OpenCV drawing functions)
imwrite("detected_objects.jpg", image);
}
}

[/java]

Python Example: Similar Object Detection with OpenCV and YOLO

[python]

import numpy as np

net = cv2.dnn.readNet("yolov3.weights", "yolov3.cfg")
image = cv2.imread("image.jpg")
blob = cv2.dnn.blobFromImage(image, 1/255.0, (416, 416), swapRB=True, crop=False)
net.setInput(blob)
detections = net.forward()

# Process detections (bounding boxes, classes, confidence)
# … (simpler logic, NumPy arrays)
# Draw bounding boxes on the image
# … (OpenCV drawing functions)
cv2.imwrite("detected_objects.jpg", image)
[/python]

Comparison and Insights:

• Syntax and Readability: Python’s syntax is generally more concise and readable for data science and AI tasks. Java, while more verbose, offers strong typing and better performance for production deployments.
• Library Ecosystem: Python’s ecosystem (NumPy, OpenCV, TensorFlow, PyTorch) is more mature and developer-friendly for AI/ML development. Java, with libraries like DL4J, is catching up, but its strength lies in enterprise integration and performance.
• Performance: Java’s performance is often superior to Python’s, especially for real-time inference and high-throughput applications.
• Enterprise Integration: Java’s ability to seamlessly integrate with existing enterprise systems (databases, message queues, APIs) is a significant advantage.
• Deployment: Java’s deployment capabilities are more robust, making it suitable for mission-critical AI applications.

Key Takeaways:

• Python is excellent for rapid prototyping and model training.
• Java excels in deploying and serving AI/ML models in production environments, where performance and reliability are paramount.
• The choice between Java and Python depends on the specific use case and requirements.

Original post

From LinkedIn: https://www.linkedin.com/posts/matthias-patzak_cto-technology-activity-7312449287647375360-ogNg?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAWqBcBNS5uEX9jPi1JPdGxlnWwMBjXwaw

Summary of the question

As CTO for a mainframe rebuild (core banking/insurance/retail app, 100 teams/1000 people with Cobol expertise), considering Java/Kotlin, TypeScript/Node.js, Go, and Python. Key decision criteria are technical maturity/stability, robust community, and innovation/adoption. The CTO finds these criteria sound and seeks a language recommendation.

TL;DR: my response

• Team, mainframe rebuild: Java/Kotlin are frontrunners due to maturity, ecosystem, and team’s Java-adjacent skills. Go has niche potential. TypeScript/Node.js and Python less ideal for core.
• Focus now: deep PoC comparing Java (Spring Boot) vs. Kotlin on our use cases. Evaluate developer productivity, readability, interoperability, performance.
• Develop comprehensive Java/Kotlin training for our 100 Cobol-experienced teams.
• Strategic adoption plan (Java, Kotlin, or hybrid) based on PoC and team input is next.
• This balances proven stability with modern practices on the JVM for our core.

My detailed opinion

As a CTO with experience in these large-scale transformations, my priority remains a solution that balances technical strength with the pragmatic realities of our team’s current expertise and long-term maintainability.

While Go offers compelling performance characteristics, the specific demands of our core business application – be it in banking, insurance, or retail – often prioritize a mature ecosystem, robust enterprise patterns, and a more gradual transition path for our significant team. Given our 100 teams deeply skilled in Cobol, the learning curve and the availability of readily transferable concepts become key considerations.

Therefore, while acknowledging Go’s strengths in certain cloud-native scenarios, I want to emphasize the strategic advantages of the Java/Kotlin ecosystem for our primary language choice, with a deliberate hesitation and deeper exploration between these two JVM-based options.

Re-emphasizing Java and Exploring Kotlin More Deeply:

• Java’s Enduring Strength: Java’s decades of proven stability in building mission-critical enterprise systems cannot be overstated. The JVM’s resilience, the vast array of mature libraries and frameworks (especially Spring Boot), and the well-established architectural patterns provide a solid and predictable foundation. Moreover, the sheer size of the Java developer community ensures a deep pool of talent and readily available support for our teams as they transition. For a core system in a regulated industry, this level of established maturity significantly mitigates risk.

• Kotlin’s Modern Edge and Interoperability: Kotlin presents a compelling evolution on the JVM. Its modern syntax, null safety features, and concise code can lead to increased developer productivity and reduced boilerplate – benefits I’ve witnessed firsthand in JVM-based projects. Crucially, Kotlin’s seamless interoperability with Java is a major strategic advantage. It allows us to:

  • Gradually adopt Kotlin: Teams can start by integrating Kotlin into existing Java codebases, allowing for a phased learning process without a complete overhaul.
  • Leverage the entire Java ecosystem: Kotlin developers can effortlessly use any Java library or framework, giving us access to the vast resources of the Java world.
  • Attract modern talent: Kotlin’s growing popularity can help us attract developers who are excited about working with a modern, yet stable, language on a proven platform.

Why Hesitate Between Java and Kotlin?

The decision of whether to primarily adopt Java or Kotlin (or a strategic mix) requires careful consideration of our team’s specific needs and the long-term vision:

• Learning Curve: While Kotlin is designed to be approachable for Java developers, there is still a learning curve associated with its new syntax and features. We need to assess how quickly our large Cobol-experienced team can become proficient in Kotlin.
• Team Preference and Buy-in: Understanding our developers’ preferences and ensuring buy-in for the chosen language is crucial for successful adoption.
• Long-Term Ecosystem Evolution: While both Java and Kotlin have strong futures on the JVM, we need to consider the long-term trends and the level of investment in each language within the enterprise space.
• Specific Use Cases: Certain parts of our system might benefit more from Kotlin’s conciseness or specific features, while other more established components might initially remain in Java.

Proposed Next Steps (Revised Focus):

1. Targeted Proof of Concept (PoC) – Deep Dive into Java and Kotlin: Instead of a broad PoC including Go, let’s focus our initial efforts on a detailed comparison of Java (using Spring Boot) and Kotlin on representative use cases from our core business application. This PoC should specifically evaluate:
   • Developer Productivity: How quickly can teams with a Java-adjacent mindset (after initial training) develop and maintain code in both languages?
   • Code Readability and Maintainability: How do the resulting codebases compare in terms of clarity and ease of understanding for a large team?
   • Interoperability Scenarios: How seamlessly can Java and Kotlin code coexist and interact within the same project?
   • Performance Benchmarking: While the JVM provides a solid base, are there noticeable performance differences for our specific workloads?
2. Comprehensive Training and Upskilling Program: We need to develop a detailed training program that caters to our team’s Cobol background and provides clear pathways for learning both Java and Kotlin. This program should include hands-on exercises and mentorship opportunities.
3. Strategic Adoption Plan: Based on the PoC results and team feedback, we’ll develop a strategic adoption plan that outlines whether we’ll primarily focus on Java, Kotlin, or a hybrid approach. This plan should consider the long-term maintainability and talent acquisition goals.

While Go remains a valuable technology for specific niches, for the core of our mainframe rebuild, our focus should now be on leveraging the mature and evolving Java/Kotlin ecosystem and strategically determining the optimal path for our large and experienced team. This approach minimizes risk while embracing modern development practices on a proven platform.

Navigating Automotive Safety Standards

The automotive industry’s shift toward software-defined vehicles has intensified the need for robust safety compliance, particularly for software components used in safety-critical applications. At OxidizeConf2024, Amit Dharmapurikar and Gnana Ganesh from Thoughtworks delivered an insightful presentation on qualifying Rust libraries for compliance with ISO 26262, a standard governing functional safety in automotive systems. With Thoughtworks’ expertise in software-defined vehicles, Amit and Gnana provided a comprehensive overview of the processes and tools required to ensure Rust libraries meet stringent safety requirements, focusing on the Rust Core library as a case study.

ISO 26262 mandates rigorous documentation, requirement coverage, and structural code coverage to ensure software reliability in electronic control units (ECUs). Amit emphasized that while the Ferrocene compiler, developed by Ferrous Systems, has already achieved safety compliance, libraries—both standard and third-party—must also be qualified. This involves producing formal specifications, verifying requirements through testing, and generating code coverage reports. The speakers highlighted the collaborative effort with Ferrous Systems to qualify the Rust Core library, underscoring the importance of aligning open-source tools with automotive standards.

Documentation and Requirement Coverage

A cornerstone of ISO 26262 compliance is comprehensive documentation, which serves as a formal specification of software components. Gnana detailed how Thoughtworks approaches this by deriving testable requirements from the Rust Core library’s standard documentation. This process involves translating descriptive text into precise, verifiable requirements, a task that poses challenges due to the library’s frequent updates as an open-source project. To address this, Amit and Gnana proposed developing tools to automate the interpretation of documentation changes, ensuring that requirements remain aligned with the library’s evolution.

Requirement coverage, as mandated by ISO 26262 Part 6, ensures that all functional requirements are tested. The speakers demonstrated a proof-of-concept where requirements for the Rust Core library were linked to test cases, providing traceability essential for audits. This approach leverages open-source tools like Sphinx, which facilitates bidirectional traceability by connecting requirements to code. By integrating these tools into the development pipeline, Thoughtworks ensures that compliance artifacts are generated iteratively, reducing manual effort and enhancing accountability.

Advancing Code Coverage with Rust Tooling

Structural code coverage is another critical aspect of ISO 26262 compliance, requiring developers to measure how thoroughly code is exercised by tests. Amit showcased a demo using the Rust toolchain’s coverage capabilities, specifically the --coverage flag in the test subcommand. This flag, combined with a custom bootstrap command (dotx), embeds profiler builtins into executables, generating profile files that tools like grcov process into coverage reports. The demo illustrated coverage analysis for the Rust Core library, excluding documentation to focus on executable code.

While statement coverage is already supported, Gnana noted that branch coverage is available in draft pull requests, and Modified Condition/Decision Coverage (MCDC) is in progress within the Rust community. These advancements, driven by initiatives like Ferrocene, demonstrate Rust’s growing maturity for safety-critical applications. The speakers acknowledged challenges, such as managing frequent library updates, but emphasized the potential of automated tools to streamline compliance, making Rust a viable choice for automotive software development.

Links:

• Thoughtworks company website
• Ferrous Systems company website

Amid the AI deluge reshaping codecraft, a tantalizing prospect emerges: harnessing neural nets natively in JavaScript, sidestepping Python’s quagmires or API tolls. Wes Bos, a prolific Canadian educator whose Syntax.fm podcast and courses have schooled half a million in JS mastery, probed this frontier at dotJS 2025. Renowned for demystifying ES6 and React, Wes extolled browser-bound inference via Transformers.js, weighing its virtues—privacy’s fortress, latency’s lightning—against hardware’s hurdles, affirming JS’s prowess for sundry smart apps.

Wes’s overture skewered the status quo: cloud fetches or Python purgatory, both anathema to JS purists. His heresy: embed LLMs client-side, ONNX Runtime fueling Hugging Face’s arsenal—sentiment sifters, translation tomes, even Stable Diffusion’s slimmer kin. Transformers.js’s pipeline paradigm gleams: import, instantiate (pipeline('sentiment-analysis')), infer (result = await pipe(input)). Wes demoed a local scribe: prompt yields prose, all sans servers, WebGPU accelerating where GPUs oblige. Onyx.js, his bespoke wrapper, streamlines: model loads, GPU probes, inferences ignite—be it code completion or image captioning.

Trade-offs tempered triumph. Footprints fluctuate: 2MB wisps to 2GB behemoths, browser quotas (Safari’s 2GB cap) constraining colossi. Compute cedes to client: beefy rigs revel, mobiles murmur—Wes likened Roblox’s drain to LLM’s voracity. Yet, upsides dazzle: zero egress fees, data’s domicile (GDPR’s grace), offline oases. 2025’s tide—Chrome’s stable WebNN, Firefox’s flag—heralds ubiquity, Wes forecasting six-month Safari stability. His verdict: JS, with its ubiquity and ecosystem, carves niches where immediacy reigns—chatbots, AR filters—not every oracle, but myriad muses.

Wes’s zeal stemmed personal: from receipt printers to microcontroller React, JS’s whimsy fuels folly. Transformers.js empowers prototypes unbound—anime avatars, code clairvoyants—inviting creators to conjure without concessions.

Client-Side Sorcery Unveiled

Wes unpacked pipelines: sentiment sorters, summarizers—Hugging Face’s trove, ONNX-optimized. Onyx’s facade: await onnx.loadModel('gpt2'), GPU fallback, inferences instantaneous. WebGPU’s dawn (Chrome 2025 stable) unlocks acceleration, privacy paramount—no telemetry trails.

Balancing Bytes and Burdens

Models’ mass mandates moderation: slim variants suffice for mobile, diffusion downsized. Battery’s bite, CPU’s churn—Wes warned of Roblox parallels—yet offline allure and cost calculus compel. JS’s sinew: ecosystem’s expanse, browser’s bastion, birthing bespoke brains.

Links:

• Wes Bos on LinkedIn
• Wes Bos Courses

Thomas Roth, known as Stacksmashing, a hardware security researcher and co-founder of HexHive, takes the audience on a technical odyssey to compromise Apple’s proprietary ACE3 USB-C controller in the iPhone 15. Using reverse-engineering, RF side-channel analysis, and electromagnetic fault injection, Thomas achieves code execution on this custom chip, unlocking JTAG access and exposing its inner workings. His work highlights the persistence required to tackle secure hardware.

Cracking the ACE3 Controller

Thomas introduces the ACE3, a microcontroller managing USB-C functions, internal buses, and JTAG on the iPhone 15. Unlike its predecessor, ACE2, which was vulnerable to software exploits, ACE3 employs personalized firmware and disabled debug interfaces. Through meticulous reverse-engineering, Thomas mapped its architecture, revealing access to UART and SPMI buses, critical for deeper device exploration.

Leveraging Side-Channel Attacks

To bypass Apple’s protections, Thomas employed RF side-channel analysis and electromagnetic fault injection. Using tools like ChipShouter, he induced faults to read and write arbitrary memory, dumping the ACE3’s ROM and RAM. This painstaking process, despite battery challenges, yielded a complete firmware dump, enabling further analysis of the chip’s security mechanisms.

Democratizing Hardware Hacking

Recognizing the high cost of professional tools, Thomas ported his attack to the affordable PQM-P1, reducing the cost to $60. This democratization of fault injection empowers researchers to explore similar chips without prohibitive expenses. His open-source firmware for ChipShouter automates the process, making hardware security research more accessible to the community.

Future of Hardware Security Research

Thomas concludes by encouraging researchers to persist in analyzing unknown silicon, as demonstrated by his success with minimal prior knowledge. His glitching lab at the MedSec Systems Village invites hands-on exploration of fault injection techniques. By sharing his tools and methodologies, Thomas fosters a collaborative approach to uncovering vulnerabilities in secure hardware.

Links:

• Thomas Roth on LinkedIn
• HexHive website
• Stacksmashing on YouTube

Managing database migrations can be tricky, but Flyway simplifies the process with versioned scripts for schema changes, data updates, and rollbacks.
Here’s a quick guide with useful examples:

✅ 1️⃣ Creating a Table (V1 – Initial migration)
“`
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username VARCHAR(50)…,
email VARCHAR(100)…,
created_at TIMESTAMP…
);
“`
✅ 2️⃣ Inserting Sample Data (V2)
“`
INSERT INTO users (username, email) VALUES
(‘alice’, ‘alice@example.com‘),
(‘bob’, ‘bob@…’);
“`

✅ 3️⃣ Adding a New Column (V3 – Schema change)
“`
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
“`

✅ 4️⃣ Renaming a Column (V4)
“`
ALTER TABLE users RENAME COLUMN email TO contact;
“`

♻ Undo Script (U4__Rename_email_to_contact.sql)
“`
ALTER TABLE users RENAME COLUMN contact TO email;
“`

✅ 5️⃣ Deleting a Column (V5)
“`
ALTER TABLE users DROP COLUMN last_login;
“`

♻ Undo Script (U5__Revert_remove_last_login.sql)
“`
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
“`

✅ 6️⃣ Deleting Specific Data (V6)
“`
DELETE FROM users WHERE username = ‘alice’;
“`

♻ Undo Script (U6__Revert_delete_user.sql)
“`
INSERT INTO users (username, contact) VALUES (‘alice’, ‘alice@example.com‘);
“`

💡 Configuring Flyway in pom.xml
To integrate Flyway into your Spring Boot or Java project, add the following configuration in your `pom.xml`:
“`
<properties>
<flyway.version>11.4.1</flyway.version>
</properties>

<dependencies>
<!– Flyway Core –>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>${flyway.version}</version>
</dependency>

<!– Database Driver (Example: PostgreSQL) –>
<dependency>
“org.postgresql:postgresql:runtime”
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>${flyway.version}</version>
<configuration>
<url>jdbc:postgresql://localhost:5432/mydb</url>
<user>myuser</user>
<password>mypassword</password>
<schemas>public</schemas>
<locations>filesystem:src/main/resources/db/migration</locations>
</configuration>
</plugin>
</plugins>
</build>
“`

📂 Migration scripts should be placed in:
`src/main/resources/db/migration/`
Example:
“`
V1__Create_users_table.sql
V2__Insert_sample_data.sql
V3__Add_last_login_column.sql
“`

💡 Flyway Maven Plugin Commands
👉Apply migrations:
“`mvn flyway:migrate“`
👉Undo the last migration (if `flyway.licenseKey` is provided):
“`mvn flyway:undo“`
👉Check migration status:
“`mvn flyway:info“`
👉Repair migration history:
“`mvn flyway:repair“`
Clean database (⚠Deletes all tables!):
“`mvn flyway:clean“`

Spring AOP (Aspect-Oriented Programming) and Struts 2 might seem like an unusual pairing, but when configured correctly, they can bring cleaner, more modular, and reusable code to your Struts-based applications.

The Challenge:

• Struts 2 manages its own action instances for each request, while Spring’s AOP relies on proxying beans managed by the Spring container. This means Struts actions are not Spring beans by default, making AOP trickier to apply.
• The Solution: Making Struts 2 Actions Spring-Managed
• To make Spring AOP work with Struts 2, follow these steps:

✅ Step 1: Enable Spring integration with Struts 2

Ensure your `struts.xml` is configured to use Spring:

“`<constant name=”struts.objectFactory” value=”spring”/>“`

This makes Struts retrieve action instances from the Spring context instead of creating them directly.

✅ Step 2: Define Actions as Spring Beans

In your applicationContext.xml or equivalent Spring configuration, define your Struts actions:

“`
<bean id=”myAction” class=”com.example.MyStrutsAction” scope=”prototype”/>
“`
Setting the scope to “prototype” ensures a new instance per request, preserving Struts 2 behavior.

✅ Step 3: Apply AOP with `@Aspect`

Now, you can apply Spring AOP to your Struts actions just like any other Spring-managed bean:

“`
@Aspect
@Component
public class LoggingAspect {

@Before(“execution(* com.example.MyStrutsAction.execute(..))”)
public void logBefore(JoinPoint joinPoint) {
System.out.println(“Executing: ” + joinPoint.getSignature().toShortString());
}
}
“`

This will log method executions before any `execute()` method in your actions runs!

Key Benefits of This Approach
🔹 Separation of Concerns – Keep logging, security, and transaction management outside your action classes.
🔹 Reusability – Apply cross-cutting concerns like security or caching without modifying Struts actions.
🔹 Spring’s Full Power – Leverage dependency injection and other Spring features within your Struts 2 actions.
🔥 By integrating Spring AOP with Struts 2, you get the best of both worlds: Struts’ flexible request handling and Spring’s powerful aspect-oriented capabilities. Ready to make your legacy Struts 2 app cleaner and more maintainable? Let’s discuss!

Building a Cohesive Cloud Computer

Oxide Computer Company is redefining server hardware by designing a cohesive system from the ground up, leveraging Rust’s capabilities across its stack. Steve Klabnik, a prominent figure in the Rust community, delivered an insightful talk at OxidizeConf2024, detailing how Rust enables Oxide’s ambitious vision. From firmware to the host operating system and HTTP API backend, Steve highlighted Rust’s role in creating a robust, open-source server platform that contrasts with traditional fragmented server designs.

Oxide’s “cloud computer” integrates hardware and software, offering customers a rack-scale solution managed via an EC2-like API. Steve, drawing from his experience at Sun and Apple, emphasized the company’s commitment to open-source principles, making nearly all code publicly available. This approach not only fosters transparency but also allows the community to benefit from Oxide’s innovations, such as custom service processors that replace traditional baseboard management controllers (BMCs).

Rust in Low-Level Systems

Rust’s suitability for low-level tasks like firmware and operating systems is a cornerstone of Oxide’s strategy. Steve explained how Rust’s memory safety and type system prevent common errors in safety-critical components, such as the root of trust and service processor firmware. Unlike traditional C-based firmware, Rust’s borrow checker ensures robust code, reducing debugging time. This was evident in Oxide’s development board, which uses an ARM chip and custom firmware written in Rust, showcasing the language’s ability to handle complex initialization without relying on standard libraries.

However, Steve acknowledged challenges, such as the difficulty of system bring-up, where hardware-specific issues like bit-banging persist regardless of the programming language. Rust mitigates some risks by preventing accidental errors, but developers must still navigate low-level complexities. Oxide’s approach, combining Rust’s safety with rigorous testing, ensures that firmware and operating system components meet the high reliability standards required for server environments.

Enhancing Productivity and Security

A significant advantage of Rust, as Steve articulated, is its impact on developer productivity. Contrary to perceptions of slow iteration due to the borrow checker, experienced Rust developers find it accelerates development by catching errors early. Steve contrasted this with languages like Ruby, where initial coding is fast but debugging consumes significant time. Rust’s holistic cost of ownership—factoring in maintenance and debugging—makes it highly productive, a point often underappreciated by newcomers.

Security is another critical focus, particularly for Oxide’s government and enterprise clients. Steve discussed measures like running Cargo audit to mitigate supply chain attacks, ensuring that the firmware executed matches the intended code. While not foolproof, these practices, combined with Rust’s safety guarantees, provide a robust foundation for secure systems. As Oxide targets regulated industries, Steve anticipates further enhancements to address stringent security requirements.

Community and Future Directions

Oxide’s commitment to open-source extends beyond code to community engagement. Steve highlighted customers like Shopify and a U.S. Department of Energy lab, reflecting diverse use cases from tech companies to privacy-focused organizations. By sharing code and collaborating on platforms like GitHub, Oxide fosters innovation and reduces development costs for non-differentiating components, such as math libraries. This aligns with industry trends toward collaborative open-source solutions, similar to the adoption of Kubernetes in the 2000s.

Looking forward, Steve envisions Rust playing a larger role in server development, particularly as organizations prioritize data sovereignty and cost efficiency. Oxide’s success in selling to high-profile clients demonstrates Rust’s readiness for production environments, challenging the notion that it’s solely suited for high-level applications. By continuing to refine their processes and share insights, Oxide is poised to shape the future of systems programming with Rust.

Links:

• Oxide Computer Company website
• Oxide Computer Company GitHub