Rust Search
Find the best content on Rust, curated by the community; a
search engine for Rustaceans.
Rust provides unsafe language features to interact with hardware or call into non-Rust libraries. However, this shifts responsibility for ensuring memory safety to the developer. Failing to do so may lead to memory-safety violations in unsafe code, which can violate the safety of the entire application. In this talk, we explore in-process isolation with Memory Protection Keys as a mechanism to shield safe program sections from safety violations that may happen in unsafe sections. Our approach is easy to use and comprehensive, as it prevents heap and stack-based violations. We further compare process-based and in-process isolation mechanisms and the necessary requirements for data serialization, communication, and context switching. We specifically explored various Rust serialization crates such as Abomonation and bincode. Our results show that in-process isolation can be effective and efficient, permits for a high degree of automation, and also enables a notion of application rewinding where the safe program section may detect and safely handle violations in unsafe code. However, even for modestly sized arguments, the context switch cost starts to get dominated by the cost of data transfer between domains. Here, the Rust data serialization method used can significantly impact performance and thus, it is crucial to optimize it for the use case at hand. We open-source our prototype and experimental evaluation data under a BSD license on GitHub: https://secure-rewind-and-discard.github.io/
Software engineers choose Rust for its safety and performance baseline. Wizards use Rust's dark arts to improve performance by chanting cursed unsafe-yet-sound expressions. Whether you’re an engineer or a wizard, this talk will give you the tools and best practices to correctly measure and explore Rust’s performance claims against your projects. And wizards will learn when the performance benefits are worth risking nasal demons with unsafe code.
This talk presents a case study in taking a security-focused application to the next level by modifying the Rust compiler to target a capability-based architecture. We will discuss CHERI, a system that enables hardware enforcement of safety constraints at runtime using capabilities, and how we have added support for CHERI to the Rust compiler in order to improve the security of CyberHive Connect, an application that implements an end-to-end encrypted mesh network. Connect can already boast a very high level of security when we consider the protocols it uses, and we can argue that the application itself has many potential vulnerabilities eliminated by being written in Rust. However, just like most real world applications, Connect needs to make use of unsafe code in areas such as the interface with the underlying operating system. This exposes an attack surface in the form of code that the compiler can't guarantee will be safe at runtime. If, however, we make modifications to the Rust compiler to support transferring knowledge about pointer provenance, bounds and other access restrictions to CHERI's capability-based runtime enforcement, then in many cases we should be able to eliminate the potential for unsafe situations to occur. This talk will demonstrate what we have managed to achieve in terms of producing a modified Rust compiler that can target CHERI architectures. We will give an overview of what problems were solved by doing this and how we worked towards getting our real world Rust application running on CHERI.
gccrs is an alternative implementation of a Rust compiler currently being developed. It aims to become a fully fledged Rust compiler, and hopes to share as much code as possible with the official Rust compiler in order to guarantee correctness and avoid damage on the Rust ecosystem. But how do we plan to integrate Rust components to the GCC codebase, and what sort of components will we reuse? This talk will explore the future of the project, as well as some of the challenges surrounding compilers, and the very silly sounding but real problems of bootstrapping and dogfooding. We will explore the stack of rustc crates that we leverage, how we use them together, and how they will play a part once the compiler has advanced further.
This talk will show you how to write your own rust linter using the rustc_tools crate which allows you to have access to the rust compiler API. It can be quite useful if you need specific lints for a project and cannot add them to clippy. It will explain how the compiler API works and give a small example at the end showing it in action.
In theory, semantic versioning (SemVer) is simple: breaking changes require major versions. SemVer rules do not change over time. Crates always adhere to SemVer. Careful coding is enough to avoid accidental breaking changes. None of those statements are true! In practice, SemVer is complex and accidental breakage is common: 1 in 6 of the top 1000 Rust crates has violated semantic versioning at least once, frustrating both users and maintainers alike. If you write Rust but don't have the time for a PhD in SemVer, this talk is for you. We'll take a practical look at SemVer in Rust: what it buys us, how Rust's features lead to strange SemVer edge cases, and how we can prevent accidental breakage using a SemVer linter called cargo-semver-checks.
Atuin aims to make your experience with your shell history delightful. It stores every command and the context around it (eg, directory it ran in, duration, etc) in a SQLite database, and then provides fuzzy search on top of that. Along with the Atuin sync server, this history can be made available on every machine the user has. I'll be walking the audience through how the project works, what problems it solves, as well as how it was implemented. I will assume the audience has some working familiarity with the shell, but the talk will be friendly for Rust beginners or anyone curious about the language.
Application developers working and testing with a specific kernel version should be able to easily control their application compatibility behavior with previous (and future) kernel versions as well. We developed a Landlock library (for security sandboxing purpose) that protects users as much as possible while making the work of application developers easier and safer. This talk gives feedback about the development of a security library that needs to deal with backward and forward compatibility, because of security features tied to specific kernel versions, handling different use cases in a safe and secure way. We explain patterns that we used to make it possible to fine tune the requested (optional) features while providing a safe default behavior. For simple use cases, the idea is to provide a best-effort security approach for potentially unsupported kernel features: use available features and ignore others. However, in more complex use cases, we may want to make some features depend on others. We may also want to handle errors differently based on unsupported features.
When creating a script or a tool to manage your network configuration it is hard to decide which language should you use. In Nmstate we noticed we could get plenty of benefits from Rust. Nmstate is a library with an accompanying command line tool that manages host networking settings in a declarative manner written in Rust. In this talk, we are going to see how we combined several existing libraries and also created our own ones to create a powerful networking tool. In addition, we will share our lessons learned from rewriting a project from Python to Rust. Of course, the talk will be full of crabs, so don't miss it!
Graphs are used in many different applications as they are an intuitive way for representing complex relationships between entities, as for example in social, communication, financial or geographical networks. Graphs in these domains can be very large, potentially spanning multiple millions and even billions of nodes and edges. In order to get analytical insights out of these structures, scalable implementations of graph algorithms are necessary. Rust is the ideal language for implementing such algorithms, due to its well-known aspects, such as "fearless concurrency" and memory safety as well as its great out-of-the-box performance and its expressive type system. In our presentation, we will talk about the "graph" project, a collection of open source crates that we are working on. The project includes an in-memory graph representation, APIs for building in-memory graphs from various data sources, and a small collection of high-performance graph algorithms. In addition to these building blocks, we started developing a Python wrapper called graph-mate for a NetworkX-like experience and an Apache Arrow endpoint for integrating the project in distributed applications. The presentation will include a project overview, a walk through the Rust API, and a demo for using the project via Python.
Pydantic is a data validation library for Python that has seen massive adoption over the last few years - it is estimated that Pydantic is now used by about 10% of professional web developers! Over the last year I've been working full time to rebuild Pydantic from the ground up, using Rust for virtually all the validation and serialization logic. Pydantic V2, with these changes included, will be released early in 2023. In this talk I will give a brief introduction to Pydantic V2 before diving into how the use of Rust has allowed us to completely change the architecture of Pydantic to make it easier to extend and maintain while also improving performance significantly. The majority of the talk will be devoted to using examples from the pydantic V2 code base (rust and python) to demonstrate the advantages (and disadvantages) of writing libraries like Pydantic in Rust. This talk should be interesting to any Rust or Python developer who's interested in combining the two languages - no knowledge of Python or Pydantic is required. However if you'd like to get some context or learn more about the topics discussed, here are some useful resources: Pydantic V2 Plan - blog post about the plan for Pydantic V2 pydantic-core - the python package that provides Rust logic in pydantic PyO3 docs - the amazing library that allows Rust to be embedded in Python Build your Python Extensions with Rust! by Paul Ganssle - good intro to building Python extensions in Rust
Sorting is one of the most common algorithms used in programming, and virtually every standard library contains a routine for it. Despite also being one of the oldest problems out there, surprisingly large improvements are still being found. Some of these are fundamental novelties, and others are optimizations matching the changing performance landscape in modern hardware. In this talk we present Glidesort, a general purpose in-memory stable comparison sort. It is fully adaptive to both pre-sorted runs in the data similar to Timsort, and low-cardinality inputs similar to Pattern-defeating Quicksort, making it to our knowledge the first practical stable sorting algorithm fully adaptive in both measures. Glidesort achieves a 3x speedup over a Rust’s standard library Timsort routine on sorting random 32-bit integers, with the speedup breaking the order of magnitude barrier for realistic low-cardinality distributions. It achieves this without the use of SIMD, processor-specific intrinsics or assumptions about the type being sorted: it is a fully generic sort taking an arbitrary comparison operator.
Game developing is hard: models, concurrency, physics and so on are difficult without any helps from the framework. In this talk we introduce Bevy Engine library that allows us to create simple games in a smart way. With the merely excuse to build a Snake Game, in this talk we create Snake Game compiling it as native application and webapp (wasm) application.
This talk will shortly present how a patch gets merged for the rust compiler and how the whole process happens and what happens after it was merged.
Started in 2014, the gccrs project is working toward creating an alternative compiler implementation for the Rust programming language. At the moment, the project targets the 1.49 version of the language and hopes to catch up once that milestone is reached. In that talk, we will explore some of the components inside gccrs, as well as dive into some of the hurdles encountered during the project's lifetime. Finally, we will explore ways to cross-pollinate with the Rust community, in order to help and benefit both projects. Specifically, we will dive into some ways we plan to share components with rustc, and how to achieve that: namely, we will look at how we plan on integrating the Polonius project to perform borrow-checking inside gccrs, what our efforts with running the rustc 1.49 testsuite are, and what we need to achieve to start being useful to the Rust- for-Linux project.
In this talk I'm going over some lessons learned from building internal APIs in Rust as well as some public APIs such as the Redis rust crate, the insta snapshot testing library, the MiniJinja template engine and more. It covers lessons learned from making mistakes, more crafty abstractions with generics and more of building libraries in Rust for 10 years.
Slint is an Open Source GUI toolkit for Desktop and Embedded. It is written in Rust, and comes with a declarative UI description language that compiles into native Rust code. We will present Slint and show how you can build an reactive GUI in Rust
CHERI defines hardware extensions to encode access constraints on pointers, enabling hardware enforcement of such restructions based on metadata stored alongside pointers. There is an ongoing drive to support compiling Rust code in a way that can make use of these extensions. Doing this provides another layer of protection. We can encode knowledge about provenance validity, bounds and other access restrictions that the compiler (and OS/etc.) knows about in a way the hardware can enforce at runtime. The Rust memory model is famous for being able to enforce these types of restrictions at compile time, but not for unsafe Rust code. Unsafe Rust code needs to be written sometimes, which presents situations which can only be verified at run time. Some other nice benefits could come from this work. For example, runtime bounds checking can now be done by hardware rather than software, and since provenance information is necessary for operations on capabilities, closing gaps where it is not currently preserved forms a part of this work. This talk is a discussion on what is required for this support, and gives an overview of the state of the various attempts to implement this support.
In programming we use editors and IDEs all the time. Previously if one use Vi/Vim like text editor it typically means you just edit soruce code as simple text, but nowadays things have been changed. Especially after releasing support of the Language Server Protocol(LSP), which works as a client to LSP servers for example rust-analyzer. This talk gives deep dive of Language server Protocol implementation for Rust and how to build friendly relationships between rust-analyzer and Neovim. In this talk i’ll start from brief of what’s LSP and rust-analayzer, some missing features you probably didn’t know about? E.g. go-to-definition, find-references, hover, completion, rename, format, refactor, etc., using semantic whole-project analysis. Also i’ll show you how to write you first plugin using Rust and interact with some LSP primitives. to turn you editor in God mode surf trough it like a pro.
We present BastionLab, a Rust open-source privacy framework for confidential data science collaboration. We aim to help data owners open access to their datasets to outside data scientists. The current approaches, such as opening Jupyter notebooks, provide no elaborate control over what is shared. Datasets can easily be extracted from them, which means they offer little privacy guarantees and make data collaboration difficult. BastionLab provides an interactive interface for data scientists to explore remote datasets, yet answers the privacy concerns of data owners, as only results compliant with the privacy policy defined by the data owners can be communicated. Data exposure is limited as data scientists never have direct access to the data, they can only use a limited set of operators which preclude arbitrary code execution to exfiltrate data, and a strict access control policy is put in place. Differential Privacy and Trusted Execution Environments are supported as well to ensure maximum privacy. We will provide an example to show how a COVID dataset could be shared to a remote data scientist to perform data exploration, cleaning and visualization, while making sure only anonymized results are communicated. The server side of BastionLab is developed in Rust for its memory safety, performance and community. It allows the use of cutting-edge libraries like polars, an open source DataFrame library in Rust several times faster than pandas, the go-to solution in Python.
"Edition!"