Re: [edk2] Issues with GenFds when FDF BaseAddress is 0x0

Subject: Re: [edk2] Issues with GenFds when FDF BaseAddress is 0x0

From: "Brian J. Johnson" <bjohnson@sgi.com>

To: edk2-devel@lists.sourceforge.net

Date: 2014-06-17 19:05:45

On 06/16/2014 03:07 PM, Michael Casadevall wrote:
> That did the trick, thanks. Haven't tested to see if it works yet, but
> at least I got a branch instruction at the start of the FD.
>
> I think we're still in a position that we can change AArch64's layout if
> loading at 0x0 is really a bad idea; as defined, there are two seperate
> NOR devices in the early boot space, and we could make an argument to
> place Tiano in the other one which would get it out of 0x0, but I'm not
> sure I understand the logic on why this is necessarily bad; nothing says
> 0x0 has to be NULL, especially when dealing with bare-metal programming.
> At least on AArch32, the ISR table is at 0x0, which is always a series
> of branch instructions.
>

I'm not familiar with AArch64 (or AArch32 for that matter), but I've 
found that having 0 be a valid address of any sort is generally a bad idea.

Writable memory at 0 proved to be a very bad idea on the 16-bit x86 
platforms.  In the old DOS days, the interrupt table was in RAM starting 
at PA 0, so whenever a buggy program wrote through a NULL pointer, it 
would trash the interrupt vectors, leading to very strange crashes in 
innocent code.

Even readable memory at 0 is something of a problem, since it provides 
data to reads through NULL pointers (assuming that NULL==0), masking the 
underlying problem.  For software debuggability, it would be better to 
take an exception whenever a NULL is dereferenced.

AFAIK most OSes avoid mapping VA 0 in user mode, to catch NULL pointer 
problems.  I've done the same with X64 BIOSes, by adjusting the segment 
registers and page tables.  It has found several bugs on each platform 
I've used it on.

My $.02....

Thanks,
Brian Johnson

> On 16 June 2014 08:03, Harry Liebel  > wrote:
>
>     Hi Michael.
>
>     I think what you are really looking for is the 'Force rebase' option
>     that goes into the fdf file. It is a workaround in the Basetool as it
>     normally skips some image creation operations if the image Base address
>     is set to 0x0.
>
>     So in your fdf file you can try something like this (taken from the
>     ArmVExpress-FVP-AArch64.fdf):
>     ---
>        [FV.FVMAIN_SEC]
>        FvBaseAddress      = 0x0  # Secure ROM
>        FvForceRebase      = TRUE
>        FvAlignment        = 16
>        ERASE_POLARITY     = 1
>     ---
>
>     The 'FvForceRebase' option forces the tool to process the image even if
>     the base address is set to 0x0.
>
>
>     To answer the other part of the question. The initial jump instruction
>     lives here:
>     BaseTools/Source/C/GenFv/GenFvInternalLib.c :
>     UpdateArmResetVectorIfNeeded()
>
>     Regards,
>     Harry
>
>
>     On 16/06/14 07:14, Michael Casadevall wrote:
>      > Hey all,
>      >
>      > I've been working on porting TianoCore to KVM on AArch64, and I've
>      > recently run into an issue which I'm hoping someone can help me to
>      > debug. Recent proposed changes to KVM place the address space for
>      > BootROMs and persistent storage from 0x0-0x8000000, with the early
>      > boot code for Tiano startng at 0x0. My problem is that when the
>     FDF is
>      > set to generate an image for this load location, it appears to create
>      > a malformed FD file.
>      >
>      > Under normal circumstances, the very first bits of the .fd file are a
>      > branch instruction to the start of the PEI. This generates correctly
>      > when the FDF is set to any BaseAddress that != 0x0.
>      >
>      > For example:
>      >
>      > Here's a known good image
>      > $ hexdump
>      > Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd |
>     head
>      > 0000000 01e2 1400 0000 0000 0000 0000 0000 0000
>      > 0000010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
>      >
>      > The same code, compiled with my updated FDF generates the following:
>      > $ hexdump
>      > Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd |
>     head
>      > 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>      > 0000010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
>      >
>      > I've tried and failed to locate the code responsible for writing out
>      > the initial branch statement, so I'm hoping somewhere here can get me
>      > a pointer on where to look. The relevant bit of my FDF is inline
>     below.
>      >
>      > [FD.KVM_EFI]
>      > BaseAddress   = 0x0000000|gArmTokenSpaceGuid.PcdFdBaseAddress  # KVM
>      > assigns 0 - 0x8000000 for a BootROM
>      > Size          = 0x8000000|gArmTokenSpaceGuid.PcdFdSize         # The
>      > size in bytes of the FLASH Device
>      > ErasePolarity = 1
>      >
>      > # This one is tricky, it must be: BlockSize * NumBlocks = Size
>      > BlockSize     = 0x00001000
>      > NumBlocks     = 0x8000
>      >
>      > As best I can tell, GenFds appears to be the relevant utility, but
>      > nothing in the code jumps out as relevent, and I admit I'm completely
>      > unfamiliar with this area of the tree.
>      >
>      > Thanks in advance,
>      > Michael
>
>
>     -- IMPORTANT NOTICE: The contents of this email and any attachments
>     are confidential and may also be privileged. If you are not the
>     intended recipient, please notify the sender immediately and do not
>     disclose the contents to any other person, use it for any purpose,
>     or store or copy the information in any medium.  Thank you.
>
>     ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>     Registered in England & Wales, Company No:  2557590
>     ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
>     9NJ, Registered in England & Wales, Company No:  2548782
>
>
>     ------------------------------------------------------------------------------
>     HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>     Solutions
>     Find What Matters Most in Your Big Data with HPCC Systems
>     Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>     Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>     http://p.sf.net/sfu/hpccsystems
>     _______________________________________________
>     edk2-devel mailing list
>     edk2-devel@lists.sourceforge.net
>     
>     https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
>
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel