Holland Bans AMD's 'Virus Protection' Campaign

Hack Jandy writes "For those of you who didn't see this coming, AMD's Advanced Virus Protection campaign has been banned in Holland since the technology does (almost) nothing to stop viruses! If you recall, AMD's NX bit attempts to stop the processor from executing pages on the stack that have been written to. Does NX even solve more problems than it causes?"

How do you explain it to Joe Sixpack?

What the "NX bit" actually does is a pretty nice thing for preventing buffer overflows... if a segment of memory is marked for data use and then the code execution point somehow arrives there, you get a crash-out instead of the execution of arbitrary code.

Of course, AMD's problem is finding a way to try to communicate that concept to the average user. Joe Sixpack doesn't even know what buffer overflow problem is, so they don't understand why they need a solution to that problem. AMD is trying to use the concept of "virus prevention" instead, but apparently they've gone too far in implying that the NX bit eliminates the need for conventional anti-virus methods, which it most certainly does not.

This is an extra set of suspenders, not a new belt.

Re:How do you explain it to Joe Sixpack?

This is akin to OpenBSD's W^X, which specifies that memory can be either Writable or eXecutable but never both. Wikipedia has a good stub on it, [wikipedia.org] as well as a nice article on the NX bit [wikipedia.org].

Re:Self-modifying code?

This is the kind of thing that NX breaks. One notable situation is that Java, .NET, and anything else that dynamically generates code will break if not properly coded. My understanding is that you have to specifically request that a data page be executable. In an OS that uses the NX bit normal data pages will be marked as not executable. I recall seeing something from Microsoft telling developers how to fix their software so this wouldn't be an issue when they updated the OS to use the NX bit (XP SP2, I believe).

Re:Self-modifying code?

It's worth noting that on most OSes, Windows included, a program that writes code to memory and then expects it to be executable without any further intervention is buggy. Windows has required a system call to make the memory executable for a long time, it's just that it wasn't actually necessary before. The programs that NX breaks were always buggy, it's just that the bug was never exposed.

Re:How do you explain it to Joe Sixpack?

Apparently, code loaders such as DLL loaders and JITs have to explicitly go through a syscall to copy from writable memory to executable memory.

Re:How do you explain it to Joe Sixpack?

Okay. Does this carry computational costs? I.e. is it a true copy or does it just do some trickery with VM pages? If the former, does the cost of stopping everything, blowing out the cache, etc to duplicate the written executable code become significant?

Re:How do you explain it to Joe Sixpack?

You can just map the same physical memory to two different addresses - one place for writting and another for executing. This way there is no overhead involved, although it weakens the protection to some degree.

Re:How do you explain it to Joe Sixpack?

Yes. Windows XP SP2 has it but calls it "DEP" (Data Execution Prevention). It took this directly from OpenBSD in thier "Secure by Default" campaign.

Re:How do you explain it to Joe Sixpack?

NX doesn't fix anything.

If I'm overflowing a stack buffer, I'll just write the address of system() over EIP and the address of a string I control after that. Then when the function returns, it will execute system("/whatever/program/i/want").

Maybe not quite as convenient as shellcode for crackers, but virus writers will adapt and NX will mean nothing.

Re:Its only part of the solution.

There are ways around that. The true solution to the problem is to not overflow your buffers!

Re:How do you explain it to Joe Sixpack?

"If I'm overflowing a stack buffer, I'll just write the address of system() over EIP"

