No-FAT: Architectural Support for Low Overhead Memory Safety Checks

Ziad, Mohamed Tarek Ibn; Arroyo, Mônica; Manzhosov, Evgeny; Piersma, Ryan; Sethumadhavan, Simha

doi:10.1109/isca52012.2021.00076

Cited by 11 publications

(8 citation statements)

References 44 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, Intel claims that MPX has been deprecated and both GCC and Linux kernel no longer support Intel MPX. The method of No-FAT [50] indexing metadata is similar to LowFat in that it uses the pointer itself to compute the object's base address and thus check if memory accesses are out of bounds. The difference with LowFat is that No-Fat's base address calculation and memory access checking are implemented in hardware.…”

Section: Hardware Expansionsmentioning

confidence: 99%

PACSan: Enforcing Memory Safety Based on ARM PA

Li¹,

Tan²,

Lv³

et al. 2022

Preprint

View full text Add to dashboard Cite

Memory safety is a key security property that stops memory corruption vulnerabilities. Existing sanitizers enforce checks and catch such bugs during development and testing. However, they either provide partial memory safety or have overwhelmingly high performance overheads.Our novel sanitizer PACSan enforces spatial and temporal memory safety with no false positives at low performance overheads. PACSan removes the majority of the overheads involved in pointer tracking by sealing metadata in pointers through ARM PA (Pointer Authentication), and performing the memory safety checks when pointers are dereferenced.We have developed a prototype of PACSan and systematically evaluated its security and performance on the Magma, Juliet, Nginx, and SPEC CPU2017 test suites, respectively. In our evaluation, PACSan shows no false positives together with negligible false negatives, while introducing stronger security guarantees and lower performance overheads than state-of-the-art sanitizers, including HWASan, ASan, Soft-Bound+CETS, Memcheck, LowFat, and PTAuth. Specifically, PACSan has 0.84× runtime overhead and 1.92× memory overhead on average. Compared to the widely deployed ASan, PACSan has no false positives and much fewer false negatives, and reduces 7.172% runtime overheads and 89.063% memory overheads.

show abstract

Section: Hardware Expansionsmentioning

confidence: 99%

PACSan: Enforcing Memory Safety Based on ARM PA

Li¹,

Tan²,

Lv³

et al. 2022

Preprint

View full text Add to dashboard Cite

show abstract

“…Workload Dependent-Runtime security overheads are highly sensitive to the types of applications being run. Even security defenses benchmarked on the same system can ex-hibit wildly different overheads depending on the exact benchmark or workload: For example, a recent runtime memory safety defense, which reports a geometric mean runtime overhead of 8%, demonstrates a 62% overhead on the gcc SPEC 2017 benchmark and a 0% overhead for others [28]. For some users and some systems, the use of such a defense may cause only negligible slowdowns whereas other users (perhaps programmers who rely heavily on gcc) will be heavily burdened.…”

Section: Measuring In Situ Performance Overheadsmentioning

confidence: 99%

“…We chose to use SPEC 2017 benchmark programs as our exemplar programs. Two security defenses in particular were considered: 1) Binary hardening flags (specifically -fPIE -pie -D_FORTIFY_SOURCE=2 -fstack-protector-all -fsanitize=safe-stack -Wl,-z,relro,-z,now)which incur a small performance overhead), and 2) a recent runtime memory safety technique-which can incur a negligible to large performance overhead [28]. Both happen to be compiler techniques, but our approach is not limited to compiler-based defenses.…”

Section: Creating the Training Setmentioning

confidence: 99%

COMMAND: Certifiable Open Measurable Mandates

Hastings¹,

Piersma²,

Sethumadhavan³

2022

Preprint

Self Cite

View full text Add to dashboard Cite

Security mandates today are often in the form of checklists and are generally inflexible and slow to adapt to changing threats. This paper introduces an alternate approach called open mandates, which mandate that vendors must dedicate some amount of resources (e.g. system speed, energy, design cost, etc.) towards security but unlike checklist security does not prescribe specific controls that must be implemented. The goal of open mandates is to provide flexibility to vendors in implementing security controls that they see fit while requiring all vendors to commit to a certain level of security. In this paper, we first demonstrate the usefulness of open security mandates: for instance, we show that mandating 10% of resources towards security reduces defenders losses by 8% and forestalls attackers by 10%. We then show how open mandates can be implemented in practice. Specifically, we solve the problem of identifying a system's overhead due to security, a key problem towards making such an open mandate enforceable in practice. As examples we demonstrate our open mandate system-COMMAND-for two contemporary software hardening techniques and show that our methodology can predict security overheads to a very high degree of accuracy (< 1% mean and median error) with low resource requirements. We also present experiments that quantify, in terms of dollars, how much end users value the performance lost to security, which help determine the costs of such a program. Taken together-the usefulness of mandates, their enforceability, and their quantifiable costs-make the case for an alternate resource-based mandate.

show abstract

“…Buffer overflow detection tools [15,31,54,63] also exist, but their performance overhead is shown to be too high to be used at runtime. Various hardware-based memory safety mechanisms exist for CPUs [11,21,22,35,38,48,59,78], but no such mechanism exists for GPUs to the best of our knowledge. Any hardware mechanism should not increase memory traffic.…”

Section: Introductionmentioning

confidence: 99%

“…Also, the driver embeds the encrypted buffer ID in the unused upper bits of the buffer base address pointers. This pointer-tagging approach [21,22,35,38,78] is lightweight and efficient since it removes the need for bounds propagation and does not require any hardware changes.…”

Section: Introductionmentioning

confidence: 99%

Securing GPU via region-based bounds checking

Lee

Kim

Cao

et al. 2022

Proceedings of the 49th Annual International Symposium on Computer Architecture

View full text Add to dashboard Cite

Graphics processing units (GPUs) have become essential generalpurpose computing platforms to accelerate a wide range of workloads, such as deep learning, scientific, and high-performance computing (HPC) applications. However, recent memory corruption attacks, such as buffer overflow, exposed security vulnerabilities in GPUs. We demonstrate that out-of-bounds writes are reproducible on an Nvidia GPU, which can enable other security attacks.We propose GPUShield, a hardware-software cooperative regionbased bounds-checking mechanism, to improve GPU memory safety for global, local, and heap memory buffers. To achieve effective protection, we update the GPU driver to assign a random but unique ID to each buffer and local variable and store individual bounds information in the bounds table allocated in the global memory. The proposed hardware performs efficient bounds checking by indexing the bounds table with unique IDs. We further reduce the bounds-checking overhead by utilizing compile-time bounds analysis, workgroup/warp-level bounds checking, and GPU-specific address mode. Our performance evaluations show that GPUShield incurs little performance degradation across 88 CUDA benchmarks on the Nvidia GPU architecture and 17 OpenCL benchmarks on the Intel GPU architecture with a marginal hardware overhead. CCS CONCEPTS• Security and privacy → Vulnerability management.

show abstract

No-FAT: Architectural Support for Low Overhead Memory Safety Checks

Cited by 11 publications

References 44 publications

PACSan: Enforcing Memory Safety Based on ARM PA

PACSan: Enforcing Memory Safety Based on ARM PA

COMMAND: Certifiable Open Measurable Mandates

Securing GPU via region-based bounds checking

Contact Info

Product

Resources

About