"Calling a function" requires more than just generating a legal address. You have to map data segments, perform whatever loading/relocations (you know, like for calls back into the OS) as necessary, allocate a stack etc. You also have to create a convention for sharing some address space between the 64 and 32 bit mechanisms.
I.e., you need something akin to the 32-bit DOS extender, as well as some kind of "super-loader" that can load both 32 and 64 bit code.
On the other hand, if the OS can load the two seperately with seperate loaders, and expose a message passing scheme (like sockets) in which the two can talk to each other, then you don't have to build such convoluated technology. I.e., compile your application once each with both 64 and 32 compilers, then just detect the best mode that is available and exec the better binary.
Given that this is not considered "a lot of money" why not instead see if you can come to a compromise. Perhaps a figure less than 2.4 million, to promise not to buy/renew any Microsoft new contracts for 7 years with a 100% refund clause on any significant violation.
7 years is an eternity for the computer industry -- if Linux cannot be able to hold its own accross the board in 7 years, then there's little point. It gives the school two possible outs -- forfeiture or just wait out the 7 year time limit before returning to MS.
A torus (dougnut) is topologically equivalent to a square with sides identified (like the Space War).
-End Jargon-
Well as long as we are spouting jargon, you might as well point out *how* the sides are identified. A normal torus, for example, would not twist, rotate, or flip the sides as the means of identity, as that would create some kind of mobius strip-like topology. I.e., the sides are mapped as if rigidly translated.
Prior to the X-Box project, the Microsoft entertainment group was profitable. Aside from that your point is correct -- every other division of Microsoft loses money.
I was unaware that IDA went to that kind of depth in its latest versions. I am familliar with their product but have an old version.
Indeed, xor eax, eax, is hard coded into most modern x86 CPUs as a "CLR EAX", but one notable exception is the AMD K6. Because of the issue with artificial dependency chains, it is actually sometimes faster to perform a MOV EAX, 0 for that processor. Furthermore, it is well known that the P6 has branch target alignment issues, so using differently sized instructions can help you align your branch targets -- and in the case of MOV EAX, 0 versus XOR EAX, EAX they are equivalent in terms of performance, only differing in the opcode space they use.
From the intel instruction set manual: "The SUB instruction... sets the CF flags to indicate an overflow in the unsigned result". Which means that the CF stays the same for both instructions since their results are the same.
Dude, this is a verbatim session with debug.com:
c:\>debug -a 104C:0100 xor ax,ax 104C:0102 sub ax, -3 104C:0105 int 3 104C:0106 xor ax, ax 104C:0108 add ax, 3 104C:010B int 3 104C:010C -g
AX=0003 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=104C ES=104C SS=104C CS=104C IP=0105 NV UP EI PL NZ AC PE CY 104C:0105 CC INT 3 -rip IP 0105 :106 -g
AX=0003 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=104C ES=104C SS=104C CS=104C IP=010B NV UP EI PL NZ NA PE NC 104C:010B CC INT 3 -
Notice the "CY" and "NC"'s in the two different runs. Just because Intel has defined "overflow" circularly, or in an opposite sense than you might be thinking about for subtraction doesn't mean we can't deduce what is really going by simply running the code for ourselves.
I spoke too soon! Actually now that I've read the article myself and dug deeper in the story I realize there is a bigger issue here. The technique used in "Hydan" actually is broken! The ADD and SUB instruction will set the carry flag in opposite directions meaning simple code sequences like:
A -= 3;
if (A 0)...
Which might be encoded as:
SUB EAX, 3
JC...
will cease to function correctly!! The technique I cite (which has been proven and used in the a86 assembler) *DOES* work, since you don't change any of the instruction semantics, but just the instruction encodings.
So in fact, this *IS* yet another bogus story posted by timothy...
You are correct -- detection should be easy so long as you have access to the original unmodified binary. I.e., an original software vendor could embed the message in a product of their own making and you would have no idea.
Furthermore in opensource environments, it may be very difficult to determine if differences are due to different compiler flag settings, or just a different version of the compiler.
In your examples, if there is are jump target in there somewhere they won't work. Remember that these are binary recompiler tools -- the source is not necessarily available, and it might not be decompilable to find all jump targets.
The second example has the additional problem of having a different side-effect on AX and possibly stack faulting.
Can someone explain to me exactly what this means? Will all i386 executable binaries have unnecessary redundancy?
The x86 instruction set has some very convoluted encodings mostly due to the various addressing modes and sometimes assumed registers. Many of the common instructions have more than one way to be encoded. You can get more information at http://www.sandpile.org/
I believe, in fact, that *most* x86 executable streams will expose a lot of this redundancy, and therefore there should be lots of potential for this. Of course it'll drive anti-virus checkers nuts...
Yeah, I know another unchecked perpetual motion machine story from timothy. But no, in this case, the story is not wrong, its just 15 years old (the technique was used 15 year ago, I mean.)
The key point is to exploit x86 instruction set redundancy to find a few bits of entropy here and there strewn throughout the executable code. RISC instructions have the same potential. For example:
add r0, r1, r2
add r0, r2, r1 # not much different
Intel is a company that time and time again proves it knows how to make money.
Yeah, by relegating each successive x86 architecture to the role of "back up plan" and pushing forward some "new idea" like i432, i860/i960, and now Itanium.
The fact is, although their formula for success is so god damned bloody obvious (sell more x86s) they only managed to realize this almost by accident.
Sure there are lots of difficulties going to a new ISA.
And as any other CPU endeavour will attest, you can't fix the ISA, except to add instructions in afterwards (and even then you have "legacy applications" problems.)
Especially at the server level. And yes Itanium has had some performance problems, especially in its first revision, but then again when was the last time you saw a company produce a 1st generation microprocessor and have it do well?
Alpha? Sparc? MIPS? All of them topped the performance charts when they were first introduced, and typically by margins *much* higher than Itanium 2's current FP lead in Spec FP.
IA64 offers tons of advanced ILP concepts and OS concepts that, when correctly implemented, can increase performance drastically.
Yeah unfortunately it requires that you write your software in a completely different way, or have compilers using "the hand of god" techniques.
(if your looking for examples, data speculation,
Something available from transmeta's CPUs.
control speculation,
More commonly referred to as "branch prediction".
predication,
Conditional moves -- yawn.
registers with kernel access only,
Are you sure that this is unique to IA-64? We know for a fact that x86-64 will at the very least, reserve FS and GS for ring-0 access.
rotating register files,
As opposed to the more general "renamed registers".
The problem may be, it puts a lot of complexity into the Compilers, and compiler technology isn't good enough for Itanium yet.
Has it occurred to you that perhaps it *cannot* get good enough? The results you see are the most herculean efforts from the combined HP and Intel compiler teams. Its not like there is some magical compiler solution -- they already have state of the art in compiler technology in what they have today.
RISC simply means that an operation instruction is embedded with both the opcode and the operands.
No, RISC means "Reduced Instruction Set Computer".
A CISC chip is one in which the opcode tends to be the first instruction processed and the operands are the next couple of instructions inputted.
No, CISC is a name made up by the people who invented the name RISC as is applied in a derrogatory manner to x86. Note that nearly all "RISC" chips in use today also need to pre-process instructions before they are executed as well. This is because of state machine instructions (like DIV) multiple actions instructions (test-and-set) and just plain weirdo instruction ideas (ARMs embed optional shift in all ALU instructions, PPCs have a multiple store instructions, etc.) You can see this in their pipelines -- they all have stages like "decode" or "crack" where things like this are figured out.
The real difference between x86's and RISC's are that the x86 ISA was designed without consideration for contemporary CPU design technology (that is/was available at the time), while RISCs supposedly are. But anyone who has looked under the hood of these CPUs will see that this has not impeded the modern x86s. x86s are more complicated (and therefore in theory should probably be either a bit larger or slower) but as time shown, instruction set complications are not the only consideration for CPU design.
All x86's are pipelined, and in fact use the absolute latest CPU design techniques. The Pentium 4, in fact, has pseudo-double clocked integer ALUs and hyper-threading. Neither of these are available in any other RISC CPU.
You ideally want to be able to take a multi-gigabyte file, and mmap() it so that it appears to your program to be just a stretch of memory.... PAE won't help you in those cases.
Yeah, that's all true, but more importantly, Intel is not going to put all their eggs in the *NIX basket. And Microsoft has pretty much gone on record on this point -- PAE has no future.
For Intel to seriously back PAE as an alternative to Hammer's functionality, then they need an new OS, and to convince programmers to recompile their apps, for this short term memory extension solution. This situation didn't help the 286, and it won't help the Pentiums either.
One time pads are not uncrackable by definition. They have two weak points.
1) The generation of the pads.
One time pads are as crackable as your method for generating the pads. If your pad is TRULY random than it can't be cracked via statistics and probability. You must also be sure that no one else saw the pads or had access to the same entropy pool you used to generate the pads.
By modern standards, this is a minor point. There are plenty of good ways of capturing non-reversable randomness (exact micro-timer results from key presses or mouse movements) and expanding them to much larger sequences of random bits (using one of the various "good" pseudo-random number generators, such as those by Marsaglia.)
2) The distribution of the pads.
Both parties need a copy of the pad for it to work. How do the parties get the pads? Is this process secure? If not, than the quality of the pad is moot.
This in fact is the only real sore point. For comparison -- strong public key crypto only requires that your own machine is secure, while OTP encryption requires that you have a completely uncompromised channel for at least the length of time required to transmit the key, *and* *neither* machine can be compromised.
Isaac Hayes has no control over the content of South Park -- there has been a blatantly obvious diss of Scientology episode (Blanetology.) Considering the utter fear everyone has about Scientology (and rightfully so) I am happy that Matt and Trey didn't let it control them at all.
Most people who have looked into this have not found your claim to be true. The Intel compiler *does* produce better code on average. I will agree with you about the code vectorization of the Intel compiler except for the very latest version of it which has actually shown itself to vectorize pretty much any time there is a reasonable opportunity for it.
Slashdot Mirror
I believe the TCPA requires chipset support, not CPU support.
"Calling a function" requires more than just generating a legal address. You have to map data segments, perform whatever loading/relocations (you know, like for calls back into the OS) as necessary, allocate a stack etc. You also have to create a convention for sharing some address space between the 64 and 32 bit mechanisms.
I.e., you need something akin to the 32-bit DOS extender, as well as some kind of "super-loader" that can load both 32 and 64 bit code.
On the other hand, if the OS can load the two seperately with seperate loaders, and expose a message passing scheme (like sockets) in which the two can talk to each other, then you don't have to build such convoluated technology. I.e., compile your application once each with both 64 and 32 compilers, then just detect the best mode that is available and exec the better binary.
Given that this is not considered "a lot of money" why not instead see if you can come to a compromise. Perhaps a figure less than 2.4 million, to promise not to buy/renew any Microsoft new contracts for 7 years with a 100% refund clause on any significant violation.
7 years is an eternity for the computer industry -- if Linux cannot be able to hold its own accross the board in 7 years, then there's little point. It gives the school two possible outs -- forfeiture or just wait out the 7 year time limit before returning to MS.
- -Begin Jargon-
Well as long as we are spouting jargon, you might as well point out *how* the sides are identified. A normal torus, for example, would not twist, rotate, or flip the sides as the means of identity, as that would create some kind of mobius strip-like topology. I.e., the sides are mapped as if rigidly translated.A torus (dougnut) is topologically equivalent to a square with sides identified (like the Space War).
-End Jargon-
Prior to the X-Box project, the Microsoft entertainment group was profitable. Aside from that your point is correct -- every other division of Microsoft loses money.
I was unaware that IDA went to that kind of depth in its latest versions. I am familliar with their product but have an old version.
Indeed, xor eax, eax, is hard coded into most modern x86 CPUs as a "CLR EAX", but one notable exception is the AMD K6. Because of the issue with artificial dependency chains, it is actually sometimes faster to perform a MOV EAX, 0 for that processor. Furthermore, it is well known that the P6 has branch target alignment issues, so using differently sized instructions can help you align your branch targets -- and in the case of MOV EAX, 0 versus XOR EAX, EAX they are equivalent in terms of performance, only differing in the opcode space they use.
- From the intel instruction set manual:
... sets the CF flags to indicate an overflow in the unsigned result".
Dude, this is a verbatim session with debug.com:"The SUB instruction
Which means that the CF stays the same for both instructions since their results are the same.
c:\>debug
-a
104C:0100 xor ax,ax
104C:0102 sub ax, -3
104C:0105 int 3
104C:0106 xor ax, ax
104C:0108 add ax, 3
104C:010B int 3
104C:010C
-g
AX=0003 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=104C ES=104C SS=104C CS=104C IP=0105 NV UP EI PL NZ AC PE CY
104C:0105 CC INT 3
-rip
IP 0105
-g
AX=0003 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=104C ES=104C SS=104C CS=104C IP=010B NV UP EI PL NZ NA PE NC
104C:010B CC INT 3
-
Notice the "CY" and "NC"'s in the two different runs. Just because Intel has defined "overflow" circularly, or in an opposite sense than you might be thinking about for subtraction doesn't mean we can't deduce what is really going by simply running the code for ourselves.
You can use SUB AX, AX in place of XOR AX, AX with no issue (both will set the flags equivalently.)
I spoke too soon! Actually now that I've read the article myself and dug deeper in the story I realize there is a bigger issue here. The technique used in "Hydan" actually is broken! The ADD and SUB instruction will set the carry flag in opposite directions meaning simple code sequences like:
...
...
...
A -= 3;
if (A 0)
Which might be encoded as:
SUB EAX, 3
JC
will cease to function correctly!! The technique I cite (which has been proven and used in the a86 assembler) *DOES* work, since you don't change any of the instruction semantics, but just the instruction encodings.
So in fact, this *IS* yet another bogus story posted by timothy
You are correct -- detection should be easy so long as you have access to the original unmodified binary. I.e., an original software vendor could embed the message in a product of their own making and you would have no idea.
Furthermore in opensource environments, it may be very difficult to determine if differences are due to different compiler flag settings, or just a different version of the compiler.
In your examples, if there is are jump target in there somewhere they won't work. Remember that these are binary recompiler tools -- the source is not necessarily available, and it might not be decompilable to find all jump targets.
The second example has the additional problem of having a different side-effect on AX and possibly stack faulting.
- It means that if you want to add 50 to a number, you can choose to do (+50) or (-(-50)).
Actually on the x86, those two are not equivalent. They set the carry flag in opposite directions.The x86 instruction set has some very convoluted encodings mostly due to the various addressing modes and sometimes assumed registers. Many of the common instructions have more than one way to be encoded. You can get more information at http://www.sandpile.org/
I believe, in fact, that *most* x86 executable streams will expose a lot of this redundancy, and therefore there should be lots of potential for this. Of course it'll drive anti-virus checkers nuts
Yeah, I know another unchecked perpetual motion machine story from timothy. But no, in this case, the story is not wrong, its just 15 years old (the technique was used 15 year ago, I mean.)
The key point is to exploit x86 instruction set redundancy to find a few bits of entropy here and there strewn throughout the executable code. RISC instructions have the same potential. For example:
add r0, r1, r2
add r0, r2, r1 # not much different
This is a well known technique that was used in the mid-80s by Eric Isaacson in his product "a86". See here: http://eji.com/a86/
Eric Isaacson used the technique to mark executables, so that he could determine if they were created with an unregistered copy of a86.
- I've received plenty, the trick is to just not open attachments from people I don't know.
That's nonsense, a lot of the Outlook viruses rummage through address books and in fact send themselves to you under all your correspondents names.- Intel is a company that time and time again proves it knows how to make money.
Yeah, by relegating each successive x86 architecture to the role of "back up plan" and pushing forward some "new idea" like i432, i860/i960, and now Itanium.The fact is, although their formula for success is so god damned bloody obvious (sell more x86s) they only managed to realize this almost by accident.
- Sure there are lots of difficulties going to a new ISA.
And as any other CPU endeavour will attest, you can't fix the ISA, except to add instructions in afterwards (and even then you have "legacy applications" problems.)- Especially at the server level. And yes Itanium has had some performance problems, especially in its first revision, but then again when was the last time you saw a company produce a 1st generation microprocessor and have it do well?
Alpha? Sparc? MIPS? All of them topped the performance charts when they were first introduced, and typically by margins *much* higher than Itanium 2's current FP lead in Spec FP.- IA64 offers tons of advanced ILP concepts and OS concepts that, when correctly implemented, can increase performance drastically.
Yeah unfortunately it requires that you write your software in a completely different way, or have compilers using "the hand of god" techniques.- (if your looking for examples, data speculation,
Something available from transmeta's CPUs.- control speculation,
More commonly referred to as "branch prediction".- predication,
Conditional moves -- yawn.- registers with kernel access only,
Are you sure that this is unique to IA-64? We know for a fact that x86-64 will at the very least, reserve FS and GS for ring-0 access.- rotating register files,
As opposed to the more general "renamed registers".- The problem may be, it puts a lot of complexity into the Compilers, and compiler technology isn't good enough for Itanium yet.
Has it occurred to you that perhaps it *cannot* get good enough? The results you see are the most herculean efforts from the combined HP and Intel compiler teams. Its not like there is some magical compiler solution -- they already have state of the art in compiler technology in what they have today.- RISC simply means that an operation instruction is embedded with both the opcode and the operands.
No, RISC means "Reduced Instruction Set Computer".- A CISC chip is one in which the opcode tends to be the first instruction processed and the operands are the next couple of instructions inputted.
No, CISC is a name made up by the people who invented the name RISC as is applied in a derrogatory manner to x86. Note that nearly all "RISC" chips in use today also need to pre-process instructions before they are executed as well. This is because of state machine instructions (like DIV) multiple actions instructions (test-and-set) and just plain weirdo instruction ideas (ARMs embed optional shift in all ALU instructions, PPCs have a multiple store instructions, etc.) You can see this in their pipelines -- they all have stages like "decode" or "crack" where things like this are figured out.The real difference between x86's and RISC's are that the x86 ISA was designed without consideration for contemporary CPU design technology (that is/was available at the time), while RISCs supposedly are. But anyone who has looked under the hood of these CPUs will see that this has not impeded the modern x86s. x86s are more complicated (and therefore in theory should probably be either a bit larger or slower) but as time shown, instruction set complications are not the only consideration for CPU design.
All x86's are pipelined, and in fact use the absolute latest CPU design techniques. The Pentium 4, in fact, has pseudo-double clocked integer ALUs and hyper-threading. Neither of these are available in any other RISC CPU.
- You ideally want to be able to take a multi-gigabyte file, and mmap() it so that it appears to your program to be just a stretch of memory.
... PAE won't help you in those cases.
Yeah, that's all true, but more importantly, Intel is not going to put all their eggs in the *NIX basket. And Microsoft has pretty much gone on record on this point -- PAE has no future.For Intel to seriously back PAE as an alternative to Hammer's functionality, then they need an new OS, and to convince programmers to recompile their apps, for this short term memory extension solution. This situation didn't help the 286, and it won't help the Pentiums either.
- One time pads are not uncrackable by definition. They have two weak points.
By modern standards, this is a minor point. There are plenty of good ways of capturing non-reversable randomness (exact micro-timer results from key presses or mouse movements) and expanding them to much larger sequences of random bits (using one of the various "good" pseudo-random number generators, such as those by Marsaglia.)1) The generation of the pads.
One time pads are as crackable as your method for generating the pads. If your pad is TRULY random than it can't be cracked via statistics and probability. You must also be sure that no one else saw the pads or had access to the same entropy pool you used to generate the pads.
- 2) The distribution of the pads.
This in fact is the only real sore point. For comparison -- strong public key crypto only requires that your own machine is secure, while OTP encryption requires that you have a completely uncompromised channel for at least the length of time required to transmit the key, *and* *neither* machine can be compromised.Both parties need a copy of the pad for it to work. How do the parties get the pads? Is this process secure? If not, than the quality of the pad is moot.
Isaac Hayes has no control over the content of South Park -- there has been a blatantly obvious diss of Scientology episode (Blanetology.) Considering the utter fear everyone has about Scientology (and rightfully so) I am happy that Matt and Trey didn't let it control them at all.
That's why South Park is so much a better show -- they don't let Isaac Hayes dictate what Trey and Matt write (ref: episode about Blanetology.)
Well, Conan O'Brian has this late night TV show that you could watch -- he was one of the writers you know.
Most people who have looked into this have not found your claim to be true. The Intel compiler *does* produce better code on average. I will agree with you about the code vectorization of the Intel compiler except for the very latest version of it which has actually shown itself to vectorize pretty much any time there is a reasonable opportunity for it.
- The Watcom compiler is the only compiler that supports writing 32 bit code using 48 bit pointers.
Not very. None of the libraries have been compiled in this mode, as there was no supported OS at the time which supported this kind of memory model.Thanks for the info. How valuable is that?