It depends how much the code uses manually spawned goroutines, and how complex the lifecycle of these goroutines is… in big codebases such as kubernetes, docker, etc, it has been a problem. There have been research papers and blogs about this, but most Go developers are not aware of this issue it seems.
That one seems to be an RPC framework, whereas the other one is for PHP applications... maybe an unfortunate name clash, but they don't do the same thing nor anything I'd call similar.
I am not an expert in incident reaction, but I thought the safe way was to image the affected machine, turn it off, take a clean machine, boot a clean OS image with the affected image mounted read only in a VM, and do the investigation like that ?
Assume that the malware has replaced system commands, possibly used a kernel vulnerability to lie to you to hide its presence, so do not do anything in the infected system directly ?
Maybe if your company infrastructure is affected but not the server you use to host your side projects on with “coolify” unless IT security is your hobby.
Nice article, thank you.
Did you also consider using bpftrace while debugging?
I do not have much experience with it, but I think you can see the kernel call stack with it and I know you can also see the return value (in eax).
That would be less effort than qemu + gdb + disabling kernel aslr, etc.
I have no practical experience with bpftrace, so it did not occur to me. I'll give it a try and perhaps there's gonna be a 2nd part of this investigation.
Author here, thanks for the feedback on legibility, I have now just learned about the CSS `tab-size` property to control how much space tabs get rendered with. I have reduced it, should be better now.
Just one point about testable assembly: I like the Golang guidelines which require to write a Go version before implementing the same in assembly. That way there is a baseline to compare with in terms of correctness and performance. Also the Go project has recently introduced mutation testing and test coverage on assembly code which is very interesting.
Finally about detecting at runtime the presence of simd: I am confused why a third-party dependency or even the std is needed. At least on x64, it’s just one instruction (“cpuid”) and then checking if a bit is set, right?
I agree with the premise, just use a specific version of your dependencies, that’s generally fine.
However: You absolutely do need a lock file to store a cryptographic hash of each dependency to ensure that what is fetched has not been tampered with. And users are definitely not typing a hash when adding a new dependency to package.json or Cargo.toml.
> And users are definitely not typing a hash when adding a new dependency to package.json or Cargo.toml
I actually much prefer that: specify the git revision to use (i.e. a SHA1 hash). I don't particularly care what "version number" that may or may not have.
I wrote a toy Kotlin compiler, for fun.
Then one day a Jetbrains employee opens an issue which only says: “Why? Just why?”.
Maybe it’s the language barrier… but I did not find that particularly polite.
On the other hand I open sourced my blog and received lots of small contributions to fix typos or such which were nice.
The guy was probably upset that someone might be trying to compete with them while their compiler is itself open source. But it still sucks that they couldn’t be more subtle about it. In the end both they and you got upset. A small change in his tone and you might both come off with a nice feeling, him for knowing you were just playing around, and you for perhaps getting recognition from a Kotlin dev.
Obviously I can't change how it made you feel, and as such it was a crappy reply to receive, but on one level at least it's a genuine question that projects should have an answer for.
It kinda matters if you build something as a proof of concept, or you build it to exercise some new technique, or you build it to improve the state of the art, or you build it as the foundation for a product etc.
You wrote it "for fun". That's an excellent reason to write something. I can appreciate your effort in that context. It's going to have rough edges etc. And when it's not fun anymore you move on.
Someone else might write the same thing, but for a different reason. Maybe they want a "better Kotlin compiler". They intend to make it perfect, build a product around it and so on. This sort of project encourages a different level of scrutiny than something fun.
So giving context to a project helps attract the right kind of attention. And more importantly the right kind of other-peoples-time.
But yeah, asking like that is not terribly polite.
>genuine question that projects should have an answer for.
Just because they take issue with the wording doesn't mean that they don't have an aswer for that question. Also, that is an awful entry point for a discussion about the purpose of the project.
A toy Kotlin compiler could probably be useful to bootstrap Kotlin from source, without any existing Kotlin binaries. Looks like there is no path to do that right now.
reply