A software stack check will already catch that. (a random number stuck under the stack frame, checked before returning. You could overflow the buffer, but you can't know what random number to write because it changes each time -> failed exploit.)

IBM did some work to put a similar feature into GCC:

http://www.research.ibm.com/trl/projects/securit y/ ssp/

Re:How do you explain it to Joe Sixpack?

Let's just say it's impossible to market something like this. In their ad they said something like "AMD processors are the only processors which actively stop/prevent viruses". Surely that's not something a CPU can do at all anyway.

And since this is only a minor improvement (if an improvement at all) in the Athlon64 I wonder why they didn't think of something else to use to promote the CPU... Surely saying that the thing is 64-bit must impress some Joe Sixpacks.

Re:How do you explain it to Joe Sixpack?

"What does 64bit mean? Obviously 32 is working for me, why do I need this. Now virus protection, that I need."

Thats why. They don't have to explain what being a 64bit processor means and why they need it, because most people don't, but everyone need virus protection and for the most part they already know that.

I have yet to see a good reason why I should get an A64, beyond the 'dude holy shit its faster then last months model.'

Re:How do you explain it to Joe Sixpack?

I have to call you on this one. It's only a "pretty nice thing" in theory, since the option has to be enabled during the compilation of the binary.

Sorry, but this isn't true - NX protection has nothing to do with compiling binaries. It is runtime protection.

In Windows (even XPsp2), this is only enabled for certain MS-created services that listen on ports. It has to run in PAE mode. Not every application is protected. Significantly, the user-space apps are not protected. You have to specify /PAE option, despite what MS says [microsoft.com].

This is unfortunate but true, the default for processors that support it really should have been to turn it on for all apps. As it is, you have to go into Control Panel->System->Advanced->Performance->Data Exec Protection and enable it for all apps yourself. It does work quite exactly how it should when you do, tho - warning you and shutting down apps that attempt to execute data as code.

So, moderators. How does the original post deserve such a high ranking? It's factually incorrect on a few points, and just makes general statements about "safety is good". The trend appears to be that early posters get points, and everyone else carps and trolls. What a shit hole slashdot has become. (I can recall when a 90-post story was big news, and most of the posts were useful... but don't get me started.)

So, moderators, how does an AC who posts factually incorrect statements also get a +4 Insightful? Is it just because he said "So, moderators"?

buffer overflows

It helps deal with buffer overflows which is a way to deal with some malware exploiting them.

Eh, whatever.

I don't understand really why AMD felt a need to make an ad campaign over the technology anyway. Most uses for this technology are buffer overflow preventions, which are almost exclusively server technology. Admittedly, it is possible for any program that makes a remote connection to accept data or idles waiting for data to possibly be vulnerable, but for a userland machine this would be mostly messaging programs and p2p programs.

I think it would have made sense to put it as a nice side feature so that geeks see the technology and how it prevents buffer overflows, but they probably already know about it.

Re:Eh, whatever.

"untrusted source"

Fluffy bunny code is untrusted, continue to install?
No.
You won't be able to see the fluffy bunnies if you don't install. Continue install?
No.
You don't want to not install?
No.
Installing Fluffy Bunny.
HULK SMASH!

Not just for servers

Windows XP uses NX now as of SP2. Its part of its Data Execution Protection scheme. DEP can run without an AMD too. Its on by default for windows system files.

Buffer overflow exploits arent just for servers either, the RPC/DCOM exploit was one. So was the previous big worm, err blaster? I don't quite remember.

This is tech for the desktop, really. Modern computers run a slew of services.

Good thing everything is submitted by a tard.

NX doesn't cause any problems asshat, it is something that real CPUs have had for years, that allows an OS to make sure no pages of memory are both writable and executable, helping prevent exploit code from working.

Does it rely...

Does this NX thing rely on the evil bit? If so, no wonder it doesn't work! *duck*

Re:Does it rely...

For those of you who don't remember the evil bit, it's RFC 3514 [faqs.org].

I thought NX was...

Hardware for preemptive multitasking... built in to the chip and not just software... not really having anything to do with viruses but more about buggy code. I must be thinking about something else...

What is a "virus" to most people

Given that, in common parlance, most people don't know the differences between the various exploits "virus" is as good a word as any.

And if the NX bit were used for more than the stack, then it could protect against a lot of (non-trojan) viral activity too.

Lets face it most viruses today aren't even viruses. They are trojans, worms, and human-engeneering exploits. How often do you see an actual virus? You know a program that writes its code into another program. It's actually getting kind of rare. Now days it is whole applications delivering themselves to your computer through email and exploiting the existing code of crap like IE and Outlook by just telling those programs to run the evil code. Most exploits today are applets and packages.

All But Gone are the days of rewritten exe headers wiht appended code fragments, and programs appending themselves to other programs in memory.

Quite frankly if all the non-code memory regions in my computer were non-execute down to the very last GDI region and printer buffer, the classic virus would be dead. The IE hacks and the trojans and the worms would still be here because certian stupid programs will do arbitrarily complex things at the behest of remote entities, but that isn't a virus. Thats bad design comming home to roost.

