Re: [edk2] Authentication status for signed FVs extracted in PEI
Mike, > If content is only required in DXE, then consider deferring the FV > publication and authentication to DXE. That may involve adjusting your FV > layout. Originally we had an uncompressed DxeCore.efi decompress the FV with the rest of the components. But the signing already happened in PEI so we had the same issue (AuthenticationStatus = 0). I suppose if we deferred the signature verification and decompression to DxeCore we would propagate AuthenticationStatus but we would be out of PEI and unable to run our recovery handler. > If signed FV is required in PEI and DXE, then it would be authenticated in > PEI, and once authenticated in PEI, it is available to DXE without additional > authentication. This is our scenario. While further authentication in DXE is not needed our policy code needs to know the results of PEI authentication so that in the security callbacks we can to answer the question "Does this image originate from an FV that was already verified in PEI?". Right now AuthenticationStatus is zero (unsigned) in the DXE phase security callbacks and this is incorrect. > I am mainly trying to understand if there is a solution using current PI > architecture. Based on our discussion I'm feeling more confident that we need to define an updated the FV HOB definition (or extend the original if this can be done compatibly) to include AuthenticationStatus from PEI. Thanks, Eugene -Original Message- From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Tuesday, November 10, 2015 7:06 PM To: Cohen, Eugene ; Gao, Liming ; Zeng, Star ; edk2-devel@lists.01.org; Kinney, Michael D Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI Eugene, No. I am not aware of a channel in current PI architecture other than any FV published by PEI is assumed by DXE to be immediately useable (no additional authentication action required). If content is only required in DXE, then consider deferring the FV publication and authentication to DXE. That may involve adjusting your FV layout. If signed FV is required in PEI and DXE, then it would be authenticated in PEI, and once authenticated in PEI, it is available to DXE without additional authentication. I am mainly trying to understand if there is a solution using current PI architecture. Thanks, Mike >-Original Message- >From: Cohen, Eugene [mailto:eug...@hp.com] >Sent: Tuesday, November 10, 2015 2:46 PM >To: Kinney, Michael D; Gao, Liming; Zeng, Star; edk2-devel@lists.01.org >Subject: RE: [edk2] Authentication status for signed FVs extracted in >PEI > >Mike, > >> I believe the current behavior is that only FVs that are either >> unsigned or FVs that are signed and pass authentication can be passed >from PEI to DXE. >> I believe your use case is to pass an FV from PEI to DXE that is signed, but >> has not been authenticated yet. > >Our use case is PEI signing and verifying FVs (the first case) using >the GUIDed encapsulation scheme you contributed a while back (thank >you!). From what I can see both in edk2 and in the PI spec there is >not an architected mechanism to pass this information. As I mentioned in my >first message, the DXE core seems to jam AuthenticationStatus to zero (in >calling ProduceFVBProtocolOnBuffer) as it processes FV HOBs. Are you aware of >a channel where this information is already being passed from PEI to DXE? > >The other lingering question I had was why others hadn't seen this >before me. I'm guessing that people are choosing different approaches for >packaging up PEI and DXE phase components than we are. > >Thanks, > >Eugene > >-Original Message- >From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] >Sent: Tuesday, November 10, 2015 12:54 PM >To: Cohen, Eugene ; Gao, Liming ; >Zeng, Star ; edk2- de...@lists.01.org; Kinney, >Michael D >Subject: RE: [edk2] Authentication status for signed FVs extracted in >PEI > >Eugene, > >I believe the current behavior is that only FVs that are either >unsigned or FVs that are signed and pass authentication can be passed from PEI >to DXE. > >I believe your use case is to pass an FV from PEI to DXE that is signed, but >has not been authenticated yet. > >Given the current PI architecture constraints, would it be a reasonable >solution to have an early DXE driver publish the FV that is signed but not >authenticated yet, so the DXE phase can do the authentication? > >Thanks, > >Mike > >>-Original Message----- >>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>Cohen, Eugene >>Sent: Tuesday, November 10, 2015 7:12 AM >>To: Gao, Liming; Zeng, Star; edk2-devel@lists.01.org >>Subject: R
Re: [edk2] Authentication status for signed FVs extracted in PEI
Eugene, No. I am not aware of a channel in current PI architecture other than any FV published by PEI is assumed by DXE to be immediately useable (no additional authentication action required). If content is only required in DXE, then consider deferring the FV publication and authentication to DXE. That may involve adjusting your FV layout. If signed FV is required in PEI and DXE, then it would be authenticated in PEI, and once authenticated in PEI, it is available to DXE without additional authentication. I am mainly trying to understand if there is a solution using current PI architecture. Thanks, Mike >-Original Message- >From: Cohen, Eugene [mailto:eug...@hp.com] >Sent: Tuesday, November 10, 2015 2:46 PM >To: Kinney, Michael D; Gao, Liming; Zeng, Star; edk2-devel@lists.01.org >Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI > >Mike, > >> I believe the current behavior is that only FVs that are either unsigned or >> FVs that are signed and pass authentication can be passed >from PEI to DXE. >> I believe your use case is to pass an FV from PEI to DXE that is signed, but >> has not been authenticated yet. > >Our use case is PEI signing and verifying FVs (the first case) using the >GUIDed encapsulation scheme you contributed a while back >(thank you!). From what I can see both in edk2 and in the PI spec there is >not an architected mechanism to pass this information. As >I mentioned in my first message, the DXE core seems to jam >AuthenticationStatus to zero (in calling ProduceFVBProtocolOnBuffer) as >it processes FV HOBs. Are you aware of a channel where this information is >already being passed from PEI to DXE? > >The other lingering question I had was why others hadn't seen this before me. >I'm guessing that people are choosing different >approaches for packaging up PEI and DXE phase components than we are. > >Thanks, > >Eugene > >-Original Message- >From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] >Sent: Tuesday, November 10, 2015 12:54 PM >To: Cohen, Eugene ; Gao, Liming ; Zeng, >Star ; edk2- >de...@lists.01.org; Kinney, Michael D >Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI > >Eugene, > >I believe the current behavior is that only FVs that are either unsigned or >FVs that are signed and pass authentication can be passed >from PEI to DXE. > >I believe your use case is to pass an FV from PEI to DXE that is signed, but >has not been authenticated yet. > >Given the current PI architecture constraints, would it be a reasonable >solution to have an early DXE driver publish the FV that is >signed but not authenticated yet, so the DXE phase can do the authentication? > >Thanks, > >Mike > >>-Original Message- >>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, >>Eugene >>Sent: Tuesday, November 10, 2015 7:12 AM >>To: Gao, Liming; Zeng, Star; edk2-devel@lists.01.org >>Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI >> >>Liming and Star, >> >>Thanks for the suggestion for extending the FV HOB. I'm not sure if the >>length change will be considered forwards and backwards >>compatible for all implementations. If people refer to the HOB by pointer it >>shouldn't be a problem but if they try to copy the HOB >>using the header length they may have a compatibility problem. >> >>I'll raise your suggestion at PIWG and see what the group recommends. >> >>Thanks, >> >>Eugene >> >>-Original Message- >>From: Gao, Liming [mailto:liming@intel.com] >>Sent: Tuesday, November 10, 2015 3:27 AM >>To: Zeng, Star ; Cohen, Eugene ; >>edk2-devel@lists.01.org >>Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI >> >>Eugene: >> Another idea is to update FV HOB to include authentication status instead >> of adding FV HOB3. The consumer code can check FV >HOB >>Length to know whether FV HOB includes authentication status. >> >>Thanks >>Liming >>> -Original Message- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>> Zeng, Star >>> Sent: Tuesday, November 10, 2015 6:19 PM >>> To: Cohen, Eugene; edk2-devel@lists.01.org >>> Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI >>> >>> On 2015/11/9 21:57, Cohen, Eugene wrote: >>> > Star, >>> > >>> >> The authentication status and its inheritance support in FvInfo2 and >>> >> FvPpi
Re: [edk2] Authentication status for signed FVs extracted in PEI
Mike, > I believe the current behavior is that only FVs that are either unsigned or > FVs that are signed and pass authentication can be passed from PEI to DXE. > I believe your use case is to pass an FV from PEI to DXE that is signed, but > has not been authenticated yet. Our use case is PEI signing and verifying FVs (the first case) using the GUIDed encapsulation scheme you contributed a while back (thank you!). From what I can see both in edk2 and in the PI spec there is not an architected mechanism to pass this information. As I mentioned in my first message, the DXE core seems to jam AuthenticationStatus to zero (in calling ProduceFVBProtocolOnBuffer) as it processes FV HOBs. Are you aware of a channel where this information is already being passed from PEI to DXE? The other lingering question I had was why others hadn't seen this before me. I'm guessing that people are choosing different approaches for packaging up PEI and DXE phase components than we are. Thanks, Eugene -Original Message- From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Tuesday, November 10, 2015 12:54 PM To: Cohen, Eugene ; Gao, Liming ; Zeng, Star ; edk2-devel@lists.01.org; Kinney, Michael D Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI Eugene, I believe the current behavior is that only FVs that are either unsigned or FVs that are signed and pass authentication can be passed from PEI to DXE. I believe your use case is to pass an FV from PEI to DXE that is signed, but has not been authenticated yet. Given the current PI architecture constraints, would it be a reasonable solution to have an early DXE driver publish the FV that is signed but not authenticated yet, so the DXE phase can do the authentication? Thanks, Mike >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, >Eugene >Sent: Tuesday, November 10, 2015 7:12 AM >To: Gao, Liming; Zeng, Star; edk2-devel@lists.01.org >Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI > >Liming and Star, > >Thanks for the suggestion for extending the FV HOB. I'm not sure if the >length change will be considered forwards and backwards >compatible for all implementations. If people refer to the HOB by pointer it >shouldn't be a problem but if they try to copy the HOB >using the header length they may have a compatibility problem. > >I'll raise your suggestion at PIWG and see what the group recommends. > >Thanks, > >Eugene > >-Original Message- >From: Gao, Liming [mailto:liming@intel.com] >Sent: Tuesday, November 10, 2015 3:27 AM >To: Zeng, Star ; Cohen, Eugene ; >edk2-devel@lists.01.org >Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI > >Eugene: > Another idea is to update FV HOB to include authentication status instead of > adding FV HOB3. The consumer code can check FV HOB >Length to know whether FV HOB includes authentication status. > >Thanks >Liming >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, >> Star >> Sent: Tuesday, November 10, 2015 6:19 PM >> To: Cohen, Eugene; edk2-devel@lists.01.org >> Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI >> >> On 2015/11/9 21:57, Cohen, Eugene wrote: >> > Star, >> > >> >> The authentication status and its inheritance support in FvInfo2 and >> >> FvPpi were covered by the mantis we submitted to support >PEI >> security and to be equivalent with DXE. >> > You raised another issue here to inherit authentication status from PEI to >> > DXE. >> > >> > Correct. >> > >> >> Currently, only verified pass FV in PEI will be processed and reported >> >> with FV HOB to DXE. >> > >> > The FV HOB doesn't explicitly say whether the FV was verified or not. We >> > have a use case where we have one FV that contains >code >> and is verified and another FV that contains some data and is not verified. >> With the current FV HOB definitions there's no way to >> differentiate these two. >> >> Curious about the FV you said is root or child FV? >> >> > >> > The DXE core just assumes that all FVs passed through FV hobs are unsigned >> > (AuthenticationStatus = 0). So in DXE-phase security >> policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting >> accurate AuthenticationStatus values with which to >make a >> decision. >> > >> > So in a way this just seems wrong since the security callbacks are saying
Re: [edk2] Authentication status for signed FVs extracted in PEI
Eugene, I believe the current behavior is that only FVs that are either unsigned or FVs that are signed and pass authentication can be passed from PEI to DXE. I believe your use case is to pass an FV from PEI to DXE that is signed, but has not been authenticated yet. Given the current PI architecture constraints, would it be a reasonable solution to have an early DXE driver publish the FV that is signed but not authenticated yet, so the DXE phase can do the authentication? Thanks, Mike >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, >Eugene >Sent: Tuesday, November 10, 2015 7:12 AM >To: Gao, Liming; Zeng, Star; edk2-devel@lists.01.org >Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI > >Liming and Star, > >Thanks for the suggestion for extending the FV HOB. I'm not sure if the >length change will be considered forwards and backwards >compatible for all implementations. If people refer to the HOB by pointer it >shouldn't be a problem but if they try to copy the HOB >using the header length they may have a compatibility problem. > >I'll raise your suggestion at PIWG and see what the group recommends. > >Thanks, > >Eugene > >-Original Message- >From: Gao, Liming [mailto:liming@intel.com] >Sent: Tuesday, November 10, 2015 3:27 AM >To: Zeng, Star ; Cohen, Eugene ; >edk2-devel@lists.01.org >Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI > >Eugene: > Another idea is to update FV HOB to include authentication status instead of > adding FV HOB3. The consumer code can check FV HOB >Length to know whether FV HOB includes authentication status. > >Thanks >Liming >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, >> Star >> Sent: Tuesday, November 10, 2015 6:19 PM >> To: Cohen, Eugene; edk2-devel@lists.01.org >> Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI >> >> On 2015/11/9 21:57, Cohen, Eugene wrote: >> > Star, >> > >> >> The authentication status and its inheritance support in FvInfo2 and >> >> FvPpi were covered by the mantis we submitted to support >PEI >> security and to be equivalent with DXE. >> > You raised another issue here to inherit authentication status from PEI to >> > DXE. >> > >> > Correct. >> > >> >> Currently, only verified pass FV in PEI will be processed and reported >> >> with FV HOB to DXE. >> > >> > The FV HOB doesn't explicitly say whether the FV was verified or not. We >> > have a use case where we have one FV that contains >code >> and is verified and another FV that contains some data and is not verified. >> With the current FV HOB definitions there's no way to >> differentiate these two. >> >> Curious about the FV you said is root or child FV? >> >> > >> > The DXE core just assumes that all FVs passed through FV hobs are unsigned >> > (AuthenticationStatus = 0). So in DXE-phase security >> policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting >> accurate AuthenticationStatus values with which to >make a >> decision. >> > >> > So in a way this just seems wrong since the security callbacks are saying >> > that FVs are unsigned when in reality there are signed and >> verified. >> > >> > I'm thinking this could be as simple as an updated FV HOB definition that >> > adds an AuthenticationStatus field. >> >> I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to >> include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one >> FV. Seemingly, we could not to just extend FV HOB to include >> AuthenticationStatus, right? >> >> Thanks, >> Star >> >> > >> > Eugene >> > >> > -Original Message- >> > From: Zeng, Star [mailto:star.z...@intel.com] >> > Sent: Monday, November 09, 2015 6:43 AM >> > To: Cohen, Eugene ; edk2-devel@lists.01.org >> > Cc: Zeng, Star >> > Subject: RE: Authentication status for signed FVs extracted in PEI >> > >> > The authentication status and its inheritance support in FvInfo2 and FvPpi >> > were covered by the mantis we submitted to support >PEI >> security and to be equivalent with DXE. >> > You raised another issue here to inherit authentication status from PEI to >> > DXE. >> > >> > Currently, only verified p
Re: [edk2] Authentication status for signed FVs extracted in PEI
Liming and Star, Thanks for the suggestion for extending the FV HOB. I'm not sure if the length change will be considered forwards and backwards compatible for all implementations. If people refer to the HOB by pointer it shouldn't be a problem but if they try to copy the HOB using the header length they may have a compatibility problem. I'll raise your suggestion at PIWG and see what the group recommends. Thanks, Eugene -Original Message- From: Gao, Liming [mailto:liming@intel.com] Sent: Tuesday, November 10, 2015 3:27 AM To: Zeng, Star ; Cohen, Eugene ; edk2-devel@lists.01.org Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI Eugene: Another idea is to update FV HOB to include authentication status instead of adding FV HOB3. The consumer code can check FV HOB Length to know whether FV HOB includes authentication status. Thanks Liming > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, > Star > Sent: Tuesday, November 10, 2015 6:19 PM > To: Cohen, Eugene; edk2-devel@lists.01.org > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI > > On 2015/11/9 21:57, Cohen, Eugene wrote: > > Star, > > > >> The authentication status and its inheritance support in FvInfo2 and FvPpi > >> were covered by the mantis we submitted to support PEI > security and to be equivalent with DXE. > > You raised another issue here to inherit authentication status from PEI to > > DXE. > > > > Correct. > > > >> Currently, only verified pass FV in PEI will be processed and reported > >> with FV HOB to DXE. > > > > The FV HOB doesn't explicitly say whether the FV was verified or not. We > > have a use case where we have one FV that contains code > and is verified and another FV that contains some data and is not verified. > With the current FV HOB definitions there's no way to > differentiate these two. > > Curious about the FV you said is root or child FV? > > > > > The DXE core just assumes that all FVs passed through FV hobs are unsigned > > (AuthenticationStatus = 0). So in DXE-phase security > policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting > accurate AuthenticationStatus values with which to make a > decision. > > > > So in a way this just seems wrong since the security callbacks are saying > > that FVs are unsigned when in reality there are signed and > verified. > > > > I'm thinking this could be as simple as an updated FV HOB definition that > > adds an AuthenticationStatus field. > > I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to > include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one > FV. Seemingly, we could not to just extend FV HOB to include > AuthenticationStatus, right? > > Thanks, > Star > > > > > Eugene > > > > -Original Message- > > From: Zeng, Star [mailto:star.z...@intel.com] > > Sent: Monday, November 09, 2015 6:43 AM > > To: Cohen, Eugene ; edk2-devel@lists.01.org > > Cc: Zeng, Star > > Subject: RE: Authentication status for signed FVs extracted in PEI > > > > The authentication status and its inheritance support in FvInfo2 and FvPpi > > were covered by the mantis we submitted to support PEI > security and to be equivalent with DXE. > > You raised another issue here to inherit authentication status from PEI to > > DXE. > > > > Currently, only verified pass FV in PEI will be processed and reported with > > FV HOB to DXE. > > Your real case will have different policy to verify FV in PEI and DXE phase? > > > > Thanks, > > Star > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Cohen, Eugene > > Sent: Monday, November 9, 2015 9:03 PM > > To: edk2-devel@lists.01.org > > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI > > > > I raised this as an issue with PIWG. In the meantime feel free to provide > > some historical context for why this hasn't been an issue in > other implementations. > > > > Thanks, > > > > Eugene > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Cohen, Eugene > > Sent: Friday, November 06, 2015 5:49 PM > > To: edk2-devel@lists.01.org > > Cc: Thompson, Mark L. (Boise IPG) > > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI > > > > [Corrected the typos with a n
Re: [edk2] Authentication status for signed FVs extracted in PEI
Eugene: Another idea is to update FV HOB to include authentication status instead of adding FV HOB3. The consumer code can check FV HOB Length to know whether FV HOB includes authentication status. Thanks Liming > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, > Star > Sent: Tuesday, November 10, 2015 6:19 PM > To: Cohen, Eugene; edk2-devel@lists.01.org > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI > > On 2015/11/9 21:57, Cohen, Eugene wrote: > > Star, > > > >> The authentication status and its inheritance support in FvInfo2 and FvPpi > >> were covered by the mantis we submitted to support PEI > security and to be equivalent with DXE. > > You raised another issue here to inherit authentication status from PEI to > > DXE. > > > > Correct. > > > >> Currently, only verified pass FV in PEI will be processed and reported > >> with FV HOB to DXE. > > > > The FV HOB doesn't explicitly say whether the FV was verified or not. We > > have a use case where we have one FV that contains code > and is verified and another FV that contains some data and is not verified. > With the current FV HOB definitions there's no way to > differentiate these two. > > Curious about the FV you said is root or child FV? > > > > > The DXE core just assumes that all FVs passed through FV hobs are unsigned > > (AuthenticationStatus = 0). So in DXE-phase security > policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting > accurate AuthenticationStatus values with which to make a > decision. > > > > So in a way this just seems wrong since the security callbacks are saying > > that FVs are unsigned when in reality there are signed and > verified. > > > > I'm thinking this could be as simple as an updated FV HOB definition that > > adds an AuthenticationStatus field. > > I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to > include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one > FV. Seemingly, we could not to just extend FV HOB to include > AuthenticationStatus, right? > > Thanks, > Star > > > > > Eugene > > > > -Original Message- > > From: Zeng, Star [mailto:star.z...@intel.com] > > Sent: Monday, November 09, 2015 6:43 AM > > To: Cohen, Eugene ; edk2-devel@lists.01.org > > Cc: Zeng, Star > > Subject: RE: Authentication status for signed FVs extracted in PEI > > > > The authentication status and its inheritance support in FvInfo2 and FvPpi > > were covered by the mantis we submitted to support PEI > security and to be equivalent with DXE. > > You raised another issue here to inherit authentication status from PEI to > > DXE. > > > > Currently, only verified pass FV in PEI will be processed and reported with > > FV HOB to DXE. > > Your real case will have different policy to verify FV in PEI and DXE phase? > > > > Thanks, > > Star > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Cohen, Eugene > > Sent: Monday, November 9, 2015 9:03 PM > > To: edk2-devel@lists.01.org > > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI > > > > I raised this as an issue with PIWG. In the meantime feel free to provide > > some historical context for why this hasn't been an issue in > other implementations. > > > > Thanks, > > > > Eugene > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Cohen, Eugene > > Sent: Friday, November 06, 2015 5:49 PM > > To: edk2-devel@lists.01.org > > Cc: Thompson, Mark L. (Boise IPG) > > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI > > > > [Corrected the typos with a new version - proofreading is a good thing] > > > > > > I'm confused about something and hope I can get some help understanding > > this. > > > > If we have a signed FV that is extracted in PEI it doesn't look like the > > AuthenticationStatus gets propagated to DXE. > > > > The hob doesn't store authentication status and the core produces FVB with > > AuthenticationStatus forced to zero, even though the FV > was signed and verified. > > > > This seems to mess up policy code in DXE because it is the > > AuthenticationStatus is not accurate. > > > > MdeModulePkg\Core\Dxe\FwVolBl
Re: [edk2] Authentication status for signed FVs extracted in PEI
On 2015/11/9 21:57, Cohen, Eugene wrote:
Star,
The authentication status and its inheritance support in FvInfo2 and FvPpi were
covered by the mantis we submitted to support PEI security and to be equivalent
with DXE.
You raised another issue here to inherit authentication status from PEI to DXE.
Correct.
Currently, only verified pass FV in PEI will be processed and reported with FV
HOB to DXE.
The FV HOB doesn't explicitly say whether the FV was verified or not. We have
a use case where we have one FV that contains code and is verified and another
FV that contains some data and is not verified. With the current FV HOB
definitions there's no way to differentiate these two.
Curious about the FV you said is root or child FV?
The DXE core just assumes that all FVs passed through FV hobs are unsigned
(AuthenticationStatus = 0). So in DXE-phase security policy callbacks (part of
EFI_SECURITY_ARCH_PROTOCOL) we are not getting accurate AuthenticationStatus
values with which to make a decision.
So in a way this just seems wrong since the security callbacks are saying that
FVs are unsigned when in reality there are signed and verified.
I'm thinking this could be as simple as an updated FV HOB definition that adds
an AuthenticationStatus field.
I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to
include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one
FV. Seemingly, we could not to just extend FV HOB to include
AuthenticationStatus, right?
Thanks,
Star
Eugene
-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Monday, November 09, 2015 6:43 AM
To: Cohen, Eugene ; edk2-devel@lists.01.org
Cc: Zeng, Star
Subject: RE: Authentication status for signed FVs extracted in PEI
The authentication status and its inheritance support in FvInfo2 and FvPpi were
covered by the mantis we submitted to support PEI security and to be equivalent
with DXE.
You raised another issue here to inherit authentication status from PEI to DXE.
Currently, only verified pass FV in PEI will be processed and reported with FV
HOB to DXE.
Your real case will have different policy to verify FV in PEI and DXE phase?
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Monday, November 9, 2015 9:03 PM
To: edk2-devel@lists.01.org
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
I raised this as an issue with PIWG. In the meantime feel free to provide some
historical context for why this hasn't been an issue in other implementations.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 5:49 PM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
[Corrected the typos with a new version - proofreading is a good thing]
I'm confused about something and hope I can get some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core produces FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code in DXE because it is the AuthenticationStatus
is not accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Note the hardcoded zero in the second-to-last argument.
Is this expected? How would DXE policy code know if the FV was verified in
PEI? It looks like the HOB definitions do not propagate PEI-phase
Authentication status forward.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 11:12 AM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: [edk2] Authentication status for signed FVs extracted in PEI
I'm confused about something and hope I can help some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core products FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code we want to have in DXE because it is not
accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TY
Re: [edk2] Authentication status for signed FVs extracted in PEI
Star,
> The authentication status and its inheritance support in FvInfo2 and FvPpi
> were covered by the mantis we submitted to support PEI security and to be
> equivalent with DXE.
You raised another issue here to inherit authentication status from PEI to DXE.
Correct.
> Currently, only verified pass FV in PEI will be processed and reported with
> FV HOB to DXE.
The FV HOB doesn't explicitly say whether the FV was verified or not. We have
a use case where we have one FV that contains code and is verified and another
FV that contains some data and is not verified. With the current FV HOB
definitions there's no way to differentiate these two.
The DXE core just assumes that all FVs passed through FV hobs are unsigned
(AuthenticationStatus = 0). So in DXE-phase security policy callbacks (part of
EFI_SECURITY_ARCH_PROTOCOL) we are not getting accurate AuthenticationStatus
values with which to make a decision.
So in a way this just seems wrong since the security callbacks are saying that
FVs are unsigned when in reality there are signed and verified.
I'm thinking this could be as simple as an updated FV HOB definition that adds
an AuthenticationStatus field.
Eugene
-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Monday, November 09, 2015 6:43 AM
To: Cohen, Eugene ; edk2-devel@lists.01.org
Cc: Zeng, Star
Subject: RE: Authentication status for signed FVs extracted in PEI
The authentication status and its inheritance support in FvInfo2 and FvPpi were
covered by the mantis we submitted to support PEI security and to be equivalent
with DXE.
You raised another issue here to inherit authentication status from PEI to DXE.
Currently, only verified pass FV in PEI will be processed and reported with FV
HOB to DXE.
Your real case will have different policy to verify FV in PEI and DXE phase?
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Monday, November 9, 2015 9:03 PM
To: edk2-devel@lists.01.org
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
I raised this as an issue with PIWG. In the meantime feel free to provide some
historical context for why this hasn't been an issue in other implementations.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 5:49 PM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
[Corrected the typos with a new version - proofreading is a good thing]
I'm confused about something and hope I can get some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core produces FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code in DXE because it is the AuthenticationStatus
is not accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Note the hardcoded zero in the second-to-last argument.
Is this expected? How would DXE policy code know if the FV was verified in
PEI? It looks like the HOB definitions do not propagate PEI-phase
Authentication status forward.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 11:12 AM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: [edk2] Authentication status for signed FVs extracted in PEI
I'm confused about something and hope I can help some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core products FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code we want to have in DXE because it is not
accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Is this expected? How would DXE policy code know if the FV was verified in PEI?
Thanks,
Eu
Re: [edk2] Authentication status for signed FVs extracted in PEI
The authentication status and its inheritance support in FvInfo2 and FvPpi were
covered by the mantis we submitted to support PEI security and to be equivalent
with DXE.
You raised another issue here to inherit authentication status from PEI to DXE.
Currently, only verified pass FV in PEI will be processed and reported with FV
HOB to DXE.
Your real case will have different policy to verify FV in PEI and DXE phase?
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Monday, November 9, 2015 9:03 PM
To: edk2-devel@lists.01.org
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
I raised this as an issue with PIWG. In the meantime feel free to provide some
historical context for why this hasn't been an issue in other implementations.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 5:49 PM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
[Corrected the typos with a new version - proofreading is a good thing]
I'm confused about something and hope I can get some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core produces FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code in DXE because it is the AuthenticationStatus
is not accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Note the hardcoded zero in the second-to-last argument.
Is this expected? How would DXE policy code know if the FV was verified in
PEI? It looks like the HOB definitions do not propagate PEI-phase
Authentication status forward.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 11:12 AM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: [edk2] Authentication status for signed FVs extracted in PEI
I'm confused about something and hope I can help some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core products FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code we want to have in DXE because it is not
accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Is this expected? How would DXE policy code know if the FV was verified in PEI?
Thanks,
Eugene
___
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
Re: [edk2] Authentication status for signed FVs extracted in PEI
I raised this as an issue with PIWG. In the meantime feel free to provide some
historical context for why this hasn't been an issue in other implementations.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 5:49 PM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
[Corrected the typos with a new version - proofreading is a good thing]
I'm confused about something and hope I can get some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core produces FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code in DXE because it is the AuthenticationStatus
is not accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Note the hardcoded zero in the second-to-last argument.
Is this expected? How would DXE policy code know if the FV was verified in
PEI? It looks like the HOB definitions do not propagate PEI-phase
Authentication status forward.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 11:12 AM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: [edk2] Authentication status for signed FVs extracted in PEI
I'm confused about something and hope I can help some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core products FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code we want to have in DXE because it is not
accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Is this expected? How would DXE policy code know if the FV was verified in PEI?
Thanks,
Eugene
___
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
Re: [edk2] Authentication status for signed FVs extracted in PEI
[Corrected the typos with a new version - proofreading is a good thing]
I'm confused about something and hope I can get some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core produces FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code in DXE because it is the AuthenticationStatus
is not accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Note the hardcoded zero in the second-to-last argument.
Is this expected? How would DXE policy code know if the FV was verified in
PEI? It looks like the HOB definitions do not propagate PEI-phase
Authentication status forward.
Thanks,
Eugene
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Friday, November 06, 2015 11:12 AM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG)
Subject: [edk2] Authentication status for signed FVs extracted in PEI
I'm confused about something and hope I can help some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core products FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code we want to have in DXE because it is not
accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Is this expected? How would DXE policy code know if the FV was verified in PEI?
Thanks,
Eugene
___
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] Authentication status for signed FVs extracted in PEI
I'm confused about something and hope I can help some help understanding this.
If we have a signed FV that is extracted in PEI it doesn't look like the
AuthenticationStatus gets propagated to DXE.
The hob doesn't store authentication status and the core products FVB with
AuthenticationStatus forced to zero, even though the FV was signed and verified.
This seems to mess up policy code we want to have in DXE because it is not
accurate.
MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
//
// Produce an FVB protocol for it
//
ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress,
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
FvHob.Raw = GET_NEXT_HOB (FvHob);
}
Is this expected? How would DXE policy code know if the FV was verified in PEI?
Thanks,
Eugene
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
