The Price of [Software] Security

Rico Mariani
2 min readJan 25, 2018

[originally posted 4/19/2017 but even more interesting in the face Specter etc.]

What’s the price of security? When does it end? Are we paying it properly?

This has been a struggle for me since my first days in the CLR when I had to deal with large startup costs associated with getting Code Access Security bootstrapped. In those cases, we were able to make important changes that materially removed these costs. Which was great in my view because I didn’t think we were getting anything valuable from that stuff. Still… valuable or no, the cost/benefit was clear.

It’s much less clear these days.

Flagship products with big security concerns because of their surface area and exposure to basically arbitrary stimulation (Microsoft Edge, Chrome, Flash, pick a web-runtime) are prepared to go to extraordinary means to try to become secure. But is it working?

Look at Microsoft Edge, and Internet Explorer before it. It’s a crucial attack vector and so it makes sense to do a lot. And indeed because so much of Windows might run in the context of a browser it might make sense to extend important protections to all of Windows even it wouldn’t otherwise be prudent. Right now, Edge is protected by Control Flow Guard tech, which basically makes it impossible for any indirect jump to go to an arbitrary address. It’s also using Memory Protector, which guards against use after free. And it’s got a complex protective process model, too.

But what I don’t understand is, why are we still using regular native code gen at all in these products?

I used to hear that managed code had too many startup issues. Yeah, what a joke that is. Compared to the startup cost of the multi-process model broker business that is the low rights solution in use, the managed code startup costs are nothing. Garbage collection costs are also already built in — Memory Protector is a garbage collector, with less benefits. Write barriers? Bounds checks? Those things have a lower marginal cost than CFG, which we could jettison if wild pointers were impossible.

It seems to me that the present strategy involves doing everything possible to get security into a native stack while avoiding the actual root cause of the problem. Manual memory management is intractable given complex object graphs. The best programmers in the world can’t get it right. Memory pointer tricks inevitably backfire, the best programmers can’t get those right either. Type confusion bugs still sneak in. The best programmers can’t get it right.

Given the tech that has already been adopted in this space, it’s hard to make the argument that managed code costs too much. We’re paying a higher price for less protection already.
And yet we persist?

That’s my read of the tea leaves.

--

--

Rico Mariani

I’m an Architect at Microsoft; I specialize in software performance engineering and programming tools.