<code>(lock REX_X? 0x83 (opcode_4 any* & operand_sib_pure_index @check_access) imm8 @process_0_operand) |</code><br />
<code>(lock REX_XB? 0x83 (opcode_4 any* & operand_sib_base_index @check_access) imm8 @process_0_operand) |</code><br />
<code>(REX_B? 0x83 (opcode_4 @operand0_32bit any* & modrm_registers @operand0_from_modrm_rm) imm8 @process_1_operand) |</code><hr />
-As you can see <code>check_access</code> is triggered after parsing ModRM/SIB bytes, but before parsing <code>imm<i>NN</i></code> field while <code>process_<i>N</i>_operands</code> action is triggered at the very end of the “normal” instruction. Even if the instruction does not use the <code>imm<i>NN</i></code> field, the <code>check_access</code> action is <b>still</b> triggered before the <code>process_<i>N</i>_operands</code> action. This is important because the <code>check_access</code> action actually depends on the <b>previous</b> state of <code>restricted_register</code> variable while <code>process_<i>N</i>_operands</code> action changes the <code>restricted_register</code> variable. Note that it's only triggered for “normal” instructions—“special” instructions either do the work themselves (e.g. <code>add %r15,%rsp</code>—which is only valid if the previous state of the <code>restricted_register</code> variable was <code>REG_RSP</code> and changes it to <code>NO_REG</code> in case of success) or call the usual <code>process_<i>N</i>_operands</code> action (e.g. <code>mov %rsp,%rbp</code> calls <code>process_0_operands</code> which ensures that this operation is not called when <code>restricted_register</code> is set to <code>REG_RSP</code>/<code>REG_RBP</code> state and transitions it to <code>NO_REG</code> state).</p>
+As you can see <code>check_access</code> is triggered after parsing ModRM/SIB bytes, but before parsing <code>imm<i>NN</i></code> field while <code>process_<i>N</i>_operands</code> action is triggered at the very end of the “normal” instruction. Even if the instruction does not use the <code>imm<i>NN</i></code> field, the <code>check_access</code> action is <b>still</b> triggered before the <code>process_<i>N</i>_operands</code> action. This is important because the <code>check_access</code> action actually depends on the <b>previous</b> state of <code>restricted_register</code> variable while <code>process_<i>N</i>_operands</code> action changes the <code>restricted_register</code> variable. Note that it's only triggered for “normal” instructions—“special” instructions either do the work themselves (e.g. <code>add %r15,%rsp</code>—which is only valid if the previous state of the <code>restricted_register</code> variable was <code>NC_REG_RSP</code> and changes it to <code>NC_NO_REG</code> in case of success) or call the usual <code>process_<i>N</i>_operands</code> action (e.g. <code>mov %rsp,%rbp</code> calls <code>process_0_operands</code> which ensures that this operation is not called when <code>restricted_register</code> is set to <code>NC_REG_RSP</code>/<code>NC_REG_RBP</code> state and transitions it to <code>NC_NO_REG</code> state).</p>
<p>You can find yet another surprising thing in the snippet above: <code>and</code> instruction is handled either as instruction with zero operands or as instruction with one operand… but of course in reality it always has two operands! Something is strange here… Well, sure: the decoder part of the validator is as streamlined as possible. We just ignore all non-register arguments and arguments which are not written to (but we <b>don't</b> ignore memory accesses if they happen here, of course). That's why <code>and</code> has either one or zero operands as far as the validator is concerned.</p>
<tr><td colspan="2" style="border: thin solid black;" width="100%" align="center">padding</td><td colspan="2" style="border: thin solid black;" align="center">operand4:<br />register_type</td><td colspan="2" style="border: thin solid black;" align="center">operand4:<br />register_name</td><td style="border: thin solid black;" align="center">padding</td><td colspan="2" style="border: thin solid black;" align="center">operand3:<br />register_type</td><td colspan="2" style="border: thin solid black;" align="center">operand3:<br />register_name</td><td style="border: thin solid black;" align="center">padding</td><td colspan="2" style="border: thin solid black;" align="center">operand2:<br />register_type</td><td colspan="2" style="border: thin solid black;" align="center">operand2:<br />register_name</td><td style="border: thin solid black;">padding</td><td colspan="2" style="border: thin solid black;" align="center">operand1:<br />register_type</td><td colspan="2" style="border: thin solid black;" align="center">operand1:<br />register_name</td><td style="border: thin solid black;" align="center">padding</td><td colspan="2" style="border: thin solid black;" align="center">operand0:<br />register_type</td><td colspan="2" style="border: thin solid black;" align="center">operand0:<br />register_name</td></tr>
<tr><td></td><td></td><td></td><td></td><td colspan="2"> ↖<br /> 0 if normal<br /> register</td><td></td><td></td><td></td><td colspan="2"> ↖<br /> 0 if normal<br /> register</td><td></td><td></td><td></td><td colspan="2"> ↖<br /> 0 if normal<br /> register</td><td></td><td></td><td></td><td colspan="2"> ↖<br /> 0 if normal<br /> register</td><td></td><td></td><td></td><td colspan="2"> ↖<br /> 0 if normal<br /> register</td></tr></table>
-<p>Register names are defined in the <code>register_name</code> enum: the first 16 are identical to the AMD/Intel names (from <code>REG_RAX</code> to <code>REG_R15</code>) while the other 16 are used (partially) to describe non-register operands (memory operand, immediate operand, <code>REG_RIP</code> and <code>REG_RIZ</code>, etc). This means that if the operand's name is >15 then it can be ignored. There are only four operand types: <code>OperandSandboxIrrelevant</code>, <code>OperandSandbox8bit</code>, <code>OperandSandboxRestricted</code>, and <code>OperandSandboxUnrestricted</code>. The first type is something not related to a general purpose register (x87, MMX, XMM, or YMM registers fall unto this category). We need to handle 8bit operands specially because they are finicky: if <code>REX</code> byte is used they access <code>%spl</code>, <code>%bps</code>, <code>%sil</code>, and <code>%dil</code>, but when <code>REX</code> byte is not used the same numbers are reused for <code>%ah</code>, <code>%ch</code>, <code>%dh</code>, and <code>%bh</code>! The last two types are the most important: these are 32bit operands (which will make the appropriate register “restricted”) or 16bit/64bit operands (these may affect the register in question negatively if it's <code>%rbp</code>, <code>%rsp</code>, or <code>%r15</code>, but for other registers these are just ignored). Note that if you assign <code>0</code> to this variable then all operands will be of <code>OperandSandboxIrrelevant</code> type.</p>
+<p>Register names are defined in the <code>register_name</code> enum: the first 16 are identical to the AMD/Intel names (from <code>NC_REG_RAX</code> to <code>NC_REG_R15</code>) while the other 16 are used (partially) to describe non-register operands (memory operand, immediate operand, <code>NC_REG_RIP</code> and <code>NC_REG_RIZ</code>, etc). This means that if the operand's name is >15 then it can be ignored. There are only four operand types: <code>OperandSandboxIrrelevant</code>, <code>OperandSandbox8bit</code>, <code>OperandSandboxRestricted</code>, and <code>OperandSandboxUnrestricted</code>. The first type is something not related to a general purpose register (x87, MMX, XMM, or YMM registers fall unto this category). We need to handle 8bit operands specially because they are finicky: if <code>REX</code> byte is used they access <code>%spl</code>, <code>%bps</code>, <code>%sil</code>, and <code>%dil</code>, but when <code>REX</code> byte is not used the same numbers are reused for <code>%ah</code>, <code>%ch</code>, <code>%dh</code>, and <code>%bh</code>! The last two types are the most important: these are 32bit operands (which will make the appropriate register “restricted”) or 16bit/64bit operands (these may affect the register in question negatively if it's <code>%rbp</code>, <code>%rsp</code>, or <code>%r15</code>, but for other registers these are just ignored). Note that if you assign <code>0</code> to this variable then all operands will be of <code>OperandSandboxIrrelevant</code> type.</p>
<p>Now the set of macros used to work with operands should look less mysterious:<hr />
<code>#define SET_OPERAND_NAME(INDEX, REGISTER_NAME) \</code><br />
<code> ((operand_states & (0xff << ((INDEX) << 3))) == \</code><br />
<code> ((((KIND) << 5) | (REGISTER_NAME)) << ((INDEX) << 3)))</code><br />
<hr />
-Calls like <code>SET_OPERAND_NAME(0, REG_RAX)</code> are used by actions to set name of the operand (this particular one is used by <code>operand0_rax</code> action) while calls like <code>SET_OPERAND_FORMAT(0, OPERAND_FORMAT_2_BIT)</code> are used by actions to set the type of operand (this particular one is used by <code>operand0_2bit</code> action). Note that we <b>don't</b> handle 2bit operands in the set of macros above. This is not a mistake: 2bit operands are only ever used as immediate operands (and then only in two instructions: <code>vpermil2pd</code> and <code>vpermil2ps</code>) and we don't process immediate operands here. If they will be by some reason left in the <code>validator_x86_64_instruction.rl</code> file this will lead to the compile-time error, not to some kind of weird overflow which may [potentially] produce security hole.</p>
+Calls like <code>SET_OPERAND_NAME(0, NC_REG_RAX)</code> are used by actions to set name of the operand (this particular one is used by <code>operand0_rax</code> action) while calls like <code>SET_OPERAND_FORMAT(0, OPERAND_FORMAT_2_BIT)</code> are used by actions to set the type of operand (this particular one is used by <code>operand0_2bit</code> action). Note that we <b>don't</b> handle 2bit operands in the set of macros above. This is not a mistake: 2bit operands are only ever used as immediate operands (and then only in two instructions: <code>vpermil2pd</code> and <code>vpermil2ps</code>) and we don't process immediate operands here. If they will be by some reason left in the <code>validator_x86_64_instruction.rl</code> file this will lead to the compile-time error, not to some kind of weird overflow which may [potentially] produce security hole.</p>
<p>Almost all manipulations with <code>operand_states</code> are done using macros described above, but there are one another construct which accesses the <code>operand_states</code> directly:<hr />
<code>#define CHECK_OPERAND_RESTRICTED(INDEX) \</code><br />
<code> /* and also make sure operand_states denotes a register (4th bit == 0). */\</code><br />
<code> (operand_states & (0x70 << ((INDEX) << 3))) == \</code><br />
<code> (OPERAND_SANDBOX_RESTRICTED << (5 + ((INDEX) << 3)))</code><hr />
-If you'll take a look on the layout of <code>operand_states</code> then it's pretty easy to understand what goes on here: <code>(operand_states & (0x70 << ((INDEX) << 3))) == (OPERAND_SANDBOX_RESTRICTED << (5 + ((INDEX) << 3)))</code> yields <code>TRUE</code> if and only if zeroth operand is “normal” register <b>and</b> it's of type <code>OperandSandboxRestricted</code>. This is actually central piece of the <code>restricted_register</code> handling—most other pieces just return it back to <code>NO_REG</code> state.</p>
+If you'll take a look on the layout of <code>operand_states</code> then it's pretty easy to understand what goes on here: <code>(operand_states & (0x70 << ((INDEX) << 3))) == (OPERAND_SANDBOX_RESTRICTED << (5 + ((INDEX) << 3)))</code> yields <code>TRUE</code> if and only if zeroth operand is “normal” register <b>and</b> it's of type <code>OperandSandboxRestricted</code>. This is actually central piece of the <code>restricted_register</code> handling—most other pieces just return it back to <code>NC_NO_REG</code> state.</p>
<h2><div style="float:right"><a href="#TOC">▲</a></div><a name="5">5. Features beyond minimal validation.</a></h2>
<tr><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td colspan="2" align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left"> </td><td align="left">┊</td><td align="left">┊</td><td align="left"> </td><td align="left" colspan="100" >└ <span class="hoverable" title="enter, extrq, insertq">Instruction has two immediates</a>.</td></tr>
<tr><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td colspan="2" align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left"> </td><td align="left">┊</td><td align="left" colspan="100" >└ <span class="hoverable" title="00 == 0 bytes, 01 == 1 bytes, 10 = 2 bytes, 11 = 4 bytes">Instruction displacement size</span>.</td></tr>
<tr><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td colspan="2" align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left"> </td><td align="left" colspan="100" >└ Instruction has relative offset.</td></tr>
-<tr><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td colspan="2" align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left" colspan="100" >└ <span style="background: lightgray;">ia32 mode: reserved;</span> amd64 mode: <span class="hoverable" title="NO_REG if instruction does not zero-extending one">Register, zero-extended by the instruction.</span></td></tr>
+<tr><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td colspan="2" align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left" colspan="100" >└ <span style="background: lightgray;">ia32 mode: reserved;</span> amd64 mode: <span class="hoverable" title="NC_NO_REG if instruction does not zero-extending one">Register, zero-extended by the instruction.</span></td></tr>
<tr><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td colspan="2" align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left" colspan="100" >└ <span style="background: lightgray;">ia32 mode: reserved;</span> amd64 mode: <span class="hoverable" title="This means that start of this instruction is not a valid jump target.">Instruction is valid, but it access memory using register which is zero-extended by previous instruction.</span></td></tr>
<tr><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td colspan="2" align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left" colspan="100" >└ <span class="hoverable" title="Note that all unsupported instructions trigger this error. This includes mov by absolute 64bit address, system instructions like lidt or even call and jmp used not as part of superinstruction. If combined with CPUID_UNSUPPORTED_INSTRUCTION it means that instruction is not yet enabled in validator.">DFA error: invalid instruction. Validation then resumes from the next bundle.</span></td></tr>
<tr><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td colspan="2" align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left">┊</td><td align="left" colspan="100" >└ Unaligned direct jump to address outside of given region.</td></tr>
projects / platform / framework / web / crosswalk.git / blobdiff