fa8325c2ed
gate out modals entirely from gen2 pddb passwords in gen2 are now entirely handled outside of the respective service crates, cleaning up the APIs some history - on gen1 (precursor) devices, the thesis was to reduce the amount of distance a password has to travel from the point of a user entering it to the point of use. I think this is academically interesting, but it pulls in a lot of code into each service to manage the passwords, conflating services with UI layers. it was a nice experiment. in gen2 (and hopefully beyond) targets, we now commit to the idea that something else is passing in the sensitive key materials. This means that, in fact, keying material has to transition between process spaces, which increases the attack surface to recover this. However, it also makes the crates more portable and maintainable. This is mitigated partially by the fact that in gen2 targets the entirety of the code base runs within a piece of silicon, so "sniffing" (passive observation of data going to memory) attacks are a good bit harder. |
||
|---|---|---|
| .cargo | ||
| .github/workflows | ||
| .vscode | ||
| api | ||
| apps | ||
| apps-dabao | ||
| bao1x-boot | ||
| baremetal | ||
| devkey | ||
| docs | ||
| emulation | ||
| imports | ||
| kernel | ||
| libs | ||
| LICENSES | ||
| loader | ||
| locales | ||
| planning | ||
| precursors | ||
| services | ||
| signing | ||
| svd2repl | ||
| svd2utra | ||
| tools | ||
| tools-bao | ||
| utralib | ||
| xous-ipc | ||
| xous-rs | ||
| xtask | ||
| .gitattributes | ||
| .gitignore | ||
| analyze-bloat.sh | ||
| API.md | ||
| baosign.ps1 | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| FORMATTING.md | ||
| LICENSE | ||
| publish.py | ||
| README-baochip.md | ||
| README-precursor.md | ||
| README.md | ||
| RELEASE-v0.8.md | ||
| RELEASE-v0.9.md | ||
| rustfmt.toml | ||
Xous Core
Core files for the Xous microkernel operating system.
The Xous Book covers the architecture and structure of the kernel.
The wiki is a community resource that answers many FAQ.
The Boachip README is the starting point for Baochip users.
The Precursor README is the starting point for Precursor users.
Xous is a mono-repo project. It contains the kernel, libraries, applications, and tools necessary to build full device images. Here is a brief description of the more important directories:
- api: "Secular" API libraries - minimal-dependency, common-core APIs used by core Xous services
- apps: Precursor applications
- apps-dabao: Dabao applications
- apps-baosec: Baosec applications
- bao1x-boot: Bao1x secure boot chain
- baremetal: Baremetal target - runs after the boot chain, for developers that don't want Xous but can still use Xous'
no-stdfeatures - emulation: Renode scripts used to emulate Xous
- imports: Vendored-in libraries that had to be forked for Xous compatibility
- kernel: core memory manager, irq manager, and syscall implementations.
- libs: Device driver libraries. The common thread is that none of these code bases contain a
main.rs, just alib.rs. - loader: Sets up virtual memory space and boots the kernel
- locales: Tools for handling internationalization
- signing: Scripts for generating signed images
- services: Xous programs that support Xous apps. Middleware, if you will.
- svd2utra: A program for converting SVD chip descriptions in XML to the UTRA "header file" format
- tools: Programs used to construct a final boot image. Also the home of various diagnostic and test utilities.
- utralib: The Unambigous Thin Register Abtraction. The core hardware interface for Xous.
- xous-ipc: Inter-process communication convenience APIs for Xous
- xous-rs: API files for the kernel. Where the syscall interfaces live.
- xtask: The build system manager for Xous.
Dependencies
Install the latest Rust or run rustup update to update your Rust installation prior to building. Xous development assumes a recent version of Rust.
Build Commands
- Precursor:
cargo xtask app-image - Dabao:
cargo xtask dabao - Baosec:
cargo xtask baosec - Baochip baremetal:
cargo xtask baremetal-bao1x
Additional apps to be bundled into images can be specified as extra arguments on the command line, e.g. cargo xtask dabao helloworld will generate a Dabao image that includes helloworld in the detached-app section. Features, app-features, loader-features, and so forth can also be passed as command line arguments; run cargo xtask on its own for more help.
Emulation
cargo xtask runwill bring up an emulated Precursorcargo xtask baosec-emuwill bring up an emulated Baoseccargo xtask renode-imagewill build an image suitable for Renode emulation of a Precursor target. Start renode by runningrenode emulation/xous-release.resc
Building Documentation
A flag of --feature doc-deps must be passed when running cargo doc, like this:
cargo doc --no-deps --feature doc-deps
doc-deps is a dummy hardware target that satisfies the requirement of
a "board" when building documentation.
Local-vs-crates.io Verification
xtask does a check every build to ensure that any crates.io dependencies
are synchronized with the contents of the monorepo. It protects against the
scenario where you edited a crate that exists in the Xous repo, but the
build system ignores the local edits because it's fetching an old version from
crates.io.
Developers working on published crates should patch them in the root Cargo.toml
file and bypass the check with --no-verify.
Acknowledgement
This project is funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 825310.
 |
 |