next_steps_nitrokey.md: extracted steps for Nitrokey integration #61
Conversation
Signed-off-by: Krystian Hebel <[email protected]>
docs/next_steps_nitrokey.md
Outdated
|
|
||
| # Implement functions specific to Fobnail in libnitrokey | ||
|
|
||
| This is temporary solution to allow testing until full Fobnail support is added |
There was a problem hiding this comment.
@krystian-hebel I'm not sure if I fully get it.
How is Implement functions specific to Fobnail in libnitrokey different from adding Fobnail support to libnitrokey ?
There was a problem hiding this comment.
libnitrokey is used for older Nitrokey models. For latest Nitrokey 3--which we are aiming here--we use pynitrokey instead.
There was a problem hiding this comment.
Probably @krystian-hebel was looking for a C library to have something without Python.
Is pynitrokey pure Python? If we are considering heads, we may have quite limited flash space to include Python interpeter and some Python modules, depending on the specific device.
There was a problem hiding this comment.
If Python is not suitable in this case, I suggest to write a new core library in Rust. This is something we were considering anyways but didn't had a need to yet.
There was a problem hiding this comment.
Heads has been looking at including Python: linuxboot/heads#689
But it is not there yet, and may be difficult to fit in some platforms/configs AFAIK.
There was a problem hiding this comment.
If you are confident that Rust will result in total smaller footprint than Python, then it might be a way to go.
I saw you have made some Rust work in heads already linuxboot/heads#1354 ?
There was a problem hiding this comment.
As for Python, Heads seems to also be headed in that direction. While I'm just a little worried about space issue for the interpreter itself, its modules tend to be bigger that C counterparts. I also prefer to get errors during compilation instead of runtime, especially for something that requires reflashing, but I can live with that.
Heads can increase amount of space available by using maximized builds, however this may prevent us from using DRTM later, because TXT probably requires ME to be functional.
I tried to build current CPython locally, and after disabling all optional features listed by ./configure --help and enabling optimizations I ended up with over 130 MiB to be installed, which after default XZ compression got down to 23MiB, which is still way too much. Note that this was with default gcc/libc on my host instead of musl used by Heads, but I don't expect it to miraculously get 10x smaller.
How is Implement functions specific to Fobnail in libnitrokey different from adding Fobnail support to libnitrokey?
Sorry, pushed wrong version, it was described better but I forgot to save the file. Based on the above discussion I'll try to rewrite this part in a way that doesn't makes any choice definitive.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Signed-off-by: Krystian Hebel <[email protected]>
No description provided.