question about a compressed Ffs3 file inside FFS2 filesystem

public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed

* question about a compressed Ffs3 file inside FFS2 filesystem
@ 2016-10-19 23:09 Sean Brogan
  2016-10-19 23:39 ` Andrew Fish
  2016-10-20  8:27 ` Gao, Liming
  0 siblings, 2 replies; 13+ messages in thread
From: Sean Brogan @ 2016-10-19 23:09 UTC (permalink / raw)
  To: edk2-devel@lists.01.org

We have a condition that occurs when we boot where we see the following message and our boot fails because of it.
DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3 formatted FV.\n"));

Which is on line 773 of FwVol.c ( https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/FwVol/FwVol.c )

The condition is caused by a large firmware volume (greater than 16mb) that is compressed and put into a smaller FV (less than 16mb).  My question is why isn't this allowed (seems like a valid scenario).  Volinfo supports this and decodes binary fine.  The PI Vol 3 spec has a section 3.2.2  EFI_FIRMWARE_FILE_SYSTEM3_GUID which says FileSystem2 doesn't support large files but it seems that the code is not taking into account that the section is compressed and therefore you can have a large file inside a compressed section inside a FV with File System2.

Feedback/thoughts/comments/Bug?

Here are some details of my scenario.
Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-896185c32dd3  (ffs3)
Non compressed FV has filesystem == 5473c07a-3dcb-4dca-bd6f-1e9689e7349a (ffs2)

VolInfo dump of the Non Compressed FV showing the nested/compressed FV inside.

Decoding
VolInfo Version 1.0 Build Build 20909
Signature:        _FVH (4856465F)
Attributes:       4FEFF
       EFI_FVB2_READ_DISABLED_CAP
       EFI_FVB2_READ_ENABLED_CAP
       EFI_FVB2_READ_STATUS
       EFI_FVB2_WRITE_DISABLED_CAP
       EFI_FVB2_WRITE_ENABLED_CAP
       EFI_FVB2_WRITE_STATUS
       EFI_FVB2_LOCK_CAP
       EFI_FVB2_LOCK_STATUS
       EFI_FVB2_STICKY_WRITE
       EFI_FVB2_MEMORY_MAPPED
       EFI_FVB2_ERASE_POLARITY
       EFI_FVB2_READ_LOCK_CAP
       EFI_FVB2_READ_LOCK_STATUS
       EFI_FVB2_WRITE_LOCK_CAP
       EFI_FVB2_WRITE_LOCK_STATUS
        EFI_FVB2_ALIGNMENT_16
        EFI_FVB2_ALIGNMENT_32
        EFI_FVB2_ALIGNMENT_64
        EFI_FVB2_ALIGNMENT_128
        EFI_FVB2_ALIGNMENT_4K
        EFI_FVB2_ALIGNMENT_8K
        EFI_FVB2_ALIGNMENT_16K
        EFI_FVB2_ALIGNMENT_32K
        EFI_FVB2_ALIGNMENT_1M
        EFI_FVB2_ALIGNMENT_2M
       EFI_FVB2_ALIGNMENT_4M
        EFI_FVB2_ALIGNMENT_8M
        EFI_FVB2_ALIGNMENT_256M
        EFI_FVB2_ALIGNMENT_512M
        EFI_FVB2_ALIGNMENT_1G
        EFI_FVB2_ALIGNMENT_2G
Header Length:         0x00000048
File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
Revision:              0x0002
Number of Blocks:      0x00000028
Block Length:          0x00010000
Total Volume Size:     0x00280000
============================================================
File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
File Offset:      0x00000048
File Length:      0x001F3FFD
File Attributes:  0x00
File State:       0xF8
        EFI_FILE_DATA_VALID
File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
------------------------------------------------------------
  Type:  EFI_SECTION_GUID_DEFINED
  Size:  0x001F3FE5
  SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf

  DataOffset:             0x0018
  Attributes:             0x0001
------------------------------------------------------------
  Type:  EFI_SECTION_RAW
  Size:  0x00000FF8
------------------------------------------------------------
  Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
  Size:  0x01010008
============================================================

Thanks
Sean


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-19 23:09 question about a compressed Ffs3 file inside FFS2 filesystem Sean Brogan
@ 2016-10-19 23:39 ` Andrew Fish
  2016-10-19 23:59   ` valerij zaporogeci
  2016-10-19 23:59   ` Sean Brogan
  2016-10-20  8:27 ` Gao, Liming
  1 sibling, 2 replies; 13+ messages in thread
From: Andrew Fish @ 2016-10-19 23:39 UTC (permalink / raw)
  To: Sean Brogan; +Cc: edk2-devel@lists.01.org


> On Oct 19, 2016, at 4:09 PM, Sean Brogan <sean.brogan@microsoft.com> wrote:
> 
> We have a condition that occurs when we boot where we see the following message and our boot fails because of it.
> DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3 formatted FV.\n"));
> 
> Which is on line 773 of FwVol.c ( https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/FwVol/FwVol.c )
> 
> The condition is caused by a large firmware volume (greater than 16mb) that is compressed and put into a smaller FV (less than 16mb).  My question is why isn't this allowed (seems like a valid scenario).  Volinfo supports this and decodes binary fine.  The PI Vol 3 spec has a section 3.2.2  EFI_FIRMWARE_FILE_SYSTEM3_GUID which says FileSystem2 doesn't support large files but it seems that the code is not taking into account that the section is compressed and therefore you can have a large file inside a compressed section inside a FV with File System2.
> 
> Feedback/thoughts/comments/Bug?
> 

Sean,

If I understand correctly you are stating that the contents of an Encapsulation section should not have any restrictions on content type. The only error checking should be that the raw encapsulation section data needs to fit into the file type. That seems reasonable to me? I'm not sure if the PI spec makes some statement that the code is enforcing, or I guess the PI spec could be vague and people are interpreting it differently. 

Thanks,

Andrew Fish

