Memory safety [LWN.net]

Memory safety

Posted Jan 10, 2014 12:33 UTC (Fri) by HelloWorld (guest, #56129)
Parent article: Practical security for 2014

I think that in order to be secure, we desperately need memory safety for programs written in C. And there's a project which claims to achieve just that:
http://acg.cis.upenn.edu/softbound/
There was a talk at 30c3:
http://www.youtube.com/watch?v=2ybcByjNlq8

IOW, the technology to get rid of almost all buffer overflow exploits is there, it just needs to be used. And as long as we don't, we can't claim to be serious about security.

to post comments

Memory safety issues deep in hardware architectures

Posted Jan 10, 2014 20:08 UTC (Fri) by zslade (subscriber, #72097) [Link] (4 responses)

This is the kind of problem that cannot be fully solved without some fundamental architecture changes. If the machine code allows you to perform (mostly) unmitigated memory accesses then these kinds of bugs will always exist even if they become mitigated in user space by better C libraries and such.

These memory issues are exactly what has inspired the crash-safe project to come into being[1]. Inherently x86 and other architectures have punted on enforcing memory protections deep in the hardware due to performance reasons and it's likely we need to rethink this stance and start with hardware that verifies access to memory before allowing a load/store. At the very least for "secure" systems.

1. http://www.crash-safe.org

Memory safety issues deep in hardware architectures

Posted Jan 10, 2014 20:11 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

It appears as though the Mill architecture should handle this[1] (IIRC, it's in the Metadata talk). I'm not really sure though (I'd love LWN to have some coverage on what Mill could mean for the kernel).

[1]http://ootbcomp.com/

Memory safety issues deep in hardware architectures

Posted Jan 10, 2014 20:23 UTC (Fri) by zslade (subscriber, #72097) [Link] (1 responses)

It's possible that OOTB is on a similar track to crash-safe, but they seem to be solving different problems. There may be more overlap than first appears on the surface, but I'm not so sure. Both projects are looking at reimplementing core portions of the ISA to enable fast and secure access.

The main difference I see between the two is that the crash-safe architecture and tools boil down to requiring ALL load/store operations to be mitigated by a memory transaction unit (MTU) that makes all memory access atomic and those operations are additionally inspected by the MTU to ensure the OP code that accesses the memory has a right to that data (read or write). This is really important for machines that are processing "secret" data alongside not-so-secret data.

Memory safety issues deep in hardware architectures

Posted Jan 10, 2014 20:32 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

See 1:06 in this video[1]. Basically, if you request something from memory your process isn't allowed to see, you get a NaR (not a result) which faults on use (similar to Haskell's Nothing; there's also "none" when you don't have a result for something, so maybe it's closer to the Left ctor of Either since there's some error code info that is encoded with the NaR).

I'd recommend watching the whole video for more context.

[1]https://www.youtube.com/watch?v=DZ8HN9Cnjhc

Memory safety issues deep in hardware architectures

Posted Jan 12, 2014 23:00 UTC (Sun) by rvolgers (guest, #63218) [Link]

It appears that Intel will be doing some kind of hardware support in the future, although it is of course a bit limited.

https://code.google.com/p/address-sanitizer/wiki/IntelMem...

Memory safety

Posted Jan 14, 2014 18:15 UTC (Tue) by paulj (subscriber, #341) [Link]

Amen to the first line. Alternatively we need to stop writing security-critical system software in C. Alternatively, if we're still writing in C, we at least need to start building tools to help us out with tediously finicky, but immensely sensitive stuff like parsing. Alternatively, if those tools already exist and we're not using them, we need to figure out why and fix that, so we can use those tools.

Sadly, we're still writing new code for highly security sensitive system software with direct, raw-pointer parsers of remote input:

http://cgit.freedesktop.org/systemd/systemd/tree/src/jour...

with predictable consequences:

https://bugzilla.redhat.com/show_bug.cgi?id=859051