Now they're getting counter sued by Qualcomm because it turns out they allegedly violated their own TLA (license to get off the shelf cores) and their ALA (architecture license).
Qualcomm is claiming that Arm is refusing to license the v10 architecture to them and refused to license some other TLA cores requiring them to get the Nuvia Custom CPU team to build cores for those products instead.
This explains their expansion into Risc-V it's a hedge against Arm interfering with QC's business.
SEAR and the Apple team does an excellent job of security on iOS, and should be commended greatly on that.
Not only are they willing to develop hardware features and plumb that throughout the entire stack, they're willing to look at ITW exploits and work on ways to mitigate that. PPL was super interesting, they decided it wasn't 100% effective so they ditched it and came up with other thigs.
Apple's vertical makes it 'easy' to do this compared to Android where they have to convince the CPU guys at QC or Mediatek to build a feature, convince the linux kernel to take it, get it in AOSP, get it in upstream LLVM, etc etc.
Pointer authentication codes (PAC) is a good example, Apple said f-it we'll do it ourselves. They maintained a downstream fork of LLVM, and built full support, leveraged in the wild bypasses and fixed those up.
One of the knock on benefits of this too is increased security across all platforms as long as someone exercises that code path on one of apples new processors with a hardened runtime.
In theory it makes it easier to catch stuff that you can’t simply catch with static analysis and it gives you some level of insight beyond simply crashing.
I buy Apple products not just because they do a great job with security and privacy, but because they do this without needing to do it. They could make plenty of money without going so deep into these features. Maybe eventually it’d catch up with them but it’s not like they even have competition forcing them to care about your privacy.
Their commitment to privacy goes beyond marketing. They actually mean it. They staffed their security team with top hackers from the Jailbreak community… they innovated with Private Relay, private mailboxes, trusted compute, multi-party inference…
I’ve got plenty of problems with Apple hypocrisy, like their embrace of VPNs (except for traffic to Apple Servers) or privacy-preserving defaults (except for Wi-Fi calling or “journaling suggestions”). You could argue their commitment to privacy includes a qualifier like “you’re protected from everyone except for Apple and select telecom partners by default.”
But that’s still leagues ahead of Google whose mantra is more like “you’re protected from everyone except Google and anyone who buys an ad from Google.”
If you have it enabled, then every thirty seconds (regardless of whether you’re actively on a call), your phone will make a request to a signaling server owned by your mobile ISP. So if you’re on T-Mobile and traveling in some other country with no cell service, but you’re connected to WiFi, then T-Mobile will see your public IP address. (IIRC, this also bypasses any VPN Profile you have enabled on your device, because the signaling system is based on a derivative of IPSec that could have problems communicating over an active VPN tunnel.)
I found out about this when I was wiresharking all outbound traffic from my router and saw my phone making these weird requests.
Apple actually does warn you about this in the fine print (“About WiFi calling and privacy…”) next to the toggle in Settings. But I didn’t realize just how intrusive it was.
I know my mobile ISP can triangulate my location already, but I don’t want to offer them even more data about every public IP of every WiFi network I connect to, even if I’m not roaming at the time.
And after all that hardcore engineering work is done, iMessage still has code paths leading to dubious code running in the kernel, enabling 0-click exploits to still be a thing.
None of that ran in the kernel. Everything happens within a single process up until the sandbox escape, which isn't even covered in your article. The article's sequel* goes into detail about that part, which involves subverting a more privileged process by exploiting logic errors to get it to execute code. The only involvement by the kernel is passing IPC messages back and forth.
Google could have added MTE for a couple of years now, but apparently don't want to force it on OEMs as part of their Android certification program, it is the same history as with OS updates.
to be fair, most of MTE's benefit is realized by having enough users running your apps with MRE enabled, rather than having it everywhere.
This is because MTE facilitate finding memory bugs and fixing them - but also consumes (physical!) space and power. If enough folks run it with, say Chrome, you get to find and fix most of its memory bugs and it benefits everyone else (minus the drawbacks, since everyone else has MTE off or not present).
trade offs, basically. At least on pixel you can decide on your own
They do that now because they care about your security, but to make it difficult to modify (jailbreak) your own devices to run your own software that is not approved by Apple.
What they do is against your interests, for them to keep the monopoly on the App Store.
Quoting Arm stock prices is hilarious considering that there is only 10% float available to be traded and 95% of that 10% is owned by institutions already. That stock is so heavily manipulated so the big boys can make insane profits on options.
On the other topic
>>Outside of Snapdragon its basically 5G Telecoms atm
>seems to be the only thing going for it.
Did you guys forget the $4B a year in auto rev that they generate, they essentially captured the entire auto market from Nvidia and NXP.
This is the exact reason why they bought Arduino... So now startups have a way to buy say 1,000 devices for prototyping. Qualcomm gets used to supporting smaller developers/startups/tinkerers and will hopefully push different types of chips into the Arduino product lines.
The issue is that their corporate culture does not support it. Arduino will be too small to matter. This is the same issue as with Coral, the Google TPU. They are not refreshed as they are too small. They are too small cause they are not updated or supported widely.
People need mainline kernel support and regular refreshes to reliably build projects based on it. This will require some level of building their BSPs in open and providing APIs for people to take advantage of the QCOM specific features. A QCOM that won't talk to anyone without an NDA cannot adapt to this.
This was very much my experience going through an acquisition like that. I was working at a company that served big customers. We bought a smaller company, with one of the goals being to expand to serving smaller customers.
What actually happened was that our management very quickly started telling the people who came along with the acquisition that they were doing everything wrong. The salespeople were selling wrong, the marketing people were marketing wrong, the customer support people were supporting customers wrong. Everything that the company we acquired did differently was seen as a problem.
Within about a year, anyone they hadn't pressured to adopt our practices had left and been replaced with a transplant from the Mothership. Another year later, the customers we picked up in the acquisition were rapidly leaving for other vendors. They simply couldn't work with us in a way that worked for their business anymore. Last I heard, pretty much the only remaining vestiges of the company we acquired were trademarks, and we were back to only having very large customers.
Here's how I like to think about it. Tech salesmen (especially enterprise software salesmen) are just like car salesmen. Now which commission would you like to receive: mattel matchbox car or BMW? This makes sense, because it's often the same sales effort per-sale for each possibility.
> This is the exact reason why they bought Arduino... So now startups have a way to buy say 1,000 devices for prototyping. Qualcomm gets used to supporting smaller developers/startups/tinkerers
For this, Qualcomm does not have to buy Arduino for a big amount of money: Qualcomm could simply offer this option on their own and save the acquisition cost.
Addendum: For the acquisition cost, Qualcomm could do a lot of marketing of their offering towards makers.
> Qualcomm could simply offer this option on their own and save the acquisition cost.
No they can't. That's like suggesting "the aircraft carrier could simply turn around." The cheap and simple way for a multi-billion-dollar secretive semiconductor manufacturing behemoth that doesn't know how to write a contract for less than a million dollars or to publish documents for the public is not to just change that. It's to write a contract for millions of dollars to buy someone else that can already do that.
More importantly, if Qualcomm management is just unable to do this, why would they suddenly be able to do this with a different brand under their umbrella?
Seems like a corporate version of the "buy vs build" question. If it's true that the goal is to become more approachable to students and hobbyists (which personally I think would be a good idea) - then Qualcomm must've evaluated both options and decided "buy".
The problem is that massive semiconductor companies like Qualcomm rarely follow through. They want their lottery ticket to be included in the next smartphone revolution but won't care about random under 5k unit Kickstarter. Everyone knows that those are two sides of the same coin, but they always choose to wait for the bankruptcy trustees to show up.
Seems like a similar play to what Broadcom did with Raspberry Pi— create a new entity/brand that could resell their chips on hobby boards and be stewards of a "community" support framework but largely without distracting the company from its enterprise customers or risk cannibalizing those relationships.
That said, interesting that Qualcomm would buy twenty years of Arduino legacy for this rather than launching something new in the space.
Broadcom wasn't really a driver behind Raspberry Pi. They acquiesced and let them have chips, once the product took off, they continued supplying chips for the Pi. And of course supported the community by refusing to supply non-propriety firmware blobs to this day ;)
Other than that, Broadcom never really had any community involvement, nor any involvement in the Raspberry Pi Foundation that runs it. However, some broadcom engineers were part of the foundation, which isn't quite the same.
> interesting that Qualcomm would buy twenty years of Arduino legacy for this rather than launching something new in the space
I wouldn't minimise the effect of people just googling around and finding the name Arduino all over the place. It would be very hard for an entirely new platform to get critical mass while esp32 is not standing still.
As other have pointed out, that doesn't make any sense. Qualcomm doesn't want anyone buying their products at 1k quantities for prototyping. They want huge customers that place huge orders consistently. The return for supporting those small orders is miserable and doesn't align with their business objectives
Qualcomm has bought plenty of companies that serviced small customers, and what happed is exactly what the person you’re replying to described. You can’t even get a quote many times.
What I expect short term is what happened to Eagle in the PCB space when Autodesk bought it (best thing that happened to kicad).
Longterm Arduino goes into the periphery of the maker market, similarly to beaglebone.
It's cheaper and easier to just spin your own boards at that point. Arduinos are not complex or special in any way. Even if you did need a ton of off the shelf boards, there are countless clones that will sell you as many as you want for next to nothing.
Plus the market you're implying exists is so small as to be utterly worthless to Qualcomm. They are in no way interested in individuals or small businesses
I wish folks would test these against current gen Qualcomm modems. We're comparing a brand new modem to a 2 1/2 year old Modem. Android uses x80 and Qualcomm just released x85. So a fair comparison would be C1 vs x80.
I understand that is what the iPhone 16 uses, but that's an Apple problem they purposefully took an older generation modem from Qualcomm for their 16 series. Knowing Apple's modus operandi they probably decided to use the x71 so when they released C1 it appeared better than it really is. They did this during the Intel Modem days when they shipped that.
None the less it will be interesting to see how this modem develops further and what products it ends up in.
No, but Apple always uses older generation parts from their suppliers (modems, displays, glass, NAND, etc), not to sabotage their products, but to cut down on BOM costs and increase margins, as suppliers always ask a premium for their latest and greatest, especially since their customers never cared about the spec sheet so using the most expensive parts would be profits wasted.
I think there is another dimension there - volume. Apple volume is on another level and it takes time to scale up factories to build latest and greatest things.
Good point, do you know the breakdown of Samsung device sales by generation and what chipsets they use? My layman expectation is that most of the android headset sales are lower end models. However, Samsung might be a different beast.
It was also further delayed until December of 2024 because during Depositions Qualcomm learned that ARM didn't destroy nuvia designs like they were required to when they terminated the ALA.
So ARM is suing Qualcomm stating that the IP rights were non-assignable per the ALA, then Qualcomm finds out that ARM also did not hold up its side of the ALA termination agreement and is using Nuvia IP in their current gen designs.
They don't agree since 2022 that Nuvia's related IP must be destroyed on termination of that license agreement, because they expect to own it due to a different license-agreement they have with ARM, but argue that ARM, the owner of the licensed architecture in question, should have destroyed all information, already KNOWING that Qualcomm intends to fight this contract.
So in turn, for ARM to defend itself in this case moving forward, Qualcomm's implication is that ARM should ask Qualcomm to provide the required information to them. But the whole case of ARM is that Qualcomm is NOT the rightful owner of this information.
-
It's also quite a visible move just to delay the proceedings.
Qualcomm states [1] that they learned this new evidence at (ARM's) Mr. Agrawal’s deposition on Dec.12 2023, contacted ARM "less than three weeks" after that to "meet and confer", but "ARM would not meaningfully engage until January 16".
Less than 3 weeks after Dec.12 2023 is NYE, between Dec.28 and Jan.03, ARM obviously responded (but did not "engage meaningfully" according to Qualcomm)
At the point Qualcomm considers ARM showing meaningful engagement, they met within 3 days, on a Friday. And on Jan.22, "the next business day", they contacted the court.
So ARM's legal team was not available to meet at NYE, didn't respond "meaningfully" immediately and an appropriate meeting-slot agreed by ARM and Qualcomm was only possible more than a month after that deposition...
> They don't agree since 2022 that Nuvia's related IP must be destroyed on termination of that license agreement, because they expect to own it due to a different license-agreement they have with ARM, but argue that ARM, the owner of the licensed architecture in question, should have destroyed all information, already KNOWING that Qualcomm intends to fight this contract.
The way you phrased that does sound like trying to have it both ways, but wouldn't those designs be co-owned by Arm and Nuvia? If so it makes logical sense to say that Arm has to delete and Qualcomm doesn't, because Qualcomm has a claim to both sides, but Arm only has a claim to one side. That's not trying to have it both ways.
> So in turn, for ARM to defend itself in this case moving forward, Qualcomm's implication is that ARM should ask Qualcomm to provide the required information to them. But the whole case of ARM is that Qualcomm is NOT the rightful owner of this information.
Qualcomm's case goes beyond "we have a valid license agreement" as to the destruction of Nuvia's design. They're arguing that they do have a valid license agreement, but also that even if they didn't they would still be the lawful owners of the IP and would not be required to destroy it. They might not be able to use it, but they could hold onto it, because nothing in Nuvia's contract with ARM requires it be destroyed by Nuvia.
> 5. Even putting aside Qualcomm’s broad license rights, ARM’s reading of the termination obligations in the NUVIA Architecture License Agreement (“ALA”) is wrong. To the extent any destruction obligation exists, it explicitly applies only to ARM Confidential Information.1 But ARM again omits important facts: (1) under the NUVIA ALA, information in the public domain is not subject to confidentiality obligations, and (2) ARM publishes its instruction set without confidentiality restrictions. Anyone is free to go to the ARM website and download the 10,000+ page ARM Architecture Reference Manual.2 In this case, Qualcomm’s CPU cores are designed to be compatible with the publicly-available ARM Architecture version <redacted>.
> 36. Moreover, even though ARM demanded destruction of Confidential Information obtained under NUVIA’s ALA, NUVIA had implemented ARM Architecture <redacted>, which had been publicly available on ARM’s website for anyone to download since at least around January 2021—over a year before the destruction request. <Redacted sentence>. Therefore, ARM Architecture was not Confidential Information, not subject to any restrictions, and not subject to any destruction obligation. For the same reasons, the NUVIA core design did not contain ARM Confidential Information.
...
> It's also quite a visible move just to delay the proceedings.
I really don't agree. It looks like a bog standard discovery dispute.
