Security Accelerator questions on configuration

 Hi, RC:

Please keep in mind that all the unit tests are designed to verify the LLD specific operation. Even though they can be served as example codes, but, that is not its main purpose and it typical just shows one way to use the LLD and sub-system. Please refer to the LLD doxygen and user guide to undertand all APIs and their configuration parameters.

Please see my answers to your questions below: 

Hi Ti Folks,
                 based on reading the UG and examples again, i have arrived at following understanding, please clarify, I was able to resolve the following.

1. lets say i have N users, each USER will have his own CHANNEL [based on below statement in Ti Doc] obtained by calling Sa_chanGetBufferReq and Sa_chanCreate],so there will be N users with N channels. [Sa_chanGetBufferReq and Sa_chanCreate will be called N times by N users ??]

[Eric] There is no concept of users in the SA LLD. It is designed to handle multiple channels where each channel is defined by its configuration parameters.
          Each channel consists of tx path and rx path. Where tx means to-network (IPSEC/SRTP) or from-air traffic (Air Ciphering) and rx means from network (IPSEC/SRTP) or to-air (Air Ciphering) traffic. Therefore, each channel will require two security contexts, one for tx and one for rx.

It is not required to call Sa_chanGetBufferReq multiple times for the same type of channels. But, it does not hurt to call it multiple times.
Yes, Sa_chanCreate() should be called for each channel and it returns a channel handle which should be used to refer to this channel for subsequent API calls.

[For each of these protocols, the SA LLD channel interface allows the USER to create channels allowing the SA to perform encryption, decryption, and 
authentication operations. Each channel is differentiated through a separate channel identification value, which is specified by the USER]

2. for each USER based on his gen config [tx and rx] and key config [tx and rx], Sa_chanControl is called 4 times. so it will be 4*N calls to this Sa_chanControl API. please clarify?

[Eric] The Sa_chanControl() API should be called multiple times to supply all configuration parameters. The only requirement is that all the configuration parameters are supplied when the sa_CONTROLINFO_CTRL_TX_ON or sa_CONTROLINFO_CTRL_RX_ON bit is set. The recommended call sequences are as the follwoings:
- gen_config [tx and rx] which including key length parameters.
- key_congig [tx and rx]
- gen_config[ tx on/rx on] or gen_config[tx on] the gen_config[rx on]

Please note that the SA LLD will invoke the callout function ScAlloc() to get Security context ID and buffer from the application when the sa_CONTROLINFO_CTRL_TX_ON and/or sa_CONTROLINFO_CTRL_RX_ON  bit is set.

3. Is there any limit of number of channels that can be created. say i create only snow3g cipher/decipher [i reiterate only snow3g cipher/decipher] based channels [there by security contexts] for N users ofcourse
with different Enc and Mac Key [Enc+Mac Key combination per user]. Is that possible?

[Eric] No, as long as there are enough unique security conext ID (15-bit) and security context buffers. Please note there are two security contexts per channel.

4. All the below functions are application provided functions ??

static Sa_CallOutFuncs_t salldsim_calloutFunc = {
salldsimDebugInfo, /* Debug function pointer */
salldsimChanKeyRequest, /* Key Request function Pointer */
salldsimScAlloc, /* Security Context Allocation function pointer */
salldsimScFree, /* Security Context Free Function pointer */
salldsimChanRegister, /* Channel Registration Function pointer */
salldsimChanUnRegister, /* Channel UnRegister Function pointer */
salldsimChanSendNullPkt /* Channel Send Null Packet function pointer */
};

[Eric] Yes, the salldsimChanKeyRequest os only used in SRTP mode.

5. Wanted to know the following, correct my understanding of the Sa LLD flow [i am mainly worried about creating N security contexts for N Users]

5.a below funtions are called and when Sa_chanCreate,Sa_chanControl,
const Sa_ProtocolCallTbl_t* salld_callTblPtr[] =
{
&Sa_callTblStrp,
&Sa_callTblSrtcp,
&Sa_callTblIpsecAh,
&Sa_callTblIpsecEsp,
&Sa_callTblAc,
&Sa_callTblDataMode,
NULL
};

[Eric] No, not exactly. This is a table of protocol function tables. The SA LLD will perform protocol-specific opertaion through function table.

5.b either at Sa_chanCreate or Sa_chanControl, when callTblAc is called, then below APPLICATION SUPPLIED FUNCTIONS are created.

