Very excited about yesterday's update。 I very much expect to get rid of the hardware (jlink) dependency。 I have one usb dongle (52840 dongle)，and have a try with nrfutil.

./deploy.py --board=nrf52840_dongle --opensk --programmer=nordicdfu fatal: This board doesn't support flashing over DFU.

then I checked deploy.py file.Then changed parameters: ./deploy.py --board=nrf52840_dongle_dfu --opensk --programmer=nordicdfu

I see ,it needs nrfutil command with version 5.1. AttributeError: 'dict' object has no attribute 'iteritems'。

Can you tell me if my operation is correct，and nrfutil's version.

Thanks !

Specifications

• Version:
• Platform: ubuntu 16.04 i686 ,python 3.5.

I'm trying to create ssh keys with ed25519-sk instead of ecdsa-sk but I receive this error: Key enrollment failed: requested feature not supported . This is my Openssh version: **OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k **

I'm using a nrf52840 dongle with the last updates of the stable branch.

Any idea why is this happening? Thanks in advance.

Is there an API in the OpenSK that I can use to store a secret string mapped to a username and retrieve it later on?

If not, can I exploit the FIDO register call to store a secret string mapped to a username? Is there any field in the FIDO2 protocol that is stored on the authenticator and is returned during authentication? I need it for the research prototype, so any hack/ideas would help.

Expected Behavior

I can register the OpenSK key on my Google account

Actual Behavior

When I try to register the OpenSK key on my Google account, it gets stuck on the confirmation page Here are the logs:

two-step-verification?rapt=***:1 Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
two-step-verification?rapt=***:1 Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
two-step-verification?rapt=***:1 Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
two-step-verification?rapt=***:1 Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.

Steps to Reproduce the Problem

1. Flash the OpenSK firmware to nRF52840-Dongle
2. Open https://myaccount.google.com/signinoptions/two-step-verification on Microsoft Edge
3. Click "Add security key", and click "Next"
4. Tap the button on the OpenSK key

Specifications

• Version: latest stable
• Platform: Windows

Feitian created an hardware dongle according to nRF52840 design, please refer to https://feitiantech.github.io/OpenSK_USB/hardware/ . There is no need to change anything to Google OpenSK source code, download the OpenSK firmware to Feitian Dongle, and it can work.

Expected Behavior

nRF52840 USB dongle should work with source code on stable branch or develop branch

Actual Behavior

Neither stable nor develop branch work.

Following below steps

1. ./reset.sh
2. ./setup.sh
3. ./deploy.py --board=nrf52840_dongle_dfu --opensk --programmer=nordicdfu
Have switched nrf52840 usb dongle to bootloader mode.
4. ./tools/configure.py \
    --certificate=crypto_data/opensk_cert.pem \
    --private-key=crypto_data/opensk.key

If I use source code from stable branch, step 4 reports error 0xF2.

info: Private key is valid.
info: Certificate is valid.
DEBUG:fido2.hid.macos:Found CTAP device: 4295020873
DEBUG:fido2.hid:SEND: ffffffff8600084859dd5c0a590e2f
DEBUG:fido2.hid:RECV: ffffffff8600114859dd5c0a590e2f00000001020100000500000000000000000000000000000000000000000000000000000000000000000000000000000000
DEBUG:fido2.hid:SEND: 0000000190000104
DEBUG:fido2.hid:RECV: 00000001900001f20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Traceback (most recent call last):
  File "./tools/configure.py", line 204, in <module>
    main(parser.parse_args())
  File "./tools/configure.py", line 134, in main
    for authenticator in tqdm(get_opensk_devices(args.batch)):
  File "./tools/configure.py", line 72, in get_opensk_devices
    return [ctap2.CTAP2(dev)]
  File "/Users/gaofeng/.pyenv/versions/3.8.8/lib/python3.8/site-packages/fido2/ctap2/base.py", line 643, in __init__
    self._info = self.get_info()
  File "/Users/gaofeng/.pyenv/versions/3.8.8/lib/python3.8/site-packages/fido2/ctap2/base.py", line 695, in get_info
    return self.send_cbor(Ctap2.CMD.GET_INFO, parse=Info)
  File "/Users/gaofeng/.pyenv/versions/3.8.8/lib/python3.8/site-packages/fido2/ctap2/base.py", line 675, in send_cbor
    raise CtapError(status)
fido2.ctap.CtapError: CTAP error: 0xF2 - UNKNOWN

If I checkout code to develop branch, after step 3, nrf52840 usb dongle behaves like

https://user-images.githubusercontent.com/10238809/126742034-fdf49cec-d0c0-4173-aeb3-64b33207f636.mp4

Even if I perform ./deploy.py --board=nrf52840_dongle_dfu --erase_storage --programmer=nordicdfu before step 3, behavior is same.

