9

我有一种情况，其中某些地址空间很敏感，因为您阅读它会崩溃，因为那里没有人响应该地址。

pop {r3,pc}
bx r0

   0:   e8bd8008    pop {r3, pc}
   4:   e12fff10    bx  r0

   8:   bd08        pop {r3, pc}
   a:   4700        bx  r0

bx 不是由编译器作为指令创建的，而是一个 32 位常量的结果，该常量不适合作为单个指令中的立即数，因此设置了 pc 相对负载。这基本上是文字池。它恰好有类似于 bx 的位。

可以很容易地编写一个测试程序来生成问题。

unsigned int more_fun ( unsigned int );
unsigned int fun ( void )
{
    return(more_fun(0x12344700)+1);
}

00000000 <fun>:
   0:   b510        push    {r4, lr}
   2:   4802        ldr r0, [pc, #8]    ; (c <fun+0xc>)
   4:   f7ff fffe   bl  0 <more_fun>
   8:   3001        adds    r0, #1
   a:   bd10        pop {r4, pc}
   c:   12344700    eorsne  r4, r4, #0, 14

在这种情况下，处理器正在等待从弹出（ldm）返回的数据移动到下一条指令 bx r0，并在 r0 中的地址开始预取。哪个挂着 ARM。

作为人类，我们将 pop 视为无条件分支，但处理器不会，它一直通过管道。

预取和分支预测并不是什么新鲜事（在这种情况下我们关闭了分支预测器），已有数十年历史，并且不仅限于 ARM，而是将 PC 作为 GPR 的指令集的数量以及在某种程度上将其视为非- 特殊的很少。

我正在寻找一个 gcc 命令行选项来防止这种情况。我无法想象我们是第一个看到这个的人。

我当然可以这样做

-march=armv4t


00000000 <fun>:
   0:   b510        push    {r4, lr}
   2:   4803        ldr r0, [pc, #12]   ; (10 <fun+0x10>)
   4:   f7ff fffe   bl  0 <more_fun>
   8:   3001        adds    r0, #1
   a:   bc10        pop {r4}
   c:   bc02        pop {r1}
   e:   4708        bx  r1
  10:   12344700    eorsne  r4, r4, #0, 14

防止问题

请注意，不仅限于拇指模式，gcc 还可以在弹出后使用文字池为类似的东西生成 arm 代码。

unsigned int more_fun ( unsigned int );
unsigned int fun ( void )
{
    return(more_fun(0xe12fff10)+1);
}

00000000 <fun>:
   0:   e92d4010    push    {r4, lr}
   4:   e59f0008    ldr r0, [pc, #8]    ; 14 <fun+0x14>
   8:   ebfffffe    bl  0 <more_fun>
   c:   e2800001    add r0, r0, #1
  10:   e8bd8010    pop {r4, pc}
  14:   e12fff10    bx  r0

希望有人知道一个通​​用或特定于 arm 的选项来执行 armv4t 之类的返回（例如 pop {r4,lr}; bx lr 在 arm 模式下）而不带行李或在 pop pc 之后立即将分支放到 self （似乎解决了问题管道并不混淆 b 作为无条件分支。

编辑

ldr pc,[something]
bx rn

也会导致预取。这不会属于-march = armv4t。gcc 故意生成 ldrls pc,[]; b 某处用于 switch 语句，这很好。没有检查后端是否有其他 ldr pc,[] 指令生成。

编辑

看起来 ARM 确实将此报告为勘误表（勘误表 720247，“可以在内存映射中的任何位置进行推测性指令提取”），希望我在我们花了一个月的时间之前就知道...

4

1 回答 1

5

https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html有一个-mpure-code 选项，它不会将常量放在代码部分中。“此选项仅在使用 MOVT 指令为 M-profile 目标生成非 pic 代码时可用。” 所以它可能会使用一对 mov-immediate 指令而不是从常量池加载常量。

但是，这并不能完全解决您的问题，因为带有虚假寄存器内容的常规指令（在函数内的条件分支之后）的推测执行仍然可能触发对不可预测地址的访问。或者只是另一个函数的第一条指令可能是负载，因此陷入另一个函数也并不总是安全的。

我可以尝试阐明为什么这足够晦涩，以至于编译器还没有避免它。

通常，错误指令的推测执行不是问题。CPU 在变为非推测性之前实际上不会承担故障。不正确（或不存在）的分支预测可能会使 CPU 在找出正确路径之前做一些缓慢的事情，但绝不应该存在正确性问题。

通常，在大多数 CPU 设计中都允许来自内存的推测性负载。但是带有 MMIO 寄存器的内存区域显然必须受到保护。例如，在 x86 中，内存区域可以是 WB（正常，可回写缓存，允许推测加载）或 UC（不可缓存，无推测加载）。更不用说写-组合直写...

您可能需要类似的东西来解决您的正确性问题，以阻止投机执行做一些实际会爆炸的事情。 这包括由推测性触发的推测性指令获取bx r0。（抱歉，我不了解 ARM，所以我不能建议您如何做到这一点。但这就是为什么对于大多数系统来说这只是一个次要的性能问题，即使它们具有无法推测性读取的 MMIO 寄存器。 )

我认为有一个设置让 CPU 从使系统崩溃的地址进行推测性加载而不是仅仅在/如果它们变为非推测性时引发异常是非常不寻常的。

在这种情况下，我们关闭了分支预测器

这可能就是为什么您总是在无条件分支 (the pop) 之外看到推测执行，而不是非常罕见。

使用 abx返回的不错的侦探工作，表明您的 CPU 在解码时检测到这种无条件分支，但不检查 a 中的pc位pop。：/

通常，分支预测必须在解码之前发生，以避免获取气泡。给定一个获取块的地址，预测下一个块获取地址。预测也是在指令级别而不是 fetch-block 级别生成的，以供内核的后续阶段使用（因为一个块中可以有多个分支指令，您需要知道采用哪一个）。

这就是一般理论。 分支预测不是 100%，所以你不能指望它来解决你的正确性问题。

x86 CPU 可能会出现性能问题，其中默认预测为间接jmp [mem]或jmp reg下一条指令。如果推测性执行启动了一些取消速度很慢的事情（例如div在某些 CPU 上）或触发了缓慢的推测性内存访问或 TLB 未命中，则一旦确定正确路径，它可能会延迟执行正确路径。

因此建议（通过优化手册ud2）int3在jmp reg. 或者更好的是，将跳转表目的地之一放在那里，这样“失败”在某些时候是一个正确的预测。（如果 BTB 没有预测，下一条指令是它唯一能做的明智的事情。）

但是，x86 通常不会将代码与数据混合，因此对于文字池很常见的架构来说，这更可能是一个问题。（但是来自虚假地址的加载仍然可能在间接分支或错误预测的正常分支之后发生推测性的。

例如if(address_good) { call table[address](); }，很容易错误预测并触发从错误地址获取推测性代码。但是如果最终的物理地址范围被标记为不可缓存，加载请求将在内存控制器中停止，直到知道它是非推测性的

返回指令是一种间接分支，但下一条指令预测不太可能有用。那么，也许bx lr是因为投机性失败不太可能有用而停滞不前？

pop {pc}（又名LDMIA来自堆栈指针）在解码阶段没有被检测为分支（如果它没有专门检查该pc位），或者它被视为通用间接分支。ldinto作为非返回分支肯定还有其他用例pc，因此将其检测为可能的返回将需要检查源寄存器编码以及pc位。

也许有一个特殊的（内部隐藏的）返回地址预测器堆栈bx lr，当与bl? x86 这样做是为了预测call/ret指令。

您是否测试过是否pop {r4, pc}比pop {r4, lr}/更有效bx lr？如果bx lr被特别处理不仅仅是为了避免垃圾的推测性执行，那么让 gcc 这样做可能会更好，而不是让它用b指令或其他东西引导它的文字池。

于 2017-09-09T04:51:25.457 回答