This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: Using derived KEK on HS devices by TISCI

Part Number: TDA4VM

We are currently doing TISCI interface testing through TDA4 / XJ721E SOC HS equipment. Since the current SDK 7.0 TISCI driver does not provide DKEK and other security management APIs, we try to develop DKEK and other APIs such as TISCI_MSG_SA2UL_SET_DKEK, TISCI_MSG_SA2UL_GET_DKEK, etc. through existing interfaces. However, these interfaces cannot receive ACK, that is, ti_sci_is_response_ack() return false. What other operations do HS devices need to do to enable DKEK and other security management interfaces.
In addition, TISCI has secure transmission and non-secure transmission, while the TISCI driver of Linux only supports non-secure transmission. Compared with the non-secure transmission, does the secure transmission only have more security headers, and when will the secure transmission interface be opened? The tisci driver of U-boot supports secure transmission, but the checksum=0 and reserved=0 of the secure transmission header. Does the HS board check chesum currently?

  • Hi Yongjin

    The TISCI message for Security does not check for the values of the integ_check. The APIs are supported in 7.0. Can you please share the details of what message you are sending? What are the parameters and are you sending this on a secure queue or a non secure queue?

    Thanks and Regards

    Piyali

  • The documents I refer to are: http://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/dkek_management.html#  and  http://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/dkek_management.html.

    According to my understanding, currently in SDK 7.0, Does the linux kernel only support non-secure queues?. In addition, how are secure and non-secure queues implemented? What is the difference between the secure queue and the non-secure queue in addition to increasing a secure header? 

    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 other words, I received a reply, but the ACK bit of the flag was not set. 
    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;

    }

  • Hi Yongjin,

    Can you please tell us if this issue is actually resolved or you resolved it by mistake?

    - Keerthy

  • This issue was not resolved, but because I have not received a reply, I closed this issue. Then I summarized the situation encountered and asked the same question. The link is:https://e2e.ti.com/support/processors/f/791/t/951904. I very much hope to receive a response, which has been going on for a while.