Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error Importing File: AssertException: _GLOBAL_OFFSET_TABLE_ already allocated #7525

Open
sliedes opened this issue Feb 19, 2025 · 5 comments
Assignees
Labels

Comments

@sliedes
Copy link

sliedes commented Feb 19, 2025

Describe the bug

Please find attached a zip file of three binaries, each of which trigger an assertion failure when importing. The assertion failure seems similar; out of caution, I'm attaching all three of these.

These are x86-64 ELF binaries with dwarf debug information, produced by building a debug build of the EDK2 reference UEFI firmware. The actual runtime EFI binaries are PE/COFF; I believe these ELF files are the same but put inside an EFI and with dwarf debug info.

Of a few hundred such .debug binaries, only these three crash; others I have used successfully in Ghidra, so clearly all the required information seems to be usually present. Having said that, I do not know how functional these would be as executables; I assume they would be.


When importing the attached "Dhcp4Dxe.debug" file, I get this error message:

2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf symbol table section .symtab linked to string table section .strtab
-- | -- | -- | --
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela.text linked to symbol table section .symtab affecting .text
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela.data linked to symbol table section .symtab affecting .data
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela linked to symbol table section .symtab affecting PT_LOAD
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_info linked to symbol table section .symtab affecting .debug_info
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_loclists linked to symbol table section .symtab affecting .debug_loclists
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_aranges linked to symbol table section .symtab affecting .debug_aranges
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_rnglists linked to symbol table section .symtab affecting .debug_rnglists
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_line linked to symbol table section .symtab affecting .debug_line
2025-02-19 | 16:14:21 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_frame linked to symbol table section .symtab affecting .debug_frame
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf symbol table section .symtab linked to string table section .strtab
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela.text linked to symbol table section .symtab affecting .text
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela.data linked to symbol table section .symtab affecting .data
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela linked to symbol table section .symtab affecting PT_LOAD
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_info linked to symbol table section .symtab affecting .debug_info
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_loclists linked to symbol table section .symtab affecting .debug_loclists
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_aranges linked to symbol table section .symtab affecting .debug_aranges
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_rnglists linked to symbol table section .symtab affecting .debug_rnglists
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_line linked to symbol table section .symtab affecting .debug_line
2025-02-19 | 16:14:23 | DEBUG | (ElfHeader) Elf relocation table section .rela.debug_frame linked to symbol table section .symtab affecting .debug_frame
2025-02-19 | 16:14:23 | DEBUG | (ElfProgramBuilder) Discarding 60-byte alignment/filler segment_1.2 at 0000d4c4
2025-02-19 | 16:14:24 | ERROR | (ImporterUtilities) Error Importing File: Error importing file: Dhcp4Dxe.debug ghidra.util.exception.AssertException: _GLOBAL_OFFSET_TABLE_ already allocated
  |   |   | at ghidra.app.util.bin.format.elf.relocation.X86_64_ElfRelocationContext.allocateGot(X86_64_ElfRelocationContext.java:163)
  |   |   | at ghidra.app.util.bin.format.elf.relocation.X86_64_ElfRelocationContext.getNextAllocatedGotEntryAddress(X86_64_ElfRelocationContext.java:203)
  |   |   | at ghidra.app.util.bin.format.elf.relocation.X86_64_ElfRelocationContext.getGotEntryAddress(X86_64_ElfRelocationContext.java:250)
  |   |   | at ghidra.app.util.bin.format.elf.relocation.X86_64_ElfRelocationHandler.relocate(X86_64_ElfRelocationHandler.java:275)
  |   |   | at ghidra.app.util.bin.format.elf.relocation.X86_64_ElfRelocationHandler.relocate(X86_64_ElfRelocationHandler.java:29)
  |   |   | at ghidra.app.util.bin.format.elf.relocation.AbstractElfRelocationHandler.relocate(AbstractElfRelocationHandler.java:119)
  |   |   | at ghidra.app.util.bin.format.elf.relocation.ElfRelocationContext.processRelocation(ElfRelocationContext.java:146)
  |   |   | at ghidra.app.util.bin.format.elf.relocation.ElfRelocationContext.processRelocation(ElfRelocationContext.java:121)
  |   |   | at ghidra.app.util.opinion.ElfProgramBuilder.processRelocationTableEntries(ElfProgramBuilder.java:1055)
  |   |   | at ghidra.app.util.opinion.ElfProgramBuilder.processRelocationTable(ElfProgramBuilder.java:950)
  |   |   | at ghidra.app.util.opinion.ElfProgramBuilder.processRelocations(ElfProgramBuilder.java:887)
  |   |   | at ghidra.app.util.opinion.ElfProgramBuilder.load(ElfProgramBuilder.java:174)
  |   |   | at ghidra.app.util.opinion.ElfProgramBuilder.loadElf(ElfProgramBuilder.java:111)
  |   |   | at ghidra.app.util.opinion.ElfLoader.load(ElfLoader.java:147)
  |   |   | at ghidra.app.util.opinion.AbstractLibrarySupportLoader.doLoad(AbstractLibrarySupportLoader.java:864)
  |   |   | at ghidra.app.util.opinion.AbstractLibrarySupportLoader.loadProgram(AbstractLibrarySupportLoader.java:107)
  |   |   | at ghidra.app.util.opinion.AbstractProgramLoader.load(AbstractProgramLoader.java:129)
  |   |   | at ghidra.plugin.importer.ImporterUtilities.importSingleFile(ImporterUtilities.java:424)
  |   |   | at ghidra.plugin.importer.ImporterDialog.lambda$okCallback$7(ImporterDialog.java:339)
  |   |   | at ghidra.util.task.TaskBuilder$TaskBuilderTask.run(TaskBuilder.java:306)
  |   |   | at ghidra.util.task.Task.monitoredRun(Task.java:134)
  |   |   | at ghidra.util.task.TaskRunner.lambda$startTaskThread$0(TaskRunner.java:106)
  |   |   | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
  |   |   | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
  |   |   | at java.base/java.lang.Thread.run(Thread.java:1575)

