Is there a GCC configuration which will produce an executable only containing ARM32 code?
I know the -marm switch tells the compiler not to produce Thumb code, but it applies only to the user code of the program, while initialization routines (e.g. _start, frame_dummy, ...) still contain Thumb instructions.
I am using the Linaro cross compiler tool-chain (arm-linux-gnueabihf-) on a Linux x86-64 system.
EDIT :
While recompiling the tool-chain I found the (probable) solution myself. The initialization routines encoded as Thumb are part of glibc and can be found in the object files crt1.o, crti.o and crtbegin.o. I haven't tried recompiling it, but there may be a configuration value which forces the whole libc to be encoded as ARM32.
Is there a GCC configuration which will produce an executable only containing ARM32 code? I know the -marm switch ...
Your main problem is that that code (e.g. _start) is not produced by the compiler but it is already present pre-compiled (as thumb code).
If you want to have these functions to be non-thumb code you'll have to "replace" the existing files (thumb) by your own ones (non-thumb).
(You don't have to overwrite the existing files but you can instruct the linker to search for these files in a different directory.)
If you don't find pre-built non-thumb files you'll have to create them yourself (what may be a lot of work).
Related
ELF binaries of Linux distributions are stripped and don't include ".comment" section.
Therefore, I could not get the information which compiler build the ELF binary.
I guess most of them are created by GCC and want to know which GCC version is used.
I know that if the ".comment" section is included in the ELF binary, I can get the compiler information using "readelf" or "objdump".
The method was posted before at the stackoverflow.com
How to retrieve the GCC version used to compile a given ELF executable?
I guess I can use decompiling tools (e.g., Hex-Rays Decompiler https://www.hex-rays.com/products/decompiler/ ) to estimate the compiler version.
I also want to know the compiler name if the binary is not created by GCC. For example LLVM-clang.
Do you know a tool to estimate the compiler name and version which create the ELF binary?
I prefer to use a free tool.
ELF binaries of Linux distributions are stripped and don't include ".comment" section. Therefore, I could not get the information which compiler build the ELF binary.
Most binaries also come with a separate debuginfo package, which does have .comment sections, and full source package which allows you to configure and build (almost) identical binary.
Examining either the debuginfo, or the source package is a much easier and more reliable way to answer your question, then guessing from the binary will ever be.
Do you know a tool to estimate the compiler name and version which create the ELF binary?
I doubt such a tool exists: writing such a tool would be a mostly pointless exercise.
I want to restrict the execution of the binaries, in Linux, to those only compiled by myself. Lets say my system has gcc with version 4.8.4, I want to allow execution of ELF binaries that are compiled by gcc only installed on my system. Any ELF that is even compiled by same version 4.8.4, should not execute on my system.
.comment section contains the version and name of the compiler used to compile ELF. Can we use this information if yes how?
Any idea and suggestion is much appreciated
I want to restrict the execution of the binaries, in Linux, to those only compiled by myself.
Suppose you succeed in this. You do realize that your shell, your gcc, your ls will all immediately stop working (unless you've built them all yourself prior to turning on the restriction).
But suppose you have built the entire system, including the compiler, assembler and linker. In this case, you'll want to modify your linker and your kernel such that the linker signs the binaries it links, and your kernel verifies that a valid signature is present, and refuses to run the binary if the signature is invalid. You can read more about code signing here.
.comment section contains the version and name of the compiler used to compile ELF.
Normally, it does. However it is trivial to add a .comment section with arbitrary contents to an already-linked executable, so you can't base your restriction on the contents of .comment (unless you want your restriction to be trivial to bypass).
can objcopy ease my life without changing linker?
Yes.
I believe you are thinking about your problem in a wrong way (thinking about mechanics before thinking about the substance of your solution).
Assuming you do want to do code signing, you'll need to generate a signature for every binary, and then:
Have some means for the kernel to verify that the signature is valid, and
Attach the signature to the binary. This could be as easy as having foo.signature in the same directory as foo for every binary you wish to run. Or you could use objcpy to make the signature part of the binary itself (more convenient if you move your binaries around).
I am porting vc++ project to work on the Linux platform i am using g++ as my compiler. i resolved compiling issues on g++ and able to generate .o files for every source file in vc++ project now i have to link them to produce final executable
i can do that by
g++ file1.o file2.o -o file.out
but when i do that in my make file and execute it a lot of ld errors are coming dueto dependency's
is there any way i can figure it out order of giving the object files ?
are there any tools to do that or any vc++ project files which have the order ?
You say "vc++", but you are using "gcc" (usually that would be g++"). Likely you are missing one or more libraries, which you would specify with a "-l" option (documented as part of ld as well as gcc).
The distinction is important, because each wrapper (gcc and g++) adds the corresponding runtime library to the options it passes to ld.
The order of shared libraries (the most common form with Linux) supposedly does not matter (the linker makes two passes to resolve symbols). A while back, before shared libraries were common, I wrote a program (named liborder, and mentioned here) which analyzes a collection of ".o" objects and "-l" (static libraries) to print a recommended order for the "-l" options. That was workable for small programs, but not for complex ones. For example, Oracle's runtime libraries around 20 years ago were all static, and one needed a list of 15-20 libraries in the proper order to successfully link. My program could not handle that. However, since then, shared libraries (which do not have the problem with ordering) are common enough that I have not bothered to package liborder for use by others (it's still on a to-do list with a dozen other programs).
If your program uses symbols which are not in the standard library for C/C++, then you have to determine that yourself. I suppose one could have a program that searches all of the development libraries for a given symbol, but that appears wasteful, since only a tiny fraction would be pertinent. I see 200 of these in my /usr/lib.
Rather, I make it easy for me to see what my program is missing, by presenting the symbols from nm in readable form -
For C, I use scripts (here as "externs" and "imports") to check which symbols are exported or imported from a collection of ".o" files. The scripts use the output of the nm program, which shows the given symbols.
For C++, there's an option "-C" of nm which shows the unmangled names of symbols.
One modern Linux security hardening tactic is to compile & link code with the option -Wl,-z-noexecstack, this marks the DLL or binary as not needing an executable stack. This condition can be checked using readelf or other means.
I have been working with uClibc and noticed that it produces objects (.so files) that do not have this flag set. Yet uClibc has a configuration option UCLIBC_BUILD_NOEXECSTACK which according to the help means:
Mark all assembler files as noexecstack, which will mark uClibc
as not requiring an executable stack. (This doesn't prevent other
files you link against from claiming to need an executable stack, it
just won't cause uClibc to request it unnecessarily.)
This is a security thing to make buffer overflows harder to exploit.
...etc...
On some digging into the Makefiles this is correct - the flag is only applied to the assembler.
Because the flag is only passed to the assembler does this mean that the uClibc devs have missed an important hardening flag? There are other options, for example UCLIBC_BUILD_RELRO which do result in the equivalent flag being added to the linker (as -Wl,-z,relro)
However a casual observer could easily misread this and assume, as I originally did, that UCLIBC_BUILD_NOEXECSTACK is actually marking the .so file when it is in fact not. OpenWRT for example ensures that that flag is set when it builds uClibc.
Why would uClibc not do things the 'usual' way? What am I missing here? Are the libraries (e.g. librt.so, libpthread.so, etc) actually not NX?
EDIT
I was able to play with the Makefiles and get the noexecstack bit by using the -Wl,-z,noexecstack argument. So why would they not use that as well?
OK, it turns out after list conversation and further research that:
the GNU linker sets the DLL / executable stack state based on the 'lowest common denominator' i.e. if any linked or referenced part has an exec stack then the whole object is set this way
the 'correct' way to resolve this problem is actually to find and fix assembly / object files that use an exec stack when they dont need to.
Using the linker to 'fix' things is a workaround if you can't otherwise fix the root cause.
So for uClibc solution is to submit a bug so that the underlying objects get fixed. Otherwise anything linked with static libraries wont get a non-exec stack.
For my own question, if building a custom firmware not using any static libraries it is possibly sufficient to use the linker flag.
References:
Ubuntu Security Team - Executable Stacks
I have a code that I have written in Fortran during my PhD, and now I am collaborating with some researcher that uses Linux, and they need my model, that is basically a single executable file. In the future I will probably make it open source, but up to know they just want the executable, also because they are not programmers and they have never compiled a program in their life. So the question is: is it possible to compile it on my linux machine and then send it to them in order to use it in another linux machine?Or does the linux version and distribution matter?
thank you very much
A.
If you do not use many libraries you can do that. One option is statically linking the executable (-static or similar compiler option). You need to have the static versions of all needed libraries for that. The have .a suffix. They are often not installed by default in Linux distributions and often they are not supplied in the repositories at all.
In my distrbution (OpenSuSE) they are in packages like glibc-devel-static, lapack-devel-static and similar.
The other option would be to compile the executable on a compatible distribution the users will have (GLIBC version is important) and supply all .so dynamically linked libraries they will need with your executable.
All of this assumes you use the same platform, like i586 or amd64 or arm like wallyk comments. I mostly assumed you are on a PC. You can force most compilers to produce a 32-bit or 64-bit executable by -m32 or -m64 option. You need the right version of the development libraries for that.