Best Practices for Secure and Reliable OAL
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/27/2008
The BSP code runs in a trusted environment that prevents the operating system (OS) from loading unknown modules and restricts access to system application programming interfaces (APIs).
Use the following best practices to enhance the security and reliability of your OAL:
- Review your BSP code and report error conditions appropriately to the caller.
For example, you should review the real-time clock (RTC) functions to ensure that bad SYSTEMTIME structures passed into OEMGetRealTime or OEMSetRealTime are handled appropriately. - Validate your input to make sure that you are only using valid data.
Be sure that the pointer provided as data input is not NULL. If you know what the data format should look like, be sure that you validate the data and do not use it if the format is wrong. - Validate the arguments for the IOCTLs to avoid implementing code in them that could potentially open your system to attack.
Always review your IOCTL code for security concerns. - Revise poorly written direct memory access (DMA) drivers that use or overuse the FlushDCache or OEMCacheRangeFlush functions. Overuse of these two functions in OEM calls or application calls can slow down the system.
- Properly implement the startup library so it does not call into the wrong code or invalid code.
For information on how to implement the StartUp** function, see Implementing the Boot Loader StartUp Function and OAL StartUp Function Implementation.** - Use __try/__except blocks for good coding practices.
- Test your images before releasing them.
- Remove code used only for development purposes from your final code or product.
For example, remove hidden entry points into OAL functions that were used to facilitate debugging. Also, remove debugging IOCTLs that give direct control to BSP or OS resources.
See Also
Concepts
Best Practices for Developing a Production-Quality OAL
Production-Quality OAL