A year of Rust and DNS • Hacker News Board

Re: A year of Rust and DNS

#91

Post by steveklabnik » Mon, Aug 22, 2016, 4:21 PM UTC

nickpsecurity wrote: post #87

api wrote: post #85

Earlier quoted context omitted.

We will port our security critical code to Rust when you can ship it in Rust for Mac, iOS, Android, Windows, Linux, BSD, FreeRTOS, SYSBIOS, and VxWorks. C's dominance today is about platform and architectural support, not hardware constraints. It's the JavaScript of systems programming.

Can't you do a reference implementation in a language with great static checks like Rust with an equivalent one in C/C++ side-by-side? From Orange Book A1 to modern seL4, they always did something like that where high-level problem is expressed in analyzable way with equivalent, low-level code. Always found problems testing missed. In your case, SPARK would prevent all kinds of problems with Rust's discipline possibl…

Rust has zero-overhead calls into C, but no production-ready transpiler yet.

Re: A year of Rust and DNS

#92

Post by steveklabnik » Mon, Aug 22, 2016, 4:22 PM UTC

api wrote: post #88

nickpsecurity wrote: post #87

Earlier quoted context omitted.

Can't you do a reference implementation in a language with great static checks like Rust with an equivalent one in C/C++ side-by-side? From Orange Book A1 to modern seL4, they always did something like that where high-level problem is expressed in analyzable way with equivalent, low-level code. Always found problems testing missed. In your case, SPARK would prevent all kinds of problems with Rust's discipline possibl…

What we do right now in our project is write thin C++ but use C++'s features (class types, exceptions, catch all, etc.) to implement bounds checking in parsers, etc., in a relatively safe way and with near-zero cost. If we need to go to plain C later we can "minus minus" this thin C++ code base relatively easily. We could in theory do the same with Rust but it would be more work since it's not as syntactically close.…

There is a very very early work in progress one, but it's not nearly ready for non-toy programs yet, it doesn't transpile nearly all of C. Gotta start somewhere!

Re: A year of Rust and DNS

#93

Post by Jtsummers » Mon, Aug 22, 2016, 4:23 PM UTC

masklinn wrote: post #62

bsder wrote: post #42

The only technical comment I have is that it continues to be amazing to me that destructuring binary data is so stupidly verbose in so many languages. I think C and Erlang are the only two languages that got this right.

Erlang I can easily see (destructuring binary data in erlang is an absolute pleasure) but C? Most binary destructuring in C seems to be done with shifts and masks, there's some gain from implicit integral conversions but I don't remember it being "right". IIRC the memory layout of bitfields is not specified so you can't use them to portably destructure binary streams, only to define "packed" structures for memory sav…

> IIRC the memory layout of bitfields is not specified so you can't use them to portably destructure binary streams, only to define "packed" structures for memory saving.

This is correct as my colleagues have recently relearned. Moving from one endianness to another seriously complicated their lives for a few weeks (time to initial discovery of error, time to add in new definitions, time to test the updated system).

Re: A year of Rust and DNS

#94

Post by kbenson » Mon, Aug 22, 2016, 4:28 PM UTC

nickpsecurity wrote: post #86

adrianN wrote: post #65

Earlier quoted context omitted.

Rewriting things in Rust probably doesn't protect against logic bugs like that. Likely it would introduce new bugs of that kind.

That's a real risk. That plus incompatibilities with real-world software that ignore the specs or get creative with any gaps in it. Those have to be tested. Ideally, if it's a critical protocol, it will be formally specified and verified to ensure the code does exactly what it's supposed to. At the least, formally specified with DbyC annotations and/or tests checking each part of the specs plus restricted, coding sty…

It would be wonderful if we could get some standardized language for defining test cases, and some tooling for converting to working (or mostly working) code for your language and implementation (at the API level, at least). If publicly developed per protocol/library, I think it would yield a substantial benefit for robustness of common protocols we have.

Want to develop a DNS library or server? Read the RFCs and download the public test suite (which may get regular updates as people fill out corner cases, put in tests for common bugs/exploits, etc). Occasionally run public test suite plus any of your own tests you have added to confirm things function as you expect. There's so much duplication of effort in this area currently, and i'm sure the majority of test suites for related applications have at least a few tests that would be useful to others.

Re: A year of Rust and DNS

#95

Post by steveklabnik » Mon, Aug 22, 2016, 4:48 PM UTC

api wrote: post #85

