Easyboot 中的 Stivale 支持
========================

永远不会发生。此启动协议存在一些非常严重的设计错误，存在巨大的安全风险。

首先，stivale 内核有一个 ELF 标头，但不知何故您应该知道该标头无效；标头中没有任何东西暗示它不是有效的 SysV ABI 内核。在 Multiboot 中，
文件开头必须有一些魔法字节，以便您可以检测协议；stivale / stivale2 中没有类似的东西。（锚点对您没有帮助，因为它可能出现在文件中的*任何地方*，
因此实际上必须*搜索整个文件*以确保它与 stivale 不兼容。）

其次，它使用节；根据 ELF 规范（参见 [第 46 页](https://www.sco.com/developers/devspecs/gabi41.pdf)），节是可选的，加载器无需关心。
加载器使用执行视图，而不是链接视图。仅因为这个协议而实现节解析对任何加载器来说都是巨大的开销，因为系统资源通常已经很稀缺了。

第三，节头位于文件末尾。这意味着为了检测 stivale，您必须加载文件的开头，解析 ELF 头，然后加载文件的末尾并解析节头，然后从文件的中间某处加载以获取实际的标记列表。
这可能是最糟糕的解决方案。而且，再说一次，没有任何迹象表明加载器应该这样做，所以您必须对所有内核执行此操作才能发现内核不使用 stivale。
这也会减慢对*所有其他*启动协议的检测速度，这是不可接受的。

应用程序处理器会主动轮询标签列表，而内核可能会随时调用引导加载程序代码，这意味着您根本无法回收引导加载程序的内存，否则必然会崩溃。这违背了 **Easyboot** 的理念。

最糟糕的是，该协议要求引导加载程序将代码注入任何与 stivale 兼容的内核，然后以尽可能高的权限级别执行。是的，这有什么不对吗？

因为我拒绝将质量低劣的代码交给别人，所以 **Easyboot** 中不会提供任何 stivale 支持。如果您听从我的建议，任何业余操作系统开发人员都不应该为了个人利益使用它。
