By Shin Li (Staff Threat Researcher, Automotive)
The automotive industry stands on the brink of another technological revolution as generative AI (GenAI) begins to make its way into vehicles. By enabling more powerful voice assistants and improving safety through better driver focus, GenAI promises to redefine the driving experience.
Semiconductor leaders like Qualcomm are driving this transformation forward. Qualcomm recently announced plans to integrate its next-generation Oryon processor into in-car computer systems, enhancing both entertainment and automated driving capabilities. Already featured in computers and soon to debut in high-end smartphones, this processor delivers immense computing power that will significantly elevate in-vehicle technology.
As such advancements unfold, it’s crucial to explore the core technology behind GenAI — and the potential security trade-offs that come with it.
Qualcomm’s Hexagon DSP: Powering the AI revolution
At the core of these groundbreaking advancements lies Qualcomm’s Hexagon DSP (digital signal processor) family. Traditionally designed to offload signal processing tasks from the CPU, Hexagon DSPs have long reduced power consumption in devices like smartphones. As AI applications have grown, Qualcomm has adapted the Hexagon architecture to meet increasingly complex demands.
The Hexagon DSP operates within an asynchronous multicore processor featuring a heterogeneous architecture. Initially built as a simple streaming engine, it has since evolved with the addition of a robust VLIW scalar engine and a vector engine. To address the growing requirements of AI and deep learning, Qualcomm further enhanced it with tensor and matrix engines, significantly boosting capabilities for tasks like model training and inference.
This evolution equips the Hexagon DSP to handle complex computations with exceptional efficiency, making it an ideal solution for AI workloads in automotive applications. By integrating scalar, vector, and tensor processing capabilities, the DSP can tackle a range of tasks, from audio playback and image processing to machine learning, all while adhering to the stringent power constraints of automotive systems.
Qualcomm emphasizes the benefits of this approach in its white paper on generative AI, stating that “heterogeneous computing maximizes application performance, thermal efficiency, and battery life to enable new and enhanced generative AI experiences.” For automakers, this means the ability to deliver cutting-edge AI features without sacrificing performance or power efficiency — by seamlessly allocating tasks to the most suitable processor, be it CPU, GPU, or NPU (neural processing unit) like the Hexagon DSP.
Bridging the gap between applications and accelerators
Offloading intensive tasks to specialized accelerators like DSPs can significantly enhance performance in automotive applications. However, this process involves complex communication and synchronization between systems. Qualcomm’s FastRPC framework addresses this challenge by enabling developers to call DSP functions as if they were local, effectively bridging the gap between applications and accelerators. By abstracting the intricacies of inter-processor communication and auto-generating the necessary code through an interface description language (IDL), FastRPC simplifies development and minimizes errors. As a result, tasks like image processing and machine learning inference can be seamlessly offloaded to the DSP.
Qualcomm’s Hexagon SDK provides practical examples of app development with FastRPC, illustrating how complex computations can be effortlessly integrated into applications. By eliminating typical hurdles, FastRPC empowers developers to harness the DSP’s full capabilities, paving the way for smarter, more responsive, and energy-efficient vehicles.
Here’s how FastRPC works:
- Application calls stub function: The client application on the CPU invokes a function stub corresponding to the desired DSP function.
- Stub packages the call: The stub code converts the function call into an RPC message, handling parameter passing and data marshaling.
- Message sent to DSP: The FastRPC framework on the CPU sends the RPC message to the DSP via a high-speed communication channel.
- DSP receives and dispatches call: The DSP’s FastRPC framework receives the message and dispatches it to the appropriate skeleton code.
- Skeleton unpacks and executes function: The skeleton code on the DSP unmarshals the parameters and calls the actual DSP function implementation.
- Result packaged and returned: Upon completion, the skeleton code packages the result and any output parameters into a return message.
- Result sent back to CPU: The DSP’s FastRPC framework sends the return message back to the CPU’s FastRPC framework.
- Stub receives result: The stub code on the CPU unmarshals the return message and delivers the result to the application as if it were a local function call.
By seamlessly handling these steps, FastRPC efficiently offloads tasks to the DSP without burdening developers with underlying complexities. This streamlined process is instrumental in advancing automotive technologies, leading to vehicles that are not only smarter and more responsive but also more energy-efficient.
Security considerations: The Hexagon DSP under scrutiny
While it unlocks transformative opportunities to the automotive industry, the integration of GenAI and advanced processors like Qualcomm’s Hexagon DSP also raises critical security concerns that demand attention. Research by cybersecurity experts, including findings presented at Recon Montreal 2019 and further investigations by the Check Point in 2020, has highlighted potential vulnerabilities within the Hexagon DSP architecture. These vulnerabilities underscore the urgent need for robust security measures as the automotive industry adopts more complex and interconnected technologies.
Understanding the Hexagon DSP and QuRT OS
The Hexagon DSP runs its own real-time operating system (RTOS): QuRT, a proprietary multi-threaded RTOS trusted by Qualcomm’s secure executable environment (QSEE). QuRT manages the DSP’s operations and facilitates the creation of separate processes for each Android application initiating remote invocation. Special shell processes, such as /vendor/dsp/fastrpc_shell_0 for the application DSP (aDSP), are loaded when a user process is spawned. These shell processes handle the invocation of skeleton and object libraries, and implement the FastRPC framework’s API required by these libraries.
The DSP's software architecture incorporates different protection domains (PDs) to ensure system stability:
- The Kernel PD has access to all memory regions and system resources.
- The Guest OS PD can access its own memory, the user PD's memory, and certain system registers.
- The User PD is restricted to its own memory space.
Unsigned dynamic shared objects run inside the unsigned PD (user PD), designed for general computing applications. These objects have limited access to the underlying DSP drivers and thread priorities, ensuring that sensitive system resources remain protected.
Exploiting FastRPC and skeleton libraries
FastRPC facilitates efficient communication between the application processor and the DSP, but improper security measures can turn it into a vector for attacks. Key libraries, such as libadsprpc.so and libcdsprpc.so, manage communication with DSP RPC drivers and provide functions like remote_handle_open and remote_handle_invoke. These functions enable clients to execute DSP methods implemented in skeleton libraries, potentially bypassing security controls.
An attacker could exploit this through the following methods:
- Direct invocation of DSP methods: An attacker with knowledge of a method index can craft arguments in the required structure and directly invoke DSP functions without proper validation.
- Stub code bypass: Skipping the auto-generated stub code might allow malicious inputs to pass unchecked into the skeleton libraries.
- Downgrading vulnerabilities: Loading outdated versions of skeleton libraries with known vulnerabilities can effectively circumvent recent security patches.
The absence of robust version control and validation for loaded skeleton libraries further exacerbates the risk. A malicious application could exploit this weakness to introduce vulnerable or malicious code into the DSP environment, compromising the system’s integrity and exposing it to threats.
Bugs in automatically generated code
The Hexagon SDK, which supports application development for the DSP, has been found to generate code with inherent vulnerabilities. These issues introduce risks across Qualcomm’s libraries and those developed by automotive manufacturers (OEMs) and third-party developers utilizing the SDK. Key vulnerabilities include:
- Improper string handling: Functions responsible for marshaling string arguments might fail to validate input lengths correctly. This oversight can lead to buffer overflows or memory corruption, creating opportunities for exploitation.
- Inadequate buffer management: Input and output buffer management functions might not thoroughly check the size or type of data being handled, enabling attackers to manipulate memory and potentially compromise system stability.
These vulnerabilities underscore the critical need for rigorous code reviews and robust validation processes in both Qualcomm’s development tools and third-party implementations to ensure secure and reliable DSP operations.
Implications for automotive systems
In automotive applications, these security vulnerabilities carry significant risks:
- System integrity risks: Exploiting DSP vulnerabilities could enable unauthorized code execution, jeopardizing the integrity of critical vehicle systems, such as braking, steering, or autonomous driving controls.
- Data privacy concerns: The DSP often handles sensitive data, including audio and visual inputs from vehicle sensors. Unauthorized access to this data could result in serious privacy breaches or misuse of personal information.
- Denial-of-service (DoS) attacks: An attacker could induce a DSP kernel panic, leading to system reboots or the disabling of essential functions. Such disruptions pose a heightened risk when the vehicle is in motion, potentially endangering drivers, passengers, and others on the road.
These implications highlight the urgent need for robust security frameworks in DSP-based automotive systems to safeguard both vehicle functionality and user safety.
Addressing security challenges
Mitigating the security risks associated with DSP vulnerabilities requires a comprehensive, multilayered strategy:
- Enhanced security measures: Strict version control, code signing, and validation checks for all DSP libraries and components should be enforced to prevent unauthorized code execution.
- Secure coding practices: Developers should adhere to rigorous coding standards, including thorough input validation, proper memory management, and the use of secure development frameworks.
- Regular updates and patches: Establishing protocols for timely updates to address discovered vulnerabilities is essential, encompassing both software patches and firmware updates for the DSP.
- Industry collaboration: Automakers, technology providers, and security experts must work together to proactively identify vulnerabilities and develop robust security frameworks.
Qualcomm has acknowledged the concerns and, in response to the findings, assigned several CVEs (Common Vulnerabilities and Exposures) to the disclosed DSP vulnerabilities and issued patches through security updates.
The path forward
The future of automotive innovation depends on fully leveraging heterogeneous computing architectures to meet the growing demands of Generative AI (GenAI). These architectures, which balance the strengths of CPUs, GPUs, and NPUs like Qualcomm’s Hexagon DSP, are essential for managing diverse workloads efficiently.
For instance, tasks requiring immediate responses, such as smaller AI models, are well-suited to CPUs, while larger, more complex models benefit from the parallel processing power of GPUs and NPUs. Continuous applications, like background monitoring or real-time sensor analysis, demand energy-efficient solutions, where NPUs excel in delivering high performance with minimal power consumption.
Beyond processing power, GenAI’s integration into vehicles must prioritize user experience. From adaptive driving assistance to personalized entertainment, the technology’s potential lies in creating seamless, intuitive systems for drivers and passengers. Achieving this requires close collaboration among automakers, technology providers, and developers to align AI models with the most suitable processors, ensuring optimal performance and efficiency.
Conclusion
As AI models continue to evolve and the demand for multimodal inputs grows, reliance on heterogeneous computing architectures will become increasingly critical. Future vehicles will likely need to run multiple AI models simultaneously, all in real time. This complexity highlights the need for optimized system design, efficient memory access patterns, and streamlined data movement within the vehicle’s computing architecture. By minimizing memory transfers and keeping data on-chip whenever possible, these systems can achieve higher performance and energy efficiency.
Qualcomm’s Hexagon DSP is pivotal in this transformation, delivering the computational power required to enable advanced features without compromising efficiency or performance. Its evolution mirrors the automotive industry’s commitment to innovation and underscores the strategic importance of heterogeneous computing.
However, innovation must be balanced with responsibility. As automakers explore these possibilities, they must also prioritize security to protect both drivers and passengers. By harnessing the full spectrum of processors within vehicles and fostering collaboration across industries, automakers are poised to redefine the driving experience. The car of the future is no longer just a mode of transportation — it’s becoming an intelligent companion and assistant on the road.
