OpenBSD, AMD64, IA32e

[CTho9305]

Is this true about Intel's costly cheap knock-off of the Athlon64 and Opteron line?

 

[n0cmonkey]

If Intel did not impliment the security features that make AMD64 worthwhile, they are idiots. Or trying to promote ia64. Either way, I won't be buying 64bit intel chips.

 

[imported_Phil]

I have to admit, it looks like Intel have really dropped the ball several times with 64-bit on the desktop. However, with Intel being Intel, they'll pour millions into R&D and come up with something that can compete with AMD, in some vague and inefficient way

 

[AFB]

Originally posted by: DopeFiend
I have to admit, it looks like Intel have really dropped the ball several times with 64-bit on the desktop. However, with Intel being Intel, they'll pour millions into R&D and come up with something that can compete with AMD, in some vague and inefficient way

And then sell it at 2x the cost of the AMD.

 

[n0cmonkey]

Originally posted by: DopeFiend
I have to admit, it looks like Intel have really dropped the ball several times with 64-bit on the desktop. However, with Intel being Intel, they'll pour millions into R&D and come up with something that can compete with AMD, in some vague and inefficient way

But if the rumors posted here are true, Intel has decided not to use the most important features of AMD64. 64bits is nice, but per page permissions are even nicer.

 

[n0cmonkey]

Rereading Theo's email brought to my attention that the permissions used in the ia32/x86 architecture will not work in 64bit mode! Geez, talk about leaving yourself wide open... Maybe Intel was still working on that part, since Theo did get a pre-production version.

 

[drag]

Originally posted by: n0cmonkey
Rereading Theo's email brought to my attention that the permissions used in the ia32/x86 architecture will not work in 64bit mode! Geez, talk about leaving yourself wide open... Maybe Intel was still working on that part, since Theo did get a pre-production version.

Alright, this W^X protection stuff is to help programmers protect against bad things happening in Buffer overruns? It's all a bit over my head.


But if I understand the basic concept..

Maybe it's part of a BS stratagy (if this is true). If AMD64 and Intel's 64 is mostly compatable, then most commercial software will be coded to work without those extra permissions and security features.

That way even if AMD64 incorporates all the niceties that are required for high-end servers and good security that was only previously aviable from high end chips then most people won't use them anyways. That way if you want to have programs that support those features then your going to have to go to intanium anyways, since most programs won't support it since having 2 different versions of programs for fundamentally the same archatecture is just going to be to big of a pain in the butt to support for most companies.

Little features and niceties like the thermal throttling, cooler running, and reliability features is what kept AMD out of the server market and helped keep Xeons dominate in that market, even though AMD's are obviously better performers per cost unit in terms of cpu performance.

AMD learned their lesson, but Intel could be trying to keep them out by making software for x86-64 crappy in someway that 95% of people buying computers couldn't care less.

You would think though that MS would be pissed off at them for doing something like this. I mean that they spent so much time porting WinXP and 2003 to x86-64 only to find out that THE dominate cpu chip manufacturer is going to be eliminating features that will help secure their operating system... unless, of course, windows was never going to use these features anyways...

So it ends up that AMD is going to be producing chips with some extra features that most people can't practicly use because of programming limitations, while Intel is going to neglect these features in order to produce cheaper chips that they will probably charge more for.

 

[Nothinman]

Alright, this W^X protection stuff is to help programmers protect against bad things happening in Buffer overruns? It's all a bit over my head.

On IA32 if a page is writable it's also executable, meaning once the overflow happens you just have to find a way to make EIP point to the overflow area to execute your code. What AMD64 (and everyone else that's not IA32 compatible) does is include an extra security bit that allows you to set pages writable but not executable, so even though the overflow still happens and the app crashes there's no chance to execute code from the overflow. Userland programmers don't see any difference, the kernel is what manages the page permissions.

 

[drag]

Originally posted by: Nothinman

Alright, this W^X protection stuff is to help programmers protect against bad things happening in Buffer overruns? It's all a bit over my head.

On IA32 if a page is writable it's also executable, meaning once the overflow happens you just have to find a way to make EIP point to the overflow area to execute your code. What AMD64 (and everyone else that's not IA32 compatible) does is include an extra security bit that allows you to set pages writable but not executable, so even though the overflow still happens and the app crashes there's no chance to execute code from the overflow. Userland programmers don't see any difference, the kernel is what manages the page permissions.

Ah. So it's more likely that Intel is just being lazy rather then being neferious.

 

[n0cmonkey]

Originally posted by: drag

Originally posted by: Nothinman

Alright, this W^X protection stuff is to help programmers protect against bad things happening in Buffer overruns? It's all a bit over my head.

On IA32 if a page is writable it's also executable, meaning once the overflow happens you just have to find a way to make EIP point to the overflow area to execute your code. What AMD64 (and everyone else that's not IA32 compatible) does is include an extra security bit that allows you to set pages writable but not executable, so even though the overflow still happens and the app crashes there's no chance to execute code from the overflow. Userland programmers don't see any difference, the kernel is what manages the page permissions.

Ah. So it's more likely that Intel is just being lazy rather then being neferious.

x86 can use segments to change things. So yes, Intel is being lazy. In 64bit mode ia32e cannot use segments to try and help with this, and they did not include per page permissions. So there are less security features in ia32e than in even ia32/x86.

And Microsoft *has* support for the NX bit on AMD64. It is one of the features of the much anticipated sp2 for AMD64. info

 

[drag]

Well, there is a big difference between saying you support something and actually supporting it. Atfer all it's closed source and most people will never know unless someone finds a buffer overflow-based exploit that would normally be stopped with the NX bit activated.

But seeing how it's mostly kernel stuff then I beleive MS it when they say they are going to support it. However it may be same amount support as the amount of USB support in win95. Hell, if I know, though. My opinion should probably be best ignored in this sort of thing.

Although there are a couple nice quotes from that article:

Intel said its next Pentium 4 chip, Prescott, would not support NX. "There are compatibility concerns around NX. We would only introduce it once those are dealt with," an Intel spokesman told Computer Weekly.

(edit: Why not just introduce it now? If there is compatability issues then the programs just shouldn't use it untill the software issues get solved. Otherwise older intel x86-64 proccessors will be useless? It doesn't make sense to me)

(edit X2: Nevermind he was talking about Pentium 4's not intel AMD64 bit version.)

, "NX technology should be considered by companies as part of their upgrade plans." She said if NX processors are already available from AMD and if Intel is about to launch them*, companies that can wait before immediately upgrading should do so to take advantage of the NX fix.

*(my emphisis)

 

[n0cmonkey]

The problems with NX are typically poor programming.

 

[Nothinman]

The problems with NX are typically poor programming.

Or possibly something like Java that could write to a processes stack space, I suppose.

 

[n0cmonkey]

Originally posted by: Nothinman

The problems with NX are typically poor programming.

Or possibly something like Java that could write to a processes stack space, I suppose.

And JAVA.

Forgot about JAVA. I think JAVA was mentioned specifically somewhere...