What's the matter?

Steps to Reproduce the Problem

1. ./reset.sh
2. ./setup.sh
3. ./deploy.py --board=nrf52840_dongle_dfu --opensk --programmer=nordicdfu
Have switched nrf52840 usb dongle to bootloader mode.
4. ./tools/configure.py \
    --certificate=crypto_data/opensk_cert.pem \
    --private-key=crypto_data/opensk.key

on either stable or develop branch.

Expected Behavior

Holding button while plugging to computer enter UF2 flash mode ( ie presenting a mass storage device to the host )

Actual Behavior

Holding button while plugging to computer does nothing

Steps to Reproduce the Problem

1. generate firmware with ./deploy.py --board=nrf52840_mdk_dfu --programmer=none --opensk
2. convert hex file to uf2 with uf2conv.py firmware.hex -c -f 0xADA52840
3. flash by copying the resulting uf2 file to the mass storage device presented.

Specifications

• Version: b0c1b73897816edb757a163943f7b36a55f76a19
• Platform: linux

Comments/Questions

Apologies if I missed something, I chose nrf52840_mdk_dfu as the board since it was the only one mentioning mdk and I tried before nrf52840_dongle but the button was not recognized ( I was able though to enter UF2 mode with that firmware flashed ).

The dongle works perfectly as is, webauthn.io test is successful. I just can't set it back to bootloader mode to flash or update something else. Just want to confirm I need a debugger probe at that point to be able to update opensk and/or change the firmware running at that point. Thank you in advance for your pointers.

Expected Behavior

　　After successfully generating the residential ssh keys by ssh-keygen -t ecdsa-sk -O resident, the private key should can be load to another computer via the OpenSK devices by ssh-add -K, but it failed to load.

Actual Behavior

　　Generation step on residental key seems to be successful, but when I tried to load the key to anthoer PC, by pluging in the OpenSK device and ssh-add -K, it shows Enter PIN for authenticator: Provider "internal" returned failure -1 Unable to load resident keys: invalid format 　　(the PIN was set correctly.) 　　After enable verbose mode by ssh-add -K -v, it shows Enter PIN for authenticator: debug1: start_helper: starting /usr/lib/ssh/ssh-sk-helper debug1: sshsk_load_resident: provider "internal", have-pin debug1: sk_probe: 1 device(s) detected debug1: sk_probe: selecting sk by touch debug1: ssh_sk_load_resident_keys: trying /dev/hidraw5 debug1: check_sk_options: option uv is unknown debug1: read_rks: get metadata for /dev/hidraw5 failed: FIDO_ERR_MISSING_PARAMETER debug1: ssh_sk_load_resident_keys: read_rks failed for /dev/hidraw5 Provider "internal" returned failure -1 debug1: ssh-sk-helper: sshsk_load_resident failed: invalid format debug1: main: reply len 8 debug1: client_converse: helper returned error -4 Unable to load resident keys: invalid format 　　which makes me confused.

Steps to Reproduce the Problem

1. Generate a pair of residental ssh key by ssh-keygen -t ecdsa-sk -O resident.
2. Plug the OpenSK device to another PC.
3. Try to load the key generated to that PC ssh-add -K -v

Specifications

• Device: Nordic nRF52840 Dongle
• Version: c6d3f51 of develop branch
• Platform: Arch Linux

　　I would appreciate it if you could do me a favour to solve that problem. Looking forward to your reply on your earliest convenience.

Fixes #335

This PR uses external ed25519-dalek crate for crypto implementation, which lead to several changes I'd like to get feedback on:

1. ed25519-dalek requires Rust 2021. For that, I've made some changes to third-party/libtock-rs submodule, which are commited in https://github.com/egor-duda/libtock-rs/tree/ed25519. They change rust-toolchain channel to nightly-2021-10-21 and update asm code to use numbered labels due to enabled #[deny(named_asm_labels)].
2. This change also causes new warnings about llvm_asm! macro being deprecated, and I don't know ARM assembly that well to be able to properly migrate from llvm_asm! to asm!. As a temporary workaround, I've removed -D warnings in deploy.py
3. Crypto structs in ed25519-dalek do not implement Clone and Eq, so instead of deriving those traits for PrivateKey, I've implemented them explicitly. Not sure if that is correct way to do that.

I've added --with-ed25519 option to deploy.py, and tested on nrf52840_dongle with openssh (ssh-keygen -t ed25519-sk) with PIN both enabled and disabled. I'm not sure is there is some webauthn test site which allows selecting specific crypto algorithm, would appreciate any pointers.

Currently, after you flash a new firmware to OpenSK, existing PIN/credentials (resident or non-resident) are still valid, you can still use them to authenticate to online services.

