ClamAV Blog

For some definition of "serious" I think the gains from a readable implementation in your working language far outweigh performance or correctness concerns.

To put it another way, I'm rarely parsing data for it to be directly optimized into a machine language. I'm parsing data to extract parts I care about and then work with those parts. The more consistent this process is the easier it is to debug and fix. If my whole parsing/using-the-parsed-data pipeline is in the same language, say Javascript, then I am still only ever debugging the same language and runtime environment (eg: node v12 on whatever \*nix).

In a practical example, YARA[0] is (confusingly) used as both a format[1] and specific implementation[2] for sharing malware detection rules. ClamAV[3] is a popular open source antivirus engine that added YARA-the-format support a few years ago[4]. If you look at their grammar[5] file as well, you can see that one uses GNU Bison 3.0.4 the other uses 3.0.5. One is 3754 lines long, the other is 1849. We can expect these to behave differently. At a certain point, say because of how regular expressions are handled[6], it becomes easier to maintain your own parser than to deal with quirks/whims of someone else's implementation (generated or not).

[0]: https://en.wikipedia.org/wiki/YARA

[1]: https://yara.readthedocs.io/en/latest/writingrules.html

[2]: https://github.com/VirusTotal/yara/blob/master/libyara/hex_grammar.c

[3]: https://www.clamav.net

[4]:…

ClamAV is the one I keep seeing used on the server side. Can't speak to as of how effective it is for contemporary Linux malware, but here's a post boasting about heuristics from 10 years ago: https://blog.clamav.net/2011/03/top-5-misconceptions-about-clamav.html

Would be interesting to see a benchmark/study evaluating it as a desktop antivirus - but arguably any server-side malware (which I assume is the majority for Linux today) also apply for a large part of Linux workstations.