On Wed, Sep 18, 2019 at 9:46 AM Andre Przywara <andre.przyw...@arm.com> wrote: > > On Wed, 18 Sep 2019 09:19:46 -0500 > Jassi Brar <jassisinghb...@gmail.com> wrote: > > Hi, > > > On Wed, Sep 18, 2019 at 4:44 AM Andre Przywara <andre.przyw...@arm.com> > > 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' ? > > Yes, the Linux block driver control the whole block device, it can do > whatever it wants. > Sorry, it doesn't make any sense.
> > 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 ? > > Huh? Where does the SCPI or SCMI driver provide this? Those clients don't > even provide any arguments. Adding some would defeat the whole point of > having this mailbox in the first place, which was to provide a drop-in > replacement for a hardware mailbox device used on other platforms. > SCPI/SCMI implementation is broken. I did NAK it. With the 'smc' mailbox you may get away without have to program the channel before transmit, but not every controller is natively so. > > 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. > > Please read the SMCCC[1]: The first argument is in r1/w1/x1. r0/w0 is the > function ID, and this is a specific value (fixed by the firmware > implementation, see Peng's ATF patch) and not up to be guessed by a client. > The first argument of smc call is the function-id arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, 0, &res); > > That's why I think the function ID (which is part of the SMCCC protocol, not > of the mailbox service!) should just be set in the controller DT node and > nowhere else. > Actually that is the very reason func-id should be a client thing and passed via client's DT node :) It is general understanding that protocol specific bits should not be a part of controller driver, but the client(protocol) driver. Page-7 Function-ID specifies :- 1) The service to be invoked. 2) The function to be invoked. 3) The calling convention (32-bit or 64-bit) that is in use. 4) The call type (fast or yielding) that is in use. Even if we turn blind to 2,3 & 4, but (1) shouts like a runtime property. Thanks.
