4 players in the baseband market doesn't really seem too much of a problem.

Sure - they all have different market segments - but any of them would seem to have the ability to nibble into any others segment if they wanted to, which in turn keeps licensing costs in check.

I don't think the complex standards are a barrier for a team of people with the capabilities of designing an ASIC. The barrier is the minefield of patents. The only realistic entry into the market would be to buy a lot of patents from an existing player, and use them in a tit-for-tat deal for any other patents one couldn't license.

> - Samsung has their own basebands but only uses them on their premium phones

Uh? There are Samsung Exynos devices not using a Samsung baseband? (Exynos spans a large size of the range, just not the sub-100$)

> Utterly unbelievable that no Western government has tackled that situation. The market for basebands is completely and utterly rotten:

There is a global problem that in a lot of areas there is a monopoly lock-in via standards. Those companies are growing their strategies to control the way standards are written, to make it more complicated and costly for 3rd parties to implement.

One example of making standards more complicated which adds more patents is DVB-T2 [1]. 95% of the usage of DVB-T2 compared to DVB-T1 is increasing modulation rate and improving FEC, but it also adds PLP (which I've seen maybe three demos of), which is covered by several patents, largely increasing complexity and patent cost.

FWIW, I love standards and I agree that the industry should largely participate in making standards. I agree that standards needs to have "SHALL", you can't make everything optional to allow for lower costs. And I won't pretend there is an easy solution to those problems.

Sadly, the only way I can see to improve this situation, is to increase government's public funding into standardization.

[1] FWIW, I know nothing of how DVB-T2 has been written and who did it, so it's just an example of complicated requirements increasing the number of patents and thus cost of implementation. It's possible that those requirements have been added in good faith.

If you think other players who would be competitive would have better security and code quality, you're mistaken. Shipping culture in hardware requires deadlines be met and that requires taking shortcuts, often in software. Unless the incentive structure changes all players will end up with similar results.

> Even Apple hasn't managed to kick Qualcomm and Broadcom to the curb where they belong.

That's not quite true.

https://www.reuters.com/technology/apple-reveals-first-custo...

You're forgetting Unisoc/Spreadtrum and ZTE in 5G, and in 4G there are also a bunch of "lower-end" Chinese basebands that are heavily copied from / derivative of one another.

> Utterly unbelievable that no Western government has tackled that situation

Yes, I think it would behoove most countries to do what China, Taiwan, and Korea have all done: force Qualcomm into antitrust settlement where they have to give up parts of their patent portfolio.

> That this lack of competition disincentivizes all actors from making investments into code quality and security is obvious

With the above said, I don't agree with this take at all; in my experience almost all hardware has horrible firmware, drivers/BSP, and software no matter how competitive the market, and whether it's good or not is driven almost completely by company culture / standards and not by market forces. I don't think the market selects for code quality at all. Janky low-level code is culturally pervasive across the globe. Hardware is delivered on strict fixed timeline and invisible to the end-user, and there's a very strong emphasis on functional testing and validation. This means that nobody cares what duct tape and bailing wire hacks are necessary to get units out the door as long as they pass validation, ship on time, and function. So, a culture of corner-cutting hackery is passed down from generation to generation of embedded engineer.

The only places I don't see Bad Hardware Code happen are places where Software People are present and start imposing software culture on the Hardware People (Google, Apple, etc.), or companies making an intense, concentrated effort towards becoming more Software Company oriented (Nvidia). This tends to come at a major cost, too - yes, code gets better, but in exchange, everything starts taking forever (see: Apple baseband project).

Checkpoint found a bunch of issues [1][2] using QEMU and AFL some time ago. So it's possible that's why srlabs didn't find much yet.

[1] https://research.checkpoint.com/2021/security-probe-of-qualc...

[2] https://blog.checkpoint.com/security/achilles-small-chip-big...