During the Toybox port to NuttX, Claude noticed that changes in the
menuconfig weren't taking affect. This issue exists for a long time on
NuttX, in fact BayLibre's presentation from 2017 make jokes about our
building system not been reliable:
https://www.youtube.com/watch?v=XUJK2htXxKw&t=320s
Stale archive members from $(AR)'s additive-only behavior can linger
after Kconfig toggles change which files provide a symbol, causing dead
weight or "multiple definition" link errors on incremental builds.
Fixed by splitting ARCHIVE into two macros: ARCHIVE keeps the original
additive behavior for apps/libapps.a, which many independent
subdirectories contribute to across a build, while the new
ARCHIVE_REBUILD deletes then archives for the far more common case
of a single Makefile building its own self-contained $(OBJS)
- all 39 such call sites now use it.
Assisted-By: Claude Sonnet 5
Signed-off-by: Alan C. Assis <acassis@gmail.com>
The existing CRYPTO_AES_CTR is the RFC 3686 profile: the last 4 bytes of
the key are a nonce, the IV is 8 bytes and only the low 32 bits of the
counter block are incremented. SSH aes128/192/256-ctr (RFC 4344) instead
uses the key as-is (no embedded nonce) and treats the whole 16-byte IV as
the initial counter block, incremented as a 128-bit big-endian integer,
with the first keystream block being E(IV).
Add CRYPTO_AES_CTR_SSH as a new enc_xform mirroring the CRYPTO_CHACHA20_DJB
addition. It reuses struct aes_ctr_ctx and the AES block; only setkey (full
key, no nonce), reinit (full 16-byte counter) and crypt (encrypt-then-
increment over all 16 bytes) differ from the RFC 3686 variant.
Keystream validated against `openssl enc -aes-128-ctr`, including a counter
that carries across byte boundaries and a non-block-aligned tail.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Description:
In kernel builds, any unprivileged process running on the NuttX device
can open /dev/efuse and attempt to read/write fuse content. Reading the
fuses may provide valuable information to an attacker controlling the user
process. The write operation, in extreme cases where the fuse blocks are
not locked, may brick the device.
This is part of https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
CRYPTO_CHACHA20 implements the RFC 8439/IETF parameterization (32-bit
counter + 96-bit nonce). SSH's chacha20-poly1305@openssh.com uses the
original DJB construction instead: a 64-bit block counter in state
words 12..13 and a 64-bit nonce in words 14..15 (libtomcrypt's
chacha_ivctr64). The two layouts produce different keystreams for the
same key, so an SSH server cannot interoperate with OpenSSH clients
through the IETF variant.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Expose the ChaCha20 stream cipher and the ChaCha20-Poly1305 AEAD through
the OCF crypto framework (/dev/crypto) so applications such as an SSH
server (chacha20-poly1305) can use them directly, and fix the underlying
ChaCha nonce/counter layout so both match RFC 8439.
RFC 8439 nonce layout fix
-------------------------
chacha_ivsetup() previously used the original DJB layout: a 64-bit block
counter (input[12..13]) followed by a 64-bit nonce (input[14..15]). RFC
8439 defines a 32-bit block counter (input[12]) and a 96-bit / 12-byte
nonce (input[13..15]). With the old layout the existing ChaCha20-Poly1305
AEAD could not reproduce the RFC 8439 test vectors (the last 4 bytes of a
12-byte nonce were consumed as the high half of the counter). This
commit switches chacha_ivsetup() to the RFC 8439 layout and updates the
ChaCha20-Poly1305 one-shot helpers to pass a 12-byte nonce accordingly.
Standalone ChaCha20 on the unified enc path
-------------------------------------------
Instead of introducing a separate multi-buffer stream path (parallel
encrypt_multi/decrypt_multi callbacks), extend the existing enc_xform
encrypt/decrypt callback signature with a length argument:
void (*encrypt)(caddr_t, FAR uint8_t *, size_t len);
void (*decrypt)(caddr_t, FAR uint8_t *, size_t len);
With that single change every cipher, block or stream, flows through the
same swcr_encdec path. swcr_encdec already handles a short final block
via buflen = MIN(i, blocksize), so arbitrary-length data works without a
second code path. This is exactly how the existing stream ciphers
(AES-CTR/OFB/CFB) already behave: the cipher keeps its own counter in the
context and swcr_encdec feeds it whole blocks (only the last one may be
shorter). chacha20_crypt likewise relies on the underlying chacha state
block counter (input[12]) to continue the keystream across calls, so no
per-call keystream caching is needed.
* chacha_private.h: chacha_ivsetup uses a 4-byte counter and a 12-byte
nonce (RFC 8439).
* chachapoly.c / chachapoly.h: split reinit into chacha20_reinit (raw,
counter 0) and chachapoly_reinit (AEAD, counter 1); chacha20_crypt
takes a length and encrypts it in one pass, mirroring aes_ctr_crypt;
12-byte nonce for the one-shot AEAD helpers.
* xform.h / xform.c: add size_t len to encrypt/decrypt; add
enc_xform_chacha20 (blocksize 64, 12-byte IV).
* cryptodev.c / cryptosoft.c: register CRYPTO_CHACHA20 as a txform
cipher, route new sessions to enc_xform_chacha20, feed the AEAD AAD
through crp_aad/crp_aadlen, and handle the short final block in
swcr_encdec.
* cryptodev.h: add CRYPTO_CHACHA20; bump EALG_MAX_BLOCK_LEN to 64.
This keeps all ciphers on one uniform path instead of maintaining two,
and any future stream cipher drops in with just an xform table entry.
Impact: extends an internal kernel callback signature (enc_xform
encrypt/decrypt). All in-tree implementations are updated in the same
commit and the user-facing /dev/crypto ABI is unchanged, so this is
self-contained and not a breaking change for existing configurations.
Testing:
Build host: Ubuntu Linux x86_64, GCC (host sim toolchain)
Target: sim:crypto (CONFIG_ARCH=sim)
Ran the crypto test apps. ChaCha20 uses RFC 8439 2.4.2 vectors
(including a 375-byte multi-block vector exercising cross-block counter
continuity); ChaCha20-Poly1305 uses the RFC 8439 2.8.2 AEAD vector.
A full regression of the other ciphers was run to confirm the extended
encrypt/decrypt signature does not change their behaviour:
nsh> chacha20
chacha20: 2/2 vectors passed
nsh> chachapoly
OK test vector 0
chachapoly: 1/1 vectors passed
nsh> des3cbc -> all vectors OK
nsh> aescbc -> all vectors OK
nsh> aesctr -> all vectors OK
nsh> aesxts -> 14 vectors OK (encrypt + decrypt)
nsh> hmac -> md5 / sha1 / sha256 all success
Signed-off-by: makejian <makejian@xiaomi.com>
Since already have support for SHA2-224, extend cryptodev/cryptosoft
to support HMAC version of SHA2-224.
Signed-off-by: Peter Barada <peter.barada@gmail.com>
Now that time_t is unconditionally 64-bit (signed int64_t) and the
struct timespec fields tv_sec / tv_nsec are wide enough on their own,
the explicit (uint64_t)/(int64_t)/(int) casts that used to guard the
multiplications and subtractions in *_us / *_ms / *_ns helpers are no
longer needed. Drop them to keep the timekeeping math readable and
consistent with the previous sclock_t/time_t cleanup.
In the same spirit, this commit also:
* Normalises the printf-style format specifiers and casts used to
print tv_sec / tv_nsec / tv_usec values across arch/, drivers/,
fs/, sched/ and libs/. The prior code was a mix of
"%d"/"%u"/"%ld"/"%lu"/"%lld"/PRIu32/PRIu64 with matching
(int)/(unsigned long)/(long long)/PRIu* casts; some formats
truncated time_t on 32-bit hosts, others mismatched signedness or
width. Replace all such cases with the portable POSIX-recommended
forms:
- tv_sec (time_t, signed, impl-defined width) -> %jd + (intmax_t)
- tv_nsec (long, signed) -> %ld (no cast)
- tv_usec (suseconds_t / long) -> %ld (no cast)
Add #include <stdint.h> where required.
* Drops a few stale `(FAR const time_t *)&ts.tv_sec` casts and
related `(FAR struct tm *)` / `(const time_t *)` casts in
gmtime_r() / localtime_r() / gmtime() callers; ts.tv_sec is plain
time_t now and the casts only obscured the type.
* Fixes one overflow in fs/procfs/fs_procfscritmon.c where
all_time.tv_sec * 1000000 could overflow on 32-bit time_t before
being multiplied again; cast to uint64_t at the start.
No behavioural change.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
This commit modularizes the curve25519 and idgen implementations in the
crypto subsystem.
Previously, curve25519.c and idgen.c were only compiled when
CONFIG_CRYPTO_RANDOM_POOL was enabled. However, cryptosoft.c (used by
software cipher support) has a direct dependency on curve25519 functions.
This caused linker errors (undefined reference to curve25519) when
software crypto was enabled but the random pool was disabled.
Changes:
- Introduce hidden Kconfig options CRYPTO_CURVE25519 and CRYPTO_IDGEN.
- Make CRYPTO_RANDOM_POOL select both CRYPTO_IDGEN and CRYPTO_CURVE25519.
- Make CRYPTO_CRYPTODEV_SOFTWARE_CRYPTO/KEYMGMT select CRYPTO_CURVE25519.
- Update CMakeLists.txt and Makefile to use the new config flags.
This ensures that required algorithms are automatically included in the
build regardless of whether the entropy pool is enabled.
Signed-off-by: karaketir16 <osmankaraketir@gmail.com>
This adds support for PBKDF2 (SHA1 and SHA256) while leveraging
the existing infrastructure for HMAC.
Signed-off-by: Vlad Pruteanu <pruteanuvlad1611@yahoo.com>
Intermediate files of make depend like .ddc and .dds may remain
when make is interrupted. Remove them using make distclean.
Signed-off-by: SPRESENSE <41312067+SPRESENSE@users.noreply.github.com>
When using a key that is longer than the block size of the hashing
algorithm used, the key must be hashed before it is used.
Signed-off-by: Vlad Pruteanu <pruteanuvlad1611@yahoo.com>
When a key is successfully exported, the return value should reflect the actual length of the exported key data.
Signed-off-by: makejian <makejian@xiaomi.com>
Add support for generating AES keys (128/192/256 bits) using the software key management backend.
The generated keys are random numbers produced by the system PRNG.
Signed-off-by: makejian <makejian@xiaomi.com>
This patch adds support for managing cryptographic keys using MTD storage.
It enables the persistence of keys across reboots using a software-based key management system.
Includes fixes for compilation warnings and validation logic.
Signed-off-by: makejian <makejian@xiaomi.com>
The callback parameters are currently passed in by the upper layer, so the release process in close should not be performed here.
This prevents double-free issues and ensures proper resource management.
Signed-off-by: makejian <makejian@xiaomi.com>
Fix incorrect memory management for asynchronous process callbacks.
Ensure callback memory is self-managed to prevent leaks or use-after-free issues.
Signed-off-by: makejian <makejian@xiaomi.com>
Fix issue where input buffer pointer was modified during crypto operations.
Ensures original buffer pointer remains valid for the caller.
Signed-off-by: makejian <makejian@xiaomi.com>
Add support for exporting RSA operations with PKCS#1 v1.5 and PSS padding schemes through the cryptodev interface.
This enables both traditional and modern RSA signature schemes:
- CRK_RSA_PKCS15_SIGN/VERIFY for PKCS#1 v1.5 padding
- CRK_RSA_PSS_SIGN/VERIFY for PSS padding
Signed-off-by: makejian <makejian@xiaomi.com>
1. p.x uninitialized in line 1643
2. l_public.y uninitialized in line 1579
3. l_public.y uninitialized in line 1533
Signed-off-by: makejian <makejian@xiaomi.com>
After adding the cross-core crypto driver, there are now three encryption modes:
1. Hardware driver in local core
2. Crypto driver in remote core
3. Software encryption in local core
This prioritizes local hardware driver first, then remote driver (typically hardware),
and finally local software encryption as a fallback.
Signed-off-by: makejian <makejian@xiaomi.com>
Replace dynamic memory allocation with stack-based variables in cryptodev_op().
This eliminates kmm_malloc/kmm_free overhead and simplifies error handling
by removing the need for goto bail cleanup paths.
Signed-off-by: makejian <makejian@xiaomi.com>
Add ivlen field to crypt_op and crp_ivlen to cryptop structure to support
cipher algorithms with different IV lengths.
Signed-off-by: makejian <makejian@xiaomi.com>
Add olen field to crypt_op structure and crp_olen to cryptop structure
to support output length tracking in virtio crypto mode.
Signed-off-by: makejian <makejian@xiaomi.com>
Rename siphash related symbols to avoid conflicts with compiler-generated
section names. Tricore-gcc produces function sections with '_end' suffix,
which conflicts with siphash_end symbol.
Signed-off-by: makejian <makejian@xiaomi.com>
Add support for storing driver-specific private data in the crypto
driver structure. This allows crypto drivers to maintain session
state and other driver-specific information.
Signed-off-by: makejian <makejian@xiaomi.com>
Replace the non-standard howmany macro with the common div_round_up macro
for consistency and better code maintainability.
Signed-off-by: makejian <makejian@xiaomi.com>
Add key management interfaces and support for generating key pairs in RSA and ECDSA cryptographic processes to the cryptodev module.
Signed-off-by: makejian <makejian@xiaomi.com>
Extend AES-CBC algorithm support to include 192-bit and 256-bit key sizes in addition to the existing 128-bit support. This enables broader compatibility with cryptographic standards and provides applications with additional key length options for enhanced security requirements.
Signed-off-by: makejian <makejian@xiaomi.com>
According to the feedback from SPDX community we should use
LicenseRef-NuttX-PublicDomain because NuttX-PublicDomain
is not a valid SPDX id, so it will fail tests for SPDX spec compliance.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
"hmac" was mistyped as "hmca", breaking linking to some prototype
functions. Also, a couple of includes were missing.
Signed-off-by: Niccolò Maggioni <nicco.maggioni+nuttx@gmail.com>
This patch is a rework of the NuttX file descriptor implementation. The
goal is two-fold:
1. Improve POSIX compliance. The old implementation tied file description
to inode only, not the file struct. POSIX however dictates otherwise.
2. Fix a bug with descriptor duplication (dup2() and dup3()). There is
an existing race condition with this POSIX API that currently results
in a kernel side crash.
The crash occurs when a partially open / closed file descriptor is
duplicated. The reason for the crash is that even if the descriptor is
closed, the file might still be in use by the kernel (due to e.g. ongoing
write to file). The open file data is changed by file_dup3() and this
causes a crash in the device / drivers themselves as they lose access to
the inode and private data.
The fix is done by separating struct file into file and file descriptor
structs. The file struct can live on even if the descriptor is closed,
fixing the crash. This also fixes the POSIX issue, as two descriptors
can now point to the same file.
Signed-off-by: Ville Juven <ville.juven@unikie.com>
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
NOTE
The code was reported as GPL by FOSS ID
and Xiaomi scanned the file xform.c with Black Duck Security and it showed
that the license was BSD-3-Clause and no risk was reported.
Since there is no clause on the license it was concluded as 0BSD
Refference
https://github.com/apache/nuttx/pull/15252
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
define NuttX local NuttX-PublicDomain identifier
“Public Domain” is a concept distinct from copyright licensing;
it generally means that the work no longer has any copyright protection
or ownership, and therefore requires no license permission in order to
use, copy, modify, distribute, perform, display, etc.
In the United States – and many jurisdictions – copyright protections
attach automatically to creative works upon creation if they satisfy
certain minimum criteria.
“Public Domain” would thus represent a significant change to the legal
status of the work.
The rules around “Public Domain” often vary or are unspecified
jurisdiction to jurisdiction. Adding to the confusion, some
jurisdictions may not even recognize the concept of “Public Domain”
(or similar). As such, a license may nevertheless be required or implied
in these cases. Even in the U.S., there is no clear,
officially-sanctioned procedure for affirmatively placing
copyright-eligible works into the “Public Domain” aside from natural
statutory expiration of copyright. The bottom-line is, there are few if
any objective, brightline rules for proactively placing
copyright-eligible works into the Public Domain that we can broadly
rely on.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
define NuttX local NuttX-PublicDomain identifier
“Public Domain” is a concept distinct from copyright licensing;
it generally means that the work no longer has any copyright protection
or ownership, and therefore requires no license permission in order to
use, copy, modify, distribute, perform, display, etc.
In the United States – and many jurisdictions – copyright protections
attach automatically to creative works upon creation if they satisfy
certain minimum criteria.
“Public Domain” would thus represent a significant change to the legal
status of the work.
The rules around “Public Domain” often vary or are unspecified
jurisdiction to jurisdiction. Adding to the confusion, some
jurisdictions may not even recognize the concept of “Public Domain”
(or similar). As such, a license may nevertheless be required or implied
in these cases. Even in the U.S., there is no clear,
officially-sanctioned procedure for affirmatively placing
copyright-eligible works into the “Public Domain” aside from natural
statutory expiration of copyright. The bottom-line is, there are few if
any objective, brightline rules for proactively placing
copyright-eligible works into the Public Domain that we can broadly
rely on.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
define NuttX local NuttX-PublicDomain identifier
“Public Domain” is a concept distinct from copyright licensing;
it generally means that the work no longer has any copyright protection
or ownership, and therefore requires no license permission in order to
use, copy, modify, distribute, perform, display, etc.
In the United States – and many jurisdictions – copyright protections
attach automatically to creative works upon creation if they satisfy
certain minimum criteria.
“Public Domain” would thus represent a significant change to the legal
status of the work.
The rules around “Public Domain” often vary or are unspecified
jurisdiction to jurisdiction. Adding to the confusion, some
jurisdictions may not even recognize the concept of “Public Domain”
(or similar). As such, a license may nevertheless be required or implied
in these cases. Even in the U.S., there is no clear,
officially-sanctioned procedure for affirmatively placing
copyright-eligible works into the “Public Domain” aside from natural
statutory expiration of copyright. The bottom-line is, there are few if
any objective, brightline rules for proactively placing
copyright-eligible works into the Public Domain that we can broadly
rely on.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
define NuttX local NuttX-PublicDomain identifier
“Public Domain” is a concept distinct from copyright licensing;
it generally means that the work no longer has any copyright protection
or ownership, and therefore requires no license permission in order to
use, copy, modify, distribute, perform, display, etc.
In the United States – and many jurisdictions – copyright protections
attach automatically to creative works upon creation if they satisfy
certain minimum criteria.
“Public Domain” would thus represent a significant change to the legal
status of the work.
The rules around “Public Domain” often vary or are unspecified
jurisdiction to jurisdiction. Adding to the confusion, some
jurisdictions may not even recognize the concept of “Public Domain”
(or similar). As such, a license may nevertheless be required or implied
in these cases. Even in the U.S., there is no clear,
officially-sanctioned procedure for affirmatively placing
copyright-eligible works into the “Public Domain” aside from natural
statutory expiration of copyright. The bottom-line is, there are few if
any objective, brightline rules for proactively placing
copyright-eligible works into the Public Domain that we can broadly
rely on.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
define NuttX local NuttX-PublicDomain identifier
“Public Domain” is a concept distinct from copyright licensing;
it generally means that the work no longer has any copyright protection
or ownership, and therefore requires no license permission in order to
use, copy, modify, distribute, perform, display, etc.
In the United States – and many jurisdictions – copyright protections
attach automatically to creative works upon creation if they satisfy
certain minimum criteria.
“Public Domain” would thus represent a significant change to the legal
status of the work.
The rules around “Public Domain” often vary or are unspecified
jurisdiction to jurisdiction. Adding to the confusion, some
jurisdictions may not even recognize the concept of “Public Domain”
(or similar). As such, a license may nevertheless be required or implied
in these cases. Even in the U.S., there is no clear,
officially-sanctioned procedure for affirmatively placing
copyright-eligible works into the “Public Domain” aside from natural
statutory expiration of copyright. The bottom-line is, there are few if
any objective, brightline rules for proactively placing
copyright-eligible works into the Public Domain that we can broadly
rely on.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
define NuttX local NuttX-PublicDomain identifier
“Public Domain” is a concept distinct from copyright licensing;
it generally means that the work no longer has any copyright protection
or ownership, and therefore requires no license permission in order to
use, copy, modify, distribute, perform, display, etc.
In the United States – and many jurisdictions – copyright protections
attach automatically to creative works upon creation if they satisfy
certain minimum criteria.
“Public Domain” would thus represent a significant change to the legal
status of the work.
The rules around “Public Domain” often vary or are unspecified
jurisdiction to jurisdiction. Adding to the confusion, some
jurisdictions may not even recognize the concept of “Public Domain”
(or similar). As such, a license may nevertheless be required or implied
in these cases. Even in the U.S., there is no clear,
officially-sanctioned procedure for affirmatively placing
copyright-eligible works into the “Public Domain” aside from natural
statutory expiration of copyright. The bottom-line is, there are few if
any objective, brightline rules for proactively placing
copyright-eligible works into the Public Domain that we can broadly
rely on.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
