BitBanging

Yep, LBAs are the primary addressing scheme in the NVMe spec, written into every single IO command. I would imagine there could be a better way, but NVMe & OS support still carries some baggage from SATA HDDs -> SATA SSDs -> NVMe SSDs.

As you mentioned, over-provisioning and other NAND flash memory health management techniques like garbage collection and wear leveling are needed for usable modern SSDs. Modern SSD controllers are complex beasts having 3-7 microprocessor cores (probably double digit core counts now with PCIe 5.0), encryption engines, power & thermal management, error correction, multiple hardware PHYs, etc.

Example product sheet: https://www.marvell.com/content/dam/marvell/en/public-collat...

IIRC SSD manufacturers are likely to store a mapping table of LBAs (logical block addresses) to PBAs (physical block addresses) in the DRAM or Host Memory Buffer.

Some calculation like:

total storage size / page size per LBA (512B or 4KiB usually) * mapping data structure size

The NAND flash manufacturers usually have no software involvement unless they are in the business of also selling SSD controller SoCs. They will typically sell FDKs/SDKs that are heaping piles of garbage written overseas for their SoCs that provide minimum functionality for interfacing with all of the components.

I wouldn't really expect controller-less NAND flash to ever meaningfully compete with what we have now. There is a lot more specialized hardware in a typical SoC than just a microprocessor and NAND flash chips