News for hackers. Stuff that matters.
Re:System programming in Rust: beyond safety by nickpsecurity on Thursday June 15, 2017 @11:19AM (#14561197)
"Assembling the machine code of a system on itself means it's independent of its "parent" system."

Far as a compiler, that doesn't really matter for most systems (esp embedded). You can cross-compile to any architecture you want with portable code and a new backend. The only tools you need for each architecture's CPU's/MCU's are something to load and test the code. Those already exist in embedded sector. Instrumentation for Rust code would be necessary but this doesn't involve doing the whole compiler on, say, an 8-bitter.

"you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks."

That's an SCM security problem. You'd need to trust every compiler developer, the repo it's stored in, the transmission process, and whatever you used to build it. Most supposed solutions focus on the last one almost exclusively when the first three were the source of most attacks historically. In any case, that's barely relevant to the discussion of using Rust on a new architecture as almost nobody will every be hit by that & most people wanting Rust backends aren't doing high-assurance security for stopping nation-states or something. Those people hand-verify the assembly anyway.

Re:System programming in Rust: beyond safety by eridius on Thursday June 15, 2017 @01:21PM (#14562366)
> You'd need to trust every compiler developer, the repo it's stored in, the transmission process, and whatever you used to build it. Most supposed solutions focus on the last one almost exclusively when the first three were the source of most attacks historically.

The first three aren't a "trusting trust" attack. With the first three, any attack is visible in the code that you eventually compile. The whole point of "trusting trust" is no amount of source code inspection will ever uncover the problem.

Re:System programming in Rust: beyond safety by nickpsecurity on Thursday June 15, 2017 @02:01PM (#14562755)
As infogulch noted, the reason I counter mentions of Paul Karger's attack (MULTICS early 70's) that Thompson wrote about is that is has to be a social fad/meme to mention it when it's happened only twice on record. Millions of attacks, countless vulnerabilities by compiler errors, many repos compromised, and 2 instances of a compiler-induced subversion. Yet, you brought up Trusting Trust instead of the other stuff we really need to worry about. That's typical do I always point it out.

Plus, Karger pointed out solution shortly after the problem: verified compiler, safe languages, repo security (esp paper in safes), crypto/courier distribution, and designed to build locally from source using onsite tools rerunning all tests, proofs, etc. Mitigates the need for worrying about Trusting Trust most of the time plus knocks out majority of attacks. Better to mention that if worried about subversion. Or Myer's landmark work that defined in detail problems and solutions.

Trusting Trust meme just misdirects focus from important issues.

Re:System programming in Rust: beyond safety by eridius on Thursday June 15, 2017 @02:09PM (#14562837)
I wasn't the one who brought up Trusting Trust.

But the person who did said

> you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks.

The point of that comment (at least, as I read it) isn't that you have to be worried about "trusting trust", but rather that there's no point in writing a new compiler from scratch unless you already are worried about "trusting trust" (with the implication being that most people aren't and so writing a new compiler from scratch isn't necessary).

SCM security issues (as you mentioned) are irrelevant at this point, because they really have no bearing on whether you have to write a new compiler from scratch.

Re:System programming in Rust: beyond safety by nickpsecurity on Thursday June 15, 2017 @07:08PM (#14565241)
Didn't look at the name. Too much of a hurry. My bad.
Re:System programming in Rust: beyond safety by infogulch on Thursday June 15, 2017 @01:38PM (#14562505)
I think nickpsecurity's point is that there are many more lucrative targets to attack than compiler binaries. More lucrative in both effort/reward payoff and also difficulty of detection. For example: Analog Malicious Hardware [1], that would allow a single component added to the chip mask to compromise the entire chip only by the attacker and be undetectable and maintain plausible deniability. Other targets like BIOS, Intel AMT, etc would also be better.

[1]: https://www.ieee-security.org/TC/SP2016/papers/0824a018.pdf