nickpsecurity wrote: post #83

Earlier quoted context omitted.

"But BIND isn't just failing because "it's written in C", it's failing because it's written in terrible C. " It's because it's written in C. Writing it in average Java, Go, or Ada would've prevented most of those problems because they're not allowed to do the damage by default. That's because the C language, by design and default, adds risk into common operations that doesn't have to be there. Especially today where…

We will port our security critical code to Rust when you can ship it in Rust for Mac, iOS, Android, Windows, Linux, BSD, FreeRTOS, SYSBIOS, and VxWorks. C's dominance today is about platform and architectural support, not hardware constraints. It's the JavaScript of systems programming.

A lot of those platforms should be covered; I'm not mega familiar with the RTOses you mention, SH-4 is one arch that I'm pretty sure nobody has done a port of yet, though it seems like LLVM supports it?

Re: A year of Rust and DNS

#96

Post by masklinn » Mon, Aug 22, 2016, 4:51 PM UTC

signa11 wrote: post #84

masklinn wrote: post #81

Earlier quoted context omitted.

> will it be possible to have some formatting guidelines / examples on the site somewhere ? https://news.ycombinator.com/formatdoc Sadly HN has jack shit formatting-wise (the most annoying part being you can't escape asterisks so half the time it's going to emphasise a comment section and remove your asterisks despite that not being what you wanted)

> Sadly HN has jack shit formatting-wise it is 'spartan' :)

I'd be fine with spartan (only support for code blocks) or more featureful (escapes at least), but as things are it's less spartan and more annoyingly half-assed.

Re: A year of Rust and DNS

#97

Post by dochtman » Mon, Aug 22, 2016, 7:36 PM UTC

bluejekyll wrote: post #49

dochtman wrote: post #47

As a ring [1] contributor, would be curious to hear if it could satisfy your crypto requirements. Using it could maybe help with your "(oh-my-dear-god I can not unsee what I saw in there, the C, not Rust)" experience. [1] https://github.com/briansmith/ring

Funny you should ask, I was just looking at that last week to try and answer that question. I was also thinking of getting my feet wet in ring with some of the easy issues on the github page.

Sounds awesome, looking forward to it!

If you are an IRC kind of person, maybe also consider joining the #rust-crypto channel on irc.mozilla.org.

Re: A year of Rust and DNS

#98

Post by jedisct1 » Mon, Aug 22, 2016, 8:20 PM UTC

Another DNS-related project in Rust: EdgeDNS https://github.com/jedisct1/edgedns

Re: A year of Rust and DNS

#99

Post by bsder » Mon, Aug 22, 2016, 10:27 PM UTC

masklinn wrote: post #62

bsder wrote: post #42

The only technical comment I have is that it continues to be amazing to me that destructuring binary data is so stupidly verbose in so many languages. I think C and Erlang are the only two languages that got this right.

Erlang I can easily see (destructuring binary data in erlang is an absolute pleasure) but C? Most binary destructuring in C seems to be done with shifts and masks, there's some gain from implicit integral conversions but I don't remember it being "right". IIRC the memory layout of bitfields is not specified so you can't use them to portably destructure binary streams, only to define "packed" structures for memory sav…

> IIRC the memory layout of bitfields is not specified so you can't use them to portably destructure binary streams

This is true, but for many of us in the embedded world, we use the specific packing anyway. I know my endianness, and I know my compiler--so my structs map straight across.

Re: A year of Rust and DNS

#100

Post by e12e » Mon, Aug 22, 2016, 11:38 PM UTC

fractalb wrote: post #55

kbenson wrote: post #33

Earlier quoted context omitted.

> I've heard people decry OpenSSL and it's various warts (it has many), but as a code base, it's worked well for years across an incredible range of platforms. That... really depends on what you consider "worked well". Being a cryptography library, I think I could make a strong argument that working well includes a very good track record with regard to exploits. I don't believe OpenSSL exhibits that[1]. Note the numb…

> I suspect that the vast majority of people would take a 50% performance hit if it yielded a library that had only half as many major flaws as we've seen How would one know whether there are any major flaws in a code base?

Openssl very much falls into the "so complicated / complected that there are no obvious flaws"-bin, while something like NaCl is closer to "So simple there are obviously no flaws" one.

Note that there turned out to be a distressing number of obvious bugs in Openssl, and that it's doubtful that all serious bugs in a full, real-world crypto stack (especially perhaps if you demand support for x509) could ever be obvious.