The company is announcing two specific TDT features. The first is “Advanced Memory Scanning.” In an effort to evade file-based anti-virus software, certain kinds of malware refrain from writing anything to disk. This can have downsides for the malware – it can’t persistently infect a machine and, instead, has to reinfect the machine each time it is rebooted – but makes it harder to spot and analyze. To counter this, anti-malware software can scan system memory to look for anything untoward. This, however, comes at a performance cost, with Intel claiming it can cause processor loads of as much as 20 percent.
This is where Advanced Memory Scanning comes into effect: instead of using the CPU to scan through memory for any telltale malware signatures, the task is offloaded to the integrated GPU. In typical desktop applications, the GPU sits there only lightly loaded, with abundant unused processing capacity. Intel says that moving the memory scanning to the GPU cuts the processor load to about two percent.
While this is interesting, I’m already completely fed up with most anti-virus packages.
Most are riddled with false-positives, such as assuming all UPX-packed executables are viruses (or more generally, any executables with overlapping segments).
At the same time, they seem to be completely incapable of finding real threats. Time and again, when I was certain I had a virus, my anti-virus claimed no threats, or only threats I was certain were not important (such as my Watcom-compiled dlls, or tracking cookies).
Scanning memory may help the latter, but it certainly won’t help the former.
Hi,
I doubt it’ll help anything.
The types of malware they’re talking about have to re-infect the computer regularly. If the malware is detected regularly, then it just needs to re-infect the computer more regularly.
The other thing that will happen is that the malware will become more polymorphic, to reduce the chance that it matches any pattern that memory scanning is looking for.
The consequence will be an “arms race”, where the rate that memory scanning is done is increased often and the pattern matching tolerances are reduced often (to keep up with increased rates of re-infection and increased polymorphism), until we hit the point where continual false positives from anti-virus become equivalent to a denial of service attack. When we reach that point, hopefully Microsoft might start to wonder why attackers are able to re-infect a computer regularly in the first place.
For performance; I’d expect that RAM bandwidth is the main bottleneck for memory scanning; and I don’t think it will make a lot of difference if you have CPUs consuming RAM bandwidth (and slowing down everything else that needs RAM) or GPUs consuming RAM bandwidth (and slowing down everything else that needs RAM).
– Brendan
I think the bulk of work is pattern matching against a threat database. This can work on a GPU internal memory if you have it (no slack for most popular Intel adapters though).
Still the problem nowadays is not the CPU load (we have abundance of idle cores) but power consumption and this approach presents little improvement here.
no
Edited 2018-04-18 02:25 UTC
Withe the article text having no question, this not being a reply to a post with a question and no other indication of what you say no to I’ll have to guess.
My guess is that you don’t think dragons exist so I have to agree:
No.
So, in other words, they’re trading CPU usage for shitty GPU performance. I mean, it’s a decent idea, but there had damn well better be a way to opt-out. If I’m gaming, I’d much rather have them hitting the CPU than the GPU, given that many games use very little CPU time these days anyway.
While you are gaming you aren’t loading much executable code anymore so there is no need for scanning.
This is an idea that makes a lot of sense for almost all usage-scenarios. However if you are gaming while multitasking and running on battery you might loose a few frames
Nowhere have I seen it said that it only runs when loading code, and in fact, it would not make sense for it to do so, the type of transient malware they are talking about doesn’t load code though normal means, so it wouldn’t get caught by scanners only checking on code being loaded (think for example of ACE vulnerabilities found in network services, they just overwrite existing loaded code or hijack control flow directly, but they almost never need to load anything). In theory, it could hook into the creation of executable mappings and changes in memory protections, but those happen so often on any moderately used system that it just makes more sense to just do time-based periodic scanning than try to make it event triggered.
ahferroin7,
If the goal of this scanner is to catch malware in memory regardless of when/how it got there, then this would have to be run periodically even when a high intensity game is running. Otherwise there would be at least two problems:
1. Malware could hide in the games that aren’t being scanned.
2. The heuristic that determine whether or not an app is a game would itself become a means for malware to cloak itself by mimicking the behavior of games that aren’t scanned.
So clearly the effectiveness of the scans can not be as accurate if games are excluded. But another problem is that if you memory map the graphics card into system memory for the purposes of AV scanning, that could potentially open new vulnerabilities whereby the attacker gains system access through the graphics card itself. You’d have to be extremely careful about accidentally leaking anything through the graphics card!
Aside: Does anyone know if graphics cards today typically support 64bit DMA addressing or are they still mapped to 32bit (ie the first 4GB of ram)?
I’m not talking about selectively disabling it based on what’s running. I’d actually lose a lot of respect for Microsoft (not that I have much to begin with) if they implemented it that way, because it would make it trivial to circumvent. I’m talking about wanting to have an option to just completely disable it.
As far as memory mapping, this is talking about using the iGPU on Intel CPU’s, so it’s already memory mapped (unless it’s disabled by firmware), but I’m pretty sure it can do 64-bit DMA (though it doesn’t matter much if it can or not, as it will end up being behind an IOMMU on the systems that support this).
The “scanner-on-gpu” will of course be running all-the-time, but it will only have to look at code, not data. Code is mostly loaded during certain parts of the game where the gpu isn’t very active. Once that code is loaded and scanned it is most likely going to be marked clean and not be scanned again during execution. Of course that assumes https://en.wikipedia.org/wiki/Executable_space_protection and it wouldn’t protect against everything (obfuscation)
avgalen,
I can’t say how this microsoft/av scanner actually works, but in principal both data and code can get infected because we live in times when the line between them has been blurred.
Say a game uses python, a virus might become resident as a python script unbeknownst to a AV scanner that limits itself to x86 code scanning. Not scanning the data pages would miss the virus.
Or to be even sneakier, a virus could import *legitimate* code into a victim processes x86 code pages, such as microsoft’s own VBA scripting components. AV scanners can’t flag MS code as malicious based on the x86 code alone, it clearly needs more context, which resides in data pages and not in x86 code.
There are many possible variations on this, but the main point is that many kinds of resident malware could lurk in “data” memory indefinitely if you explicitly exempt it from scanning. If the goal here is to stop all kinds of memory resident viruses, then they have to scan data too. The moment you take a short cut and say “we won’t scan this”, it creates another opportunity for viruses to evade the scanner.
Yes, that is identical to the way it happens on a harddisk/ssd. Virusfiles on a disk don’t have to be scanned all the time and could theoretically lurk there without any issue for eternity. They only have to be scanned when they are about to be executed.
The same applies for memory that is being marked as no-execute. It is safe to not scan that data until that data is actually executed.
Just like you could copy a virusfile or even open it in a text-editor, it is harmless to have virus-code in memory. The only thing an AV has to do is “prevent virus-code from executing”.
Of course this is all theory and it only takes 1 bug or overflow to accidentally “execute non-executable data”. The wiki-article mentions compiler-issues in JIT for example
avgalen,
I understand what you are talking about with bugs that cause accidental data execution, however that isn’t what I’m referring to. What I’m talking about is a virus who’s resident payload does not get executed by the processor as a code page. While I do understand the performance motivation for not scanning data pages, the point I’m making here is that if you explicitly make it a policy not to scan the data, then it gives virus makers an avenue by which they can reliably escape detection by remaining resident in bytecode/script form. The virus could run in it’s own thread or schedule a timer to run periodically within the infected process.
Edited 2018-04-19 14:41 UTC
Marking scanned code clear is in itself a vulnerability in the scanner. Most malware isn’t ‘loaded as code’, or even loaded as data, it’s injected through other means (usually mechanisms that result in indirect writes to memory that’s already allocated), so you can’t rely on hooking into anything to check selectively. Beyond that though, very few things are infected by this type of malware when they are loaded, it’s usually some time afterwards, so you can’t realistically avoid re-scanning something either.
Which type of malware are you talking about? And I ask again, do you have any source for your claim that it is usually not at load but some time afterwards?
Because if it never touches persistent storage, it can’t have been loaded from it. There are some mechanisms which might count as an ‘initial load’ (for example, javascript), but as mentioned above, the only reliable way to avoid persistent storage (almost) completely is to inject the malware into a network service remotely, which by definition can’t happen when that service loads.
I’m sure the anti-cheat code being run by your game will be more than happy to let you know your GPU is running illegal code and shut you down.
Depends on the game. I actually don’t run anything these days that requires me to install a rootkit just to play, and very few games that don’t require a rootkit to be installed do anything beyond validating their code when they load and making sure nothing modifies it externally while running, neither of which are things that would flag this (and in fact, games that do that are already protected from the type of malware this is trying to stop).
Scanning for malware in memory comes down to bus bandwidth. It doesn’t matter WHAT is doing the scanning, in the end it’s just more bandwidth consumed from a finite resource. I can see Intel talking about this since they put some of the biggest caches on processors, and I’m willing to bet they WON’T be scanning cached data. Still, a processor needs to fill and empty the cache, and that means needing bus bandwidth… which is now being consumed by the GPU even when nothing is happening video wise.
A much smarter idea would be to make a completely separate module that monitors the bus looking for malware as it’s being stored to ram in the first place rather than scan all of memory looking for it after the fact.
JLF65,
Nice out of the box thinking here!
It would be a very expensive piece of hardware though, haha. Consider how fast it would need to be to keep up with memory bandwidth.
It’s necessarily observing physical addresses, but the programs are running in virtual addresses, so it would need a reverse page mapping. Furthermore I wonder how problematic it is to detect virus signatures only from fragmented writes.
The easy case is when everything is written out sequentially and the scanner can perform a linear scan strait off the bus, but what if a virus deliberately writes those pages out in a random order?
This may be similar to the out of order IP fragment reassembly problem, where you can’t pass the payload to the next network layer until all the fragments arrive. In the case of your scanner, I would think it would either have to fetch out of order fragments from memory (and slowing it down), or it would have to save it’s own mirror copy of the data.
I think it’s an interesting idea, but it may be complex and impractical to implement.
Yes, the fragmentary nature of writes vs the size of the malware scanned for is indeed the main problem with the suggestion. However, I don’t think that it’s necessary to keep the entire block in temporary storage, rather, I’d do partial comparisons and feed yes/no results to something like a neural net. Once enough partial hits occur for a particular malware, THEN the OS is interrupted and instructed to scan for the flagged malware. That should fit in a single chip without massive resources. The net could be periodically trained on new malware to recognize.
Isn’t better using a secure OS, so you don’t need to scan disks and/or memory?
Edited 2018-04-20 03:30 UTC