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.

RTOS/PROCESSOR-SDK-OMAPL138: Security questions for DSP/BIos, SYS/BIOS

Part Number: PROCESSOR-SDK-OMAPL138
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello
My customer is considering the OMAP-L138ZWT in an Avionics project requiring DO-178 certification and has a number of questions concerning DSP-BIOS (SYS-BIOS) that I hope you can help me answer :-

I am currently evaluating the COTS products that we use in our product in terms of security and one of these SW COTS items is the DSP/Bios Real-Time Operating System (www.ti.com/tool/dspbios) to which all of the following questions is concerned. These questions will help us justify the use of the DSP Bios and ultimately the Texas Instruments DSP in our products.

 

So to the questions:

  • Did you follow any official approach in developing this SW e.g. DO-178?
  • Is it possible for us to get access to your bug database with issues posted towards this SW?
  • Do Texas Instruments perform a security survey on this SW such as scanning the internet for vulnerabilities or an official process for posting new vulnerabilities?
    • Is it possible for Customers to either subscribe or get access to the result of such a survey?
    • Since the version we have currently implemented is not the newest version:
      • Is it possible to get the history of previous found vulnerabilities on this COTS?
      • Wen new vulnerabilities are found do you evaluate them against all versions of the COTS or only the latest binary?
  • Your website only allows download of this COTS using insecure HTTP without any secure hash to verify the integrity of the download.
    • Do Texas Instruments provide any alternative secure site to download this SW such as HTTPS, FTPS or SSH?
    • Is Texas Instruments able to provide us with a hash of the binary provided by an alternative source than the download server where the binary is downloaded from?
    • Does Texas provide an additional download server or other means from which a binary comparison would be possible?
  • In case Texas Instruments becomes aware of any security issues, does Texas Instruments have a process of handling these?
    • How is the evaluation process?
    • As a user of this SW binary, what is the patch delay that we could expect?
  • Since Customer does not have the source-code (and in the case we acquired the source code the licensing terms does not allow us to modify the source code) Customer relies of Texas Instruments for updates:
    • What is the expected maintenance/support period for this SW?
    • If Texas Instruments choose no longer to support/maintain this SW, is it possible for us to continue the maintenance ourelves?

 

Thank you in advance for taking the time to answer our questions.