Finally someone cracks down on stupid marketing

Reclame Code Commissie of the Netherlands, an organization that regulates advertising in the country, recently said some or all AMD EVP radio ads were "too absolute and as a result misleading"

Almost all CPU advertising is misleading, first of all because it has to paint with such a broad brush. The NX bit plays only a tiny role in virus prevention. The much-hyped Hyperthreading was only of questionable benefit and certainly not worth paying extra license costs for most people. Dual cores may be a mixed bag if I read my cards correctly. I can think of lots of examples... But, misleading advertising is allowed anyway.

Well, I guess this time someone got caught. I hope this trend continues. If I have to be subject to censorship rules, why shouldn't the marketing people at AMD?

Hum.

So my first reaction was that I'm not so sure about this one. There exist worms which use buffer overflows to propigate themselves. NX could potentially protect against such worms. Referring to a worm as a "virus" may not be strictly accurate but it isn't unreasonable, unless there's some quirk of the Dutch language at play I'm unaware of. If infection by Code Red, or any other buffer overflow based worm of the last few years which targeted end-users, could have been prevented by running a chip with NX functionality, then referring to this as "virus protection" may be a tiny bit silly, but not unreasonable. Certainly not deception on the same scale as the Pentium 4 "IT WILL MAKE THE INTERNETS MORE FUN" ads.

...then I actually RTFA.

Reclame Code Commissie of the Netherlands, an organization that regulates advertising in the country, recently said some or all AMD EVP radio ads were "too absolute and as a result misleading", according to Tweakers.net web-site. The regulators pointed out the fact that the technology needed Service Pack 2 to be installed on a PC running Microsoft Windows XP operating system and was able to protect only against a number of malicious programs.

So it appears that the complaint wasn't against the claim NX "protects against viruses", the complaint was that the advertisements did not make necessary disclaimers like "requires special operating system support". This seems definitely reasonable on the regulators' part.

This said, I have heard it claimed that NX technology is rediculously easy to circumvent. Specifically, I saw a long post by Linus Tourvalds somewhere in which he noted that NX provided protection against some classes of buffer overflow attacks, but not all, and then outlined various ways in which someone attempting a buffer overflow under Linux could potentially simply structure their buffer overflow so as to circumvent the protections NX offers. The post was very technical and I could not tell if the statements were general or just byproducts of the way Linux handles stack and such. Does WinXP suffer from these same problems with regard to the efficacy of an NX bit?

Re:Hum.

As has been said over and over by people who understand NX, it is simply one more arrow in the quiver, not a panacea to stop all viruses.

A well crafted buffer-overflow attack that overwrites the return instruction pointer on the stack to point to existing code elsewhere will not be caught by NX. NX catches *execution* of code
from non-allowed pages as pre-determined by the OS; but it does not block data writes.

For now, it creates more problems than it solves.

