Meltdown, Spectre, and why hardware can be correct yet insecure

The recent Meltdown and Spectre attacks have exposed, or at least emphasized, a fundamental problem with the conventional approach to computer security at the hardware level. Both of these attacks rely on side channels in conventional processor designs. By exploiting these side channels, an untrusted program can learn the contents of the operating system kernel's memory or … Continue reading Meltdown, Spectre, and why hardware can be correct yet insecure

Deserialization considered harmful: the security case for persistent objects

I've done a fair amount of work on persistent object systems, starting with the Thor distributed storage system and more recently, the Fabric system. I used to think the point of persistent object systems was to make programming easier. Lately I think security might be an even stronger argument. For programmers, the great thing about persistent … Continue reading Deserialization considered harmful: the security case for persistent objects

Why Good Programmers are Master Architects, Negotiators, Gardeners, and Detectives

Good Programmers are Master Architects Good programmers understand that they are building a complex structure with layers stacked upon other layers. They think critically about their design, and they know they need a strong, reliable foundation to support their work. Since their systems have many interdependent parts, they design carefully to limit these dependencies so that failures and … Continue reading Why Good Programmers are Master Architects, Negotiators, Gardeners, and Detectives

Deterrence

Nice article about how deterrence cannot work for computer security at Slate. The real problem is that computing systems are generally vulnerable to attack. This is not an inevitable state of affairs, but currently no one knows how to build secure, usable systems in a cost-effective way. It is not merely an engineering problem; it … Continue reading Deterrence