Hacker News Reader

Comment by justin_vanw | Hacker News Reader

When I opened the github link and saw all those .c files, I assumed it must be doing something tricky, like timing system calls or doing statistics or looking at what memory addresses are allocated or... something.

This entire repo is like a 40 line bash script, but they wrote it in C because.. they know C presumably?

The thing that really makes me curious though, how many people are running VPS's on so many clients that they need a tool to tell if it's virtualized? I can understand wanting to know, I guess, but why not just have a list like "if /proc/whatever exists, you are in kvm" instead of compiling and running this? Who would do it? Why is this on the frontpage?

View on HN

Out of curiosity how would you reimplement this file in bash? https://github.com/kaniini/slabbed-or-not/blob/master/xen-de...

In particular, the fact that it's using inline asm directly (for cpuid, ud2, some others). Maybe with 'as' but that's not exactly pure bash (and I suspect not embedding it in C would need a non-trivial main function anyway).

Reading an arbitrary memory address (for the cpuid scans) might be a bit tricky too, though it could be doable with /proc/$PID/mem.

CPUID is available in /proc/cpuinfo (or whatever the /sys or modern equivalent is, my Linux is a bit rusty)

Not sure re: UD2 though.

The point here is that the information in /proc/cpuinfo is virtualized, and therefore may not reflect reality...

Would you have to be a kernel module to access the CPU directly?

No. All binary programs access the CPU directly. Only certain instructions require being in a certain "ring" (i.e. access level). The CPUID instruction is non-privileged, meaning you can access it from user space.

Related work anecdote: I was working on IPv6 support for a C code base running on a Linux appliance. Time came for me to have a go at the traffic shaper application. Was given repository access. Had assumed the whole application was doing to be littered with IPv4 specific netlink/ioctl-stuff. Turned out most of it was string manipulation and calling tc using system(). Like less than 10 lines of bash turned in to a way bigger heap of potential failure points. Nothing against C as a language, it's just that to some people, everything is a nail.

In the face of that, this seems insignificant.

C is perfectly fine for this, and anything else, especially if you are very proficient as whoever created this library clearly is. It's going to make it MUCH more painful for people to use though, especially if they don't have gcc on their servers and their desktop isn't linux.

This is more about the "I put a VPS inside your VPS" situation, which is common amongst the providers offering Virtuozzo at budget pricing.

In that case, we do not have files in /proc to look at, we have to do it the hard way instead.

So you're trying to start a language war on HN? Or did I misunderstand?

You misunderstand. It is perfectly fine to question the use of a particular language for a particular task. It need not be meant as an attack on the language itself.

That said, this project seems to use C to make CPUID calls with inline assembly, and thus circumvent the `/proc/` interface. If this is true, it might be useful to describe your process in your README.

> it might be useful to describe your process in your README

The submitter is not the owner of the github repo. Not everyone submits their own things, a lot of people submit things they think will be interesting to others.

If you run Linux with systemd, then you already have this for the most part.

http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/...

http://cgit.freedesktop.org/systemd/systemd/tree/src/detect-...

Reply on news.ycombinator.com