Samsung Begins Mass Production of Its Own 5G Chips (zdnet.com)

Samsung Electronics has started mass-producing its 5G chips, the company said. From a report: Among the company's new chip offerings is the Exynos Modem 5100, which contains a 5G multi-mode chipset; it is the same chipset that is used to power the Galaxy S10 5G, which became available for sale in South Korea as of Wednesday. The model, unveiled in August, is the world's first 5G modem to be compatible with the 3GPP's 5G New Radio (5G-NR) standard. Mass production for its single-chip radio frequency transceiver, the Exynos RF 5500, and supply modulator solution, the Exynos SM 5800, have also started, Samsung said. These technologies also power Samsung's flagship 5G phone. The Exynos RF 5500 has 14 receiver paths for download, 4x4 MIMO (Multiple-Input, Multiple-Output), and a higher-order 256 QAM (Quadrature Amplitude Modulation) scheme for data transfer in 5G networks; and the Eyxnos SM5800 is 30% more power efficient than previous offerings.

Comments

Re:Better certification system needed.

[Gravis Zero]

Actually, it's a fairly difficult problem because you're talking real time systems verification and dozens of threads that can interact with each other, only a tiny combination of which if a packet of type Z arrives and within 1.2 ms a packet of type Y comes in, there's an exploitable window of 50 ms where if you send a packet of type A, the modem drops.

It's a heavily multitasked system of which there's at least a couple of processors mandatory (a DSP and a control processor) all trying to handle dozens of events that can happen.

...

These edge cases cause all sorts of thread timing issues which can expose vulnerabilities, or even smash the stack.

I'm aware of the multitasked/pipelined nature of GSM decoding which is exactly why formal verification should be used for implementations. Timing issues are absolutely an issue and formal verification can help identify when, where and how they happen. A bulletproof implementation isn't impossible, it's simply not a priority because there has been no public exposure of just how weak these systems can be.

We discovered through user testing that the subway would routinely crash the modem firmware (when it goes into a tunnel suddenly and then exits it) All we could do is simply ask for firmware updates and providing them with logs of the modem and keep re-trying the scenario.

If this issue had been identified during the design phase (via formal verification) then you would have been able to properly address the issue.