In a recent cluster installation, we noticed that any tool (IBM's RAID console and the PolyServe cluster files system managment console) involving Java aborted with SIGSEGV errors. This was a Redhat ES 3.0 u3 installation on IBM e336 (dual Xeon 3.06 GHz) systems. Run the tools, immediate BOOM!

Noting that the problem was the JRE blowing itself out of the water with SIGSEGV (and talking to friends that had installed the same OS and same software on different hardware) led me to do some more research. "strace" can indeed be your friend. It seems that AFAICT the NX feature was added to the Xeon processor versions (stepping) that were in our machines. There was no way to disable the feature in the BIOS. There is a little, er, confusion in the various documentation about the kernel's behavior, but "noexec=on" is the default as far as I can tell.

So, what (apparently) happened here?

[personal opinion] Intel, rushing to counter the AMD marketing blitz about the wonders of "no execute", put the feature into their newest Xeon CPUs, possibly before the BIOS functionality caught up. The Linux kernel's choice of defaulting the new feature to "on" (theoretically the best choice) unfortunately resulted in numerous "issues", particularly in applications (simulators, virtual machines, etc.) that commonly execute things within the stack segment. This is done all the time in this class of application. The software development community hadn't caught up to the new feature, either. It seems that there are linker attributes that can disable the behavior (still researching this). [/personal opinion]

If you Google for this issue you will find that virtually (pun intended) anyone that relies on a JRE on Linux (Oracle, IBM, etc.) was affected iff the hardware did the NX bit. Our solution was to download the latest JRE from a source on the Web (Sun in this case) and hope that we did not run into Java compatibility issues or that the JRE versions in the software packages were not bolted in.

We squeaked by with our solution, but it only cost about a whole day figuring it out. Time is cheap. Technical problems are fun, especially with a customer watching all of the game over your shoulder. "You have done this before, right?"

Interesting that this should happen

I was speaking to someone on a forum just recently, and they mentioned how their processor had "built in virus scanning." After a bit of an argument (he was quite convinced that it was truly virus scanning) I ended up correcting him, and simply explained that it could help stop a "bad program from tricking your computer into doing something it shouldn't."

It's a shame that they couldn't come up with a better way to market this ... because it's definetly misleading to those who don't understand what it does and can easily become an issue of semantics for people who might confuse "virus protection" with "antivirus software." And in a world where the blue E on grandma's desktop = The Internet(TM) this may be happening more than it's apparent.

Can understand..

I can understand the stance that the Dutch took in regards to the NX issue. Ultimately, these commissions need to ensure that the information given out by companies such as AMD are as clear and accurate as possible, and I'm sorry, when they say, "advanced virus protection", after putting my end-user hat on for two minutes, what the advertisement is basically saying is this; "throw out all your anti-virus software, this new CPU can not only protect you like a normal virus protector, but does it even better!"

With that being said, however, the other flip side is how thinly do they want to slice the information; many things in IT can't be simplistically put down to a few catch words; the people to blame for this over simplification aren't the engineers, most engineers would love to give the information straight to the customer and say "here is the information, make you decision based on that", on the other side, the people who sell these products tend to have limited information technology knowledge, and not only misunderstand technology but try to break down things into simplistic language in when reality, they're complex matters now matter how much they're rephrased.

So, I guess it is more of an issue of trying to weigh up on one hand, informing customers of a product feature whilst at the same time realising that some aspects of technology are just plain well complex.

How to stop Buffer overflow .

Why do we have these anymore ?

Why don't the people at Monopolysoft start using more secure libraries with visual c/c++ ?

Performance hits are worth it.

Buffer overflows not the issue on Windows

On Windows systems, no, it's not buffer overflows that are the major problem and the CPU's capabilities with respect to flagging memory pages will do absolutely nothing. Humans install viruses on Windows systems. They fall for tricks, it's a social problem. Sure there are still some buffer overflow issues.

Ohh Cmon

I can't say I think the NX bit is really that big a deal, it only makes things a little harder when you can't execute code on the stack since a stack overflow lets you return program execution to any address on the system you want. Often a cleverly designed system call or another non-stack user controlled data structure will still allow the attacker to gain control.

Still it really does provide some virus protection which is alot more than can be said about most commercials. I mean is the 'lemon strength cleanser' actually a better cleanser because of the lemon. Is 'oxygenation' or whatever really important for skin care.

Maybe they manage to stop all these types of advertising exageration over there, and if so my hat is off to them. At least if they can really manage to do it objectively. Often these sorts of rules aren't applied evenly, letting false but dear cultural assumptions slide by but blocking correct but disconerting claims. For instance I have no doubt that if we had these sort of tight 'truth in advertising' laws in the US we would find condom ads forced to produce 3 peer-reviewed studies for every claim they make while gun ads would be allow to imply or outright say that carrying a gun makes you safer. But maybe other countries can pull this off, after all I'm always amazed the U.K. can function so well without an explicit constitution so who knows. If they can do it objectively my hats off to them.

The simple, but misleading explanations

I'm curious if there were any countries that had a similar reaction to past near-false advertising campaigns, such as the "The Pentium II makes the internet faster!" ad several years back.

Nobody has pointed out

That NX has ALWAYS been around. It used to be enforced and used a long, long time ago...processors stopped respoding to it, so people got lazy and coded. It doesnt "break" anything anymore than Mozilla breaks badly coded CSS pages. You people who are saying that it causes more problems are completly ignoring the REAL problem, and that is substandard coders and code!

The AMD NX feature is a long, long overdue feature that processors have been missing for quite some time, and it can prevent a LOT of misuse. I admit that AMD has made it seem like its an end-all to viruses, but trying to explain it to non-technical people isn't a simple thing.

"Pointer in memory protection"

There is a much more effective technology around since about 1988. IBM's AS/400 (now called "iSeries 400" or "eServer i5") has a feature called "Pointer in memory protection".

Every time when the processor writes an address into memory (for example, return addresses stored in stack memory by subroutine calls) the memory location is marked as containing a valid address by using a "shadowed" flag, a 65th bit (one bit of ECC memory is used, so the machine does not need special memory modules, just standard ECC memory modules). If that memory location is overwritten with data, the CPU automatically clears the "shadowed" flag. If the CPU tries to use a pointer as a memory address, that was overwritten with data before, it automatically generates an interrupt.

This feature was originally not designed to be a buffer overflow protection, but it was neccessary, because the AS/400 uses a so-called "single level storage", where all applications use the same address space. Therefore, the machine needed some method to prevent applications from writing to arbitrary locations in memory, and that's why pointer-in-memory-protection was invented.

Actually, the memory is also segmented, one segment for every "object" created by a program. Most buffer overflows can not even overwrite an address, because a character array will have its own object boundary.
For example, the following code will typically not generate a buffer overflow on an AS/400:

int main(void)
{
char space_a[20];
char space_b[20];
int i;

for (i = 0; i < 100; i++)
{
space_a[i] = 'A';
}
for (i = 0; i < 100; i++)
{
space_b[i] = 'B';
}
}

Just try it out, it should not even crash.
I tried a lot of things like these on an AS/400 Mod. 170 running V5R2 using IBM ILE C compiler.

I think, pointer protection using shadow flags is the right way to prevent execution of code inserted by exploiting buffer overflows, because all other protection methods can't prevent return-into-libc exploits, but the pointer-in-memory-protection can, so IMHO it is the only *real* protection.

Further reading: "The inside story of the IBM iSeries" by Frank Soltis (a book about the architecture of the iSeries and the POWER processors)

AMD64 Adverts Suspect Too

Don't forget that this is the company that uses a very badly retouched Apple G4 Titanium Powerbook in its AMD64 adverts. I was waling down a street in Glasgow last week and saw it in a bus shelter. You could even see where the *artist* had tried to cover the Apple logo on the lid.

Ah, here it is

This seems to be the post that hit the news:
http://gathering.tweakers.net/forum/list_message/2 2383398#22383398 [tweakers.net]

Fortunately they did not ban PaX!

Of course NX does not stop virusses and trojans. However, in itself it does only stop some memory corruption attacks, like simple stack overflows. But not many other types of memory corruption attacks.

NX is just one method to protect the integrity of the memory. What it basically does is that it allows an OS to implement separation between data and code in the memory of a running process. Many overflow and other attacks depend on writing data in the process memory and then executing it as if it was code. A virus or a trojan is usually a program. It depends on being run, not on memory corruption. Therefore protection against memory corruption brings you literally nothing.

NX in itself stops exploit writers for aproximately 15 minutes, which is the time it takes for them to adjust most of their overflows to make them work with NX. Only a hand full of attacks cannot be adjusted. So NX in itself doesn't bring you much, despite what the marketing departments of companies like AMD and Red Hat tell you.

The trick to provide good memory protection is not to only use NX, but to combine it with other protection methods. This is the approach taken by the PaX project http://pax.grsecurity.net/ [grsecurity.net].

However, there are also some PaX imitations which, unfortunately, do not implement all of the PaX technology (even though some of them claim they do or claim to be even better). Examples are: MS-Windows SP2, Red-Hat's Exec-shield and OpenBSD's W^X.

Anyways, back from the technical intermezzo to AMD marketing. These guys have the same problem which people from the PaX project, exec-shield, OpenBSD and others who produce stuff like this have: Try to explain why this stuff is useful. If clever people like Linus don't get it, then how is one going to explain it to John Doe or the PHB's of this world? ``Memory corruption? Exploits? Buffer overflows?'' ``Woah! Brain overload!'' At least they have heard the word ``virus'' a few times and have learned that ``virus = bad''. So ``NX = good'', which cannot be explained to lusers, became ``NX = anti-virus = good''. Even if it is disabled by default, if you cannot motivate people to try to look for it, they never will.

Oh yes, these patches break things. Most programmers are spoiled. They think it is normal to mess around with memory in any way they like. Few of them understand that what is convenient for them, is also convenient for exploit writers. It's like MS-DOS programmers complaining about the file permissions on UNIX.

I hope AMD takes the challenge to produce better marketing, so more people start using this technology. Even though it is badly implemented in MS-Windows, it is a small step in the right direction.

This just in

Microsoft has anounced a new patch to stop social engineering... well acually its a minor addition to the windows xp firewall that may prevent a small portion of attacks... but people won't understand that...

AMD's idea is actually quite usefull....

Quite a few virusses and hacks rely on buffer overflow errors. So eliminating that goes a long way.

In fact I think Dutch courts took it to far, or at least farther than they would have for other pruduct that mislead the public through advertising.

Don't get me wrong, I'm all for truth in advertising, but this is selective justice.

I have yet to see one laundry detergent that fail to get your cum stains out of your mothers favorite sweater to actually get banned for false advertising.

It Breaks Down Like This

VINCENT
Yeah, it's legal, but is ain't a
hundred percent legal. I mean you
can't walk into a restaurant, open
up a laptop, and start settin' NX bits.
You're only supposed to hack in
your home or certain designated places.

JULES
Those are internet cafes?

VINCENT
Yeah, it breaks down like this:
it's legal to buy it, it's legal to
own it and, if you're the
proprietor of an internet cafe, it's
legal to sell it. It's legal to
carry it, which doesn't really
matter 'cause -- get a load of this
-- if the cops stop you, it's
illegal for this to search you.
Searching you is a right that the
cops in Amsterdam don't have.

HW protection long time ago implemented on SPARC

This NX bit is a long waited hardware feature in the x86 platform. Sun Solaris developers needed a similar way of avoiding stack overflows due to arbitrary code execution. The solution was partially addressed in the Sun UltraSparc architecture with the introduction of an optional flag that could mark the stack as no executable [uwaterloo.ca]. Additionally even the unsuccessfull attempts to break this protection could be logged for further investigation.

At first this flag was disabled by default because it was not comply with SPARCv8 ABI so some (mainly bad coded) applications that relied on the execution of code inside the stack could not run as expected. Sun collaborated with its huge community of developers to address [sun.com]some collateral effects and once resolved Sun published the new SPARCv9 ABI reference guide in which the stack is no longer mapped as executable.
Currently 64-bit Solaris applications running on SPARC [sparc.org] don't need to worry about exploits that rely on malicious code execution due to stack overflows.

And the cute thing is the advert - it has a G4

You do want to look at the NX advert at the top of this page [amd.com] - an titanium powerbook G4 is used in the adverts. No AMD inside :-)

