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

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

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
> > the
> > 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
> breakage.
>
> 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.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel