Re: [edk2] Disassemble UEFI FV

Subject: Re: [edk2] Disassemble UEFI FV

From: Andrew Fish <afish@apple.com>

To: edk2-devel@lists.sourceforge.net

Date: 2012-11-28 15:39:22

James,

This could have to do with you looking at the object file that has NOT been linked, the things that are zero probably need to get resolved by the linker. 

You want to look at the linked output and that should be in the Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/DEBUG directory.  Try the *.efi, this should work if you objdump supports PE/COFF. If this does not work then look at the *.dll file.  You should also be able to look at the map file, *.map, to get info about the link. 

Andrew Fish


On Nov 28, 2012, at 2:45 AM, James White wrote:

Thanks for your help.

When I look at just the first few lines of the disassembled code of SecEntryPoint.S then I get the following output:

arm-linux-gnueabi-objdump -d Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/OUTPUT/SecEntryPoint.obj  

Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/OUTPUT/SecEntryPoint.obj:     file format elf32-littlearm

Disassembly of section .text:

00000000 <StartupAddr>:
   0:    00000000     .word    0x00000000

00000004 <_ModuleEntryPoint>:
   4:    ebfffffe     bl    0 <ArmDisableInterrupts>
   8:    ebfffffe     bl    0 <ArmDisableCachesAndMmu>
   c:    e3a0a001     mov    sl, #1
  10:    fafffffe     blx    0 <ArmPlatformSecBootAction>

00000014 <_IdentifyCpu>:
  14:    ebfffffe     bl    0 <ArmReadMpidr>
  18:    e59f10a4     ldr    r1, [pc, #164]    ; c4 <_NeverReturn+0x4>
  1c:    e0005001     and    r5, r0, r1
  20:    e3a03000     mov    r3, #0
  24:    e1550003     cmp    r5, r3
  28:    0a000003     beq    3c <_InitMem>

I am a bit surprised that it seem that all functions outside of Sec are set to "0", e.g. ArmDisableInterrupts etc. Or do I not read it properly? When are the addresses of those functions defined? Does that part come later when linking all of them together as single binary?


Yes

Thanks for any pointers.


From: afish@apple.com
Date: Tue, 27 Nov 2012 11:25:22 -0800
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Disassemble UEFI FV


On Nov 27, 2012, at 9:21 AM, James White wrote:

Hi Andrew

Thanks for your reply. Great help.

I currently have the problem that I'm trying to split SEC from PEI/DXE/BDS. I load the Sec module into a read-only ROM. The ROM is memory-mapped at 0x0 (this is specific to my platform). 
When I disassemble Sec/Sec/OUTPUT/SecEntryPoint.obj I can see that the address of CEntryPoint/StartupAddr is 0x0. 

00000000 <StartupAddr>:
   0:    00000000     .word    0x00000000

This is the entry point for Sec.c (not the startup function of SecEntryPoint.S) but doesn't that conflict with me having the ROM mapped at 0x0?
I cannot get any output of my system because it fails so early at power on. I'm currently using ARM's Fast Model simulation to find the problem.


You can look at the link map for Sec and see the linked address of the symbols. It is likely that the Sec will be linked at 0x00000000 or 0x00000240 (started with non-PE/COFF image). The info in the FDF file is used to relocate Sec to its execute in place address. So In my example that would shift everything over by 0xEC000000 + offset of the Sec PE/COFF image in the FD. 

Just to clarify, what exactly does the BaseAddress mean? Is that where the flash device is memory-mapped on the system, or just some location in RAM where we can relocate code to?


This is the address the FD will execute from. So on a PC this a FLASH ROM address. On a BeagleBoard the mask ROM turns on DRAM and reads a table from ROM and shadows the FD into RAM, so it is a RAM address. 

Thanks again for your help.



From: afish@apple.com
Date: Tue, 27 Nov 2012 08:44:13 -0800
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Disassemble UEFI FV

The edk2 build system produces a command line tool called VolInfo that dumps FVs. It does not disassemble code, but it will show you the layout. 

The FD layout is defined in the platforms .FDF file. Look in the [FD.*] sections. So for example: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ArmPlatformPkg/ArmPlatformPkg.fdf
[FD.Sec_ArmPlatform_EFI]
BaseAddress   = 0xEC000000|gArmTokenSpaceGuid.PcdSecureFdBaseAddress  #The base address of the Secure FLASH Device.
Size          = 0x00010000|gArmTokenSpaceGuid.PcdSecureFdSize         #The size in bytes of the Secure FLASH Device
ErasePolarity = 1
BlockSize     = 0x00001000
NumBlocks     = 0x10
0x00000000|0x00010000
gArmTokenSpaceGuid.PcdSecureFvBaseAddress|gArmTokenSpaceGuid.PcdSecureFvSize
FV = FVMAIN_SEC
So FVMAIN_SEC is relocated to 0xEC000000. This relocation is done when the build calls GenFv. The FV header starts with a zero vector (16-bytes of zero), on ARM these values are patched with a branch to the entry point of the SEC Core. See UpdateArmResetVectorIfNeeded() in https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BaseTools/Source/C/GenFv/GenFvInternalLib.c

The FV layout is completely defined in the UEFI Platform Initialization (PI) Specification 1.2.1 @ http://www.uefi.org/specs/

Disassembly is usually done via a JTAG debugger (I assume you don't have one) or by using a debugger. So if you have gdb you can use the VolInfo + info in the .FDF file to calculate the offset of the Sec PE/COFF image. You can then load the binary into the debugger and disassemble. There are two things to look out for:
1) A Section in a FV File contains a section header, so make sure you are using the start of the PE/COFF image, and not the section header in front of the PE/COFF image
2) In general all images in edk2 are linked a zero. If the build tools produce an ELF or Mach-O file and convert it to PE/COFF then the image is linked at the size of the PE/COFF header. This is due to the PE/COFF header getting loaded into memory when the image is loaded, but the ELF or Mach-O headers do not get copied into memory. So for example you often have to add 0x240 to the load address to get symbols to work correctly. Think load address + link address. 

Given the start of the FV will be a branch to the SEC PE/COFF image entry point you should be able verify you are doing the math correctly. 

It may be possible to write a debugger script that loads the FD into memory, and then you can disassemble it with the given offsets. In gdb you may be able to use `restore Sec_ArmPlatform_EFI.fd 0xEC000000 0xEC00FFFF`.  Don't forget to set the processor architecture in the debugger, and you may have to use 0 vs. the real address depending on what is legal virtual address space for an application on your build platform.


Thanks,

Andrew Fish


On Nov 27, 2012, at 7:10 AM, James White wrote:

Is there a way that I can disasseble my generated UEFI binary (in my case FV/SEC_RTSM_VE_CORTEX-A15_MPCORE_EFI.fd) so that I can see the exact instructions that are being run once the firmware is executed from ROM?
Is there documentation about the format of that .fd? In my case I only have the Sec module in the binary but I can see that the .fd is not exactly the same as Sec/Sec/OUTPUT/ArmPlatformSec.efi - what is the difference?
Can anyone recommend a good disassembler for ARM EFI binaries?

Thanks for any pointers.
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right.http://goparallel.sourceforge.net
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel