Skip to content

dev: add a note on what we consider to be an attack surface in AP #7359

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
peterbarker wants to merge 1 commit into
base: master
Choose a base branch
from
Open

dev: add a note on what we consider to be an attack surface in AP #7359

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions dev/source/docs/style-guide.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -770,3 +770,25 @@ No Dead Code
------------

We don't keep dead code in ArduPilot. If code is unused, it should be removed - not just commented out. This is a general rule and not universally adhered to.


Security Attack Surface
-----------------------

ArduPilot works in a resource-constrained environment. We can't afford all of the sanity checks that we might otherwise include.

To this end, we do not consider every input to the autopilot firmware potentially malicious. We trust our SPI-connected inertial sensors to be trusted, for example.
Copy link
Member

@IamPete1 IamPete1 Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To this end, we do not consider every input to the autopilot firmware potentially malicious. We trust our SPI-connected inertial sensors to be trusted, for example.
To this end, we do not consider every input to the autopilot firmware potentially malicious. We trust our SPI-connected inertial sensors to be well behaved, for example.

Just a little odd having "trust" in there twice.


Ground Control Stations
.......................

Most notable amongst "trusted" data sources are connections to the Ground Control Station. We expect GCSs to be well-behaved in terms of the data sent to the autopilot. Remember that your GCS can disarm your vehicle mid-air or force it into terrain as a matter of course.

We disable floating point exceptions in the embedded firmware, meaning that a lot of floating point operations which would result in a Floating Point Exception now simply don't. By default we do NOT disable floating point exceptions in SITL, allowing errors in Ground Control Stations to be picked up in SITL rather than when someone is flying a real vehicle!

One exception to the trusted-ground-control-station model is if MAVLink signing is enabled. If data coming into ArduPilot on a serial port configured for signed-only MAVLink2 connections from a GCS which does not have the signing key can cause the vehicle to misbehave (ignoring DOS attacks), we *do* consider this to be a security issue.

Disabling FPE in SITL
.....................

To more-closely approximate what happens on our embedded platforms, you can use the ``SIM_FLOAT_EXCEPT`` parameter to disable floating point exceptions in ArduPilot SITL. This may help find real problems with trying to use fuzzers to find problems with the ArduPilot codebase.