In the print versions sold locally (e..g in the HCC magazine) it is even more obvious as you see the whole machine.

Dw.

Does it cause more problems then it solves?

in my opinion, yes. It encourages sloppy programming practise. Why bother checking for buffer overruns and fixing them when the processor can be forced to just not do anything if they occur.

The actual reason

is that the campain was misleading. AMD stated their campain in such a way that it sounded like you don't need any virus protection any more.
Which we all know, isn't true.

By the way: Holland ins't the same as The Netherlands. Holland is just a small part in the west of The Netherlands. To make it more confusing: Zeeland and Friesland are also part of The Netherlands

I would have advertised it

NX

The first bit of Palladium.

Solve more problems than it causes?

I've been using the equivalent of NX on Solaris/SPARC for a couple years, now. Everything works as expected. Self-modifying code is dumb, anyway.

What this stuff really does

In order to determine what NX does, we must look back at what people have created fake NX bits for in the past. This has been used on x86 for security purposes for a while.

Let's go back a few years, to late 2000, when PaX was created. PaX (Article [wikipedia.org]) emulated an NX bit on x86 with a low-to-high and potentially extreme level of overhead depending on memory usage. Later on, a new method was devised to do this emulation with a low level of overhead, but restricted the VM space to 1.5GiB (which didn't really matter anyway).