Should OpenSK clear all existing Credentials(resident or non-resident), PIN and other security parameters if it has been updated to the new firmware?

Expected Behavior

Before (include) 2e419fe77b37255778fe13166cdc891caee3b334, when insert nRF52840 USB dongle to USB port, LEDs are off. When receiving CTAP2/U2F command, LEDs will blink and wait for user presence. After user press the button, it response correctly.

Actual Behavior

Now (after 2e419fe77b37255778fe13166cdc891caee3b334), after insert to USB port, LEDs are blinking even if it is in idle. OpenSK does not work after user presses button.

Steps to Reproduce the Problem

1. Download firmware to nRF52840 dongle as usual.
2. Replug it to USB port, take a look at the LED status, they are blinking, different from before.
3. Test it on https://webauthn.io/ or other test website.
4. Make credential and press button.

I tested source code from 752bf47ed5caa2265e1d3884a40798fd7a2e95d6 to latest. It has same behavior.

Expected Behavior

This board on aliexpress NRF52840 moduł RF E104-BT5040U

Actual Behavior

Wsl doesn't recognize DFU mode. I was pressed resset and was plug into usb. I trying with VirtualBox with xubuntu ans WSL also and result is the same.

• Platform: DFU

Despite I know ESP32-C3/C2 is magnitude slower than nRF52840, but I want to port this there. Right now OpenSK seems like very centric to nRF52840, but I guess this can be traded with time. There is one thing about ESP32-C3/C2 though, that they don't have official atomic support, and I believe changing it to use atomic_polyfill can have some, say like timing consequences. Wonder if we can make something relaxed so we can port things easier?

Multiple vulnerabilities resulting in out-of-bounds writes

| Details | | | ------------------- | ---------------------------------------------- | | Package | linked_list_allocator | | Version | 0.8.11 | | URL | https://github.com/advisories/GHSA-xg8p-34w2-j49j | | Date | 2022-09-07 | | Patched versions | >=0.10.2 |

• The heap initialization methods were missing a minimum size check for the given heap size argument. This could lead to out-of-bound writes when a heap was initialized with a size smaller than 3 * size_of::<usize> because of metadata write operations.
• When calling Heap::extend with a size smaller than two usizes (e.g., 16 on x86_64), the size was erroneously rounded up to the minimum size, which could result in an out-of-bounds write.
• Calling Heap::extend on an empty heap tried to construct a heap starting at address 0, which is also an out-of-bounds write.
  • One specific way to trigger this accidentally is to call Heap::new (or a similar constructor) with a heap size that is smaller than two usizes. This was treated as an empty heap as well.
• Calling Heap::extend on a heap whose size is not a multiple of the size of two usizes resulted in unaligned writes. It also left the heap in an unexpected state, which might lead to subsequent issues. We did not find a way to exploit this undefined behavior yet (apart from DoS on platforms that fault on unaligned writes).

See advisory page for additional details.

Expected Behavior

Compiling OpenSK should work fine on platforms like aarch64-apple-darwin (e.g. with cargo build --features std)

Actual Behavior

Compiling with the pinned toolchain from libtock-rs causes linking errors on aarch64-apple-darwin. I assume that rust support for apple silicon chips was not ready yet at this point.

Steps to Reproduce the Problem

1. Run cargo build --features std on aarch64-apple-darwin and observe the following C++ linking errors (watch out, very long).

Compiling libtock_core v0.1.0 (/Users/yk/Documents/Coding/opensk_fork/third_party/libtock-rs/core) error: linking with cc failed: exit status: 1 | = note: "cc" "-arch" "arm64" "-L" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.0.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.1.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.10.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.11.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.12.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.13.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.14.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.15.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.2.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.3.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.4.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.5.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.6.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.7.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.8.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.9.rcgu.o" "-o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.3hj9l8a3kvh4kb7e.rcgu.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/yk/rust-artifacts/debug/deps" "-L" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd-c74e6b3de522962e.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-c93ea4d419dae922.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libobject-d002150646c82cc7.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libaddr2line-08d0962d65625914.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libgimli-19ddd96688ea0319.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd_detect-d8646d3f69dbb0b4.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_demangle-53d2a1a1245eee83.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libhashbrown-66a22362d0e1778d.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_alloc-ad006e595a77ae48.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libunwind-0d9b6902b79f5775.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcfg_if-b94ae0abe03da051.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liblibc-e1883bf629bf5f4b.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liballoc-43a6bd8ab40401f6.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_core-309925a076418223.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcore-4ce201db55ae746f.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcompiler_builtins-226f06aaeebfc929.rlib" "-lSystem" "-lresolv" "-lc" "-lm" "-liconv" = note: ld: in /Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-c93ea4d419dae922.rlib(lib.rmeta), archive member 'lib.rmeta' with length 35728 is not mach-o or llvm bitcode file '/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-c93ea4d419dae922.rlib' for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

