docs/development/languages/fidl/reference/ftp/ftp-005.md - fuchsia - Git at Google

 > This [FTP](README.md) is rejected

 # Rejection Rationale

 This FTP was rejected because having a hard limit was felt to be too
 heavy-handed.
 The [types.h][types] file has definitions for `ZX_CHANNEL_MAX_MSG_BYTES`
 and `ZX_CHANNEL_MAX_MSG_HANDLES` that can be examined by the implementor
 and used to limit the resource consumption.

 Possible directions discussed were annotation based constraints (today
 we have `[MaxHandles]` and `[MaxBytes]` attributes).

 There are also use cases where we need to express (in the language) possibly
 unbounded messages (size, or handles).
 Typically, such messages are dynamically assembled to meet the requirements
 of the underlying transport (e.g. optimize throughput, adapt to older clients).

 # [FIDL Tuning Proposal](README.md) 005

 Method Impossible
 =================

 Field     | Value
 ----------|--------------------------
 Status    | Rejected
 Authors   | ianloic@google.com
 Submitted | 2018-07-19
 Reviewed  | 2018-09-11

 [TOC]

 ## Summary

 It should be an error to declare an interface method that may require more
 than the maximum number of handles or bytes allowed in a Zircon channel
 message.

 It's easy to declare FIDL types that may be impossible to send in a single
 Zircon channel message.
 Developers should be able to avoid defining types that may cause unexpected
 runtime errors.

 Since we foresee other transports for FIDL data like shared memory,
 persistent storage and the network, the limit is on interface methods rather
 than on types.

 ## Motivation

 Edge-cases are hard to test well and hard to reason about.
 FIDL messages that could be impossible to transmit in exceptional
 circumstances are likely to expose poorly tested parts of FIDL services.
 They may be exposed to untrusted code.

 For example, in `fuchsia.sys`, currently a `FlatNamespace` may contain any
 number of handles.
 A `LaunchInfo` may contain a `FlatNamespace`.
 A call to `Launcher.CreateComponent()` could be crafted (maliciously or
 accidentally) that would succeed, but then when the appmgr went to pass the
 supplied `LaunchInfo` to `Runner.StartComponent()` the additional handles
 supplied would block the successful encoding of the message.

 ## Design

 This modifies the FIDL compiler but not the FIDL language, bindings or wire
 format.

 The FIDL frontend compiler now keeps track of how many handles and bytes may
 be required to represent a message.
 Currently a Zircon channel message may only contain up to 64 handles.
 The compiler should print an error and fail if any method is defined that
 could require more than 64 handles to encode its request or response.
 Currently a Zircon channel message may only contain up to 64k bytes.
 The compiler should print an error and fail if any method is defined that
 could require more than 64k bytes to encode its request or response.

 There are two main patterns that fall afoul of this restriction: recursive
 types with handles and unbounded vectors of handles (or types that contain
 them).
 It's fairly straight-forward to avoid these.

 ## Documentation and Examples

 FIDL documentation should document this constraint and ensure that all
 examples are valid.
 The error messages produced by the compiler should be clear and useful.

 ## Backwards Compatibility

 This breaks FIDL source compatibility.
 Many existing interfaces (such as `FlatNamespace` described above) fail to
 constrain the number of handles or bytes that may be required.
 These interfaces would have to be tightened up.

 ## Performance

 There should be no direct performance impact.
 Some interfaces and types may need to be changed if they really want to
 support arbitrarily many handles or bytes but they never would have worked
 anyway.

 ## Security

 This change reduces the amount of unexpected, under-tested behavior that
 applications will experience so it will improve security.

 ## Testing

 The `fidlc` compiler should get some new tests to ensure that its
 calculations of handle counts are correct.

 ## Drawbacks, Alternatives, and Unknowns

 This exposes some additional details of the Zircon channel IPC mechanism to
 FIDL interface authors.
 This seems like a fair trade-off because currently anyone using those
 interfaces needs to be aware of those trade-offs.

 We could require all strings and vectors to have explicit bounds.
 This would encourage interface authors to design types that might be safely
 usable across Zircon channels but might limit the flexibility of FIDL types
 across other media.

 While the only transport for handles is channel messages, there are other
 transports for FIDL encoded bytes such as VMOs, network sockets and
 persistent storage.
 It may be useful to allow some types to opt-out (for example with an
 attribute) from this constraint, even though those types would never be able
 to be transmitted over a zircon channel.

 It may be worth considering incorporating other mechanism into the FIDL
 language (pagination / streaming / etc.) before imposing this constraint on
 byte lengths.

 ## Prior Art and References

 Unknown

 <!-- xrefs -->
 [types]: /zircon/system/public/zircon/types.h
	> This [FTP](README.md) is rejected

	# Rejection Rationale

	This FTP was rejected because having a hard limit was felt to be too
	heavy-handed.
	The [types.h][types] file has definitions for `ZX_CHANNEL_MAX_MSG_BYTES`
	and `ZX_CHANNEL_MAX_MSG_HANDLES` that can be examined by the implementor
	and used to limit the resource consumption.

	Possible directions discussed were annotation based constraints (today
	we have `[MaxHandles]` and `[MaxBytes]` attributes).

	There are also use cases where we need to express (in the language) possibly
	unbounded messages (size, or handles).
	Typically, such messages are dynamically assembled to meet the requirements
	of the underlying transport (e.g. optimize throughput, adapt to older clients).

	# [FIDL Tuning Proposal](README.md) 005

	Method Impossible
	=================

	Field \| Value
	----------\|--------------------------
	Status \| Rejected
	Authors \| ianloic@google.com
	Submitted \| 2018-07-19
	Reviewed \| 2018-09-11

	[TOC]

	## Summary

	It should be an error to declare an interface method that may require more
	than the maximum number of handles or bytes allowed in a Zircon channel
	message.

	It's easy to declare FIDL types that may be impossible to send in a single
	Zircon channel message.
	Developers should be able to avoid defining types that may cause unexpected
	runtime errors.

	Since we foresee other transports for FIDL data like shared memory,
	persistent storage and the network, the limit is on interface methods rather
	than on types.

	## Motivation

	Edge-cases are hard to test well and hard to reason about.
	FIDL messages that could be impossible to transmit in exceptional
	circumstances are likely to expose poorly tested parts of FIDL services.
	They may be exposed to untrusted code.

	For example, in `fuchsia.sys`, currently a `FlatNamespace` may contain any
	number of handles.
	A `LaunchInfo` may contain a `FlatNamespace`.
	A call to `Launcher.CreateComponent()` could be crafted (maliciously or
	accidentally) that would succeed, but then when the appmgr went to pass the
	supplied `LaunchInfo` to `Runner.StartComponent()` the additional handles
	supplied would block the successful encoding of the message.

	## Design

	This modifies the FIDL compiler but not the FIDL language, bindings or wire
	format.

	The FIDL frontend compiler now keeps track of how many handles and bytes may
	be required to represent a message.
	Currently a Zircon channel message may only contain up to 64 handles.
	The compiler should print an error and fail if any method is defined that
	could require more than 64 handles to encode its request or response.
	Currently a Zircon channel message may only contain up to 64k bytes.
	The compiler should print an error and fail if any method is defined that
	could require more than 64k bytes to encode its request or response.

	There are two main patterns that fall afoul of this restriction: recursive
	types with handles and unbounded vectors of handles (or types that contain
	them).
	It's fairly straight-forward to avoid these.

	## Documentation and Examples

	FIDL documentation should document this constraint and ensure that all
	examples are valid.
	The error messages produced by the compiler should be clear and useful.

	## Backwards Compatibility

	This breaks FIDL source compatibility.
	Many existing interfaces (such as `FlatNamespace` described above) fail to
	constrain the number of handles or bytes that may be required.
	These interfaces would have to be tightened up.

	## Performance

	There should be no direct performance impact.
	Some interfaces and types may need to be changed if they really want to
	support arbitrarily many handles or bytes but they never would have worked
	anyway.

	## Security

	This change reduces the amount of unexpected, under-tested behavior that
	applications will experience so it will improve security.

	## Testing

	The `fidlc` compiler should get some new tests to ensure that its
	calculations of handle counts are correct.

	## Drawbacks, Alternatives, and Unknowns

	This exposes some additional details of the Zircon channel IPC mechanism to
	FIDL interface authors.
	This seems like a fair trade-off because currently anyone using those
	interfaces needs to be aware of those trade-offs.

	We could require all strings and vectors to have explicit bounds.
	This would encourage interface authors to design types that might be safely
	usable across Zircon channels but might limit the flexibility of FIDL types
	across other media.

	While the only transport for handles is channel messages, there are other
	transports for FIDL encoded bytes such as VMOs, network sockets and
	persistent storage.
	It may be useful to allow some types to opt-out (for example with an
	attribute) from this constraint, even though those types would never be able
	to be transmitted over a zircon channel.

	It may be worth considering incorporating other mechanism into the FIDL
	language (pagination / streaming / etc.) before imposing this constraint on
	byte lengths.

	## Prior Art and References

	Unknown

	<!-- xrefs -->
	[types]: /zircon/system/public/zircon/types.h