Bibliographic record
Abstract
Hardware security extensions are engineered to enhance software security for various purposes such as memory protection, program execution environment isolation, among others. Nevertheless, due to constrained hardware resources and the intricate nature of security goals pertaining to diverse software applications, the practical utilization of these hardware features by software developers, may diverge from those original envisioned by the hardware designers. We examine the repurposed uses of hardware features within the field of operating system security, presenting three case studies. The first involves a light-weight memory protection system designed to guard against return-oriented programming attacks, repurposing the intended use of a memory protection hardware extension. The second case presents a suite of secure OSes aimed at bolstering application security on mobile platforms, broadening the scope of the original target audience of a mobile hardware security feature. Lastly, we discuss an attack method that augments other side-channel attacks enabling them to elude detection and mitigation by manipulating processor thermal control functionality. The adapted uses of these hardware features can lead to a variety of potential consequences. While some outcomes, such as improved efficiency or innovative defense mechanisms, may be beneficial, others could inadvertently introduce security vulnerabilities. Through an exhaustive analysis of these three case studies, we gleaned the following insights: (1) A flexible approach to the utilization of hardware security extensions for different security purposes can yield partial security, resulting in lower and more acceptable overhead. (2) To accommodate new application security requirements, the design of the operating system can be adapted to cater to a broader range of users. (3) Hardware features that initially seem irrelevant could effectively counter the assumptions made by software defence that rely on hardware security extensions. This thesis underscores the importance of hardware-software collaboration for achieving optimal operating system security. Through the scrutiny of three specific examples of repurposed hardware feature utilization, the study illuminates both the potential benefits and risks inherent to these interactions. Consequently, it advocates for a more holistic and cooperative approach to navigate the challenges and intricacies of current secure computing systems.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.003 | 0.001 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.000 |
| Bibliometrics | 0.001 | 0.004 |
| Science and technology studies | 0.001 | 0.000 |
| Scholarly communication | 0.002 | 0.000 |
| Open science | 0.002 | 0.001 |
| Research integrity | 0.001 | 0.002 |
| Insufficient payload (model declined to judge) | 0.000 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one teacher head, not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".