Is the kernel executable bootable?

Question

Wikipedia page on Nuclear Dump says

On Unix-like systems, the main dumps usually use the standard image-format executable:

a.out in older versions of Unix, ELF in modern Linux, System V, Solaris, and BSD systems, Mach-O in OS X, etc. 

Does this mean that the main dump itself is executable? If not, why not?

Edit: Since @ WumpusQ.Wumbley mentions coredump_filter in a comment, perhaps the above question should be: can a kernel dump be created in such a way that it runs by itself?

Answer 1

In older versions of unix, text was included by default, as well as data in the kernel dump, but it was also specified in a.out format, and not in ELF. Today, the default behavior (for Linux, for sure, and not 100% sure of the options for BSD, Solaris, etc.) is to have a basic dump in ELF format without text partitions, but this behavior can be changed.
However, a core dump cannot be performed anyway without any help. The reason for this is that there are two things in the simplest kernel file. One of them is an entry point, the other is code for restoring the state of the processor in the state or immediately before the dump (by default there are also no text sections).
AIX used to have a utility called unump, but I have no idea what happened to it. It does not exist in any standard Linux distribution that I know of. As mentioned above (@WumpusQ), there is also an attempt at a similar Linux project mentioned in the comments above, however this project is not complete and does not restore the processor to its original state. This, however, is still quite good in some specific debugging cases.
It is also worth mentioning that there are other files in the ELF format, which also cannot be executed, which are not the main files. Such as object file files (compiler output) and .so (shared object). To start external addresses, a binding step is required.

Answer 2

There are two types of core dumps: system core dumps and process dumps. They differ in many aspects, such as the way they are created and the method used to analyze them.

In most cases, the signal causing the application to crash is SIGSEGV (segmentation violation) or SIGBUS.

Similar types of signals trigger a core dump ... perhaps cause it.

Answer 3

I emailed this question to the creator of the undump utility for my experience and received the following answer:

As mentioned in some answers, you can enable code sections by setting coredump_filter, but this is not the default for Linux (and I'm not quite sure about the BSD and Solaris options). If various pieces of code are saved in the original core-dump, there is actually nothing missing to create a new executable file. However, it requires some changes in the original (for example, including an entry point and indicating that the record, specify the code that will restore the processor registers). If the main file is modified in this way, it will become executable, and you can start it. Unfortunately, some states are not going to be saved, so the new executable file will not be able to work directly. open files, sockets, pips, etc. will not be open and may even point to other FDs (which can cause all kinds of strange things). However, this is likely to be sufficient for most debugging tasks, such as launching small functions from gdb (so you don’t get the “don’t run the executable” stuff).

Answer 4

As the other guys said, I don’t think you can execute the kernel dump file without the source binary.

In case you are interested in debugging a binary file (and debugging symbols are included in it, in other words it is not split), you can run gdb binary core .

Inside gdb, you can use the bt (backtrace) command to get the stack trace when the application crashes.