public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Zeng, Star" <star.zeng@intel.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	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" <edk2-devel@lists.01.org>,
	"Zhu, Yonghong" <yonghong.zhu@intel.com>,
	"Gao, Liming" <liming.gao@intel.com>,
	"Zeng, Star" <star.zeng@intel.com>
Subject: Re: question about a compressed Ffs3 file inside FFS2 filesystem
Date: Thu, 20 Oct 2016 01:50:44 +0000	[thread overview]
Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103958F7B0@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F5648356D4@ORSMSX113.amr.corp.intel.com>

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


  reply	other threads:[~2016-10-20  1:50 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
2016-10-20  0:15       ` Kinney, Michael D
2016-10-20  1:50         ` Zeng, Star [this message]
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=0C09AFA07DD0434D9E2A0C6AEB0483103958F7B0@shsmsx102.ccr.corp.intel.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