Multicore embedded systems employ a big.LITTLE architecture to combine different cores into a single microcontroller (MCU). However, resources sharing among cores raises security challenges. Once LITTLE cores (which often receive external inputs) are compromised, the whole system will be affected. Existing hardware-assisted isolation approaches use privilege separation and code instrumentation to enforce memory isolation, which suffer from inefficiencies. This paper presentsuBOX, a lightweight sandbox for multicore embedded systems. The goal ofuBOXis to enforce memory isolation over untrusted software (on LITTLE cores) at the same privileged level. Specifically, it uses the Memory Protection Unit (MPU) to restrict memory access by untrusted software. To protect sandbox policies,uBOXdeprives the write capability of untrusted software towards MPU configurations by replacing its regular store instructions with unprivileged counterparts. Additionally, to protectuBOX's necessary regular store instructions from being abused,uBOX's memory is set to read-only and non-executable when running untrusted software. For the normal operation ofuBOX, we use an overlooked feature of the MPU and develop secure gates that quickly disable and re-enable the MPU, allowinguBOXto execute at a permissive memory view. Our evaluation demonstrates thatuBOXeffectively enforces isolation with average 1.27% runtime overhead, 0.83X Flash overhead, and 36.50X SRAM overhead.

Manual confirmation of static analysis reports is a daunting task. This is due to both the large number of warnings and the high density of false positives among them. Fuzzing techniques have been proposed to verify static analysis warnings. However, a major limitation is that fuzzing the whole project to reach all static analysis warnings is not feasible. This can take several days and exponential machine time to increase code coverage linearly.

Memory leak bugs are a major problem in C/C++ programs. They occur when memory objects are not deallocated. Developers need to manually deallocate these objects to prevent memory leaks. As such, several techniques have been proposed to automatically fix memory leaks. Although proposed approaches have merit in automatically fixing memory leaks, they present limitations. Static-based approaches attempt to trace the complete semantics of memory object across all paths. However, they have scalability-related challenges when the target program has a large number of paths (path explosion). On the other hand, dynamic approaches can spell out precise semantics of memory object only on a single execution path (it does not consider multiple execution paths). In this paper, we complement prior approaches by designing and implementing a novel framework namedAddressWatcher. AddressWatcher allows the semantics of a memory object to be tracked on multiple execution paths. Addresswatcher accomplishes this by using a leak database that allows one to store and compare different execution paths of a leak over several test cases. Also, AddressWatcher performs lightweight instrumentation during compile time that is utilized during the program execution to watch and track memory leak read/writes. We conduct an evaluation of AddressWatcher over five popular packages, namely binutils, openssh, tmux, openssl and git. In 23 out of 50 real-world memory leak bugs, AddressWatcher correctly points to a free location to fix memory leaks. Finally, we submit 25 Pull Requests across 12 popular OSS repositories using AddressWatcher suggestions. Among these, 21 were merged leading to 5 open issues being addressed. In fact, our critical fix prompted a new version release for the calc repository, a program used to find large primes. Furthermore, our contributions through these PRs sparked intense discussions and appreciation in various repositories such as coturn, h2o, and radare2.