Sa_ProtocolCallTbl_t Sa_callTblAc =
{
sa_PT_3GPP_AC,
salld_ac_init,
salld_ac_control,
salld_ac_get_stats,
salld_ac_send_data,
salld_ac_receive_data,
salld_ac_close,
salld_ac_get_swInfo
};

[Eric]. No, that is static function table. the corresponding function will be called, not created.

Sa_chanCreate (Air Ciphering) will call salld_ac_init()
Sa_chanControl(Air Ciphering) will call salld_ac_control()
...

5.c

salld_ac_control calls its own share of APPLICATION provided functions [salld_ac_set_tx_sc] [salld_ac_set_rx_sc] which calls the below salldsim_calloutFunc

salld_ac_control -------------------------------->salldsim_calloutFunc
salld_ac_control -------------> salld_ac_set_tx_sc >------------------->salldsim_calloutFunc
salld_ac_control --------------> salld_ac_set_tx_sc >------------------>salldsim_calloutFunc

[Eric] Yes.
{based on Ti example comment [All the call-out functions should be implemented by the application and provided
to the SALLD at @ref Sa_create]}

[Eric] Yes, it should be provided at Sa_start() for mulriple core application as well.

/* Global SALLD call-out function table */
static Sa_CallOutFuncs_t salldsim_calloutFunc = {
salldsimDebugInfo, /* Debug function pointer */
salldsimChanKeyRequest, /* Key Request function Pointer */
salldsimScAlloc, /* Security Context Allocation function pointer */
salldsimScFree, /* Security Context Free Function pointer */
salldsimChanRegister, /* Channel Registration Function pointer */
salldsimChanUnRegister, /* Channel UnRegister Function pointer */
salldsimChanSendNullPkt /* Channel Send Null Packet function pointer */
};

salldsimScAlloc calls salld_sim_alloc_sc which picks next available SECURITY CONTEXT Memory from salldsimScBuf. This is the buffer which UG talks about in many sections...i mean salldsimScBuf
placement particulars and caching details. please correct?

[Eric] It is up to the application to mange the security context IDs and buffers. This is just a simple way to implement as a sample code. This method will not work at multiple core environment. The security context cache should be handled by the OSAL functions Sa_osalBeginScAccess() and Sa_osalEndScAccess().

5.d

lets say since per USER [there can be TX keyconfig and RX keyconfig, there can be 2 [salld_ac_set_tx_sc and salld_ac_set_rx_sc] security contexts and so per channel 4 place holders are given here ],
only 4 SECURITY CONTEXTS ARE allowed [ofcourse in this Ti given example], What is the idea behind the 4 contexts, can anyone please explain inner details of why 4.

pChan is pointer to a SECURITY CHANNEL of a USER X, and within that TX and RX security contexts can be possible, so 2 occupy the place holders out of 4 [please see below code]

======================================
/* Record the scID and ScBuf in the instance */
for (index = 0; index < 4; index++)
{
if(pChan->scInfo[index].scID == 0)
break;
}

if (index >= 4)
{
salld_sim_print("SALLD Channel %d: salldsimScAlloc failed due to lack of internal buffer\n!", chnum - 1);
salld_sim_free_sc(scReqInfo->scID);
scReqInfo->scBuf = NULL;
return;
}
pChan->scInfoIndex = index;
pChan->scInfo[index] = *scReqInfo;

is there any limit on number of SECURITY CONTEXTS per channel??
=========================================

[Eric]  There are two security contexts per IPSEC or Air Ciphering channels. There may be up to 4 security contexts per SRTP channel due to re-key operation.

6. 

User 1 Channel's Security contexts 

User 2 Channel's Security contexts 

According to Ti UG,....To use the caching mechanism efficiently as new security contexts are created, it is recommended to linearly increment the security context identification values.

but in the example the SCindex are jumping at 16 increments [16384,16400,16416,16432].

Why is this jump of 16, can it be explained detailedly? how is it going to affect caching mechanism, if there is a jump of 16..[my expectation is that it should be increments of 1.i am correct on this]..please explain?

[Eric] Yes, you are right.  The context ID should be incremented by one in general. In our example, we increment it by 16 to make them use the same cache line so that we can test SASS autonomous context cache evict operation with limited number of channels.. 

Thanks
RC Reddy

Hi, RC:

Please note that this is test code to verify the encryption and decryption operation in loopback mode. In other words, we need to decrypt the packet as in the UE.

Best regards,

Eric

'