panic: runtime error: invalid memory address or nil pointer dereference with garble, not with go #190
Labels
needs info
Requires extra information to be solved
Comments
|
Thanks - can you provide any code to let us reproduce this crash? Otherwise it's going to be near impossible to debug and fix. My guess is that, if you're using protobuf, it's somehow related to reflection. |
|
I'll see if I can reproduce with an example gRPC server. |
|
@dustin-decker We need you to provide a case to reproduce, otherwise this issue will need to be closed as we cannot do anything here. |
|
@dustin-decker Feel free to reopen once you share some code which reproduces this issue. |
|
According to my test, when the enumerated type appears in protobuf, this error will occur after the binary compiled by golang version: go1.15.8 windows/amd64 main.go: protos/test.proto: protos/test.pb.go: |
|
Thanks @SNcoder, I can reproduce that panic. |
|
I also found another error caused by using the dns library. I don't know if it is the same type of problem. golang version: go1.15.8 windows/amd64 main.go: error message: |
|
If I disable import path obfuscation, the protobuf segfault goes away. The obfuscated code also seems correct to me. It's possible that we are breaking the compiled object file. |
|
I can also confirm this is not a recent regression; e014f48 has the same bug. |
mvdan
added a commit
to mvdan/garble-fork
that referenced
this issue
Feb 27, 2021
We used to rely on a parallel implementation of an object file parser and writer to be able to obfuscate import paths. After compiling each package, we would parse the object file, replace the import paths, and write the updated object file in-place. That worked well, in most cases. Unfortunately, it had some flaws: * Complexity. Even when most of the code is maintained in a separate module, the import_obfuscation.go file was still close to a thousand lines of code. * Go compatibility. The object file format changes between Go releases, so we were supporting Go 1.15, but not 1.16. Fixing the object file package to work with 1.16 would probably break 1.15 support. * Bugs. For example, we recently had to add a workaround for burrowers#224, since import paths containing dots after the domain would end up escaped. Another example is burrowers#190, which seems to be caused by the object file parser or writer corrupting the compiled code and causing segfaults in some rare edge cases. Instead, let's drop that method entirely, and force the compiler and linker to do the work for us. The steps necessary when compiling a package to obfuscate are: 1) Replace its "package foo" line with the obfuscated package path. No need to separate the package path and name, since the obfuscated path does not contain slashes. 2) Replace the "-p pkg/foo" flag with the obfuscated path. 3) Replace the "-importcfg [...]" file with a version that uses the obfuscated paths instead. The linker also needs that last step, since it also uses an importcfg file to find object files. There are three noteworthy drawbacks to this new method: 1) Since we no longer write object files, we can't use them to store data to be cached. As such, the -debugdir flag goes back to using the "-a" build flag to always rebuild all packages. On the plus side, that caching didn't work very well; see burrowers#176. 2) The package name "main" remains in all declarations under it, not just "func main", since we can only rename entire packages. This seems fine, as it gives little information to the end user. 3) The -tiny mode no longer sets all lines to 0, since it did that by modifying object files. As a temporary measure, we instead set all top-level declarations to be on line 1. A TODO is added to hopefully improve this again in the near future. The upside is that we get rid of all the issues mentioned before. Plus, garble now nearly works with Go 1.16, with the exception of two very minor bugs that look fixable. A follow-up PR will take care of that and start testing on 1.16. Fixes burrowers#176. Fixes burrowers#190.
mvdan
added a commit
to mvdan/garble-fork
that referenced
this issue
Feb 27, 2021
We used to rely on a parallel implementation of an object file parser and writer to be able to obfuscate import paths. After compiling each package, we would parse the object file, replace the import paths, and write the updated object file in-place. That worked well, in most cases. Unfortunately, it had some flaws: * Complexity. Even when most of the code is maintained in a separate module, the import_obfuscation.go file was still close to a thousand lines of code. * Go compatibility. The object file format changes between Go releases, so we were supporting Go 1.15, but not 1.16. Fixing the object file package to work with 1.16 would probably break 1.15 support. * Bugs. For example, we recently had to add a workaround for burrowers#224, since import paths containing dots after the domain would end up escaped. Another example is burrowers#190, which seems to be caused by the object file parser or writer corrupting the compiled code and causing segfaults in some rare edge cases. Instead, let's drop that method entirely, and force the compiler and linker to do the work for us. The steps necessary when compiling a package to obfuscate are: 1) Replace its "package foo" lines with the obfuscated package path. No need to separate the package path and name, since the obfuscated path does not contain slashes. 2) Replace the "-p pkg/foo" flag with the obfuscated path. 3) Replace the "import" spec lines with the obfuscated package paths, for those dependencies which were obfuscated. 4) Replace the "-importcfg [...]" file with a version that uses the obfuscated paths instead. The linker also needs that last step, since it also uses an importcfg file to find object files. There are three noteworthy drawbacks to this new method: 1) Since we no longer write object files, we can't use them to store data to be cached. As such, the -debugdir flag goes back to using the "-a" build flag to always rebuild all packages. On the plus side, that caching didn't work very well; see burrowers#176. 2) The package name "main" remains in all declarations under it, not just "func main", since we can only rename entire packages. This seems fine, as it gives little information to the end user. 3) The -tiny mode no longer sets all lines to 0, since it did that by modifying object files. As a temporary measure, we instead set all top-level declarations to be on line 1. A TODO is added to hopefully improve this again in the near future. The upside is that we get rid of all the issues mentioned before. Plus, garble now nearly works with Go 1.16, with the exception of two very minor bugs that look fixable. A follow-up PR will take care of that and start testing on 1.16. Fixes burrowers#176. Fixes burrowers#190.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When running a binary built with garble I'm getting:
It runs fine without garble though.
The text was updated successfully, but these errors were encountered: