| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
cmake: fix and update packaging | 3 年前 | |
NuttX cmake improvements - fix temporary Make.defs copy - implement custom macros for COMPILE, COMPILEXX, ASSEMBLE, ARCHIVE to enable ccache properly (if available and enabled) - fix NuttX mkdeps - fix libapps race condition with context | 6 年前 | |
fix(build): add kconfig support for fortified toolchains | 5 个月前 | |
Cygwin: use absolute path with cygpath conversion to the linker script again because the relative path is interpreted differently on linux, mac and windows | 8 年前 | |
fix(cmake): incremental no-op rebuild 44 s -> 0.15 s on NuttX targets (#27324) * fix(cmake): use Python3 module; cache PYTHON_EXECUTABLE properly The legacy find_package(PythonInterp 3) is deprecated (warned with noisy CMP0148 by cmake 3.27+, currently visible on Ubuntu 24.04 CI runs). It also stores its result as PYTHON_EXECUTABLE without a proper CACHE type, which interacts badly with the Makefile's cmake-cache-check. cmake -L skips UNINITIALIZED entries, so the -DPYTHON_EXECUTABLE=... passed by the top-level Makefile is never matched in the cache and every invocation forces a full reconfigure. Switch to find_package(Python3 COMPONENTS Interpreter REQUIRED), then bridge to the legacy PYTHON_EXECUTABLE name that the rest of the codebase still references. Promote it to a CACHE FILEPATH entry so cmake -L lists it, preserving any user-supplied value verbatim (find_package(Python3) canonicalises e.g. bin/python3 to bin/python3.13, defeating a string-based cache match). Signed-off-by: Daniel Fanache <dan@rts.ro> * fix(cmake): promote CONFIG to CACHE STRING for incremental builds When CONFIG is passed via -DCONFIG=... on the cmake command line, it is stored as an UNINITIALIZED cache entry. cmake -L skips UNINITIALIZED entries by design, so the Makefile's cmake-cache-check (which uses cmake -L to diff desired vs cached options) never finds CONFIG in the output, concludes the cache is stale, and triggers a full reconfigure on every make <target> invocation. If a config identifier is given, we force promote it to CACHE STRING. This preserves the user supplied value as it was, while making it visible to cmake -L, so the cache-check succeeds when nothing has changed. Signed-off-by: Daniel Fanache <dan@rts.ro> * fix(cmake): track default.px4board as a configure dependency Non-default labels merge default.px4board + {label}.px4board via merge_config.py, but only the label file was listed as a configure dependency. Changes to default.px4board were silently ignored until a clean build, which is surprising and easy to debug for hours. Register default.px4board as a CMAKE_CONFIGURE_DEPENDS in the non-default-label branch so edits trigger reconfigure as expected. Signed-off-by: Daniel Fanache <dan@rts.ro> * fix(cmake): correct NuttX apps/library build dependency tracking Three dependency graph defects in the libapps.a and per NuttX library custom_commands caused either spurious full rebuilds or stale outputs on incremental builds. (1) builtin_list.h and builtin_proto.h are regenerated by the apps build from px4.bdat/px4.pdat on every invocation. They were included in nuttx_apps_files, so on each build we saw them as changed inputs and re-triggered the apps target perpetually. Exclude them with a list(FILTER). (2) libapps.a's custom_command lacked px4.bdat/px4.pdat as dependencies, so module additions or renames (which regenerate those registries) did not propagate to a rebuild of the builtin command table. Add them to DEPENDS. (3) NuttX's recursive make does not always notice that builtin_list.h has been regenerated and that builtin_list.c therefore needs recompiling. Touch builtin_list.c so NuttX's make picks up the indirect change. Additionally, drop the destructive cleanup COMMANDs that ran at the start of libapps.a and each per-library custom_command (remove -f *.a, find ... -delete *.o). These were workarounds for the now fixed dependency tracking; without them removed, they would also force unnecessary full rebuilds every time. Signed-off-by: Daniel Fanache <dan@rts.ro> --------- Signed-off-by: Daniel Fanache <dan@rts.ro> Co-authored-by: Ramon Roche <mrpollo@gmail.com> | 4 个月前 | |
parameters: remove parameters_injected.xml and support for it in the build system (#25549) This was apparently added 10 years ago to store metadata of UAVCAN components within the PX4 binary. The parameters in the xml are mostly early UAVCAN ESC parameters that are presumably out of date and not used. Also it does not scale to maintain metadata for all the possible UAVCAN components and it causes confusion when users read the metadata documentation because these parameters are not available in PX4. That's why I suggest to remove it. | 1 年前 | |
build(simulation): depend on gz-harmonic for SITL deb (#27178) * build(simulation): depend on gz-harmonic meta-package for SITL deb * build(simulation): refresh apt lists before installing px4-gazebo .deb | 5 个月前 | |
tests: remove previous fuzz testing We now use https://github.com/google/fuzztest (see previous commits). And the test was also failing to build (https://github.com/PX4/PX4-Autopilot/actions/workflows/cflite_batch.yml) This reverts these commits: - 9eda5b373c1f16ffec585a0e27d55682d5726c0e - 2cbc99397681ad9b67f69703c5dd65eaea26c154 - be0a5b4b3272fac13716436c06ff435d157965b4 | 1 年前 | |
fix(cmake): add proper gtest filtering (#26861) Before this change, filtered test runs still built every gtest target because test_results depended on all unit and functional gtest targets. This updates both px4_add_unit_gtest() and px4_add_functional_gtest() to use the filtered dependency helper so filtered runs only build the selected targets. Signed-off-by: Onur Özkan <work@onurozkan.dev> | 5 个月前 | |
Qurt lightweight parameter implementation (#20735) | 3 年前 | |
events: Move implementation of events::send() to lib/events Events have a global, system-wide sequence number, which must be handled atomically, (fetching and incrementing the sequence AND sending the event to uORB must be atomic). Currently in FLAT mode, only one instance of this sequence number exists, so it is OK to have it in px4_platform. However, in PROTECTED mode px4_platform is instantiated both in kernel- and user spaces, which makes two instances of this sequence number, which causes problems in the mavlink event handling logic. When mavlink receives and handles events, it expects that: - The sequence numbers arrive in order (seq n is followed by n+1 etc) - It increments by 1 - There is only one instance of the sequence number In PROTECTED mode this is violated, as the kernel and user sequence numbers run freely on their own. This patch fixes the issue by moving the event backend to the kernel and by providing user access to it via ioctl. | 2 年前 | |
feat(bootloader): Revive secure-boot with example, docs, and various fixes (#27237) * feat(secure_bootloader): add ed25519 key and signing helpers Scaffolding for PX4 secure-boot firmware signing, split into two self-contained scripts: - generate_signing_keys.py: produces <name>.json (private+public hex) for use by sign_firmware.py and <name>.pub (C-array public key) for inclusion in the bootloader build via CONFIG_PUBLIC_KEYn. Refuses to overwrite existing private-key files. - sign_firmware.py: pads an input .bin to a 4-byte boundary and appends a 64-byte ed25519 signature, producing a file that drops directly into the flash slot described by the image TOC. Optionally appends an R&D certificate binary after the signature. Replaces the signing path of the old Tools/cryptotools.py that was removed along with the log-encryption cleanup; the new layout keeps bootloader-signing tooling separate from log encryption to avoid confusing the two independent crypto surfaces. * fix(bootloader): panic if px4_get_secure_random is ever called sw_crypto's crypto_open() unconditionally references px4_get_secure_random from its XCHACHA20 path, so even a bootloader that only performs ed25519 signature verification (and never touches stream ciphers) pulls in an undefined symbol at link time. The app build resolves it through nuttx_random.c, which is gated behind CONFIG_CRYPTO_RANDOM_POOL and only compiled in when the NuttX random pool is enabled. That config isn't on in the tiny bootloader NuttX defconfig, and enabling it would pull in a pile of kernel code the bootloader doesn't need. Supply the symbol locally, but make it call up_assert() instead of returning zeros. Silently handing out predictable bytes would be a serious security bug if anyone later enables the XCHACHA20 path in the bootloader without wiring up a real RNG. Aborting makes the mistake impossible to miss. * fix(bootloader): add PROTO_VERIFY_SIG opcode for upload-time signature check Today a signed-boot failure is invisible to the uploader: verify_app() runs inside jump_to_app() after PROTO_BOOT has already rebooted the chip, so the host sees a successful upload followed by the device silently staying in the bootloader. There is no protocol-level signal that the image that was just written is not going to run. Add PROTO_VERIFY_SIG (0x39) so the host can ask the bootloader to run find_toc() + verify_app(0) *before* the reboot and get a concrete OK / FAILED / INVALID answer back over the still-open USB connection. The new opcode is gated on BOOTLOADER_USE_SECURITY: bootloaders built without secure boot return cmd_bad (INSYNC/INVALID) so an uploader can tell "I don't know this command" apart from "verification failed". Two subtleties required care: 1. PROG_MULTI deliberately defers the very first word of the app image to a RAM variable (first_word) and only commits it to flash inside PROTO_BOOT, so a partial upload can never become bootable. But verify_app() reads directly from flash, so if we verified before committing first_word, even a valid image would always fail (the first four bytes at APP_LOAD_ADDRESS would still be 0xffffffff). The handler therefore mirrors the first half of the PROTO_BOOT handler: gate on STATE_ALLOWS_REBOOT, program the deferred first word, then run the crypto check. 2. On failure we deliberately do not try to "undo" the first-word write — H7 flash programming granularity makes it impossible to revert in place, and the device was going to end up in the same reject state at the next boot either way. The improvement is purely that the uploader sees the failure before REBOOT instead of after. Chose opcode 0x39 to stay clear of ArduPilot's 0x28 (READ_MULTI) and 0x40 (CHIP_FULL_ERASE), which PX4 does not currently use but which an AP-compatible uploader might. ArduPilot also has bootloader secure boot (monocypher ed25519, like us) but their verification runs at boot time, not upload time — so neither project currently solves the "upload silently wrote a bad image" problem. This puts PX4 ahead on that. * feat(Tools): add --image_signed to mark signed firmware for uploader px_uploader.py only needs to run signature verification over USB for images that actually carry a signature — asking the bootloader to verify an unsigned image would always fail, and the extra round trip is wasted time for the common unsigned case. It therefore needs a reliable way to tell the two apart. We cannot tell by inspecting the bytes: a sign_firmware.py output is just the raw .bin with 64 bytes of ed25519 signature glued on the end, indistinguishable in content from an unsigned image of the same padded length. The natural place to put the flag is the .px4 JSON envelope, which already carries board_id / version / summary / etc. Add --image_signed to px_mkfw.py, which sets "image_signed": true in the emitted JSON. The flag has no effect on what bytes actually end up on the device — it just tells the uploader "this blob has a signature, please verify it before booting". * feat(Tools): verify firmware signature before reboot After PROG_MULTI + GET_CRC, send a new VERIFY_SIG opcode (0x39) to the bootloader to check the ed25519 signature over the freshly flashed image *before* sending REBOOT. This way a signature failure is reported as a clean error from the uploader script, instead of a silent "device stays in bootloader after reboot" that leaves the user guessing. The uploader always probes VERIFY_SIG. The bootloader is the source of truth for whether secure boot is enabled: - INSYNC/OK -> verification passed, proceed to REBOOT - INSYNC/FAILED -> raise; "Signature does not verify against any trusted key" if the firmware claims to be signed, "Secure bootloader rejected an unsigned image" otherwise (= helpful guidance for the common misconfiguration of uploading default firmware to a secureboot bootloader) - INSYNC/INVALID -> bootloader has no secure boot. Quietly proceed unless the firmware metadata says image_signed, in which case raise. - recv timeout -> assume a pre-VERIFY_SIG bootloader, proceed. Surfaces a "Verifying image signature... passed" line on the upload status path when the firmware is marked signed, so users get a clear positive signal that the secure-boot pipeline ran end-to-end. Also drop the redundant logger.error in the upload() loop, which was duplicating the error message printed by the top-level handler in main() for every UploadError path (not specific to verify_signature, but only became obvious once these clean error messages started firing in normal usage). * fix(cmake): fix .px4board variant resolution to require exact match px4_config.cmake matched the requested CONFIG against each candidate .px4board with MATCHES, which is a regex partial match. For a config like px4_fmu-v6x_bootloader_secureboot, the iteration over .px4board files (alphabetical glob order) would match bootloader.px4board first — because "px4_fmu-v6x_bootloader" is a prefix of "px4_fmu-v6x_bootloader_secureboot" — and stop, silently selecting the wrong board config. Use STREQUAL instead so each candidate has to match the full requested CONFIG. Existing single-label cases (e.g. exact match on px4_fmu-v2_default or px4_fmu-v2) are unaffected because they were already exact in practice; this just plugs the prefix-match hole that any future <label>_<suffix> variant would trip over. * fix(nuttx): support bootloader_<variant> labels Boards can ship bootloader variants beyond the default bootloader label — e.g. a bootloader_secureboot that adds crypto + keystore Kconfig on top of the same source tree. Two pieces of build glue were hardcoded to the exact label bootloader and need to relax to match any bootloader_* label: 1. platforms/nuttx/CMakeLists.txt picked the bootloader linker script and bootloader-specific library list only when the label was exactly bootloader. Any other label (including bootloader_secureboot) silently fell through to the app build, producing nonsensical link flags. Match ^bootloader instead, and explicitly set SCRIPT_PREFIX to bootloader_ so all bootloader variants share the single existing linker script regardless of their full label. 2. platforms/nuttx/cmake/px4_impl_os.cmake selects the NuttX config subdirectory by exact label match, falling back to nsh when no matching directory exists. For bootloader_secureboot that fell through to nsh, dragging in a full app-style NuttX with cromfs, networking, and the full heap subsystem — a 128 KB bootloader sector overflowed by ~50 KB. Add an intermediate fallback: if the label starts with bootloader and a bootloader/ subdir exists, use that instead of nsh. Both changes are backward-compatible: existing single-label bootloader builds take exactly the same path as before. They only gain the ability for boards to add bootloader_<suffix>.px4board files without duplicating bootloader build wiring. * feat(build): auto-sign secure-boot images via BOARD_SECUREBOOT Add a Kconfig pair that boards can opt into: CONFIG_BOARD_SECUREBOOT -- bool: sign the .px4 with ed25519 CONFIG_BOARD_SECUREBOOT_KEY -- string: path to JSON private key (default: Tools/test_keys/test_keys.json) When set, the .px4 build rule inserts a Tools/secure_bootloader/sign_firmware.py step between the unsigned .bin and px_mkfw.py, and passes --image_signed so the .px4 envelope's metadata flags it for the uploader's VERIFY_SIG step. The unsigned .bin is still produced alongside the .px4, so users can sign with their own key out-of-tree if they prefer. A BOARD_SECUREBOOT_KEY environment variable overrides the Kconfig path at build time, mirroring the override pattern used for CONFIG_PUBLIC_KEYn in stub_keystore. This makes release builds practical: BOARD_SECUREBOOT_KEY=/secure/path/release.json make px4_<board>_secureboot Relative paths in the Kconfig are resolved against the repo root (not the build directory) so the same value works regardless of where the build runs from. Default builds are byte-identical to before; the new code path is gated on CONFIG_BOARD_SECUREBOOT being set. * feat(boards): add secureboot demo variant + docs Two coordinated build variants demonstrate end-to-end secure boot on px4_fmu-v6x without touching the default builds: px4_fmu-v6x_secureboot -- the app, with TOC + signing px4_fmu-v6x_bootloader_secureboot -- the matching secure bootloader App side (secureboot.px4board): - Selects nuttx-config/scripts/secureboot-script.ld via CONFIG_BOARD_LINKER_PREFIX. The script is a copy of the default layout plus a fixed 0x800 reservation past the vector table for the image TOC, and an empty .signature section at end-of-FLASH so sign_firmware.py knows where the appended ed25519 signature will land. - Compiles src/toc.c (a four-entry IMAGE_MAIN_TOC matching the layout used elsewhere in the tree) into drivers_board, gated on PX4_BOARD_LABEL == secureboot so the default build still produces the existing layout. - Sets CONFIG_BOARD_SECUREBOOT=y so the .px4 build rule signs the image with the upstream test key by default. Bootloader side (bootloader_secureboot.px4board): - Enables CONFIG_BOARD_CRYPTO + DRIVERS_SW_CRYPTO + DRIVERS_STUB_KEYSTORE, which links monocypher and the stub keystore into the bootloader. - Bakes Tools/test_keys/key0.pub in as CONFIG_PUBLIC_KEY0, paired with the test_keys.json the app variant signs with. - hw_config.h gates BOOTLOADER_USE_SECURITY, BOOTLOADER_SIGNING_ALGORITHM (CRYPTO_ED25519), and BOARD_IMAGE_TOC_OFFSET (0x800) on PX4_CRYPTO, so they only activate in this variant. Together the two variants implement the workflow: make px4_fmu-v6x_bootloader_secureboot # build + flash via SWD once make px4_fmu-v6x_secureboot upload # signs with test key, verifies Bootloader fits in 128 KB (~57 KB used) thanks to --gc-sections stripping the unused libtomcrypt code; nothing in the bootloader binary depends on monocypher beyond the ed25519 verifier. Replace the bundled test key for production with Tools/secure_bootloader/generate_signing_keys.py output and update both .px4board files (or set BOARD_SECUREBOOT_KEY at build time) — see docs/en/advanced_config/bootloader_secure_boot.md. * fix(boards): cap H7 bootloader linker scripts at 128 KB Roughly half of the H7 boards in tree had LENGTH = 2048K for the bootloader sector in their bootloader_script.ld, even though the matching app linker script places APP_LOAD_ADDRESS at 0x08020000 — i.e. the bootloader actually only owns the first 128 KB sector. The 2048K constraint is wrong: it lets a bootloader that grew past the 128 KB sector silently overflow into the app sector at link time and corrupt the start of the app on flash. The linker should fail the build instead. The current default bootloader is ~46 KB, well under 128 KB on every affected board, so this change is a no-op for default builds. It just plugs a footgun for anyone adding bootloader features (secure boot, extra UI, network boot, ...) that would have otherwise silently grown into the app's flash range. Boards fixed: 3dr-style H7 reference boards: cubepilot/cubeorange, cubepilot/cubeorangeplus, holybro/durandal-v1, narinfc/h7 vendor variants: corvon/743v1, cuav/nora, cuav/x7pro, gearup/airbrainh743, hkust/nxt-dual, hkust/nxt-v1, matek/h743, matek/h743-mini, matek/h743-slim, micoair/h743, micoair/h743-aio, micoair/h743-lite, micoair/h743-v2, x-mav/ap-h743r1, x-mav/ap-h743v2 Boards already correct (LENGTH = 128K) are unchanged. * fix(ci): add pynacl to Python requirements Tools/secure_bootloader/sign_firmware.py uses PyNaCl for ed25519 signing, and the .px4 build rule for boards with CONFIG_BOARD_SECUREBOOT calls it as part of the normal build (e.g. px4_fmu-v6x_secureboot). Without pynacl in the dev requirements, those builds fail in CI and fresh dev setups. * docs(update): Subedit * docs(update): Fix example error I made * fix(docs): document BOOT and SIG1 regions * fix(platforms): style fix * fix(ci): workaround to get pip dependency * fix(ci): fall back to plain pip on older build containers The voxl2 build image ships a pip that predates --break-system-packages (added in pip 23.0.1), so the install step blew up with "no such option". Modern containers enforce PEP 668 and need the flag; older ones don't support it but also don't enforce PEP 668, so plain pip works there. Try the modern flag first, fall back if pip rejects it. Signed-off-by: Julian Oes <julian@oes.ch> * fix(build): strip BUILD_DIR_SUFFIX from CONFIG in cmake-build cmake-build was passing the full build-dir name (including any BUILD_DIR_SUFFIX like _replay or _failsafe_web) as -DCONFIG=, which the board-lookup in cmake/px4_config.cmake then tried to match against <vendor>_<model>_<label> .px4board files. That used to work by accident because px4_config.cmake matched with regex MATCHES, but since the switch to STREQUAL (needed to disambiguate bootloader_secureboot from bootloader) the suffixed CONFIG no longer matches anything and LABEL ends up empty, tripping a CMake error in kconfig.cmake. Pass the bare CONFIG and keep the suffix only on the build dir so both concerns are independent. Signed-off-by: Julian Oes <julian@oes.ch> --------- Signed-off-by: Julian Oes <julian@oes.ch> Co-authored-by: Hamish Willee <hamishwillee@gmail.com> | 3 个月前 | |
cmake add a few include guards - this is a minor cmake configure time optimization | 6 年前 | |
Whitespace cleanup. | 4 年前 | |
boards organization | 7 年前 | |
cmake: px4_parse_function_args re-enable failure on unparsed (invalid) arguments | 3 年前 | |
tests: remove previous fuzz testing We now use https://github.com/google/fuzztest (see previous commits). And the test was also failing to build (https://github.com/PX4/PX4-Autopilot/actions/workflows/cflite_batch.yml) This reverts these commits: - 9eda5b373c1f16ffec585a0e27d55682d5726c0e - 2cbc99397681ad9b67f69703c5dd65eaea26c154 - be0a5b4b3272fac13716436c06ff435d157965b4 | 1 年前 | |
feat(build): add SPDX 2.3 SBOM generation for builds (#26731) | 5 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 6 年前 | ||
| 5 个月前 | ||
| 8 年前 | ||
| 4 个月前 | ||
| 1 年前 | ||
| 5 个月前 | ||
| 1 年前 | ||
| 5 个月前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 个月前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 5 个月前 |