为什么x86允许未对齐的访问，以及如何检测未对齐的访问？
也许我误解了什么，但x86中的未对齐访问似乎带来了安全问题，例如返回地址完整性问题。
>
为什么x86设计器首先允许未对齐的访问？（性能是我能想到的唯一好处。）
如果x86设计人员允许这种未对齐的访问问题，他们应该知道如何解决它，不是吗？是否可以使用静态技术或清理技术检测未对齐的访问？
共有1个答案
我对这里存在安全隐患的整个前提持怀疑态度；快速搜索您的链接不会发现任何未对齐访问的问题。
许多其他ISA现在也支持未对齐的访问。e、 AArch64，后来的ARM包括ARMv6和ARMv7，甚至还有MIPS32r6（但早期的MIPS修订版并不能保证这一点）。非x86实现通常会对未对齐的加载或存储造成性能损失，即使它位于一条缓存线内（对于可缓存的加载/存储，现代x86没有任何损失）。
8086的主要设计者是Stephen Morse（他写了一本关于它的书，The 8086 Primer，现在在他的网站上免费）。
x86设计选择于1976年至1978年间。（在以后的x86中，如果不中断向后兼容，就无法进行更改，而向后兼容是x86的主要功能。）8086需要支持字节加载和存储，而在其16位总线上支持未对齐的2字节字所需的硬件可能很小。特别是因为还计划使用8088，带有8位总线。我认为它与8086的唯一区别在于总线接口单元。或者，仅仅这样做可能比实现某种对齐故障机制更便宜。
没有明显的安全问题，当然也没有任何人会听说过的问题。
如果8080可以一次加载或存储2个字节，那么8086设计用于从8080-IDK轻松移植asm源代码，但如果允许这样做，它可能不关心对齐，因此8086需要支持。现代静态分析工具可能还没有实现，大多数8080代码都是用asm手工编写的。（我想，就像早期的8086代码一样。）
当时互联网几乎不存在，几乎可以肯定的是，这不是一个考虑因素。8086没有内存保护或特权级别，因此它的设计当然没有考虑到安全性。（与运行多用户操作系统的现代微型计算机CPU不同）。
在AFAIK时代，PC唯一真正的安全威胁是引导扇区病毒，这些病毒通常通过直接执行引导期间系统自动运行的代码或从软盘中传播，而不是攻击其他程序中的漏洞。我可以想象像这样的恶意数据文件。zip或文字处理器格式在某种程度上是被考虑过的，但如果不允许未对齐的访问有任何安全优势的话，那么这在当时是未知的。
软件当然没有在硬化上花费额外的代码大小或周期，在8086之后的几十年里没有。
是否可以使用静态技术或清理技术检测未对齐的访问？
HW支持在x86上检测未对齐的访问，以EFLAGS中AC位的形式。但这通常是不可用的，因为编译器（以及libc中手写的ami memcpy等）有时会使用未对齐的负载，例如初始化或复制结构的相邻窄成员。
GCC具有-fsanize=alignment，它似乎可以检查未针对其类型充分对齐的解引用指针的UB。e、 g.它检查int\u ptr，但不添加memcpy（char\u arr，
未对齐的locked指令非常昂贵（例如系统范围的总线锁或其他东西），至少在跨两条缓存线拆分时是如此，并且有专门的检测它们的特殊支持，而无需抱怨正常的未对齐加载/存储发生在memcpy中的奇数大小。这些机制包括它的perf计数器，以及最近添加的MSR（模型特定寄存器）配置位，以让内核使它们引发异常。
在让一个内核上的非特权代码干扰另一个内核上的硬实时代码方面，缓存-行-拆分locked指令显然是一个问题。
x86中的未对齐访问似乎会带来安全问题，例如返回地址完整性问题。
为什么呢
您链接的那篇文章提到了在这个建议的强化机制中函数查找表的对齐。整篇文章中只有两个字符串“align”的实例，它们都没有谈到ARMv7-M对未对齐的加载/存储的支持，这造成了任何困难。（ARMv7-M是他们正在讨论的ISA，因为它是关于增强嵌入式系统的。）
-
问题内容： 我正在开发一个宠物的开源项目，该项目实现了一些流密码算法，并且只有在ARM处理器上运行该bug时，我才遇到问题。我什至尝试在qemu下的x86中运行ARM二进制文件，但该错误并未在那里触发。 该错误的具体机制仍然难以捉摸，但是我最好的选择是相信它是由程序中未对齐的内存访问尝试引起的，这是qemu实现的，但被开发板中的真正ARM处理器默默忽略了。 因此，由于该问题很难诊断，所以我想知道是
-
我总是听说未对齐的访问是不好的，因为它们要么会导致运行时错误并使程序崩溃，要么会减慢内存访问速度。但是我找不到任何关于它们会减慢多少速度的实际数据。 假设我在x86上并且有一些（但未知的）未对齐访问份额——实际上可能的最糟糕的减速是什么，以及如何在不消除所有未对齐访问并比较两个版本代码的运行时间的情况下估计它？
-
我想模拟x86/x86_64上禁止未对齐内存访问的系统。是否有一些调试工具或特殊模式来执行此操作？ 当使用为SPARC或其他类似CPU设计的软件（C/C）时，我想在几台x86/x86_64PC上运行许多（CPU密集型）测试。但是我对Sparc的访问是有限的。 正如我所知，Sparc总是检查内存读写的对齐是否正常（从任何地址读取一个字节，但仅当地址可被4整除时才允许读取一个4字节的字）。 可能是Va
-
问题内容： 我想用x86 / x86_64上禁止的未对齐内存访问来模拟系统。有一些调试工具或特殊模式可以做到这一点吗？ 当使用为SPARC或其他类似CPU设计的软件（C / C ++）时，我想在几台x86 / x86_64 PC上运行许多（CPU密集型）测试。但是我对Sparc的访问受到限制。 据我所知，Sparc总是检查内存读写的对齐是否自然（从任何地址读取一个字节，但仅当地址被4整除时才读取4
-
在回答中，我说过长期以来（在x86/x86_64上）未对齐的访问速度几乎与对齐的访问速度相同。我没有任何数字来支持这个说法，所以我为它创建了一个基准。 你看到这个基准有什么缺陷吗？你能改进它吗（我的意思是，增加GB/秒，以便更好地反映真相）？
-
我知道C中的未对齐访问是什么，它可能会导致某些处理器UB。 我想知道这样写在NASM汇编上的代码中是否存在同样的问题：