> Here are some details of my scenario.
> Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-896185c32dd3  (ffs3)
> Non compressed FV has filesystem == 5473c07a-3dcb-4dca-bd6f-1e9689e7349a (ffs2)
> 
> VolInfo dump of the Non Compressed FV showing the nested/compressed FV inside.
> 
> Decoding
> VolInfo Version 1.0 Build Build 20909
> Signature:        _FVH (4856465F)
> Attributes:       4FEFF
>       EFI_FVB2_READ_DISABLED_CAP
>       EFI_FVB2_READ_ENABLED_CAP
>       EFI_FVB2_READ_STATUS
>       EFI_FVB2_WRITE_DISABLED_CAP
>       EFI_FVB2_WRITE_ENABLED_CAP
>       EFI_FVB2_WRITE_STATUS
>       EFI_FVB2_LOCK_CAP
>       EFI_FVB2_LOCK_STATUS
>       EFI_FVB2_STICKY_WRITE
>       EFI_FVB2_MEMORY_MAPPED
>       EFI_FVB2_ERASE_POLARITY
>       EFI_FVB2_READ_LOCK_CAP
>       EFI_FVB2_READ_LOCK_STATUS
>       EFI_FVB2_WRITE_LOCK_CAP
>       EFI_FVB2_WRITE_LOCK_STATUS
>        EFI_FVB2_ALIGNMENT_16
>        EFI_FVB2_ALIGNMENT_32
>        EFI_FVB2_ALIGNMENT_64
>        EFI_FVB2_ALIGNMENT_128
>        EFI_FVB2_ALIGNMENT_4K
>        EFI_FVB2_ALIGNMENT_8K
>        EFI_FVB2_ALIGNMENT_16K
>        EFI_FVB2_ALIGNMENT_32K
>        EFI_FVB2_ALIGNMENT_1M
>        EFI_FVB2_ALIGNMENT_2M
>       EFI_FVB2_ALIGNMENT_4M
>        EFI_FVB2_ALIGNMENT_8M
>        EFI_FVB2_ALIGNMENT_256M
>        EFI_FVB2_ALIGNMENT_512M
>        EFI_FVB2_ALIGNMENT_1G
>        EFI_FVB2_ALIGNMENT_2G
> Header Length:         0x00000048
> File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> Revision:              0x0002
> Number of Blocks:      0x00000028
> Block Length:          0x00010000
> Total Volume Size:     0x00280000
> ============================================================
> File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> File Offset:      0x00000048
> File Length:      0x001F3FFD
> File Attributes:  0x00
> File State:       0xF8
>        EFI_FILE_DATA_VALID
> File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> ------------------------------------------------------------
>  Type:  EFI_SECTION_GUID_DEFINED
>  Size:  0x001F3FE5
>  SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> 
>  DataOffset:             0x0018
>  Attributes:             0x0001
> ------------------------------------------------------------
>  Type:  EFI_SECTION_RAW
>  Size:  0x00000FF8
> ------------------------------------------------------------
>  Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
>  Size:  0x01010008
> ============================================================
> 
> Thanks
> Sean
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-19 23:39 ` Andrew Fish
@ 2016-10-19 23:59   ` valerij zaporogeci
  2016-10-19 23:59   ` Sean Brogan
  1 sibling, 0 replies; 13+ messages in thread
From: valerij zaporogeci @ 2016-10-19 23:59 UTC (permalink / raw)
  To: Andrew Fish; +Cc: Sean Brogan, edk2-devel@lists.01.org

>From the specification:
 > A firmware volume image section is a leaf section that contains a
PI Firmware Volume Image.
 > EFI_FIRMWARE_VOLUME_IMAGE_SECTION2 must be used if the section is 16MB or
 > larger.

So it looks like PI wants you to use large format (FFS3, File2,
Section2) when uncompressed section is >16MB. And it is in your
scenario:

 > Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
 > Size:  0x01010008


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-19 23:39 ` Andrew Fish
  2016-10-19 23:59   ` valerij zaporogeci
@ 2016-10-19 23:59   ` Sean Brogan
  2016-10-20  0:11     ` Andrew Fish
  1 sibling, 1 reply; 13+ messages in thread
From: Sean Brogan @ 2016-10-19 23:59 UTC (permalink / raw)
  To: afish@apple.com; +Cc: edk2-devel@lists.01.org

Yes. I think the challenge in the code is the compressed section is a guided section and the decompression is all handled transparently.  
One solution might be that once a section was processed that had attributes of EFI_GUIDED_SECTION_PROCESSING_REQUIRED then the check for filesystems should no longer be performed.  

Thanks
Sean


> -----Original Message-----
> From: afish@apple.com [mailto:afish@apple.com]
> Sent: Wednesday, October 19, 2016 4:40 PM
> To: Sean Brogan <sean.brogan@microsoft.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2
> filesystem
> 
> 
> > On Oct 19, 2016, at 4:09 PM, Sean Brogan <sean.brogan@microsoft.com>
> wrote:
> >
> > We have a condition that occurs when we boot where we see the following
> message and our boot fails because of it.
> > DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3
> > formatted FV.\n"));
> >
> > Which is on line 773 of FwVol.c (
> >
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/
> Fw
> > Vol/FwVol.c )
> >
> > The condition is caused by a large firmware volume (greater than 16mb)
> that is compressed and put into a smaller FV (less than 16mb).  My question
> is why isn't this allowed (seems like a valid scenario).  Volinfo supports this
> and decodes binary fine.  The PI Vol 3 spec has a section 3.2.2
> EFI_FIRMWARE_FILE_SYSTEM3_GUID which says FileSystem2 doesn't
> support large files but it seems that the code is not taking into account that
> the section is compressed and therefore you can have a large file inside a
> compressed section inside a FV with File System2.
> >
> > Feedback/thoughts/comments/Bug?
> >
> 
> Sean,
> 
> If I understand correctly you are stating that the contents of an Encapsulation
> section should not have any restrictions on content type. The only error
> checking should be that the raw encapsulation section data needs to fit into
> the file type. That seems reasonable to me? I'm not sure if the PI spec makes
> some statement that the code is enforcing, or I guess the PI spec could be
> vague and people are interpreting it differently.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Here are some details of my scenario.
> > Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-896185c32dd3
> > (ffs3) Non compressed FV has filesystem ==
> > 5473c07a-3dcb-4dca-bd6f-1e9689e7349a (ffs2)
> >
> > VolInfo dump of the Non Compressed FV showing the nested/compressed
> FV inside.
> >
> > Decoding
> > VolInfo Version 1.0 Build Build 20909
> > Signature:        _FVH (4856465F)
> > Attributes:       4FEFF
> >       EFI_FVB2_READ_DISABLED_CAP
> >       EFI_FVB2_READ_ENABLED_CAP
> >       EFI_FVB2_READ_STATUS
> >       EFI_FVB2_WRITE_DISABLED_CAP
> >       EFI_FVB2_WRITE_ENABLED_CAP
> >       EFI_FVB2_WRITE_STATUS
> >       EFI_FVB2_LOCK_CAP
> >       EFI_FVB2_LOCK_STATUS
> >       EFI_FVB2_STICKY_WRITE
> >       EFI_FVB2_MEMORY_MAPPED
> >       EFI_FVB2_ERASE_POLARITY
> >       EFI_FVB2_READ_LOCK_CAP
> >       EFI_FVB2_READ_LOCK_STATUS
> >       EFI_FVB2_WRITE_LOCK_CAP
> >       EFI_FVB2_WRITE_LOCK_STATUS
> >        EFI_FVB2_ALIGNMENT_16
> >        EFI_FVB2_ALIGNMENT_32
> >        EFI_FVB2_ALIGNMENT_64
> >        EFI_FVB2_ALIGNMENT_128
> >        EFI_FVB2_ALIGNMENT_4K
> >        EFI_FVB2_ALIGNMENT_8K
> >        EFI_FVB2_ALIGNMENT_16K
> >        EFI_FVB2_ALIGNMENT_32K
> >        EFI_FVB2_ALIGNMENT_1M
> >        EFI_FVB2_ALIGNMENT_2M
> >       EFI_FVB2_ALIGNMENT_4M
> >        EFI_FVB2_ALIGNMENT_8M
> >        EFI_FVB2_ALIGNMENT_256M
> >        EFI_FVB2_ALIGNMENT_512M
> >        EFI_FVB2_ALIGNMENT_1G
> >        EFI_FVB2_ALIGNMENT_2G
> > Header Length:         0x00000048
> > File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> > Revision:              0x0002
> > Number of Blocks:      0x00000028
> > Block Length:          0x00010000
> > Total Volume Size:     0x00280000
> >
> ==========================================================
> ==
> > File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> > File Offset:      0x00000048
> > File Length:      0x001F3FFD
> > File Attributes:  0x00
> > File State:       0xF8
> >        EFI_FILE_DATA_VALID
> > File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> > ------------------------------------------------------------
> >  Type:  EFI_SECTION_GUID_DEFINED
> >  Size:  0x001F3FE5
> >  SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> >
> >  DataOffset:             0x0018
> >  Attributes:             0x0001
> > ------------------------------------------------------------
> >  Type:  EFI_SECTION_RAW
> >  Size:  0x00000FF8
> > ------------------------------------------------------------
> >  Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
> >  Size:  0x01010008
> >
> ==========================================================
> ==
> >
> > Thanks
> > Sean
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-19 23:59   ` Sean Brogan
@ 2016-10-20  0:11     ` Andrew Fish
  2016-10-20  0:15       ` Kinney, Michael D
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Fish @ 2016-10-20  0:11 UTC (permalink / raw)
  To: Sean Brogan; +Cc: edk2-devel@lists.01.org


> On Oct 19, 2016, at 4:59 PM, Sean Brogan <sean.brogan@microsoft.com> wrote:
> 
> Yes. I think the challenge in the code is the compressed section is a guided section and the decompression is all handled transparently.  
> One solution might be that once a section was processed that had attributes of EFI_GUIDED_SECTION_PROCESSING_REQUIRED then the check for filesystems should no longer be performed.  
> 

That seems reasonable. Lets see what other people think. 

We can also, independently, bring it up at the UEFI Forum to see if we need to clarify the PI spec. 

Thanks,

Andrew Fish

