Crypto / SQLite / Codec Reachability Cuts

What this page is. Three negative reachability results, each one a clean cut a reimplementer can act on. The host Neuron runtime ships (or sits beside) a pile of general-purpose libraries — OpenSSL, SQLite, liblzma, libbz2, zlib — and the natural assumption is that a NEFF load exercises them: signature checks, attestation, a cache DB, multi-codec decompression. It does not. The GPSIMD load path touches exactly one of those libraries (zlib's inflate), and even that only on one packager version. The other four are linked-but-unreached or not even linked.

Every verdict below is a claim + the exact piped command + its count, run against the binary. The payoff for a reimplementer is spelled out once, up front: a GPSIMD host can SAFELY OMIT libcrypto, libssl, libsqlite3, liblzma and libbz2 and keep only a decompress-only zlib. Nothing on the nrt_load path will miss them.

Primary subject — the single 122 MB host runtime ELF that every Part-8 page dissects:

opt/aws/neuron/lib/libnrt.so.2.31.24.0   (SONAME libnrt.so.1)
122,956,336 B ; ELF64 x86-64 ; aws-neuronx-runtime-lib 2.31.24.0-0b044f4ce
BuildID[sha1] 8bb57aba0fb2e0035f1d88e9fc4fb3e7387c102e
sha256 956382de73f4cced5d9a0dc040ca82843fb37aef00d5bf2241f343ff02cd59a6
carries .symtab + .debug_info — symbol names below are REAL, not inferred.

BuildID and byte size were read with readelf -n / ls -l; both match. The page default is [HIGH × OBSERVED]; claims that depart from it carry an explicit tag.

See The libnrt Surface Map (GPSIMD lens) for the host link graph this page cuts down, and the package bibliography page (Bibliography of Source Binaries, appendix/bibliography-source-binaries.md) for provenance of the two packages that supply the binaries here.

0. The three cuts on one screen

Two physically distinct packages are in play; keep them apart:

• SURFACE A — host runtime. libnrt.so.2.31.24.0 from aws-neuronx-runtime-lib (opt/aws/neuron/lib/). This is the actual nrt_load path. The "does crypto/codec/sqlite run at NEFF load?" question is answered here.
• SURFACE B — customop SDK. c10/lib/{libcrypto,libssl,libsqlite3,liblzma,libz, libbz2}.so from aws-neuronx-gpsimd-customop-lib_0.21.2.0 — a PyTorch CustomOp build/link staging tree. The "linked-but-unreached" audit is answered here.

Both surfaces come out negative for live crypto and live sqlite; only zlib's inflate is live, and only on Surface A.

NOTE — what "GPSIMD load path" means for these cuts. The relevant entry is the public nrt_load@@NRT_2.0.0 (0xa9fe0) and everything it transitively reaches to stage a NEFF onto the device. The reachability claims are call-graph claims rooted at that entry, not whole-binary "is the symbol anywhere" claims — three of these libraries leave defined symbols in the ELF that are simply never called from nrt_load.

1. Cut #1 — libcrypto / libssl: the load path exercises NO cryptography

Claim. No attestation, no signature verification, no certificate check runs at NEFF load. libnrt.so is not linked against OpenSSL at all; the customop SDK's OpenSSL is consumed only by OpenSSL itself.

1.1 The DT_NEEDED set has no crypto edge

The complete dynamic-dependency set of the host runtime:

$ readelf -d libnrt.so.2.31.24.0 | rg 'NEEDED|SONAME|RUNPATH'
 (NEEDED)   libgcc_s.so.1
 (NEEDED)   libutil.so.1
 (NEEDED)   librt.so.1
 (NEEDED)   libpthread.so.0
 (NEEDED)   libdl.so.2
 (NEEDED)   libstdc++.so.6
 (NEEDED)   libm.so.6
 (NEEDED)   libc.so.6
 (NEEDED)   ld-linux-x86-64.so.2
 (SONAME)   libnrt.so.1
 (RUNPATH)  /opt/aws/neuron/lib

Nine NEEDED entries, all of them the C/C++ runtime. No libcrypto, no libssl. This nine-entry set is the canonical "TIER-1" host dependency list for libnrt.so and is the same set the codec cut (§2) and sqlite cut (§3) start from.

1.2 No crypto symbol is imported, statically or dynamically

$ nm -D --undefined-only libnrt.so.2.31.24.0 | rg -c '.'            -> 613   (total UND)
$ nm -D --undefined-only libnrt.so.2.31.24.0 | rg -c 'EVP_|SSL_|SHA|RSA_'  -> 0

613 undefined (imported) dynamic symbols; zero are crypto. The import-graph artifact agrees independently — parsing the 613-entry native_imports.json list for any EVP_/SSL_/RSA_/SHA/sqlite/inflate/... name yields 0 hits (see §4).

A whole-symtab scan for defined OpenSSL primitives is also empty once false-positives are removed:

$ nm libnrt.so.2.31.24.0 | rg -c '\bEVP_[A-Za-z]|\bSSL_[A-Za-z]|\bX509_|\bECDSA_|\bRSA_sign|\bRSA_verify|\bHMAC_[A-Za-z]|\bd2i_|\bPEM_'  -> 0

CORRECTION — grep precision. A naïve scan nm … | rg -c 'EVP_|RSA_|ECDSA|X509|HMAC_' returns 19 matches on this binary, not 0 — but every one of the 19 is a C++ mangled-name false positive: the Itanium substitution token …RSA_PSA_E… inside absl::btree_iterator<… basic_string…> and protobuf ExtensionSet symbols, plus nrt_config_parse. There is no real OpenSSL routine. The word-boundary scan above (\bEVP_[A-Za-z] etc.) is the correct query and returns 0. The "symbol search empty" verdict is right; this records the exact grep that proves it without the substring noise.

1.3 No dlopen escape hatch into crypto

A library can reach crypto without a NEEDED edge via dlopen()/dlsym(). Ruled out — every .so name the runtime can dlopen is EFA networking, collectives, firmware, or device-code glue:

$ strings libnrt.so.2.31.24.0 | rg '\.so$' | rg 'lib(fabric|nccom|ncfw|nrtucode|crypto|ssl|sqlite)'
 libfabric.so
 libnccom.so
 libnccom-net.so
 libncfw.so
 libnrtucode_extisa.so

libfabric (EFA), libnccom/libnccom-net (collectives), libncfw (device firmware), libnrtucode_extisa (the device-code host glue). No crypto, no sqlite, no codec target. The dlopen surface is mechanism-complete and negative.

1.4 The only hashing is a private, unkeyed MD5/SHA-256 — integrity, not authenticity

libnrt carries a hand-rolled (not OpenSSL EVP) MD5 + SHA-256, defined as local t symbols at the exact addresses below:

$ nm libnrt.so.2.31.24.0 | rg -w 'sha256_transform|sha256_init|sha256_update|sha256_final|MD5_Init|MD5_Update|MD5_Final|MD5_hash_str'
 5ca680 t sha256_transform   5caa40 t sha256_init    5caa70 t sha256_update   5cab20 t sha256_final
 5ca0e0 t MD5_Init           5ca100 t MD5_Update     5ca300 t MD5_Final       5ca5c0 t MD5_hash_str

These are unkeyed hashes — anyone can recompute them; they authenticate nothing. There is no AES/ChaCha/Poly1305/Curve25519/Ed25519/RSA/ECDSA/X509/HMAC code anywhere in the binary. They run from nrt_load → … → neff_parse (§2.4 has the exact chain) as a corruption/integrity compare — digest vs. a value stored in the NEFF header — and are gated on a per-load verify flag: when the flag is clear, the NEFF is extracted with no digest comparison.

GOTCHA — "signature" in libnrt is never cryptographic. The runtime is full of *_signature symbols (validate_rg_signature, calculate_hostcc_signature, enc_calculate_signature, calculate_src_target_pairs_signature, …). Every one is a collectives op-config fingerprint — an MD5 of the replica-group / op configuration, compared between peers to catch mismatched collectives ("failed signature check from peer … mismatched collectives between the peers"). No key, no asymmetric primitive. A reimplementer should not mistake any of these for an authentication routine.

There are no attestation/secure-boot/certificate strings either:

$ strings libnrt.so.2.31.24.0 | rg -ci 'RSA_verify|ECDSA_verify|EVP_DigestVerify|attest|secure[_ ]boot|measured[_ ]boot|sev-snp|nitro'  -> 0

CORRECTION (grep precision). A loose scan rg -ci 'x509|certificate|public key|attestation' returns 5 hits, all of which are mangled-name false positives (…_S_copy_chars…S7_, protobuf ExtensionSet…S7_). The narrow token scan above (real verify/attest/boot primitives) returns 0. No measured/secure boot, no TPM/Nitro/SEV-SNP attestation string exists.

1.5 Surface B — the customop SDK OpenSSL is self-referential

The SDK physically ships OpenSSL 1.1.1zb (11 Feb 2025): c10/lib/{libcrypto.so.1.1, libssl.so.1.1, engines-1.1/{afalg,padlock}.so}. Who NEEDs libcrypto? — only other parts of OpenSSL:

$ for so in <every .so in the customop tree>; do readelf -d "$so" | rg 'NEEDED.*libcrypto'; done
 afalg.so       NEEDS libcrypto.so.1.1     (OpenSSL engine plug-in)
 padlock.so     NEEDS libcrypto.so.1.1     (OpenSSL engine plug-in)
 libssl.so      NEEDS libcrypto.so.1.1     (OpenSSL itself)
 libssl.so.1.1  NEEDS libcrypto.so.1.1     (OpenSSL itself)

No GPSIMD customop library, ucode loader, driver or executable declares a NEEDED edge to libssl or libcrypto. Cross-checking the device-image loaders the customop runtime actually uses: libnrtucode.so DT_NEEDED is libc.so.6 only, and its UND set has zero crypto symbols (§3.2 re-uses this same query). OpenSSL here is a transitive PyTorch-bundle packaging artifact — present on disk, dead-code from the GPSIMD standpoint. [HIGH × OBSERVED; "why bundled" MED × INFERRED]

1.6 Verdict — Cut #1

The GPSIMD load-time trust chain does not exercise cryptography. On the host runtime, crypto is not even linked; on the customop SDK it is linked-but- unreached (self-referential OpenSSL). The only load-time hashing is an unkeyed, optional MD5/SHA-256 integrity compare — corruption detection, not a cryptographic trust operation. This is the import-edge + call-graph corroboration of the "no cryptographic root of trust" finding tracked by the Firmware Trust Chain + Threat Model page (control/security/trust-chain-threat-model.md). A reimplementer can omit libcrypto and libssl entirely and reimplement only the private MD5/SHA-256 (or skip even that, behind the same verify flag).

2. Cut #2 — codecs: zlib-only inflate, statically vendored

Claim. The runtime inflates NEFF payloads with zlib only. liblzma and libbz2 are absent in every sense. A decompress-only zlib 1.3.1 is statically compiled into libnrt.so; the single inflate consumer is libarchive's gzip filter, reached from nrt_load only on pkg_version==2 NEFFs.

2.1 No codec import edge — three independent negatives

$ readelf -d libnrt.so.2.31.24.0 | rg 'NEEDED'
   -> 9 NEEDED, NONE of libz/liblzma/libbz2/libarchive   (the same TIER-1 set, §1.1)

$ nm -D --undefined-only libnrt.so.2.31.24.0 | rg -c 'inflate|uncompress|BZ2_|lzma_'   -> 0
$ nm -D --undefined-only libnrt.so.2.31.24.0 | rg -c 'inflate|deflate|lzma_|BZ2_|archive_|uncompress|crc32|adler32|zlib|gz'  -> 0

No dynamic codec dependency, no codec UND symbol. The codec is not reached across a library boundary — it is compiled into libnrt.so.

2.2 Static codec inventory — zlib present (inflate-side), lzma/bz2 absent

$ nm libnrt.so.2.31.24.0 | rg -iw 'inflate|inflateInit2_|inflateInit_|inflateEnd|inflateReset|inflate_table|inflate_fast|crc32|adler32|zlibVersion'
 501060 t adler32        501d10 t crc32          5059e0 t zlibVersion
 502260 t inflate        5020d0 t inflateInit2_  5021c0 t inflateInit_
 501f90 t inflateReset   504490 t inflateEnd     504e60 t inflate_table   505a50 t inflate_fast

$ nm libnrt.so.2.31.24.0 | rg -c 'deflate|compress2|gzopen|gzread'   -> 0
$ nm libnrt.so.2.31.24.0 | rg -ci 'lzma_'   -> 0
$ nm libnrt.so.2.31.24.0 | rg -ci 'BZ2_'    -> 0
$ strings libnrt.so.2.31.24.0 | rg 'inflate 1.3.1'
 " inflate 1.3.1 Copyright 1995-2024 Mark Adler "       (NO deflate banner)

So the build is zlib 1.3.1, inflate-only — no deflate/compress2/gz* present. lzma and bz2 leave zero symbols. The only lzma/bz2/xz-shaped strings in the binary are the static libarchive filter-NAME enum labels (ARCHIVE_FILTER_BZIP2, etc.) baked into every libarchive build — name table, not code.

QUIRK — only the gzip filter is compiled into libarchive. libnrt vendors a minimal libarchive (329 archive_* symbols) with exactly one decompression filter registered:

$ nm libnrt.so.2.31.24.0 | rg 'archive_read_support_filter_'   -> only archive_read_support_filter_gzip (0x4d1f40)

No _bzip2/_xz/_lzma/_zstd/_lz4/_all filter backend is linked. This is the structural reason lzma/bz2 are absent: libarchive here can dispatch to nothing but the gzip filter, which calls zlib's inflate.

2.3 The inflate call site — gzip_filter_read @ 0x4d1c04

The codec edge proper lives in libarchive's gzip filter gzip_filter_read (0x4d1970). Ranged disassembly (objdump -d --start-address=0x4d1970 --stop-address=0x4d1e10), zlib calls in order:

 4d1b5f   call 0x501d10 <crc32>            ; gzip member CRC (trailer integrity)
 4d1b9c   call 0x5020d0 <inflateInit2_>    ; window-bits init for the gzip stream
 4d1c04   call 0x502260 <inflate>          ; <-- THE decompression call site
 4d1c33   call 0x504490 <inflateEnd>       ; teardown

Annotated reconstruction of the load-time inflate path (the codec consumer end of nrt_load):

/* gzip_filter_read @ 0x4d1970 — libarchive's gzip read-filter, the SOLE caller of
 * zlib's inflate in libnrt.so. Invoked lazily by the libarchive filter pipeline
 * each time a consumer pulls bytes (archive_read_data / archive_read_next_header)
 * from a stream whose bidder sniffed the 0x1f 0x8b gzip magic. */
static ssize_t gzip_filter_read(struct archive_read_filter *self,
                                const void **buff)
{
    struct private_data *state = self->data;
    /* ... pull compressed input window through libarchive's own buffering ... */
    avail_in = __archive_read_filter_ahead(self->upstream, 1, &read_avail); /* 0x4d1b3a */

    if (state->in_stream == 0) {              /* first call: parse gzip header */
        /* CRC over the just-consumed gzip member header bytes (trailer check) */
        state->crc = crc32(state->crc, p, header_len);              /* 0x4d1b5f */
        inflateInit2_(&state->stream, -15 /*raw,15-bit window*/,    /* 0x4d1b9c */
                      ZLIB_VERSION, sizeof(z_stream));
        state->in_stream = 1;
    }

    state->stream.next_in   = (Bytef *)compressed_window;
    state->stream.avail_in  = read_avail;
    state->stream.next_out  = state->out_block;
    state->stream.avail_out = state->out_block_size;

    ret = inflate(&state->stream, 0 /*Z_NO_FLUSH*/);               /* 0x4d1c04 */
    /* ... map Z_STREAM_END / Z_OK / error, advance CRC over the decompressed bytes,
     *     hand *buff back to the tar walker ... */
    if (ret == Z_STREAM_END /*member done*/)
        inflateEnd(&state->stream);                                /* 0x4d1c33 */
    __archive_read_filter_consume(self->upstream, consumed);       /* 0x4d1c26 */
    return decompressed_len;
}

Uniqueness of the codec edge (verified by ranged disassembly): inflate (0x502260) and inflateInit2_ (0x5020d0) each have exactly one caller — gzip_filter_read. There is no uncompress/gz* high-level wrapper; libarchive reaches the raw inflate API directly. So zlib has a single consumer (gzip_filter_read), and that filter has a single registrant (neff_parse, §2.4).

2.4 The inflate path is reached from nrt_load — only on pkg_version==2

Every edge below is a concrete call <target> read from the binary:

 nrt_load @0xa9fe0  (T, public NRT_2.0.0 API)
   0xaa0a2  call 0xa9920  nrt_load_util       (_Z13nrt_load_utilPKvmiPP9nrt_modelii)
     0xa9b62  call 0xde280  kmgr_load_nn_nc
       0xde4c4  call 0x4ca3f0  neff_parse      (call site #1)
       0xde6ca  call 0x4ca3f0  neff_parse      (call site #2)

neff_parse has exactly these two callers in the whole binary, both inside kmgr_load_nn_nc. Inside neff_parse (0x4ca3f0), the libarchive driver sequence:

 0x4ca58b  call archive_read_new
 0x4ca59d  call archive_read_support_format_tar
 0x4ca5a5  call archive_read_support_filter_gzip   <-- the ONLY caller of this symbol
 0x4ca5b3  call archive_read_open_memory(a, data, data_size)
 0x4ca61c  call archive_read_next_header           ; per-member loop head
 0x4ca756  call archive_read_data_skip             ; "...checksum" side-files
 0x4ca95a  call archive_read_data                  ; <-- triggers gzip_filter_read -> inflate
 0x4ca995  call archive_read_close   /  0x4ca99d  call archive_read_free

The gzip filter is registered up front (0x4ca5a5) but stays inert until a stream actually presents a gzip member: archive_read_open_memory installs the filter chain, gzip_bidder_bid sniffs the 0x1f 0x8b magic, and only then does gzip_filter_read decompress on each archive_read_data (0x4ca95a) pull. So the precise inflate site reached from nrt_load is:

neff_parse:0x4ca95a archive_read_data → gzip_filter_read:0x4d1c04 inflate.

The static edges are OBSERVED; the lazy-pull ordering (registered-but-bids-0 vs. bids-and-inflates) is INFERRED from the libarchive filter model. [edges HIGH × OBSERVED; pull ordering MED × INFERRED]

The pkg_version gate (from the decompiled neff_parse body, cross-checked):

• pkg_version==1 (raw-tar NEFF): the gzip filter is registered but bids 0, so inflate is never reached. Integrity, if the verify flag is set, is SHA-256.
• pkg_version==2 (gzip-tar NEFF): the inner archive is a gzip stream; gzip_filter_read → inflate runs per member. Integrity, if verified, is MD5.

So pkg_version is the runtime switch that arms or disarms the inflate path. See the NEFF Version / Compatibility Model page (neff/version-compat.md) for the pkg1/pkg2 container model this gates on.

2.5 Which NEFF section types are compressed — whole-archive, not per-section

The compression granularity is the whole inner archive, not individual sections:

• The NEFF container is [1024-B header][data_size bytes of inner archive].
• For pkg_version==2 the entire inner POSIX-pax tar (holding kelf-a.json, neff.json, sgNN/def.json, sgNN/{pe,act,dve,sp,pool}.{json,bin,asm}, ucode_lib.json, the *.npy weight/constant members, …) is a single gzip stream. neff_parse gunzips that one stream and walks the decompressed tar; every member is produced by the same gzip_filter_read → inflate pipeline.
• There is therefore no "section X is compressed, section Y is not": in pkg2 all members ride inside the one gzip stream; in pkg1 none do. The large constant tensors (*.npy weight members) are inside that gzip stream and inflated by the same single consumer; the runtime applies no second-stage codec to weights (no uncompress/lzma/bz2 anywhere). The ...checksum producer side-files are archive_read_data_skip'd — decompressed then discarded, not a separate codec. [single-gzip-stream facts HIGH × OBSERVED; weight-bin corollary MED × INFERRED]

2.6 Surface B + verdict — Cut #2

The customop SDK separately ships the full libz.so.1.3.1 (deflate+inflate banners both present — distinct from the inflate-only static copy inside libnrt), plus liblzma.so.5.4.1 and libbz2.so.1.0.8. Their consumer graph is empty: nothing in the customop tree DT_NEEDEDs liblzma, libbz2 or libz.so; the device-runtime wrappers libnrtucode{,_internal}.so have no codec NEEDED entry. They are transitive host-toolchain build deps; their codec internals are out of scope here.

Verdict. The runtime NEFF codec set is exactly { zlib-inflate 1.3.1 }, wrapped by a tar+gzip-only libarchive, reached on pkg_version==2 only. A reimplementer keeps a decompress-only zlib (inflate side) and omits liblzma, libbz2, and the deflate/compress half of zlib — none is on the load path.

3. Cut #3 — libsqlite3: ZERO importers, linked-but-unreached

Claim. No sqlite3_* importer exists from the GPSIMD runtime path — host or device. The runtime opens no DB, prepares no statement, runs no query. The bundled libsqlite3 is a vanilla SQLite 3.44.0 SDK with no consumer.

3.1 No sqlite import edge — host runtime

$ nm -D --undefined-only libnrt.so.2.31.24.0 | rg -c 'sqlite3_'   -> 0
$ nm        libnrt.so.2.31.24.0 | rg -ci 'sqlite3_'                -> 0   (nothing DEFINED either)

The import-graph artifact agrees: the 613-entry native_imports.json list has 0 sqlite-substring names (§4). libnrt neither imports nor defines a single sqlite symbol, and libsqlite3 is not in its DT_NEEDED set (the nine-entry TIER-1 list, §1.1).

3.2 No sqlite import edge — device-runtime wrappers (customop SDK)

The GPSIMD device-code runtime wrappers in the customop package:

$ readelf -d libnrtucode.so | rg 'NEEDED'                          -> libc.so.6   (only)
$ nm -D --undefined-only libnrtucode.so | rg -c 'sqlite3_|EVP_|SSL_|inflate|lzma_|BZ2_|dlopen|dlsym'  -> 0

libnrtucode.so (and libnrtucode_internal.so) DT_NEEDED is libc.so.6 only; the complete UND set is ~18 glibc symbols + 3 toolchain weak symbols + two SUNDA_Q7_POOL_RELEASE_EXTISA_0_{JSON,SO}_get device ISA-pool getters. Zero sqlite3_* imports, zero dlopen/dlsym primitive, zero "sqlite"/".db" string. The negative is mechanism-complete: static link, dynamic link, and dlopen-by-name are all excluded.

3.3 What libsqlite3 actually is, and why nothing reaches it

$ <c10/lib>: libsqlite3.{so,so.0,so.0.8.6,a,la} + ../include/sqlite3{,ext}.h + pkgconfig/sqlite3.pc
$ strings libsqlite3.so.0.8.6 | rg '^3\.[0-9]'   -> 3.44.0

It is a complete link SDK (shared + static + headers + pkg-config + the package's only .debug_info compile unit, sqlite3.c), bundled into the PyTorch C10 link tree alongside libc10.a and the usual third-party set (crypto/ssl/lzma/z/bz2/ffi/sqlite3). Its own NEEDED is the stock distro set (-lm -ldl -lpthread). The customop build driver script/build_custom_op.py links c10/lib/libc10.a but names neither sqlite nor crypto/ssl/lzma/z/bz2/ffi — so sqlite is not even pulled into the on-device custom-op image. Even libc10.a itself has 0 sqlite call sites; the only sqlite3_open/exec/prepare name hits in the whole tree are the definitions inside libsqlite3 itself.

NOTE — scope correction. The sqlite subject is elsewhere named as "libnrt.so (122 MB, debug_info)", but that binary lives in the runtime-lib package, not the customop SDK corpus where the sqlite SDK ships; and the cited "debug_info" actually belongs to libsqlite3.so, the only c10/lib payload carrying .debug_* sections. Both reachability halves — device-runtime wrappers (OBSERVED here) and host libnrt (§3.1, OBSERVED here; cross-referenced to the libnrt surface map) — are nonetheless negative.

3.4 Verdict — Cut #3

linked-but-unreached. No runtime DB on the GPSIMD path. sqlite contributes zero to runtime behaviour: no cache DB, no manifest DB, no host or device DB on the execution path. It is a PyTorch build-SDK passenger. A reimplementer omits libsqlite3 entirely.

4. The import graph as a single cross-cut

All three negatives fall out of one artifact in one pass — the libnrt native_imports.json (the .dynsym UND table, 613 entries):

$ python3 -c "import json,re; d=json.load(open('<libnrt>_native_imports.json'));
    names=[v['name'] for v in d];
    pat=re.compile(r'inflate|lzma|bz2|zlib|archive|gz|uncompress|crc32|adler32|EVP_|SSL_|SHA|RSA_|sqlite3_|deflate', re.I);
    print('total', len(names), 'codec/crypto/sqlite hits', sum(1 for n in names if pat.search(n)))"
 total 613 codec/crypto/sqlite hits 0

613 imports, 0 codec/crypto/sqlite names. Every versioned import is a GLIBC_*/GLIBCXX_*/CXXABI_*/GCC_* C/C++ runtime symbol. This single query is the import-graph proof for all three cuts simultaneously, and it agrees byte-for-byte with the nm -D --undefined-only counts in §§1–3 (the JSON is readelf -Ws of the same .dynsym).

5. Adversarial self-verification

The five strongest claims on this page, each anchored in the binary:

Two grep-precision CORRECTIONs are embedded in §1.2 and §1.4: the loose crypto/cert substring scans return non-zero only on C++ ABI mangled names, never on real OpenSSL routines; the word-boundary queries confirm the clean negative.

6. The reimplementer's takeaway

A GPSIMD host that reimplements the nrt_load → … → neff_parse NEFF-staging path needs, from this entire family of general-purpose libraries, only a decompress-only zlib (inflate side) — and even that only to handle pkg_version==2 (gzip-tar) NEFFs; pkg_version==1 (raw-tar) NEFFs touch no codec at all. It can safely omit libcrypto, libssl, libsqlite3, liblzma and libbz2:

• No crypto — no signature/attestation/certificate verification runs at load; the only hashing is an optional, unkeyed MD5/SHA-256 integrity compare, gated on a per-load verify flag.
• No second codec — lzma/bz2 are never linked or called; the whole inner archive (including weight *.npy members) is one gzip stream or none.
• No database — sqlite opens nothing; there is no cache/manifest DB on the host or device path.

Cross-references: The libnrt Surface Map (GPSIMD lens) (the host link graph these cuts trim); the NEFF Version / Compatibility Model (neff/version-compat.md, the pkg1/pkg2 model that arms the inflate path); the Firmware Trust Chain + Threat Model (control/security/trust-chain-threat-model.md, the "no crypto root of trust from the GPSIMD path" position these import-edge cuts substantiate); and the Bibliography of Source Binaries (appendix/bibliography-source-binaries.md, provenance of the runtime-lib and customop-lib packages).

7. Confidence & limitations

• Codec identity (zlib only; lzma/bz2 absent), no crypto edge, no sqlite edge: HIGH × OBSERVED — each rests on three independent negatives (DT_NEEDED, .dynsym UND, defined symtab) plus the import-graph JSON, all agreeing.
• nrt_load → … → neff_parse → gzip_filter_read → inflate chain: HIGH × OBSERVED — every edge is a concrete call <target> read from the binary; the two neff_parse callers and inflate's single caller were enumerated by ranged disassembly.
• Lazy-pull ordering (filter inert until the gzip member is sniffed) and the weight-bin "single gzip stream" corollary: MED × INFERRED from the libarchive filter model + observed vtable wiring; static analysis sees registered edges, not the runtime pull order.
• "Why OpenSSL/sqlite are bundled" (PyTorch third-party build deps): MED × INFERRED from the c10/lib layout, not a decompiled provenance record.
• Default state of the verify flag across all nrt_load callers is out of scope here (it is a runtime-selectable boolean written at config-init sites).
• Method: white-hat static analysis only (no execution). All facts read as derived from the shipped libnrt.so.2.31.24.0 and customop-SDK artifacts; no external source tree was consulted or quoted.