PaX later introduced ASLR as well, to randomly arrange the address space. This can be easily defeated by reading the global offset table, or GOT; however, the GOT offset is stored in a register, and the GOT itself is stored in a randomly placed segment of memory. Finding existing useful data and program code for ret2libc attacks requires reading the GOT; reading the GOT requires finding the GOT; and finding the GOT requires injecting code.

PaX used its newly emulated NX bit to prevent the root problem from occuring. It made a definite and permenant separation between executable memory and data areas. Any memory created as executable had to be initially loaded with the code, either by mmap() or by the kernel reading in an executable .text segment. These segments couldn't become writable unless they dropped executability. Other segments could freely change read and write permissions; but they could never add the executable protection, even if they were non-writable.

Under these restrictions, code could still easily be injected into a running program, as long as it wasn't being injected into executable memory--which was never allowed to be writable for any period. Once the process changed the PC to that code, however, the CPU would trigger a segmentation fault, which PaX would handle by killing the program and complaining in the kernel log about an illegal execution attempt. In this way, only code existing in executable segments at link time (load-time or dlopen()/dlsym() linking) could be executed. This also meant that existing code could not be executed out of order without extreme luck and a blind guess as to where that code would be, since the randomization could not be examined by an attacker.

Later, in 2003, two new technologies appeared. One was OpenBSD's W^X, and another was RedHat's Exec Shield. Both used a new, fast method of approximately emulating an NX bit; however, this method was flawed; mprotect()ing a higher memory address breaks the emulation so that you get a full executable layout below that point. Unlike PaX, these also did not and do not constrict mprotect() to safe combinations. Interestingly, PaX' original logic for emulation was augmented with this new method later, but with a fallback to the original logic if the flaw was activated. The new SEGMEXEC logic was still kept, and is still recommended by many who use PaX.

