We noticed that the current HII Database code that processes the image packages 
incorrectly increments the ImageId for EXT1, EXT2 and EXT4 blocks.

The specification allows these forms of the IIBT block types to be used for any 
other blocks, including DUP and SKIP1 and SKIP2. But currently, EXT1 does this:

    case EFI_HII_IIBT_EXT1:
      Length8 = *(ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8));
      ImageBlock += Length8;
      ImageIdCurrent++;
      break;
    case EFI_HII_IIBT_EXT2:
      CopyMem (
        &Length16,
        ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8),
        sizeof (UINT16)
        );
      ImageBlock += Length16;
      ImageIdCurrent++;
      break;
    case EFI_HII_IIBT_EXT4:
      CopyMem (
        &Length32,
        ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8),
        sizeof (UINT32)
        );
      ImageBlock += Length32;
      ImageIdCurrent++;
      break;

Notice the inconsistent behavior here between EXT1, EXT2 and EXT4. EXT1 does 
not copy the block, but EXT2 and EXT4 do. Also, notice that ImageIdCurrent is 
incremented. This leads to inconsistent behavior when SKIP1 and SKIP2 or DUP 
are encoded using any of these forms.

You may ask: why would anyone do this? Well, one of the ways we are considering 
to extend the image package format is adding new image types (such as 
IIBIT_32BIT). One of the problems with this is that older tools may correctly 
skip the unknown block, but they the ImageId assignment would be incorrect 
(since the older tools don't know it should be incremented). So the solution we 
were thinking is that new image types should be followed by a IIBT_SKIP1 (1) so 
that even older tools would correctly handle the increment of the ImageId. But 
of course, that will not work if the current EDK2 implementation makes all EXT4 
and EXT2 increment the ImageId!

Tim
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to