软件中断例程和用户模式功能之间的区别

Question

好吧，我的问题在标题中

众所周知，异常处理程序例程负责将用户模式切换到内核模式 这涉及某些装配说明

据称这是为了防止应用程序使用具有受限访问权限的高权限指令和内存区域

用户模式应用程序不能单独执行此用户内核切换吗？即在应用程序本身的通常功能例程中使用那些汇编指令？

如果是这样，那么我无法理解软件中断的重点以及与用户内核交换机相关的所有安全注意事项

我们只是在程序中实现了这个开关，瞧！我们现在处于内核模式

WTH

Answer 1

你犯了一个错误：用户唯一能做的就是调用一个可以执行特权指令的例程。这是由软件中断完成的。它被称为中断，因为原始用户模式程序在处理呼叫时停止。这样，用户模式程序完全无法执行特殊权限，但它可以调用内核中的中断例程。程序本身从不处于内核模式。

Answer 2

重点是安全。

Userland应用程序在有限的环境中工作。他们可以做自己的事情，但不能读或写任何未明确分配给他们的东西。这是非常重要的。整个现代操作系统的重点是保持应用程序分离。这主要是通过使用现代硬件提供的内存管理器单元来确保的。因此，典型的用户态应用程序无法访问任何内核内存，无法“跳入”任何地方。如果允许的话，就无法确定应用程序是否没有跳到内核没有预料到的地方，并且执行代码会导致整个系统崩溃或从另一个应用程序中窃取您的信用卡号。

当应用程序需要任何“在它自己的框之外”的功能时，它必须调用内核代码来执行它。但是怎么样？从应用程序的角度来看，任何地方都没有内核代码。这就是为什么通常有一条“系统调用”指令（系统调用）。它使当前的代码流跳转到一个，指定了内核准备的内容以及它希望处理所有userland请求的位置。由于系统调用与IRQ，数据/预取和类似事件非常相似，因此硬件体系结构通常对这些事件进行建模，这些事件通常称为“异常”。因此名称为“软件中断”。

这有点过分简单，但确实如此。如果你想完全理解它，你必须熟悉异常，虚拟内存和类似的概念。

Answer 3

首先，我不太明白你想通过“手动”切换到内核模式获得什么。所以，你已经切换了然后呢？你想下一步该做什么？如果你想访问不应该在用户应用程序中访问的资源，那么这就是不允许它的重点，因为如果它被允许，那么你的应用程序将能够轻松地做出令人讨厌的事情：

• 损坏操作系统并挂起或重新启动计算机
• 将计算机用户扣为人质并索取赎金
• 将计算机变成隐蔽垃圾邮件机器人或网络上其他计算机的远程操作攻击者
• 监视操作系统和其他应用程序并窃取机密信息
• 篡改信息
• 解决DRM和其他各种许可证等问题
• 假冒同一台计算机的其他用户可能使用他们的银行帐户或信用卡信息或其密码窃取他们或偷窃他们
• 禁用反病毒软件（如果有），可能导致上述任何或所有内容
• 等等

现在，如果您对上述任何内容不感兴趣，那么您的应用就没有理由获得内核权限。

我承认，操作系统中存在某些错误以及我们考虑通过获取所述访问权限来解决的错误，但这种情况很少见，很少有人能够在不破坏重要性的情况下“修复”这些错误因此，可靠性和安全性问题超过了1000比1的“修复”操作系统中你不喜欢的东西的冲动。

至于中断和异常是切换到内核模式的方式，这只是一个有意义的常见实现。

必须在内核中处理中断，这就是它们在需要时产生切换的原因。它们必须是因为只有内核和设备驱动程序知道如何处理触发中断的硬件。这就是操作系统的重点，要抽象出硬件差异，并为程序提供统一的API，以便让他们摆脱知道如何使用这个或那个显示器或声卡，网卡或打印机等的负担。等

软件中断只是捎带与硬件中断相同的机制，因为这样做很便宜。软件中断的主要用途是从操作系统请求一些工作/帮助，并且可以理解的是，它们也需要切换，这就是硬件中断已经做到的。

在x86平台上，硬件中断和ìnt指令在CPU中产生非常相同的响应，它们的处理方式非常相似。

对于此系统调用功能，某些CPU提供与中断无关的特殊指令。它们可能比在硬件中断之上实现的软件中断更快，或者它们可能带有软件中断不提供的一些有用的额外功能。

x86说明sysenter和syscall就属于这种情况。它们针对从用户模式到内核模式的快速转换进行了优化。

一些例外与硬件中断具有相同的性质，例如：页面错误异常。它也必须在内核中处理，因为这是操作系统用来实现虚拟磁盘内存的机制。操作系统需要访问磁盘上的内容以响应页面错误，然后更改页面表，您的应用程序不太可能自己做到这一点，让它访问像任意位置这样的重要事情不是一件好事在磁盘或页面表上自由。

其他异常用于控制应用程序的执行并通知操作系统出错的地方，这使操作系统有机会解决问题或终止行为不端的应用程序而不必将其保留在仍然消耗宝贵的zombi状态内存等资源。这些异常也需要在内核中处理，这是实现它的唯一方法。

现在，您可能有兴趣在应用程序本身内处理应用程序的异常。有些操作系统允许你这样做。 Windows实现了它所谓的Structured Exception Handling（AKA SEH），而Linux和Unix实现了signals。通常做任何一种操作仍然需要先在内核中处理异常，然后再将其反映回原来的位置。这就是大多数CPU的实现方式。当异常首次路由到内核时，这样的实现很容易且很便宜，并且它不会禁止任何内容，因为内核可以在此基础上实现任何功能，包括SEH和信号。

无论如何，因为操作系统/内核为用户应用程序提供功能并确保安全性而且两者往往并非齐头并进（因为操作系统/内核可以访问所有内容，而您的应用程序不应该操作系统有时代表你的应用程序访问这些东西，想到礼貌:)，这两件事都在用户模式和内核模式之间的假想范围之后。