[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 6/7] xen/arm: zynqmp: implement zynqmp_eemi


On 12/12/18 11:56 PM, Stefano Stabellini wrote:
On Wed, 12 Dec 2018, Julien Grall wrote:
On 11/12/2018 22:23, Stefano Stabellini wrote:
On Tue, 11 Dec 2018, Julien Grall wrote:
Furthermore, you are forwarding unsanitized values to the firmware. For
instance, what would happen if the number of parameters of the call are
increased? How are you sure this will not open a hole?

EEMI is backward compatible and the implementation is tested with Xen
regularly. A change like the one you describe should be considered a
backward compatibility breakage.

I disagree, you can still make backward compatible. For instance, the new
parameters could be gated by a flag in an existing parameter. Another way is
Xilinx promise that non-existing arguments should always be 0 and then
re-purpose the value for non-zero case.

While it is backward compatible, you may end up passing unsanitized value to
firmware. Not sure this is what we want...

Backward compatibility is not only about avoiding breaking existing call
parameters and return values. It is also about not breaking the
semantics of the calls.

If a call is deemed guest safe (when a guest has a device assigned) so
Xen forwards the call to firmware, but then firmware introduces a new
parameter (before it was ignored) and with it, allows more extensive
operations that go beyong a single device, I think that is semantics

In any case, this is almost impossible to do with EEMI because calls
take a node_id parameter or similar that identifies the area of the
effect of the operation, and we already check on the node_id to see if
the guest is allowed to make the call.

Please write it down in the code so we know why we don't need to worry on parameters.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.