Is it truly impossible to tell what a CPU is doing?CPU/Processor error rate in calculationsHow does a CPU work?Understanding CPU clock signal processingWhat limits CPU speed?How to program pentium CPUWhat happens to the electricity after it is used in a CPU cycle?1 bit shannon entropy CPU instructions?Can you stack one cpu on top of another, same cpu?WiFi-CPU Direct TalkWhat is the composition of CPU chip
Why isn't Tyrion mentioned in the in-universe book "A Song of Ice and Fire"?
How can I tell if I'm being too picky as a referee?
Time complexity of an algorithm: Is it important to state the base of the logarithm?
Beginner looking to learn/master musical theory and instrumental ability. Where should I begin?
Why haven't we yet tried accelerating a space station with people inside to a near light speed?
Is it rude to call a professor by their last name with no prefix in a non-academic setting?
SFDX: where can set Field-level security and accessibility?
What is the meaning of "<&3" and "done < file11 3< file22"
Determine this limit
Why isn't 'chemically-strengthened glass' made with potassium carbonate to begin with?
Can I install a back bike rack without attachment to the rear part of the frame?
What Armor Optimization applies to a Mithral full plate?
Take elements from a list based on two criteria
Is it legal to meet with potential future employers in the UK, whilst visiting from the USA
ESTA validity after a visa denial
Can my floppy disk still work without a shutter spring?
Making a electromagnet
Mercedes C180 (W204) dash symbol
Where is Jon going?
What's difference between "depends on" and "is blocked by" relations between issues in Jira next-gen board?
Are black holes spherical during merger?
Which European Languages are not Indo-European?
Non-containing subsets of two sizes
How does the EU Emissions Trading Scheme account for increased emissions outside the EU?
Is it truly impossible to tell what a CPU is doing?
CPU/Processor error rate in calculationsHow does a CPU work?Understanding CPU clock signal processingWhat limits CPU speed?How to program pentium CPUWhat happens to the electricity after it is used in a CPU cycle?1 bit shannon entropy CPU instructions?Can you stack one cpu on top of another, same cpu?WiFi-CPU Direct TalkWhat is the composition of CPU chip
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
Computer programmers often recite the mantra that x86 instructions are totally opaque: Intel tells us they are doing something, but there is no hope that anyone can verify what's happening, so if the NSA tells them to backdoor their RNGs, then we can't really do anything about it.
Well, I believe that computer programmers can't do anything about this problem. But how would an electric engineer attack it? Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
cpu reverse-engineering
asked 9 hours ago
user14717user14717
1291
New contributor
user14717 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
|
show 1 more comment
$begingroup$
Computer programmers often recite the mantra that x86 instructions are totally opaque: Intel tells us they are doing something, but there is no hope that anyone can verify what's happening, so if the NSA tells them to backdoor their RNGs, then we can't really do anything about it.
Well, I believe that computer programmers can't do anything about this problem. But how would an electric engineer attack it? Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
cpu reverse-engineering
asked 9 hours ago
user14717user14717
1291
New contributor
user14717 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
1
$begingroup$
You'd have to do something like xray the die and analyze everything to see what it's actually doing. Basically reverse engineer the chip and account for trhe function of every circuit. Totally impractical.
$endgroup$
– Toor
9 hours ago
1
$begingroup$
No electrical circuit performs to an exact spec because of noise and the slight possibility that one day there will be a glitch that is "big enough".
$endgroup$
– Andy aka
9 hours ago
$begingroup$
There are techniques and tools to reverse chips - xray as said, microscopes and such. Modern microprocessors are extremely complex beasts, so such a work will be extremely difficult, but possible..
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
This is very much like trying to reconstruct the Windows source code from its kernel image. Possible in theory, true, but way too much effort...
$endgroup$
– michi7x7
8 hours ago
$begingroup$
Fun info: This is vaguely related to Laplace's demon.
$endgroup$
– Harry Svensson
8 hours ago
|
show 1 more comment
$begingroup$
Computer programmers often recite the mantra that x86 instructions are totally opaque: Intel tells us they are doing something, but there is no hope that anyone can verify what's happening, so if the NSA tells them to backdoor their RNGs, then we can't really do anything about it.
Well, I believe that computer programmers can't do anything about this problem. But how would an electric engineer attack it? Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
cpu reverse-engineering
asked 9 hours ago
user14717user14717
1291
New contributor
user14717 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
Computer programmers often recite the mantra that x86 instructions are totally opaque: Intel tells us they are doing something, but there is no hope that anyone can verify what's happening, so if the NSA tells them to backdoor their RNGs, then we can't really do anything about it.
Well, I believe that computer programmers can't do anything about this problem. But how would an electric engineer attack it? Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
cpu reverse-engineering
cpu reverse-engineering
asked 9 hours ago
user14717user14717
1291
New contributor
user14717 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 9 hours ago
user14717user14717
1291
New contributor
user14717 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 9 hours ago
user14717user14717
1291
New contributor
user14717 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 9 hours ago
user14717user14717
1291
asked 9 hours ago
user14717user14717
1291
1291
New contributor
user14717 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user14717 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
$begingroup$
You'd have to do something like xray the die and analyze everything to see what it's actually doing. Basically reverse engineer the chip and account for trhe function of every circuit. Totally impractical.
$endgroup$
– Toor
9 hours ago
1
$begingroup$
No electrical circuit performs to an exact spec because of noise and the slight possibility that one day there will be a glitch that is "big enough".
$endgroup$
– Andy aka
9 hours ago
$begingroup$
There are techniques and tools to reverse chips - xray as said, microscopes and such. Modern microprocessors are extremely complex beasts, so such a work will be extremely difficult, but possible..
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
This is very much like trying to reconstruct the Windows source code from its kernel image. Possible in theory, true, but way too much effort...
$endgroup$
– michi7x7
8 hours ago
$begingroup$
Fun info: This is vaguely related to Laplace's demon.
$endgroup$
– Harry Svensson
8 hours ago
|
show 1 more comment
1
$begingroup$
You'd have to do something like xray the die and analyze everything to see what it's actually doing. Basically reverse engineer the chip and account for trhe function of every circuit. Totally impractical.
$endgroup$
– Toor
9 hours ago
1
$begingroup$
No electrical circuit performs to an exact spec because of noise and the slight possibility that one day there will be a glitch that is "big enough".
$endgroup$
– Andy aka
9 hours ago
$begingroup$
There are techniques and tools to reverse chips - xray as said, microscopes and such. Modern microprocessors are extremely complex beasts, so such a work will be extremely difficult, but possible..
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
This is very much like trying to reconstruct the Windows source code from its kernel image. Possible in theory, true, but way too much effort...
$endgroup$
– michi7x7
8 hours ago
$begingroup$
Fun info: This is vaguely related to Laplace's demon.
$endgroup$
– Harry Svensson
8 hours ago
1
1
$begingroup$
You'd have to do something like xray the die and analyze everything to see what it's actually doing. Basically reverse engineer the chip and account for trhe function of every circuit. Totally impractical.
$endgroup$
– Toor
9 hours ago
$begingroup$
You'd have to do something like xray the die and analyze everything to see what it's actually doing. Basically reverse engineer the chip and account for trhe function of every circuit. Totally impractical.
$endgroup$
– Toor
9 hours ago
1
1
$begingroup$
No electrical circuit performs to an exact spec because of noise and the slight possibility that one day there will be a glitch that is "big enough".
$endgroup$
– Andy aka
9 hours ago
$begingroup$
No electrical circuit performs to an exact spec because of noise and the slight possibility that one day there will be a glitch that is "big enough".
$endgroup$
– Andy aka
9 hours ago
$begingroup$
There are techniques and tools to reverse chips - xray as said, microscopes and such. Modern microprocessors are extremely complex beasts, so such a work will be extremely difficult, but possible..
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
There are techniques and tools to reverse chips - xray as said, microscopes and such. Modern microprocessors are extremely complex beasts, so such a work will be extremely difficult, but possible..
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
This is very much like trying to reconstruct the Windows source code from its kernel image. Possible in theory, true, but way too much effort...
$endgroup$
– michi7x7
8 hours ago
$begingroup$
This is very much like trying to reconstruct the Windows source code from its kernel image. Possible in theory, true, but way too much effort...
$endgroup$
– michi7x7
8 hours ago
$begingroup$
Fun info: This is vaguely related to Laplace's demon.
$endgroup$
– Harry Svensson
8 hours ago
$begingroup$
Fun info: This is vaguely related to Laplace's demon.
$endgroup$
– Harry Svensson
8 hours ago
|
show 1 more comment
3 Answers
3
active
oldest
votes
$begingroup$
Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
In theory, yes, I think this is possible. However, for a complex CPU it will take a lot of time and money. Also, if you do not fully know and understand the design, you will be unable to judge if any activity is "legit" or not.
A CPU is "just" a complex digital circuit consisting of many logic cells.
It is possible to reverse engineer the chip and reconstruct the design by observing the metal connections. There can be many of these connection layers like up to 8 layers or more.
You will need experts in the field to recognize the logic cells and then maybe some software can figure out how they're all connected so you can reconstruct the netlist.
Once you have the netlist you "know" the design. That doesn't mean you now also know how it works!
It could be that a certain function activates 2 sections of the design while you think one should be enough so you then suspect some suspicious activity is going on. However, the design does some clever trick you do not know about to speed up operations.
Without knowing and understanding the design, any conclusion you draw might still be wrong. Only the engineers who designed the CPU might know everything that goes on.
answered 9 hours ago
BimpelrekkieBimpelrekkie
53.9k251121
$endgroup$
12
$begingroup$
Only the engineers which designed the CPU know everything that goes on - I happen to be an engineer working in this industry and let me assess this statement as being a very optimistic one :)
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
@EugeneSh. :-) You have a point, I'll change that to Only the engineers who designed the CPU might know everything that goes on
$endgroup$
– Bimpelrekkie
9 hours ago
3
$begingroup$
No, the CPU designers would not know everything that goes on - design at that level is dependent on synthesis tools, and those could inject behavior beyond that in the HDL design. To take a non-nefarious example, a lot of FPGA tools will let you compile in a logic analyzer.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
Reverse engineering a chip with "billions of transistors" would present a challenge. spectrum.ieee.org/semiconductors/processors/…
$endgroup$
– laptop2d
6 hours ago
add a comment |
$begingroup$
The only way would be to strip down the chip layer by layer and record every transistor with an electron microscope, and them enter that into some kind of simulation program and then watch it run.
This is essentially the Black Box problem in which you try and reconstruct the internals from measuring inputs and outputs. Once the complexity of the internals, or number of I/O, gets beyond the trivial there is a combinatorial explosion where the number of possible internal states becomes astronomical. Where numbers like Googol get thrown about.
answered 9 hours ago
Dirk BruereDirk Bruere
6,12953266
$endgroup$
1
$begingroup$
...and it is easier to steal the design using social engineering :)
$endgroup$
– Eugene Sh.
9 hours ago
2
$begingroup$
No. The glaring mistake here is that simulation would not be sufficient. Even if you were given an accurate simulation model, you still would not be able to find carefully hidden behavior, because you have no idea how to trigger it.
$endgroup$
– Chris Stratton
7 hours ago
3
$begingroup$
@ChrisStratton I wouldn't call that mistake glaring. It's a reasonable assumption that the design was based on doing simplifications that are physically usual, e.g. that you don't put two metallization traces so close together that they couple inductively sufficiently to change the state of a MOSFET gate. That is only a mistake if a) your simplifications don't match the physical model of what the designer used or b) the designer is intentionally hiding something by intentionally breaking the requirements for these simplifications in non-obvious ways.
$endgroup$
– Marcus Müller
6 hours ago
2
$begingroup$
@ChrisStratton ah, sorry, ok, I think now I'm getting your point. You say that even the digital/behavioural clocked models of a CPU are complex enough to hide cases where the programmer's understanding / assumptions simply do not apply. That's true. One could have documented the effects leading to SPECTRE in excruciating detail, and most people would have never thought of caching to having data- or program flow-relevant side effects. Indeed!
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Thanks :) Your argument brings the whole topic of formal verification of the correctness of ISAs back into view ("does this ISA actually guarantee that a compliant CPU does not grant RING 0 privileges to unprivileged code?") and of formal verification of HDL/RTL against such ISA specifications (I like this RISC-V CPU Core verification project especially.)
$endgroup$
– Marcus Müller
6 hours ago
|
show 3 more comments
$begingroup$
Well, I believe that computer programmers can't do anything about this
problem. But how would an electric engineer attack it?
There are not good ways to find back doors, one way to find a hardware backdoor would be to test combinations or undocumented instructions. Here's a good talk of someone who actually does this and does audits on x86 hardware. This can be done without cracking the chip. One problem with intel (I'm not sure about other chips) is it actually has a processor with linux running on it so there is also software running on some processors, and you don't have access to that supposedly.
Are there techniques an electrical engineer could use to verify that a
circuit actually performs the operations described in its spec, and no
other operations?
There are ways to test to use the hardware itself to test functionality. Since x86 has an undocumented portion of its instruction set, it would be unusual to introduce backdoors in normal instructions because it would introduce the possibility of bugs (like if you had a backdoor in an add or mult instruction), so the first place to look would be in the undocumented instructions.
If you did need to test the functionality of regular instructions you could watch the time it takes to execute instructions, watch the amount of power it takes to run instructions to see if there are differences from what you'd expect.
answered 8 hours ago
laptop2dlaptop2d
30.5k123791
$endgroup$
1
$begingroup$
I would disagree, its not impossible that someone would do this, but unlikely. lets say you backdoored an regular instruction like an add instruction, and if you executed an additional instruction lets say it opened a backdoor. Then a customer develops a program that has exactly that combination, they look into it, find the back door and everyone gets mad and you get sued. Much safer to put a backdoor in the undocumented instructions (or the linux computer built into CPU's)
$endgroup$
– laptop2d
7 hours ago
3
$begingroup$
@user14717 - the nasty possibility would be a trigger sequence in a jailed native executable, something like native client. But there's no reason it has to be code and not data.
$endgroup$
– Chris Stratton
7 hours ago
1
$begingroup$
@laptop2d Bugs where CPUs don't do what the theoretical documentation of the instruction set say happen all the time; nobody gets sued, usually: Read the errata section in the intel 7th gen Core i7 family doc update, for example. Using an undocumented instruction would immediately sound the alarm of any malware researcher. Using an unusual combination of rhythmic ADDs with the right inter-register MOVs is less likely to trigger any alarm.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Point being that the "normally used" x86_64 instruction set is so large already that arbitrary sequences of say 10 instructions are already so incredibly combinatorically unlikely that you can safely use them in a malware program without anyone ever noticing.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
@laptop2d that's why I'd argue that if anyone catches a program that has an illegal instruction actually leading to privilege escalation, that'll be really bad for business, because it's virtually 100% certain that there was malicious intent on the silicon side. "If I read the stack pointer twenty-three times in 100 instructions, with at least one arithmetic instruction between each MOV, followed by a JMP to code that should trigger a system interrupt, but doesn't" might be easier to sell as bug.
$endgroup$
– Marcus Müller
6 hours ago
|
show 7 more comments
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("schematics", function ()
StackExchange.schematics.init();
);
, "cicuitlab");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "135"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
user14717 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f439826%2fis-it-truly-impossible-to-tell-what-a-cpu-is-doing%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
In theory, yes, I think this is possible. However, for a complex CPU it will take a lot of time and money. Also, if you do not fully know and understand the design, you will be unable to judge if any activity is "legit" or not.
A CPU is "just" a complex digital circuit consisting of many logic cells.
It is possible to reverse engineer the chip and reconstruct the design by observing the metal connections. There can be many of these connection layers like up to 8 layers or more.
You will need experts in the field to recognize the logic cells and then maybe some software can figure out how they're all connected so you can reconstruct the netlist.
Once you have the netlist you "know" the design. That doesn't mean you now also know how it works!
It could be that a certain function activates 2 sections of the design while you think one should be enough so you then suspect some suspicious activity is going on. However, the design does some clever trick you do not know about to speed up operations.
Without knowing and understanding the design, any conclusion you draw might still be wrong. Only the engineers who designed the CPU might know everything that goes on.
answered 9 hours ago
BimpelrekkieBimpelrekkie
53.9k251121
$endgroup$
12
$begingroup$
Only the engineers which designed the CPU know everything that goes on - I happen to be an engineer working in this industry and let me assess this statement as being a very optimistic one :)
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
@EugeneSh. :-) You have a point, I'll change that to Only the engineers who designed the CPU might know everything that goes on
$endgroup$
– Bimpelrekkie
9 hours ago
3
$begingroup$
No, the CPU designers would not know everything that goes on - design at that level is dependent on synthesis tools, and those could inject behavior beyond that in the HDL design. To take a non-nefarious example, a lot of FPGA tools will let you compile in a logic analyzer.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
Reverse engineering a chip with "billions of transistors" would present a challenge. spectrum.ieee.org/semiconductors/processors/…
$endgroup$
– laptop2d
6 hours ago
add a comment |
$begingroup$
Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
In theory, yes, I think this is possible. However, for a complex CPU it will take a lot of time and money. Also, if you do not fully know and understand the design, you will be unable to judge if any activity is "legit" or not.
A CPU is "just" a complex digital circuit consisting of many logic cells.
It is possible to reverse engineer the chip and reconstruct the design by observing the metal connections. There can be many of these connection layers like up to 8 layers or more.
You will need experts in the field to recognize the logic cells and then maybe some software can figure out how they're all connected so you can reconstruct the netlist.
Once you have the netlist you "know" the design. That doesn't mean you now also know how it works!
It could be that a certain function activates 2 sections of the design while you think one should be enough so you then suspect some suspicious activity is going on. However, the design does some clever trick you do not know about to speed up operations.
Without knowing and understanding the design, any conclusion you draw might still be wrong. Only the engineers who designed the CPU might know everything that goes on.
answered 9 hours ago
BimpelrekkieBimpelrekkie
53.9k251121
$endgroup$
12
$begingroup$
Only the engineers which designed the CPU know everything that goes on - I happen to be an engineer working in this industry and let me assess this statement as being a very optimistic one :)
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
@EugeneSh. :-) You have a point, I'll change that to Only the engineers who designed the CPU might know everything that goes on
$endgroup$
– Bimpelrekkie
9 hours ago
3
$begingroup$
No, the CPU designers would not know everything that goes on - design at that level is dependent on synthesis tools, and those could inject behavior beyond that in the HDL design. To take a non-nefarious example, a lot of FPGA tools will let you compile in a logic analyzer.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
Reverse engineering a chip with "billions of transistors" would present a challenge. spectrum.ieee.org/semiconductors/processors/…
$endgroup$
– laptop2d
6 hours ago
add a comment |
$begingroup$
Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
In theory, yes, I think this is possible. However, for a complex CPU it will take a lot of time and money. Also, if you do not fully know and understand the design, you will be unable to judge if any activity is "legit" or not.
A CPU is "just" a complex digital circuit consisting of many logic cells.
It is possible to reverse engineer the chip and reconstruct the design by observing the metal connections. There can be many of these connection layers like up to 8 layers or more.
You will need experts in the field to recognize the logic cells and then maybe some software can figure out how they're all connected so you can reconstruct the netlist.
Once you have the netlist you "know" the design. That doesn't mean you now also know how it works!
It could be that a certain function activates 2 sections of the design while you think one should be enough so you then suspect some suspicious activity is going on. However, the design does some clever trick you do not know about to speed up operations.
Without knowing and understanding the design, any conclusion you draw might still be wrong. Only the engineers who designed the CPU might know everything that goes on.
answered 9 hours ago
BimpelrekkieBimpelrekkie
53.9k251121
$endgroup$
Are there techniques an electrical engineer could use to verify that a circuit actually performs the operations described in its spec, and no other operations?
In theory, yes, I think this is possible. However, for a complex CPU it will take a lot of time and money. Also, if you do not fully know and understand the design, you will be unable to judge if any activity is "legit" or not.
A CPU is "just" a complex digital circuit consisting of many logic cells.
It is possible to reverse engineer the chip and reconstruct the design by observing the metal connections. There can be many of these connection layers like up to 8 layers or more.
You will need experts in the field to recognize the logic cells and then maybe some software can figure out how they're all connected so you can reconstruct the netlist.
Once you have the netlist you "know" the design. That doesn't mean you now also know how it works!
It could be that a certain function activates 2 sections of the design while you think one should be enough so you then suspect some suspicious activity is going on. However, the design does some clever trick you do not know about to speed up operations.
Without knowing and understanding the design, any conclusion you draw might still be wrong. Only the engineers who designed the CPU might know everything that goes on.
answered 9 hours ago
BimpelrekkieBimpelrekkie
53.9k251121
edited 9 hours ago
answered 9 hours ago
BimpelrekkieBimpelrekkie
53.9k251121
answered 9 hours ago
BimpelrekkieBimpelrekkie
53.9k251121
answered 9 hours ago
BimpelrekkieBimpelrekkie
53.9k251121
53.9k251121
12
$begingroup$
Only the engineers which designed the CPU know everything that goes on - I happen to be an engineer working in this industry and let me assess this statement as being a very optimistic one :)
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
@EugeneSh. :-) You have a point, I'll change that to Only the engineers who designed the CPU might know everything that goes on
$endgroup$
– Bimpelrekkie
9 hours ago
3
$begingroup$
No, the CPU designers would not know everything that goes on - design at that level is dependent on synthesis tools, and those could inject behavior beyond that in the HDL design. To take a non-nefarious example, a lot of FPGA tools will let you compile in a logic analyzer.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
Reverse engineering a chip with "billions of transistors" would present a challenge. spectrum.ieee.org/semiconductors/processors/…
$endgroup$
– laptop2d
6 hours ago
add a comment |
12
$begingroup$
Only the engineers which designed the CPU know everything that goes on - I happen to be an engineer working in this industry and let me assess this statement as being a very optimistic one :)
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
@EugeneSh. :-) You have a point, I'll change that to Only the engineers who designed the CPU might know everything that goes on
$endgroup$
– Bimpelrekkie
9 hours ago
3
$begingroup$
No, the CPU designers would not know everything that goes on - design at that level is dependent on synthesis tools, and those could inject behavior beyond that in the HDL design. To take a non-nefarious example, a lot of FPGA tools will let you compile in a logic analyzer.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
Reverse engineering a chip with "billions of transistors" would present a challenge. spectrum.ieee.org/semiconductors/processors/…
$endgroup$
– laptop2d
6 hours ago
12
12
$begingroup$
Only the engineers which designed the CPU know everything that goes on - I happen to be an engineer working in this industry and let me assess this statement as being a very optimistic one :)
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
Only the engineers which designed the CPU know everything that goes on - I happen to be an engineer working in this industry and let me assess this statement as being a very optimistic one :)
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
@EugeneSh. :-) You have a point, I'll change that to Only the engineers who designed the CPU might know everything that goes on
$endgroup$
– Bimpelrekkie
9 hours ago
$begingroup$
@EugeneSh. :-) You have a point, I'll change that to Only the engineers who designed the CPU might know everything that goes on
$endgroup$
– Bimpelrekkie
9 hours ago
3
3
$begingroup$
No, the CPU designers would not know everything that goes on - design at that level is dependent on synthesis tools, and those could inject behavior beyond that in the HDL design. To take a non-nefarious example, a lot of FPGA tools will let you compile in a logic analyzer.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
No, the CPU designers would not know everything that goes on - design at that level is dependent on synthesis tools, and those could inject behavior beyond that in the HDL design. To take a non-nefarious example, a lot of FPGA tools will let you compile in a logic analyzer.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
Reverse engineering a chip with "billions of transistors" would present a challenge. spectrum.ieee.org/semiconductors/processors/…
$endgroup$
– laptop2d
6 hours ago
$begingroup$
Reverse engineering a chip with "billions of transistors" would present a challenge. spectrum.ieee.org/semiconductors/processors/…
$endgroup$
– laptop2d
6 hours ago
add a comment |
$begingroup$
The only way would be to strip down the chip layer by layer and record every transistor with an electron microscope, and them enter that into some kind of simulation program and then watch it run.
This is essentially the Black Box problem in which you try and reconstruct the internals from measuring inputs and outputs. Once the complexity of the internals, or number of I/O, gets beyond the trivial there is a combinatorial explosion where the number of possible internal states becomes astronomical. Where numbers like Googol get thrown about.
answered 9 hours ago
Dirk BruereDirk Bruere
6,12953266
$endgroup$
1
$begingroup$
...and it is easier to steal the design using social engineering :)
$endgroup$
– Eugene Sh.
9 hours ago
2
$begingroup$
No. The glaring mistake here is that simulation would not be sufficient. Even if you were given an accurate simulation model, you still would not be able to find carefully hidden behavior, because you have no idea how to trigger it.
$endgroup$
– Chris Stratton
7 hours ago
3
$begingroup$
@ChrisStratton I wouldn't call that mistake glaring. It's a reasonable assumption that the design was based on doing simplifications that are physically usual, e.g. that you don't put two metallization traces so close together that they couple inductively sufficiently to change the state of a MOSFET gate. That is only a mistake if a) your simplifications don't match the physical model of what the designer used or b) the designer is intentionally hiding something by intentionally breaking the requirements for these simplifications in non-obvious ways.
$endgroup$
– Marcus Müller
6 hours ago
2
$begingroup$
@ChrisStratton ah, sorry, ok, I think now I'm getting your point. You say that even the digital/behavioural clocked models of a CPU are complex enough to hide cases where the programmer's understanding / assumptions simply do not apply. That's true. One could have documented the effects leading to SPECTRE in excruciating detail, and most people would have never thought of caching to having data- or program flow-relevant side effects. Indeed!
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Thanks :) Your argument brings the whole topic of formal verification of the correctness of ISAs back into view ("does this ISA actually guarantee that a compliant CPU does not grant RING 0 privileges to unprivileged code?") and of formal verification of HDL/RTL against such ISA specifications (I like this RISC-V CPU Core verification project especially.)
$endgroup$
– Marcus Müller
6 hours ago
|
show 3 more comments
$begingroup$
The only way would be to strip down the chip layer by layer and record every transistor with an electron microscope, and them enter that into some kind of simulation program and then watch it run.
This is essentially the Black Box problem in which you try and reconstruct the internals from measuring inputs and outputs. Once the complexity of the internals, or number of I/O, gets beyond the trivial there is a combinatorial explosion where the number of possible internal states becomes astronomical. Where numbers like Googol get thrown about.
answered 9 hours ago
Dirk BruereDirk Bruere
6,12953266
$endgroup$
1
$begingroup$
...and it is easier to steal the design using social engineering :)
$endgroup$
– Eugene Sh.
9 hours ago
2
$begingroup$
No. The glaring mistake here is that simulation would not be sufficient. Even if you were given an accurate simulation model, you still would not be able to find carefully hidden behavior, because you have no idea how to trigger it.
$endgroup$
– Chris Stratton
7 hours ago
3
$begingroup$
@ChrisStratton I wouldn't call that mistake glaring. It's a reasonable assumption that the design was based on doing simplifications that are physically usual, e.g. that you don't put two metallization traces so close together that they couple inductively sufficiently to change the state of a MOSFET gate. That is only a mistake if a) your simplifications don't match the physical model of what the designer used or b) the designer is intentionally hiding something by intentionally breaking the requirements for these simplifications in non-obvious ways.
$endgroup$
– Marcus Müller
6 hours ago
2
$begingroup$
@ChrisStratton ah, sorry, ok, I think now I'm getting your point. You say that even the digital/behavioural clocked models of a CPU are complex enough to hide cases where the programmer's understanding / assumptions simply do not apply. That's true. One could have documented the effects leading to SPECTRE in excruciating detail, and most people would have never thought of caching to having data- or program flow-relevant side effects. Indeed!
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Thanks :) Your argument brings the whole topic of formal verification of the correctness of ISAs back into view ("does this ISA actually guarantee that a compliant CPU does not grant RING 0 privileges to unprivileged code?") and of formal verification of HDL/RTL against such ISA specifications (I like this RISC-V CPU Core verification project especially.)
$endgroup$
– Marcus Müller
6 hours ago
|
show 3 more comments
$begingroup$
The only way would be to strip down the chip layer by layer and record every transistor with an electron microscope, and them enter that into some kind of simulation program and then watch it run.
This is essentially the Black Box problem in which you try and reconstruct the internals from measuring inputs and outputs. Once the complexity of the internals, or number of I/O, gets beyond the trivial there is a combinatorial explosion where the number of possible internal states becomes astronomical. Where numbers like Googol get thrown about.
answered 9 hours ago
Dirk BruereDirk Bruere
6,12953266
$endgroup$
The only way would be to strip down the chip layer by layer and record every transistor with an electron microscope, and them enter that into some kind of simulation program and then watch it run.
This is essentially the Black Box problem in which you try and reconstruct the internals from measuring inputs and outputs. Once the complexity of the internals, or number of I/O, gets beyond the trivial there is a combinatorial explosion where the number of possible internal states becomes astronomical. Where numbers like Googol get thrown about.
answered 9 hours ago
Dirk BruereDirk Bruere
6,12953266
answered 9 hours ago
Dirk BruereDirk Bruere
6,12953266
answered 9 hours ago
Dirk BruereDirk Bruere
6,12953266
answered 9 hours ago
Dirk BruereDirk Bruere
6,12953266
6,12953266
1
$begingroup$
...and it is easier to steal the design using social engineering :)
$endgroup$
– Eugene Sh.
9 hours ago
2
$begingroup$
No. The glaring mistake here is that simulation would not be sufficient. Even if you were given an accurate simulation model, you still would not be able to find carefully hidden behavior, because you have no idea how to trigger it.
$endgroup$
– Chris Stratton
7 hours ago
3
$begingroup$
@ChrisStratton I wouldn't call that mistake glaring. It's a reasonable assumption that the design was based on doing simplifications that are physically usual, e.g. that you don't put two metallization traces so close together that they couple inductively sufficiently to change the state of a MOSFET gate. That is only a mistake if a) your simplifications don't match the physical model of what the designer used or b) the designer is intentionally hiding something by intentionally breaking the requirements for these simplifications in non-obvious ways.
$endgroup$
– Marcus Müller
6 hours ago
2
$begingroup$
@ChrisStratton ah, sorry, ok, I think now I'm getting your point. You say that even the digital/behavioural clocked models of a CPU are complex enough to hide cases where the programmer's understanding / assumptions simply do not apply. That's true. One could have documented the effects leading to SPECTRE in excruciating detail, and most people would have never thought of caching to having data- or program flow-relevant side effects. Indeed!
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Thanks :) Your argument brings the whole topic of formal verification of the correctness of ISAs back into view ("does this ISA actually guarantee that a compliant CPU does not grant RING 0 privileges to unprivileged code?") and of formal verification of HDL/RTL against such ISA specifications (I like this RISC-V CPU Core verification project especially.)
$endgroup$
– Marcus Müller
6 hours ago
|
show 3 more comments
1
$begingroup$
...and it is easier to steal the design using social engineering :)
$endgroup$
– Eugene Sh.
9 hours ago
2
$begingroup$
No. The glaring mistake here is that simulation would not be sufficient. Even if you were given an accurate simulation model, you still would not be able to find carefully hidden behavior, because you have no idea how to trigger it.
$endgroup$
– Chris Stratton
7 hours ago
3
$begingroup$
@ChrisStratton I wouldn't call that mistake glaring. It's a reasonable assumption that the design was based on doing simplifications that are physically usual, e.g. that you don't put two metallization traces so close together that they couple inductively sufficiently to change the state of a MOSFET gate. That is only a mistake if a) your simplifications don't match the physical model of what the designer used or b) the designer is intentionally hiding something by intentionally breaking the requirements for these simplifications in non-obvious ways.
$endgroup$
– Marcus Müller
6 hours ago
2
$begingroup$
@ChrisStratton ah, sorry, ok, I think now I'm getting your point. You say that even the digital/behavioural clocked models of a CPU are complex enough to hide cases where the programmer's understanding / assumptions simply do not apply. That's true. One could have documented the effects leading to SPECTRE in excruciating detail, and most people would have never thought of caching to having data- or program flow-relevant side effects. Indeed!
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Thanks :) Your argument brings the whole topic of formal verification of the correctness of ISAs back into view ("does this ISA actually guarantee that a compliant CPU does not grant RING 0 privileges to unprivileged code?") and of formal verification of HDL/RTL against such ISA specifications (I like this RISC-V CPU Core verification project especially.)
$endgroup$
– Marcus Müller
6 hours ago
1
1
$begingroup$
...and it is easier to steal the design using social engineering :)
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
...and it is easier to steal the design using social engineering :)
$endgroup$
– Eugene Sh.
9 hours ago
2
2
$begingroup$
No. The glaring mistake here is that simulation would not be sufficient. Even if you were given an accurate simulation model, you still would not be able to find carefully hidden behavior, because you have no idea how to trigger it.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
No. The glaring mistake here is that simulation would not be sufficient. Even if you were given an accurate simulation model, you still would not be able to find carefully hidden behavior, because you have no idea how to trigger it.
$endgroup$
– Chris Stratton
7 hours ago
3
3
$begingroup$
@ChrisStratton I wouldn't call that mistake glaring. It's a reasonable assumption that the design was based on doing simplifications that are physically usual, e.g. that you don't put two metallization traces so close together that they couple inductively sufficiently to change the state of a MOSFET gate. That is only a mistake if a) your simplifications don't match the physical model of what the designer used or b) the designer is intentionally hiding something by intentionally breaking the requirements for these simplifications in non-obvious ways.
$endgroup$
– Marcus Müller
6 hours ago
$begingroup$
@ChrisStratton I wouldn't call that mistake glaring. It's a reasonable assumption that the design was based on doing simplifications that are physically usual, e.g. that you don't put two metallization traces so close together that they couple inductively sufficiently to change the state of a MOSFET gate. That is only a mistake if a) your simplifications don't match the physical model of what the designer used or b) the designer is intentionally hiding something by intentionally breaking the requirements for these simplifications in non-obvious ways.
$endgroup$
– Marcus Müller
6 hours ago
2
2
$begingroup$
@ChrisStratton ah, sorry, ok, I think now I'm getting your point. You say that even the digital/behavioural clocked models of a CPU are complex enough to hide cases where the programmer's understanding / assumptions simply do not apply. That's true. One could have documented the effects leading to SPECTRE in excruciating detail, and most people would have never thought of caching to having data- or program flow-relevant side effects. Indeed!
$endgroup$
– Marcus Müller
6 hours ago
$begingroup$
@ChrisStratton ah, sorry, ok, I think now I'm getting your point. You say that even the digital/behavioural clocked models of a CPU are complex enough to hide cases where the programmer's understanding / assumptions simply do not apply. That's true. One could have documented the effects leading to SPECTRE in excruciating detail, and most people would have never thought of caching to having data- or program flow-relevant side effects. Indeed!
$endgroup$
– Marcus Müller
6 hours ago
1
1
$begingroup$
Thanks :) Your argument brings the whole topic of formal verification of the correctness of ISAs back into view ("does this ISA actually guarantee that a compliant CPU does not grant RING 0 privileges to unprivileged code?") and of formal verification of HDL/RTL against such ISA specifications (I like this RISC-V CPU Core verification project especially.)
$endgroup$
– Marcus Müller
6 hours ago
$begingroup$
Thanks :) Your argument brings the whole topic of formal verification of the correctness of ISAs back into view ("does this ISA actually guarantee that a compliant CPU does not grant RING 0 privileges to unprivileged code?") and of formal verification of HDL/RTL against such ISA specifications (I like this RISC-V CPU Core verification project especially.)
$endgroup$
– Marcus Müller
6 hours ago
|
show 3 more comments
$begingroup$
Well, I believe that computer programmers can't do anything about this
problem. But how would an electric engineer attack it?
There are not good ways to find back doors, one way to find a hardware backdoor would be to test combinations or undocumented instructions. Here's a good talk of someone who actually does this and does audits on x86 hardware. This can be done without cracking the chip. One problem with intel (I'm not sure about other chips) is it actually has a processor with linux running on it so there is also software running on some processors, and you don't have access to that supposedly.
Are there techniques an electrical engineer could use to verify that a
circuit actually performs the operations described in its spec, and no
other operations?
There are ways to test to use the hardware itself to test functionality. Since x86 has an undocumented portion of its instruction set, it would be unusual to introduce backdoors in normal instructions because it would introduce the possibility of bugs (like if you had a backdoor in an add or mult instruction), so the first place to look would be in the undocumented instructions.
If you did need to test the functionality of regular instructions you could watch the time it takes to execute instructions, watch the amount of power it takes to run instructions to see if there are differences from what you'd expect.
answered 8 hours ago
laptop2dlaptop2d
30.5k123791
$endgroup$
1
$begingroup$
I would disagree, its not impossible that someone would do this, but unlikely. lets say you backdoored an regular instruction like an add instruction, and if you executed an additional instruction lets say it opened a backdoor. Then a customer develops a program that has exactly that combination, they look into it, find the back door and everyone gets mad and you get sued. Much safer to put a backdoor in the undocumented instructions (or the linux computer built into CPU's)
$endgroup$
– laptop2d
7 hours ago
3
$begingroup$
@user14717 - the nasty possibility would be a trigger sequence in a jailed native executable, something like native client. But there's no reason it has to be code and not data.
$endgroup$
– Chris Stratton
7 hours ago
1
$begingroup$
@laptop2d Bugs where CPUs don't do what the theoretical documentation of the instruction set say happen all the time; nobody gets sued, usually: Read the errata section in the intel 7th gen Core i7 family doc update, for example. Using an undocumented instruction would immediately sound the alarm of any malware researcher. Using an unusual combination of rhythmic ADDs with the right inter-register MOVs is less likely to trigger any alarm.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Point being that the "normally used" x86_64 instruction set is so large already that arbitrary sequences of say 10 instructions are already so incredibly combinatorically unlikely that you can safely use them in a malware program without anyone ever noticing.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
@laptop2d that's why I'd argue that if anyone catches a program that has an illegal instruction actually leading to privilege escalation, that'll be really bad for business, because it's virtually 100% certain that there was malicious intent on the silicon side. "If I read the stack pointer twenty-three times in 100 instructions, with at least one arithmetic instruction between each MOV, followed by a JMP to code that should trigger a system interrupt, but doesn't" might be easier to sell as bug.
$endgroup$
– Marcus Müller
6 hours ago
|
show 7 more comments
$begingroup$
Well, I believe that computer programmers can't do anything about this
problem. But how would an electric engineer attack it?
There are not good ways to find back doors, one way to find a hardware backdoor would be to test combinations or undocumented instructions. Here's a good talk of someone who actually does this and does audits on x86 hardware. This can be done without cracking the chip. One problem with intel (I'm not sure about other chips) is it actually has a processor with linux running on it so there is also software running on some processors, and you don't have access to that supposedly.
Are there techniques an electrical engineer could use to verify that a
circuit actually performs the operations described in its spec, and no
other operations?
There are ways to test to use the hardware itself to test functionality. Since x86 has an undocumented portion of its instruction set, it would be unusual to introduce backdoors in normal instructions because it would introduce the possibility of bugs (like if you had a backdoor in an add or mult instruction), so the first place to look would be in the undocumented instructions.
If you did need to test the functionality of regular instructions you could watch the time it takes to execute instructions, watch the amount of power it takes to run instructions to see if there are differences from what you'd expect.
answered 8 hours ago
laptop2dlaptop2d
30.5k123791
$endgroup$
1
$begingroup$
I would disagree, its not impossible that someone would do this, but unlikely. lets say you backdoored an regular instruction like an add instruction, and if you executed an additional instruction lets say it opened a backdoor. Then a customer develops a program that has exactly that combination, they look into it, find the back door and everyone gets mad and you get sued. Much safer to put a backdoor in the undocumented instructions (or the linux computer built into CPU's)
$endgroup$
– laptop2d
7 hours ago
3
$begingroup$
@user14717 - the nasty possibility would be a trigger sequence in a jailed native executable, something like native client. But there's no reason it has to be code and not data.
$endgroup$
– Chris Stratton
7 hours ago
1
$begingroup$
@laptop2d Bugs where CPUs don't do what the theoretical documentation of the instruction set say happen all the time; nobody gets sued, usually: Read the errata section in the intel 7th gen Core i7 family doc update, for example. Using an undocumented instruction would immediately sound the alarm of any malware researcher. Using an unusual combination of rhythmic ADDs with the right inter-register MOVs is less likely to trigger any alarm.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Point being that the "normally used" x86_64 instruction set is so large already that arbitrary sequences of say 10 instructions are already so incredibly combinatorically unlikely that you can safely use them in a malware program without anyone ever noticing.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
@laptop2d that's why I'd argue that if anyone catches a program that has an illegal instruction actually leading to privilege escalation, that'll be really bad for business, because it's virtually 100% certain that there was malicious intent on the silicon side. "If I read the stack pointer twenty-three times in 100 instructions, with at least one arithmetic instruction between each MOV, followed by a JMP to code that should trigger a system interrupt, but doesn't" might be easier to sell as bug.
$endgroup$
– Marcus Müller
6 hours ago
|
show 7 more comments
$begingroup$
Well, I believe that computer programmers can't do anything about this
problem. But how would an electric engineer attack it?
There are not good ways to find back doors, one way to find a hardware backdoor would be to test combinations or undocumented instructions. Here's a good talk of someone who actually does this and does audits on x86 hardware. This can be done without cracking the chip. One problem with intel (I'm not sure about other chips) is it actually has a processor with linux running on it so there is also software running on some processors, and you don't have access to that supposedly.
Are there techniques an electrical engineer could use to verify that a
circuit actually performs the operations described in its spec, and no
other operations?
There are ways to test to use the hardware itself to test functionality. Since x86 has an undocumented portion of its instruction set, it would be unusual to introduce backdoors in normal instructions because it would introduce the possibility of bugs (like if you had a backdoor in an add or mult instruction), so the first place to look would be in the undocumented instructions.
If you did need to test the functionality of regular instructions you could watch the time it takes to execute instructions, watch the amount of power it takes to run instructions to see if there are differences from what you'd expect.
answered 8 hours ago
laptop2dlaptop2d
30.5k123791
$endgroup$
Well, I believe that computer programmers can't do anything about this
problem. But how would an electric engineer attack it?
There are not good ways to find back doors, one way to find a hardware backdoor would be to test combinations or undocumented instructions. Here's a good talk of someone who actually does this and does audits on x86 hardware. This can be done without cracking the chip. One problem with intel (I'm not sure about other chips) is it actually has a processor with linux running on it so there is also software running on some processors, and you don't have access to that supposedly.
Are there techniques an electrical engineer could use to verify that a
circuit actually performs the operations described in its spec, and no
other operations?
There are ways to test to use the hardware itself to test functionality. Since x86 has an undocumented portion of its instruction set, it would be unusual to introduce backdoors in normal instructions because it would introduce the possibility of bugs (like if you had a backdoor in an add or mult instruction), so the first place to look would be in the undocumented instructions.
If you did need to test the functionality of regular instructions you could watch the time it takes to execute instructions, watch the amount of power it takes to run instructions to see if there are differences from what you'd expect.
answered 8 hours ago
laptop2dlaptop2d
30.5k123791
answered 8 hours ago
laptop2dlaptop2d
30.5k123791
answered 8 hours ago
laptop2dlaptop2d
30.5k123791
answered 8 hours ago
laptop2dlaptop2d
30.5k123791
30.5k123791
1
$begingroup$
I would disagree, its not impossible that someone would do this, but unlikely. lets say you backdoored an regular instruction like an add instruction, and if you executed an additional instruction lets say it opened a backdoor. Then a customer develops a program that has exactly that combination, they look into it, find the back door and everyone gets mad and you get sued. Much safer to put a backdoor in the undocumented instructions (or the linux computer built into CPU's)
$endgroup$
– laptop2d
7 hours ago
3
$begingroup$
@user14717 - the nasty possibility would be a trigger sequence in a jailed native executable, something like native client. But there's no reason it has to be code and not data.
$endgroup$
– Chris Stratton
7 hours ago
1
$begingroup$
@laptop2d Bugs where CPUs don't do what the theoretical documentation of the instruction set say happen all the time; nobody gets sued, usually: Read the errata section in the intel 7th gen Core i7 family doc update, for example. Using an undocumented instruction would immediately sound the alarm of any malware researcher. Using an unusual combination of rhythmic ADDs with the right inter-register MOVs is less likely to trigger any alarm.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Point being that the "normally used" x86_64 instruction set is so large already that arbitrary sequences of say 10 instructions are already so incredibly combinatorically unlikely that you can safely use them in a malware program without anyone ever noticing.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
@laptop2d that's why I'd argue that if anyone catches a program that has an illegal instruction actually leading to privilege escalation, that'll be really bad for business, because it's virtually 100% certain that there was malicious intent on the silicon side. "If I read the stack pointer twenty-three times in 100 instructions, with at least one arithmetic instruction between each MOV, followed by a JMP to code that should trigger a system interrupt, but doesn't" might be easier to sell as bug.
$endgroup$
– Marcus Müller
6 hours ago
|
show 7 more comments
1
$begingroup$
I would disagree, its not impossible that someone would do this, but unlikely. lets say you backdoored an regular instruction like an add instruction, and if you executed an additional instruction lets say it opened a backdoor. Then a customer develops a program that has exactly that combination, they look into it, find the back door and everyone gets mad and you get sued. Much safer to put a backdoor in the undocumented instructions (or the linux computer built into CPU's)
$endgroup$
– laptop2d
7 hours ago
3
$begingroup$
@user14717 - the nasty possibility would be a trigger sequence in a jailed native executable, something like native client. But there's no reason it has to be code and not data.
$endgroup$
– Chris Stratton
7 hours ago
1
$begingroup$
@laptop2d Bugs where CPUs don't do what the theoretical documentation of the instruction set say happen all the time; nobody gets sued, usually: Read the errata section in the intel 7th gen Core i7 family doc update, for example. Using an undocumented instruction would immediately sound the alarm of any malware researcher. Using an unusual combination of rhythmic ADDs with the right inter-register MOVs is less likely to trigger any alarm.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
Point being that the "normally used" x86_64 instruction set is so large already that arbitrary sequences of say 10 instructions are already so incredibly combinatorically unlikely that you can safely use them in a malware program without anyone ever noticing.
$endgroup$
– Marcus Müller
6 hours ago
1
$begingroup$
@laptop2d that's why I'd argue that if anyone catches a program that has an illegal instruction actually leading to privilege escalation, that'll be really bad for business, because it's virtually 100% certain that there was malicious intent on the silicon side. "If I read the stack pointer twenty-three times in 100 instructions, with at least one arithmetic instruction between each MOV, followed by a JMP to code that should trigger a system interrupt, but doesn't" might be easier to sell as bug.
$endgroup$
– Marcus Müller
6 hours ago
1
1
$begingroup$
I would disagree, its not impossible that someone would do this, but unlikely. lets say you backdoored an regular instruction like an add instruction, and if you executed an additional instruction lets say it opened a backdoor. Then a customer develops a program that has exactly that combination, they look into it, find the back door and everyone gets mad and you get sued. Much safer to put a backdoor in the undocumented instructions (or the linux computer built into CPU's)
$endgroup$
– laptop2d
7 hours ago
$begingroup$
I would disagree, its not impossible that someone would do this, but unlikely. lets say you backdoored an regular instruction like an add instruction, and if you executed an additional instruction lets say it opened a backdoor. Then a customer develops a program that has exactly that combination, they look into it, find the back door and everyone gets mad and you get sued. Much safer to put a backdoor in the undocumented instructions (or the linux computer built into CPU's)
$endgroup$
– laptop2d
7 hours ago
3
3
$begingroup$
@user14717 - the nasty possibility would be a trigger sequence in a jailed native executable, something like native client. But there's no reason it has to be code and not data.
$endgroup$
– Chris Stratton
7 hours ago
$begingroup$
@user14717 - the nasty possibility would be a trigger sequence in a jailed native executable, something like native client. But there's no reason it has to be code and not data.
$endgroup$
– Chris Stratton
7 hours ago
1
1
$begingroup$
@laptop2d Bugs where CPUs don't do what the theoretical documentation of the instruction set say happen all the time; nobody gets sued, usually: Read the errata section in the intel 7th gen Core i7 family doc update, for example. Using an undocumented instruction would immediately sound the alarm of any malware researcher. Using an unusual combination of rhythmic ADDs with the right inter-register MOVs is less likely to trigger any alarm.
$endgroup$
– Marcus Müller
6 hours ago
$begingroup$
@laptop2d Bugs where CPUs don't do what the theoretical documentation of the instruction set say happen all the time; nobody gets sued, usually: Read the errata section in the intel 7th gen Core i7 family doc update, for example. Using an undocumented instruction would immediately sound the alarm of any malware researcher. Using an unusual combination of rhythmic ADDs with the right inter-register MOVs is less likely to trigger any alarm.
$endgroup$
– Marcus Müller
6 hours ago
1
1
$begingroup$
Point being that the "normally used" x86_64 instruction set is so large already that arbitrary sequences of say 10 instructions are already so incredibly combinatorically unlikely that you can safely use them in a malware program without anyone ever noticing.
$endgroup$
– Marcus Müller
6 hours ago
$begingroup$
Point being that the "normally used" x86_64 instruction set is so large already that arbitrary sequences of say 10 instructions are already so incredibly combinatorically unlikely that you can safely use them in a malware program without anyone ever noticing.
$endgroup$
– Marcus Müller
6 hours ago
1
1
$begingroup$
@laptop2d that's why I'd argue that if anyone catches a program that has an illegal instruction actually leading to privilege escalation, that'll be really bad for business, because it's virtually 100% certain that there was malicious intent on the silicon side. "If I read the stack pointer twenty-three times in 100 instructions, with at least one arithmetic instruction between each MOV, followed by a JMP to code that should trigger a system interrupt, but doesn't" might be easier to sell as bug.
$endgroup$
– Marcus Müller
6 hours ago
$begingroup$
@laptop2d that's why I'd argue that if anyone catches a program that has an illegal instruction actually leading to privilege escalation, that'll be really bad for business, because it's virtually 100% certain that there was malicious intent on the silicon side. "If I read the stack pointer twenty-three times in 100 instructions, with at least one arithmetic instruction between each MOV, followed by a JMP to code that should trigger a system interrupt, but doesn't" might be easier to sell as bug.
$endgroup$
– Marcus Müller
6 hours ago
|
show 7 more comments
user14717 is a new contributor. Be nice, and check out our Code of Conduct.
user14717 is a new contributor. Be nice, and check out our Code of Conduct.
user14717 is a new contributor. Be nice, and check out our Code of Conduct.
user14717 is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f439826%2fis-it-truly-impossible-to-tell-what-a-cpu-is-doing%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
$begingroup$
You'd have to do something like xray the die and analyze everything to see what it's actually doing. Basically reverse engineer the chip and account for trhe function of every circuit. Totally impractical.
$endgroup$
– Toor
9 hours ago
1
$begingroup$
No electrical circuit performs to an exact spec because of noise and the slight possibility that one day there will be a glitch that is "big enough".
$endgroup$
– Andy aka
9 hours ago
$begingroup$
There are techniques and tools to reverse chips - xray as said, microscopes and such. Modern microprocessors are extremely complex beasts, so such a work will be extremely difficult, but possible..
$endgroup$
– Eugene Sh.
9 hours ago
$begingroup$
This is very much like trying to reconstruct the Windows source code from its kernel image. Possible in theory, true, but way too much effort...
$endgroup$
– michi7x7
8 hours ago
$begingroup$
Fun info: This is vaguely related to Laplace's demon.
$endgroup$
– Harry Svensson
8 hours ago