3 ms·

> It isn't possible to trick /proc/cpuinfo on Linux, it always gave me the correct info. Is this because Linux reads this once at boot time, before you have a

> It isn't possible to trick /proc/cpuinfo on Linux, it always gave me the correct info. Is this because Linux reads this once at boot time, before you have a chance to modify it? If so, I assume you could still modify the string from the firmware, bootloader, or simply by modifying the kernel.

bravetraveler 4y ago
I don't know exactly how it's maintained, but you're 100% right -- it can be modified elsewhere For example, on my AMD Threadripper system I can make a VM that pretends to be essentially any Xeon It may perform horribly where features/extensions don't line up, but it'll report whatever. For physical devices it's possible too, just not nearly as common
- nixcraft 4y ago
  Here is what: ls -l /proc/cpuinfo It says (basically it is a pseudo-filesystem with read-only permission, so I don't think so it is possible without making any changes at the Linux kernel/driver level): -r--r--r-- 1 root root 0 Oct 28 09:38 /proc/cpuinfo
  - bravetraveler 4y ago
    Indeed, the proc filesystem is well maintained by the kernel. I understand that part, less so if it's properly immutable/irreplaceable The thing is, it has to get the information from somewhere -- and depending on the age/type of the hardware (physical or virtualized), masking this is either easy or nearly impossible I remember changing this information (DMI?) was more common back in the like Pentium 3 era, for example.
    - bravetraveler 4y ago
      Others have helped me understand this is part of the CPUID thing -- you know, the core of the topic for the overall post! I appreciate it everyone, save your fingers :) I've seen this done for physical chips before too, but I can't recall anything - hence vagueness
  - dezgeg 4y ago
    I wonder if one could bind-mount some other proc file (say /proc/$EVIL_PID/cmdline) over cpuinfo to fake content. Would meet root and be visible in mount output though.
    - stormbrew 4y ago
      You definitely can and things like that are precisely why bind mounts (usually) require root, because POSIX is built very much on the premise of one filesystem tree seen by both privileged and unprivileged users. Other systems do better by not depending on that.
    - raimue 4y ago
      It would be easier to intercept the open() for the /proc/cpuinfo file with a LD_PRELOAD library. Of course that would still be detectable by the benchmark. You could also use a modified libc to spoof it. Then their only way out would be static linking. You could even just modify the kernel to report arbitrary strings in /proc/cpuinfo. So they use the CPUID instruction instead. The CPUID instruction can be trapped to throw a SIGSEGV instead of returning real values on x86 with arch_prctl(ARCH_SET_CPUID, 0). So an injected SIGSEGV handler could then spoof it. But even then, you could also trap the CPUID instruction in the kernel, and spoof it from there, which would be even harder to detect from user space. In the end, the benchmark program always needs to trust the kernel. Is it really worth trying to detect spoofing?
- ilyt 4y ago
  It's because hypervisor intercepts the call for CPUID and returns what you told you to. It's usually used to downgrade a set of features if you want VM to be able to be live-migrated between machines with different CPUs, we migrated a bunch of stuff off Intel to AMD that way. There is a performance hit on that as you're basically making virtual "lowest common denominator" CPU
  - bravetraveler 4y ago
    Thank you! I was aware of the downgrading for live-migration, but not that there was a particular call for it
- pjc50 4y ago
  That's a VM. It will be trapping CPUID at the instruction level and returning whatever the VM is set up as.

bravetraveler 4y ago

I don't know exactly how it's maintained, but you're 100% right -- it can be modified elsewhere For example, on my AMD Threadripper system I can make a VM that pretends to be essentially any Xeon It may perform horribly where features/extensions don't line up, but it'll report whatever. For physical devices it's possible too, just not nearly as common

nixcraft 4y ago
Here is what: ls -l /proc/cpuinfo It says (basically it is a pseudo-filesystem with read-only permission, so I don't think so it is possible without making any changes at the Linux kernel/driver level): -r--r--r-- 1 root root 0 Oct 28 09:38 /proc/cpuinfo
- bravetraveler 4y ago
  Indeed, the proc filesystem is well maintained by the kernel. I understand that part, less so if it's properly immutable/irreplaceable The thing is, it has to get the information from somewhere -- and depending on the age/type of the hardware (physical or virtualized), masking this is either easy or nearly impossible I remember changing this information (DMI?) was more common back in the like Pentium 3 era, for example.
  - bravetraveler 4y ago
    Others have helped me understand this is part of the CPUID thing -- you know, the core of the topic for the overall post! I appreciate it everyone, save your fingers :) I've seen this done for physical chips before too, but I can't recall anything - hence vagueness
- dezgeg 4y ago
  I wonder if one could bind-mount some other proc file (say /proc/$EVIL_PID/cmdline) over cpuinfo to fake content. Would meet root and be visible in mount output though.
  - stormbrew 4y ago
    You definitely can and things like that are precisely why bind mounts (usually) require root, because POSIX is built very much on the premise of one filesystem tree seen by both privileged and unprivileged users. Other systems do better by not depending on that.
  - raimue 4y ago
    It would be easier to intercept the open() for the /proc/cpuinfo file with a LD_PRELOAD library. Of course that would still be detectable by the benchmark. You could also use a modified libc to spoof it. Then their only way out would be static linking. You could even just modify the kernel to report arbitrary strings in /proc/cpuinfo. So they use the CPUID instruction instead. The CPUID instruction can be trapped to throw a SIGSEGV instead of returning real values on x86 with arch_prctl(ARCH_SET_CPUID, 0). So an injected SIGSEGV handler could then spoof it. But even then, you could also trap the CPUID instruction in the kernel, and spoof it from there, which would be even harder to detect from user space. In the end, the benchmark program always needs to trust the kernel. Is it really worth trying to detect spoofing?
ilyt 4y ago
It's because hypervisor intercepts the call for CPUID and returns what you told you to. It's usually used to downgrade a set of features if you want VM to be able to be live-migrated between machines with different CPUs, we migrated a bunch of stuff off Intel to AMD that way. There is a performance hit on that as you're basically making virtual "lowest common denominator" CPU
- bravetraveler 4y ago
  Thank you! I was aware of the downgrading for live-migration, but not that there was a particular call for it
pjc50 4y ago
That's a VM. It will be trapping CPUID at the instruction level and returning whatever the VM is set up as.