{"id":20140271,"url":"https://github.com/outpost-os/sentry-kernel","last_synced_at":"2026-02-10T22:02:49.154Z","repository":{"id":256593427,"uuid":"835135536","full_name":"outpost-os/sentry-kernel","owner":"outpost-os","description":"Outpost OS sentry kernel sources","archived":false,"fork":false,"pushed_at":"2025-01-27T15:59:58.000Z","size":7123,"stargazers_count":0,"open_issues_count":23,"forks_count":2,"subscribers_count":0,"default_branch":"main","last_synced_at":"2025-08-19T08:45:22.840Z","etag":null,"topics":["kernel","micro-kernel","outpostos"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/outpost-os.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":".github/SECURITY.md","support":"support/arch/asm-cortex-m/meson.build","governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-07-29T08:27:44.000Z","updated_at":"2025-04-29T18:09:39.000Z","dependencies_parsed_at":"2025-01-14T12:24:48.931Z","dependency_job_id":"e19a1a5b-d8bf-4d8c-b21d-bb98ce96bd5a","html_url":"https://github.com/outpost-os/sentry-kernel","commit_stats":null,"previous_names":["outpost-os/sentry-kernel"],"tags_count":6,"template":false,"template_full_name":null,"purl":"pkg:github/outpost-os/sentry-kernel","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/outpost-os%2Fsentry-kernel","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/outpost-os%2Fsentry-kernel/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/outpost-os%2Fsentry-kernel/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/outpost-os%2Fsentry-kernel/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/outpost-os","download_url":"https://codeload.github.com/outpost-os/sentry-kernel/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/outpost-os%2Fsentry-kernel/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29319267,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-10T20:44:44.282Z","status":"ssl_error","status_checked_at":"2026-02-10T20:44:43.393Z","response_time":65,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["kernel","micro-kernel","outpostos"],"created_at":"2024-11-13T21:49:57.622Z","updated_at":"2026-02-10T22:02:49.117Z","avatar_url":"https://github.com/outpost-os.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003c!--\nSPDX-FileCopyrightText: 2023-2024 Ledger SAS\nSPDX-License-Identifier: Apache-2.0\n--\u003e\n\n![sentry logo](https://outpost-sentry.readthedocs.io/en/latest/_images/sentry_kernel.png)\n\n# About\n\n[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/9667/badge)](https://www.bestpractices.dev/projects/9667)\n![GNU/Linux build](https://github.com/outpost-os/sentry-kernel/actions/workflows/gnulinux.yml/badge.svg)\n![MacOS X build](https://github.com/outpost-os/sentry-kernel/actions/workflows/macos.yml/badge.svg)\n![Frama-C RTE Analysis](https://github.com/outpost-os/sentry-kernel/actions/workflows/proof.yml/badge.svg)\n[![Documentation Status](https://readthedocs.org/projects/outpost-sentry/badge/?version=latest)](https://outpost-sentry.readthedocs.io/en/latest/?badge=latest)\n![GitHub Release](https://img.shields.io/github/v/release/outpost-os/sentry-kernel)\n![GitHub License](https://img.shields.io/github/license/outpost-os/sentry-kernel)\n[![REUSE status](https://api.reuse.software/badge/github.com/outpost-os/sentry-kernel)](https://api.reuse.software/info/github.com/outpost-os/sentry-kernel)\n\nThe Sentry kernel is a high security level micro-kernel implementation made for high security embedded systems that include micro-controllers in association with dedicated Secure Element component for security cryptographic functions.\n\nComplete Sentry documentation is published on [readthedocs](https://outpost-sentry.readthedocs.io/en/latest/index.html).\n\nSentry kernel uses [The Meson Build System](https://mesonbuild.com/).\n\n# Prerequisites\n\n## Tools installation\nBefore building the project, one needs to install the build system and related tool. This project use the meson reference implementation in python. All dependencies are described in `requirements.txt`.\n\n```console\npip3 install -r requirements.txt\n```\n\n## Cross Toolchain\n\nThis kernel aims to be fully portable. Its initial target are ARM Cortex-M MCUs (starting with STM32) and thus one needs a cross toolchain for such target. One can use any cross toolchain as long as this is a GNU compatible compiler for Cortex-M. The reference toolchain used for `CI/CD` is bundled in this project using `meson` wrap mechanism.\n\nCross-toolchain relative need to be declared so that the `meson` build system is able to detect overall cross-compilers and associated tools. This is\ndone by defining `cross-files`. The meson build system describes these cross file [here](https://mesonbuild.com/Cross-compilation.html).\n\n### Project bootstrap\n\nA common good practice is `do not inject environment variable for build configuration`. For this purpose, `meson` does not allow using relative path in toolchain definition. Toolchain path **_must_** be absolute.\n\nOne needs to deliver to the `meson` build system the kernel configuration based on Kconfig. This can be done with\nkconfiglib that is listed in `requirements.txt. The kernel configuration is generated into a local `.config` file that\nholds the complete kernel configuration, and that is used at build time to select the corresponding sources and features.\n\n#### Using defconfigs\n\ndefconfig files are stored in configs/ directory and can be used directly. In that case, the defconfig must be parsed in order to\nforge a `.config` file. This file is then passed to the `config` option at setup time:\n\n```console\ndefconfig configs/stm32f4_debug_defconfig\nmeson setup -Dconfig=.config [...]\n```\nIf a complete config file is used, it can be directly passed to the `config` option.\n\n#### Setting custom configurations\n\nGenerating the configuration is made using the standard Linux Kconfig UI. This interface can be called by ninja by targetting the kconfig module's menuconfig target:\n```console\nninja -C builddir kconfig@@menuconfig\n```\n\nOr by calling `menuconfig` directly. This, one need to have kconfig venv set correctly (`srctree` and `subprojects`).\nThis can be done by using Meson [`devenv`](https://mesonbuild.com/Commands.html#devenv)\n```console\nmeson devenv -C builddir\nmenuconfig\n```\n\n# How to build\n\n## About build options\n\nThe Sentry kernel has the following configuration options, that can be added at `meson setup` time using `-D\u003coptname\u003e=\u003coptvalue\u003e`\n\n   * `with_doc` (boolean, false): Enable support for building docs\n   * `with_tests` (boolean, false): Enable unit test suite support through `meson test`\n   * `with_proof` (boolean, false): Enable support for frama-C analysis through `meson test`\n   * `with_kernel` (boolean, true): Enable kernel binary build\n   * `with_uapi` (boolean, true): Enable kernel UAPI library build\n   * `with_idle` (boolean, true): Enable kernel Idle task build\n   * `with_tools` (boolean, true): Enable build host native tooling build\n   * `config`: (string): path to the defconfig file. Can be externally provided, while respecting the kernel Kconfig\n   * `dts` (string): DTS file path, may be local or any externaly provided DTS file\n   * `dts-include-dirs` (array): DTS file include dir for dtsi resolution, depending on the DTS file content\n\nIt is to note that all the `with_` options are not mandatory, while others are.\n\n## meson setup\nThe first step in meson build is project setup, this will create a specific build directory for the given options. This step also configures the toolchain to use.\n\nSome cross-files describing toolchain configuration are set in `support/meson` directory. More than one cross file can be used if needed.\n\n```console\nmeson setup [-Doption ...] --cross-file=\u003c/path/to/cross/file\u003e \u003cbuilddir\u003e\n```\n\nA typical complete setup of the Sentry kernel can then be, in a standalone mode:\n\n```console\ndefconfig configs/stm32f429i_disc1_autotest_defconfig\nmeson setup -Dwith_doc=true -Dwith_tests=true -Ddts=dts/examples/stm32f429i_disc1_autotest.dts -Dconfig=.config --cross-file support/meson/armv7m.ini --cross-file support/meson/cortex-m4.ini builddir\n```\n\n## build\n\nOnce meson build directory is setup, the build step is as simple as calling ninja.\n```console\nninja -C builddir\n```\n\n## proof\n\nSentry kernel proof is supported by Frama-C framework. It is based on the\nanalysis of the libsentry sources, which include all the kernel drivers,\nservices, etc. except the kernel entrypoint.\n\n**INFO**: the Frama-C framework used is Cobalt (27), with why3 and cvc4. Meson check that they are installed on the system.\n\nFrama-C targetts are hosted in the `proof` directory and are activable using\nthe `with_proof` option:\n\n```console\nmeson setup -Dwith_proof=true [...]\n```\n\nIt can be directly used with the cross configuration, as frama-C only preprocess the sources and then natively parse the C code into its own AST\nin order to analyse the source correctness.\n\nFramaC execution is controled through the meson test framework (see tests chapter) and thus is directly accessible through the test command.\nAll Frama-C tests are a part of the same suite denoted proof. If both proofs and tests are enabled in the very same time, the proof tests can\nthen be called separatelly by calling only the proof suite.\n\nFramaC tests can be listed using:\n\n```console\n$ meson test -C builddir/ --list\nsentry-kernel:proof / frama-C-parsing\nsentry-kernel:proof / frama-c-eva-entrypoint\nsentry-kernel:proof / frama-C-eva-handler-systick\nsentry-kernel:proof / frama-c-eva-handler-svc\nsentry-kernel:proof / frama-c-eva-zlib\nsentry-kernel:proof / frama-C-eva-handler-systick-redalarm\nsentry-kernel:proof / frama-c-eva-handler-svc-redalarm\nsentry-kernel:proof / frama-c-eva-zlib-redalarm\n[...]\n```\n\nEach Frama-C execution is stored in a dedicated build directory that hold all usual files such as session file, red alarms, flamgraph and so on,\nthat allows various post-processing, such as results analysis or Frama-C tools usage such as `ivette` or `frama-c-gui`.\n\n## tests\n\n### Unit testing\n\nSentry kernel supports unit testing. This is done using the gtest framework.\nAnalysis of various components of the Sentry kernel is made by emulating, for each subcomponent, the ecosystem it needs in order to simulate the target.\nFor e.g., the EXTI driver is unit-tested using an emulated EXTI device mapped at the very same memory address map as the effective device, so that the device driver do not need any modifiacations while tested.\n\nOther non-HW related components are tested for their expected behavior, in multiple nominal and borderline cases.\n\nEnabling the test suite is made by activating the tests at setup time:\n\n```console\nmeson setup -Dwith_tests=true [...]\n```\n\nThe test framework is based on multiple test suites. The suite names can be listed using the standard `meson test` target:\n\n```console\nmeson test -C \u003cbuilddir\u003e --list\nsentry-kernel:ut-utils / io\nsentry-kernel:ut-utils / bits\nsentry-kernel:ut-bsp / exti\n```\n\nEach test suite (or even test) can be executed independently if needed:\n\n```console\nmeson test -C \u003cbuilddir\u003e --suite ut-utils\n[...]\n```\n\n### Pre-integration tests with autotest\n\nSentry support a special applications named autotest (see concepts) that is built in autotest mode in order to execute and validate the\noverall Sentry UAPI for efficient performance and anti-regression testing.\n\nWhen build in autotest mode, the build system generate a dedicated `firmware.hex` file, in which Sentry kernel automatically load and\nstart the autotest application.\nAutotest results can be manually read from serial output, or can be\nparsed, generating a full report using **robotframework**. The robot files are written in the `tools/robot` subdir and can be directly called by robotframework, generating a complete report.\n\nWhen installed, the kernel build system install target deploy the robot files in the `$datadir/robotframework` directory\n\nIn order to support example robot files, robotframework-pyocd\u003e=0.2.0 and robotframework-pyserial\u003e=1.2.0 python packages are required.\nA typical usage of robot files of the kernel would be, considering the following `pyocd list` content:\n\n```console\npyocd list\n  #   Probe/Board       Unique ID                  Target\n---------------------------------------------------------------------\n  0   STLINK-V3         004300483232510239353236   ✔︎ stm32u5a5zjtxq\n      NUCLEO-U5A5ZJ-Q\n\n  1   STM32 STLink      0671FF575251717867205336   ✔︎ stm32f429zitx\n      DISCO-F429Z\n```\n\n```console\nrobot --variable FIRMWARE_FILE:builddir/firmware.hex --variable PROBE_UID:004300483232510239353236 -d results ./tools/robot/sentry-autotest.robot\n```\n\nAll results (report and logs) are then deployed in the results local directory.\n\n## Documentation\n\nSentry documentation is written in the `doc/` subdirectory.\nIt can be build if the `with_doc` flag is set to true.\n\nThere are multiple doc types:\n\n   * concepts: Overall Sentry concepts definition, and high level documentation, targetting the user or application developer\n   * internals: Sentry internal code hierarchy, mostly built using doxygen. This doc is for kernel developers\n   * mandb: Sentry UAPI manuals, in groff (man) format, so that it can be used with the `man` utitily\n\nThe ninja targets associated to these documentations are `doc-concepts` (`doc-concepts-pdf` for PDF generation), `doc-internals` and `mandb`.\n\nGenerated documentation is in the `$BUILDDIR/doc` directory, and are also deployed in `/usr/share/doc` in case of the usage of the `install` target.\n\nMore information about the various concepts of the Sentry-kernel and its build system can be found in the `concepts` documentation.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Foutpost-os%2Fsentry-kernel","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Foutpost-os%2Fsentry-kernel","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Foutpost-os%2Fsentry-kernel/lists"}