Qualcomm: Difference between revisions

Tooniis (talk | contribs)
Undo revision, lost actual edit to conflict 26525 by Tooniis (talk)
Tag: Undo
Tooniis (talk | contribs)
mNo edit summary
 
(3 intermediate revisions by the same user not shown)
Line 13: Line 13:


==Controversial Practices==
==Controversial Practices==
===Restrictions on software modifications===
Qualcomm employs mechanisms in their Snapdragon SoCs that prevent users from running their own code or modifying firmware or operating system code on their devices. Such mechanisms include Secure Boot where each boot stage authorizes the next stage establishing a "chain of trust". On power-on, the SoC executes the Primary Boot Loader (PBL), stored in immutable read-only memory (ROM) etched on the silicon die making it physically impossible to modify. PBL loads and authorizes the eXtended Boot Loader (XBL), which in turn loads and authorizes the next stage which can be another bootloader or the operating system, all of which are stored in rewritable flash memory. The SoC contains a set of one-time programmable (OTP) electronic fuses within the SoC, which store cryptographic signing keys along with other parameters such as enabling Secure Boot and debugging flags. The signing keys are generated by Qualcomm and the device OEM and are used by the various boot stages to verify images loaded from flash memory. The keys are not provided to the end user, preventing any modifications to the software images.
A technical paper by Qualcomm<ref>[https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/secure-boot-and-image-authentication.pdf Secure Boot and Image Authentication Technical Overview], ''Qualcomm Technologies Inc.'', Retrieved 2025-10-08</ref> details the Secure Boot mechanism and clarifies the entities allowed to authorize software running on the end device:
<blockquote>The OTP eFuse configuration dictates the device custodian, who is commonly referred as the Original Equipment Manufacturer (OEM). The device OEM takes control of the device mutable software by loading a configuration file with their custom fuse values. The configuration file sets the fuses that enable secure boot and stores a cryptographic hash of the manufacturer public key certificate in the fuses reserved for it.
Moreover, the immutable hardware has the ability to include the OEM fuse configuration in platform key derivations along with hardware secrets provisioned into the chip by Qualcomm Technologies and the device OEM. Secure boot restricts all keys with these bindings to software signed by that OEM and to them alone. One of the guiding principles of Qualcomm Secure boot is that no software runs without an authorization from the OEM.</blockquote>The device OEM is set as the "device custodian" which controls the software that may run on the device. Further text describes other entities that may have a hand in authorizing software:
<blockquote>Besides the OEM there are other parties that have some type of stake in the final product. For instance, independent software vendors, content providers, and certification bodies want to ensure that their requirements are met with the product. Those parties may find it easier to get their assurance from
a commonly used platform like the Qualcomm TEE, rather than inspect an individual OEM’s product. Hence, images that control assets linked to multiple stakeholders, or control shared resources on the SoC, are signed by both Qualcomm Technologies and the device manufacturer in a process known as double-signing. This is designed to ensure that any security-critical image can only be executed if it has been approved by Qualcomm Technologies and the device manufacturer.</blockquote>
Several entities are listed as being stakeholders in the final product, while no mention of the end user is made.


==References==
==References==