New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users

Issue metadata

Status: Available
Owner: ----

Sign in to add a comment

Issue 2508: nacl_cpuid.c uses vendor string in features check

Reported by, Dec 21 2011

Issue description

in nacl_cpuid.c (line 378):

The function "NaClArchSupported" returns the following:

return (Bool) (features.f_cpuid_supported && features.f_cpu_supported);

f_cpu_supported is only set on two lines: 372 & 374

  if (strncmp(cpuversionid, Intel_CPUID0, kCPUID0Length) == 0) {
    features->f_cpu_supported = 1;
  } else if (strncmp(cpuversionid, AMD_CPUID0, kCPUID0Length) == 0) {
    features->f_cpu_supported = 1;

This means that only CPUs with the vendor string of "GenuineIntel" and "AuthenticAMD" can run NaCl.

A CPU vendor string is not a CPU feature and there is no reason to validate against it.

Comment 1 by, Jan 11 2012

Project Member
Labels: -Pri-2 Pri-1 Mstone-19
Status: Available
@bjornstar: Thanks for pointing this out. 

It would be helpful in terms of testing if you could suggest what kind of machine you would like to see Native Client support.

Comment 2 by, Jan 11 2012

Thanks for replying,

Generally, when checking for CPU features, you would ask the CPU what features it supports instead of relying on the existence of a vendor string on the CPU.

Another instance of using vendor strings instead of features is in the Check386CPU function:

static bool Check386CPU() {
  const size_t kCPUID0Length = 12;
  char *cpuversionid;
  int hascpuid = asm_HasCPUID();

  if (!hascpuid) return 0;
  cpuversionid = CPUVersionID();
  if (strncmp(cpuversionid, Intel_CPUID0, kCPUID0Length) == 0) {
    return CheckCPUFeature(CPUFeature_386);
  } else if (strncmp(cpuversionid, AMD_CPUID0, kCPUID0Length) == 0) {
    return CheckCPUFeature(CPUFeature_386);
  } else {
    return 0;

This seems to be saying that being 386 compatible means having a CPU vendor string of "GenuineIntel" or "AuthenticAMD"

Why wouldn't you just return the value of CheckCPUFeature(CPUFeature_386)?

Comment 3 by, Jan 13 2012

Because our system is potentially vulnerable to incorrect x86 implementations, it would be easier for us to consider adding one or more specific CPU vendor strings, as opposed to opening it up to any x86 implementation. Please feel free to suggest additional CPU vendor strings; in the mean time we will evaluate the risks of allowing all x86 implementations.

Comment 4 by, Jan 18 2012

I'm not sure what you are trying to say when you say things like "incorrect x86 implementations" When I did a Google search for "incorrect x86 implementations" I only got this bug report as a result. Do you have more information about these incorrect x86 implementations that NativeClient is potentially vulnerable to? I'd be interested in seeing some documentation from the NativeClient team as to why you'd make a statement like that.

Using the wikipedia list of x86 manufacturers ( we could come to the conclusion that there are currently three x86 manufacturers:

 - Intel "GenuineIntel"
 - AMD "AuthenticAMD"
 - VIA "CentaurHauls"

However, I still stand by my assertion that a vendor string is not a CPU feature and it does not belong in a feature check.

Comment 5 by, Jan 18 2012

Project Member
Labels: -Pri-1 -Mstone-19 Pri-2 Mstone-X
Thank you for your feedback and your interest in this question. Please understand that security is a critical challenge in this space, and we are determined to do an excellent job of protecting users of our system.

Try searching for "Intel Specification Update" or "AMD Revision Guide" for some examples of defects in popular x86 implementations. While it is hard to find a documented defect that allows a simple Native Client exploit, we are inclined to take a pessimistic position in the interest of protecting our users.

In general we feel the errata documents provided by x86 vendors are inadequate. We work with engineers from Intel and AMD to get additional information on errata of particular interest. We would like to work with other x86 vendors, assuming they can provide errata documentation and appropriate technical contacts.

Comment 6 by, Jun 17 2014

Project Member
Labels: Component-TCB

Comment 7 by, Sep 24 2016

5 years later and there is still a vendor string check.

It would be really nice to see this go away.

Sign in to add a comment