4 ms·

A good read for sure, thank you. '4. Protocol Parsing', hand-writing protocol parsers in C looks particularly thrilling.

by yazzku 4y ago

77pt77 4y ago
What could go wrong? It's not like there are decades of paying the price of such decisions...
- yazzku 4y ago
  At a cursory glance, they assert((size_t)rv <= n), but if that's the assert.h assert(), it's just void when NDEBUG is defined, and cmake seems to define that when building a Release target. Also, gcc does not seem to define it by default. So that's a bit of an overflow there.
- CyberDildonics 4y ago
  I think you're mixing up parsing a binary protocol with parsing strings.
- swatcoder 4y ago
  You don't have to learn raw systems coding yourself, but if nobody bothers, the code of 2050 is going to be built on a lot of stale, brittle magic that nobody can reproduce or understand. This is exactly the sort of playground effort where those who do want to learn can get their hands dirty. If this is their first time doing this kind of project, they shouldn't use any of this code in production. There will be all sorts of cheated corners and vulnerabilities, and not just in obvious high-risk places like this. That's how hands-on learning goes.
theideaofcoffee 4y ago
The redis wire protocol is simple enough where it's not very difficult. It's instructive to write it in C because there's a lot of translatable knowledge to other languages: read in a buffer, cast that buffer to the protocol-specific struct, read the various fields from memory, etc. Basic operations for a systems-level project like this.
- yazzku 4y ago
  It's simple enough, and yet: https://nvd.nist.gov/vuln/detail/CVE-2021-32675 https://nvd.nist.gov/vuln/detail/CVE-2021-32675 https://nvd.nist.gov/vuln/detail/CVE-2021-41099 https://nvd.nist.gov/vuln/detail/CVE-2021-41099 https://nvd.nist.gov/vuln/detail/CVE-2021-32761 https://nvd.nist.gov/vuln/detail/CVE-2021-32761 I agree it's instructive, but on the other hand, the time might be right to start teaching why not to do this stuff. Modeling a protocol parser in a high-level language that can spit up correct and highly-optimized C code would be just as instructive and perhaps even more fun.
  - blagie 4y ago
    <-- This. Yes, "read in a buffer, cast that buffer to the protocol-specific struct, read the various fields from memory, etc" are all operations one should generally NOT do. This was instructive maybe three decades ago, when the internet was relatively safe. Knowing how to do this RIGHT is important. The place this is still helpful is low-level programming, and embedded is a far better place to learn. If one part of your microwave is talking to a sensor, security isn't really an issue, since you control both ends.
    - yazzku 4y ago
      Yeah, and I said the above being myself a big fan of C. I write C in my hobby projects. Yet if I were doing anything non-trivial that talks over the network, that protocol parsing would for sure not be hand-written.
      - blagie 4y ago
        I really enjoyed writing low-level C code, maybe three decades ago. I grew out of it, eventually, but I remember the joy. Similar for assembly, actually. (And rereading, I don't mean "growing out" in a derogatory way -- I grow into and out of a lot of things -- and low-level programming is something anyone can enjoy for a few years)

A good read for sure, thank you. '4. Protocol Parsing', hand-writing protocol parsers in C looks particularly thrilling.

by yazzku 4y ago

A good read for sure, thank you. '4. Protocol Parsing', hand-writing protocol parsers in C looks particularly thrilling.

77pt77 4y ago

What could go wrong? It's not like there are decades of paying the price of such decisions...

yazzku 4y ago
At a cursory glance, they assert((size_t)rv <= n), but if that's the assert.h assert(), it's just void when NDEBUG is defined, and cmake seems to define that when building a Release target. Also, gcc does not seem to define it by default. So that's a bit of an overflow there.
CyberDildonics 4y ago
I think you're mixing up parsing a binary protocol with parsing strings.
swatcoder 4y ago
You don't have to learn raw systems coding yourself, but if nobody bothers, the code of 2050 is going to be built on a lot of stale, brittle magic that nobody can reproduce or understand. This is exactly the sort of playground effort where those who do want to learn can get their hands dirty. If this is their first time doing this kind of project, they shouldn't use any of this code in production. There will be all sorts of cheated corners and vulnerabilities, and not just in obvious high-risk places like this. That's how hands-on learning goes.

theideaofcoffee 4y ago

The redis wire protocol is simple enough where it's not very difficult. It's instructive to write it in C because there's a lot of translatable knowledge to other languages: read in a buffer, cast that buffer to the protocol-specific struct, read the various fields from memory, etc. Basic operations for a systems-level project like this.

yazzku 4y ago
It's simple enough, and yet: https://nvd.nist.gov/vuln/detail/CVE-2021-32675 https://nvd.nist.gov/vuln/detail/CVE-2021-32675 https://nvd.nist.gov/vuln/detail/CVE-2021-41099 https://nvd.nist.gov/vuln/detail/CVE-2021-41099 https://nvd.nist.gov/vuln/detail/CVE-2021-32761 https://nvd.nist.gov/vuln/detail/CVE-2021-32761 I agree it's instructive, but on the other hand, the time might be right to start teaching why not to do this stuff. Modeling a protocol parser in a high-level language that can spit up correct and highly-optimized C code would be just as instructive and perhaps even more fun.
- blagie 4y ago
  <-- This. Yes, "read in a buffer, cast that buffer to the protocol-specific struct, read the various fields from memory, etc" are all operations one should generally NOT do. This was instructive maybe three decades ago, when the internet was relatively safe. Knowing how to do this RIGHT is important. The place this is still helpful is low-level programming, and embedded is a far better place to learn. If one part of your microwave is talking to a sensor, security isn't really an issue, since you control both ends.
  - yazzku 4y ago
    Yeah, and I said the above being myself a big fan of C. I write C in my hobby projects. Yet if I were doing anything non-trivial that talks over the network, that protocol parsing would for sure not be hand-written.
    - blagie 4y ago
      I really enjoyed writing low-level C code, maybe three decades ago. I grew out of it, eventually, but I remember the joy. Similar for assembly, actually. (And rereading, I don't mean "growing out" in a derogatory way -- I grow into and out of a lot of things -- and low-level programming is something anyone can enjoy for a few years)