Binary portability for BPF programs

Posted Nov 30, 2018 21:57 UTC (Fri) by sorokin (guest, #88478)
In reply to: Binary portability for BPF programs by ibukanov
Parent article: Binary portability for BPF programs

The problem with WebAssembly is that it is binary. Binary means unportable and insecure. I would opt into a completely text-based kernel. Being text-based guarantees backward compatibility, portability, extensibility and security.

I can imagine a micro-kernel where each service is Node.js instance. IPC is done using simple text-based JSON. Kernel modules can be loaded from npm at boot time.

What about performance? Well you know JITs nowadays can be as fast as C and sometimes they are even faster. So I guess it can be even faster than Linux kernel, right?

Binary portability for BPF programs

Posted Nov 30, 2018 22:28 UTC (Fri) by mfuzzey (subscriber, #57966) [Link] (2 responses)

Have I been sleeping for the last 4 months?
No not April yet :)

Binary portability for BPF programs

Posted Nov 30, 2018 23:27 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

It's always April somewhere.

Binary portability for BPF programs

Posted Dec 1, 2018 18:48 UTC (Sat) by Camto (guest, #128967) [Link]

T I M E Z O N E S

Binary portability for BPF programs

Posted Nov 30, 2018 23:04 UTC (Fri) by rweikusat2 (subscriber, #117920) [Link]

> What about performance? Well you know JITs nowadays can be as fast as C and sometimes they are even faster. So I guess it can be > even faster than Linux kernel, right?

C isn't executed, hence, C-code has no speed (if a compiler is being used). Machine code is executed. As "at the absolutely wrong time" (namely, while a user is waiting for something to happen) compilers generate machine code, there's obviously no reason why machine code generated "just in time" (when the program was compiled) would have an built-in speed difference compared to machine code generated by the "at the wrong time" compiler.

But that's a pretty meaningless statement: An typical Node.js module depends on each other, typical Node.js module which was at least already planned by the it was written. And a codepath traversing all Node.js code on this planet will take longer to execute that a functionally equivalent, self-contained program. Not to mention that "at the absolutely wrong time" compiling all Node.js code on this planet will already take a lof of time on its own.

Hence, outside of doctored microbenchmarks, the "runs even faster" is not going to happen.

Binary portability for BPF programs

Posted Dec 1, 2018 13:58 UTC (Sat) by meyert (subscriber, #32097) [Link]

This is one of the worst ideas I did hear in the last few years.

Binary portability for BPF programs

Posted Dec 1, 2018 14:52 UTC (Sat) by nix (subscriber, #2304) [Link] (7 responses)

The problem with WebAssembly is that it is binary. Binary means unportable and insecure. I would opt into a completely text-based kernel.

The problem with binary protocols over textual ones is not that they are unportable and insecure, not if their properties are properly specified (as eBPF's has been). It is that they are opaque and hard to debug if you're looking at a raw packet dump. This is not usually considered a problem for assembly languages, which are not usually transmitted over the wire (if you want to debug it, you have a disassembler), and if you are throwing it over the network the ubiquity of tcpdump and/or Wireshark and its massive army of packet dissectors means that binary protocols are much less annoying than they used to be too. The only remaining advantage of textual protocols is that they are easy to write by hand... and who the hell writes major web apps by hand into a telnet session? (Or BPF programs, for that matter). Not even people doing early experimentation do any such thing.

There is a reason the successors to HTTP are all binary protocols. I like textual protocols but in some respects their benefits have declined to irrelevance. The tradeoff wheel has turned once more.

Binary portability for BPF programs

Posted Dec 2, 2018 4:12 UTC (Sun) by sorokin (guest, #88478) [Link] (5 responses)

I did not marked it explicitly, but there should be a big <sarcasm> tag in my comment.

No, I don't think it is a good idea to have micro-kernel consisting of Node.js instances. My comment was intended to have humorous meaning. I just took a few misconceptions I heard from different people and mixed them all together in a single absurd comment.

One example of such misconception is "text based protocols/formats have inherently better backward compatibility than binary". The source of the misconception is comparing key/value-based text formats with sequence-based binary formats. People attribute the distinction to the difference between text and binary, instead of between key/value-based and sequence-based. One can formulate another statement like "key/value-based formats have inherently better backward compatibility than sequence-based". Well this is only partially true. This holds true for only one type of change of the format: adding a new key and assigning a default value if it is not present. Other changes (deleting key, renaming key) break backward-compatibility of key/value-based formats.

Above I've refused only one misconception, but there are many others I used in my comment.

I completely agree with what you said. Thank you for thoughtful answer to my comment. My comment was not intended to be taken seriously. Sorry if my sarcasm was not apparent at first.

Binary portability for BPF programs

Posted Dec 2, 2018 17:21 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

I thought it might be sarcastic, but except for node.js I've heard exactly the same thing from many bearded old fart sysadmins used to typing stuff into telnet sessions. Of course what they actually want is a textual *interpretation* of the output (and the ability to put textual input in and have it translated the other way), but that's rarely what they ask for. :)

Binary portability for BPF programs

Posted Dec 2, 2018 17:43 UTC (Sun) by marcH (subscriber, #57642) [Link]

> I've heard exactly the same thing from many bearded old fart sysadmins used to typing stuff into telnet sessions.

Whereas younger people love using hex editors.

> Of course what they actually want is a textual *interpretation* of the output (and the ability to put textual input in and have it translated the other way), but that's rarely what they ask for. :)

They don't ask that because they know they never get it.

http://www.catb.org/esr/writings/taoup/html/ch05s01.html

Binary portability for BPF programs

Posted Dec 2, 2018 17:33 UTC (Sun) by marcH (subscriber, #57642) [Link] (2 responses)

> People attribute the distinction to the difference between text and binary, instead of between key/value-based and sequence-based.

That confusion is because they're often the same in practice. Key/value means a parser is required, a parser is where the compatibility comes from. Protocols are often binary *because* designers want to just copy from/to memory with as little parsing as possible (just some sanity checks), for instance for performance reasons.

> Other changes (deleting key, renaming key) break backward-compatibility of key/value-based formats.

That's why newer versions rarely ever delete any key and only after a long period of deprecation and warnings and why would anyone rename a key?

> One can formulate another statement like "key/value-based formats have inherently better backward compatibility than sequence-based". Well this is only partially true.

Partially true... in theory.

Binary portability for BPF programs

Posted Dec 3, 2018 18:55 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

> why would anyone rename a key?

I know that IETF handled it well (basically by just saying "oops, sorry"), but some people would not have been able to restrain themselves from fixing "Referer".

Binary portability for BPF programs

Posted Dec 3, 2018 19:20 UTC (Mon) by excors (subscriber, #95769) [Link]

Early versions of HTML5 even attempted to spread the misspelling to the new feature <a rel=noreferer>, for consistency with the HTTP header it refer(r)ed to. But then someone pointed out the DOM API for Referer was already called document.referrer, so HTML5 could switch to <a rel=noreferrer> without feeling guilty about being the first to break consistency.

Binary portability for BPF programs

Posted Dec 2, 2018 14:21 UTC (Sun) by rweikusat2 (subscriber, #117920) [Link]

> The only remaining advantage of textual protocols is that they are easy to write by hand... and who the hell writes major web apps > by hand into a telnet session? (Or BPF programs, for that matter). Not even people doing early experimentation do any such thing.

Well, people who program "web apps" write HTTP "by hand", just like all the other code. Text is also fairly easily generated with simple facilities: It's possible to write a fairly comprehensive HTTP-library in less then 600 lines of code.

Binary portability for BPF programs

Posted Dec 1, 2018 18:50 UTC (Sat) by Camto (guest, #128967) [Link] (2 responses)

> Binary means unportable

Oh yes like PDFs. Those are so unportable.

Binary portability for BPF programs

Posted Dec 2, 2018 4:25 UTC (Sun) by k8to (guest, #15413) [Link]

Funny thing: I've created many many valid PDFs that many PDF reader implementations cannot render correctly. Most of them I didn't even do intentionally. I sort of think of it as "DF".

Binary portability for BPF programs

Posted Dec 2, 2018 8:43 UTC (Sun) by matthias (subscriber, #94967) [Link]

Actually, PDF is a 7-bit ASCII format. Yes, there might be some binary content embedded, especially if you use compression and/or encryption, but like PostScript it is a language that you could write in a normal text editor.

Fun fact: In the national German computer science contest (Bundeswettbewerb Informatik) we once got a solution for an exercise, where some fractal image should be computed. The code was entirely written in PostScript. It could be send to a PostScript printer to compute and print the image. There was no restriction to the programming language. The code had to be documented and the language should be somewhat reasonable.