There were compatibility issues with all of these. ES relied on a binary marking that would mprotect() the stack or heap on load automatically, to be executable. The ASLR in ES still had to be disabled system-wide, to my understanding, if there were compatibility issues. This was not a robust solution.

If PaX breaks something, some PaX flags can be set on the affected binary executable to A) De-restrict mprotect(); B) make all of VM executable; C) disable ASLR. This only affects the particular program itself. Trampolines can be detected and allowed if desired as well (per-binary); and RELROs can be specially set to be mprotect()able freely (system-wide).

All of these methods have some level of overhead; and some of them are inaccurate and will relax restrictions excessively under certain circumstances. These problems stem mainly from the methods of emulation used. With a hardware NX bit, however, the NX logic is handled natively by the CPU. The inaccuracies of the W^X and ES emulation method, and the

Re:good.

Exploits rarely execute from the Stack but rather the printer buffer.

Great! so I'm safe, as I have no printer connected to this computer! all those silly antivirus customers ...

Re:Holland or the Netherlands?

Oops, I wasn't finished...

The X-bit article body says Netherlands, but the title says Holland. Holland is a sub-region of Netherlands. Maybe it really doesn't matter all that much to me, but there is a difference, and some people get picky about what their country is called, and this is a common mistake for Americans to make.

The thing I really hate

Hey, I'm really sorry; I try not to let stuff like this get to me, but for this one I just can't resist. I have to say it:

Your sig sucks.

Re:... AMD is banned but ...

No choice to make - you choose AMD for the CHEAP thrill.

Re:Honest Answer

Hmm, as far as I can tell Linux has no functionality where the "Start Menu", "User Switching", or the "middle mouse button" are concerned.

However, perhaps in your ignorance you meant "GNU/Linux", though really I think you just mean GNU or more generally opensource.

In which case here I am in Gnome2...Where is that Start Menu again?

User switching? Oh yeah, I disabled that in Windows because it was so annoying (I mean, you have to do the windows update every day to stay safe, then you have to find whoever logged in to make sure they shut their apps down, etc).

Middle mouse button? What useful feature does that have in Windows. At least I can paste with it in X, which is quite the timesaving feature.

"etc" - Does that include FUD?

The Golden Rule - "A Troll for a Troll"

Re:It does little for Windows

The really question is "Where does Microsoft want to go today ?" I hope they don't think I care. I also hope that they themselves might come to know where they want to go - but they will stay out of my back pocket !

