TDA4VM: Using derived KEK on HS devices by TISCI

yongjin ma

Part Number: TDA4VM

We are currently doing TISCI interface testing through TDA4 / XJ721E SOC HS equipment. I added TISCI_MSG_SA2UL_SET_DKEK and TISCI_MSG_SA2UL_GET_DKEK functions in TISCI driver by referring to other TISCI functions. Howerver, ti_sci_is_response_ack(resp) return false in linux kernel and u-boot. In other words, I received a reply, but the ACK bit of the flag was not set. Furthermore, I did a test in ti-boot3. At this time, SET_DKEK and other interfaces can work normally. why is this happening? What I know is that the linux kernel and u-boot run on A72, the host ID is 0x0c, while tiboot3 runs on R5, the host ID is 0x04, and the rest of the sending parameters are the same.

Take SET_DKEK as an example. The length of the sent message is 41，that is,

xfer->xfer_buf[0~40]={0x03,0x90,0x0c,0x00,0x02,0x00,0x00,0x00,0x00,0x05,0x05,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,

0x00,0x00,0x00,0x00,0x04,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x3d,0x01,0x3d,0x01,0x00}.

The response message is,

xfer->xfer_buf[0~7]={0x03,0x90,0x0c,0x00,0x00,0x00,0x00,0x00}.

What might be wrong with this?

The main part of SET_DKEK function is:

/* in the ti_sci.h */

#define TI_SCI_MSG_SA2UL_SET_DKEK 0x9003

struct ti_sci_msg_req_sa2ul_set_dkek {

#define KDF_LABEL_AND_CONTEXT_LEN_MAX 30

struct ti_sci_msg_hdr hdr;

u8 sa2ul_instance;

u8 kdf_label_len;

u8 kdf_context_len;

u8 kdf_label_and_context[KDF_LABEL_AND_CONTEXT_LEN_MAX];

}__unpacked

struct ti_sci_msg_resp_sa2ul_set_dkek {

struct ti_sci_msg_hdr hdr;

}__unpacked

/* in the ti_sci.c */

struct ti_sci_msg_req_sa2ul_set_dkek *req;

struct ti_sci_msg_resp_sa2ul_set_dkek *resp;

xfer= ti_sci_get_one_xfer(info,TI_SCI_MSG_SA2UL_SET_DKEK,

TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,

sizeof(*req),sizeof(*resp));

req=(struct ti_sci_msg_req_sa2ul_set_dkek *)xfer->xfer_buf;

req->sa2ul_instance=0;

req->kdf_label=10;

req->kdf_context_len=10;

ret=ti_sci_do_xfer(info,xfer);

resp=(struct ti_sci_msg_resp_sa2ul_set_dkek *)xfer->xfer_buf;

if(!ti_sci_is_response_ack(resp))

ret=-ENODEV;

}

over 4 years ago

0 Piyali Goswami over 4 years ago

TI__Mastermind 30245 points

Dear Yongjin Ma,

First thing would be to check is the board configuration for security. Can you please confirm that you are using HOST_ID_ALL or 2 entries for A72 and R5F host Ids you are using in the dkek configuration?

Refer: https://git.ti.com/cgit/k3-image-gen/k3-image-gen/tree/soc/j721e/evm/sec-cfg.c#n76

Second thing to check would be are you running the R5F and the A72 together simultaneously? The DKEK is generated once and the internal status is set to DKEK_SET, The API will not try to set the DKEK again in that state.

I will also in parallel check with my colleague if there are any known limitations for DKEK access via A72 non secure access.

Thanks and Regards

Piyali

0 yongjin ma over 4 years ago in reply to Piyali Goswami

Prodigy 240 points

Hi Piyali,

First, I am using HOST_ID_ALL。

Second, I am not running the R5F and the A72 together simultaneously.

Third, TISCI_MSG_GET_SOC_UID interface has the same problem. Do all security management interfaces have this problem?

Thanks

Yongjin Ma

0 Venkat Mandela over 4 years ago in reply to yongjin ma

TI__Expert 5960 points

Hi,

Most of the security messages except for firewall and boot are expected to be sent from a secure host. This restriction is in addition to the host ID restrictions specified by board configuration. Let me discuss internally if we should remove the secure host restriction.

TISCI_MSG_GET_SOC_UID - There should not be any restriction on the sender of this message. This is a bug and we will fix it in the next release.

regards,

Venkat

0 yongjin ma over 4 years ago in reply to Venkat Mandela

Prodigy 240 points

