I made my VM think it has a CPU fan(wbenny.github.io)
wbenny.github.io
I made my VM think it has a CPU fan
https://wbenny.github.io/2025/06/29/i-made-my-vm-think-it-has-a-cpu-fan.html
199 comments
Writing this from a passively cooled (Streacom FC8 Evo) Linux PC with a Russian keyboard.
Sensor data:
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x002C, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0029
Type: <OUT OF SPEC>
Status: <OUT OF SPEC>
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Cooling Dev 1
Handle 0x002F, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0029
Type: <OUT OF SPEC>
Status: <OUT OF SPEC>
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Not Specified
Handle 0x0037, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0036
Type: Power Supply Fan
Status: OK
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Cooling Dev 1
Sensor data:
iwlwifi_1-virtual-0
Adapter: Virtual device
temp1: +59.0°C
acpitz-acpi-0 # Fake, always reports these temperatures
Adapter: ACPI interface
temp1: +27.8°C
temp2: +29.8°C
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +51.0°C (high = +86.0°C, crit = +92.0°C)
Core 0: +51.0°C (high = +86.0°C, crit = +92.0°C)
Core 1: +47.0°C (high = +86.0°C, crit = +92.0°C)
Core 2: +49.0°C (high = +86.0°C, crit = +92.0°C)
Core 3: +49.0°C (high = +86.0°C, crit = +92.0°C)> Streacom FC8 Evo
I normally think PC cases are gaudy and boring even when trying to evoke some style. That stuff in Streacom website however makes me want to build something with it.
I normally think PC cases are gaudy and boring even when trying to evoke some style. That stuff in Streacom website however makes me want to build something with it.
LTT did a video with the SG10 a couple months ago. Really neat concept.
https://www.youtube.com/watch?v=iLHC2_gByQ8
https://www.youtube.com/watch?v=iLHC2_gByQ8
Isn’t it just a smoother-looking typical industrial PC case? Always liked them though, too.
I am not sure what an "industrial PC" means. Inside, there are heat pipes connected to the CPU, and one side of the case (where these heat pipes lead) serves as both a heatsink and a surface with fins for convective cooling.
Industrial PCs are computers meant to go in industrial environments. They vary quite a bit but often have to handle dirty (possibly explosive or corrosive) air, 24v power, wide temperature ranges, lots of electrical and radio noise, and being cabinet mounted.
If you've got a little Node-RED box reading serial data from your bar code reader, doing lookups in your SAP database, and then sending Modbus commands to your PLC to redirect a box down a different conveyor line, it's probably an industrial PC.
If you've got a little Node-RED box reading serial data from your bar code reader, doing lookups in your SAP database, and then sending Modbus commands to your PLC to redirect a box down a different conveyor line, it's probably an industrial PC.
Streacom makes fanless and air-cooled cases computers that aim to look good. Their products target an audio/video and enthusiastic pc building market. I would say they would be on the same category as Silverstone.
Yeah, that sounds quite different than industrial PCs, where the engineer specifying it spends 10 minutes pouring over specs and 2 seconds looking at the picture.
It doesn't need to be one or the other. It takes some engineering work to design something like https://streacom.com/products/db4-fanless-mini-itx-case/#fea....
Passively cooled PC probably won't work because the board will still have fan headers even if nothing is connected to them.
So we just need to implement the opposite of what OP has on our PCs, i.e. make OS think there are no fans.
Board vendors ought to start including a BIOS option to hide fans from DMI.
Yes and another method of controlling them.
External cooling device?
The computer knows there's a fan because it sees tacho output. If it doesn't see tacho, shrug. You can get an external temperature-controlled PWM controller for a few units of your local currency on AliExpress, steal 12V from somewhere (Molex header or whatever) and run the fans off that. Figure out where to put the temp sensor to get the desired effect.
There are far better ways to do this, but they require software engineering, not €3 and 15 minutes.
There are far better ways to do this, but they require software engineering, not €3 and 15 minutes.
The computer knows there is a fan because it knows when there isn't a fan. By subtracting where there is a fan from where there isn't a fan, or where there isn't from where there is (whichever is greater) it obtains a difference, or deviation...
"because it knows when there isn't a fan"
How does the computer knows that? You mean the parts that can meassure temperature will meassure where it gets warmer, or where it doesn't get warmer, altough it should?
How does the system knows, it is not a local heat pipe, transferring heat away?
How does the computer knows that? You mean the parts that can meassure temperature will meassure where it gets warmer, or where it doesn't get warmer, altough it should?
How does the system knows, it is not a local heat pipe, transferring heat away?
(the comment you're replying to is a meme - https://knowyourmeme.com/memes/the-missile-knows-where-it-is)
The problem is not the fan, it’s the fan controller on the motherboard. I doubt a nonfancy fan controller will bother to drop off the bus/whatever if it doesn’t have fans connected, and the comment by 'patrakov upthread seems to confirm this.
I feel like we could make our operating system more secure and make things easier for researchers by simply making a normal OS look like a virtual machine. Any program that needs to access resources in a non-virtualized way would have to ask for permission first. If granted, it could then see the relevant information or access the necessary APIs.
This way, malware authors would have to choose between making things easier for researchers or targeting far fewer people.
Either way, everyone except the malware creators wins.
This way, malware authors would have to choose between making things easier for researchers or targeting far fewer people.
Either way, everyone except the malware creators wins.
Genode / SculptOS[0] go this direction. Before starting any process, you craft a view of the hardware resources it will see. Applications come with resource request definitions which you can satisfy by attaching real, virtual, or null resource.
It's a pretty neat system; runs Doom, so we know it's production ready; and the source is meticulously organized.
The docs try to be overly general, IMHO, clouding the core ideas. If you're interested, I recommend just spinning up a VM and mucking about, along with the user guide.
[0]:https://genode.org/download/sculpt
It's a pretty neat system; runs Doom, so we know it's production ready; and the source is meticulously organized.
The docs try to be overly general, IMHO, clouding the core ideas. If you're interested, I recommend just spinning up a VM and mucking about, along with the user guide.
[0]:https://genode.org/download/sculpt
Anti-cheat software vendors would lose as well. I prefer the software I run to know its place, but there are enough people who enjoy multiplayer games that hate cheaters more than they hate what amounts to spyware.
I wonder if gaming cyber cafes that have no input ports that only play against another PCs of the same cyber franchise would be a sustainable business venture "no cheaters, no need to install spyware in your own device, warm coffee brought to your table just by clicking a desktop shortcut"
This is basically the value proposition for game consoles, for both players and game developers. For the player, secure gaming-specialized device that they don't have to set up and manage in the way a general-purpose computer requires. For the developer, a standardized trustable platform where they can avoid much of the anti-cheat complexity by letting the platform maintain security instead.
Definitely not enough people caring about anti-cheat spyware.
The other important incentive would be games that cannot be cheated, I saw a few games on steam that have reviews informing potential buyers that the games have been ruined because the devs didn't implement a successful anti-cheat system.
> simply making a normal OS look like a virtual machine
Or perhaps the other way around?
That is making VMs totally unaware they've been virtualised, as I believe IBM's lpars work…
Or perhaps the other way around?
That is making VMs totally unaware they've been virtualised, as I believe IBM's lpars work…
That doesn't seem like it would be possible, if you want all the convenient hooks in VM's for them to be able to integrate with and be usable from the host system.
The solution really does seem like implementing those same hooks in non-VM environments, but preventing their actual usage behind permissions. In a VM, the permissions could genuinely be granted or denied. In a non-VM they would always be denied. But malware could never be able to tell why it was denied permission.
The solution really does seem like implementing those same hooks in non-VM environments, but preventing their actual usage behind permissions. In a VM, the permissions could genuinely be granted or denied. In a non-VM they would always be denied. But malware could never be able to tell why it was denied permission.
If that were easy, this article wouldn't exist.
"Simply"
This is a huge, huge, huge amount of work. Even the most obvious things -- like "can you run a VM?" -- can require huge support, in that case even from the hardware, when you want to do them within a VM.
This is a huge, huge, huge amount of work. Even the most obvious things -- like "can you run a VM?" -- can require huge support, in that case even from the hardware, when you want to do them within a VM.
Welcome to mobile development.
Oh please no. That would make using PC and writing apps a chore. There is a reason why nobody really works with mobile OS or Chrome OS.
Isn’t this exactly the idea with Flatpak on Linux and Sandbox on Mac?
I am yet to see _any_ consumer-oriented motherboard where SMBIOS descriptions have even a passing relationship to the actual hardware. I would not be surprised if this malware would also fail in 50% of real hardware out there. But I also guess malware can afford this failure rate; as long as it guarantees it also fails on 100% of VMs/debuggers, it is worth it.
But if these assumptions are true then I'd presume malware authors would do timing checks rather than the trivially "emulable" SMBIOS.
But if these assumptions are true then I'd presume malware authors would do timing checks rather than the trivially "emulable" SMBIOS.
> I am yet to see _any_ consumer-oriented motherboard where SMBIOS descriptions have even a passing relationship to the actual hardware.
This seems to be especially true for cheap chineese boxes. If I had a dollar for every time I saw "to be filled in by OEM" strings in "live/production" BIOS images ... i'd be retired :).
This seems to be especially true for cheap chineese boxes. If I had a dollar for every time I saw "to be filled in by OEM" strings in "live/production" BIOS images ... i'd be retired :).
Bonus points for a non-unique UEFI UUID that is already enrolled in some random company's Microsoft Intune / Windows Autopilot instance so when you fire it up off a fresh Windows install it begs you to sign into $RANDOM_COMPANY_WITH_BAD_IT_CONTROLS.
Triple-points if the vendor includes a sticker telling you to complete Windows OOBE without connecting it to the Internet to avoid this.
Triple-points if the vendor includes a sticker telling you to complete Windows OOBE without connecting it to the Internet to avoid this.
I still can't believe that microsoft allows companies to essentially brick machines they don't even own like that. Seems criminal to me.
More criminal than hard coding UUID for some other device?
You can do whatever you want with your device. Microsoft is also doing whatever they want with your device.
If the OEM hadn't messed up and reused UUIDs, it would be "Microsoft letting companies do whatever they want with their device", which is not unreasonable. OEMs reusing UUIDs for some ridiculous reason is breaking down the chain of "whose device is it".
Forget about the OEM. If you find out someone else's UUID you can spin up a VM with your UUID set to theirs and then add it to your system and brick their machine?
Mistakes happen. It is inevitable at scale. So maybe we need softer recovery processes?
I’m fairly sure my expensive ASUS ROG motherboard (ergo: not even their budget line) also had a “to be filled in by OEM” string that I couldn’t even override. (ASUS have a utility but it’s not publicly available, probably just for computer shops)
But that's exactly the point. Computer shops that sell complete systems are supposed to put their name in the "system manufacturer" field. If you bought the mainboard yourself and built your own system, then who do you think should have replaced that string?
I get that, but I'd expect it to be a setting I can change in BIOS, or at least default to the motherboard's model number. Instead, if I build my own, I just can't change it ever because ASUS refuse to release it publicly. Hell, even the shop I used for the previous PC didn't have such a tool. (And if you change it in Windows, it's rewritten from SMBIOS every boot)
I worked in PC stores for a long time and never had any such access to such a tool. Sounds like something only the big OEM's would get honestly.
It's mentioned in some ASUS docs, but it's not available on their support anywhere. Probably reserved for big OEMs, yeah.
I stumbled upon that feature in the (MS-DOS based) bios flashing utility for some mainboard, via some command line option. Just don't remember which one it was, it was ages ago.
Okay but we're talking about consumer-grade boards sold at retail here. It's not like these are boards that fell off a truck. ASUS sells them this way, but then doesn't give consumers a way to alter that field.
How about set it to default "Asus", and computer shop has tool to override it
Then you can't tell it apart from systems that were actually built by Asus. But given that most smaller shops don't seem to have access to the tool anyways, we'd then just have the opposite situation.
Need I remind you of the ASUS Zenbook UX21 from 2011, almost the first machine to be branded an “Ultrabook”, that experienced sudden shutdowns under Linux (but not Windows) because its ACPI firmware scribbled over random places of I/O space in an attempt to initialize a SATA controller the SSD-based machine did not physically have? (Can’t find the link now, sorry.)
If you buy a motherboard to build your own (or any, even if it is for someone else) PC, you are the OEM.
That's basically my experience for 2 other "gaming" motherboard brands that aren't ASUS as well. My guess is that people who build their own PCs probably don't care about SMBIOS serial numbers being properly populated, so why bother?
I would care if I could change it, but you need a proprietary tool that you can't obtain. (Every other way I found involved patching the UEFI and turning off Secure Boot)
# Manufacturer: Micro-Star International Co., Ltd.
# Product Name: PRO Z790-A WIFI (MS-7E07)
$ sudo cat /sys/firmware/dmi/tables/DMI | strings | grep -i filled | wc -l
10
But this is correct, if the Mainboard was bought as is and was not part of a complete system, the system manufacturer is obviously not filled out as there is none.
Malware has bugs. In fact some viruses have done far more damage than the author intended due to bugs.
There was a substantially effective virus years ago that made it around the world in 90 minutes, and it turns out a bug in its networking code caused it to spread half as fast as it should have. Meaning it should have been everywhere in 45 minutes. You can still do a lot of damage without hitting every machine in existence.
There was a substantially effective virus years ago that made it around the world in 90 minutes, and it turns out a bug in its networking code caused it to spread half as fast as it should have. Meaning it should have been everywhere in 45 minutes. You can still do a lot of damage without hitting every machine in existence.
How does Linux find the fans these days? Is it an ACPI/EFI thing now? Nearly all my machines seem to have correct fans/sensors.
Through a bazillion of practically motherboard-model-specific hacks:
https://lxr.linux.no/#linux+v6.7.1/drivers/hwmon/
https://lxr.linux.no/#linux+v6.7.1/drivers/hwmon/
Yes acpi is far more reliable.
Is it the actual malware checking this or some researcher-created malware samples?
Using such tricks might seem like a cute way for malware to make analysis difficult, but often times calling these obscure system APIs can be detected statically, and you bet that it will flagged as suspicious by AV software. If the malware binary is not obfuscated to hide such calls, I'd even call them "counterproductive" for the malware authors!
The legit programs interested in these APIs are almost always binaries signed by well known (and trusted) CAs - making it sensible for the analysis to report sus behavior.
I worked as a junior in this field, and one of my tasks was to implement regex pattern matching to detect usages of similar APIs. Surprisingly effective at catching low hanging fruit distributed en masse.
The legit programs interested in these APIs are almost always binaries signed by well known (and trusted) CAs - making it sensible for the analysis to report sus behavior.
I worked as a junior in this field, and one of my tasks was to implement regex pattern matching to detect usages of similar APIs. Surprisingly effective at catching low hanging fruit distributed en masse.
Malware is signed surprisingly often these days, you can't rely on malware companies not to sign their binaries anymore. Hacked code signing certificates seem to be all over the place and Microsoft seems very reluctant to revoke trust out of fear of actually breaking their original customers' software.
Same goes for the common vulnerable drivers that malware likes to load so they can get into the kernel. A weird tiny binary making WMI calls may stand out, but a five year old overclocking utility full of vulnerabilities doing the same queries wouldn't.
From the research I've read, this doesn't seem to be about avoiding detection as much as it's about not detonating the real payload on a malware analyst's machine. If the AV flags the binary or the detection trips, the second stage isn't downloaded and the malware that does stuff that makes the news doesn't execute (yet).
Same goes for the common vulnerable drivers that malware likes to load so they can get into the kernel. A weird tiny binary making WMI calls may stand out, but a five year old overclocking utility full of vulnerabilities doing the same queries wouldn't.
From the research I've read, this doesn't seem to be about avoiding detection as much as it's about not detonating the real payload on a malware analyst's machine. If the AV flags the binary or the detection trips, the second stage isn't downloaded and the malware that does stuff that makes the news doesn't execute (yet).
>Hacked code signing certificates seem to be all over the place and Microsoft seems very reluctant to revoke trust out of fear of actually breaking their original customers' software.
AFAIK most (all?) code signing CAs are cracking down on this (or maybe Microsoft is pushing them) by mandating that signing keys be on physical or cloud hosted HSMs. For instance if you try to buy a digicert code signing certificate, all the delivery options are either cloud or physical HSMs.
https://www.digicert.com/signing/code-signing-certificates
AFAIK most (all?) code signing CAs are cracking down on this (or maybe Microsoft is pushing them) by mandating that signing keys be on physical or cloud hosted HSMs. For instance if you try to buy a digicert code signing certificate, all the delivery options are either cloud or physical HSMs.
https://www.digicert.com/signing/code-signing-certificates
It's a change to the CA rules that was passed in https://cabforum.org/2022/04/06/ballot-csc-13-update-to-subs... to align OV certificate requirements with the EV ones (that enforces the use of HSMs/hardware tokens/etc) that was meant to go into effect for new certificates issued after November 2022, but was delayed and eventually implemented on June 1 2023.
The trick is to become a company like "CrowdStrike", get your crappy software that runs at kernel level signed, then you can run all of the "suspicious" calls to sys apis all you want. Forget determining if it’s a VM or not.
Just push untested code/releases on production machines across all of your customers. Then watch the world burn, flights get delayed, critical infrastructure gets hammered, _real_ people get impacted.
_Legitimate_ companies have done more damage to American companies than black hat hackers or state actors can ever dream of.
The folks behind xz util within libzma aspire to cause the amount of damage companies like ClownStrike and SolarWinds have caused.
Just push untested code/releases on production machines across all of your customers. Then watch the world burn, flights get delayed, critical infrastructure gets hammered, _real_ people get impacted.
_Legitimate_ companies have done more damage to American companies than black hat hackers or state actors can ever dream of.
The folks behind xz util within libzma aspire to cause the amount of damage companies like ClownStrike and SolarWinds have caused.
So, from a security perspective, maybe we should run all software inside a VM then?
You'd lose things like hardware acceleration.
That said, plenty of malware will stop downloading additional modules or even erase itself when it detects things that could indicate it's being analysed, like VirtualBox drivers, VMWare hardware IDs, and in the case of some Russian malware relying on the "as long as we don't hack Russians the government won't care" tactic, a Russian keyboard layout.
It won't stop less sophisticated malware, but running stuff inside of a VM can definitely have viruses kill themselves out of fear of being analysed.
That said, plenty of malware will stop downloading additional modules or even erase itself when it detects things that could indicate it's being analysed, like VirtualBox drivers, VMWare hardware IDs, and in the case of some Russian malware relying on the "as long as we don't hack Russians the government won't care" tactic, a Russian keyboard layout.
It won't stop less sophisticated malware, but running stuff inside of a VM can definitely have viruses kill themselves out of fear of being analysed.
> You'd lose things like hardware acceleration.
This is increasingly less true. SR-IOV and S-IOV are becoming increasingly common even in consumer hardware and OS manufacturers are increasingly leaning on virtualisation as a means to protect users or provide conveniences.
WSL has helped with virtualisation support quite a bit as a means of getting hardware manufacturers to finally play nice with consumer virtualisation.
And Microsoft is even now provides full ephemeral Windows VM "sandboxes". The feature that came with them that surprised me was that they support enabling proper GPU virtualisation as well.
This is increasingly less true. SR-IOV and S-IOV are becoming increasingly common even in consumer hardware and OS manufacturers are increasingly leaning on virtualisation as a means to protect users or provide conveniences.
WSL has helped with virtualisation support quite a bit as a means of getting hardware manufacturers to finally play nice with consumer virtualisation.
And Microsoft is even now provides full ephemeral Windows VM "sandboxes". The feature that came with them that surprised me was that they support enabling proper GPU virtualisation as well.
But then you have your "VMs" accessing the real hardware, so the benefits of the VM reduce if not disappear. You literally can't have the cake and eat it too.
Not entirely? The virtualised PCIE frameworks (SIOV, SRIOV, etc) don't actually give direct access to the hardware but rather create a virtualised device inside the PCIE device akin to how modern PCs virtualise CPUs and memory.
Well, that's precisely the point of these frameworks. They give direct access to the hardware in order to gain the speed advantages of ... directly accessing the hardware. The PCIe aspect of this is just (very high level description) a way to let the hardware know what VM is making the request.
You're now at the mercy of the hardware manufacturer on whether there's isolation between the different "partitions" or ... nothing at all. Your attack surface expands in a way that's difficult to imagine.
You're now at the mercy of the hardware manufacturer on whether there's isolation between the different "partitions" or ... nothing at all. Your attack surface expands in a way that's difficult to imagine.
> They give direct access to the hardware
> You're now at the mercy of the hardware manufacturer
No!
Read up on SR-IOV before you continue posting more misleading nonsense.
https://en.wikipedia.org/wiki/Single-root_input/output_virtu...
> You're now at the mercy of the hardware manufacturer
No!
Read up on SR-IOV before you continue posting more misleading nonsense.
https://en.wikipedia.org/wiki/Single-root_input/output_virtu...
And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message?
Your one link literally says the same thing I have said (a way to multiplex access to the bus). This is ALL about giving VMs direct access to hardware. It makes no sense to even discuss features like this otherwise. What do you think this is for if not real hardware acess? Giving VM hosts an easier time emulating Intel PRO1000 ethernet cards?
Your one link literally says the same thing I have said (a way to multiplex access to the bus). This is ALL about giving VMs direct access to hardware. It makes no sense to even discuss features like this otherwise. What do you think this is for if not real hardware acess? Giving VM hosts an easier time emulating Intel PRO1000 ethernet cards?
This is a better description of what it's doing:
SR-IOV: https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer...
S-IOV: https://cdrdv2-public.intel.com/671403/intel-scalable-io-vir...
What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything.
This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU.
And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) and all of the context associated, the registers, the BAR, etc. This is akin to how VT-x and similar instructions virtualise the CPU (and registers, etc). And notably these virtual functions can be restricted via access controls, quotas, etc in hardware.
So your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general). Now SR-IOV and S-IOV virtualise the PCI-E bus w/ access control over the lanes. And now SR-IOV and S-IOV virtualise the PCI-E device hardware and their functions/interface on the bus (akin to VT-x and VT-d).
Now notably S-IOV should be seen as a "SR-IOV 2.0" rather than an accompanying feature. It essentially moves the virtual function to physical function translation from the CPU or hardware in the chipset directly into the PCI-E device itself.
SR-IOV: https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer...
S-IOV: https://cdrdv2-public.intel.com/671403/intel-scalable-io-vir...
What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything.
This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU.
And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) and all of the context associated, the registers, the BAR, etc. This is akin to how VT-x and similar instructions virtualise the CPU (and registers, etc). And notably these virtual functions can be restricted via access controls, quotas, etc in hardware.
So your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general). Now SR-IOV and S-IOV virtualise the PCI-E bus w/ access control over the lanes. And now SR-IOV and S-IOV virtualise the PCI-E device hardware and their functions/interface on the bus (akin to VT-x and VT-d).
Now notably S-IOV should be seen as a "SR-IOV 2.0" rather than an accompanying feature. It essentially moves the virtual function to physical function translation from the CPU or hardware in the chipset directly into the PCI-E device itself.
I do not understand what results in this confusion.
> What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged
This is exactly what I know and what I said in my original post: a way to identify which VM is accessing what. For... giving that VM access to the hardware.
> and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything.
Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from.
This is entirely the definition of giving the VM direct access to the hardware. There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface.
For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise.
> This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU.
Not at all. Usually IOMMU is for constraining hardware that already has direct access to the RAM in the first place.
> And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions)
Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view).
> your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general
This is meaningless because it mixes and matches everything. What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c).
But the entire point of this is again to give the VM direct access to hardware! What is it exactly that you want to refute from this?
> What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged
This is exactly what I know and what I said in my original post: a way to identify which VM is accessing what. For... giving that VM access to the hardware.
> and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything.
Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from.
This is entirely the definition of giving the VM direct access to the hardware. There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface.
For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise.
> This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU.
Not at all. Usually IOMMU is for constraining hardware that already has direct access to the RAM in the first place.
> And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions)
Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view).
> your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general
This is meaningless because it mixes and matches everything. What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c).
But the entire point of this is again to give the VM direct access to hardware! What is it exactly that you want to refute from this?
> This is exactly what I know and what I said in my original post: a way to identify which VM is accessing what. For... giving that VM access to the hardware.
Yes but the whole point is that it's moving the isolation of the VM's access from software to hardware. Yes you are giving direct access to a subset of hardware but that subset of hardware is configured from outside the VM's access to restrict the VM's access.
> Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from.
That's not actually true to my knowledge. S-IOV and SR-IOV require hardware support. Sure the manufacturer can do a shit job at implementing it but both S-IOV and SR-IOV require partitioning. But if you are granting your VMs S-IOV or SR-IOV access to hardware, you are at minimum implicitly trusting that the hardware manufacturer implemented the spec correctly.
> There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface.
This is true but the same is true of VT-x, VT-d, etc (i.e. the commonplace virtualisation extensions). It is no less true with S-IOV or SR-IOV other than by them being newer and less "battletested". If you use virtualisation extensions you are no longer doing pure software virtualisation anyways.
> For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise.
The exact same applies to the microcode and internal firmware on modern CPUs and the associated chipset.
> Not at all. Usually IOMMU is for constraining hardware that already had direct access to the RAM in the first place.
Yes. And VT-d extends this for VMs by introducing hardware level IO, interrupt, and DMA remapping so that the host doesn't need to do software level remapping instead.
> Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view).
I call it virtualisation because it is virtualisation. In SR-IOV it is still virtualisation but yes it is architecturally similar to partitioning with access controls however that is still virtualisation, it just prevents nesting. With S-IOV however it is full on-hardware virtualisation and supports nesting virtual devices.
> What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c).
Yes I was playing loose with the terminology. Yes RAM is already virtualised (to a certain degree) but VT-d extends that completely and allows arbitrary nesting. And yes VT-d is not required for virtualisation but it is important in accelerating virtualisation by moving it from software virt to hardware virt.
> But the entire point of this is again to give the VM direct access to hardware! What is exactly that you want to refute from this?
I think the disconnect here is that I (and I assume others) are operating under the assumption that giving the VM access to an access controlled and permissioned subset of the hardware through hardware virtualisation extensions/frameworks wouldn't fall under "giving the VM direct access to the hardware" any more than CPU virtualisation extensions do (which are essentially always enabled).
----------
Edit: Oh I should also add in that another commenter was in our comment chain. I just realised they were the one arguing that SR-IOV/S-IOV wouldn't make you at the mercy of the HW manufacturer to implement the isolation and virtualisation functionality correctly. That may help clear up some misunderstanding because I 100% get that you are reliant on the HW manufacturer implementing the feature correctly for it to be secure.
Yes but the whole point is that it's moving the isolation of the VM's access from software to hardware. Yes you are giving direct access to a subset of hardware but that subset of hardware is configured from outside the VM's access to restrict the VM's access.
> Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from.
That's not actually true to my knowledge. S-IOV and SR-IOV require hardware support. Sure the manufacturer can do a shit job at implementing it but both S-IOV and SR-IOV require partitioning. But if you are granting your VMs S-IOV or SR-IOV access to hardware, you are at minimum implicitly trusting that the hardware manufacturer implemented the spec correctly.
> There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface.
This is true but the same is true of VT-x, VT-d, etc (i.e. the commonplace virtualisation extensions). It is no less true with S-IOV or SR-IOV other than by them being newer and less "battletested". If you use virtualisation extensions you are no longer doing pure software virtualisation anyways.
> For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise.
The exact same applies to the microcode and internal firmware on modern CPUs and the associated chipset.
> Not at all. Usually IOMMU is for constraining hardware that already had direct access to the RAM in the first place.
Yes. And VT-d extends this for VMs by introducing hardware level IO, interrupt, and DMA remapping so that the host doesn't need to do software level remapping instead.
> Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view).
I call it virtualisation because it is virtualisation. In SR-IOV it is still virtualisation but yes it is architecturally similar to partitioning with access controls however that is still virtualisation, it just prevents nesting. With S-IOV however it is full on-hardware virtualisation and supports nesting virtual devices.
> What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c).
Yes I was playing loose with the terminology. Yes RAM is already virtualised (to a certain degree) but VT-d extends that completely and allows arbitrary nesting. And yes VT-d is not required for virtualisation but it is important in accelerating virtualisation by moving it from software virt to hardware virt.
> But the entire point of this is again to give the VM direct access to hardware! What is exactly that you want to refute from this?
I think the disconnect here is that I (and I assume others) are operating under the assumption that giving the VM access to an access controlled and permissioned subset of the hardware through hardware virtualisation extensions/frameworks wouldn't fall under "giving the VM direct access to the hardware" any more than CPU virtualisation extensions do (which are essentially always enabled).
----------
Edit: Oh I should also add in that another commenter was in our comment chain. I just realised they were the one arguing that SR-IOV/S-IOV wouldn't make you at the mercy of the HW manufacturer to implement the isolation and virtualisation functionality correctly. That may help clear up some misunderstanding because I 100% get that you are reliant on the HW manufacturer implementing the feature correctly for it to be secure.
> And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message?
Violate..? Relax, dude.
You only had to read the very first sentence, but let me paraphrase:
> In virtualization, single root input/output virtualization (SR-IOV) is a specification that allows the isolation of PCI Express resources for manageability and performance reasons.
Violate..? Relax, dude.
You only had to read the very first sentence, but let me paraphrase:
> In virtualization, single root input/output virtualization (SR-IOV) is a specification that allows the isolation of PCI Express resources for manageability and performance reasons.
This does not imply what you think it implies. SR-IOV is about multiplexing the _bus_ itself, and offering a way for the devices to recognize which VM it is talking with. It cannot even define what devices do with this nor how they do it because _devices are a myriad_.
Counterexample #1: a SRIOV ethernet card that still allows multiple domains (partitions, virtual functions, whatever) to access the same PHY (aka ethernet port). Who is doing the "bridging" here? The PCIe bus? How do you think that even remotely works? Explain to me like a 5 year old, please.
Counterexample #2: a GPU with SRIOV. Each domain can still access a portion of the VRAM from the GPU. How do you think that works, if it is not the GPU itself who is doing the multiplexing? What do you think a PCIe standard even _has anything to do_ with this. How could it even have something to do?
The GPU is not necessarily even exposing its entire VRAM through PCIe at all. At most, it is exposing the registers that allow you to tell how much VRAM to give each partition through a PCIe BAR. And you can tag the one for each partition with a different VF in the same way you could tag them with a different base address or literally ANYTHING.
I do not understand why you (and the sibling guy) seem to think a standard for a _bus_ is even relevant to counter the argument that all of this is for VMs to make direct access to the hardware. You quote a communications standard for this hardware to be accessed by a host with multiple VMs running concurrently. This is, if anything, _even more evidence_ that this is for VMs directly accessing hardware.
Again: I claim that what you're doing here is directly connecting your VMs to the hardware, where before they were not, only through a software emulation layer. You claim that this is not true, and that I couldn't be more wrong, because there is this magical interface that makes the hardware appear as if it actually was several instances. You totally miss the point: if anything, this makes your VMs _easier to directly connect to hardware_, not less.
In fact, the very second sentence:
> SR-IOV is commonly used in conjunction with an SR-IOV enabled hypervisor to provide virtual machines direct hardware access to network resources hence increasing its performance.
And how is SR-IOV hardware going to magically appear as several interfaces, we leave that for the reader as an exercise, because you will not like the response: closed source firmware, likely an order of magnitude less reviewed than even the worst VM hardware emulator you can think of.
Much more efficient, though.
I am sorry, but you are not making the right argument.
Counterexample #1: a SRIOV ethernet card that still allows multiple domains (partitions, virtual functions, whatever) to access the same PHY (aka ethernet port). Who is doing the "bridging" here? The PCIe bus? How do you think that even remotely works? Explain to me like a 5 year old, please.
Counterexample #2: a GPU with SRIOV. Each domain can still access a portion of the VRAM from the GPU. How do you think that works, if it is not the GPU itself who is doing the multiplexing? What do you think a PCIe standard even _has anything to do_ with this. How could it even have something to do?
The GPU is not necessarily even exposing its entire VRAM through PCIe at all. At most, it is exposing the registers that allow you to tell how much VRAM to give each partition through a PCIe BAR. And you can tag the one for each partition with a different VF in the same way you could tag them with a different base address or literally ANYTHING.
I do not understand why you (and the sibling guy) seem to think a standard for a _bus_ is even relevant to counter the argument that all of this is for VMs to make direct access to the hardware. You quote a communications standard for this hardware to be accessed by a host with multiple VMs running concurrently. This is, if anything, _even more evidence_ that this is for VMs directly accessing hardware.
Again: I claim that what you're doing here is directly connecting your VMs to the hardware, where before they were not, only through a software emulation layer. You claim that this is not true, and that I couldn't be more wrong, because there is this magical interface that makes the hardware appear as if it actually was several instances. You totally miss the point: if anything, this makes your VMs _easier to directly connect to hardware_, not less.
In fact, the very second sentence:
> SR-IOV is commonly used in conjunction with an SR-IOV enabled hypervisor to provide virtual machines direct hardware access to network resources hence increasing its performance.
And how is SR-IOV hardware going to magically appear as several interfaces, we leave that for the reader as an exercise, because you will not like the response: closed source firmware, likely an order of magnitude less reviewed than even the worst VM hardware emulator you can think of.
Much more efficient, though.
I am sorry, but you are not making the right argument.
Soundlike having a virtual.Russian keyboard and installing VMware tools or virtualbox addons to host and not using them is the new low overhead antivirus.
> You'd lose things like hardware acceleration.
I've been gaming through a VM for the last few years now, and hw acceleration is not an issue.
You would passthrough a GPU and then enjoy near native performance.
I use iGPU for my Linux desktop and a dGPU passed through to my gaming vm.
I also passthrough the whole bluetooth device to the VM as I don't use bluetooth on my host anyway. That way I can use gamepads and headset in the vm, too.
> That said [...]
Now you're just riffing.
I've been gaming through a VM for the last few years now, and hw acceleration is not an issue.
You would passthrough a GPU and then enjoy near native performance.
I use iGPU for my Linux desktop and a dGPU passed through to my gaming vm.
I also passthrough the whole bluetooth device to the VM as I don't use bluetooth on my host anyway. That way I can use gamepads and headset in the vm, too.
> That said [...]
Now you're just riffing.
That leaves you vulnerable to side channel attacks. From a security perspective, we shouldn’t run software at all, but if you have to, just use AWS Lambda.
My response is in the queue, please be patient.
I want it and I want it now. Screw your event based system
What kind of side-channel attacks? You mean caching-related?
We wouldn't need to if we used capability-based operating systems.
Every app would have a long permissions dialog. Every app would want to read your CPU fan for no good reason (just as another piece of fingerprint) so you'd get use to clicking accept so you could use any apps at all. The malware would still get through. This already happened on mobile.
> This already happened on mobile.
It happened on mobile because Android (dunno iOS's permission model well enough) is more on the developers' side than the user's side, or at least they're more concerned with everything just working (for some values of "just work") than with giving users a chance to make sure that things don't work that the users don't want to work. A fine-grained capacity system where users were given the option to lie to the software about what capacities it has wouldn't be perfect either, but it would remove a lot of the user-focused pain points of Android's permission model.
It happened on mobile because Android (dunno iOS's permission model well enough) is more on the developers' side than the user's side, or at least they're more concerned with everything just working (for some values of "just work") than with giving users a chance to make sure that things don't work that the users don't want to work. A fine-grained capacity system where users were given the option to lie to the software about what capacities it has wouldn't be perfect either, but it would remove a lot of the user-focused pain points of Android's permission model.
It would be a non issue, if the options are not just allow/disallow, but also offer to provide random/fake data, so bad apps would not actually know if the permission is allowed or if the data is fake.
That’s how the Xbox works too
IIRC the xbox one onwards (switching from PowerPC to AMD x86) gave them synergy with AMD's efforts to push hard into servers with virtualization, as well as MS pushing Azure
Qubes OS exists
Anti virus software just guessing what is and isn’t malware by analysing static calls is actually really annoying. If you’re doing that then why not just make an allow list of trusted software and mark any software not in that list as being malware. It’ll work just about the same.
That's pretty much exactly how it works now. We instead analyze programs and guess that they're safe.
Well, after we send a copy of the program to Microsoft, of course
Well, after we send a copy of the program to Microsoft, of course
I friend of mine in the infosec business spends most of their time (it seems to me) to make their malware honeypots super representative of their respective hardware. Whether its a windows XP based thermostat, a Siemen's PLC controller, or a banker's desktop PC, its kind of amazing the things they do.
I surely hope there are no windows XP thermostats.
Curiosity got the better of me: https://www.crestron.com/Products/Catalog/Inactive/Discontin...
My home builder tried to get us to use crestron and we noped out of that. Their stuff feels like it's a relic of the X10 days and has bonkers price tags. A single lightswitch that can dim is $200-$300 from them. And that doesn't include the hub to control things that costs (IIRC) $2-$3k.
In comparison, a lutron switch is $70 and the hub is $50.
In comparison, a lutron switch is $70 and the hub is $50.
I wouldn't consider a Lutron light switch to be a direct comparison to Crestron. Crestron targets the ultra wealthy by being very reliable (assuming setup by a competent programmer) with unified control of pretty much everything household - shades, lights, audio, video, etc. They're aiming for the kind of people who will pay a premium to make sure their house just works, every time, without having to deal with tech issues.
You could certainly bodge together a similar system for less money, but the controls won't be as nice and it'll be nowhere near as hassle free long term. HomeAssistant and competitors have really been catching up in the past few years though, i'm excited to see competition in the market. I wish they could all play nice together with reasonable APIs :/
You could certainly bodge together a similar system for less money, but the controls won't be as nice and it'll be nowhere near as hassle free long term. HomeAssistant and competitors have really been catching up in the past few years though, i'm excited to see competition in the market. I wish they could all play nice together with reasonable APIs :/
Lest this mislead anyone, that's a touch panel not a thermostat. Pretty much all of Crestrons panels and Processors (the brains of the system) ran some form of windows embedded. They've switched the current generation over to linux I believe.
Don't buy your HVAC systems from Crane.
This reminds me of how having the right SMBIOS was necessary to create a working Hackintosh. There are so many of these relatively obscure APIs which have been added to the PC over the years, which are often overlooked by those writing virtualisation software, and malware and other VM detection software often tries to poke at them to see how real they look.
A next step to making the VM look real is having simulated temperature sensors that actually change in response to CPU load.
A next step to making the VM look real is having simulated temperature sensors that actually change in response to CPU load.
> simulated temperature sensors that actually change in response to CPU load.
Or maybe just increments to absurd numbers or negative values. Or locks up when probed. Either way could be fun.
Or maybe just increments to absurd numbers or negative values. Or locks up when probed. Either way could be fun.
> Or maybe just increments to absurd numbers or negative values. Or locks up when probed.
unironically that would mimick a bunch of existing hardware out there. I owned a PC motherboard that always reported a -65535c in a non existing sensor.
my guess is some sensor described but non existing, probably reporting an infinite value of resistance of some unused pin...
unironically that would mimick a bunch of existing hardware out there. I owned a PC motherboard that always reported a -65535c in a non existing sensor.
my guess is some sensor described but non existing, probably reporting an infinite value of resistance of some unused pin...
When I was a teen and made a malware for the Apple II : I could inoculate disks by putting the hex value $50 in an unused place of the VTOC that was stored on disk. $50 is P which stands for Parasite. This was before the word virus had taken hold and I called my program a parasite. I could prevent the parasite from infecting my and my friends DOS disks with this benign change.
> Some malware samples are known to do various checks to determine if they are running in a virtual machine.
Not just malware, but some apps are known to do this too, e.g. WeChat.
There needs to be a better virtual machine that tries to emulate everything, including random walks for GPS, IMU noise, barometric noise, temperature fluctuations etc.
Not just malware, but some apps are known to do this too, e.g. WeChat.
There needs to be a better virtual machine that tries to emulate everything, including random walks for GPS, IMU noise, barometric noise, temperature fluctuations etc.
That’s nothing. I make my VMs think they have dust.
I wonder if making a user endpoint actually look like a VM could help? Maybe adding some VM like flags to throw off some malware?
I feel that bad actors would catch on, but it might offer some protection for some low hanging vulnerabilities?
This has applications for other kinds of malware. I used to work in ads, to put it mildly, and all this stuff about blocking the trackers at the DNS level or something? Very silly stuff.
If you want to fuck up surveillance capitalism, you send plausible but wrong information to the trackers. There are a zillion ways to do this: let one through now and again and replay it, do a P2P browser extension that proxies you and someone near you through each other, subtly corrupt it, bounce it off a mullvad node. The possibilities are endless.
If you got a fair number of people doing it, you could even have some collective bargaining, like let some of the extreme value conversion stuff through in return for concessions on the more egregious tracking-for-the-sake-of-tracking.
Sure they'll checksum and shit, but that's a cat-and-mouse game they lose: the typical tracker cookie fire isn't worth shit, it's Superman 2 fractions of a basis point, so even modest effort playing smart against it drives the effective CPM negative.
If you want to fuck up surveillance capitalism, you send plausible but wrong information to the trackers. There are a zillion ways to do this: let one through now and again and replay it, do a P2P browser extension that proxies you and someone near you through each other, subtly corrupt it, bounce it off a mullvad node. The possibilities are endless.
If you got a fair number of people doing it, you could even have some collective bargaining, like let some of the extreme value conversion stuff through in return for concessions on the more egregious tracking-for-the-sake-of-tracking.
Sure they'll checksum and shit, but that's a cat-and-mouse game they lose: the typical tracker cookie fire isn't worth shit, it's Superman 2 fractions of a basis point, so even modest effort playing smart against it drives the effective CPM negative.
isn't this what initiatives like Ad Nauseam do?
There's lots of interesting things in dmidecode, including the asset tag of the machine. If anyone is interested, on both Lenovo and Super micro servers you can set the asset tag. Lenovos do it with Redfish, with Supermicros, you have to use their "sum" tool.
Using it, you can also modify the model name and serial number of your Super micro motherboard. Which cam be useful when your idiot system integrator can't be assed to set them correctly themselves.
Using it, you can also modify the model name and serial number of your Super micro motherboard. Which cam be useful when your idiot system integrator can't be assed to set them correctly themselves.
There are moments where I consider myself a good engineer and then I read posts like this and realize im a very little fish in a very big ocean
I guess that's a gap for a new tool to be developed. Emulate as much hardware as possible, to make a VM look like a real PC. Maybe also faking the CPU ID, to fake another CPU type with less performance (from the same series), so malware can't even detect the lower performance caused by virtualization, or lower core count.
Also see the effort people go through to fake out minecraft/roblox so they can run via a VM
Fascinating article. It prompted two questions for me:
1) With the level of expertise, would it be as easy, or easier, to modify the check in the malware itself?
2) How much work would it be for a something like KVM to fake absolutely everything about a PC so it was impossible to tell it was a VM?
1) With the level of expertise, would it be as easy, or easier, to modify the check in the malware itself?
2) How much work would it be for a something like KVM to fake absolutely everything about a PC so it was impossible to tell it was a VM?
I wonder if this could be used to throttle vms, like I'd like to set something like "this vm can only use at most x% of a cpu" measured over y time.
> Your first impulse might be to use DLL hooking and patch the cimwin32. But that’s smol pp way of thinking. We can do better.
What's wrong with DLL hooking though?
What's wrong with DLL hooking though?
Pretty funny that a blog post talking about complex and innovative ways to help investigate malware has a block of the lowest quality, scummiest ads that probably lead to malware.
> Frankly, I did not miss this at first. I just hoped that what I was trying to do was not “overriding” the predefined structure.
> Because Xen (or rather hvmloader) does not define it.
> So, before defining it myself, I tried to find out if there was any other poor soul who tried to do the same thing before me. And to my disappointment, there was. Right in the xen-devel patch archive.
> Why it was my disappointment, you may ask? Because after reading the response to the patch, I felt the frustration of the author.
Specifically, the patch is annotated "SMBIOS tables like 7,8,9,26,27,28 are ne[c]essary to prevent sandbox detection by malware using WMI-queries."
And the rejection is in two points:
(1) Why is that valuable?
(2) What if there were other tables that also helped with that goal? Your patch doesn't include them.
> Because Xen (or rather hvmloader) does not define it.
> So, before defining it myself, I tried to find out if there was any other poor soul who tried to do the same thing before me. And to my disappointment, there was. Right in the xen-devel patch archive.
> Why it was my disappointment, you may ask? Because after reading the response to the patch, I felt the frustration of the author.
Specifically, the patch is annotated "SMBIOS tables like 7,8,9,26,27,28 are ne[c]essary to prevent sandbox detection by malware using WMI-queries."
And the rejection is in two points:
(1) Why is that valuable?
(2) What if there were other tables that also helped with that goal? Your patch doesn't include them.
> (2) What if there were other tables that also helped with that goal? Your patch doesn't include them.
If there's anything I've painfully learned in my career, is to not let perfect get in the way of good enough.
If there's anything I've painfully learned in my career, is to not let perfect get in the way of good enough.
Misread the title as "I made my VM think it WAS a CPU fan" and was a bit disappointed to find the actual article was not about a VM with an identity crisis.
I haven't bought a computer cooled by a fan in over 13 years.
If you don't mind sharing, what's your exact setup? Fanless laptop (having read many of your previous comments - and found them very inspring -, I'm aware of your modest/text-only needs) or something really spartan like a USB-booting OS, etc? Many thanks.
[deleted]
What an arcane piece of tech. Why not use EFI?
Lovely writeup! 10/10
Hang on, does this mean the MacBook Air is less vulnerable to some malware?
Mitre ATT&CK's T1497.001 (VM Detection) lists SMBIOS checks as a known vector means its open for injection anyways.
i did one little expirement on faking VM's powersupply. done it with 'HotReplaceable=Yes' and 'Status=OK', and you suddenly look like a $5k baremetal server.
cmd used
pip install dmigen dmigen -o smbios.bin \
--type0 vendor="American Megatrends",version="F.1" \
--type1 manufacturer="Dell Inc.",product="PowerEdge T630" \
--type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1
i did one little expirement on faking VM's powersupply. done it with 'HotReplaceable=Yes' and 'Status=OK', and you suddenly look like a $5k baremetal server.
cmd used
pip install dmigen dmigen -o smbios.bin \
--type0 vendor="American Megatrends",version="F.1" \
--type1 manufacturer="Dell Inc.",product="PowerEdge T630" \
--type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1
FYI: You need two line breaks to force an actual break on HN, or you need to indent each line by two to force code mode.
This has always striked me as a weird choice, out of all places, one would think the generally computer savvy and technical "forum" would respect formatting as inputted, specially with how often code is discussed
[flagged]
Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
The psychological wellbeing of ~2 million men in the US feels interesting to me, but sounds like we disagree there.
The problem is it doesn't achieve anything to vent about it here. These kinds of complaints are best taken up with the author.
Appreciate you engaging on this, and I have sent an email to the author.
I personally found that venting about it did achieve something — disagreeing with folks in the comments prompted me to look up concrete numbers on how many men are likely to experience shame around their penis size.
I also think it helps nudge social norms towards making that kind of language less acceptable (both here on HN and elsewhere), and in a best case may have prompted some folks to reflect on how they speak and write.
Is that speculative benefit worth the conflict it created? I think so — when managed appropriately, conflict is a normal and healthy part of most human relationships. And IMO the wellbeing of ~2 million men is worth stirring the pot a little.
But you might disagree and you're the mod, so for better or worse your opinion is the one that matters here.
I personally found that venting about it did achieve something — disagreeing with folks in the comments prompted me to look up concrete numbers on how many men are likely to experience shame around their penis size.
I also think it helps nudge social norms towards making that kind of language less acceptable (both here on HN and elsewhere), and in a best case may have prompted some folks to reflect on how they speak and write.
Is that speculative benefit worth the conflict it created? I think so — when managed appropriately, conflict is a normal and healthy part of most human relationships. And IMO the wellbeing of ~2 million men is worth stirring the pot a little.
But you might disagree and you're the mod, so for better or worse your opinion is the one that matters here.
I hear you, it's just that the guidelines are there for a reason, which is to optimize discussions for intellectual curiosity. Avoiding generic tangents is an important part of that. We hope we can be the kind of place where people can resist the urge to succumb to either titillation or indignation when an article includes what is clearly intended as a silly joke. We all know what it's like when someone reacts to this kind of thing at a dinner party or in a classroom.
This is a blog post, not a journal. I don't think he should be policing his language in his own work.
Sounds like we have a difference of opinion here.
The large majority of humans adapt our language to the context and the audience every time we open our mouths or put our hands on the keyboard. I’d like the author to do a little more of that.
The large majority of humans adapt our language to the context and the audience every time we open our mouths or put our hands on the keyboard. I’d like the author to do a little more of that.
This forum needs a code of conduct. We need to be civil and productive. But I think a blog post should have more freedom. If the author made an ignorant choice of phrase, then a comment about it would be appropriate. But choice of dark/crass humor should not be reprimanded. I don't want to be posh and well mannered in my own home. No masks; let me be as disgusting and pathetic as I can be.
I found that jarring as well. I'm all for mixing in a jovial, even immature tone to keep technical blog posts interesting but at the very least I'd prefer to keep it non-vulgar.
Personal sites are like the last bastions of free speech on the internet, you really want to censor that because it may offend someone who is voluntarily reading it?
I’m not advocating for censorship, just expressing a desire for people to be intentional about their language.
Men are routinely shamed for their bodies, especially penis size, and I think it makes their lives worse. So I’d like people to stop doing it.
Men are routinely shamed for their bodies, especially penis size, and I think it makes their lives worse. So I’d like people to stop doing it.
Our language? Whose language is that, person in the link aggregator comment section of someone else's blog post?
English, the language that I personally own and get to make all executive decisions for of course :)
I wouldn't bet on it. A guy in my city has a "SML PP" custom license plate. I'm not sure on the reasoning either.
I wouldn’t bet on it either unfortunately. But a girl can dream.
I would sooner remove posts calling people out for harmless jokes as if they were a moral offense.
It may feel harmless to you, but research consistently shows a large proportion of men feel insecure about their penis size [1].
Let’s assume those studies are off by an order of magnitude and it’s only 1% of men who feel insecure about their penis. In the US, that’s still 1.7 million men.
If I had to choose between vulgar jokes and two million people having a better relationship with their bodies, I know where my priorities lie.
[1]: https://www.issm.info/sexual-health-qa/what-percentage-of-me...
Let’s assume those studies are off by an order of magnitude and it’s only 1% of men who feel insecure about their penis. In the US, that’s still 1.7 million men.
If I had to choose between vulgar jokes and two million people having a better relationship with their bodies, I know where my priorities lie.
[1]: https://www.issm.info/sexual-health-qa/what-percentage-of-me...
No.
Alternatively, yes.
No. You as a woman have no no say in how men talk to each other. You don't know what it's like to be a man.
whall6(2)
What's up with the body shaming in this article?
> But that’s smol pp way of thinking
> But that’s smol pp way of thinking
Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Every once in a while I manage to forget I’m a woman in a space that’s not friendly to women, and then I come across something like this.
I don't think "smol pp" is meant to be unfriendly to women, but it's telling that men are expected to self-police such utterly innocuous jokes when women are present even though you couldn't find a phrase less applicable to women if you tried.
Oh I'm sure it's not meant to be unfriendly to women. It's meant to be unfriendly to men, who are the only people reading the article, in the author's mind. You do see the problem, yes?
If I make a joke about hammering a nail with a screwdriver in an article, I'd not feel like I'm implicitly excluding people who do not own a screwdriver.
[deleted]
...no? I'm pretty sure men don't have a problem putting down other men in front of women.
If you’re writing a piece like this, you’re naturally going to pick an insult that will land with your audience, right? If you read an article where the author says “that’s training bra thinking,” obviously the author is envisioning women reading the article. If you read an article where the author says “that’s smol pp way of thinking,” obviously the author is envisioning men reading the article. That was all I was saying: I was just reading along and suddenly I was reminded that I’m in an industry where men write articles for men, and any women who happen to show up really aren’t expected to be there.
> If you read an article where the author says “that’s training bra thinking,” obviously the author is envisioning women reading the article. If you read an article where the author says “that’s smol pp way of thinking,” obviously the author is envisioning men reading the article.
Again... no?
If you read an article where the author says "that's training bra thinking", the author is female.
If you read one where the author says "that's smol pp thinking", the author is male.
Again... no?
If you read an article where the author says "that's training bra thinking", the author is female.
If you read one where the author says "that's smol pp thinking", the author is male.
All right then. What a fascinating way of looking at the world.
Because they think it's funny. Personally, I just found it off-putting and stopped reading.
Ain’t no way, that was my favorite part
Has me picturing the author ambling down the road in a truck with a penguin bumper sticker alongside another adornment attached to the trailer hitch...
> smol pp way of thinking
apt install laugh
apt install laugh
naikrovek(2)
And also set up a Russian keyboard: https://krebsonsecurity.com/2021/05/try-this-one-weird-trick...