4 ms·

x86 is considered a much more complex instruction set than arm, with multitudes more side-effects. This makes baseband firmware exploits potentially more likely

x86 is considered a much more complex instruction set than arm, with multitudes more side-effects. This makes baseband firmware exploits potentially more likely. That said, modern ARM architectures are also quite complex and calling them RISC is a stretch.

Symmetry 8y ago
There isn't anything to really indicate that this processor has many more instructions than a 8086, befitting its role as an embedded device. I'm not aware of any difference in x86 and ARM semantics in embedded that might cause a problem. Now, the fact that an x86 instruction stream isn't self-synchronizing can represent a danger in theory. That is, you can craft a sequence of x86 instruction such that if you start executing form 0x0000 they're safe and friendly but if you start executing from 0x0001 you'll see a different, equally valid, stream of instructions that might do something malicious. But that doesn't seem like a credible attack vector in this case given the embedded nature of the code.
- monocasa 8y ago
  I'll throw out there that unaligned, unintended instructions can give an attacker more options from an ROP perspective. But it's only a small benefit for the attacker. And for something like this 30MB binary it's six of one, half dozen of another practically speaking.
- dfox 8y ago
  Well, the disassembly in the article contains LGDT, so it is certainly significantly more complex core than 8086.
  - smolsky 8y ago
    Not just that, the second listing used "e" registers, so 32-bit mode (and not just 8086).
    - monocasa 8y ago
      Sure, lgdt implies 32 bit protected mode.
      - dfox 8y ago
        LGDT is valid even for 286-style 16b protected mode.
        monocasa 8y ago
        Oh, you're totally right.
    - dfox 8y ago
      Given how the i386 instruction encoding works that is not significant as in 16b mode mov ax, bx has same encoding as mov eax, ebx in 32b mode (in reality it is somewhat more complex, but this is the gist of it) and thus how it gets disassembled depend on the configuration of the disassembler. One thing that would certainly point on the code being for 32b mode would be stores into control registers (eg. mov cr0, eax instead of smsw ax, which have different encodings, and slightly different effect, with the second one being somewhat nonsencial in 32b mode).
      - dfox 8y ago
        On the other hand the 32b mode code in the disassembly snippet containing lgdt looks reasonable, if it would be 16b code disassembled as 32b it would lead to non-sense as it combines 16b and 32b instructions in meaningful way.
- mehrdadn 8y ago
  What does "self-synchronizing" mean in this context? I've never heard of a self-synchronizing instruction stream. Does it just mean "memory-aligned"?
  - kmeisthax 8y ago
    No. Memory-aligned means that instructions can only exist on certain addresses. (It also implies a minimum instruction length.) On most RISC architectures, instructions are also a constant size, with the same alignment. For example, a MIPS instruction stream consists of 4-byte instructions aligned to every fourth byte in memory. Memory alignment and constant instruction size ensure that any given instruction stream can only be executed as itself, or part of itself. Note that this is not self-synchronization - if you removed a byte from an instruction stream, you would get a wildly different instruction stream. (I said MIPS because ARM instruction streams can be THUMB, which permits a different instruction interpretation for the same stream, and thus defeats the security advantages of memory alignment requirements.) Self-synchronizing means that each subdivided unit (usually byte) of a stream also indicates if it is the start of a new symbol within that stream. For example, UTF-8 is an example of a self-synchronizing byte stream. In UTF-8, encoded codepoints have variable-length representations. However, the upper bits of each byte clearly indicate not only if the byte is the start of a new codepoint, but how many bytes follow to complete the codepoint. This means that a deleted or altered byte will only delete or alter the symbol it's a part of, and not any other part of the stream. Self-synchronization and alignment requirements address the same problem - ambiguous instruction streams - by different methods. Memory alignment prohibits you from reinterpreting the stream; while self-synchronization makes doing so less valuable.
    - Dylan16807 8y ago
      But do any self-synchronizing instruction sets exist? (And are in commercial silicon?) It seems like it would be very annoying for density and constant-encoding reasons with 8 bit code units, and none of the variable 16/32 bit encodings I can name do it either.
      - 8y ago