Also (this might be considered a separate issue?), during batch import, such an import error stops the entire batch.

To Reproduce

Unzip the attached zip. Import one or all of the binaries, for example Dhcp4Dxe.debug.

Expected behavior

  • The import succeeds

Quite possibly:

  • Even if the import fails, the a batch import process containing that binary still proceeds to the next binary.

Attachments

import_crash.zip

Environment (please complete the following information):

  • OS: NixOS Linux
  • Java Version: 23.0.1
  • Ghidra Version: 11.3
  • Ghidra Origin: NixOS/nixpkgs
@ghidra1
Copy link
Collaborator

ghidra1 commented Feb 19, 2025

NOTE: I have only examined one of the binaries at this point: Ip4Dxe.debug

Was this built with a published build script that is known to produce a good ELF binary with debug? Is there any chance the build is bad/invalid? It seems to have an invalid situation with an almost empty _GLOBAL_OFFSET_TABLE_ where the symbols referenced by the R_X86_64_GOTPCREL relocations are not accounted for within the GOT (e.g., Ip4SysPacketSent). Since the associated symbol is on the actual function this does not appear to be fully/properly linked if the GOT was allocated without it. This binary reports itself as a fully-linked executable which should have a more complete GOT, whereas if it were an object module I would expect there to be no GOT which would get created during the linking process. My first reaction is that something went wrong during the link phase.

@ghidra1
Copy link
Collaborator

ghidra1 commented Feb 19, 2025

You may want to try disabling relocation processing during the import (see import options) since those relocations that caused a problem are not needed since the affected relocation address appears to be properly linked without the need for a GOT entry. It is possible these were optimized away during the linking process but the corresponding relocations were not eliminated.

@ghidra1
Copy link
Collaborator

ghidra1 commented Feb 20, 2025

While the binary does appear to require relocation processing it does appear to have some bad flow resulting in relatively poor disassembly. I am uncertain what would cause this.

@ghidra1 ghidra1 added Status: Waiting on customer Waiting for customer feedback and removed Status: Triage Information is being gathered labels Feb 20, 2025
@sliedes
Copy link
Author

sliedes commented Feb 20, 2025

It's built in the EDK2 build. The "main output" is PE/COFF binaries to be run in the UEFI boot environment; these ELF binaries exist essentially for debugging purposes (as carriers of dwarf).

@sliedes
Copy link
Author

sliedes commented Feb 21, 2025

So, essentially, no, I don't know how sane these files are.

Having said that, I think a useful behavior, if easy within the Java code framework, would be to fail the import of these files but continue the entire batch import instead of stopping the batch import of a bunch of files. What I do now is a batch import, then delete the results and try to figure out from the logs which import failed, and repeat until everything succeeds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants