News for hackers. Stuff that matters.
Re:DARPA's “Unhackable” Computer by jchw on Tuesday December 26, 2017 @03:41PM (#16010887)
Unclear what the article is really talking about. However, regardless of programming language, I do think that microarchitectures could do more for security. When going for memory safety, why stop at the highest level?

Frankly, if it were about memory safety, though, I think we could count C out. A microarchitecture with inherent protection against memory bugs would likely not be able to provide it's advantages to vanilla C or existing C software.

Re:DARPA's “Unhackable” Computer by abecedarius on Tuesday December 26, 2017 @04:24PM (#16011130)
Re:DARPA's “Unhackable” Computer by deepnotderp on Tuesday December 26, 2017 @04:56PM (#16011295)
Unfortunately, given the industry reliance upon standard C, I doubt capability machines will ever catch on.
Re:DARPA's “Unhackable” Computer by nickpsecurity on Tuesday December 26, 2017 @05:18PM (#16011409)
CHERI a capability machine designed for C programs that runs FreeBSD.
Re:DARPA's “Unhackable” Computer by deepnotderp on Tuesday December 26, 2017 @06:12PM (#16011653)
My point is more that it requires modifications to existing C code to use the full capabilities (no pun intended) of a capability machine.
Re:DARPA's “Unhackable” Computer by fao_ on Tuesday December 26, 2017 @09:00PM (#16012314)
I wonder if this could be done with an alternate stdlib. Editing the usual e.g. heap management functions et al. so it does stuff behind the scenes.
Re:DARPA's “Unhackable” Computer by otakucode on Wednesday December 27, 2017 @01:07PM (#16016604)
Why not get safety AND easy concurrency by going to Software Transactional Memory in hardware? I don't know the specifics of the overhead off the top of my head but I imagine we're getting close to the point where it's a reasonable cost to bear for the benefits it would bring...