Samsung Begins Mass Production of Its Own 5G Chips (zdnet.com) 26
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.
Already on 5G. Thanks marketing. (Score:2)
My Galaxy S8 already says 5G. Way to go Sprint "re-branding" your cellular service so that the average consumer thinks they are already on 5G.
That's not shadily deceptive at all, THATS MARKETING! :)
Re: (Score:2)
I assume you mean AT&T. Sprint is the one suing AT&T for rebranding their LTE as "5G E".
Better certification system needed. (Score:5, Insightful)
Frankly, every wireless chipset (not just GSM version xyz) has been one shitty implementation after another. Since we're putting these things in everything from pocket computers to infrastructure, we need to start having stringent chipset testing to ensure they cannot be exploited. I there are few (if any) wireless chipsets that can actually stand up to fuzzing let alone a reverse engineering attack.
We really need a certification body that actually tests chipsets to ensure that at the very least they won't fault/reboot (indicative of being exploitable) when they are fuzzed. Frankly, I would think to have the highest level of certification from this body that your code would have be formally verified. Considering they are a small isolated system, this isn't a Herculean task.
Re:Better certification system needed. (Score:4, Informative)
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.
And it's possible - think of a high speed download taking place alongside a call, the signal is fading out and the radio has to do a handoff procedure to get onto the next cell it can see, but because the road you're on is at the cell boundaries, just as soon as it's done one handoff, it needs to restart it to handle the new cell.
These edge cases cause all sorts of thread timing issues which can expose vulnerabilities, or even smash the stack.
Many years ago, I worked on a cellphone design. 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.
Re:Better certification system needed. (Score:4, Interesting)
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.
Might wait this out another year... (Score:2)
I was kind of planning to get a new phone this year, but given how the real 5G rollout has gone just now [cnet.com], I am not thinking there will be much point in owning a 5G phone even by winter... maybe at the end of next year the network and the hardware will be stabilized.
On a side-note, if you read that article it has an aside about how they are using a phone that has a separate battery for 5G so it doesn't eat the main battery!!! That is nuts to me.
Re:Might wait this out another year... (Score:4, Informative)
So soon you can burn through your quota in seconds (Score:3)