940, Rigorous, p4:
Microsoft estimates that 70% of the vulnerabilities they have patched between 2006 and 2018 are caused by memory safety issues[2].
MITRE considers classic buffer overflows as the third most dangerous software error[3].
ISA v5, p14:
Dramatic changes in threat models, resulting from ubiquitous connectivity and pervasive uses of computer technology in many diverse and widely used applications such as wireless mobile devices, automobiles, and critical infrastructure.
An extended “arm race” of inevitable vulnerabilities and novel new attack mechanisms has led to a cycle of “patch and pray”. … a strong need for underlying architectures that offer stronger inherent immunity to attackers, minimize gained attack surfaces, and increase the work factor for attackers.
New opportunities for research into (and possible revisions of) hardware-software interfaces, brought about by programmable hardware (especially FPGA soft cores) and complete open-source software stacks such as FreeBSD and LLVM.
An increasing trend towards exposing inherent hardware parallelism through virtual machines and explicit software multi-programming, and an increasing awareness of information flow for reasons of power and performance that may align well with the requirements of security. what is this mean, examples?
Emerging advances in programming languages, such as the ability to map language structures into protection parameters to more easily express and implement various policies. what is this? examples?
–> Map language structures into protectin parameters?
Reaching the tail end of a “compatibility at all costs” trend in CPU design, due to proximity to physical limits on clock rates and trends towards heterogeneous and distributed computing. While “Wintel” remains entrenched on the desktop, mobile systems – such as phones and tablet PCs, as well as appliances and embedded devices – are much more divers, running on a wide variety of instruction set architectures (especially ARM and MIPS).
Likewise, new diversity in operating systems has arisen, in which commercial products such as Apple’s iOS and Google’s Android extend open-source systems such as FreeBSD, Mach, and Linux. These new platforms abandon many traditional constraints, requiring that rewritten applications conform to new security models, programming languages, hardware architectures, and user-input modalities.
Development of hybrid capability-system models, such as Capsicum, that integrate capability-system design tenets into current operating-system and language designs. With CHERI, we are transposing this design philosophy into the instruction-set architecture. Hybrid design is a key differentiator from prior capability-system processor designs that have typically required ground-up software-architecture redesign and reimplementation.
Significant changes in the combination of hardware, software, and formal methods to enhance assurance now make possible the development of trustworthy system architectures that previously were simply too far ahead of their times.
Client-server and cloud computing:
even thin clients are not thin in most practical senses: as with client-server computer systems, they built from commodity operating system kernels, hundreds of user-space libraries, window servers, language runtime environments, and web browsers, which themselves include scripting language interpreters, virtual machines, and rendering engines.
Both server and embedded systems likewise depends on complex (and quite similar) software stacks. All require confluence of competing interests, representing multiple site, tasks, and end users in unified computing environments.
Whereas higher-layer applications are able to run on top of type-safe or constrained execution environments, such as JavaScript interpreters, lower layers of the system must provide the link to actual execution on hardware. As a result, almost all such systems are written in the C programming language; collectively, this Trusted Computing Base (TCB) consists of many tens of millions of lines of trusted (but not trustworthy) C and C++ code. Coarse hardware, OS, and language security models mean that much of this code is security sensitive: a single flaw, such as an errant NULL pointer dereference in the kernel, can expose all rights held by users of a system to an attacker or to malware.
Even if low-level escalation techniques (such as arbitrary code injection and code reuse attacks) could be prevented, logical erros and supply-chain attacks will necessarily persist.
.. compartmentalizing applications into components executed in isolated sandboxes can mitigate exploited vulnerabilities (sometimes referred to as privilege separation).
Historically, compartmentalization of TCB components such as operating system kernels and central system services has caused significant difficulty for software developers – which limits its applicability for large-scale, real-world applications, and leads to the abandonment of promissing research such as 1990s microkernel projects.
A recent resurgence of compartmentalization, applied in userspace to applications such as OpenSSH and Chromium, and more recently in our own Capsicum project, has been motivated by a critical security need; however, it has seen success only at very coarse separation granularity due to the challenges involved.
Domain switching results in TLB overflowing, especially with large page table sizes.
The TLB footprint of fine-grained, compartmentalized software increases with the product of in-flight security domains and objects due to TLB aliasing.
Intra address space communication: pass a pointer; Inter address space communication:
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?