MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture 2021
DOI: 10.1145/3466752.3480076
|View full text |Cite
|
Sign up to set email alerts
|

Cryptographic Capability Computing

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1

Citation Types

0
2
0

Year Published

2022
2022
2024
2024

Publication Types

Select...
4
2

Relationship

0
6

Authors

Journals

citations
Cited by 12 publications
(2 citation statements)
references
References 37 publications
0
2
0
Order By: Relevance
“…The worst-case, 531.deepsjeng_r benchmark exercises an alpha-beta tree search, suggesting that the overhead is caused by the frequent non-safe memory-accesses and pointer manipulations while traversing the tree. Comparing this to the estimated 7% tag-checking overhead reported by [15], suggests that the tag forgery prevention instrumentation is a not insignificant contributor to this overhead. We expect that the tag forgery prevention overhead can be lowered by optimizing it to avoid redundant tag checking.…”
Section: Resultsmentioning
confidence: 63%
See 1 more Smart Citation
“…The worst-case, 531.deepsjeng_r benchmark exercises an alpha-beta tree search, suggesting that the overhead is caused by the frequent non-safe memory-accesses and pointer manipulations while traversing the tree. Comparing this to the estimated 7% tag-checking overhead reported by [15], suggests that the tag forgery prevention instrumentation is a not insignificant contributor to this overhead. We expect that the tag forgery prevention overhead can be lowered by optimizing it to avoid redundant tag checking.…”
Section: Resultsmentioning
confidence: 63%
“…For example, use-after-free errors for heap allocations (or use-after-return for stack allocations) can be protected against by assigning random tags to newly allocated memory regions and clearing the tags on freeing memory [31]. Re-allocated memory will, with probability 15 16 , be assigned a different tag, which prevents access by any remaining dangling pointers. However, because the address tag is stored within the pointer itself, such solutions do not lend themselves for post-deployment run-time protection against an adversary that can overwrite pointers and their address tags.…”
Section: Armv85-a Memory Tagging Extensionmentioning
confidence: 99%