Hi Venkat,

Thank you for your feedback. Add that according to our usage, TISCI_MSG_PROC_AUTH_BOOT in the BOOT interface also has this problem. In addition, in which document does the HOST restriction you talk about are explained?

regards,

jimmy

0 Piyali Goswami over 4 years ago in reply to yongjin ma

TI__Mastermind 30245 points

Hello Yongjin

The details regarding whether the message is secure or non secure is highlighted in the documentation:

http://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/index.html

Here with each message a "Secure Queue Only?" information is added which highlights whether this message can be sent by a secure host only or a non secure host as well.

Looking at the source code I have summarized the status of each security message below:

Message	Non Secure	Secure
TISCI_MSG_SET_FWL_REGION	Yes	Yes
TISCI_MSG_GET_FWL_REGION	Yes	Yes
TISCI_MSG_CHANGE_FWL_OWNER	Yes	Yes
TISCI_MSG_SA2UL_SET_DKEK	No	Yes
TISCI_MSG_SA2UL_RELEASE_DKEK	No	Yes
TISCI_MSG_GET_SOC_UID	No	Yes
TISCI_MSG_READ_OTP_MMR	No	Yes
TISCI_MSG_WRITE_OTP_ROW	No	Yes
TISCI_MSG_LOCK_OTP_ROW	No	Yes
TISCI_MSG_SOFT_LOCK_OTP_WRITE_GLOBAL	No	Yes
TISCI_MSG_GET_OTP_ROW_LOCK_STATUS	No	Yes
TISCI_MSG_SA2UL_GET_DKEK	No	Yes
TISCI_MSG_PROC_REQUEST	Yes	Yes
TISCI_MSG_PROC_RELEASE	Yes	Yes
TISCI_MSG_PROC_HANDOVER	Yes	Yes
TISCI_MSG_PROC_SET_CONFIG	Yes	Yes
TISCI_MSG_PROC_SET_CONTROL	Yes	Yes
TISCI_MSG_PROC_GET_STATUS	Yes	Yes
TISCI_MSG_PROC_WAIT_STATUS	Yes	Yes
TISCI_MSG_PROC_AUTH_BOOT	Yes	Yes

For the observation regarding TISCI_MSG_PROC_AUTH_BOOT, you should see the API passing with non-secure hosts as well.

Regards

Piyali

0 yongjin ma over 4 years ago in reply to Piyali Goswami

Prodigy 240 points

I used the website you mentioned to check whether the TISCI interface only supports secure host, but it is completely different from the listed table. For example, TISCI_MSG_SA2UL_SET_DKEK does not only support secure queues, but your list shows that only secure hosts are supported.

In addition, the Linux/VxWroks system started by TDA4 runs on A72_2 by default, and the host ID is 12. Can I configure it to run on a secure host?

0 Piyali Goswami over 4 years ago in reply to yongjin ma

TI__Mastermind 30245 points

"I used the website you mentioned to check whether the TISCI interface only supports secure host, but it is completely different from the listed table. For example, TISCI_MSG_SA2UL_SET_DKEK does not only support secure queues, but your list shows that only secure hosts are supported."

Yes. This is a bug which we have filed on the documentation to match with the implementation. Please refer to my table above till the documentation gets fixed.

Host ID 12 is non-secure by default. What you are looking for is how this API can be called from a non-secure Host. I am discussing with my colleagues if there is a specific reason we see the SET_DKEK to secure only. If we enable the TISCI to support non-secure on this API, then your problems will be easily resolved. I will get back to you with an answer if this is possible or not by the end of this week.

Regards

Piyali

0 Piyali Goswami over 4 years ago in reply to Piyali Goswami

TI__Mastermind 30245 points

Dear Yongjin Ma

I checked with the team here. The current plan is to have the SET_DKEK to secure Only. The team will evaluate the security implications to allow non-secure hosts to send the SET_DKEK and if feasible will add it as a roadmap item.

Regards

Piyali

0 yongjin ma over 4 years ago in reply to Piyali Goswami

Prodigy 240 points

Do you mean that except for SET_DKEK, all TISCI interfaces can be accessed through non-secure hosts, and SET_DKEK is under evaluation.

0 Piyali Goswami over 4 years ago in reply to yongjin ma

TI__Mastermind 30245 points

Dear Yongjin ma,

The APIs which can be supported by non-secure hosts is as per the table I had posted earlier.

Thanks and Regards

Piyali

Processors

Processors forum

TDA4VM: Using derived KEK on HS devices by TISCI