On Wed, Sep 18, 2019 at 4:44 AM Andre Przywara <andre.przywara@xxxxxxx> wrote: > > > which needs 9 arguments to work. The fact that the fist argument is > > always going to be same on a platform is just the way we use this > > instruction. > > > > > We should be as strict as possible to avoid any security issues. > > > > > Any example of such a security issue? > > Someone finds a way to trick some mailbox client to send a crafted message to the mailbox. > What if someone finds a way to trick the block layer to erase 'sda' ? That is called "bug in the code". It does happen in every subsystem but we don't stop implementing new features .... we write flexible code and then fix any bug. > Do you have any example of a use case where the mailbox client needs to provide the function ID? > FSL_SIP_SCMI_1/2 ? But that is not the main point, which is to be consistent (not ignoring first argument because someone may find a bug to exploit) and flexible. > > > The firmware certainly knows the function ID it implements. The firmware controls the DT. So it is straight-forward to put the ID into the DT. The firmware could even do this at boot time, dynamically, before passing on the DT to the non-secure world (bootloader or kernel). > > > > > > What would be the use case of this functionality? > > > > > At least for flexibility and consistency. > > I appreciate the flexibility idea, but when creating an interface, especially a generic one to any kind of firmware, you should be as strict as possible, to avoid clashes in the future. > I really don't see how there can be clashes with more complete and flexible implementation. Thanks.
