If so, what are these OSes? Are they specially crafted? How difficult is it to apply this kind of program verification to the everyday OSes we use?

If not, why haven't people invented such OSes?

Package signature verification is quite common with today's package managers. What I'm asking about is signature verification at loading time.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Dec 9, 2016 at 13:33
  • IBM i has allowed validation of program signatures for a number of years. Only sites needing such security measures make use of it. Programs with invalid signatures cannot be restored onto the system at the highest validation level. Commented Dec 9, 2016 at 14:11

10 Answers 10


iOS and Android both validates the signature of every single piece of code before loading them into memory.

Windows UWP apps are also all checked for signature before being loaded as well.

Package signature verification is quite common with today's package managers. What I'm asking about is signature verification at loading time.

The difference is massive in terms of performances. A package signature is checked when it is installed and not afterward.

To be effective, code signing must be checked for every binary before it is executed or loaded.

Furthermore, special care must be taken by the OS (or runtime environment) in order to make sure a memory page marked as executable is signed (or, at least, that is has been loaded from something that was properly signed). That requirements is extremely hard to enforce on any environment that wasn't designed with code signing in mind because it tends to break a lot of legacy code.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Dec 8, 2016 at 10:45
  • 5
    Are you sure that Android performs signature validation on load? It seems improbable, since the signature is on the Dalvik bytecode, but this is not directly executed, but either optimized or AOT-compiled depending on the Android version. It would seem logical for the actual signature verification to happen on install.
    – lxgr
    Commented Dec 8, 2016 at 16:06
  • 1
    @lxgr Now that you mention it, now I'm not sure. I'm trying to find the relevant documentation but I'm having less luck that with iOS. I'll update my answer when I find something. Thanks
    – Stephane
    Commented Dec 9, 2016 at 8:27
  • I'm sure also all OS'ses of recent game consoles (like PS4) do this. Commented Dec 9, 2016 at 9:26
  • 3
    macOS also validates signatures (unless you tell it not to explicitly).
    – idmean
    Commented Dec 10, 2016 at 17:38

Why do not all OS verify signature of programs? Simply because in the early times, most programs were written and compiled locally, and still nowadays, some business applications are specifically built locally. A lot of high quality programs are distributed as source and can be compiled locally. It often make sense on high performance servers because compilation options can be used to tweak a program for specific needs. If you could only use signed executable from well-known sources, all that would not be possible.

Of course for an OS targeted to end users like Android or iOS things go different, and it makes sense to only allow executable installed from well known sources.

But even on my Windows box, I would be very disappointed if I could not write, build and execute a program in C or C++...

  • 8
    Presumably, what you would do on Windows (or any other OS) in the case of stronger lockdown is add a local certificate to the trust store, then compile and sign with that. In fact, there's good security reasons to do so even in the case of compiled-from-source code for servers (since letting arbitrary people compile and deploy to production is a terrible thing to do). Keep in mind that Microsoft doesn't have control over private keys used for signing 3rd party programs anyways, and I doubt that changed in the Windows store. Commented Dec 7, 2016 at 17:37

One example that's occasionally used in education and corporate environments is AppLocker, which can restrict application execution to a whitelist based on administrator-defined attributes, including the publisher name from a signature, or the hash of a specific file.

The biggest problem is of course the administration overhead, having to specifically whitelist all programs a user could possibly need. Additionally, many publishers don't sign their applications. And of course it's not a foolproof solution - e.g. a bug in a whitelisted program could still be exploited to run arbitrary code1.

Actually, the executable's signature isn't even the important part. The whitelist can be implemented by path for all the difference it makes - what's important in this scheme is that the user has no write permissions to the program directory2. Assuming that's true, what advantage does verification at execution time provide over verification at install time? No one can change the installed program. If the attack vector is offline editing of files, full disk encryption is the correct answer.

1 Most such bugs would not be considered severe in a normal environment, where they would not lead to privilege escalation. W^X can still be bypassed with ROP.

2 Even verification of signature of the executable will miss external modules (e.g. dynamically-linked libraries) by default. And enabling that can have significant performance impacts.


Linux already has the necessary mechanisms in the kernel (since version 3.7), called IMA:

The goals of the kernel integrity subsystem are to detect if files have been accidentally or maliciously altered, both remotely and locally, appraise a file's measurement against a "good" value stored as an extended attribute, and enforce local file integrity. These goals are complementary to Mandatory Access Control (MAC) protections provided by LSM modules, such as SElinux and Smack, which, depending on policy, can attempt to protect file integrity.

With IMA, sensitive files can be labelled "immutable" (which is what you'd do with executable files), which signs them with a special RSA key. The signature is validated on file access, preventing offline tampering. Executing files which are not immutable can be prohibited via SElinux policies.

Of course, usability of such a system is reduced. To build and execute your own files on such a system, you will need a trusted private key to sign them first. Software upgrades are likely to require a reboot in order to update immutable files before they are locked.

  • One of the downsides to IMA is that the entire file must be accessed in order to hash it and verify the hash. This breaks demand paging which can slow down large programs with many large libraries.
    – forest
    Commented Feb 27, 2018 at 9:06
  • AFAIK this has improved since Merkle trees are used now for only hashing individual updated / accessed parts.
    – k_o_
    Commented Dec 22, 2023 at 2:31

Load time verification is very expensive and not fool proof.

Are there any OSes that verify program signatures before executing them?

EDIT: As pointed out in comments, such operating systems. ChromeOS for e.g.

If so, what are these OSes? Are they specially crafted? How difficult is it to apply this kind of program verification to the everyday OSes we use?

It is fairly difficult to verify a program at loading time. Plus even if you successfully do it, once a program has been started the attacker can still give malformed input and cause havoc(buffer overflows). Having said that, there are software modules that verify their signatures at load time (Software attestation e.g.FIPS compliant OpenSSL). Having an operating system do it for each and every process is very very expensive.

As the focus shifts towards cloud computing, you would want to ensure that you are able to run high assurance software on even untrusted systems. I would say that not a lot of research would be done on protecting the system from the software that is running on it. Instead the focus will be more on doing trusted computation even in untrusted environment. You can have a basic chain of trust like system or software attestation (refer the bottom link) if you want at load time. The important thing would be ensuring that the software isn't compromised at run-time.

Look at this discussion: Can a running interpreted program cryptographically prove it is the same as as a published source code version?

  • 1
    Not unlikely at all -- such operating systems actually exist. Look at ChromeOS -- the whole block device with the OS is signed. And there are extensions for Linux making this functionality available present in the upstream kernel. Commented Dec 7, 2016 at 16:46
  • @CharlesDuffy I was thinking more in terms of commodity operating systems which don't have a specially designed marketplace. But yeah. I'll edit my answer. Thanks for pointing it out!
    – Limit
    Commented Dec 7, 2016 at 17:06

Many answers mention general OSes having relatively recent support, but I see no mention of TPMs and the Trusted Computing Group. A TPM provides the minimum necessary hardware to do signed execution with a chain of integrity up from firmware boot as a standardized consumer grade motherboard module. It works by allowing boot stages to extend hash registers with measurements of each subsequent stage before execution, and then providing a locked keystore mechanism that can be conditional on these hash register values.

With the TPM solving the Chicken and Egg problem for PKI and early boot, resource access could be restricted to software allowed in a specific policy to whatever extent that code was itself exploit free. Without a verified boot, there is little point in runtime signature checking with no reason to believe the PKI system and policy is unmodified.

To my knowledge (which is not current), only Apple and Google had enough control of their hardware platforms to experiment with on-by-default TPMs and I don't think either implemented a complete TCG style of verified boot. But the threat of being left behind by a sudden uptake of these new devices caused OS vendors to start implementing some runtime integrity components.


NetBSD has veriexec.



It is very well suited for Internet-facing servers, along with a raised securelevel ( https://wiki.netbsd.org/kernel_secure_levels/#index2h1 ).


Firstly, I am clearly a non-expert on anything I am about to say so be cautious...

In the free software world I live in, people are working on reproducible builds. The goal is that every binary downloaded could be verified by the user themselves by, well, building it. Many distros and software projects are interested in it. If I remember correctly, this idea was started by the bitcoin people and followed by the tor project.

From what I have heard, some people suggested after sufficiently many packages are reproducible, the hash could be shared in some p2p ways. So to answer your question, in my opinions, at loading time, a verifier can simply hash the binary and check if it matches the hash published by the others, although this may be slow depending on your internet connection speed (maybe the connection has to go through tor).

Also, I happen to know 2 distros more than others so I will elaborate more with them:
From what I have heard, Debian will make reproducible-build a policy requirement after sufficiently many packages are reproducible.
Guix implements guix challenge command so that one can verify the hash of your local build with the official build on Hydra.

  • This idea is interesting. But I'm wondering: If you already have a hash of the build result, why not simply download it using magnet? Unless you don't have good network, compilation can be very time consuming and the output size is usually smaller than the source code so what are the benefits of building it by yourself?
    – Cyker
    Commented Dec 8, 2016 at 7:05
  • In order to see whether a package is actually built from the source it claims to be built from. Side note: The concept has very little to do with your question.
    – elaforma
    Commented Dec 8, 2016 at 11:20
  • @Cyker: Multiple people redoing reproducible build is attestation to the hash itself, rather than attestation to the build result. The more independent, mutually untrusting people claims to get the same build result, the more trustworthy the published hash becomes.
    – Lie Ryan
    Commented Dec 8, 2016 at 11:36
  • 1
    @Cyker: in open source software, you don't necessarily need to trust the author, because you have the source code and can look for backdoors in the source code. This auditability breaks during a build when the build isn't reproducible, because the software author could add a backdoor before building, which wouldn't exist in the published source code. It'd be very difficult to notice such backdoor, compared to noticing a backdoor in the source code. By having reproducible build, any backdoors are limited to the ones that's difficult to notice in the source code as well.
    – Lie Ryan
    Commented Dec 8, 2016 at 13:02
  • 1
    @Cyker: Yes, if multiple mutually untrusting entities agreed on a hash when they rebuild, then most people can reasonably securely use the pre-built package and save the building effort, relying on herd immunity. The most paranoid probably should still build themselves, just in case the entire world are conspiring against him.
    – Lie Ryan
    Commented Dec 8, 2016 at 15:40

I am not an 'expert' but just a common user of some of the tools.

Am sharing about reproducible builds a bit more and as comments was not the right place, hence sharing here. From what little I understand, used and experimented, what it does it gives you a .deb package along with a .buildinfo text file. The buildinfo text file will have names and version numbers of all libraries which were needed in the build environment to make the binary.

So if you are suspicious about a binary package (from the archive or even outside) which has the buildinfo text file, it may or may not be triviai to test the packages by re-creating the exact build environment and comparing the hashes of the final binary packages.

It may also be possible to have some sort of web of trust so that more people can jump and say that the hashes match making it somewhat more reliable perhaps. There may be edge-cases that I don't know about.


Microsoft Windows 7+ can be configured to only allow Authenticode signed programs to run.

But you have to understand, that this only means you know who made the virus that destroyed your computer. It is not really a security feature, because it doesn't tell you anything about a application that it is signed. Yes, you know that $RANDOM_GUY from China, Ukraine, Angola, wherever created it. But what good would this really do you, if your valuable data is encrypted and $RANDOM_GUY demands 20BTC to decrypt it. And if the software steals all your data, then what good will it do you that you know $RANDOM_GUY probably stole it?

  • That's just AppLocker, which also allows (as in your link) the admin to identify a specific Publisher. AppLocker additionally allows restriction based on the hash of a specific file, which is far more precise than just the certificate (though will break on update). Actually, a code-signing certificate isn't particularly easy to get either.
    – Bob
    Commented Dec 12, 2016 at 7:01
  • @Bob Well, I have a code signing certificate which just cost me $60 and a scan of my passport. You can get one for 14€ if you say you only use it for open-source software. I would call that easy to get.
    – Josef
    Commented Dec 12, 2016 at 8:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .