Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Categories
Random page
Top Contributors
Recent changes
Special pages
Contribute
Create a page
How to help
Wiki policy
Article suggestion list
Articles in need of work
Help
Frequently asked questions
Join the discord!
Help about MediaWiki
Moderators' noticeboard
Report a bug
Consumer Rights Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Qualcomm
(section)
Page
Discussion
English
Read
Edit
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
Edit source
View history
Purge cache
General
What links here
Related changes
Page information
Cargo data
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===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.
Summary:
Please note that all contributions to Consumer Rights Wiki are considered to be released under the Creative Commons Attribution-ShareAlike 4.0 International (see
Consumer Rights Wiki:Copyrights
for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource.
Do not submit copyrighted work without permission!
To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Qualcomm
(section)
Add topic