I find Task Manager Interesting

You guys have gone WAY OVER my head about who does what and how.

But I just find it very interesting to sit here and watch the various items shown under the Performance Tab changes as I do things.

But I do notice that in the CPU History graph there is always a little red showing at the bottom of the graph.

It is also fun to sit here and watch the meter go up and down from 30% to 100% while doing a system AV scan. ( today is the day for that )

Now lets see what happens when I submit this.

BillyBob

 

You would probably enjoy messing around with the Performance utility in Administrative tools. You can configure it to graph any one of a large number of items.

After opening the program select System Monitor and then use the + sign to add counters. Begin by looking at the Performance Objects available and then the various Counters available under each Object.

Have fun.

DRD

 

First, there are 3 variations of this theme.
Intel has NX processors (No Execute)
AMD has Enhanced Virus Protection (EVP)
and
MS has DEP

So, let's see what the experts think.

Intel
....can protect data pages from being used by malicious software to execute code

....can prevent certain classes of malicious "buffer overflow" attacks

AMD

Enabled by Windows XP Service Pack 2, AMD’s EVP is designed to prevent certain types of viruses from replicating and spreading to other systems. [Note: Enhanced Virus Protection will by default only protect the user's Windows operating system. After properly installing the appropriate Windows release, users must enable the protection of their applications and associated files from memory buffer overrun attacks.

....but keeps some of the most damaging, like buffer overflow exploits, from executing at all

Microsoft

....processors that support execution protection are capable of raising an exception when code is executed from a page marked with the appropriate attribute set

See also the paragraph, "How DEP Works ".

Data execution prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to help protect against malicious code exploits


In these articles you will notice that the DEP concept is distinguishing between code areas and data areas, and what they are attempting to stop is code that is trying to be run in a data area. NOT, data that is trying to be run as code.

And the whole reason for doing this, is to try to block viruses/trojans/etc (code) that are exploiting buffer overflows, and are managing to get themselves executed even though they live in a Data area.

 

WhitPhil

Those are all very good references and agree totally with what I described above. For example, from MS

says exactly what I said above, i.e., data in memory is NOT supposed to be executed, and that correctly implies that without this protection, it CAN and possibly WILL be, depending on running software (bad program, virus, worm, etc.).

You'll note that the hardware 'protection' just sets a bit that the OS may use, if it can and so desires, to run code that enables the actual protection (=DEP), as I said.

Also from the same page:

I don't see that statement anywhere, and don’t believe that the CPU or OS can distinguish between data or program in memory marked as data; certainly the CPU isn't smart enough, and I'm not impressed that the OS is either, since it requires that data areas be marked and just uses that information to decide to act.

I don't see that either, only that it's A reason, scare tactics to justify what they're doing, which may be in part worthwhile, but actually does much more than just prevent data execution, and on computers I use it's set to Alwaysoff.

Best regards. suggest we agree to disagree.

 

sparrow
I'm not sure if we are disagreeing or arguing semantics. But I think it's a bit of both.

You say "data in memory is NOT supposed to be executed, and that correctly implies that without this protection, it CAN and possibly WILL be, depending on running software (bad program, virus, worm, etc.). "

I agree that data is not supposed to be executed. But to me, DATA can not be executed in the first place. If it can, then it is not data, it is CODE. So, your "CAN" and possibly "WILL" be, can't happen with "real" data.

And, as far as I can determine, the protection offered by the hardware/software implementations was not built to stop DATA from being executed, but rather to stop CODE, that is living in an area that should only have DATA, from being executed.

But, having said that, if the processor is asked to load an area marked as being DATA, and is asked to execute it, it will fail. And, it will fail in one of two ways. If DEP (or whatever) is protecting that area, it will fail, OR when an "unknown" opcode is attempted to be executed (for arguments sake, an ascii letter "A "), then it will fail on an invalid op-code.

This is where I believe we have the disagreement and is what I was attempting to explain above.

When the CPU is asked to load and execute an "instruction" in an area marked as data (via DEP), then the processor will cause that operation to fail.

And, that is exactly what my first link in the previous post explains.

The reason that I say that it was built to tackle malware in buffer overflows, is because I see absolutely nothing, anywhere that states it was built for any other reason. If you have any links that provide more info, I'd love to read them.

 

That's where we disagree, and I'm relying on facts I have observed, my experience. To the debugger, which sees ram just as the CPU sees it, ALL and ANY data consists of executable code and nothing else. If you'll take a look, you'll be convinced. It usually isn't executed because the program counter usually doesn't point to it, but a rogue instruction or error in coding can and HAS led to execution of data and the inevitable crash that results. This occured in the days before ubiquitous viruses and other trojans, and can still occur today. That's why DEP is named for what it is. The reason for it can be explained any way you like, but if it walks like a duck...

 

Ok. I surrender!!
But only after one last try.

But, data areas do NOT consist of executable code. UNLESS you mean that every last ascii character is also an op-code.
For example, the ascii "A" is also a PUSH op. If that is what you are saying, sure, I agree.
BUT, when the CPU gets that ascii "A" and tries to execute it as a PUSH, it then expects that following characters to contain the parameters to the PUSH. And, if these are invalid, the CPU will kick out an Invalid Op exception.

If this is NOT what you mean, I would appreciate if you could explain.

"but a rogue instruction or error in coding can and HAS led to execution of data and the inevitable crash "

Yes, of course. It's because a piece of DATA was fed to the CPU, which attempted to interpret it as CODE, couldn't and the running app either died or a fatal exception was returned.

 

We're getting closer together now.

That's just about what I mean. More specifically, the CPU sees only binary numbers, bits, in the instruction stream, i.e., whatever RAM is fed it by the program counter. It assumes those bits make up op-codes because that's all it knows about. For example, a push instruction takes the next piece of RAM as something to be pushed, and I don't see how the CPU can distinguish anything there as legal or illegal. It just does what it's told. The CPU doesn't just "attempt to interpret it as CODE ", it does interpret it as code, because that's what the CPU is designed to do.

An afterthought: Of course the above is simplified to make a point, and the actual operations are somewhat more complex. For example, the CPU is constantly informing the program through numerous 'flags' set in a dedicated register, and programmers must set up control logic accordingly as well as the intrinsic logic of the algorithm, using tools such as assemblers, debuggers, and, at higher levels, compilers - which in turn have to do the assembly too. Trouble is, I think, folks that use only compilers don't get a feel for the nitty-gritty.

 

Ah!
As I started to guess, it was primarily semantics.

Agreed.

Again, my semantics. I used the word "attempt" because if it isn't really valid, it's going to fail. But "attempt" or "does ", the end result is the same.

It essentially can do some of this, because once it determines what the particular OP is, the "complete" opcode (including parameters) is well defined. So as it continues to "attempt" to process an opcode, anything invalid about the contents of a parameter(or register) or in the format of the opcode itself, is going to end up with an exception.

The following 2 documents show the flow and the exceptions that can occur.

Instructions A-M

Instructions N-Z

The only thing that we completely disagree on is the reason for the design of the DEP feature in the hardware/software, but that is really a moot point.
It does what it does. And doesn't do, what it wasn't meant to do!!!

 

Great!

 

Sparrow

You made a comment back a little in this post somewhat to the effect "unfortunate for you if you have an amd64 ". Could I ask you why ???

I was never much of an amd fan but decided a few months back to build my own 64bit machine and at that time amd was the only production out there. After building the machine I was quite impressed at the speed this chip has and that surprised me that I would like it.

My main machine is an Intel p4/3.4 and honestly when booting or shutting down as an example the amd is much quicker at just those functions.

Never liked the k6 or k7 or even the athlon but the amd64 seems pretty nice. I have talked with you before and respect your opinion so I just was curious as to your amd64 comment.

thanks

 

gghartman

is what I said.

 

sparrow

sorry i miss read.