Currently the 8-byte section is inserted under semi-random name like
.ARM.exidx.text._ZN50_$LT$T$u20$as$u20$core..convert..Into$LT$U$GT$$GT$4into17h79ccbc4bdfe3f200E.
This makes it hard to include it in _codelen that is later baked into
firmware header. This change adds new section because including it in
.flash causes linker error due to mixing "ordered" and "unordered"
sections.
By renaming .exidx to /DISCARD/ we'd drop this info, there may also
exist compiler flag to do that.
This is what the spec recommends and it has been the case before
workflow-restarts, when `apps.webauthn.fido2` was imported exactly once
per lifetime.
With workflow-restarts, `fido2` is being imported repeatedly and the
keys regenerated. This does not seem to be a problem per the spec -- a
FIDO workflow will retain the same keys, and non-FIDO workflows can be
seen as unplugs/replugs as far as the FIDO functionality is concerned.
However, regenerating the keys is slow, which is a problem for the
hardware-based unit tests. We can avoid the slowness by returning to the
spec-mandated behavior and generating once per power-up.
A small fixed list of modules is kept pre-loaded in the GC arena.
These must not keep references to anything else, as all other modules
are unloaded and the memory is cleared.
apps.webauthn.boot() does not need an if-condition because it's only
called from session.py when the usb interface is enabled
This means that they do not need to be stored in RAM at all. The obvious
drawback is that we need to hand-edit the if/elif sequence, but we don't
register new handlers all that often so 🤷
On a cleanly wiped device, storage must be unlocked in order to create
and retrieve the serial number. However, storage unlocking happens in
boot.py, which is imported _after_ usb.py
We must therefore sidestep asking for the serial number.
core: Remove dangling module decls
core: Use new Cargo feature resolver, use external MacOS debug info
core: Rust docs improvements
core: Upgrade bindgen
core: Add test target to Rust
ci: build rust sources
build(core): .ARM.exidx.text.__aeabi_ui2f in t1 firmware size
It's an unwind table for softfloat function inserted by rustc, probably
can be removed to save 8 bytes:
599c58db70/link.x.in (L175-L182)
scons: Remove dead code
core: Move Rust target to build/rust
core: Replace extern with a FFI version
core: Add some explanatory Rust comments
core: Use correct path for the Rust lib
core: Remove Buffer::as_mut()
Mutable buffer access needs MP_BUFFER_WRITE flag. TBD in the Protobuf PR.
core: Improve docs for micropython::Buffer
core: Minor Rust docs changes
core: Rewrite trezor_obj_get_ll_checked
core: Fix incorrect doc comment
core: Remove cc from deps
fixup! core: Rewrite trezor_obj_get_ll_checked
core: update safety comments
Add two new input and four output script types.
Decred ticket purchases consist of a stake submission, op returns, and
change addresses. Although change addresses are allowed by consensus,
they are no longer used in practice and so have been given the
restrictions of a null pubkey and no value. Stake scripts are almost
identical to p2pkh or p2sh except for an extra opcode in front. Inputs
are currently only used in the form of one input three outputs with the
first output, or stake submission, paying to a public key hash, or with
two inputs and five outputs with the stake submission paying to a
multisig script hash. The op returns are directed to the user in the
case of one and the voting service provider and user in the case of two.
One of the sstx commitment for a ticket must pay back to the trezor
wallet. This is checked and an error is thrown if we don't find the
expected public key hash.
Because this adds the ability to create new types of outputs once the
ticket votes, two new input script types are also needed. A successful
vote will lead to a stake generation script that must be spent, and an
unsuccessful vote will lead to a revocation script that must be spent.
If we allowed stake change scripts to have a valid pubkey, that too
would require another op code, but we disallow those for output.
using define causes compiler to over-optimize the code in display_init_seq
leading to larger differences in the resulting binaries when the flag changes
we want to keep the difference to minimum (1 byte) and using const volatile
instead of define achieves that