> Thanks
> Sean
> 
> 
>> -----Original Message-----
>> From: afish@apple.com [mailto:afish@apple.com]
>> Sent: Wednesday, October 19, 2016 4:40 PM
>> To: Sean Brogan <sean.brogan@microsoft.com>
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2
>> filesystem
>> 
>> 
>>> On Oct 19, 2016, at 4:09 PM, Sean Brogan <sean.brogan@microsoft.com>
>> wrote:
>>> 
>>> We have a condition that occurs when we boot where we see the following
>> message and our boot fails because of it.
>>> DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3
>>> formatted FV.\n"));
>>> 
>>> Which is on line 773 of FwVol.c (
>>> 
>> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/
>> Fw
>>> Vol/FwVol.c )
>>> 
>>> The condition is caused by a large firmware volume (greater than 16mb)
>> that is compressed and put into a smaller FV (less than 16mb).  My question
>> is why isn't this allowed (seems like a valid scenario).  Volinfo supports this
>> and decodes binary fine.  The PI Vol 3 spec has a section 3.2.2
>> EFI_FIRMWARE_FILE_SYSTEM3_GUID which says FileSystem2 doesn't
>> support large files but it seems that the code is not taking into account that
>> the section is compressed and therefore you can have a large file inside a
>> compressed section inside a FV with File System2.
>>> 
>>> Feedback/thoughts/comments/Bug?
>>> 
>> 
>> Sean,
>> 
>> If I understand correctly you are stating that the contents of an Encapsulation
>> section should not have any restrictions on content type. The only error
>> checking should be that the raw encapsulation section data needs to fit into
>> the file type. That seems reasonable to me? I'm not sure if the PI spec makes
>> some statement that the code is enforcing, or I guess the PI spec could be
>> vague and people are interpreting it differently.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Here are some details of my scenario.
>>> Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-896185c32dd3
>>> (ffs3) Non compressed FV has filesystem ==
>>> 5473c07a-3dcb-4dca-bd6f-1e9689e7349a (ffs2)
>>> 
>>> VolInfo dump of the Non Compressed FV showing the nested/compressed
>> FV inside.
>>> 
>>> Decoding
>>> VolInfo Version 1.0 Build Build 20909
>>> Signature:        _FVH (4856465F)
>>> Attributes:       4FEFF
>>>      EFI_FVB2_READ_DISABLED_CAP
>>>      EFI_FVB2_READ_ENABLED_CAP
>>>      EFI_FVB2_READ_STATUS
>>>      EFI_FVB2_WRITE_DISABLED_CAP
>>>      EFI_FVB2_WRITE_ENABLED_CAP
>>>      EFI_FVB2_WRITE_STATUS
>>>      EFI_FVB2_LOCK_CAP
>>>      EFI_FVB2_LOCK_STATUS
>>>      EFI_FVB2_STICKY_WRITE
>>>      EFI_FVB2_MEMORY_MAPPED
>>>      EFI_FVB2_ERASE_POLARITY
>>>      EFI_FVB2_READ_LOCK_CAP
>>>      EFI_FVB2_READ_LOCK_STATUS
>>>      EFI_FVB2_WRITE_LOCK_CAP
>>>      EFI_FVB2_WRITE_LOCK_STATUS
>>>       EFI_FVB2_ALIGNMENT_16
>>>       EFI_FVB2_ALIGNMENT_32
>>>       EFI_FVB2_ALIGNMENT_64
>>>       EFI_FVB2_ALIGNMENT_128
>>>       EFI_FVB2_ALIGNMENT_4K
>>>       EFI_FVB2_ALIGNMENT_8K
>>>       EFI_FVB2_ALIGNMENT_16K
>>>       EFI_FVB2_ALIGNMENT_32K
>>>       EFI_FVB2_ALIGNMENT_1M
>>>       EFI_FVB2_ALIGNMENT_2M
>>>      EFI_FVB2_ALIGNMENT_4M
>>>       EFI_FVB2_ALIGNMENT_8M
>>>       EFI_FVB2_ALIGNMENT_256M
>>>       EFI_FVB2_ALIGNMENT_512M
>>>       EFI_FVB2_ALIGNMENT_1G
>>>       EFI_FVB2_ALIGNMENT_2G
>>> Header Length:         0x00000048
>>> File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
>>> Revision:              0x0002
>>> Number of Blocks:      0x00000028
>>> Block Length:          0x00010000
>>> Total Volume Size:     0x00280000
>>> 
>> ==========================================================
>> ==
>>> File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
>>> File Offset:      0x00000048
>>> File Length:      0x001F3FFD
>>> File Attributes:  0x00
>>> File State:       0xF8
>>>       EFI_FILE_DATA_VALID
>>> File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
>>> ------------------------------------------------------------
>>> Type:  EFI_SECTION_GUID_DEFINED
>>> Size:  0x001F3FE5
>>> SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
>>> 
>>> DataOffset:             0x0018
>>> Attributes:             0x0001
>>> ------------------------------------------------------------
>>> Type:  EFI_SECTION_RAW
>>> Size:  0x00000FF8
>>> ------------------------------------------------------------
>>> Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
>>> Size:  0x01010008
>>> 
>> ==========================================================
>> ==
>>> 
>>> Thanks
>>> Sean
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-20  0:11     ` Andrew Fish
@ 2016-10-20  0:15       ` Kinney, Michael D
  2016-10-20  1:50         ` Zeng, Star
  0 siblings, 1 reply; 13+ messages in thread
From: Kinney, Michael D @ 2016-10-20  0:15 UTC (permalink / raw)
  To: Andrew Fish, Sean Brogan, Kinney, Michael D; +Cc: edk2-devel@lists.01.org

Sean,

I agree this seems like a reasonable scenario.

Looks like the BaseTools allows generation of this content and the FW code
does not support unwrapping it, so there is a mismatch.

Please enter a Bugzilla issue for this and we can investigate further.

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish
> Sent: Thursday, October 20, 2016 8:12 AM
> To: Sean Brogan <sean.brogan@microsoft.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2 filesystem
> 
> 
> > On Oct 19, 2016, at 4:59 PM, Sean Brogan <sean.brogan@microsoft.com> wrote:
> >
> > Yes. I think the challenge in the code is the compressed section is a guided
> section and the decompression is all handled transparently.
> > One solution might be that once a section was processed that had attributes of
> EFI_GUIDED_SECTION_PROCESSING_REQUIRED then the check for filesystems should no
> longer be performed.
> >
> 
> That seems reasonable. Lets see what other people think.
> 
> We can also, independently, bring it up at the UEFI Forum to see if we need to
> clarify the PI spec.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks
> > Sean
> >
> >
> >> -----Original Message-----
> >> From: afish@apple.com [mailto:afish@apple.com]
> >> Sent: Wednesday, October 19, 2016 4:40 PM
> >> To: Sean Brogan <sean.brogan@microsoft.com>
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2
> >> filesystem
> >>
> >>
> >>> On Oct 19, 2016, at 4:09 PM, Sean Brogan <sean.brogan@microsoft.com>
> >> wrote:
> >>>
> >>> We have a condition that occurs when we boot where we see the following
> >> message and our boot fails because of it.
> >>> DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3
> >>> formatted FV.\n"));
> >>>
> >>> Which is on line 773 of FwVol.c (
> >>>
> >> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/
> >> Fw
> >>> Vol/FwVol.c )
> >>>
> >>> The condition is caused by a large firmware volume (greater than 16mb)
> >> that is compressed and put into a smaller FV (less than 16mb).  My question
> >> is why isn't this allowed (seems like a valid scenario).  Volinfo supports this
> >> and decodes binary fine.  The PI Vol 3 spec has a section 3.2.2
> >> EFI_FIRMWARE_FILE_SYSTEM3_GUID which says FileSystem2 doesn't
> >> support large files but it seems that the code is not taking into account that
> >> the section is compressed and therefore you can have a large file inside a
> >> compressed section inside a FV with File System2.
> >>>
> >>> Feedback/thoughts/comments/Bug?
> >>>
> >>
> >> Sean,
> >>
> >> If I understand correctly you are stating that the contents of an Encapsulation
> >> section should not have any restrictions on content type. The only error
> >> checking should be that the raw encapsulation section data needs to fit into
> >> the file type. That seems reasonable to me? I'm not sure if the PI spec makes
> >> some statement that the code is enforcing, or I guess the PI spec could be
> >> vague and people are interpreting it differently.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>> Here are some details of my scenario.
> >>> Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-896185c32dd3
> >>> (ffs3) Non compressed FV has filesystem ==
> >>> 5473c07a-3dcb-4dca-bd6f-1e9689e7349a (ffs2)
> >>>
> >>> VolInfo dump of the Non Compressed FV showing the nested/compressed
> >> FV inside.
> >>>
> >>> Decoding
> >>> VolInfo Version 1.0 Build Build 20909
> >>> Signature:        _FVH (4856465F)
> >>> Attributes:       4FEFF
> >>>      EFI_FVB2_READ_DISABLED_CAP
> >>>      EFI_FVB2_READ_ENABLED_CAP
> >>>      EFI_FVB2_READ_STATUS
> >>>      EFI_FVB2_WRITE_DISABLED_CAP
> >>>      EFI_FVB2_WRITE_ENABLED_CAP
> >>>      EFI_FVB2_WRITE_STATUS
> >>>      EFI_FVB2_LOCK_CAP
> >>>      EFI_FVB2_LOCK_STATUS
> >>>      EFI_FVB2_STICKY_WRITE
> >>>      EFI_FVB2_MEMORY_MAPPED
> >>>      EFI_FVB2_ERASE_POLARITY
> >>>      EFI_FVB2_READ_LOCK_CAP
> >>>      EFI_FVB2_READ_LOCK_STATUS
> >>>      EFI_FVB2_WRITE_LOCK_CAP
> >>>      EFI_FVB2_WRITE_LOCK_STATUS
> >>>       EFI_FVB2_ALIGNMENT_16
> >>>       EFI_FVB2_ALIGNMENT_32
> >>>       EFI_FVB2_ALIGNMENT_64
> >>>       EFI_FVB2_ALIGNMENT_128
> >>>       EFI_FVB2_ALIGNMENT_4K
> >>>       EFI_FVB2_ALIGNMENT_8K
> >>>       EFI_FVB2_ALIGNMENT_16K
> >>>       EFI_FVB2_ALIGNMENT_32K
> >>>       EFI_FVB2_ALIGNMENT_1M
> >>>       EFI_FVB2_ALIGNMENT_2M
> >>>      EFI_FVB2_ALIGNMENT_4M
> >>>       EFI_FVB2_ALIGNMENT_8M
> >>>       EFI_FVB2_ALIGNMENT_256M
> >>>       EFI_FVB2_ALIGNMENT_512M
> >>>       EFI_FVB2_ALIGNMENT_1G
> >>>       EFI_FVB2_ALIGNMENT_2G
> >>> Header Length:         0x00000048
> >>> File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> >>> Revision:              0x0002
> >>> Number of Blocks:      0x00000028
> >>> Block Length:          0x00010000
> >>> Total Volume Size:     0x00280000
> >>>
> >> ==========================================================
> >> ==
> >>> File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> >>> File Offset:      0x00000048
> >>> File Length:      0x001F3FFD
> >>> File Attributes:  0x00
> >>> File State:       0xF8
> >>>       EFI_FILE_DATA_VALID
> >>> File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> >>> ------------------------------------------------------------
> >>> Type:  EFI_SECTION_GUID_DEFINED
> >>> Size:  0x001F3FE5
> >>> SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> >>>
> >>> DataOffset:             0x0018
> >>> Attributes:             0x0001
> >>> ------------------------------------------------------------
> >>> Type:  EFI_SECTION_RAW
> >>> Size:  0x00000FF8
> >>> ------------------------------------------------------------
> >>> Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
> >>> Size:  0x01010008
> >>>
> >> ==========================================================
> >> ==
> >>>
> >>> Thanks
> >>> Sean
> >>> _______________________________________________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
> >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-20  0:15       ` Kinney, Michael D
@ 2016-10-20  1:50         ` Zeng, Star
  0 siblings, 0 replies; 13+ messages in thread
From: Zeng, Star @ 2016-10-20  1:50 UTC (permalink / raw)
  To: Kinney, Michael D, Andrew Fish, Sean Brogan, Kinney, Michael D
  Cc: edk2-devel@lists.01.org, Zhu, Yonghong, Gao, Liming, Zeng, Star

As I remember, the parent FV file system type will inherit the file system type of child file or even child FV in guided section.
See r2612 at https://svn.code.sf.net/p/edk2-buildtools/code/trunk/BaseTools/ that is the original BaseTools development trunk.

Which revision of BaseTools is being used? The behavior has been changed recently?


Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Kinney, Michael D
Sent: Thursday, October 20, 2016 8:15 AM
To: Andrew Fish <afish@apple.com>; Sean Brogan <sean.brogan@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2 filesystem

Sean,

I agree this seems like a reasonable scenario.

Looks like the BaseTools allows generation of this content and the FW code does not support unwrapping it, so there is a mismatch.

Please enter a Bugzilla issue for this and we can investigate further.

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of 
> Andrew Fish
> Sent: Thursday, October 20, 2016 8:12 AM
> To: Sean Brogan <sean.brogan@microsoft.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2 
> filesystem
> 
> 
> > On Oct 19, 2016, at 4:59 PM, Sean Brogan <sean.brogan@microsoft.com> wrote:
> >
> > Yes. I think the challenge in the code is the compressed section is 
> > a guided
> section and the decompression is all handled transparently.
> > One solution might be that once a section was processed that had 
> > attributes of
> EFI_GUIDED_SECTION_PROCESSING_REQUIRED then the check for filesystems 
> should no longer be performed.
> >
> 
> That seems reasonable. Lets see what other people think.
> 
> We can also, independently, bring it up at the UEFI Forum to see if we 
> need to clarify the PI spec.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks
> > Sean
> >
> >
> >> -----Original Message-----
> >> From: afish@apple.com [mailto:afish@apple.com]
> >> Sent: Wednesday, October 19, 2016 4:40 PM
> >> To: Sean Brogan <sean.brogan@microsoft.com>
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] question about a compressed Ffs3 file inside 
> >> FFS2 filesystem
> >>
> >>
> >>> On Oct 19, 2016, at 4:09 PM, Sean Brogan 
> >>> <sean.brogan@microsoft.com>
> >> wrote:
> >>>
> >>> We have a condition that occurs when we boot where we see the 
> >>> following
> >> message and our boot fails because of it.
> >>> DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3 
> >>> formatted FV.\n"));
> >>>
> >>> Which is on line 773 of FwVol.c (
> >>>
> >> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei
> >> /
> >> Fw
> >>> Vol/FwVol.c )
> >>>
> >>> The condition is caused by a large firmware volume (greater than 
> >>> 16mb)
> >> that is compressed and put into a smaller FV (less than 16mb).  My 
> >> question is why isn't this allowed (seems like a valid scenario).  
> >> Volinfo supports this and decodes binary fine.  The PI Vol 3 spec 
> >> has a section 3.2.2 EFI_FIRMWARE_FILE_SYSTEM3_GUID which says 
> >> FileSystem2 doesn't support large files but it seems that the code 
> >> is not taking into account that the section is compressed and 
> >> therefore you can have a large file inside a compressed section inside a FV with File System2.
> >>>
> >>> Feedback/thoughts/comments/Bug?
> >>>
> >>
> >> Sean,
> >>
> >> If I understand correctly you are stating that the contents of an 
> >> Encapsulation section should not have any restrictions on content 
> >> type. The only error checking should be that the raw encapsulation 
> >> section data needs to fit into the file type. That seems reasonable 
> >> to me? I'm not sure if the PI spec makes some statement that the 
> >> code is enforcing, or I guess the PI spec could be vague and people are interpreting it differently.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>> Here are some details of my scenario.
> >>> Compressed FV has filesystem == 
> >>> 8c8ce578-8a3d-4f1c-9935-896185c32dd3
> >>> (ffs3) Non compressed FV has filesystem == 
> >>> 5473c07a-3dcb-4dca-bd6f-1e9689e7349a (ffs2)
> >>>
> >>> VolInfo dump of the Non Compressed FV showing the 
> >>> nested/compressed
> >> FV inside.
> >>>
> >>> Decoding
> >>> VolInfo Version 1.0 Build Build 20909
> >>> Signature:        _FVH (4856465F)
> >>> Attributes:       4FEFF
> >>>      EFI_FVB2_READ_DISABLED_CAP
> >>>      EFI_FVB2_READ_ENABLED_CAP
> >>>      EFI_FVB2_READ_STATUS
> >>>      EFI_FVB2_WRITE_DISABLED_CAP
> >>>      EFI_FVB2_WRITE_ENABLED_CAP
> >>>      EFI_FVB2_WRITE_STATUS
> >>>      EFI_FVB2_LOCK_CAP
> >>>      EFI_FVB2_LOCK_STATUS
> >>>      EFI_FVB2_STICKY_WRITE
> >>>      EFI_FVB2_MEMORY_MAPPED
> >>>      EFI_FVB2_ERASE_POLARITY
> >>>      EFI_FVB2_READ_LOCK_CAP
> >>>      EFI_FVB2_READ_LOCK_STATUS
> >>>      EFI_FVB2_WRITE_LOCK_CAP
> >>>      EFI_FVB2_WRITE_LOCK_STATUS
> >>>       EFI_FVB2_ALIGNMENT_16
> >>>       EFI_FVB2_ALIGNMENT_32
> >>>       EFI_FVB2_ALIGNMENT_64
> >>>       EFI_FVB2_ALIGNMENT_128
> >>>       EFI_FVB2_ALIGNMENT_4K
> >>>       EFI_FVB2_ALIGNMENT_8K
> >>>       EFI_FVB2_ALIGNMENT_16K
> >>>       EFI_FVB2_ALIGNMENT_32K
> >>>       EFI_FVB2_ALIGNMENT_1M
> >>>       EFI_FVB2_ALIGNMENT_2M
> >>>      EFI_FVB2_ALIGNMENT_4M
> >>>       EFI_FVB2_ALIGNMENT_8M
> >>>       EFI_FVB2_ALIGNMENT_256M
> >>>       EFI_FVB2_ALIGNMENT_512M
> >>>       EFI_FVB2_ALIGNMENT_1G
> >>>       EFI_FVB2_ALIGNMENT_2G
> >>> Header Length:         0x00000048
> >>> File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> >>> Revision:              0x0002
> >>> Number of Blocks:      0x00000028
> >>> Block Length:          0x00010000
> >>> Total Volume Size:     0x00280000
> >>>
> >> ==========================================================
> >> ==
> >>> File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> >>> File Offset:      0x00000048
> >>> File Length:      0x001F3FFD
> >>> File Attributes:  0x00
> >>> File State:       0xF8
> >>>       EFI_FILE_DATA_VALID
> >>> File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> >>> ------------------------------------------------------------
> >>> Type:  EFI_SECTION_GUID_DEFINED
> >>> Size:  0x001F3FE5
> >>> SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> >>>
> >>> DataOffset:             0x0018
> >>> Attributes:             0x0001
> >>> ------------------------------------------------------------
> >>> Type:  EFI_SECTION_RAW
> >>> Size:  0x00000FF8
> >>> ------------------------------------------------------------
> >>> Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
> >>> Size:  0x01010008
> >>>
> >> ==========================================================
> >> ==
> >>>
> >>> Thanks
> >>> Sean
> >>> _______________________________________________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
> >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-19 23:09 question about a compressed Ffs3 file inside FFS2 filesystem Sean Brogan
  2016-10-19 23:39 ` Andrew Fish