Re:It does little for Windows

Man, you really have no idea what you are talking about. In my practice (and it apparently not as limited as yours) linux software goes through a lot more stringent control than windows counter parts (say adobe or winamp or even the microsoft products). On the other hand if you look at the BSD front well buddy, OpenBSD is the only OS out there that can say that it has only 2 vulnerabilities found in it's over 5 year history. Plus it is light years ahead of the Windows kernel. It has encrypted virtual memory plus a whole bunch of other security goodies. I have yet to hear of a well mainained FreeBSD server that got hacked.

Oh yeah and if you knew anything about system design you would also know that buffer overflows increase rather than decrease as your software base grows (i.e. "problem just gets lost in the systemic noise" this must be the most dilusionate thing that I have heard in a long time). First of all there is no such thing as *systemic noise* and second of all the more stuff you install the higher the chance for a buffer overflow in your system because it has to integrate all the newlly added dlls and make sure that they play nice (in layman's terms).

Re:Is Holland a Country?

Yes, I know what a buffer overflow is. I was just saying that AMD didn't have anything to worry about, and I was expressing my OPINION about how unnecessary virus protection is, as long as you're not a dumbass.

Re:... AMD is banned but ...

That's right, it is medically [usdoj.gov] known [cnn.com] to not [cancer.ca] damage [cnn.com] people

It's safe just like alcohol [ecureme.com] and tobacco [smokinglungs.com].

There may be components in marijuana that can be medically useful, but using the plant itself (a mixture of a variety of beneficial and harmful components) isn't going to net one any benefits. It's somewhat akin to putting crude in your gasoline car versus using gasoline which is just one component refined from oil.

Re:Holland or the Netherlands? Wanna know ?

ok, here goes. The Netherlands and Holland are one and the same, so they are different names for 1 country. Holland is an old name, you see, 'Hol' is an old word for wood in dutch (= the language of the netherlands), back in the day the whole country was full of trees so they basically called it 'Land of wood'.

The Netherlands means what it says; compared to sea level countries like belgium, holland and luxemburg lie very low (not sure if 'lie very low' is the correct way to say it but you catch what I mean.), about 16 meters or so below sea level. Since a few centuries ago the Netherlands consisted of belgium, holland an luxemburg, those countries were called 'the netherlands'. As in, 'the lands which lie nether' ...

Added confusion: Holland consists of 12 'provinces', not unlike a 'county' in the US. two of these counties are called 'North-Holland' and 'South-Holland'. Those are just names, and are only a small part of the country.

Re:Dutch people

And quite right too, my AC friend. The fact that I'm not Dutch but that I do work for Philips distorts my point of view.

Re:Is Holland a Country?

Sure Holland's a country - although some Dutch would like to see all us foreigners get our tongues round "The Netherlands". In Dutch, Holland technically refers only to two of its provinces, but this ain't Dutch...
However - to the point - I can't see why the ad should be banned. After all, who would be using the latest ADM processors on machines running XP without installing SP2?
It sounds a bit silly to me. But all publicity is good publicity!
Rgds
Martin

Who cares?

Let me assure you that just about _noone_ outside the Netherlands cares about this, and the vast majority inside doesn't care either. Only a few highly frustrated provincials seem to be bothered by the fact that Holland and the Netherlands are technically not the same, the rest of us use the words interchangeably when speaking English.

Of course, the whole mess doesn't exist in the Dutch language anyway. We live in Nederland, we speak Nederlands, and we call ourselves Nederlanders - all perfectly regular. If I called myself a "Hollander" in Dutch, I would be indicating I was from either South Holland or North Holland. If I do the same in English people understand I'm from the Netherlands.

Oh, and if the audience is American, they know I'm from the capital of a country known as Kopenhagen ;-) Sorry about that, but you must understand that American tourists who are not only lost, but in fact at least two entire countries removed from where they think they are, are the stuff of legend in Europe ;-)

Re:Is Holland a Country?

The parent said what he did in a flamebait way, but he does make two good points:

1. "Holland" is not a country; "The Netherlands" is a country.

2. This is not likely to have a large impact on what AMD is trying to accomplish because the Netherlands is not a large or populous country.

MOD PARENT UP

erm, Why is this modded troll? It should be insightful!