Home >

The Best Defense is Offensive Programming

Tyler Hoffman - Watch Now - Duration: 43:21

Let's face it. The firmware we write has bugs, and we need to defend against and accept failures when our system experiences bugs. This is when we typically employ defensive programming practices, but if not used correctly, they may cause more problems than they solve.

There is an alternative and complimentary set of programming practices, often called "offensive programming", which takes defensive programming and flips it on its head. Instead of defending against errors in firmware, this technique will surface them immediately using liberal asserting and proper fault handling.

This talk will cover offensive programming techniques, prerequisites to implementing the suggestions in your firmware, and how you can use them to quickly and easily track down and root cause 1 in 1,000 hour bugs and keep your sanity at the same time.

italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 0 | 1 year ago | no reply

Thanks for a great talk. Which pressure sensor gave you problems at higher altitudes? I'm looking at BMP390 and a couple others...

Score: 0 | 1 year ago | 1 reply

Assuming you use malloc_assert() of times, would it be more efficient to make it into a macro, that would be replaced at compile time, than jumping to the function in runtime?

Score: 0 | 1 year ago | no reply

That's a good idea! I'm generally against macros that hide or change functionality and don't mind the extra function call in most cases. You could consider forcing inlining through your compiler options which would have the same benefit but not be a macro.

Steve S
Score: 0 | 1 year ago | 1 reply

Very good talk. I am also a fan of these offensive programming techniques. It may sound strange, but have you had to defend the offense; have you had to worry about offensive programming techniques in a critical application scenario. An example would be life support systems, or maybe autonomous driving systems. The reset is not, or less tolerable in these applications. Are there other offensive programming techniques (not hardware based) you would use here?

Score: 0 | 1 year ago | no reply

Personally, I need to dig in more myself and understand what is and isn't allowed in certain types of firmware / devices. I'd argue that letting a firmware continue to run with bugs occurring / corruption / undefined behavior is much, much worse than just resetting the system, especially if the device reboots on the order of milliseconds and can pick up from where it left off on boot.

We talked a little about recovering from faults without resetting the MCU in this Interrupt blog post: https://interrupt.memfault.com/blog/cortex-m-fault-debug#recovering-from-a-fault

I think for critical sections, it's probably OK to lessen the severity of the asserts and make them high-priority logs, but just make sure to track them! Understand why they are still being hit, aggregate and count them, and understand why they are happening. When testing internally, do escalate the issue and really dig into why it's happening.

Score: 0 | 1 year ago | no reply

Bug Report: @ 22 minutes
if (!name|| name_len > 32)
You said if name length is too small it is bad, but this looks to see if the length is too big

Score: 0 | 1 year ago | no reply

Awesome discussion Tyler! Thank you.