@ 2016-10-20  8:27 ` Gao, Liming
  2016-10-20 14:49   ` Sean Brogan
  1 sibling, 1 reply; 13+ messages in thread
From: Gao, Liming @ 2016-10-20  8:27 UTC (permalink / raw)
  To: Sean Brogan, edk2-devel@lists.01.org

Sean:
  In MdePkg.dec, gEfiFirmwareFileSystem2Guid and gEfiFirmwareFileSystem3Guid are defined below. 
  gEfiFirmwareFileSystem2Guid     = { 0x8c8ce578, 0x8a3d, 0x4f1c, { 0x99, 0x35, 0x89, 0x61, 0x85, 0xc3, 0x2d, 0xd3 }}
gEfiFirmwareFileSystem3Guid      = { 0x5473c07a, 0x3dcb, 0x4dca, { 0xbd, 0x6f, 0x1e, 0x96, 0x89, 0xe7, 0x34, 0x9a }}

  From the dump message, the root FV File System ID is 5473c07a-3dcb-4dca-bd6f-1e9689e7349a. It is FF3 file system. 
  
Thanks
Liming
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Sean Brogan
> Sent: Thursday, October 20, 2016 7:09 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] question about a compressed Ffs3 file inside FFS2 filesystem
> 
> We have a condition that occurs when we boot where we see the following
> message and our boot fails because of it.
> DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3
> formatted FV.\n"));
> 
> Which is on line 773 of FwVol.c
> ( https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pe
> i/FwVol/FwVol.c )
> 
> The condition is caused by a large firmware volume (greater than 16mb) that
> is compressed and put into a smaller FV (less than 16mb).  My question is
> why isn't this allowed (seems like a valid scenario).  Volinfo supports this and
> decodes binary fine.  The PI Vol 3 spec has a section 3.2.2
> EFI_FIRMWARE_FILE_SYSTEM3_GUID which says FileSystem2 doesn't
> support large files but it seems that the code is not taking into account that
> the section is compressed and therefore you can have a large file inside a
> compressed section inside a FV with File System2.
> 
> Feedback/thoughts/comments/Bug?
> 
> Here are some details of my scenario.
> Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-896185c32dd3
> (ffs3)
> Non compressed FV has filesystem == 5473c07a-3dcb-4dca-bd6f-
> 1e9689e7349a (ffs2)
> 
> VolInfo dump of the Non Compressed FV showing the nested/compressed
> FV inside.
> 
> Decoding
> VolInfo Version 1.0 Build Build 20909
> Signature:        _FVH (4856465F)
> Attributes:       4FEFF
>        EFI_FVB2_READ_DISABLED_CAP
>        EFI_FVB2_READ_ENABLED_CAP
>        EFI_FVB2_READ_STATUS
>        EFI_FVB2_WRITE_DISABLED_CAP
>        EFI_FVB2_WRITE_ENABLED_CAP
>        EFI_FVB2_WRITE_STATUS
>        EFI_FVB2_LOCK_CAP
>        EFI_FVB2_LOCK_STATUS
>        EFI_FVB2_STICKY_WRITE
>        EFI_FVB2_MEMORY_MAPPED
>        EFI_FVB2_ERASE_POLARITY
>        EFI_FVB2_READ_LOCK_CAP
>        EFI_FVB2_READ_LOCK_STATUS
>        EFI_FVB2_WRITE_LOCK_CAP
>        EFI_FVB2_WRITE_LOCK_STATUS
>         EFI_FVB2_ALIGNMENT_16
>         EFI_FVB2_ALIGNMENT_32
>         EFI_FVB2_ALIGNMENT_64
>         EFI_FVB2_ALIGNMENT_128
>         EFI_FVB2_ALIGNMENT_4K
>         EFI_FVB2_ALIGNMENT_8K
>         EFI_FVB2_ALIGNMENT_16K
>         EFI_FVB2_ALIGNMENT_32K
>         EFI_FVB2_ALIGNMENT_1M
>         EFI_FVB2_ALIGNMENT_2M
>        EFI_FVB2_ALIGNMENT_4M
>         EFI_FVB2_ALIGNMENT_8M
>         EFI_FVB2_ALIGNMENT_256M
>         EFI_FVB2_ALIGNMENT_512M
>         EFI_FVB2_ALIGNMENT_1G
>         EFI_FVB2_ALIGNMENT_2G
> Header Length:         0x00000048
> File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> Revision:              0x0002
> Number of Blocks:      0x00000028
> Block Length:          0x00010000
> Total Volume Size:     0x00280000
> ==========================================================
> ==
> File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> File Offset:      0x00000048
> File Length:      0x001F3FFD
> File Attributes:  0x00
> File State:       0xF8
>         EFI_FILE_DATA_VALID
> File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> ------------------------------------------------------------
>   Type:  EFI_SECTION_GUID_DEFINED
>   Size:  0x001F3FE5
>   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> 
>   DataOffset:             0x0018
>   Attributes:             0x0001
> ------------------------------------------------------------
>   Type:  EFI_SECTION_RAW
>   Size:  0x00000FF8
> ------------------------------------------------------------
>   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
>   Size:  0x01010008
> ==========================================================
> ==
> 
> Thanks
> Sean
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-20  8:27 ` Gao, Liming
@ 2016-10-20 14:49   ` Sean Brogan
  2016-10-21  1:01     ` Zeng, Star
  0 siblings, 1 reply; 13+ messages in thread
From: Sean Brogan @ 2016-10-20 14:49 UTC (permalink / raw)
  To: Gao, Liming, edk2-devel@lists.01.org

Liming,

Good catch not sure how that happened. Unfortunately now the problem doesn't make sense.  The code should have IsFfs3Fv = True and the debug message that indicates the code path which ignores the section should not get executed.  I'll look at it again today as the problem still exists, just my analysis is incorrect.  

Current workaround is to make sure FFS2 sizes and guids are used everywhere so a problem with FFS3 is lurking somewhere.  

Thanks
Sean


> -----Original Message-----
> From: Gao, Liming [mailto:liming.gao@intel.com]
> Sent: Thursday, October 20, 2016 1:27 AM
> To: Sean Brogan <sean.brogan@microsoft.com>; edk2-devel@lists.01.org
> Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2 filesystem
> 
> Sean:
>   In MdePkg.dec, gEfiFirmwareFileSystem2Guid and
> gEfiFirmwareFileSystem3Guid are defined below.
>   gEfiFirmwareFileSystem2Guid     = { 0x8c8ce578, 0x8a3d, 0x4f1c, { 0x99, 0x35,
> 0x89, 0x61, 0x85, 0xc3, 0x2d, 0xd3 }}
> gEfiFirmwareFileSystem3Guid      = { 0x5473c07a, 0x3dcb, 0x4dca, { 0xbd, 0x6f,
> 0x1e, 0x96, 0x89, 0xe7, 0x34, 0x9a }}
> 
>   From the dump message, the root FV File System ID is 5473c07a-3dcb-4dca-
> bd6f-1e9689e7349a. It is FF3 file system.
> 
> Thanks
> Liming
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> > Sean Brogan
> > Sent: Thursday, October 20, 2016 7:09 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] question about a compressed Ffs3 file inside FFS2
> > filesystem
> >
> > We have a condition that occurs when we boot where we see the
> > following message and our boot fails because of it.
> > DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3
> > formatted FV.\n"));
> >
> > Which is on line 773 of FwVol.c
> > ( https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pe
> > i/FwVol/FwVol.c )
> >
> > The condition is caused by a large firmware volume (greater than 16mb)
> > that is compressed and put into a smaller FV (less than 16mb).  My
> > question is why isn't this allowed (seems like a valid scenario).
> > Volinfo supports this and decodes binary fine.  The PI Vol 3 spec has
> > a section 3.2.2 EFI_FIRMWARE_FILE_SYSTEM3_GUID which says FileSystem2
> > doesn't support large files but it seems that the code is not taking
> > into account that the section is compressed and therefore you can have
> > a large file inside a compressed section inside a FV with File System2.
> >
> > Feedback/thoughts/comments/Bug?
> >
> > Here are some details of my scenario.
> > Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-896185c32dd3
> > (ffs3)
> > Non compressed FV has filesystem == 5473c07a-3dcb-4dca-bd6f-
> > 1e9689e7349a (ffs2)
> >
> > VolInfo dump of the Non Compressed FV showing the nested/compressed FV
> > inside.
> >
> > Decoding
> > VolInfo Version 1.0 Build Build 20909
> > Signature:        _FVH (4856465F)
> > Attributes:       4FEFF
> >        EFI_FVB2_READ_DISABLED_CAP
> >        EFI_FVB2_READ_ENABLED_CAP
> >        EFI_FVB2_READ_STATUS
> >        EFI_FVB2_WRITE_DISABLED_CAP
> >        EFI_FVB2_WRITE_ENABLED_CAP
> >        EFI_FVB2_WRITE_STATUS
> >        EFI_FVB2_LOCK_CAP
> >        EFI_FVB2_LOCK_STATUS
> >        EFI_FVB2_STICKY_WRITE
> >        EFI_FVB2_MEMORY_MAPPED
> >        EFI_FVB2_ERASE_POLARITY
> >        EFI_FVB2_READ_LOCK_CAP
> >        EFI_FVB2_READ_LOCK_STATUS
> >        EFI_FVB2_WRITE_LOCK_CAP
> >        EFI_FVB2_WRITE_LOCK_STATUS
> >         EFI_FVB2_ALIGNMENT_16
> >         EFI_FVB2_ALIGNMENT_32
> >         EFI_FVB2_ALIGNMENT_64
> >         EFI_FVB2_ALIGNMENT_128
> >         EFI_FVB2_ALIGNMENT_4K
> >         EFI_FVB2_ALIGNMENT_8K
> >         EFI_FVB2_ALIGNMENT_16K
> >         EFI_FVB2_ALIGNMENT_32K
> >         EFI_FVB2_ALIGNMENT_1M
> >         EFI_FVB2_ALIGNMENT_2M
> >        EFI_FVB2_ALIGNMENT_4M
> >         EFI_FVB2_ALIGNMENT_8M
> >         EFI_FVB2_ALIGNMENT_256M
> >         EFI_FVB2_ALIGNMENT_512M
> >         EFI_FVB2_ALIGNMENT_1G
> >         EFI_FVB2_ALIGNMENT_2G
> > Header Length:         0x00000048
> > File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> > Revision:              0x0002
> > Number of Blocks:      0x00000028
> > Block Length:          0x00010000
> > Total Volume Size:     0x00280000
> > ==========================================================
> > ==
> > File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> > File Offset:      0x00000048
> > File Length:      0x001F3FFD
> > File Attributes:  0x00
> > File State:       0xF8
> >         EFI_FILE_DATA_VALID
> > File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> > ------------------------------------------------------------
> >   Type:  EFI_SECTION_GUID_DEFINED
> >   Size:  0x001F3FE5
> >   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> >
> >   DataOffset:             0x0018
> >   Attributes:             0x0001
> > ------------------------------------------------------------
> >   Type:  EFI_SECTION_RAW
> >   Size:  0x00000FF8
> > ------------------------------------------------------------
> >   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
> >   Size:  0x01010008
> > ==========================================================
> > ==
> >
> > Thanks
> > Sean
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-20 14:49   ` Sean Brogan
@ 2016-10-21  1:01     ` Zeng, Star
  2016-10-21 16:39       ` Sean Brogan
  0 siblings, 1 reply; 13+ messages in thread
