| RFC-0062：方法不可行 | |
|---|---|
| 状态 | 已拒绝 |
| 区域 |
|
| 说明 | 如果声明的接口方法可能需要的句柄或字节数超过 Zircon 通道消息中允许的最大数量，则应视为错误。 |
| 作者 | |
| 提交日期（年-月-日） | 2018-07-19 |
| 审核日期（年-月-日） | 2018-09-11 |
拒绝理由
我们之所以拒绝此 FTP，是因为设定硬性上限过于严厉。types.h 文件包含 ZX_CHANNEL_MAX_MSG_BYTES 和 ZX_CHANNEL_MAX_MSG_HANDLES 的定义，可供实现者检查并用于限制资源消耗。
讨论的可能方向是基于注解的约束条件（目前，我们有 [MaxHandles] 和 [MaxBytes] 属性）。
在某些应用场景中，我们需要（使用该语言）表达可能无限的消息（大小或句柄）。通常，此类消息会动态组装，以满足底层传输的要求（例如优化吞吐量、适应旧版客户端）。
摘要
如果声明的接口方法可能需要的句柄或字节数超出 Zircon 通道消息中允许的最大数量，则应视为错误。
您可以轻松声明可能无法在单个 Zircon 通道消息中发送的 FIDL 类型。开发者应避免定义可能导致意外运行时错误的类型。
由于我们预计 FIDL 数据还会有其他传输方式（例如共享内存、持久存储空间和网络），因此限制的是接口方法，而不是类型。
设计初衷
边缘用例很难进行充分测试，也很难推理。在异常情况下无法传输的 FIDL 消息可能会暴露 FIDL 服务中测试不充分的部分。它们可能会被暴露在不受信任的代码中。
例如，在 fuchsia.sys 中，目前 FlatNamespace 可以包含任意数量的句柄。LaunchInfo 可以包含 FlatNamespace。攻击者可能会（恶意或意外地）构造出成功调用 Launcher.CreateComponent() 的请求，但当 appmgr 尝试将提供的 LaunchInfo 传递给 Runner.StartComponent() 时，提供的其他句柄会阻止成功编码消息。
设计
这会修改 FIDL 编译器，但不会修改 FIDL 语言、绑定或线格格式。
FIDL 前端编译器现在会跟踪表示消息可能需要的句柄和字节数。目前，Zircon 通道消息最多只能包含 64 个标识名。如果定义了任何可能需要超过 64 个句柄来编码其请求或响应的方法，编译器应输出错误并失败。目前，Zircon 通道消息最多只能包含 64k 字节。如果定义了任何可能需要超过 64k 字节来编码其请求或响应的方法，编译器应输出错误并失败。
有两种主要模式会违反此限制：包含句柄的递归类型和无限的句柄矢量（或包含它们的类型）。避免这些问题非常简单。
文档和示例
FIDL 文档应记录此约束条件，并确保所有示例均有效。编译器生成的错误消息应清晰且实用。
向后兼容性
这会破坏 FIDL 源代码兼容性。许多现有接口（例如上文所述的 FlatNamespace）都无法限制可能需要的句柄或字节数。这些接口必须更加严格。
性能
对性能应该没有直接影响。 如果某些接口和类型确实想要支持任意数量的句柄或字节，但它们无论如何都无法正常运行，则可能需要进行更改。
安全
这项变更可减少应用会遇到的未经充分测试的意外行为，从而提高安全性。
测试
fidlc 编译器应获得一些新测试，以确保其计算的句柄数正确无误。
缺点、替代方案和未知情况
这会向 FIDL 接口作者公开 Zircon 通道 IPC 机制的一些其他详细信息。这似乎是一个公平的权衡，因为目前，使用这些接口的任何人都需要了解这些权衡。
我们可以要求所有字符串和矢量都具有显式边界。这将鼓励接口作者设计可在 Zircon 通道中安全使用的类型，但可能会限制 FIDL 类型在其他媒体中的灵活性。
虽然句柄的唯一传输方式是通道消息，但对于 FIDL 编码的字节，还有其他传输方式，例如 VMO、网络套接字和永久存储空间。允许某些类型选择不受此约束（例如使用属性）可能很有用，即使这些类型永远无法通过 Zircon 通道传输。
在对字节长度强加此限制之前，不妨考虑将其他机制（分页/流式传输等）纳入 FIDL 语言。
在先技术和参考文档
未知