Slashdot Mirror
Data Execution Protection
esarjeant writes "In addition to a number of other security features, anti-virus vendors are starting to push buffer overflow detection. This will be part of Microsoft's future direction with Data Execution Prevention (DEP) and is already integrated with McAfee 8.0i. So it looks like everyone is going to upgrade all of their software again, will software vendors be able to keep up with the support calls?"
This is good news everyone, it is good to see mircosoft caring more. Thanks for your time.
Who buys viruses?
This sig made only from recycled ASCII
Support calls ?
NO
virus vendors... ???
So it looks like everyone is going to upgrade all of their software again, will software vendors be able to keep up with the support calls?
Yes, with more automation, more people on the other end (most likely in India) and more cost passed onto the customer. When I used to work we used to have a saying. "If it weren't for Microsoft, we would all be out of jobs"
Evolution or ID?
Virus vendors have been pushing buffer overflows for quite some time ...
...for a new crappy antivirus version... :-/
This might be a good test for the outsourcing model, as well. Will the software vendors who ahve outsourced fare better, or worse than those who have kept their support services based here? Might be an interesting thing for someone to watch.
The eternal struggle of good vs. evil begins within one's self.
Virus venders.. hmmm For just £39.95 a month, you too can recieve the latest virii, trojans and worms directly to your inbox.
Does that open the door to virus EULA and copywrite issues? Other than Microsoft what other virus vendors are out there?
I'm just a microcontroller guy, but can't the PC guys check their goddamn counters and pointers when using buffers? And why the hell do we still need to code buffers? Isn't there a library or a call to handle buffers in a safe way?
"Will software vendors be able to keep up with the support calls?" No. Customers are going to have to wait on hold for... Oh... Nevermind.
"So it looks like everyone is going to upgrade all of their software again, will software vendors be able to keep up with the support calls" I will be optimistic that despite the development into a new direction, and the occasional headaches, things will be better in the future. That said, why are people so negative about change? So Microsoft's SP2 broke some programs, at least they finally released it. So we have more than 640K of memory and you had to use a memory manager, at least we got past conventional memory. So at least in theory, there will be less buffer under runs in patched/upgraded systems. Would you prefer they didn't try?
I know a guy named Sig.
I hate to ask, but as a person that has never been into 'code', I have never understood what a buffer overflow was.
I am asking as a person that isn't a programmer but understands the concepts that go behind the smoke and mirrors.
It could be worse, it could be Monday.
I feel safer already.
____
~ |rip/\/\aster /\/\onkey
Cisco Systems CSA product does this and more.
Regardless of how you feel about data crimes, it is not moral for capital punishment to be applied to data, regardless of the heinessness of the alleged crime.
Microsoft and Intel are finally catching up to where DEC was back in 1992. DEC Alpha + OpenVMS = no such thing as a buffer overflow and 64 bit processing as well. Whatever happened to the future again? ;P
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
DEP will not prevent all buffer overflow attacks. It is intended to protect from the attack where the return address of the stack is overwritten to make the program jump into the stack. However, the program could still jump into a useful portion of existing code, or simply crash, or keep running but overflow a flag variable on the stack that will cause odd behaviour. It can also prevent things like JIT/HotSpot compilation. I'm not saying it's not useful at all, but it is one of many measures that all help a little.
This may sound really dumb, but isn't it up to the guy who wrote the vulnerability in the first place to fix it? (in other words wouldn't microsoft be better off fixing the code? I mean if they can detect buffer overflows then why not put a box up, infect it with everything under the sun and fix all the problems?) ps. how the hell do you detect an overflow?
If they are a small user (grandmom), they will box the damn thing up and go back to reading the paper and playing bingo at the VFW.
Eventually, someone will create a ROM-booted web applicance that has flash and pdf capability built in that they will feel comfortable using, will work for 10 years without an upgrade, and is immune to viruses because when you turn it off - everything is wiped. Their "Desktop" will be on google or somewhere external to their own system.
meh
The basic architecture is fundamentally flawed in today's 'consumer grade' computers. Using a strict Harvard architecture, where data is *separate* from code, would eliminate a lot of today's troubles.
Is it too late to change? Well, we have had new chips arise ( like power , or CELL ) so, its not impossible.. just difficult.
---- Booth was a patriot ----
The SELinux approach sounds to me like a far better way to approach this, actually controlling the permissions of a process with some high degree of precision, down to what files it can use and what other processes it can invoke.
Anyone learned in this stuff care to give a non-flamed opinion of the two approaches strengths and weaknesses? Also, do or will the newer Linux kernels do anything similar regarding stack protection?
Sometimes, serious crimes such as participating in the films "Star Trek 9" and "Star Trek 10" need serious punishment. Data is indeed guilty.
Don't blame Durga. I voted for Centauri.
"Hey, my 3ghz computer is running as slow as a Pentium 1.5ghz... Why is that?"
"Oh that's all the new virus checking that runs the executables before they run to make sure they don't have any viruses in them."
So y'see... Viruses ARE good for the industry!
It was included with Windows XP SP2. It's also in the soon-to-be-released SP1 for Windows Server 2003.
It appears that if the hardware doesn't support DEP, it will enable some sort of software DEP, instead.
W2K3 SP! also includes a new, XPSP2-like firewall interface with some nice logging and an easy-to-use rules interface. There's also the new Security Configuration Wizard, which seems to do a pretty damned good job of really locking down 2003 for those that need it.
Compilers should store data in separate protected memory segments, never embedded inside code, where overwrites can change adjacent instructions. JMPs to data segments should issue compiler warnings, and execution past original allocations should set a flag, at least in the VM. The compiler and existing VM can protect from most overflows, and is a centralized link in the chain to guard the software from every programmer, no matter how naive. If CPU vendors want to get on the bandwagon, they can offer an interrupt triggered by such boundary transgressions. Making buffer execution the exception, requiring handling, rather than the default, is a better model of coding suited best to the compilers that translate our directions to the computer into instructions to the CPU.
--
make install -not war
The huge problem with McAfee 8.0i has been figuring out a policy that protects from buffer overruns and keeps your developers happy; I've had to loosen the restrictions for those folks because as you put together stuff in vstudio and attempt to debug it, McAfee's Buffer Overrun flags it and doesn't allow it to run :(.
--pete
If you're not a techie that's a very concise, understandable, and accurate answer. I'd mod if I had the points
init 11 - for when you need that edge.
...what does it do for us? Allow Microsoft even more freedom to sell us crappy software?
Free Firefox news reader.
Stack overflow protection has been available in Linux for ages. I believe it is one of the standard kernel build options starting 2.4... Welcome to 21st century, Microsoft!
"You mortals are so obtuse." -Q
(And yes, I still write C/C++ when I need it, but that's laziness after 25 years of habitual use, and usually I use shel when I need to program :-)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
You are quite right, however, in that buffer overflow is a result of careless programming. Making assumptions about length of strings is fine if you're in a purely academic setting and under time constratints to get your programming assignments done... besides, your professors usually will tell you that it's fine. I do wish, however, they'd emphasize that while it's fine in a controlled environment, in the real world, you have to provide for checks against buffer lengths, etc.
C is still used for a lot of things because of its flexibility. Yes, you can very easily shoot yourself in the foot, but with the flexibility and power comes greater responsibility... which means anyone who uses it needs to be vigilant, always expecting the unexpected.
OCO is Loco
Stack overflow detection ?
OpenBSD has had this sort of thing for ages. And it's not limited to OpenBSD. None of this is new. It's just that MS software is so crap that they don't include it.
I still fail to understand why anyone uses MS software for much at all (I accept that it has it's place... mostly in the bin). It's such a complete bag of junk when you need to run huge globs of anti-virus software just to stop it being compromised. Anti-virus software is NOT an answer ! Why doesn't everone wake up to this fact ?
You wouldn't accept buying a new car and being told that you also needed to buy a bit of string to hold the exhaust pipe on. But the string wears out after a while so you have to replace it every few weeks. You'd laugh in the salesman's face !!!
Why do you treat a computer OS (and I use this term very loosely with ref. to MS Windows) as something that you are quite happy to have bits of string holding it together ?
It's junk. Simple.
Check it: http://www.jwz.org/doc/worse-is-better.html/
What this really implies is that the world will always be playing catch-up with the virus writers: security is only an issue when someone releases an actual threat. Until then, there's no economic incentive to do anything about it.
668: Neighbour of the Beast
Yeah. I saw the Boost Marketing headline this morning:
I dunno how I feel about competition. I'm not so sure the free security is such a winfall. After all, I've already paid for all the bugs and security holes.A feeling of having made the same mistake before: Deja Foobar
I thought everyone knew that spammers did. Most all the viruses in the last 2 years or so have been spam pushing bots. Somebody is buying the damn things and someone is selling them.
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
Having recently gotten my hands on a Windows XP box with a P4 that supported the NX bit I thought I'd turn it on, good idea right? yeah, great idea if you don't want to use half your applications. The NX bit stayed used for about five minutes. I wonder how many of Microsoft's apps will actually work with this protection turned on.
I am surprised that major distributions have not picked up and run with this great tool. One of the first things I do on any new machine is to ensure that all internet-facing services are being run with libsafe preloaded.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
Sorry, but the whole "No Execute" thang is aceite de serpiente, as they say in Madrid. Even the much-vaunted {by people who don't understand it, anyway} Harvard Architecture {i.e. using separate buses for data and instructions, thereby breaking the Neumann principle totally} doesn't work. If the computer can make some kind of decision based on the content of memory location x, then this is tantamount to x being an executable location.
Now, if you had a "Take no action whatsoever based on the content of this location, in fact, whenever you are asked even to read it, always return the same value" flag -- that might prevent the execution of unwanted code. Chances are your system would also be computationally incomplete.
As it stands, NX is trivially defeated by persuading the user to install a simple piece of code -- effectively an emulator.
Basically, NX is answering the wrong question. The question that needs to be asked is "How can we best persuade users not to run arbitrary code when they don't know what the hell it does?" My own answer would be for every processor to have its own, unique instruction set; so only code compiled for that one particular individual processor would ever run on it. {Obviously you'd have to have a compatibility mode for bootstrapping, so you could compile the compiler to compile the unique-ified software; but this would have to be accessed by some deliberate hardware action that no software could get around.} I'm sure that is not impossible; but I'm not sure that it's feasible as long as the likes of Microsoft want to do things their way.
Je fume. Tu fumes. Nous fûmes!
I have an AMD 64 with DEP (NX) enabled and on sysinternals process explorer, its reporting it as SOFTWARE under DEP Status column on the process list, how come? Isnt it suppost to be reporting as HARDWARE? Is process explorer from sysinterlans wrong or is it actually not hardware based protection mode? If not, how can i enable this?
DEP actually can be evaded because it supplies no ASLR. If the attacker can reasonably know where some data exists in memory--particularly, his exploit and msvcrt.dll for memcpy() and VirtualAlloc()--he can basically switch DEP off during an attack. Believe it or not, this is pretty easy if everything is in the same place every program run.
Fortunately in Linux we have PaX, which supplies much better protection than W^X, Exec Shield, or DEP with "competetive" (i.e. comparable, potentially lower; it can actually viably compete) compatibility. Red Hat of course has convinced the GCC devs to make GCC mark everything to have an executable stack if the compiler is at all not sure that it can operate without one; but PaX ignores that and still only "breaks" a few packages (and nVidia's glx).
PaX, GrSecurity, IBM's SSP (ProPolice), and PIE executable binaries should pave the future on Linux; but people are trying so hard to avoid them. It's not even much work to maintain a distro using those.
DEP is basically like vanilla Linux on AMD64.
Support my political activism on Patreon.
The superstition that OpenVMS was magically immune to buffer overflows (among other things) was responsible for the fact that once you got inside an OpenVMS machine you'd be unlikely to even be _noticed_ let alone turfed out, because the admins couldn't conceive of DEC having ever made a mistake.
I'm kind of a jr programmer and here's the idea I had. Could be done by the compiler and is probably already out there in some form.
;-)
Character arrays have an extra byte stuck on the end of them. When the compiler sees that it's being called by an unsafe method or some sort of strcpy it puts a random value into that byte, and rechecks it after the call. There is no way for the buffer overflow code to know what the value was and when it is changed the program is immediately killed. Then again your overflows still have a 1 in 256 chance of working.
So is this already being done somewhere or is there any reason why this just wouldn't work?
Seems to me OSS along with GCC has the potential to fix overflow problems a LOT easier than a commerical OS vender could.
-Don.
Cwm, fjord-bank glyphs vext quiz
This just seems to me to be a new way to attack your PC. Overwrite the DEP for the applciation and bring the app down. So now you have a PC that each appication will evently refuse to run! Great! The purpose of DEP is to stop code from executing on the PC.
No, the "PC guys" cannot guarantee that every single allocation and buffer access in a 100,000 line program is done correctly. Hell, the "PC guys" find it very hard just to make the program work at all.
... not really, no. Nothing universal, anyway. Higher level toolkits do help a lot though.
I'm one of said guys, so I'm well and truly familiar with this pain.
Part of it is culture - features and fast development above correctness. A project I'm involved with now is a horrifying mass of spaghetti that barely works at all, yet they're still adding new features with little focus on cleanup. There is no test suite.
As for libraries, etc
IMO the part of the solution is use a language better suited to writing software on the scale we do it on PCs. Not C, suitable for OS kernels and microcontrollers, or C++, but something with AUTOMATIC MEMORY MANAGEMENT. No more (programmer-visible) buffer manipulation, no more pointer ownership problems, double free()s, and forgotten `delete's.
Use of tools like valgrind is also important, as is coding carefully and considering getting it right as more important than getting it "working".
Finally, though it's not as useful for security issues, test suites are a really important thing in software development IMO.
So, how many people had this thought pop into your mind when you read this post:
"I'm sorry Dave... I can't let you do that."
Or has that been said dozens of times? I haven't read the comments.
The two approaches are orthogonal and can be combined. For example, Red Hat FC3 has both SELinux and ExecShield (which includes library address randomisation and W^X-style checks like what MS calls "data execution protection").
Jim Allchin, a VP at Microsoft said so.
Why not instead push BETTER PROGRAMMING, if needed by the total eradication of the programming languages that happily let you shoot yourselves in the foot by letting you program sloppily?
Also, castration of programmers could help by reducing the need to display machoness by programming in a low-level language (or what looks like a high-level language but is in reality a disguised assembler) could be contemplated.
But, of course, nothing would beat a major clueing-in of programming -spit- managers.
STart your negative modding engines now...
Considering that IE was the only browser that did not fail a recent test of random data sent to it through http, I'd say that there was some evidence for it.
Course Firefox amd Moz crashed like a chineese rocket on the same test, so yes, we poor Windows users may still need this protection due to poorly programmed Open Source er... programs.
The article linked doesn't say much about this "breakthrough technology", but from what I could gather, it looks rather like a cheap (and incomplete!) knock-off of OpenBSD's W^X (write-xor-execute). Anyone know more technical details?
Assorted stuff I do sometimes: Lemuria.org
I've had stack protection for quite some time with Solaris and OpenBSD. The Windows platform is a few years late to the party; doesn't Microsoft realize how much easier their life would be if they acted earlier?
Companies with Windows are like a person persisting to wear worn-out shoes. They're uncomfortable, they cause blisters, they don't keep water out, yet they keep them, because going barefoot is worse, I guess. The software industry still has a lot of growing-up to do.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
Yet another example of usless spending. Rather than ensuring that there are no leaks, they want to detect them when they happen. I'm tired of it.
A fitting name. In German, a Depp is another word for stupid idiot.
Assorted stuff I do sometimes: Lemuria.org
You were at your buddy's place to watch the Super Bowl. The chips ran out in the second quarter. Since you knew there was no way the half time show was going to be as interesting this year, you volunteered to go get more.
On your way out you made a mental note to come back to your buddy's place, rather than your own. This is the return address. You also made a mental note that you needed potato chips and another case of beer. That list is in your buffer.
Your other "friend", a known sponge who still owes several people for beer at various events dating back 3 years now, comes along. While you are at the store, he throws an extra case into the cart. He'll pay you back later.
That annoyed you enough that you forgot whose house you were going back to. You ended up at your place before you realized it. As a result, you missed the first few minutes of the third quarter.
The net will not be what we demand, but what we make it. Build it well.
So, with this great feature, I will be unable to say (compile 'my-function) in my LISP REPL, because it creates executable code in data section?
will software vendors be able to keep up with the support calls?
---
It would be better if the vendors fixed their buffer overflows and avoided the support calls. It's too bad the users will be caught in the middle, but Microsoft is doing the right thing.
Lets weigh the choices:
1. Leave the security issues in place for the convenience of the users:
Russian card mob gets all of your info because a program, active x control or something else exploits an unchecked buffer.
2. Inconvenience the users and secure their computers better:
Half the software they have stops working because it's written insecurely, but their bank account doesn't get drained. User has to wait for patches from vendor to use programs.
I'll take inconvenience over mortgage forclosure (due to drained checking account) and bankruptcy any day of the week.
This will most likely force vendors to properly check their buffers and write more secure software.
l8,
AC
I even enabled DEP for all programs and services, not the default "essential" ones.
In Spanish, DEP stands for "Descanse En Paz", or "Rest in Peace" in English
Measuring usability for fun and profit.
The problem you are describing is not with Windows or Linux. What you are describing is in fact exactly the lack of a "NX" bit. The Intel processors could not make memory readable and not be executable. Thus if you want to read the data on your stack then it was also possible to jump to it and execute it. The fact that Windows or Linux were unable to fix this problem is not their fault.
Possibly you are confused by 80286 segments, which could make memory readable without being executable (because you could only execute by loading the PC segment register, and the OS could apply totally different rules depending on which segment register was being loaded). However apparently the 80286 scheme has a lot of problems which is why neither Windows or Linux use it for virtual memory (I am not sure what the problems are but it is obvious nobody wanted to work with it).
You obviously don't remember how painful it was to program for 16-bit Windows. Segments and thunks and far pointers and all that other bullshit.
:)
Windows uses a 4GB flat address space. The same memory model used by Linux and all other modern OSes. Segmentation, though supported by the hardware, is (1) inefficient and (2) more difficult to program for. Even CPU vendors realize it was bad technology and are moving away from it. Example: The new AMD64 chips support all the segmentation crap in compatibility mode, but if you switch them to 64-bit mode they ONLY SUPPORT A FLAT ADDRESS SPACE. There is a word for this: "Progress".
The real answer, as another poster pointed out, is to add NX bits to the page protection hardware. One of the odd quirks of the x86 page protection hardware was that if you can read it, you can execute it. That turned out to be a bad design.
Restricting what code is allowed to run ... and this is MS doing it. Can anyone say "DRM and Palladium"? Sneaky move ...
Early versions of Unix (circa early '80's) running on PDP-11's split application memory into Instruction and Data space. Instruction space was the programs instructions and data included static, stack, and heap space. Data space was not executable. So a buffer overrun could result in a core dump (GPF) but not a security violation. Please keep this in mind, when MS is issued a patent on their novel DEP scheme.
[Insert pithy quote here]
But beware of the dark side. Anger... fear... aggression. The dark side are they. Easily they flow, quick to join you in a fight. If once you start down the dark path, forever will it dominate your destiny, consume you it will,
That is the path the anti-virus company's follow. They go for quick profit. They do not manage to completely erradicate virus ever. They do not help against phishing attacks, they do not help against spyware, you need to buy another product for that. and all those products together do your pc as much harm as the first virus that comes along.
Fear: mcafee popup's a Warning about a virus every few days, that on very very close inspections was not intercepted, but it was just just advertising it could help against. fear......
The program that you write in an interpretter is not executed in the classic sense of creating actual binary. It is more a case of looking at the data portion then doing something in the execution space. Your 'program' remains in data, whether in text or some intermediate compiled form.
You could also do something similar with the MC68000. I can't remember if it successors also had it.
Basically, there were two extra output pins on the address bus. One signified program or data access, and the other signified supervisory versus user. So, a clever engineer could four separate memory spaces. I am unaware of any products that used it, though.
(S(SKK)(SKK))(S(SKK)(SKK))
;; Why do you think that modern Common Lisp
;; implementations are pure interpreters?
CL-USER> (declaim (optimize speed
(safety 0)
(space 0)
(debug 0)))
T
CL-USER> (defun my-func (x)
(declare (fixnum x))
(the fixnum (1+ x)))
MY-FUNC
CL-USER> (compile 'my-func)
MY-FUNC
NIL
NIL
CL-USER> (disassemble 'my-func)
;; disassembly of #<Function MY-FUNC>
;; formals:
;; code start: #x2083517c:
0: 83 c0 04 addl eax,$4
3: f8 clc
4: 8b 75 fc movl esi,[ebp-4]
7: c3 ret
; No value
;; This doesn't look like something "intermediate".
;; It's executable code which is created dynamically.
Yeah, the next big thing, Microsoft will make this/that obsolete...
Except they never do! When it was released in April 2003, Windows Server 2003 (see my review) was the most secure server operating system Microsoft had ever developed yeah, except that is what win98, win 2K, winXp all claimed. It never happened! Look, Microsoft can't even get out of their own way!
Fuck 'em! Just fuck 'em!
Note: mod me down again. Who cares? That always makes what I say more insubstantial, doesn't it?
... it's about damn time. Data General had a similar scheme, called ring memory, in AOS/VS about 20 years ago. You can read about it in Tracy Kidder's Soul of a New Machine.
"Who controls the past controls the future. Who controls the present controls the past." -- George Orwell
We recently deployed McAfee 8.0i in our organization. We have been satisfied with it, but one of our accessibility apps in our disabled student labs was crippled by the buffer overflow protection. We decided to just disable the buffer overflow protection accross the enterprise via EPO.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Under both *nix and NT, basically the only restrictions security-wise are that the owner of an object (e.g. a file, directory, or registry key) can set permissions as to which users can access that object, and how they can do so (read, write, execute, etc).
Since these permissions are set at the discretion of the object owner, they are called Discretionary Access Controls. However, if somebody gets root on your box, they can change the permissions to whatever they want, and your security is gone.
Under an OS with Mandatory Access Controls, like SELinux, the permission settings are system wide, and cannot be changed by even the root user (obviously, the perms have to be changeable, but it must by a method inaccessible to root or any other regular user).
Further, in MAC systems there is usually far more granularity with regard to what objects can have permissions set for them. In addition to files, other things like processes, hardware, ports, etc all have permission settings. You can specify that the snarfblat.exe process can only access 2 files and send data over port 69 on network interface eth1; and root can do nothing to change these settings.
This allows you to implement the principle of least privilege, much like a firewall. You can set rules that disallow everything, and then make narrow exceptions for legitimate activity on your system.
-Ryan
On the other hand, the number of people I know who rave about productivity in Python, and the convenience I've seen writing a few things in Perl, suggest that for many tasks in user space it's really better to invest the time learning a more productive language that's also safer, and Java's probably more productive than C on large projects even if it runs slower. Of course, there are the academics who'd recommend Scheme or Haskell instead of Python, but those are probably adequately safe languages as well.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Are there better languages than C to write OSs in? Maybe not, but as I said, the number of people writing kernel code and device drivers is *really* limited - most code is userland code, and most exploits are userland exploits - C may be in wider user than ever in user space, but there are a couple of orders of magnitude more user-space programmers than kernel programmers. Sure, crackers can occasionally stomp on your IP stack by handing it unexpected packets, but that's rare, and it's usually a DDOS problem like the Ping of Death rather than an exploit. On the other hand, how many times have you seen security-critical bugs in web browsers, ftp servers, mail servers (sendmail is *much* less bad than it was, but I still wouldn't bet money on it being safe), other random things running from inetd, or for that matter even jpeg viewers have had security-critical buffer overflows in the last year.
That doesn't mean that enforcing safe languages will create total safety, of course :-) There are still lots of popular attacks that are language-independent, such as trying file pathnames with ../..'s in them in case the program isn't checking carefully for things like that. Operating System permissions can help prevent attacks like that from cracking root, but they don't always stop a web server from letting browsers write to the wrong place in a single user's web space.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
As a long-time C programmer, I'm curious as
to what you mean by "anonymous functions" in
C. (This is *not* a troll.) Example code is
always welcome. Other than that, thanks for
the useful post.
Peace & Blessings,
bmac
This is just another case of how we collectively forget great truths. When I was writing compilers for PDP-11s and VAXen, they generated CODE and DATA type Program SECTtions. Those got loaded into PAGEs with appropriate protection characteristics (executable, read-only, etc). What happened that we abandoned all this while the processors remained capable of support for these characteristics is a real mystery (did we get tired or just get lazy?). Of more modern concern, what impact does I/D (instruction/data) space have on JVM implementations?
Putting data and code in separate segments is nothing new. making data read/write only and code read/execute only isnothing new. This was standard on Multics (http://www.multicians.org). I believe Bouroughs and other vendors also did this as a standard feature back in the 60's as well. I find all this reinvent 60's and 70's technology very amusing. Why does everyone have to keep reinventing solutions?
In AMD64, the segment bases are still honored for segments loaded into %fs or %gs.
There is even a MSR flag to re-enable limit checking for all segments loaded into all registers, though it is only available in later AMD64 chips, and not in Intel's chips.
What if I just piss on the floow. What is that called?
Why are we bashing Microsoft here when the fundemental issue is that Intel didn't design the architecture corrently. As has been said, we've known forever, that executable pages of memory should not be writable. It was well know before the i386 was designed. Intel deserves the lions share of the blame here.
Linux and UNIX are more secure becuase they use a file system with permissions and user accounts do not have permission to write into system directories. Most UNIX systems are administered and Linux systems are used by more techie folks. When it was just a FAT file system, there were no permissions so anyone could modify any critical file.
With NTFS, files in critical directories can be protected. The problem becomes getting people to take the step of not having user accounts have admin rights. People can already do this in XP Home, but few do. The problem is that this would be viewed as inconvenient to most home users who don't udnerstand enough to know why they need this extra step to protect them. As long as home users grant admin privileges to everyone on aa system and then blindly download and install software, this problem can not be solved.
Even then, Microsoft needs to extend the privilege model to only allow designated applications to insert code in the TCP stack, keyboard stack, etc. Their spyware stuff sort of detects many of these issues, but the OS needs to control them.
MS says they are serous about secrity and it is priority one. Allowing any kind of install of a system component without admin control is unacceptable if you want a secure system. To get security we are going to have to sacrificae some convenience and flexibility, but how do we implement this when so many users are so technically niave, unsophisticated, unwill to do the slighted extra work to keep their systems safe, etc.
As an industry we need to stop bashing MS and start educating users that security is their problem. leave your car unlocked in a high crime area with the keys in it and you should take the blame, not GM. The Internet is a high crime neighborhood and unless you take personal responsibility and avoid the dark alleys, giving your wallet to strangers and leaving your car and house unlocked, you are going to get robbed and assaulted.
Twitter, you're a petulant cock-gobbling sycophant to Linux Torvaldyos! Quit taking DP from ESR and RMS's feculent cocks and why don't you try to stop sucking quite so much? Get out of your parents' basement and see the real world - maybe then you'll see how pathetic you sound, with your neverending stream of bullshit about how Microsoft is stalking you. Wasn't it you who said that Microsoft believes your insane ranting is actually a threat to them, so they PAY PEOPLE to reply to you on Slashdot? No sir, I don't get any money. I do it for the love. Someone has to go up against your paranoid whining. So get back in your cage and shut the fuck up already.
The NX bit says that code is not to be executed on a per-page (usually 4k) basis WITHIN AN EXECUTABLE SEGMENT. You can have non-executable segments, and you have been able to for over 20 years on the x86 processor range, without the NX bit. You'd just need to make sure your code segment doesn't reach as high as your stack segment, and that would solve most of the problems. (It's also possible to create executable read-only segments, so that code can't be changed once loaded in.)
Unfortunately, doing something like that this late into OS development can be quite tricky and could break some software.
But this is definitely down to the OS guys, not the chip guys. If ya don't believe, check the 386 white papers, look for details on the global descriptor table.
-2A
The revolution will not be televised... but it will have a page on Wikipedia