From: Zeng, Star @ 2016-10-21  1:01 UTC (permalink / raw)
  To: Sean Brogan, Gao, Liming, edk2-devel@lists.01.org; +Cc: Zeng, Star

Sean,

I guess the codes are reporting FvInfo PPI like below that makes the problem.

      PeiServicesInstallFvInfoPpi(
        NULL,
        (VOID *)PcdGet32(PcdFlashFvXXXBase),
        PcdGet32(PcdFlashFvXXXSize),
        NULL,
        NULL
        );

PeiServicesInstallFvInfoPpi() has below comments for FvFormat parameter.
  @param  FvFormat             Unique identifier of the format of the memory-mapped
                               firmware volume.  This parameter is optional and
                               may be NULL.  If NULL is specified, the
                               *EFI_FIRMWARE_FILE_SYSTEM2_GUID* format is assumed.

I suggest the codes can be updated to:

      PeiServicesInstallFvInfoPpi(
        &(((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32(PcdFlashFvXXXBase))->FileSystemGuid),
        (VOID *)PcdGet32(PcdFlashFvXXXBase),
        PcdGet32(PcdFlashFvXXXSize),
        NULL,
        NULL
        );

Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Sean Brogan
Sent: Thursday, October 20, 2016 10:49 PM
To: Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org
Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2 filesystem

Liming,

Good catch not sure how that happened. Unfortunately now the problem doesn't make sense.  The code should have IsFfs3Fv = True and the debug message that indicates the code path which ignores the section should not get executed.  I'll look at it again today as the problem still exists, just my analysis is incorrect.  

Current workaround is to make sure FFS2 sizes and guids are used everywhere so a problem with FFS3 is lurking somewhere.  

Thanks
Sean


> -----Original Message-----
> From: Gao, Liming [mailto:liming.gao@intel.com]
> Sent: Thursday, October 20, 2016 1:27 AM
> To: Sean Brogan <sean.brogan@microsoft.com>; edk2-devel@lists.01.org
> Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2 
> filesystem
> 
> Sean:
>   In MdePkg.dec, gEfiFirmwareFileSystem2Guid and 
> gEfiFirmwareFileSystem3Guid are defined below.
>   gEfiFirmwareFileSystem2Guid     = { 0x8c8ce578, 0x8a3d, 0x4f1c, { 0x99, 0x35,
> 0x89, 0x61, 0x85, 0xc3, 0x2d, 0xd3 }}
> gEfiFirmwareFileSystem3Guid      = { 0x5473c07a, 0x3dcb, 0x4dca, { 0xbd, 0x6f,
> 0x1e, 0x96, 0x89, 0xe7, 0x34, 0x9a }}
> 
>   From the dump message, the root FV File System ID is 
> 5473c07a-3dcb-4dca- bd6f-1e9689e7349a. It is FF3 file system.
> 
> Thanks
> Liming
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf 
> > Of Sean Brogan
> > Sent: Thursday, October 20, 2016 7:09 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] question about a compressed Ffs3 file inside FFS2 
> > filesystem
> >
> > We have a condition that occurs when we boot where we see the 
> > following message and our boot fails because of it.
> > DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3 
> > formatted FV.\n"));
> >
> > Which is on line 773 of FwVol.c
> > ( https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pe
> > i/FwVol/FwVol.c )
> >
> > The condition is caused by a large firmware volume (greater than 
> > 16mb) that is compressed and put into a smaller FV (less than 16mb).  
> > My question is why isn't this allowed (seems like a valid scenario).
> > Volinfo supports this and decodes binary fine.  The PI Vol 3 spec 
> > has a section 3.2.2 EFI_FIRMWARE_FILE_SYSTEM3_GUID which says 
> > FileSystem2 doesn't support large files but it seems that the code 
> > is not taking into account that the section is compressed and 
> > therefore you can have a large file inside a compressed section inside a FV with File System2.
> >
> > Feedback/thoughts/comments/Bug?
> >
> > Here are some details of my scenario.
> > Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-896185c32dd3
> > (ffs3)
> > Non compressed FV has filesystem == 5473c07a-3dcb-4dca-bd6f- 
> > 1e9689e7349a (ffs2)
> >
> > VolInfo dump of the Non Compressed FV showing the nested/compressed 
> > FV inside.
> >
> > Decoding
> > VolInfo Version 1.0 Build Build 20909
> > Signature:        _FVH (4856465F)
> > Attributes:       4FEFF
> >        EFI_FVB2_READ_DISABLED_CAP
> >        EFI_FVB2_READ_ENABLED_CAP
> >        EFI_FVB2_READ_STATUS
> >        EFI_FVB2_WRITE_DISABLED_CAP
> >        EFI_FVB2_WRITE_ENABLED_CAP
> >        EFI_FVB2_WRITE_STATUS
> >        EFI_FVB2_LOCK_CAP
> >        EFI_FVB2_LOCK_STATUS
> >        EFI_FVB2_STICKY_WRITE
> >        EFI_FVB2_MEMORY_MAPPED
> >        EFI_FVB2_ERASE_POLARITY
> >        EFI_FVB2_READ_LOCK_CAP
> >        EFI_FVB2_READ_LOCK_STATUS
> >        EFI_FVB2_WRITE_LOCK_CAP
> >        EFI_FVB2_WRITE_LOCK_STATUS
> >         EFI_FVB2_ALIGNMENT_16
> >         EFI_FVB2_ALIGNMENT_32
> >         EFI_FVB2_ALIGNMENT_64
> >         EFI_FVB2_ALIGNMENT_128
> >         EFI_FVB2_ALIGNMENT_4K
> >         EFI_FVB2_ALIGNMENT_8K
> >         EFI_FVB2_ALIGNMENT_16K
> >         EFI_FVB2_ALIGNMENT_32K
> >         EFI_FVB2_ALIGNMENT_1M
> >         EFI_FVB2_ALIGNMENT_2M
> >        EFI_FVB2_ALIGNMENT_4M
> >         EFI_FVB2_ALIGNMENT_8M
> >         EFI_FVB2_ALIGNMENT_256M
> >         EFI_FVB2_ALIGNMENT_512M
> >         EFI_FVB2_ALIGNMENT_1G
> >         EFI_FVB2_ALIGNMENT_2G
> > Header Length:         0x00000048
> > File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> > Revision:              0x0002
> > Number of Blocks:      0x00000028
> > Block Length:          0x00010000
> > Total Volume Size:     0x00280000
> > ==========================================================
> > ==
> > File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> > File Offset:      0x00000048
> > File Length:      0x001F3FFD
> > File Attributes:  0x00
> > File State:       0xF8
> >         EFI_FILE_DATA_VALID
> > File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> > ------------------------------------------------------------
> >   Type:  EFI_SECTION_GUID_DEFINED
> >   Size:  0x001F3FE5
> >   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> >
> >   DataOffset:             0x0018
> >   Attributes:             0x0001
> > ------------------------------------------------------------
> >   Type:  EFI_SECTION_RAW
> >   Size:  0x00000FF8
> > ------------------------------------------------------------
> >   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
> >   Size:  0x01010008
> > ==========================================================
> > ==
> >
> > Thanks
> > Sean
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-21  1:01     ` Zeng, Star
@ 2016-10-21 16:39       ` Sean Brogan
  2016-10-22 10:41         ` Zeng, Star
  0 siblings, 1 reply; 13+ messages in thread
From: Sean Brogan @ 2016-10-21 16:39 UTC (permalink / raw)
  To: Zeng, Star, Gao, Liming, edk2-devel@lists.01.org

Star,  

Thanks.  That was the issue and that fixed the problem.   How about adding an assert in PeiServicesLib?  

MdePkg\Library\PeiServicesLib\PeiServicesLib.c ~ line 642 

add the assert for the else case.  

if (FvFormat != NULL) {
    CopyGuid (&FvInfoPpi->FvFormat, FvFormat);
  } else {
    CopyGuid (&FvInfoPpi->FvFormat, &gEfiFirmwareFileSystem2Guid);
    //Since FileSystem 2 is being assumed check the FV
    //Check that the File system matches.  
    ASSERT(CompareGuid(&(((EFI_FIRMWARE_VOLUME_HEADER *)FvInfo)->FileSystemGuid), &gEfiFirmwareFileSystem2Guid));
  }


Thanks again
Sean


This email message may contain confidential and privileged information.  Any unauthorized use is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

> -----Original Message-----
> From: Zeng, Star [mailto:star.zeng@intel.com]
> Sent: Thursday, October 20, 2016 6:02 PM
> To: Sean Brogan <sean.brogan@microsoft.com>; Gao, Liming
> <liming.gao@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.zeng@intel.com>
> Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2
> filesystem
> 
> Sean,
> 
> I guess the codes are reporting FvInfo PPI like below that makes the
> problem.
> 
>       PeiServicesInstallFvInfoPpi(
>         NULL,
>         (VOID *)PcdGet32(PcdFlashFvXXXBase),
>         PcdGet32(PcdFlashFvXXXSize),
>         NULL,
>         NULL
>         );
> 
> PeiServicesInstallFvInfoPpi() has below comments for FvFormat parameter.
>   @param  FvFormat             Unique identifier of the format of the memory-
> mapped
>                                firmware volume.  This parameter is optional and
>                                may be NULL.  If NULL is specified, the
>                                *EFI_FIRMWARE_FILE_SYSTEM2_GUID* format is assumed.
> 
> I suggest the codes can be updated to:
> 
>       PeiServicesInstallFvInfoPpi(
>         &(((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN)
> PcdGet32(PcdFlashFvXXXBase))->FileSystemGuid),
>         (VOID *)PcdGet32(PcdFlashFvXXXBase),
>         PcdGet32(PcdFlashFvXXXSize),
>         NULL,
>         NULL
>         );
> 
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Sean Brogan
> Sent: Thursday, October 20, 2016 10:49 PM
> To: Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2
> filesystem
> 
> Liming,
> 
> Good catch not sure how that happened. Unfortunately now the problem
> doesn't make sense.  The code should have IsFfs3Fv = True and the debug
> message that indicates the code path which ignores the section should not
> get executed.  I'll look at it again today as the problem still exists, just my
> analysis is incorrect.
> 
> Current workaround is to make sure FFS2 sizes and guids are used
> everywhere so a problem with FFS3 is lurking somewhere.
> 
> Thanks
> Sean
> 
> 
> > -----Original Message-----
> > From: Gao, Liming [mailto:liming.gao@intel.com]
> > Sent: Thursday, October 20, 2016 1:27 AM
> > To: Sean Brogan <sean.brogan@microsoft.com>; edk2-devel@lists.01.org
> > Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2
> > filesystem
> >
> > Sean:
> >   In MdePkg.dec, gEfiFirmwareFileSystem2Guid and
> > gEfiFirmwareFileSystem3Guid are defined below.
> >   gEfiFirmwareFileSystem2Guid     = { 0x8c8ce578, 0x8a3d, 0x4f1c, { 0x99,
> 0x35,
> > 0x89, 0x61, 0x85, 0xc3, 0x2d, 0xd3 }}
> > gEfiFirmwareFileSystem3Guid      = { 0x5473c07a, 0x3dcb, 0x4dca, { 0xbd,
> 0x6f,
> > 0x1e, 0x96, 0x89, 0xe7, 0x34, 0x9a }}
> >
> >   From the dump message, the root FV File System ID is
> > 5473c07a-3dcb-4dca- bd6f-1e9689e7349a. It is FF3 file system.
> >
> > Thanks
> > Liming
> > > -----Original Message-----
> > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
> > > Of Sean Brogan
> > > Sent: Thursday, October 20, 2016 7:09 AM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] question about a compressed Ffs3 file inside FFS2
> > > filesystem
> > >
> > > We have a condition that occurs when we boot where we see the
> > > following message and our boot fails because of it.
> > > DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3
> > > formatted FV.\n"));
> > >
> > > Which is on line 773 of FwVol.c
> > > (
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pe
> > > i/FwVol/FwVol.c )
> > >
> > > The condition is caused by a large firmware volume (greater than
> > > 16mb) that is compressed and put into a smaller FV (less than 16mb).
> > > My question is why isn't this allowed (seems like a valid scenario).
> > > Volinfo supports this and decodes binary fine.  The PI Vol 3 spec
> > > has a section 3.2.2 EFI_FIRMWARE_FILE_SYSTEM3_GUID which says
> > > FileSystem2 doesn't support large files but it seems that the code
> > > is not taking into account that the section is compressed and
> > > therefore you can have a large file inside a compressed section inside a
> FV with File System2.
> > >
> > > Feedback/thoughts/comments/Bug?
> > >
> > > Here are some details of my scenario.
> > > Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-
> 896185c32dd3
> > > (ffs3)
> > > Non compressed FV has filesystem == 5473c07a-3dcb-4dca-bd6f-
> > > 1e9689e7349a (ffs2)
> > >
> > > VolInfo dump of the Non Compressed FV showing the
> nested/compressed
> > > FV inside.
> > >
> > > Decoding
> > > VolInfo Version 1.0 Build Build 20909
> > > Signature:        _FVH (4856465F)
> > > Attributes:       4FEFF
> > >        EFI_FVB2_READ_DISABLED_CAP
> > >        EFI_FVB2_READ_ENABLED_CAP
> > >        EFI_FVB2_READ_STATUS
> > >        EFI_FVB2_WRITE_DISABLED_CAP
> > >        EFI_FVB2_WRITE_ENABLED_CAP
> > >        EFI_FVB2_WRITE_STATUS
> > >        EFI_FVB2_LOCK_CAP
> > >        EFI_FVB2_LOCK_STATUS
> > >        EFI_FVB2_STICKY_WRITE
> > >        EFI_FVB2_MEMORY_MAPPED
> > >        EFI_FVB2_ERASE_POLARITY
> > >        EFI_FVB2_READ_LOCK_CAP
> > >        EFI_FVB2_READ_LOCK_STATUS
> > >        EFI_FVB2_WRITE_LOCK_CAP
> > >        EFI_FVB2_WRITE_LOCK_STATUS
> > >         EFI_FVB2_ALIGNMENT_16
> > >         EFI_FVB2_ALIGNMENT_32
> > >         EFI_FVB2_ALIGNMENT_64
> > >         EFI_FVB2_ALIGNMENT_128
> > >         EFI_FVB2_ALIGNMENT_4K
> > >         EFI_FVB2_ALIGNMENT_8K
> > >         EFI_FVB2_ALIGNMENT_16K
> > >         EFI_FVB2_ALIGNMENT_32K
> > >         EFI_FVB2_ALIGNMENT_1M
> > >         EFI_FVB2_ALIGNMENT_2M
> > >        EFI_FVB2_ALIGNMENT_4M
> > >         EFI_FVB2_ALIGNMENT_8M
> > >         EFI_FVB2_ALIGNMENT_256M
> > >         EFI_FVB2_ALIGNMENT_512M
> > >         EFI_FVB2_ALIGNMENT_1G
> > >         EFI_FVB2_ALIGNMENT_2G
> > > Header Length:         0x00000048
> > > File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> > > Revision:              0x0002
> > > Number of Blocks:      0x00000028
> > > Block Length:          0x00010000
> > > Total Volume Size:     0x00280000
> > >
> ==========================================================
> > > ==
> > > File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> > > File Offset:      0x00000048
> > > File Length:      0x001F3FFD
> > > File Attributes:  0x00
> > > File State:       0xF8
> > >         EFI_FILE_DATA_VALID
> > > File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> > > ------------------------------------------------------------
> > >   Type:  EFI_SECTION_GUID_DEFINED
> > >   Size:  0x001F3FE5
> > >   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> > >
> > >   DataOffset:             0x0018
> > >   Attributes:             0x0001
> > > ------------------------------------------------------------
> > >   Type:  EFI_SECTION_RAW
> > >   Size:  0x00000FF8
> > > ------------------------------------------------------------
> > >   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
> > >   Size:  0x01010008
> > >
> ==========================================================
> > > ==
> > >
> > > Thanks
> > > Sean
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-21 16:39       ` Sean Brogan
@ 2016-10-22 10:41         ` Zeng, Star
  2016-10-24  2:15           ` Gao, Liming
  0 siblings, 1 reply; 13+ messages in thread
