我了解，当用户通过所述操作系统提供的系统调用使用系统和文件系统时，操作系统会强制用户执行安全策略。
是否可以通过实现您自己的硬件指令而不是使用操作系统提供的系统调用接口来规避这种安全性？即使在您通常无法访问的文件中写入一个位也足够了。
【问题讨论】：
标签： security assembly operating-system system-calls
首先，为简单起见，我认为操作系统和内核是一回事。
在执行代码时，CPU 可以处于不同的模式。 假设一个假设的 CPU 只有两种执行模式（主管和用户）
现在，这个工作的诀窍是，在超级用户模式下，你可以切换到用户模式，因为它是一种特权较低的模式，但是在用户模式下，你不能回到超级用户模式，因为不再允许这样做的说明。 返回管理员模式的唯一方法是通过系统调用或中断。这使操作系统能够完全控制硬件。
一个可能的示例如何将所有东西组合到这个假设的 CPU 中：
我只解释了单个应用程序的流程。 作为帮助您了解它如何与多个运行的应用程序配合使用的奖励，抢占式多任务如何工作的简化视图：
这里的底线是，除非操作系统（或硬件设计）中存在错误，否则应用程序可以从用户模式进入超级用户模式的唯一方法是通过操作系统本身使用系统调用。
这是我在我的爱好项目（虚拟计算机）中使用的机制https://github.com/ruifig/G4DevKit。
【讨论】：
硬件设备连接到 CPU 槽总线，CPU 确实使用与它们通信 in/out 指令在 I/O 端口读取/写入值（当前硬件使用不太多，在早期家用计算机的常用方法），或者设备内存的一部分被“映射”到 CPU 地址空间，CPU 通过在共享内存中定义的位置写入值来控制设备。
所有这些都不能在“用户级别”上下文中访问，其中常见的应用程序由操作系统执行（因此尝试写入该共享设备内存的应用程序会在非法内存访问时崩溃，实际上那块内存通常不是甚至映射到用户空间，即从用户应用程序的角度来看不存在）。直接in/out 指令在 CPU 级别也被阻塞。
设备由驱动程序代码控制，它要么运行是专门配置的用户级上下文，它具有特定的端口和内存映射（微内核模型，其中驱动程序不是内核的一部分，如 OS MINIX） .这种架构更加健壮（驱动程序崩溃无法关闭内核，内核可以隔离有问题的驱动程序并重新启动它，或者完全杀死它），但是内核和用户级别之间的上下文切换是一个非常昂贵的操作，因此吞吐量的数据受到了一点伤害。
或者设备驱动程序代码运行在内核级别（单片内核模型，如 Linux），因此驱动程序代码中的任何漏洞都可以直接攻击内核（仍然不是微不足道的，但比尝试从用户上下文中获取隧道要容易得多通过一些内核错误）。但是 I/O 的整体性能更好（尤其是对于像显卡或 RAID 磁盘集群这样的设备，其数据带宽达到每秒 GiBs）。例如，这就是为什么早期的 USB 驱动程序存在如此巨大的安全风险的原因，因为它们往往存在很多错误，因此特制的 USB 设备可以在内核级上下文中从设备执行一些恶意代码。
因此，正如 Hyd 已经回答的那样，在一般情况下，当一切正常时，用户级应用程序应该无法在其用户沙箱之外发出单个位，并且系统调用之外的可疑行为将被忽略，或使应用崩溃。
如果您找到了打破此规则的方法，那就是安全漏洞，通常会在操作系统供应商收到通知后尽快修补这些漏洞。
虽然目前的一些问题很难修补。例如，当前 DRAM 芯片的“行锤击”根本无法在 SW（OS）或 CPU（配置/固件闪存）级别修复！目前大多数 PC HW 都容易受到这种攻击。
或者在移动世界中，设备使用的是基于传统设计的无线电芯片，具有多年前开发的闭源固件，所以如果你有足够的资源来支付对这些的研究，你很可能能够通过伪造的 BTS 站向目标设备发送恶意无线电信号来获取任何特定设备。
等等......供应商与安全研究人员之间的持续战争以修补所有漏洞，而黑客则寻找理想的零日漏洞利用，或者至少挑选那些没有以足够快的速度修补他们的设备/软件与已知错误的用户。
【讨论】：
不正常。如果有可能是因为操作系统软件错误。如果发现软件错误，它会被快速修复，因为它被认为是软件漏洞，这等于坏消息。
【讨论】：
“系统”调用在比应用程序更高的处理器级别执行：通常是内核模式（但系统系统有多个系统级别模式）。
您所看到的“系统”调用实际上只是一个包装器，它设置寄存器然后触发某种更改模式异常（该方法是系统特定的）。系统异常处理程序分派给适当的系统服务器。
您不能只编写自己的函数并做坏事。诚然，有时人们会发现允许绕过系统保护的错误。作为一般原则，您无法访问设备，除非您通过系统服务进行访问。
【讨论】：