Possible Solution

Updating the pinned nightly toolchain to a later version like 2021-06-25 and hence updating the specified submodule. With simple overwriting I found out that for example nightly 2021-05-25 does not seem to work yet but the June version one month later indeed does (meaning the above compile command passed without any errors).

Since the toolchain is propagated through the libtock-rs version we need to be careful not break any (runtime) functionality with later versions.

I found a couple of bugs while reviewing the OpenSK APDU parser, because while writing a FIDO client library, I noticed many FIDO implementations have buggy ISO 7816 implementations. I haven't run this on "real hardware" to try it out properly.

1. APDU parser does not handle extended form with N_c = 0 and N_e > 0 ("Case 2E"). It would error out with WRONG_LENGTH.

   Example request, where N_c = 0 and N_e = 0x1234:

   CLA INS P1 P2 0x00 0x12 0x34
   

   U2F GET_VERSION is impacted by this, other U2F commands and CTAP2 (over an ISO 7816 transport) always have command payloads.

   The parser appears to only handle "Case 2S" (short form N_c = 0 and N_e > 0), but supporting extended form is required for all transports, and supporting short form is only required over NFC.

2. APDU parser accepts malformed 3 byte L_c + 3 byte L_e.

   Per ISO 7816-4:2005 Section 5.1 (Command-response pairs), when N_c > 0 and N_e > 0 and using extended form ("Case 4E"), the correct representation is:

   CLA INS P1 P2 0x00 {Nc as uint16_be} {command bytes} {Ne as uint16_be}
   

   The implementation here appears to also incorrectly accept malformed requests of the form:

   CLA INS P1 P2 0x00 {Nc as uint16_be} {command bytes} 0x00 {Ne as uint16_be}
   

   The only reason L_e should be prefixed with 0x00 is if the L_c field is absent and L_e is in extended form ("Case 2E").

   Accepting malformed requests can cause implementers "testing against OpenSK" to make mistakes which are only exposed when testing with another FIDO implementation which follows ISO 7816 correctly. I've already seen subtle differences in existing FIDO certified devices with malformed inputs.

Note: "Case 2E", "Case 2S" and "Case 4E" references to ISO 7816-3:2006 section 12.1.3 (Decoding conventions for command APDUs); S = short form, E = extended form.

Case | Command Data Field | Response Length Field | Total length ----- | ------ | ---- | ----- Case 1 | None | None | 4 bytes Case 2S | None | Present (1 byte) | 5 bytes Case 2E | None | Present (3 bytes) | 7 bytes Case 3S | Present (1 byte) | None | 5 + (command data length) bytes Case 3E | Present (3 bytes) | None | 7 + (command data length) bytes Case 4S | Present (1 byte) | Present (1 byte) | 6 + (command data length) bytes Case 4E | Present (3 bytes) | Present (2 bytes) | 9 + (command data length) bytes

Hi,

I am hoping to do some work based on OpenSK but am having some difficulty getting the debug printouts to work. Is there something that I am missing in this process?

When I use an unmodified (non-opensk) version of tock, I am able to see the "Initialization complete. Entering main loop'" printout as well as extra printouts made by userspace apps (such as the libtock-c button-print example). Using OpenSK, when I do not have the OpenSK connected to my computer via the USB peripheral cable, I can see this message as well as an explicit print statement that I added in the main loop. When I have the USB peripheral cable connected, I cannot see any of these printouts.

edit: I am now thinking that the issue may be just that pressing the reset button (even without the peripheral usb attached) stops the console writes from showing up. Is this expected behavior?

Expected Behavior

When I start a server in one terminal with:

JLinkExe -device nrf52 -if swd -speed 1000 -autoconnect 1

And a client in another with:

JLinkRTTClient

and then deploy opensk to my board with:

./deploy.py --board=nrf52840dk --opensk --debug --panic-console

I see the Tock initialization printout and additional opensk debug output when going through an example setup flow.

Actual Behavior

There is no output in the RTT terminal beyond the following when the peripheral USB cable is connected and after pushing the reset button to connect:

SEGGER J-Link V7.80b - Real time terminal output
J-Link OB-nRF5340-NordicSemi compiled Dec  3 2021 15:46:49 V1.0, SN=1050271190
Process: JLinkExe

When the peripheral USB cable is not connected, I can see other outputs but cannot see debug print statements (though this could be because I am not able to initiate an authentication flow without the second USB connected)

Steps to Reproduce the Problem

As above.

Specifications

• Version: stable branch 1b70583
• Platform: x1 carbon gen 6 running manjaro linux