From: Zeng, Star @ 2016-10-22 10:41 UTC (permalink / raw)
  To: Sean Brogan, Gao, Liming, edk2-devel@lists.01.org; +Cc: Zeng, Star

I think adding the assert makes sense and makes the same issue to be caught easily in the further, could you help file a bugzilla bug to track it?

Thanks,
Star
-----Original Message-----
From: Sean Brogan [mailto:sean.brogan@microsoft.com] 
Sent: Saturday, October 22, 2016 12:40 AM
To: Zeng, Star <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org
Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2 filesystem

Star,  

Thanks.  That was the issue and that fixed the problem.   How about adding an assert in PeiServicesLib?  

MdePkg\Library\PeiServicesLib\PeiServicesLib.c ~ line 642 

add the assert for the else case.  

if (FvFormat != NULL) {
    CopyGuid (&FvInfoPpi->FvFormat, FvFormat);
  } else {
    CopyGuid (&FvInfoPpi->FvFormat, &gEfiFirmwareFileSystem2Guid);
    //Since FileSystem 2 is being assumed check the FV
    //Check that the File system matches.  
    ASSERT(CompareGuid(&(((EFI_FIRMWARE_VOLUME_HEADER *)FvInfo)->FileSystemGuid), &gEfiFirmwareFileSystem2Guid));
  }


