[PATCH V5 0/2] firmware: ti_sci: zero the secure_hdr in do_xfer
This series adds a fix to make the initial 4 bytes of the secure_hdr to be 0 as per the protocol requirement as of now. Also, inorder to provide a little more context to people add a comment to explain why secure calls are made from uboot
For context, please refer to the discussion from the first patch here: https://lore.kernel.org/all/20240124101558.184411-1-d-gole@ti.com/
Boot tested for sanity on AM62x SK and J721S2: https://gist.github.com/DhruvaG2000/9ca35d1261e8b30f1c2d4a514b9cd941
Changelog:
v4 --> v5 Pick Nishanth's review and also s/sizeof(var)/sizeof(*var) in 1/2
v3 --> v4 Improve commit message in 1/2 and add comment in 2/2
v2 --> v3 Address Kamlesh's comment on v2: use sizeof(struct ti_sci_secure_msg_hdr)
v1 --> v2 Rebased on top of latest master branch
Cc: Nishanth Menon nm@ti.com Cc: Tom Rini trini@konsulko.com Cc: Neha Francis n-francis@ti.com Cc: Manorit Chawdhry m-chawdhry@ti.com Cc: Vignesh Raghavendra vigneshr@ti.com Cc: Kamlesh Gurudasani kamlesh@ti.com Cc: Andrew Davis afd@ti.com
Dhruva Gole (2): firmware: ti_sci: fix the secure_hdr in do_xfer firmware: ti_sci: Add comment explaining the is_secure code
drivers/firmware/ti_sci.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
base-commit: d5c0c990c3128401810514c66b41b386096d206e prerequisite-patch-id: 2ed0c527b6ebf850744d9ff0eca0300a125f7796
The ti_sci driver in U-Boot has support for secure_msg as part of it's do_xfer function. This let's U-boot send secure messages during boot up.
The protocol to send such secure messages is described as part of the struct ti_sci_secure_msg_hdr. As part of this, there are 2 fields for checksum and reserved that occupy the first 4 bytes of any secure message. This is called as the secure_hdr.
As of now, the secure_hdr needs to be 0 init-ed before sending secure messages. However the existing code was never putting the zero-inited vars into the secure_buf, leading to possibility of the first 4 bytes of secure_buf being possibly garbage.
Fix this by initialising the secure_hdr itself to the secure_buf location, thus when we make secure_hdr members 0, it automatically ensures the first 4 bytes of secure_buf are 0.
Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control Interface (TI SCI)") Reviewed-by: Nishanth Menon nm@ti.com Signed-off-by: Dhruva Gole d-gole@ti.com --- drivers/firmware/ti_sci.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c index 6e9f93e9a302..b77ac36af284 100644 --- a/drivers/firmware/ti_sci.c +++ b/drivers/firmware/ti_sci.c @@ -236,21 +236,21 @@ static int ti_sci_do_xfer(struct ti_sci_info *info, { struct k3_sec_proxy_msg *msg = &xfer->tx_message; u8 secure_buf[info->desc->max_msg_size]; - struct ti_sci_secure_msg_hdr secure_hdr; + struct ti_sci_secure_msg_hdr *secure_hdr = (struct ti_sci_secure_msg_hdr *)secure_buf; int ret;
if (info->is_secure) { /* ToDo: get checksum of the entire message */ - secure_hdr.checksum = 0; - secure_hdr.reserved = 0; - memcpy(&secure_buf[sizeof(secure_hdr)], xfer->tx_message.buf, + secure_hdr->checksum = 0; + secure_hdr->reserved = 0; + memcpy(&secure_buf[sizeof(*secure_hdr)], xfer->tx_message.buf, xfer->tx_message.len);
xfer->tx_message.buf = (u32 *)secure_buf; - xfer->tx_message.len += sizeof(secure_hdr); + xfer->tx_message.len += sizeof(*secure_hdr);
if (xfer->rx_len) - xfer->rx_len += sizeof(secure_hdr); + xfer->rx_len += sizeof(*secure_hdr); }
/* Send the message */
On Tue, Jan 30, 2024 at 08:29:59PM +0530, Dhruva Gole wrote:
The ti_sci driver in U-Boot has support for secure_msg as part of it's do_xfer function. This let's U-boot send secure messages during boot up.
The protocol to send such secure messages is described as part of the struct ti_sci_secure_msg_hdr. As part of this, there are 2 fields for checksum and reserved that occupy the first 4 bytes of any secure message. This is called as the secure_hdr.
As of now, the secure_hdr needs to be 0 init-ed before sending secure messages. However the existing code was never putting the zero-inited vars into the secure_buf, leading to possibility of the first 4 bytes of secure_buf being possibly garbage.
Fix this by initialising the secure_hdr itself to the secure_buf location, thus when we make secure_hdr members 0, it automatically ensures the first 4 bytes of secure_buf are 0.
Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control Interface (TI SCI)") Reviewed-by: Nishanth Menon nm@ti.com Signed-off-by: Dhruva Gole d-gole@ti.com
Applied to u-boot/master, thanks!
Add a comment to explain the code under is_secure condition of ti_sci_do_xfer. This will help avoid confusion amongst people who may in future touch upon this code.
Reviewed-by: Nishanth Menon nm@ti.com Signed-off-by: Dhruva Gole d-gole@ti.com --- drivers/firmware/ti_sci.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c index b77ac36af284..ee0921855881 100644 --- a/drivers/firmware/ti_sci.c +++ b/drivers/firmware/ti_sci.c @@ -239,6 +239,12 @@ static int ti_sci_do_xfer(struct ti_sci_info *info, struct ti_sci_secure_msg_hdr *secure_hdr = (struct ti_sci_secure_msg_hdr *)secure_buf; int ret;
+ /* + * The reason why we need the is_secure code is because of boot R5. + * boot R5 starts off in "secure mode" when it hands off from Boot + * ROM over to the Secondary bootloader. The initial set of calls + * we have to make need to be on a secure pipe. + */ if (info->is_secure) { /* ToDo: get checksum of the entire message */ secure_hdr->checksum = 0;
On Tue, Jan 30, 2024 at 08:30:00PM +0530, Dhruva Gole wrote:
Add a comment to explain the code under is_secure condition of ti_sci_do_xfer. This will help avoid confusion amongst people who may in future touch upon this code.
Reviewed-by: Nishanth Menon nm@ti.com Signed-off-by: Dhruva Gole d-gole@ti.com
Applied to u-boot/master, thanks!
participants (2)
-
Dhruva Gole -
Tom Rini