Initial support for the ATECC508A #3696
Conversation
572d0df to
0b8e506
Compare
|
Generally, I think it absolutely makes sense to include/use cryptographic peripherals. First, while having the cipher/plaintext exposed over, e.g. I2C that could be sniffed with physical access is a bummer, but fine under some threat models (e.g. TPMs often have this "flaw" at a higher level). Second, it's really not the place of the Tock, IMO, to dictate which threat models are or are not acceptable. One caveat would be if there is a significant architectural or performance/overhead cost to support multiple cases, we might want to optimize for the case that is either more common or "better." In this case, since cryptographic accelerators, whether on or off die, are very likely to be asynchronous anyway (we're not talking about an AESNI instruction or something, but co-processors in both cases), I don't forsee that being an issue here. |
0b8e506 to
f90fa94
Compare
I know I'm kind of necroing this and just leaving a drive-by reply, but the ATECC608A is capable of having a symmetric key on the MCU and on the secure element and you can encrypt the I2C communication, in order to mitigate this issue. |
0e4e20c to
ad8df50
Compare
ad8df50 to
eb19bc2
Compare
|
Ready to go now |
|
Ping! |
1 similar comment
|
Ping! |
b5e1764 to
379f453
Compare
|
Ping! |
There was a problem hiding this comment.
This seems like a cool chip to support.
The wakeup function indeed seems less than elegant, but I don't have any hard feelings about this code so long as it's in the board crate, and I wouldn't want to block on that.
Some other (minor) remarks. This is yet another component that illustrates that we need some form of configuration framework, instead of sprinkling cfgs here and there. For now, configuration boards seem to be the best approximation of that, and I can see that working well here too.
As I don't own this chip myself I can't really test any of the capsule code. From skimming over it, nothing stood out to me though.
| # This feature enables support for the ATECC508A Cryptographic Co-Processor | ||
| # Breakout. If you connect one of these | ||
| # (https://www.sparkfun.com/products/15573) via the I2C Qwiic connector you | ||
| # should enable this feature. | ||
| atecc508a = [] |
There was a problem hiding this comment.
I think this is a great use of our newly established configuration boards concept. You can convert the lora_things_plus board into a bin+lib crate, and then create a configuration board which extends this base board with your peripheral.
I'm personally not opposed to cfgs in boards as much as I am for all other crates, but even here the fact that we don't test all (or actually, any) permutations of features means this is subject to bit rot.
And seeing that you have global use statements depend on this cfg makes me really skittish. Those are really hard to keep in sync & free of warnings without CI that tests all permutations of features.
There was a problem hiding this comment.
I was trying to avoid a configuration board for this. I think there are good use cases for the config boards, but I don't feel this is one of them.
In this case we are just enabling an off board peripheral. As it's only additive I feel it's a good use for a cfg. It also will hopefully allow adding things in the future. On top of that a cfg board is extra maintenance and the 3 apollo3 boards are already hard to keep in sync.
I agree about not being tested though. What if I ensure they are tested in the CI?
There was a problem hiding this comment.
This is tested in the CI now
| return; | ||
| } | ||
|
|
||
| debug!("This can not be undone!"); |
There was a problem hiding this comment.
I don't like that we're permanently locking a config without user input. Imagine a user doesn't have their serial port open -- they may easily just leave it connected after flashing. Is locking required to use the device, and if so, how is this test/function even run? Adding some docs here, and perhaps waiting until a button is pushed would be good.
There was a problem hiding this comment.
Locking is required to use the device at all. The test is run as part of the usual make test process.
I can add some more docs to explain that as well. The board does have a button, but mine doesn't work (no idea why) so I can't easily test waiting on a button
There was a problem hiding this comment.
That's unfortunate. I guess waiting for a character on the UART is too hard in the kernel?
I mis-burned some expensive clock chips before by accident, and it's incredibly frustrating when fuses / configs are burnt without explicit, all-caps, triple-checked user confirmation. In the best case it's "whatever", worse it means re-ordering and waiting for a new chip, and for some people the $4.95 + shipping might also be a not-insignificant amount of money.
So I really would like to see us have some form of user input beforehand. 😕
There was a problem hiding this comment.
That's fair... But I don't really have a easy way to ask for input before running the kernel tests.
My feeling at the moment is that a user must explicitly enable this feature and plug the device into the board. At which point hopefully they know we have to lock the device otherwise nothing on it works
379f453 to
263e34b
Compare
|
I think this is exposing some warts in the otherwise ideally clean separation of concerns, but is otherwise close to good, modulo @lschuermann's comments |
66555c5 to
05cd985
Compare
|
Updated, I think that should address all of the comments |
|
Ping! |
Signed-off-by: Alistair Francis <[email protected]>
If we read the interrupt state again during the interrupt handler we can miss important information, such as a Nack event. So don't handle the interrupts that occur while processing an interrupt and instead wait for the interrupt handler to be called again. Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
…ation Device Signed-off-by: Alistair Francis <[email protected]>
05cd985 to
b098a67
Compare
…on Device Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
b098a67 to
412caaa
Compare
|
Ping! |
|
@lschuermann I think your concerns are addressed. |
Pull Request Overview
The ATECC508A is an interesting Cryptographic Co-Processor.
It connects to an MCU via I2C and can then provide crypto features, including
The ATECC608A (different chip, but backwards compatible) even supports AES encryption/decryption. The ATECC608A is aimed at TLS support and secure booting, both of which are interesting use cases for Tock.
The ATECC508A/ATECC608A is useful for Tock boards as it provides crypto operations and entropy sources for boards that otherwise wouldn't have any. The hope is that co-processors like this can help expand Tock's crypto support and develop generic HILs and capsules. It would also be great to implement a measured boot in Tock.
Testing Strategy
This PR can lock the device and retrieve random numbers from it.
TODO or Help Wanted
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.