Thanks again
Sean


This email message may contain confidential and privileged information.  Any unauthorized use is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

> -----Original Message-----
> From: Zeng, Star [mailto:star.zeng@intel.com]
> Sent: Thursday, October 20, 2016 6:02 PM
> To: Sean Brogan <sean.brogan@microsoft.com>; Gao, Liming 
> <liming.gao@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.zeng@intel.com>
> Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2 
> filesystem
> 
> Sean,
> 
> I guess the codes are reporting FvInfo PPI like below that makes the 
> problem.
> 
>       PeiServicesInstallFvInfoPpi(
>         NULL,
>         (VOID *)PcdGet32(PcdFlashFvXXXBase),
>         PcdGet32(PcdFlashFvXXXSize),
>         NULL,
>         NULL
>         );
> 
> PeiServicesInstallFvInfoPpi() has below comments for FvFormat parameter.
>   @param  FvFormat             Unique identifier of the format of the memory-
> mapped
>                                firmware volume.  This parameter is optional and
>                                may be NULL.  If NULL is specified, the
>                                *EFI_FIRMWARE_FILE_SYSTEM2_GUID* format is assumed.
> 
> I suggest the codes can be updated to:
> 
>       PeiServicesInstallFvInfoPpi(
>         &(((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) 
> PcdGet32(PcdFlashFvXXXBase))->FileSystemGuid),
>         (VOID *)PcdGet32(PcdFlashFvXXXBase),
>         PcdGet32(PcdFlashFvXXXSize),
>         NULL,
>         NULL
>         );
> 
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of 
> Sean Brogan
> Sent: Thursday, October 20, 2016 10:49 PM
> To: Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2 
> filesystem
> 
> Liming,
> 
> Good catch not sure how that happened. Unfortunately now the problem 
> doesn't make sense.  The code should have IsFfs3Fv = True and the 
> debug message that indicates the code path which ignores the section 
> should not get executed.  I'll look at it again today as the problem 
> still exists, just my analysis is incorrect.
> 
> Current workaround is to make sure FFS2 sizes and guids are used 
> everywhere so a problem with FFS3 is lurking somewhere.
> 
> Thanks
> Sean
> 
> 
> > -----Original Message-----
> > From: Gao, Liming [mailto:liming.gao@intel.com]
> > Sent: Thursday, October 20, 2016 1:27 AM
> > To: Sean Brogan <sean.brogan@microsoft.com>; edk2-devel@lists.01.org
> > Subject: RE: [edk2] question about a compressed Ffs3 file inside 
> > FFS2 filesystem
> >
> > Sean:
> >   In MdePkg.dec, gEfiFirmwareFileSystem2Guid and 
> > gEfiFirmwareFileSystem3Guid are defined below.
> >   gEfiFirmwareFileSystem2Guid     = { 0x8c8ce578, 0x8a3d, 0x4f1c, { 0x99,
> 0x35,
> > 0x89, 0x61, 0x85, 0xc3, 0x2d, 0xd3 }}
> > gEfiFirmwareFileSystem3Guid      = { 0x5473c07a, 0x3dcb, 0x4dca, { 0xbd,
> 0x6f,
> > 0x1e, 0x96, 0x89, 0xe7, 0x34, 0x9a }}
> >
> >   From the dump message, the root FV File System ID is
> > 5473c07a-3dcb-4dca- bd6f-1e9689e7349a. It is FF3 file system.
> >
> > Thanks
> > Liming
> > > -----Original Message-----
> > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On 
> > > Behalf Of Sean Brogan
> > > Sent: Thursday, October 20, 2016 7:09 AM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] question about a compressed Ffs3 file inside FFS2 
> > > filesystem
> > >
> > > We have a condition that occurs when we boot where we see the 
> > > following message and our boot fails because of it.
> > > DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3 
> > > formatted FV.\n"));
> > >
> > > Which is on line 773 of FwVol.c
> > > (
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pe
> > > i/FwVol/FwVol.c )
> > >
> > > The condition is caused by a large firmware volume (greater than
> > > 16mb) that is compressed and put into a smaller FV (less than 16mb).
> > > My question is why isn't this allowed (seems like a valid scenario).
> > > Volinfo supports this and decodes binary fine.  The PI Vol 3 spec 
> > > has a section 3.2.2 EFI_FIRMWARE_FILE_SYSTEM3_GUID which says
> > > FileSystem2 doesn't support large files but it seems that the code 
> > > is not taking into account that the section is compressed and 
> > > therefore you can have a large file inside a compressed section 
> > > inside a
> FV with File System2.
> > >
> > > Feedback/thoughts/comments/Bug?
> > >
> > > Here are some details of my scenario.
> > > Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-
> 896185c32dd3
> > > (ffs3)
> > > Non compressed FV has filesystem == 5473c07a-3dcb-4dca-bd6f- 
> > > 1e9689e7349a (ffs2)
> > >
> > > VolInfo dump of the Non Compressed FV showing the
> nested/compressed
> > > FV inside.
> > >
> > > Decoding
> > > VolInfo Version 1.0 Build Build 20909
> > > Signature:        _FVH (4856465F)
> > > Attributes:       4FEFF
> > >        EFI_FVB2_READ_DISABLED_CAP
> > >        EFI_FVB2_READ_ENABLED_CAP
> > >        EFI_FVB2_READ_STATUS
> > >        EFI_FVB2_WRITE_DISABLED_CAP
> > >        EFI_FVB2_WRITE_ENABLED_CAP
> > >        EFI_FVB2_WRITE_STATUS
> > >        EFI_FVB2_LOCK_CAP
> > >        EFI_FVB2_LOCK_STATUS
> > >        EFI_FVB2_STICKY_WRITE
> > >        EFI_FVB2_MEMORY_MAPPED
> > >        EFI_FVB2_ERASE_POLARITY
> > >        EFI_FVB2_READ_LOCK_CAP
> > >        EFI_FVB2_READ_LOCK_STATUS
> > >        EFI_FVB2_WRITE_LOCK_CAP
> > >        EFI_FVB2_WRITE_LOCK_STATUS
> > >         EFI_FVB2_ALIGNMENT_16
> > >         EFI_FVB2_ALIGNMENT_32
> > >         EFI_FVB2_ALIGNMENT_64
> > >         EFI_FVB2_ALIGNMENT_128
> > >         EFI_FVB2_ALIGNMENT_4K
> > >         EFI_FVB2_ALIGNMENT_8K
> > >         EFI_FVB2_ALIGNMENT_16K
> > >         EFI_FVB2_ALIGNMENT_32K
> > >         EFI_FVB2_ALIGNMENT_1M
> > >         EFI_FVB2_ALIGNMENT_2M
> > >        EFI_FVB2_ALIGNMENT_4M
> > >         EFI_FVB2_ALIGNMENT_8M
> > >         EFI_FVB2_ALIGNMENT_256M
> > >         EFI_FVB2_ALIGNMENT_512M
> > >         EFI_FVB2_ALIGNMENT_1G
> > >         EFI_FVB2_ALIGNMENT_2G
> > > Header Length:         0x00000048
> > > File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> > > Revision:              0x0002
> > > Number of Blocks:      0x00000028
> > > Block Length:          0x00010000
> > > Total Volume Size:     0x00280000
> > >
> ==========================================================
> > > ==
> > > File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> > > File Offset:      0x00000048
> > > File Length:      0x001F3FFD
> > > File Attributes:  0x00
> > > File State:       0xF8
> > >         EFI_FILE_DATA_VALID
> > > File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> > > ------------------------------------------------------------
> > >   Type:  EFI_SECTION_GUID_DEFINED
> > >   Size:  0x001F3FE5
> > >   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> > >
> > >   DataOffset:             0x0018
> > >   Attributes:             0x0001
> > > ------------------------------------------------------------
> > >   Type:  EFI_SECTION_RAW
> > >   Size:  0x00000FF8
> > > ------------------------------------------------------------
> > >   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
> > >   Size:  0x01010008
> > >
> ==========================================================
> > > ==
> > >
> > > Thanks
> > > Sean
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: question about a compressed Ffs3 file inside FFS2 filesystem
  2016-10-22 10:41         ` Zeng, Star
@ 2016-10-24  2:15           ` Gao, Liming
  0 siblings, 0 replies; 13+ messages in thread
From: Gao, Liming @ 2016-10-24  2:15 UTC (permalink / raw)
  To: Zeng, Star, Sean Brogan, edk2-devel@lists.01.org

Star:
 One https://tianocore.acgmultimedia.com/show_bug.cgi?id=160 has been submitted. 

