But the function code isn't on the stack, it's in the code segment. Stack frames store local variables, arguments and stack metadata information - no code.
But you can't overwrite stack that isn't being used yet - as soon as it is used your buffer overflow will be overwritten.
Buffer overflows != overwriting the code of other functions. Overflowing a buffer depends on being able to overwrite the stack linkage data and (usually) injecting code into the stack.
The best explanation I can find for how you'd attack an upwards-growing stack is that of another poster who pointed out that code that iterates over ever-decreasing memory addresses might be tricked into overwriting earlier stack frames. I guess that's the issue, although I'd imagine it was rather more rare than the reverse case.
> But why I ask is the OS allowing one process to > overwrite memory of another.
It's not allowing a process to directly overwrite another process's memory. Buffer overflows basically "trick" a program into overwriting bits of its own memory that the author didn't expect.
> Is it just that the stack is limited?
It's something that you have to code carefully to avoid, since C lacks various checks that avoid the programmer having to worry about this. Lots of languages do have these checks but they're less popular.
Stacks on x86 grow downwards (i.e. to lower memory addresses). Each time you call a function, the top of the stack gets *lower* in virtual memory.
It allocates a 12 character array *on the stack*. If we can trick foo() into writing more than 12 characters into the "filename" array, then it'll continue to write the data into higher and higher addresses *overwriting earlier data on the stack*.
The process is overwriting its own memory so there's nothing the OS can do to protect against it. The trouble is that if the data foo() read is not only too large but contains some malicious code, the application may be tricked into running that code when the function exits. If the application was running as root (or if the code was part of the kernel) then that malicious code now has control of your system:-(
> As another posted said is it a hangover from > days of tightly limited system resources > and no swap?
Not really, it's something that just happens. Writing code which allows buffers to be overflowed in this way is sloppy - the coder got it wrong.
I'm afraid you'll have to educate us - how do Solaris' MAC facilities measure up against SELinux? Are they as flexible? Do they offer any more features? In what way are they better?
Xen and Zones are different things. Yes they both provide virtual servers but in different ways. Both have strengths - the ideal system would support both.
Xen: * virtually no performance penalty * supports live migration of virtual servers * runs Linux 2.4 / 2.6, FreeBSD 5.3, NetBSD 2.0, Plan 9 in guests * can live-migrate virtual machines between physical hosts * greater isolation of virtual servers for better security / robustness * can almost certainly run on more hardware than Solaris * can run device drivers in fault-resistant sandboxes * can be used to debug guest OS kernels
Zones: * lower memory footprint than Xen (and more flexible in memory usage) * even lower performance penalty, approaching zero (if Sun have Done It Right) * lighter weight virtual servers than Xen, with better resource sharing between virtual servers
A combination of the two would be really useful - use Xen where you need migration, high assurance isolation, etc. Use VServers where you are less concerned about these issues and want lighter-weight virtualisation.
Neither is "better" than the other without considering the use case.
Xen 1.x could run a ported Windows XP on standard PC hardware. This is the port that was never released to the public.
Xen-unstable (the development tree, to become 3.0 this summer) includes support for Intel Vanderpool virtual machine extensions - these will allow it to run unmodified guest OSs on supporting hardware.
Unmodified Linux guests will boot on Xen right now on Vanderpool hardware. Windows guests are a little further off (possibly post 3.0) because they require support for various 16-bit x86 cruft;-)
Actually it is true: Cocoa / Carbon apps are restricted to 32 bit. This is allegedly for performance reasons (reduces the cache footprint - apparently for the GUI libraries the overhead of using 64 bit was found significant), not just to simplify implemention.
Note that this means although most applications are limited to 32 bits of address space you can still use more than 32 bits of addressable RAM overall.
The kernel runs in a 32 bit address space, creating temporary mappings to pages outside this space when necessary (i.e. it doesn't map the whole of physical memory like Linux). They do (AFAIK) maintain binary compatibility for device drivers, unlike Windows, Linux, or anything else I know of.
Actually I agree with you too.
On the one hand, from one purely technical point of view avoiding OS modifications because of licensing issues is (in some senses) a work around.
On the other hand I see nothing "inappropriate" about closed source licenses so I don't mean to complain about those either.
I intended to clarify Andrew Morton's statement to those less familiar with the issues of x86 virtualisation but I probably should have phrased it slightly differently.
Anthony's point was that it will be able to run unmodified guests using Intel's Vanderpool / VT-x extensions and using AMD's Pacifica extensions.
VT-x is shipping some time this year, IIRC. I'm not sure when Pacifica is shipping.
I agree completely that it's good to be able to run unmodified OSs. It allows you to match testing installations in virtual machines even closer (though almost certainly not identical) to the real hardware you will run on, it's good for some lowlevel OS development environment. And it would be nice not to introduce a new architecture.
OTOH, it's also good to make the VMM as small as possible and get the maximum performance out of the hardware. Paravirtualisation helps here, so it's a trade-off. Of course, in an ideal world the dominant processor architecture would make this rather easier to accomplish and we wouldn't need such extensive modifications.
Xen is only "special" in that it is technically strong, was the first open source paravirtualised VMM and now has a large amount of support from industry and the community. If it ever becomes the default environment, it'll be for these pragmatic reasons - if another system can do better on those scores then that may become the de facto standard.
A WinXP port to Xen was prepared in Cambridge but is unreleasable due to its intrusive changes to the source code (which was available to the University under the MS Academic Source license).
There are potential ways to hack around this but the current plan is to wait for Intel Vanderpool / AMD Pacifica machines to become available. The hard-to-modify bits of Windows (like the memory management) will see a fully virtualised MMU, etc. Paravirtualised device drivers can still be installed to maximise IO performance.
In the meantime, there's also a port of ReactOS in the pipeline (http://www.reactos.com/wiki/index.php/Xen_port) - seems to be making good progress, although it'll be a while yet before you can run applications on it;-)
As pointed out by the parent poster, NetBSD-current includes support for running as both dom0 (host) and domU (guest) under Xen 2.0. This support will therefore be in NetBSD 3.0.
Sorry for this oversight.
To clarify support in the present release: NetBSD 2.0 includes support for running as dom0 and as domU on Xen 1.2. The Xen tree includes a patch to run NetBSD 2.0 as a domU (guest) on Xen 2.0.
NetBSD was the second OS to be ported to Xen, after the Linux 2.4 port done in Cambridge.
Yes, Intel has contributed code to Xen to support their Vanderpool extensions (now called VT-x) already. This will (eventually) allow you to run Windows in a Xen virtual machine.
AMD have also indicated their support for the Xen project.
Note that performance using (at least a degree of) paravirtualisation (guest OS porting) will likely still be better (at the very least equal) to that of hardware supported virtualisation, so there is still a point to Guest OS modifications and specialised drivers.
I'd say the parent is a fair question, not a troll.
Morton's point appears to be this: * x86 is notoriously unco-operative to full virtualisation * trying to fully virtualise it (as VMWare and Virtual PC do) is a work around for the fact you can't modify the guest OS because it's closed source * fully virtualising x86 in software results in rather painful performance hits for many workloads and a very complex hypervisor * for open source OSs, it therefore makes sense to use paravirtualisation. This involves porting the OS to a special virtual machine-oriented "architecture", closely resembling the real hardware but without the costly-to-virtualise parts. * paravirtualisation can be argued to be better than full virtualisation because (esp. on x86) the performance hit is much lower.
Porting of open source OSs is happening: Linux 2.4 and 2.6, NetBSD, FreeBSD 5.3 and Plan 9 can run on Xen (although currently only the Linuxes are supported as "host" or "Dom0" operating systems).
Maybe the time isn't right for an alternative!
on
Dell Still Intel Only
·
· Score: 2, Insightful
Why not offer customers an alternative that has better performance instead of risking the lose of those customers to another vendor that does?
Right or wrong, markets have inertia. If there isn't enough demand for AMD chips from Dells' huge corporate customers then it makes little business sense to expend effort on providing them. Unfortunately, the technology isn't the only factor here. When sufficient demand exists, expect Dell to get rather more keen on AMD products.
The other factor is AMD's manufacturing capacity. I imagine Dell would be wary about going for AMD if they had concerns about this.
That particular error isn't very user friendly;-) Come on the xen-devel list (see http://lists.xensource.com) and we may be able to sort you out. Alternatively, someone on #xen at OFTC may be able to help.
And following on from that Intel (for instance) can disable one defective core on a chip to make a working single core chip. A defect in a single large core will potentially break the whole core. This is analagous to current techniques of disabling half the cache if there is a defect.
Maybe one day all Pentiums will be dual core and Celerons will be single cores that are actually half-disabled Pentiums. Of course, Intel have been known to disable working features in order to make a "low end" chip, so maybe we'll see hacks to re-enable one core. That would be Coolness;-)
A couple of thoughts as to why CMP is favoured right now:
* Easier to just replicate a core you've already designed then design a new bigger core. Improves time to market, reduces costs, reduces probability of implementation bugs. * Easier to achieve high clock rates if your core is smaller than if it's a huge monolithic SMT core - may achieve higher overall performance (at least, for a given investment in development or for current apps). * The manufacturers may have done their own evaluation and come to slightly different conclusions for the workloads they are targetting.
[disclaimer: I'm a Xen developer] Xen 2.0 itself is pretty robust by now, plenty of people running it in production environment. The tools could do with some work but they are quite nice to use.
I can't say I've played with the NetBSD port yet but NetBSD will have vested interest in making it work well, since they use Xen internally.
You should also be able to boot virtual machines running Linux 2.4 / 2.6.
HT has basically two sets of registers so that during a cache miss which would cuase a bubble the chip switches to the other set so it doesn't sit idle.
I'm sorry but that's not correct. What you refer to is known as "Fine Grained Multithreading", or the product name "Superthreading".
Intel's product "hyperthreading" is also known as "simultaneous multithreading" and is able to run multiple instruction streams simultaneously in order to maximise use of the functional units when they are not saturated by a single instruction stream. This is in addition to avoiding complete stalls on cache misses.
Similar in that they modify the guest OS to run effectively inside the virtual machine. Different in that Xen runs beneath all the OS kernels on the system, whereas Plex86 runs as a module for a host kernel (with guests sitting on top).
I haven't checked out Plex86 recently but I think Xen is rather more functional by now.
There was someone trying this out with Xen (giving each virtual machine direct access to a different graphics card) but a brave volunteer to work on this is really needed to get it up to scratch.
Yes, that's a fair comment. I guess SuSE sees it as "value add" and as a way to get it wider exposure prior to it's inclusion in SLES.
That said Xen's inclusion been stalled for some time on whether a new architecture should be added or whether it should be a subarch of i386, rather than for debugging reasons.
With Xen, you have to staticly partition physical memory among the domains, which can be wasteful if the domains have different workloads. With Zones, the resources can shift between zones dynamically based on usage.
Under Xen you can move memory between domains using the balloon driver. Unlike for Zones, this won't happen automagically at the moment but it wouldn't be difficult to implement simple autoballooning.
With Xen, each domain has a full install of the OS, which takes quite a bit of diskspace.
You can share things like/usr read-only between domains. There's also the possibility of using CoW block devices / filesystems, although we've yet to find an ideal solution for this.
Regarding the article, I think it's also worth pointing out that under Linux, vservers is much closer to BSD Jail / Solaris Zones than Xen or UML and would probably be a better comparison.
Slashdot Mirror
But the function code isn't on the stack, it's in the code segment. Stack frames store local variables, arguments and stack metadata information - no code.
But you can't overwrite stack that isn't being used yet - as soon as it is used your buffer overflow will be overwritten. Buffer overflows != overwriting the code of other functions. Overflowing a buffer depends on being able to overwrite the stack linkage data and (usually) injecting code into the stack. The best explanation I can find for how you'd attack an upwards-growing stack is that of another poster who pointed out that code that iterates over ever-decreasing memory addresses might be tricked into overwriting earlier stack frames. I guess that's the issue, although I'd imagine it was rather more rare than the reverse case.
> But why I ask is the OS allowing one process to
...does...stuff...here...
:-(
> overwrite memory of another.
It's not allowing a process to directly overwrite another process's memory. Buffer overflows basically "trick" a program into overwriting bits of its own memory that the author didn't expect.
> Is it just that the stack is limited?
It's something that you have to code carefully to avoid, since C lacks various checks that avoid the programmer having to worry about this. Lots of languages do have these checks but they're less popular.
Stacks on x86 grow downwards (i.e. to lower memory addresses). Each time you call a function, the top of the stack gets *lower* in virtual memory.
Suppose we have a function "foo":
void foo()
{
char[12] filename;
return;
}
It allocates a 12 character array *on the stack*. If we can trick foo() into writing more than 12 characters into the "filename" array, then it'll continue to write the data into higher and higher addresses *overwriting earlier data on the stack*.
The process is overwriting its own memory so there's nothing the OS can do to protect against it. The trouble is that if the data foo() read is not only too large but contains some malicious code, the application may be tricked into running that code when the function exits. If the application was running as root (or if the code was part of the kernel) then that malicious code now has control of your system
> As another posted said is it a hangover from
> days of tightly limited system resources
> and no swap?
Not really, it's something that just happens. Writing code which allows buffers to be overflowed in this way is sloppy - the coder got it wrong.
How can you affect the behaviour of functions above you on the stack which won't have been called yet?
Growing in a different direction is still not a total solution (the ideal solution being not to have overflowable buffers).
I'm afraid you'll have to educate us - how do Solaris' MAC facilities measure up against SELinux? Are they as flexible? Do they offer any more features? In what way are they better?
Xen and Zones are different things. Yes they both provide virtual servers but in different ways. Both have strengths - the ideal system would support both.
Xen:
* virtually no performance penalty
* supports live migration of virtual servers
* runs Linux 2.4 / 2.6, FreeBSD 5.3, NetBSD 2.0, Plan 9 in guests
* can live-migrate virtual machines between physical hosts
* greater isolation of virtual servers for better security / robustness
* can almost certainly run on more hardware than Solaris
* can run device drivers in fault-resistant sandboxes
* can be used to debug guest OS kernels
Zones:
* lower memory footprint than Xen (and more flexible in memory usage)
* even lower performance penalty, approaching zero (if Sun have Done It Right)
* lighter weight virtual servers than Xen, with better resource sharing between virtual servers
A combination of the two would be really useful - use Xen where you need migration, high assurance isolation, etc. Use VServers where you are less concerned about these issues and want lighter-weight virtualisation.
Neither is "better" than the other without considering the use case.
Xen 1.x could run a ported Windows XP on standard PC hardware. This is the port that was never released to the public.
;-)
Xen-unstable (the development tree, to become 3.0 this summer) includes support for Intel Vanderpool virtual machine extensions - these will allow it to run unmodified guest OSs on supporting hardware.
Unmodified Linux guests will boot on Xen right now on Vanderpool hardware. Windows guests are a little further off (possibly post 3.0) because they require support for various 16-bit x86 cruft
Actually it is true: Cocoa / Carbon apps are restricted to 32 bit. This is allegedly for performance reasons (reduces the cache footprint - apparently for the GUI libraries the overhead of using 64 bit was found significant), not just to simplify implemention. Note that this means although most applications are limited to 32 bits of address space you can still use more than 32 bits of addressable RAM overall. The kernel runs in a 32 bit address space, creating temporary mappings to pages outside this space when necessary (i.e. it doesn't map the whole of physical memory like Linux). They do (AFAIK) maintain binary compatibility for device drivers, unlike Windows, Linux, or anything else I know of.
Actually I agree with you too. On the one hand, from one purely technical point of view avoiding OS modifications because of licensing issues is (in some senses) a work around. On the other hand I see nothing "inappropriate" about closed source licenses so I don't mean to complain about those either. I intended to clarify Andrew Morton's statement to those less familiar with the issues of x86 virtualisation but I probably should have phrased it slightly differently.
Anthony's point was that it will be able to run unmodified guests using Intel's Vanderpool / VT-x extensions and using AMD's Pacifica extensions. VT-x is shipping some time this year, IIRC. I'm not sure when Pacifica is shipping.
I agree completely that it's good to be able to run unmodified OSs. It allows you to match testing installations in virtual machines even closer (though almost certainly not identical) to the real hardware you will run on, it's good for some lowlevel OS development environment. And it would be nice not to introduce a new architecture.
OTOH, it's also good to make the VMM as small as possible and get the maximum performance out of the hardware. Paravirtualisation helps here, so it's a trade-off. Of course, in an ideal world the dominant processor architecture would make this rather easier to accomplish and we wouldn't need such extensive modifications.
Xen is only "special" in that it is technically strong, was the first open source paravirtualised VMM and now has a large amount of support from industry and the community. If it ever becomes the default environment, it'll be for these pragmatic reasons - if another system can do better on those scores then that may become the de facto standard.
That's basically the point.
;-)
A WinXP port to Xen was prepared in Cambridge but is unreleasable due to its intrusive changes to the source code (which was available to the University under the MS Academic Source license).
There are potential ways to hack around this but the current plan is to wait for Intel Vanderpool / AMD Pacifica machines to become available. The hard-to-modify bits of Windows (like the memory management) will see a fully virtualised MMU, etc. Paravirtualised device drivers can still be installed to maximise IO performance.
In the meantime, there's also a port of ReactOS in the pipeline (http://www.reactos.com/wiki/index.php/Xen_port) - seems to be making good progress, although it'll be a while yet before you can run applications on it
As pointed out by the parent poster, NetBSD-current includes support for running as both dom0 (host) and domU (guest) under Xen 2.0. This support will therefore be in NetBSD 3.0.
Sorry for this oversight.
To clarify support in the present release: NetBSD 2.0 includes support for running as dom0 and as domU on Xen 1.2. The Xen tree includes a patch to run NetBSD 2.0 as a domU (guest) on Xen 2.0.
NetBSD was the second OS to be ported to Xen, after the Linux 2.4 port done in Cambridge.
Yes, Intel has contributed code to Xen to support their Vanderpool extensions (now called VT-x) already. This will (eventually) allow you to run Windows in a Xen virtual machine.
AMD have also indicated their support for the Xen project.
Note that performance using (at least a degree of) paravirtualisation (guest OS porting) will likely still be better (at the very least equal) to that of hardware supported virtualisation, so there is still a point to Guest OS modifications and specialised drivers.
[ disclaimer: I'm a Xen developer ]
I'd say the parent is a fair question, not a troll.
Morton's point appears to be this:
* x86 is notoriously unco-operative to full virtualisation
* trying to fully virtualise it (as VMWare and Virtual PC do) is a work around for the fact you can't modify the guest OS because it's closed source
* fully virtualising x86 in software results in rather painful performance hits for many workloads and a very complex hypervisor
* for open source OSs, it therefore makes sense to use paravirtualisation. This involves porting the OS to a special virtual machine-oriented "architecture", closely resembling the real hardware but without the costly-to-virtualise parts.
* paravirtualisation can be argued to be better than full virtualisation because (esp. on x86) the performance hit is much lower.
Porting of open source OSs is happening: Linux 2.4 and 2.6, NetBSD, FreeBSD 5.3 and Plan 9 can run on Xen (although currently only the Linuxes are supported as "host" or "Dom0" operating systems).
Right or wrong, markets have inertia. If there isn't enough demand for AMD chips from Dells' huge corporate customers then it makes little business sense to expend effort on providing them. Unfortunately, the technology isn't the only factor here. When sufficient demand exists, expect Dell to get rather more keen on AMD products.
The other factor is AMD's manufacturing capacity. I imagine Dell would be wary about going for AMD if they had concerns about this.
That particular error isn't very user friendly ;-) Come on the xen-devel list (see http://lists.xensource.com) and we may be able to sort you out. Alternatively, someone on #xen at OFTC may be able to help.
And following on from that Intel (for instance) can disable one defective core on a chip to make a working single core chip. A defect in a single large core will potentially break the whole core. This is analagous to current techniques of disabling half the cache if there is a defect.
;-)
Maybe one day all Pentiums will be dual core and Celerons will be single cores that are actually half-disabled Pentiums. Of course, Intel have been known to disable working features in order to make a "low end" chip, so maybe we'll see hacks to re-enable one core. That would be Coolness
A couple of thoughts as to why CMP is favoured right now:
* Easier to just replicate a core you've already designed then design a new bigger core. Improves time to market, reduces costs, reduces probability of implementation bugs.
* Easier to achieve high clock rates if your core is smaller than if it's a huge monolithic SMT core - may achieve higher overall performance (at least, for a given investment in development or for current apps).
* The manufacturers may have done their own evaluation and come to slightly different conclusions for the workloads they are targetting.
[disclaimer: I'm a Xen developer]
Xen 2.0 itself is pretty robust by now, plenty of people running it in production environment. The tools could do with some work but they are quite nice to use.
I can't say I've played with the NetBSD port yet but NetBSD will have vested interest in making it work well, since they use Xen internally.
You should also be able to boot virtual machines running Linux 2.4 / 2.6.
I'm sorry but that's not correct. What you refer to is known as "Fine Grained Multithreading", or the product name "Superthreading".
Intel's product "hyperthreading" is also known as "simultaneous multithreading" and is able to run multiple instruction streams simultaneously in order to maximise use of the functional units when they are not saturated by a single instruction stream. This is in addition to avoiding complete stalls on cache misses.
Similar in that they modify the guest OS to run effectively inside the virtual machine. Different in that Xen runs beneath all the OS kernels on the system, whereas Plex86 runs as a module for a host kernel (with guests sitting on top). I haven't checked out Plex86 recently but I think Xen is rather more functional by now.
There was someone trying this out with Xen (giving each virtual machine direct access to a different graphics card) but a brave volunteer to work on this is really needed to get it up to scratch.
Yes, that's a fair comment. I guess SuSE sees it as "value add" and as a way to get it wider exposure prior to it's inclusion in SLES. That said Xen's inclusion been stalled for some time on whether a new architecture should be added or whether it should be a subarch of i386, rather than for debugging reasons.
Under Xen you can move memory between domains using the balloon driver. Unlike for Zones, this won't happen automagically at the moment but it wouldn't be difficult to implement simple autoballooning.
You can share things like /usr read-only between domains. There's also the possibility of using CoW block devices / filesystems, although we've yet to find an ideal solution for this.
Regarding the article, I think it's also worth pointing out that under Linux, vservers is much closer to BSD Jail / Solaris Zones than Xen or UML and would probably be a better comparison.
I think it'll be a _very_ long time before it's sensible for Dell to drop Intel.
However, I'm not sure selling a single AMD model would make good business sense - they'd at least want to offer _some_ choice.