Best Regards
Bob Bacon

  • Hi Bob,

    I've forwarded your query to the security and software experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Bob,

    Let me answer your question from the device perspective and I will let the TI RTOS team to comment on DSPBIOS support.

    The DSP BIOS and related  software for this pariticular device is currently not under development and is meant to be used "AS IS". For this device, we have moved the support to the TI RTOS baseline (SYSBIOS) and currently support new development using PRocessor SDK RTOS for OMAPL138. This extends the SYSBIOS support to ARM9 and C674x core on this device with set of serial, control and audio drivers. Check the release notes 

    In terms of security, this device supports a version of security which is referred to as Basic secure boot using a single encryption key and we offer no runtime security support in SYSBIOS kernel.  The documentation for the security offering is provided here:

    www.ti.com/.../SECDEVTOOL-OMAPL138C6748

    For advanced security, we would recommend looking K2G device that support standard secure boot with runtime secure kernel with TI RTOS.

    I have looped in the TI RTOS team to comment on state of the DSPBIOS kernel and questions related to its maintenance and support.

    Regards,

    Rahul

  • Bob,

    The best person to answer from the kernel's point of view is currently out. He'll return on Weds (or Thurs).

    Todd
  • Bob,

    Here are some answers:

    1. I concur with Rahul in that the customer shouldn't be using DSP/BIOS, but should be using SYSBIOS (also called TI-RTOS Kernel). This ships with source code included with no restrictions on modification and therefore should address the customer concerns being able to support the product. We generally support products indefinitely with some obvious caveats:

    a. The first option is always to move the customer to the latest release as that often contains fixes to existing problems and facilitates use of newer versions of associated development tools.

    b. Any patches to older versions of SW need very compelling reasons. We do rarely do these, but not even every year.

    If the customer has already used to DSP/BIOS and it's too late to change, we can license them the source code for the version they have used. We have done this with other avionics customers using DSP/BIOS in the past. However, I would strongly recommend they use SYS/BIOS.

    2. We generally don't provide access to our bug database. The release notes for each release of SYS/BIOS list all bugs that were fixed and any known issues.

    3. We have a defined SW development process but it is not DO-178B or any similar safety-critical standard. Our process currently lacks some of the steps these development flows have (e.g. formal requirements tracking, code coverage testing).

    4. The question about 'vulnerabilities' is not really applicable. SYS/BIOS (or DSP/BIOS) is not a large, complex operating systems like Windows. It will be about 30-60 KB of code with fairly minimal functionality that just helps schedule different tasks. SYS/BIOS does not included a networking stack. You should find out whether the customer plans to run Linux or SYS/BIOS on the ARM core and, if the latter, whether they need to use the associated TCP/IP stack. If they do, then there could be some issues about vulnerabilities in the TCP/IP stack.

    5. We can potentially make the SW available to the customer via drop-box or some other more secure method if needed. However I would stress that the nature of the SW and relatively small customer base make it extremely unlikely that someone would try to intercept it and replace it with a modified version.

    Nick Lethaby

  • Hi Nick, Rahul
    Thanks for your response, here's some feedback [BB] from my customer, could you help with additional information :-

    • Did you follow any official approach in developing this SW e.g. DO-178? No. The software was developed using internal TI processes that are missing some key elements compared to DO-178B/C.
    • Is it possible for us to get access to your bug database with issues posted towards this SW? No - TI does not allow external access to the database.
    • Do Texas Instruments perform a security survey on this SW such as scanning the internet for vulnerabilities or an official process for posting new vulnerabilities?
    [BB] Unanswered.

    • Is it possible for Customers to either subscribe or get access to the result of such a survey?
    [BB] Unanswered.

    • Since the version we have currently implemented is not the newest version:
    • Is it possible to get the history of previous found vulnerabilities on this COTS?
    [BB]Partly answered.

    Issues that are fixed are published as part of the release note together with known open issues.
    [BB] Security issues are not specifically addressed or marked. It is normal that companies does not always publish if vulnerabilities are fixed. So since TI is not explicitly open to the way security issues are handled makes me wonder if TI would ever publish this information.

    • Wen new vulnerabilities are found do you evaluate them against all versions of the COTS or only the latest binary? Unanswered.
    • Your website only allows download of this COTS using insecure HTTP without any secure hash to verify the integrity of the download. TI could provide an alternative solution if requested. Thank you.
    • Do Texas Instruments provide any alternative secure site to download this SW such as HTTPS, FTPS or SSH? See above. OK.
    • Is Texas Instruments able to provide us with a hash of the binary provided by an alternative source than the download server where the binary is downloaded from? See above. OK.
    • Does Texas provide an additional download server or other means from which a binary comparison would be possible? See above. OK.
    • In case Texas Instruments becomes aware of any security issues, does Texas Instruments have a process of handling these?
    [BB] Unanswered.

    • How is the evaluation process?
    [BB] Unanswered.

    • As a user of this SW binary, what is the patch delay that we could expect?
    [BB] Unanswered.

    • Since Customer does not have the source-code (and in the case we acquired the source code the licensing terms does not allow us to modify the source code) Customer relies of Texas Instruments for updates:
    • What is the expected maintenance/support period for this SW?
    [BB} Partly answered.

    Maintenance on DSP/BIOS is discontinued and TI suggests moving to SYS/BIOS.
    [BB] Does that also mean that if some issues occur and a fix is requested by a customer TI will not go back and fix this issue?

    • If Texas Instruments choose no longer to support/maintain this SW, is it possible for us to continue the maintenance ourselves?
    [BB] Partly answered.

    TI can licence us the source-code to DSP/BIOS in case it is too late to change to SYS/BIOS. What would be the cost of such licence? Under what licencing terms would we acquire this source-code?

    [BB] Moreover, Nick Lethaby states that questions to security of the SYS/BIOS or DSP/BIOS is not applicable because it is very simple. But even though the kernel does not implement any TCP/IP stack it still handles I/O which may be connected to untrusted interfaces. Based on this I still do not have any evidence that e.g. a buffer overflow could not exist at this level?

    Thanks
    Bob Bacon
  • Bob,

    We don't do any security evaluations of our SW. It doesn't make sense for our kernel. It would make sense for our TCP/IP stack.

    Nick