Thanks
Liming
> -----Original Message-----
> From: Zeng, Star
> Sent: Saturday, October 22, 2016 6:42 PM
> To: Sean Brogan <sean.brogan@microsoft.com>; Gao, Liming
> <liming.gao@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.zeng@intel.com>
> Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2
> filesystem
> 
> I think adding the assert makes sense and makes the same issue to be caught
> easily in the further, could you help file a bugzilla bug to track it?
> 
> Thanks,
> Star
> -----Original Message-----
> From: Sean Brogan [mailto:sean.brogan@microsoft.com]
> Sent: Saturday, October 22, 2016 12:40 AM
> To: Zeng, Star <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>;
> edk2-devel@lists.01.org
> Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2
> filesystem
> 
> Star,
> 
> Thanks.  That was the issue and that fixed the problem.   How about adding
> an assert in PeiServicesLib?
> 
> MdePkg\Library\PeiServicesLib\PeiServicesLib.c ~ line 642
> 
> add the assert for the else case.
> 
> if (FvFormat != NULL) {
>     CopyGuid (&FvInfoPpi->FvFormat, FvFormat);
>   } else {
>     CopyGuid (&FvInfoPpi->FvFormat, &gEfiFirmwareFileSystem2Guid);
>     //Since FileSystem 2 is being assumed check the FV
>     //Check that the File system matches.
>     ASSERT(CompareGuid(&(((EFI_FIRMWARE_VOLUME_HEADER *)FvInfo)-
> >FileSystemGuid), &gEfiFirmwareFileSystem2Guid));
>   }
> 
> 
> Thanks again
> Sean
> 
> 
> This email message may contain confidential and privileged information.  Any
> unauthorized use is prohibited.  If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message.
> 
> > -----Original Message-----
> > From: Zeng, Star [mailto:star.zeng@intel.com]
> > Sent: Thursday, October 20, 2016 6:02 PM
> > To: Sean Brogan <sean.brogan@microsoft.com>; Gao, Liming
> > <liming.gao@intel.com>; edk2-devel@lists.01.org
> > Cc: Zeng, Star <star.zeng@intel.com>
> > Subject: RE: [edk2] question about a compressed Ffs3 file inside FFS2
> > filesystem
> >
> > Sean,
> >
> > I guess the codes are reporting FvInfo PPI like below that makes the
> > problem.
> >
> >       PeiServicesInstallFvInfoPpi(
> >         NULL,
> >         (VOID *)PcdGet32(PcdFlashFvXXXBase),
> >         PcdGet32(PcdFlashFvXXXSize),
> >         NULL,
> >         NULL
> >         );
> >
> > PeiServicesInstallFvInfoPpi() has below comments for FvFormat parameter.
> >   @param  FvFormat             Unique identifier of the format of the memory-
> > mapped
> >                                firmware volume.  This parameter is optional and
> >                                may be NULL.  If NULL is specified, the
> >                                *EFI_FIRMWARE_FILE_SYSTEM2_GUID* format is assumed.
> >
> > I suggest the codes can be updated to:
> >
> >       PeiServicesInstallFvInfoPpi(
> >         &(((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN)
> > PcdGet32(PcdFlashFvXXXBase))->FileSystemGuid),
> >         (VOID *)PcdGet32(PcdFlashFvXXXBase),
> >         PcdGet32(PcdFlashFvXXXSize),
> >         NULL,
> >         NULL
> >         );
> >
> > Thanks,
> > Star
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> > Sean Brogan
> > Sent: Thursday, October 20, 2016 10:49 PM
> > To: Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org
> > Subject: Re: [edk2] question about a compressed Ffs3 file inside FFS2
> > filesystem
> >
> > Liming,
> >
> > Good catch not sure how that happened. Unfortunately now the problem
> > doesn't make sense.  The code should have IsFfs3Fv = True and the
> > debug message that indicates the code path which ignores the section
> > should not get executed.  I'll look at it again today as the problem
> > still exists, just my analysis is incorrect.
> >
> > Current workaround is to make sure FFS2 sizes and guids are used
> > everywhere so a problem with FFS3 is lurking somewhere.
> >
> > Thanks
> > Sean
> >
> >
> > > -----Original Message-----
> > > From: Gao, Liming [mailto:liming.gao@intel.com]
> > > Sent: Thursday, October 20, 2016 1:27 AM
> > > To: Sean Brogan <sean.brogan@microsoft.com>; edk2-devel@lists.01.org
> > > Subject: RE: [edk2] question about a compressed Ffs3 file inside
> > > FFS2 filesystem
> > >
> > > Sean:
> > >   In MdePkg.dec, gEfiFirmwareFileSystem2Guid and
> > > gEfiFirmwareFileSystem3Guid are defined below.
> > >   gEfiFirmwareFileSystem2Guid     = { 0x8c8ce578, 0x8a3d, 0x4f1c, { 0x99,
> > 0x35,
> > > 0x89, 0x61, 0x85, 0xc3, 0x2d, 0xd3 }}
> > > gEfiFirmwareFileSystem3Guid      = { 0x5473c07a, 0x3dcb, 0x4dca, { 0xbd,
> > 0x6f,
> > > 0x1e, 0x96, 0x89, 0xe7, 0x34, 0x9a }}
> > >
> > >   From the dump message, the root FV File System ID is
> > > 5473c07a-3dcb-4dca- bd6f-1e9689e7349a. It is FF3 file system.
> > >
> > > Thanks
> > > Liming
> > > > -----Original Message-----
> > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
> > > > Behalf Of Sean Brogan
> > > > Sent: Thursday, October 20, 2016 7:09 AM
> > > > To: edk2-devel@lists.01.org
> > > > Subject: [edk2] question about a compressed Ffs3 file inside FFS2
> > > > filesystem
> > > >
> > > > We have a condition that occurs when we boot where we see the
> > > > following message and our boot fails because of it.
> > > > DEBUG ((EFI_D_ERROR, "Found a FFS3 formatted section in a non-FFS3
> > > > formatted FV.\n"));
> > > >
> > > > Which is on line 773 of FwVol.c
> > > > (
> >
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pe
> > > > i/FwVol/FwVol.c )
> > > >
> > > > The condition is caused by a large firmware volume (greater than
> > > > 16mb) that is compressed and put into a smaller FV (less than 16mb).
> > > > My question is why isn't this allowed (seems like a valid scenario).
> > > > Volinfo supports this and decodes binary fine.  The PI Vol 3 spec
> > > > has a section 3.2.2 EFI_FIRMWARE_FILE_SYSTEM3_GUID which says
> > > > FileSystem2 doesn't support large files but it seems that the code
> > > > is not taking into account that the section is compressed and
> > > > therefore you can have a large file inside a compressed section
> > > > inside a
> > FV with File System2.
> > > >
> > > > Feedback/thoughts/comments/Bug?
> > > >
> > > > Here are some details of my scenario.
> > > > Compressed FV has filesystem == 8c8ce578-8a3d-4f1c-9935-
> > 896185c32dd3
> > > > (ffs3)
> > > > Non compressed FV has filesystem == 5473c07a-3dcb-4dca-bd6f-
> > > > 1e9689e7349a (ffs2)
> > > >
> > > > VolInfo dump of the Non Compressed FV showing the
> > nested/compressed
> > > > FV inside.
> > > >
> > > > Decoding
> > > > VolInfo Version 1.0 Build Build 20909
> > > > Signature:        _FVH (4856465F)
> > > > Attributes:       4FEFF
> > > >        EFI_FVB2_READ_DISABLED_CAP
> > > >        EFI_FVB2_READ_ENABLED_CAP
> > > >        EFI_FVB2_READ_STATUS
> > > >        EFI_FVB2_WRITE_DISABLED_CAP
> > > >        EFI_FVB2_WRITE_ENABLED_CAP
> > > >        EFI_FVB2_WRITE_STATUS
> > > >        EFI_FVB2_LOCK_CAP
> > > >        EFI_FVB2_LOCK_STATUS
> > > >        EFI_FVB2_STICKY_WRITE
> > > >        EFI_FVB2_MEMORY_MAPPED
> > > >        EFI_FVB2_ERASE_POLARITY
> > > >        EFI_FVB2_READ_LOCK_CAP
> > > >        EFI_FVB2_READ_LOCK_STATUS
> > > >        EFI_FVB2_WRITE_LOCK_CAP
> > > >        EFI_FVB2_WRITE_LOCK_STATUS
> > > >         EFI_FVB2_ALIGNMENT_16
> > > >         EFI_FVB2_ALIGNMENT_32
> > > >         EFI_FVB2_ALIGNMENT_64
> > > >         EFI_FVB2_ALIGNMENT_128
> > > >         EFI_FVB2_ALIGNMENT_4K
> > > >         EFI_FVB2_ALIGNMENT_8K
> > > >         EFI_FVB2_ALIGNMENT_16K
> > > >         EFI_FVB2_ALIGNMENT_32K
> > > >         EFI_FVB2_ALIGNMENT_1M
> > > >         EFI_FVB2_ALIGNMENT_2M
> > > >        EFI_FVB2_ALIGNMENT_4M
> > > >         EFI_FVB2_ALIGNMENT_8M
> > > >         EFI_FVB2_ALIGNMENT_256M
> > > >         EFI_FVB2_ALIGNMENT_512M
> > > >         EFI_FVB2_ALIGNMENT_1G
> > > >         EFI_FVB2_ALIGNMENT_2G
> > > > Header Length:         0x00000048
> > > > File System ID:        5473c07a-3dcb-4dca-bd6f-1e9689e7349a
> > > > Revision:              0x0002
> > > > Number of Blocks:      0x00000028
> > > > Block Length:          0x00010000
> > > > Total Volume Size:     0x00280000
> > > >
> >
> ==========================================================
> > > > ==
> > > > File Name:        9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
> > > > File Offset:      0x00000048
> > > > File Length:      0x001F3FFD
> > > > File Attributes:  0x00
> > > > File State:       0xF8
> > > >         EFI_FILE_DATA_VALID
> > > > File Type:        0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
> > > > ------------------------------------------------------------
> > > >   Type:  EFI_SECTION_GUID_DEFINED
> > > >   Size:  0x001F3FE5
> > > >   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf
> > > >
> > > >   DataOffset:             0x0018
> > > >   Attributes:             0x0001
> > > > ------------------------------------------------------------
> > > >   Type:  EFI_SECTION_RAW
> > > >   Size:  0x00000FF8
> > > > ------------------------------------------------------------
> > > >   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
> > > >   Size:  0x01010008
> > > >
> >
> ==========================================================
> > > > ==
> > > >
> > > > Thanks
> > > > Sean
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2016-10-24  2:15 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-19 23:09 question about a compressed Ffs3 file inside FFS2 filesystem Sean Brogan
2016-10-19 23:39 ` Andrew Fish
2016-10-19 23:59   ` valerij zaporogeci
2016-10-19 23:59   ` Sean Brogan
2016-10-20  0:11     ` Andrew Fish
2016-10-20  0:15       ` Kinney, Michael D
2016-10-20  1:50         ` Zeng, Star
2016-10-20  8:27 ` Gao, Liming
2016-10-20 14:49   ` Sean Brogan
2016-10-21  1:01     ` Zeng, Star
2016-10-21 16:39       ` Sean Brogan
2016-10-22 10:41         ` Zeng, Star
2016-10-24  2:15           ` Gao, Liming

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox