Gregory, I agree with Michael's response, but I fail to understand the scope/relevance of what you are describing.
The firmware running on the mote implements the IEEE802.15.4 TSCH state machine, which includes everything related to timing. If your "malware" is a complete new firmware, it can do anything it wants, including introduce an arbitrary drift, blink LEDs, or make coffee. If your "malware" is a new application running on top of a stack, your software architecture should rely on the kernel to prevent this application from breaking/influencing the stack. This can be done by having an MPU detect when the app accesses memory locations it isnt support to, and killing it. I feel that this discussion is related to software architecture, not protocol/6TiSCH. Thomas On Sat, Nov 12, 2016 at 11:49 AM, Michael Richardson <[email protected]> wrote: > > Gregory Braekevelt <[email protected]> wrote: > > I'm mainly searching for information that proofs or counters the fact > > that malware (can) cause clock drift. > > It could be the case, and for a specific device, and a specific piece of > malware, it could be the case. I see no reason for there to be general > rule > like this. > > So, yes, malware could cause clock drift, but I see no reason why malware > MUST cause clock drift. > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
