It would be nice if libnettle.a could be built out-of-the-box

[niels-moller]

This is what I'm trying to do, and it almost works:

$ mkdir nettle-tkey
$ cd nettle-tkey
$ ~/hack/nettle/configure --host=riscv32-unknown-none CC='clang-15 --target=riscv32-unknown-none-elf -march=rv32iczmmul -mabi=ilp32 -mcmodel=medany -nostdlib -fno-common -fno-builtin-printf -fno-builtin-putchar -mno-relax -O2 -Wall' --disable-shared --enable-mini-gmp --with-include-path=/home/nisse/hack/tkey/tkey-libs/include:/home/nisse/hack/tkey/include-hack
$ make libnettle.a

Not sure what's the intention, but I want to put tkey-libs/include on my include path, so that tkey-specific headers would be used as #include <tkey/foo.h> in application code.

I got this to work, with only a few header files added in the above include-hack directory. Details:

• assert.h: Just include tkey/assert.h. I think this file should be moved one level up, from include/tkey/.

• stdio.h: Dummy definition of FILE, stderr and fprintf:

typedef struct {} FILE;
#define stderr NULL
static inline int fprintf(FILE *f, const char *format, ...) { (void) f; (void) format; return -1; }

Not sure what would actually make sense for tkey-libs, but a fprintf function always returning -1 might be reasonable?

• stdlib.h: Include tkey/lib.h (for stddef.h and stdint.h, provided by clang). Dummy definitions of realloc (always return NULL), free (do nothing) and abort.

The abort function is an interesting case. Ideally, it should terminate application, with some way for firmware to tell the host that the app aborted. If that's not doable, maybe abort() should be an infinite loop, so it at least doesn't return.

• string.h: Include tkey/lib.h, for memset/memcpy. Define strcmp and memcmp.

In my hack string.h, I did strcmp and memcmp as static inline functions. I think it would make sense to add proper definitions of strcmp and memcmp to tkey-libs.

And that's all, with just those tweaks, it compiles successfully. Compiling the public-key things in nettle (the code which goes into libhogweed.a) will be more challenging, even with --enable-minigmp, since the bignum operations unfortunately depend on working malloc/realloc/free.

[mchack-work]

Thanks.

There's currently no way to return to firmware after switching to app mode, so firmware will have no way of indicating anything at all to the client if the device app aborts.

We might want to change tkey-libs' crt0.S to just loop forever if main() exits. Not sure why it doesn't when the corresponding thing in firmware does.

[niels-moller]

One alternative, applied to all of abort, exit, _exit, and return from main, might be to signal break on the serial port, and then loop forever. Seems a bit hairy for the host client to detect break in a useful way on a unix tty, though. Or if there are some additional serial control lines wired up that could be used for signalling. In a different project with a lattice ice40 board, I managed to wire up the DCD bit to indicate if the processor on the fpga is running or halted.

[mchack-work]

Signalling break on the serial port is a nice idea. We're moving to two device endpoints, though, both CDC and HID. There will be nothing listening on the CDC in the FIDO use case.

Changing the hardware right now to make signalling like this possible is a low priority.

It might help to feed an illegal instruction instead of just looping forever, though. That will trigger our illegal instruction hardware trap which is also used in assert(). It will blink the status LED red forever, controlled by only hardware. Not useful for the client software but a human observer might see it. At least something.

[mchack-work]

We might want to use our illegal instruction trap. That will blink the status LED red forever, controlled by only hardware. Not useful for the client software, but might be visible to a human user.

Signalling break on the serial port is a nice idea but since we're moving to have two USB classes, both CDC and HID, this might not be worth it.
There will be nothing listening on the CDC in the FIDO

[mchack-work]

We're just in the process of changing license to BSD 2 clause. Would you be willing to send a PR even if it's BSD licensed?

[niels-moller]

We're just in the process of changing license to BSD 2 clause. Would you be willing to send a PR even if it's BSD licensed?

On licensing, I don't think GPLv2-only was ideal, so I'm happy that is being changed. I do think GPL still would make sense for most or all of the code running on the device, and I'd be happy to discuss GPLv3 implications some time. But BSD 2 clause is good enough for contributing.