public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Andrew Fish <afish@apple.com>
To: Sean Brogan <sean.brogan@microsoft.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: question about a compressed Ffs3 file inside FFS2 filesystem
Date: Wed, 19 Oct 2016 17:11:47 -0700	[thread overview]
Message-ID: <C2D64C31-CAB4-47D3-97BB-007DF6C010C0@apple.com> (raw)
In-Reply-To: <BY1PR03MB1355D9958B51B6ED439B6FCDE1D20@BY1PR03MB1355.namprd03.prod.outlook.com>


> 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



  reply	other threads:[~2016-10-20  0:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C2D64C31-CAB4-47D3-97BB-007DF6C010C0@apple.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox