Exec Shield for the Linux Kernel 266
DarkOx writes "There is a new patch from Ingo Molnar which can prevent overflow attacks. The scoop from KernelTrap is as follows: Ingo Molnar has announced a new kernel-based security feature for Linux/x86 called 'Exec Shield'. He describes the patch, which is against the 2.4.20-rc1 kernel, as: 'The exec-shield feature provides protection against stack, buffer or function pointer overflows, and against other types of exploits that rely on overwriting data structures and/or putting code into those structures. The patch also makes it harder to pass in and execute the so-called 'shell-code' of exploits. The patch works transparently, ie. no application recompilation is necessary.'"
grsec ? (Score:5, Interesting)
Sounds like much of the same security that's been available from grsecurity.net [grsecurity.net] for quite a while now.
Re:grsec ? (Score:3, Informative)
Re:grsec ? (Score:2, Informative)
All I can say is try it. There's a lot more to it than just an ACL. In fact I don't even use the ACL, I use all the _other_ security enhancements it offers.
Re:grsec ? (Score:5, Informative)
Yes, grsecurity includes equilevant protection to this. It uses PAX [virtualave.net] kernel patch for this. It has existed for years, and Ingo really should have mentioned that in his announcement, assuming he even knew about it?
Difference is that PAX uses some weird x86 kludges to do this and it causes slight speed difference (max. 10% IIRC), but I think that's a very small penalty for very good protection against buffer overflows. It also reduces the maximum memory available to process by .. was it 1-2GB, but there's not many processes that really need that much. And Ingo's patch seems to limit at least number of executable pages even more so.
Re:grsec ? (Score:3, Informative)
Wrong, address randomization prevents that (in a probabilistic sense). Nor does Exec Shield prevent it (hint: i386 is little endian).
> The Exec Shield also tries to limit the size of
> the code segment much more than the
> segmentation-based solution in grsecurity
> - resulting in a much smaller area of attack.
You don't have many clues what you're talking about, do you?
Also sounds like the OpenBSD hack? (Score:2)
Yes, but does it... (Score:3, Funny)
A cure for stupidity is a many-splendored thing - Publius Julius Caesar on the day before the ides of March ## B.C.
why would it do that? (Score:2)
WOW! (Score:4, Interesting)
Re:WOW! (Score:5, Funny)
Re:Yeah... (Score:4, Funny)
Re:Yeah... (Score:2)
Re:Yeah... (Score:2, Insightful)
XBill is actually very pro-M$.
Because no matter what you do, sooner or later you end up with winbows on every machine on the screen.
It should be changed so that you can actually win the game. No more Bills to swat at level 10, or at 1000 points, or whatever.
Re:Yeah... (Score:3, Interesting)
Re:Yeah... (Score:2, Funny)
Re:Yeah... (Score:3, Interesting)
I want Linux to succeed more than anything, because I love some of the things that it does. KDE and Gnome both blow away Windows from the level of usefullness and power, an
Re:Yeah... (Score:2)
I doubt there's going to be anything like it for Linux. The computer graphics world lost a brilliant man when Kai Krause retired.
Photoshop
If you do output for print, the Gimp is nowhere near Photoshop, and won't be for a while. If you do output for digital media, the Gimp can quite handily go toe-to-toe with Photoshop.
MS Office
Yup. Open Office is good enough for folks that occasionally have to interact with Office docs and are fed up with having to deal with Windows, but if
Re:Yeah... (Score:2)
He didn't really retire. In case you're interested, you can find the website of his project at http://www.byteburg.de/
Go to the german version, there is also english content.
Ingo's announcement (Score:3, Informative)
_____________________________________________
[Announcement] "Exec Shield", new Linux security feature
We are pleased to announce the first publically available source code
release of a new kernel-based security feature called the "Exec Shield",
for Linux/x86. The kernel patch (against 2.4.21-rc1, released under the
GPL/OSL) can be downloaded from:
http://redhat.com/~mingo/exec-shield/
The exec-shield feature provides protection against stack, buffer or
function pointer overflows, and against other types of exploits that rely
on overwriting data structures and/or putting code into those structures.
The patch also makes it harder to pass in and execute the so-called
'shell-code' of exploits. The patch works transparently, ie. no
application recompilation is necessary.
Background:
-----------
It is commonly known that x86 pagetables do not support the so-called
executable bit in the pagetable entries - PROT_EXEC and PROT_READ are
merged into a single 'read or execute' flag. This means that even if an
application marks a certain memory area non-executable (by not providing
the PROT_EXEC flag upon mapping it) under x86, that area is still
executable, if the area is PROT_READ.
Furthermore, the x86 ELF ABI marks the process stack executable, which
requires that the stack is marked executable even on CPUs that support an
executable bit in the pagetables.
This problem has been addressed in the past by various kernel patches,
such as Solar Designer's excellent "non-exec stack patch". These patches
mostly operate by using the x86 segmentation feature to set the code
segment 'limit' value to a certain fixed value that points right below the
stack frame. The exec-shield tries to cover as much virtual memory via the
code segment limit as possible - not just the stack.
Implementation:
---------------
The exec-shield feature works via the kernel transparently tracking
executable mappings an application specifies, and maintains a 'maximum
executable address' value. This is called the 'exec-limit'. The scheduler
uses the exec-limit to update the code segment descriptor upon each
context-switch. Since each process (or thread) in the system can have a
different exec-limit, the scheduler sets the user code segment dynamically
so that always the correct code-segment limit is used.
the kernel caches the user segment descriptor value, so the overhead in
the context-switch path is a very cheap, unconditional 6-byte write to the
GDT, costing 2-3 cycles at most.
Furthermore, the kernel also remaps all PROT_EXEC mappings to the
so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
addresses are special because they cannot be jumped to via ASCII-based
overflows. E.g. if a buggy application can be overflown via a long URL:
http://somehost/buggy.app?realyloooooooooooooooooo oong.123489719875
then only ASCII (ie. value 1-255) characters can be used by attackers. If
all executable addresses are in the ASCII-armor, then no attack URL can be
used to jump into the executable code - ie. the attack cannot be
successful. (because no URL string can contain the \0 character.) E.g. the
recent sendmail remote root attack was an ASCII-based overflow as well.
With the exec-shield activated, and the 'cat' binary relinked into the the
ASCII-armor, the following layout is created:
$
00101000-00116000 r-xp 00000000 03:01 319365
00116000-00117000 rw-p 00014000 03:01 319365
00117000-0024a000 r-xp 00000000 03:01 319439
0024a000-00
LIDS? (Score:2)
Re:LIDS? (Score:2)
This is good. (Score:5, Interesting)
Assuming their claims of extremely low over-head are true, why would we not want this?
In fact, a lot of security issues could be stopped before they ever happen if we look more closely at the Operating System instead of all the software! Think how much easier it would be to work on isolating software and protecting the system from itself than trying to make every single app ever written secure. Yes, focusing attention to the Operating System for vulerabilites is a good step--even though we can't ignore our applications.
Re:This is good. (Score:2)
Re:This is good. (Score:2)
Re:This is good. (Score:4, Insightful)
Well, as long as MS keeps claiming IE, IIS etc. are part of the operating system and can not be separated, exploits against those parts should be filed against the OS. In Linux, when an application gets exploited, well you don't have to run that application, you don't even have to install it, it *is* separable from the OS! Especially as there are alternatives to (almost) everything...
Regards, Ulli
Re:This is good. (Score:2)
How many IIS-users has swatted their bugs that fast?
Re:This is good. (Score:2)
I don't get it -- I've never seen this. Can you give an example? The only thing I can think of that you might be thinking of is that IE updates get classified under OS updates, as it's bundled with the OS.
Re:This is good. (Score:5, Insightful)
Umm... do you have some vague notion of what the kernel is? First of all, it isn't spelled with an "a". Secondly, ease of use of a kernel is a very messed up concept and I'm not even sure what it means. The kernel isn't easy or hard to use any more than winsock.dll is easy or hard to use. Very few programmers interact with the kernel except through libraries, so "easy of use" (whatever you mean by that) is much more important in the low-level libraris than the kernel. How does this affect marketability to individuals? Both POSIX and Win32 APIs are available on both systems. Are you referring to clean kernel interfaces, clean kernel implementation, availablility of the source for better understanding, or some other metric?
Kernel: That word... you keep using it. I do not think it means what you think it means.
I think you're thinking about UI. The GUI, the shell, the command line, the layout of the directories, etc. are all very very far removed from the kernel. In theory you could run explorer (the Win32 shell, not IE) on top of WINE, along with all of the Win32 programs and the user would have identical ease of use as Windows. 99.99% of users couldn't tell it wasn't the NT kernel and couldn't show evidence of it being Linux even if told (without watching the boot sequence). Asking about "ease of use" of a kernel is like asking about the top speed of your house. Neither question makes much sense unless you further define your strange thinking. You could guess that the person is asking how fast a house would be going when it hit the ground if dropped from 60,000 feet up (terminal velociy) just like you could assume a person is talking about how clean a kernel's APIs are. However, the usual sense of ease of use as realated to marketing to individuals is ease of use of the UI. I can only make educated guesses as to what strange thoughts are going through your head. For all I know, you filled hard drive platters up with both kernels and are attempting to use the platters to cut 440 stainless bar stock and are referring to the different metal cutting characteristics of kernel-filled HD platters. Please clarify exactly how you think the ease of use of the NT and Linux kerenls differ.
Uh Oh... (Score:5, Funny)
Hrm...
"Shit, spaceballs, there goes the planet" --apes
"read or execute" flag? (Score:5, Insightful)
From the announcement:
It is commonly known that x86 pagetables do not support the so-called executable bit in the pagetable entries - PROT_EXEC and PROT_READ are merged into a single 'read or execute' flag. This means that even if an application marks a certain memory area non-executable (by not providing the PROT_EXEC flag upon mapping it) under x86, that area is still executable, if the area is PROT_READ.
Is this limitation in the x86 processor MMU, or in the Linux kernel?
Is anyone working to fix this limitation? (E.g. AMD fixing it in 64-bit mode on the Opteron, or someone reworking the Linux kernel)
Furthermore, the x86 ELF ABI marks the process stack executable, which requires that the stack is marked executable even on CPUs that support an executable bit in the pagetables.
Does this statement imply that some x86 processors do the right thing with PROT_EXEC?
If Linus is willing to create a new ELF standard, could this problem be fixed? Would it be worth the pain of a new incompatible ELF standard? Are there any other problems that can only be fixed with a new version of ELF, so we can fix them together?
It would be sort of cool to get a new ELF standard, so that Linus can call the new kernel "3.0"!
steveha
Re:"read or execute" flag? (Score:5, Informative)
Re:"read or execute" flag? (Score:2, Informative)
While I applaud the effort made for this product, I still believe that the only way to completely shield ourselves from such attacks is to enforce it in hardware.
Re:"read or execute" flag? (Score:5, Informative)
The problem is the way that people use x86's paging mechanism. Each page can, in fact, be distinctly assigned to being either code or data, but because each page requires a distinct entry in the page table, if each process had to have separate code and data pages, then it would stand to double the number of page table entries.
So why did they do it this way, if it was so simple to avoid? Back in the early 90's, when Linux was first written, it was highly desirable (with protected mode code in general) to minimize distinct page table entries in the x86 because page tables could take up so much space. So protected mode programs (and operating systems) were typically designed so that the code and data segment descriptors could end up mapping to the same pages in the x86's paging mechanism to reduce overall page count.
Indeed, if the x86 had not allowed a page to be both writeable and executable, then this would never have been an issue. Although it would have had the memory overhead in the page table entries that I described earlier, since we wouldn't have even had a choice in the matter, we would have just had to settle for what we got (although back then the design would have likely been criticized as being wasteful of memory).
Er... to expand a little bit... (Score:5, Informative)
If and when different pages are used for code and data, since both already use different segment descriptors, the code and data have their own completely isolated address spaces, so trying to invoke a buffer overflow that would cause a "return" to some point in the user-supplied data would actually simply cause a return to the corresponding point in the code page, which is, of course, not actually modified by the application. At best, a buffer overflow could cause a branch to a particular section of the existing program, but would not permit the execution of arbitrary code since in the ideal case, even the kernel code resides in an address space that is invisible to any running application. The most probable upshot of trying to "return" in this fashion would be a segmentation fault, which should result in no more than the application simply terminating with a core dump.
Re:"read or execute" flag? (Score:4, Insightful)
Trampolines (Score:4, Insightful)
16 'segments' (call them what you will) can be based (pointed to) at any one time, each by one base-register.
B0 points to code
B1 points to the stack
B2-B15 point to data segments.
If you want to point B0 to another executable segment, you have to execute CALL, GOTO or RTN (return
Yes, we can have buffer-overflows, but 'all' that happens is that other data is overwritten. This will usually cause the program to abort. It is even possible to organise things so that every routine has it's own discrete data-segments. If a routine then starts accessing data outside of the routine, it gets the equivalent of a Segfault. Obviously parameters/arguments are excepted from this, although there would also be a Segfault if a routine went outside it's caller's data-area.
Actually, the hardware allows a caller to restrict a subroutine's access to only the n bytes it actually passed over as an argument. The HLL implementations do not enforce this setting in any of the languages I use.
Segment attributes are from Owner-Read, Owner-Write, Owner-Execute, Other-Read, Other-W and Other-X. Segments also have a Sharing-Level which is: Activity, Program, Application and Exec/System. Exec/System is normally combined with Other-Access: None, Application is normally combined with Read+Execute.
How much damage is caused each year because the 32-bit I386 architecture cannot supply a reasonable security framework at a reasonable overhead? If the AMD 64-bit processors are capable of fixing this mess, then the GLIBC maintainers could start looking at (optionally?) allowing a safer implementation by separating Code and Data. If this incurs memory-overhead, server farms should be migrating to 64-bit processors anyway by the time such a feature became available. They could also always compile the libraries without that feature.
Re:"read or execute" flag? (Score:5, Informative)
This means that even if an application marks a certain memory area non-executable (by not providing the PROT_EXEC flag upon mapping it) under x86, that area is still executable, if the area is PROT_READ.
No. The x86 page table has 12 bits per page table entry for storing page information. It contains a bit for R/W (read/write) which you can force a page read-only; and it contains a bit U/S (user/supervisor) which you can force a page usable only by the kernel. There is nothing which says "this page must not be executed as code". So Linux kernel actually has an interface that only some hardware provides. I don't think now it still has spare bit to give for executable bit.
Furthermore, the x86 ELF ABI marks the process stack executable, which requires that the stack is marked executable even on CPUs that support an executable bit in the pagetables.
It is not about "do the right thing". The processor simply has no such bit, so there is no new "right thing" for it to do---it is already doing the right thing. The processor assumes that segmentation is used to enforce execute permission, so that each library code should be allocated a segment and inter-segment jumps and calls should be used to access them. In such way only read-only code segments are executable. Linux simply decided at the very beginning not to employ this facility.
ELF is not designed by Linus. And even if ELF is changed so that stack is not assumed executable by default (which probably break some programs that rely on executable stack), all computers from 386 to P4 will not benefit from it.on the subject of paging and protection (Score:2)
For example, a page could be data only if the Read and Write ring was 3, but the eXecute ring was 0. Then, only the kernel would be able to execute code in that page.
This scheme is very flexible: there can be read-only pages, write-only pages, exec-only pages, or any combination of the three. F
Saturday night /. Session (Score:5, Funny)
Another saturday night spent on
easier on x86-64 (Score:5, Informative)
Slightly off-topic, but does anybody know whether IA64 or x86-64 allow you to make the stack non-executable in the same way you can on SPARC?
and hpa replied to this:
x86-64 definitely does, and it's the default on Linux/x86-64.
Up to now, x86 chips have not been able to separate Read from Execute privileges for memory segments, which makes it hard to make stacks non-executable. This is excellent news for anyone looking forward to AMD's x86-64 chips...it keeps looking like they've done the Right Things.
Re:easier on x86-64 (Score:2)
adam
Re:easier on x86-64 (Score:2)
Up to now, x86 chips have not been able to separate Read from Execute privileges for memory segments
On x86, the stack segment can be a different area of memory than the app's memory space. It is just Linux that implements it that way.
A long time ago I proposed that the SS register should point to another area of memory which is not executable. People replied by pointing out that the way GCC implements trampolines requires code to be executable from the stack. I strongly disagree with trampolines, as I
Just one problem with it... (Score:5, Insightful)
That leaves us with only 15 MB of space for code!
Are they really trying to say that they have not hit that limit yet? No program on earth has more than 15 MB code?! I can hardly believe that.
I was going to cite Emacs on this one, but Emacs is an interpreter, so the actual interpreter code might be small enough. Mhh. What about Mozilla?
Heck, what about WINE?!
Re:Just one problem with it... (Score:4, Informative)
Re:Just one problem with it... (Score:2)
Re:Just one problem with it... (Score:2)
For Mozilla, code + data is on the order of 20MB. I'd be surprised if more than 15MB of that is code -- the encoding conversion tables and the printing tables are huge.
Possible Problem (Score:5, Interesting)
I've written a few pieces of code which take advantage of the executability of the stack and the heap. For example if you want to write a just-in-time compiler for some language, an easy way to do it is allocate an area on the heap, let the JIT compiler write the appropriate x86 machine code into that area, and then typecast the area pointer to a function pointer and execute it.
With this patch, that won't work...
Re:Possible Problem (Score:2)
Re:Possible Problem (Score:5, Informative)
Perhaps even better would be to have your own "private" heap in userland. That would protect the OS, and you get to use your trick still.
I'm not a coder by trade, so I can't really critisize what you're doing. I do understand operating systems and memory allocation therein though, so my admittedly uninformed opinion is that you're employing a somewhat dangerous hack here. The heap was not intended to hold executeable programs - you'd be broken on x86-64 as well. Using what amounts to a design flaw in a program isn't what I would be willing to call "good design". Might be better to come up with a different method - Ingo Molnar seems to think you do at any rate.
Soko
Re:Possible Problem (Score:3, Insightful)
Dynamically writing code is not a dangerous hack. The more correct way of solving this problem is for people not to use unchecked arrays that can overflow - C, C++ and a few other really low level languages about the only languages that have unchecked arrays as a standard data type. Most of these problems don't show up in programs written in other languages.
Re:Possible Problem (Score:2)
It is not possible (at least in the implemention available to me) to ask 'how big is that string, physically'?
The language I use on a day-to-day basis is (shock, horror) Cobol.
Given a 50-byte field FIELD-50 and a 100-byte field FIELD-100,
copies FIELD-50 to the first 50 bytes of FIELD-100 and fills the rest with spaces.
copies the first 50 bytes of
Will work fine ... (Score:5, Informative)
In other words, ELF format has flags to indicate if the stack should be readable and/or executable. If your doing that sort of thing, make sure that the flag is set, and you'll have no problems [0].
It your doing those sort of tricks, your probably being very careful with what goes where, and buffer lengths and such. The problems come in when people don't realise that there could be a problem, and don't audit the buffer handling code properly.
So, don't worry, just use the ELF flags.
[0] Well, you could set the feature to ignore what the binary says, and implement the security anyway. But that's not a good idea, and very much not default.
Re:Possible Problem (Score:3, Insightful)
Fear not my friend :-) . Please read the announcement from Ingo:
Re:Possible Problem (Score:2)
Re:Possible Problem (Score:3, Interesting)
m = mmap(NULL,
1000000,
PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON,
-1,
0);
will allocate 1000000 bytes of memory which can contain executable code on Linux and BSD. On some other Unices you have to use
Re:Possible Problem (Score:2)
Potentially Stupid Question (Score:4, Interesting)
(As I'm sure you can tell) I don't claim to know much about any of this at all, but I did read the kerneltrap post, for what it was worth, and as a non-x86 user, I have a few questions. Ingo's patch is only for x86; is equivalent protection for other architectures possible, or even necessary? To what extent are buffer-overflow exploits architecture specific?
Sorry if I'm missing something simple here.
Re:Potentially Stupid Question (Score:5, Interesting)
However
It's not perfect (nor is the better hardware solution). However, it will make many exploits an order of magnitude more complex, making writing and utilising them a much more complex task.
The part about locating code inside the ASCII armour is, however, zero overhead, and will, I think, get wrapped into mainline on all archtectures (although possbily not till 2.7)
openwall patch (Score:4, Informative)
Quoting from the README: Non-executable user stack area.
Most buffer overflow exploits are based on overwriting a function's return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non-executable, buffer overflow vulnerabilities become harder to exploit.
Another way to exploit a buffer overflow is to point the return address to a function in libc, usually system(). This patch also changes the default address that shared libraries are mmap()'ed at to make it always contain a zero byte. This makes it impossible to specify any more data (parameters to the function, or more copies of the return address when filling with a pattern), -- in many exploits that have to do with ASCIIZ strings.
However, note that this patch is by no means a complete solution, it just adds an extra layer of security. Many buffer overflow vulnerabilities will remain exploitable a more complicated way, and some will even remain unaffected by the patch. The reason for using such a patch is to protect against some of the buffer overflow vulnerabilities that are yet unknown.
Silly me (Score:4, Funny)
prevent stupid business executives to
ask questions about Linux mindshare and
the like...
Executable stack protection, very nice, but... (Score:3, Insightful)
Sure, this will nullify most remotely exploitable vulnerabilities, but what about local ones that are vulnerable in the manners I just described?
Re:Executable stack protection, very nice, but... (Score:3, Insightful)
Someone has to say it... (Score:5, Funny)
You kill -9 my ppid
prepare to die!
Typo in post (Score:5, Informative)
as a non-programing network admin (Score:3, Interesting)
Re:as a non-programing network admin (Score:2)
Yes. Everyone should have installed grsecurity [grsecurity.net] long time ago for their servers, which provides this protection and much more. It includes ACLs which requires some work to get working, but you don't have to use them. Non-exec stack+heap and address space randomizations require nothing but upgrading the kernel and possibly disabling them for a few binaries that don't like them. I'd guess grsec will include Ingo's patch with it as alternativ
Non-executable stacks are part of the solution (Score:5, Interesting)
It should also be pointed out that while most buffer overflow exploits do indeed simultaneously overwrite the return address and inject the shellcode onto the stack, a certain class of buffer overflow exploits called return-into-libc attacks do not require executable stacks and are not too difficult to construct. These attacks overwrite the return address with the starting address for one of the libc exec*() functions. At the same time, the parameters for executing /bin/sh are pushed onto the stack. The execution of the corresponding return instruction then causes the exec*() function to execute /bin/sh. See this paper [securityfocus.com] for a more detailed analysis of some buffer overflow solutions.
I think that it's interesting that in the past few weeks, several solutions for buffer overflows have been announced (e.g., the OpenBSD announcements). Each of these solutions are good solutions, but they heavily borrow from earlier solutions. Unfortunately, the previous work has often not been properly acknowledged. Since the masses are generally not aware of the current state of the art, these supposedly new solutions are given more credit than due. Still, I suppose it's a good thing if general awareness of the buffer overflow problem is raised, even if the pioneers of the technology do not receive their due credit.
Tim Tsai
Call me stupid, but this makes no sense to me. (Score:5, Interesting)
1) x86 stack grows from high addresses to lower ones, allowing for a string allocated on the stack to overflow such that it overwrites the return address.
2) x86 is little-endian which means that the return address (in this case, on the stack) starts with the low byte and stops with the high byte.
3) In C programs, strings are null-terminated.
The ASCII shield relies on ASCII not being able to represent certain addresses, namely 0x00000000 to 0x0100ffff.
Well, here's what I don't get. Assuming all three above, there are five possibilities we can generate for overwriting an address:
1) All four address bytes are overwritten by ASCII characters generating an address greater than 0x01010101.
2) The first three bytes are overwritten by ASCII characters, and the last one is overwritten by the null terminator. This results in an address between 0x00010101 and 0x00ffffff. This certainly looks like an address within the 16M "armor"
3-5) For (3), we only overwrite three of the address bytes, the first two being ASCII, and the last being NUL, resulting in an address something like 0x??00AAAA, where AAAA is greater than 0x0101. This would require that the attacker know what the upper byte of the address is, which is possible. (4) and (5) represent similar situations.
As far as I can see, this 16M protected region doesn't exist. WHAT AM I MISSING?
Thank you.
Hmm.. you might be right! Someone tell INGO! (Score:2, Interesting)
#include <stdio.h>
#include <string.h>
int main(void)
{
char arr[sizeof(int)] = { 0x01, 0x01, 0x01, 0x00 };
printf("%d\n", *((int *)arr));
return 0;
}
So I don't get what Ingo means when he says that this region is somehow ASCII-shielded
Re:Call me stupid, but this makes no sense to me. (Score:2, Informative)
So unless spawn_shell(void) exists, the armoring is quite effective.
Great but... (Score:2)
Windows (Score:5, Informative)
So it looks like Microsoft beat Ingo to it
Not exactly surprising... (Score:3, Interesting)
inclusion into vanilla kernel (Score:2)
and i sure hope that the non-exec flag has been implemented on amd's and intel's 64 bit cpus.
ASCII-Armor area (Score:3, Interesting)
probably not completely transparent (Score:3, Insightful)
Programs compiled for the x86 architecture may well assume that they don't have to set the executable bit on pages because the hardware doesn't support it anyway. Whether such programs are "correct" or not, this patch may break applications.
Re:Great! [Scott] (Score:5, Insightful)
Well, yes and no. Think about the analogy of this to driving. Cars today have a number of safety features, including seat belts, air-bags, anti-lock breaks, etc. Do we drive less safely because of them? More importantly, should we not include these devices in cars to increase driving safety?
I believe it was Chris Rock joking about this in one of his sketches. He claimed that airbags are NOT going to make someone drive safely. He said something like "What you need is a giant spike coming out of the steering wheel. That'll make someone drive safe!".
Re:Great! [Scott] (Score:2)
Re:Great! [Scott] (Score:2, Funny)
Re:Great! [Scott] (Score:2, Insightful)
The problem is, then, that air bags in the US actually become more dangerous when seatbelts are used, but there is no evidence to suggest that they help those that don't wear them any more
Re:Great! [Scott] (Score:2)
Re:Great! [Scott] (Score:5, Interesting)
People have a marginal value for driving dangerously, which is balanced by the marginal cost of that action. Where the two meet (marginal cost -vs- marginal value curve), is how people behave (or drive in this case).
In comes a safety feature. That safety feature reduces the marginal cost of driving dangerously. Thus, the driver is able to "afford" more dangerous driving. ie the equilibrium point where marginal value and marginal cost meets has shifted higher towards dangerous driving.
Thus, in economics theory, the driver will drive more dangerously with additional safety features.
The opposite effect, in the original poster's example, of having a spike come out greatly increases the marginal cost. Thus, the "affordable" point shifts far down towards much safer driving.
Of course... this is fundamental microeconomics, and I'm no expert in economics.
Re:Great! [Scott] (Score:2, Informative)
Re:Great! [Scott] (Score:2)
Re:Great! [Scott] (Score:2)
Whether an additional safety feature will make people even more c
Re:Great! [Scott] (Score:2)
Re:Great! (Score:4, Informative)
the patch was designed to be as efficient as possible. There's a very minimal (couple of cycles) tracking overhead for every PROT_MMAP system-call, plus there's the 2-3 cycles cost per context-switch.
Re:Great! (Score:2, Interesting)
Protected/virtual address spaces help avoid a plethra of security/stability issues. Does this mean in your opinion that such virtual addressing encourages sloppy programming?
--adam
Not slow. (Score:5, Interesting)
Re:Not slow. (Score:5, Informative)
sorry, but the number of context switches is not limited by the HZ setting. thats the maximum number that would occur if there were no blocked threads and no interrupts (except the system timer) causing threads to become runnable.
my system runs audio software that is generally powered by the audio interface interrupt, which occurs at about 1kHz. every single one of those interrupts generally leads to about 4 context switches in the typical case. thats about 4000 context switches per second.
RTFANNOUNCE-exec-shield (Score:2)
---------
the patch was designed to be as efficient as possible. There's a very
minimal (couple of cycles) tracking overhead for every PROT_MMAP
system-call, plus there's the 2-3 cycles cost per context-switch.
Re:Transparent? Why Not? (Score:2)
Re:Transparent? Why Not? (Score:2)
Let me explain this to you.. (Score:5, Informative)
While it is true that in general even HUGE changes to the kernel rarely need an application recompile, and are transparent, sometimes this is not the case.
Consider the following:
Actually, even this patch is not entirely transparent. In order to best benefit from the ASCII-armor area, you will notice that in the readme text file they actually gave a patch to binutils to make executables try and use a lower address for their program text. Executables (unlike shared libraries) aren't relocatable and thus need to be re-linked in order to use a different (lower) address...
Re:Transparent? Why Not? (Score:2, Interesting)
One (implied in the linux-kernel post) is that it would be nice to fix the ELF format and remove the assumption that the stack can contains executable code. Also, changing the way the program is laid out in memory affects security (see the "ASCII Armour" bit). A priori you might think that recompilation (producing a new binary) would be required for that.
The second is self-modifying code. Some application (the post mentions XFree86)
Re:Hahaha, that's the way it's supposed to be! (Score:2)
Also for the most part it doesn't matter in Linux because you have the source code. If you update part of the system you should update everything related too. You aren't stuck with something that is broken.
Re:The name is taken ... (Score:3, Informative)
Re:binutils patch? why? (Score:2)
But what about the quantum flux capacitor?!
Re:Microsoft (Score:5, Insightful)
Hope that helps!
Re:Stack executability all or nothing on Linux? (Score:2)