|RFC-0102: Forbid CHILD_NO_WRITE with CHILD_RESIZABLE|
Make it an error to pass ZX_VMO_CHILD_NO_WRITE with ZX_VMO_CHILD_RESIZABLE to zx_vmo_create_child
|Date submitted (year-month-day)||2021-05-25|
|Date reviewed (year-month-day)||2021-06-10|
This RFC proposes to make it an error to pass the combination of both
Creating a child VMO, using
zx_vmo_create_child, that has the
ZX_VMO_CHILD_NO_WRITE flag set explicitly removes
ZX_RIGHT_WRITE from the
produced handle. As this is the only, at this point, handle to the newly created
VMO, and its rights can never be upgraded to include
additional handles to the VMO with
ZX_RIGHT_WRITE can ever be produced.
The resize operation,
zx_vmo_set_size, that can be performed on VMO children
ZX_RIGHT_WRITE, as it can
result in modifying VMO data.
The combination of passing both of these flags to
in the successful creation of a VMO, with a handle returned that will error if
zx_vmo_set_size is called. It is highly confusing from a user point of view to
successfully create an object with
ZX_VMO_CHILD_RESZIABLE, only to have the
resize operation fail. Not only does it fail on the immediately produced handle,
but there is no way for a handle to this object to ever be produced that could
be resized, since handle rights cannot be upgraded.
zx_vmo_create_child syscall will check at the start if both the
ZX_VMO_CHILD_RESIZABLE flags are set, and if so
All changes can be implemented in a single CL.
No known existing usages of this flag combination.
Unit test added to validate restriction.
The API documentation of
zx_vmo_create_child would need updating.
Drawbacks, alternatives, and unknowns
Dedicated resize right
ZX_RIGHT_WRITE is used to gate the
zx_vmo_set_size operation as resizing
modifies the VMO via truncation or zero extension. This is a very limited and
predicted set of modifications and so could have its own dedicated right to
separate it from arbitrary modifications.
Even with such a specialized right, the
ZX_VMO_CHILD_NO_WRITE would almost
certainly want to strip that permission as well since the purpose of
ZX_VMO_CHILD_NO_WRITE is to prevent code modifications. The combination of
truncation and zero extension could, especially on variable instruction length
architectures like x86, result in the formulation of malicious instructions,
even if limited to being done on page boundaries.
The alternative is to leave the syscall how it is, and possibly document the fact that on success a produced handle may not be resizable, even if it was requested.