Symmetry 8y ago

There isn't anything to really indicate that this processor has many more instructions than a 8086, befitting its role as an embedded device. I'm not aware of any difference in x86 and ARM semantics in embedded that might cause a problem. Now, the fact that an x86 instruction stream isn't self-synchronizing can represent a danger in theory. That is, you can craft a sequence of x86 instruction such that if you start executing form 0x0000 they're safe and friendly but if you start executing from 0x0001 you'll see a different, equally valid, stream of instructions that might do something malicious. But that doesn't seem like a credible attack vector in this case given the embedded nature of the code.

monocasa 8y ago
I'll throw out there that unaligned, unintended instructions can give an attacker more options from an ROP perspective. But it's only a small benefit for the attacker. And for something like this 30MB binary it's six of one, half dozen of another practically speaking.
dfox 8y ago
Well, the disassembly in the article contains LGDT, so it is certainly significantly more complex core than 8086.
- smolsky 8y ago
  Not just that, the second listing used "e" registers, so 32-bit mode (and not just 8086).
  - monocasa 8y ago
    Sure, lgdt implies 32 bit protected mode.
    - dfox 8y ago
      LGDT is valid even for 286-style 16b protected mode.
      - monocasa 8y ago
        Oh, you're totally right.
  - dfox 8y ago
    Given how the i386 instruction encoding works that is not significant as in 16b mode mov ax, bx has same encoding as mov eax, ebx in 32b mode (in reality it is somewhat more complex, but this is the gist of it) and thus how it gets disassembled depend on the configuration of the disassembler. One thing that would certainly point on the code being for 32b mode would be stores into control registers (eg. mov cr0, eax instead of smsw ax, which have different encodings, and slightly different effect, with the second one being somewhat nonsencial in 32b mode).
    - dfox 8y ago
      On the other hand the 32b mode code in the disassembly snippet containing lgdt looks reasonable, if it would be 16b code disassembled as 32b it would lead to non-sense as it combines 16b and 32b instructions in meaningful way.
mehrdadn 8y ago
What does "self-synchronizing" mean in this context? I've never heard of a self-synchronizing instruction stream. Does it just mean "memory-aligned"?
- kmeisthax 8y ago
  No. Memory-aligned means that instructions can only exist on certain addresses. (It also implies a minimum instruction length.) On most RISC architectures, instructions are also a constant size, with the same alignment. For example, a MIPS instruction stream consists of 4-byte instructions aligned to every fourth byte in memory. Memory alignment and constant instruction size ensure that any given instruction stream can only be executed as itself, or part of itself. Note that this is not self-synchronization - if you removed a byte from an instruction stream, you would get a wildly different instruction stream. (I said MIPS because ARM instruction streams can be THUMB, which permits a different instruction interpretation for the same stream, and thus defeats the security advantages of memory alignment requirements.) Self-synchronizing means that each subdivided unit (usually byte) of a stream also indicates if it is the start of a new symbol within that stream. For example, UTF-8 is an example of a self-synchronizing byte stream. In UTF-8, encoded codepoints have variable-length representations. However, the upper bits of each byte clearly indicate not only if the byte is the start of a new codepoint, but how many bytes follow to complete the codepoint. This means that a deleted or altered byte will only delete or alter the symbol it's a part of, and not any other part of the stream. Self-synchronization and alignment requirements address the same problem - ambiguous instruction streams - by different methods. Memory alignment prohibits you from reinterpreting the stream; while self-synchronization makes doing so less valuable.
  - Dylan16807 8y ago
    But do any self-synchronizing instruction sets exist? (And are in commercial silicon?) It seems like it would be very annoying for density and constant-encoding reasons with 8 bit code units, and none of the variable 16/32 bit encodings I can name do it either.
    - 8y ago