Date   

回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

gaoliming
 

Mike:

-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@intel.com>
发送时间: 2020年12月16日 10:52
收件人: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
rfc@edk2.groups.io; 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
<leif@nuviainc.com>; lersek@redhat.com; 'Sean Brogan'
<sean.brogan@microsoft.com>; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
主题: RE: [RFC V2] Create supported branch from edk2-stable* tag (Required
to address critical bug BZ3111)

-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Tuesday, December 15, 2020 5:19 PM
To: Kinney, Michael D <michael.d.kinney@intel.com>;
devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish'
<afish@apple.com>; 'Leif Lindholm' <leif@nuviainc.com>;
lersek@redhat.com; 'Sean Brogan' <sean.brogan@microsoft.com>;
'Bret Barkelew' <Bret.Barkelew@microsoft.com>
Subject: 回复: [RFC V2] Create supported branch from edk2-stable* tag
(Required to address critical bug BZ3111)

Mike:

-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@intel.com>
发送时间: 2020年12月16日 8:25
收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com)
<afish@apple.com>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek
<lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean
Brogan' <sean.brogan@microsoft.com>; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
主题: [RFC V2] Create supported branch from edk2-stable* tag (Required
to
address critical bug BZ3111)

Hello,

The following bug has been fixed on edk2/master

https://bugzilla.tianocore.org/show_bug.cgi?id=3111
https://github.com/tianocore/edk2/pull/1226

This bug is also considered a critical bug against edk2-stable202011. The
behavior
of the Variable Lock Protocol was changed in a non-backwards compatible
manner in
edk2-stable202011 and this is impacting some downstream platforms.
The
following
2 commits on edk2/master restore the original behavior of the Variable
Lock
Protocol.


https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f
53858d6acaa15a348bad7c

https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91ce
deeed45bc0fbdfde49f7968
[Liming] This one is for unit test. It is not critical fix. I don't think it is
required.


I agree it is not strictly required for functionality, but the bug fix that is
required
was reviewed and submitted in a PR as a patch series. I think critical bug
fixes should
be applied to a supported branch at the same granularity they were
submitted to the
trunk. Since the EDK II CI system does not evaluate the stability of each
patch in
a patch series, there is a risk to take portions of a patch series.

I suggest when a critical bug fix is identified, that we start with cherry-picking
all the patches in the patch series. If there is a specific concern about taking
the entire patch series, then that can be discussed and potentially a different
patch series can be applied to the supported branch. This would require CI
on
supported branch to make sure the quality and functionality are the same.
This case is clear. One commit is for the bug fix, another is for the unit test.
If the unit test is also important for this fix, it can be cherry-pick. I understand the critical bug fix is for the functionality only.


The request here is to create a supported branch from edk2-stable202011
tag
and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a
request to create
a supported branch from one of those tags. As a result, there are a
couple
opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/<YYYY><MM>
Example: stable/202011
Here is my suggestion on the live period of the stable tag branch.
The stable tag branch will be created only when the critical issue is found in
this stable tag. By default, no stable tag
branch is created.
Now, the quarterly stable tag will be created every three months. So, this
branch will exist for at most three months.
Once next stable tag is created, new stable tag will be used. Previous stable
tag branch will not be maintained.
That means only latest stable tag branch will be maintained if it is created.
It is hard to predict how downstream platforms use a stable tag or a
supported branch.
If a downstream consumer identifies a critical bug in a previous stable tag or
a supported branch, then that bug report needs to be evaluated and
determine if
the bug fix needs to be applied to a stable branch or not. I do not think we
should
reject all requests just because there is a more recent stable tag. We need
to evaluate each request.
If stable branch requires long term maintain, the stable branches will become more and more,
the branch maintain effort will be more and more. It may not be workable in open source edk2 community
unless there is the dedicated branch maintainers.

So, I suggest that downstream consumers maintain their downstream branch to include the hot fix.
Edk2 stable branch is the reference for the downstream users.

Thanks
Liming
We do want to encourage all platforms under development to use the latest
stable
tag. But once a platform is released as a product using a specific stable tag
they may prefer to continue to use that stable tag for long term maintenance
of that platform.



2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/*
branches
and update GitHub settings so stable/* branches are protected
branches.
The patch has been verified in master. CI test may not be necessary.
In the general case where more than one critical bug may be fixed in a
stable branch, CI will help make sure that the combination of fixes
work together. For this first case, I agree that CI may not be required.


3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be
made
that
would trigger focused testing of the supported branch and creation of
a
new
release. If all testing passes, then a tag is created on the
stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of
critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01
It is OK to create new stable tag per the request. The platform can use
stable branch.

Thank you. I will start work on a patch for review.


Besides, there are few new issues. I have cancelled the bug triage meeting.

Thanks
Liming
Please let me know if you have any feedback or comments on this
proposal.
The goal
is to close on this topic this week.

Thank you,

Mike


回复: [edk2-devel] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

gaoliming
 

Mike:
I review all submodules in edk2. They are all from github except for cmocka. So, I agree to use github mirror for cmocka.

Thanks
Liming

-----邮件原件-----
发件人: bounce+27952+69010+4905953+8761045@groups.io
<bounce+27952+69010+4905953+8761045@groups.io> 代表 Michael D
Kinney
发送时间: 2020年12月17日 2:46
收件人: rfc@edk2.groups.io; devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@intel.com>; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>
主题: [edk2-devel] [RFC] UnitTestFrameworkPkg cmocka submodule
alternatives

Hello,

We have had at least three incidents in the last year where the link to the
cmocka submodule in the UnitTestFrameworkPkg has not been available, and
this
impacted the EDK II CI system. The following submodule link is the one that
is not reliable:

https://git.cryptomilk.org/projects/cmocka.git

We have identified two potential mirrors of this repo:

https://github.com/neverware-mirrors/cmocka.git
https://gitlab.com/cmocka/cmocka.git

The following patch provided a temporary fix for the EDK II CI agents, but
does not help other consumers of the edk2 repository.

https://github.com/tianocore/edk2/commit/be746104d1766a8c363e74
d6063144657820d688

I have seen one suggestion that TianoCore create its own
mirror of cmocka. This does require monitoring and maintenance
by the TianoCore community. I would prefer to use a well
maintained mirror in github as long as we do not observe any
issues with the support of that mirror.

I propose we update the submodule in the UnitTestFrameworkPkg
to use the https://github.com/neverware-mirrors/cmocka.git mirror.
By using a mirror in github, we remove one external dependency.

Please provide feedback and comments on this proposal. If there
are no objections, then we will proceed with a patch review for
this update.

Thanks,

Mike




回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

gaoliming
 

Mike:

-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@intel.com>
发送时间: 2020年12月16日 8:25
收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com)
<afish@apple.com>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek
<lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean
Brogan' <sean.brogan@microsoft.com>; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
主题: [RFC V2] Create supported branch from edk2-stable* tag (Required to
address critical bug BZ3111)

Hello,

The following bug has been fixed on edk2/master

https://bugzilla.tianocore.org/show_bug.cgi?id=3111
https://github.com/tianocore/edk2/pull/1226

This bug is also considered a critical bug against edk2-stable202011. The
behavior
of the Variable Lock Protocol was changed in a non-backwards compatible
manner in
edk2-stable202011 and this is impacting some downstream platforms. The
following
2 commits on edk2/master restore the original behavior of the Variable Lock
Protocol.


https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f
53858d6acaa15a348bad7c

https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91ce
deeed45bc0fbdfde49f7968
[Liming] This one is for unit test. It is not critical fix. I don't think it is required.

The request here is to create a supported branch from edk2-stable202011 tag
and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a
request to create
a supported branch from one of those tags. As a result, there are a couple
opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/<YYYY><MM>
Example: stable/202011
Here is my suggestion on the live period of the stable tag branch.
The stable tag branch will be created only when the critical issue is found in this stable tag. By default, no stable tag branch is created.
Now, the quarterly stable tag will be created every three months. So, this branch will exist for at most three months.
Once next stable tag is created, new stable tag will be used. Previous stable tag branch will not be maintained.
That means only latest stable tag branch will be maintained if it is created.


2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/*
branches
and update GitHub settings so stable/* branches are protected
branches.
The patch has been verified in master. CI test may not be necessary.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made
that
would trigger focused testing of the supported branch and creation of a
new
release. If all testing passes, then a tag is created on the
stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of
critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01
It is OK to create new stable tag per the request. The platform can use stable branch.

Besides, there are few new issues. I have cancelled the bug triage meeting.

Thanks
Liming
Please let me know if you have any feedback or comments on this proposal.
The goal
is to close on this topic this week.

Thank you,

Mike


Re: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Bret Barkelew <bret.barkelew@...>
 

“I agree with Liming that stable branches should have a predefined
lifetime. Keeping stable branches regression-free is very difficult and
ungrateful work, and the community should not have expectations that
we're going to do "LTS" branches.”

Seconded. We actually had to update our release process with this blurb recently:
https://microsoft.github.io/mu/How/release_process/#post-lts-and-archiving

- Bret

From: Laszlo Ersek<mailto:lersek@redhat.com>
Sent: Thursday, December 17, 2020 5:50 AM
To: Kinney, Michael D<mailto:michael.d.kinney@intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Andrew Fish (afish@apple.com)<mailto:afish@apple.com>; Leif Lindholm<mailto:leif@nuviainc.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Subject: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

On 12/16/20 01:24, Kinney, Michael D wrote:
Hello,

The following bug has been fixed on edk2/master

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=MnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&amp;reserved=0

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53858d6acaa15a348bad7c&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=h19eR7KFYlerrva%2FVGMDb7DMVIUihINgAlOh96Hb2xI%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8nCkmGD5jRyfrsMID0ESAcUb8plWrRkFafvhPiS2Zo8%3D&amp;reserved=0

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/<YYYY><MM>
Example: stable/202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.
- Looks good; just a typo in the example: "edk2-stable201111.01" should
use 2020, not 2011.


- I agree with Liming that stable branches should have a predefined
lifetime. Keeping stable branches regression-free is very difficult and
ungrateful work, and the community should not have expectations that
we're going to do "LTS" branches. That's too resource hungry; companies
have dedicated "maintenance engineer" positions for that.

Here's an example stable process:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dblob_plain%3Bf%3Ddocs%2Fdevel%2Fstable-process.rst%3Bhb%3DHEAD&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bOmSbEHuU%2BqLr3mdmhP%2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&amp;reserved=0

I would recommend that, initially, we only promise support for the last
stable tag's branch.


- Including a unit test (if it exists) with the actual bugfix on a
stable branch seems important to me.

Thanks
Laszlo


Re: [EXTERNAL] Re: [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Bret Barkelew <bret.barkelew@...>
 

My vote is to own a fork. I agree with Laszlo that it’s very low maintenance (may even be able to automate it with an existing DevOps pipeline to run every day) and gives us the most control of our destiny.

- Bret

From: Rebecca Cran<mailto:rebecca@nuviainc.com>
Sent: Thursday, December 17, 2020 8:01 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@redhat.com<mailto:lersek@redhat.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Subject: [EXTERNAL] Re: [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

On 12/17/20 8:54 AM, Laszlo Ersek wrote:
On 12/17/20 15:48, Laszlo Ersek wrote:

I don't know who or what the <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fneverware-mirrors&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C4cd7a0f805864468a2cb08d8a2a50fb8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438177109105172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=oOtke9Pjf8TFVV2D0nv1xW%2B2a9sBsXgbFo1A9fodooc%3D&amp;reserved=0>
organization is, and I'd prefer not fetching code from them automatically.
I'm sorry, this was silly.

The whole point of git is "addressing by content". Our submodule
reference in edk2 makes us check out the cmocka tree at a known hash, so
where that comes from is totally irrelevant.

I'm OK with the proposal as posted.
Also, apparently Neverware is part of Google:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcloudreadykb.neverware.com%2Fs%2Farticle%2FNeverware-is-now-part-of-Google-FAQ&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C4cd7a0f805864468a2cb08d8a2a50fb8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438177109115169%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=RssBVgGe3ryeIudu%2Fg0WEEIyyUzkNo5mUBiXw3TCqT0%3D&amp;reserved=0

--
Rebecca Cran


Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Rebecca Cran <rebecca@...>
 

On 12/17/20 8:54 AM, Laszlo Ersek wrote:
On 12/17/20 15:48, Laszlo Ersek wrote:

I don't know who or what the <https://github.com/neverware-mirrors>
organization is, and I'd prefer not fetching code from them automatically.
I'm sorry, this was silly.
The whole point of git is "addressing by content". Our submodule
reference in edk2 makes us check out the cmocka tree at a known hash, so
where that comes from is totally irrelevant.
I'm OK with the proposal as posted.
Also, apparently Neverware is part of Google:

https://cloudreadykb.neverware.com/s/article/Neverware-is-now-part-of-Google-FAQ

--
Rebecca Cran


Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Laszlo Ersek
 

On 12/17/20 15:48, Laszlo Ersek wrote:

I don't know who or what the <https://github.com/neverware-mirrors>
organization is, and I'd prefer not fetching code from them automatically.
I'm sorry, this was silly.

The whole point of git is "addressing by content". Our submodule
reference in edk2 makes us check out the cmocka tree at a known hash, so
where that comes from is totally irrelevant.

I'm OK with the proposal as posted.

Thanks & sorry again,
Laszlo


Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Laszlo Ersek
 

On 12/16/20 19:45, Michael D Kinney wrote:
Hello,

We have had at least three incidents in the last year where the link to the
cmocka submodule in the UnitTestFrameworkPkg has not been available, and this
impacted the EDK II CI system. The following submodule link is the one that
is not reliable:

https://git.cryptomilk.org/projects/cmocka.git

We have identified two potential mirrors of this repo:

https://github.com/neverware-mirrors/cmocka.git
https://gitlab.com/cmocka/cmocka.git

The following patch provided a temporary fix for the EDK II CI agents, but
does not help other consumers of the edk2 repository.

https://github.com/tianocore/edk2/commit/be746104d1766a8c363e74d6063144657820d688

I have seen one suggestion that TianoCore create its own
mirror of cmocka. This does require monitoring and maintenance
by the TianoCore community. I would prefer to use a well
maintained mirror in github as long as we do not observe any
issues with the support of that mirror.

I propose we update the submodule in the UnitTestFrameworkPkg
to use the https://github.com/neverware-mirrors/cmocka.git mirror.
By using a mirror in github, we remove one external dependency.

Please provide feedback and comments on this proposal. If there
are no objections, then we will proceed with a patch review for
this update.
We could create our own fork under the <https://github.com/tianocore>
organization.

It does not require much extra maintenance or monitoring, in my opinion.
We only need to advance our fork to the actual master HEAD when we
intend to advance our submodule reference in edk2 as well. As long as
the submodule reference in edk2 does not move, the actual master HEAD of
the cmocka project may very well be ahead of our fork (mirror), without
causing issues.

I don't know who or what the <https://github.com/neverware-mirrors>
organization is, and I'd prefer not fetching code from them automatically.

Thanks
Laszlo


Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Laszlo Ersek
 

On 12/16/20 01:24, Kinney, Michael D wrote:
Hello,

The following bug has been fixed on edk2/master

https://bugzilla.tianocore.org/show_bug.cgi?id=3111
https://github.com/tianocore/edk2/pull/1226

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f53858d6acaa15a348bad7c
https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/<YYYY><MM>
Example: stable/202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.
- Looks good; just a typo in the example: "edk2-stable201111.01" should
use 2020, not 2011.


- I agree with Liming that stable branches should have a predefined
lifetime. Keeping stable branches regression-free is very difficult and
ungrateful work, and the community should not have expectations that
we're going to do "LTS" branches. That's too resource hungry; companies
have dedicated "maintenance engineer" positions for that.

Here's an example stable process:

https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/devel/stable-process.rst;hb=HEAD

I would recommend that, initially, we only promise support for the last
stable tag's branch.


- Including a unit test (if it exists) with the actual bugfix on a
stable branch seems important to me.

Thanks
Laszlo


Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Laszlo Ersek
 

On 12/15/20 20:39, Leif Lindholm wrote:
Makes sense. Let's go with the branch.

Mike: yes, that was what I was suggesting wrt cherry-picking and pushing.
Sounds good to me as well, thanks!
Laszlo


[RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Michael D Kinney
 

Hello,

We have had at least three incidents in the last year where the link to the
cmocka submodule in the UnitTestFrameworkPkg has not been available, and this
impacted the EDK II CI system. The following submodule link is the one that
is not reliable:

https://git.cryptomilk.org/projects/cmocka.git

We have identified two potential mirrors of this repo:

https://github.com/neverware-mirrors/cmocka.git
https://gitlab.com/cmocka/cmocka.git

The following patch provided a temporary fix for the EDK II CI agents, but
does not help other consumers of the edk2 repository.

https://github.com/tianocore/edk2/commit/be746104d1766a8c363e74d6063144657820d688

I have seen one suggestion that TianoCore create its own
mirror of cmocka. This does require monitoring and maintenance
by the TianoCore community. I would prefer to use a well
maintained mirror in github as long as we do not observe any
issues with the support of that mirror.

I propose we update the submodule in the UnitTestFrameworkPkg
to use the https://github.com/neverware-mirrors/cmocka.git mirror.
By using a mirror in github, we remove one external dependency.

Please provide feedback and comments on this proposal. If there
are no objections, then we will proceed with a patch review for
this update.

Thanks,

Mike


Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Michael D Kinney
 

-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Tuesday, December 15, 2020 5:19 PM
To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish'
<afish@apple.com>; 'Leif Lindholm' <leif@nuviainc.com>; lersek@redhat.com; 'Sean Brogan' <sean.brogan@microsoft.com>;
'Bret Barkelew' <Bret.Barkelew@microsoft.com>
Subject: 回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Mike:

-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@intel.com>
发送时间: 2020年12月16日 8:25
收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com)
<afish@apple.com>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek
<lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean
Brogan' <sean.brogan@microsoft.com>; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
主题: [RFC V2] Create supported branch from edk2-stable* tag (Required to
address critical bug BZ3111)

Hello,

The following bug has been fixed on edk2/master

https://bugzilla.tianocore.org/show_bug.cgi?id=3111
https://github.com/tianocore/edk2/pull/1226

This bug is also considered a critical bug against edk2-stable202011. The
behavior
of the Variable Lock Protocol was changed in a non-backwards compatible
manner in
edk2-stable202011 and this is impacting some downstream platforms. The
following
2 commits on edk2/master restore the original behavior of the Variable Lock
Protocol.


https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f
53858d6acaa15a348bad7c

https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91ce
deeed45bc0fbdfde49f7968
[Liming] This one is for unit test. It is not critical fix. I don't think it is required.

I agree it is not strictly required for functionality, but the bug fix that is required
was reviewed and submitted in a PR as a patch series. I think critical bug fixes should
be applied to a supported branch at the same granularity they were submitted to the
trunk. Since the EDK II CI system does not evaluate the stability of each patch in
a patch series, there is a risk to take portions of a patch series.

I suggest when a critical bug fix is identified, that we start with cherry-picking
all the patches in the patch series. If there is a specific concern about taking
the entire patch series, then that can be discussed and potentially a different
patch series can be applied to the supported branch. This would require CI on
supported branch to make sure the quality and functionality are the same.


The request here is to create a supported branch from edk2-stable202011 tag
and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a
request to create
a supported branch from one of those tags. As a result, there are a couple
opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/<YYYY><MM>
Example: stable/202011
Here is my suggestion on the live period of the stable tag branch.
The stable tag branch will be created only when the critical issue is found in this stable tag. By default, no stable tag
branch is created.
Now, the quarterly stable tag will be created every three months. So, this branch will exist for at most three months.
Once next stable tag is created, new stable tag will be used. Previous stable tag branch will not be maintained.
That means only latest stable tag branch will be maintained if it is created.
It is hard to predict how downstream platforms use a stable tag or a supported branch.
If a downstream consumer identifies a critical bug in a previous stable tag or
a supported branch, then that bug report needs to be evaluated and determine if
the bug fix needs to be applied to a stable branch or not. I do not think we should
reject all requests just because there is a more recent stable tag. We need
to evaluate each request.

We do want to encourage all platforms under development to use the latest stable
tag. But once a platform is released as a product using a specific stable tag
they may prefer to continue to use that stable tag for long term maintenance
of that platform.



2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/*
branches
and update GitHub settings so stable/* branches are protected
branches.
The patch has been verified in master. CI test may not be necessary.
In the general case where more than one critical bug may be fixed in a
stable branch, CI will help make sure that the combination of fixes
work together. For this first case, I agree that CI may not be required.


3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made
that
would trigger focused testing of the supported branch and creation of a
new
release. If all testing passes, then a tag is created on the
stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of
critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01
It is OK to create new stable tag per the request. The platform can use stable branch.
Thank you. I will start work on a patch for review.


Besides, there are few new issues. I have cancelled the bug triage meeting.

Thanks
Liming
Please let me know if you have any feedback or comments on this proposal.
The goal
is to close on this topic this week.

Thank you,

Mike


[RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Michael D Kinney
 

Hello,

The following bug has been fixed on edk2/master

https://bugzilla.tianocore.org/show_bug.cgi?id=3111
https://github.com/tianocore/edk2/pull/1226

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f53858d6acaa15a348bad7c
https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/<YYYY><MM>
Example: stable/202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.

Thank you,

Mike


Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Michael D Kinney
 

Hi Leif,

Thank you for the feedback.

I will send a revised RFC soon.

I will discuss with Liming in the Tianocore bug scrub this evening.

Mike

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Leif Lindholm
Sent: Tuesday, December 15, 2020 11:40 AM
To: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; rfc@edk2.groups.io; devel@edk2.groups.io; gaoliming@byosoft.com.cn;
Andrew Fish (afish@apple.com) <afish@apple.com>; Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>;
Sean Brogan <sean.brogan@microsoft.com>
Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Makes sense. Let's go with the branch.

Mike: yes, that was what I was suggesting wrt cherry-picking and pushing.

Best Regards,

Leif

On Tue, Dec 15, 2020 at 19:06:21 +0000, Bret Barkelew wrote:
FWIW, we tried both branches and tags in Mu, and have gotten more
mileage out of branches. We will still do tags periodically (to
establish a point at which all the sub repos were put through a full
validation run), but our platform consumers have shown a preference
for just living on the stabilized branch.

- Bret

From: Kinney, Michael D<mailto:michael.d.kinney@intel.com>
Sent: Tuesday, December 15, 2020 10:57 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@nuviainc.com<mailto:leif@nuviainc.com>; Kinney, Michael
D<mailto:michael.d.kinney@intel.com>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Andrew
Fish (afish@apple.com)<mailto:afish@apple.com>; Laszlo Ersek <lersek@redhat.com>
(lersek@redhat.com)<mailto:lersek@redhat.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Bret
Barkelew<mailto:Bret.Barkelew@microsoft.com>
Subject: [EXTERNAL] RE: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug
BZ3111)

Hi Leif,

I think you are suggesting that a local branch could be created from edk2-stable202011 and the
2 commits cherry-picked onto that local branch and then create a tag on that local branch and
only push the new tag to edk2 repo (e.g. edk2-stable202011.01). Correct?

I think with this approach, we would wait for the community to request a new stable dot tag
(e.g. edk2-stable202011.01) with a specific set of commits.

Another advantage of branch vs tag is that platforms that want to always use an edk2-stable*
tag with all the known critical bug fixes can pull the branch to get the latest fixes. Or select
a tag on the branch or a specific sha on the branch based on their platform requirements. If
a platform has to wait for a new stable dot tag then the platform can not test with those critical
fixes directly from the edk2 repo. They would have to create their own downstream.

I think between the CI use case and this downstream platform use case, a branch has more
advantages than a tag.

I am fine with removing the redundant use of 'stable' and 'edk2' in the branch naming proposal.

Proposal: stable/*
Example: stable/202011

Thanks,

Mike

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Leif Lindholm
Sent: Tuesday, December 15, 2020 9:17 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com)
<afish@apple.com>;
Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean Brogan' <sean.brogan@microsoft.com>;
'Bret
Barkelew' <Bret.Barkelew@microsoft.com>
Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Hi Mike,

This looks fine to me.
I will add a potential tweak that I won't strongly advocate for, but
think should be considered:
We don't technically need a branch for this; a tag could be pushed
directly.

On Tue, Dec 15, 2020 at 16:53:09 +0000, Kinney, Michael D wrote:
Hello,

The following bug has been fixed on edk2/master

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;da
ta=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;
sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%
7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743
6554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=
pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&amp;reserved=0

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
893cfe2847b83da74f53858d6acaa15a348bad7c&amp;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b40
24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&amp;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b40
24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&amp;reserved=0

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/edk2-stable*
Example: stable/edk2-stable202011
For the bikeshedding part, if we're doing the branches, I support
using the stable/ prefix, but I also think this obviates the need to
include the word stable in the portion after /.
Since branches unlike tags don't have global namespace, I also think
there is no need for the edk2 portion of the name.
So an example branch name could be:
stable/202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.
This would of course mandate the use of branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01
Sounds good to me.

Best Regards,

Leif

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.

Thank you,

Mike





Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Leif Lindholm
 

Makes sense. Let's go with the branch.

Mike: yes, that was what I was suggesting wrt cherry-picking and pushing.

Best Regards,

Leif

On Tue, Dec 15, 2020 at 19:06:21 +0000, Bret Barkelew wrote:
FWIW, we tried both branches and tags in Mu, and have gotten more
mileage out of branches. We will still do tags periodically (to
establish a point at which all the sub repos were put through a full
validation run), but our platform consumers have shown a preference
for just living on the stabilized branch.

- Bret

From: Kinney, Michael D<mailto:michael.d.kinney@intel.com>
Sent: Tuesday, December 15, 2020 10:57 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@nuviainc.com<mailto:leif@nuviainc.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Andrew Fish (afish@apple.com)<mailto:afish@apple.com>; Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com)<mailto:lersek@redhat.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Subject: [EXTERNAL] RE: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Hi Leif,

I think you are suggesting that a local branch could be created from edk2-stable202011 and the
2 commits cherry-picked onto that local branch and then create a tag on that local branch and
only push the new tag to edk2 repo (e.g. edk2-stable202011.01). Correct?

I think with this approach, we would wait for the community to request a new stable dot tag
(e.g. edk2-stable202011.01) with a specific set of commits.

Another advantage of branch vs tag is that platforms that want to always use an edk2-stable*
tag with all the known critical bug fixes can pull the branch to get the latest fixes. Or select
a tag on the branch or a specific sha on the branch based on their platform requirements. If
a platform has to wait for a new stable dot tag then the platform can not test with those critical
fixes directly from the edk2 repo. They would have to create their own downstream.

I think between the CI use case and this downstream platform use case, a branch has more
advantages than a tag.

I am fine with removing the redundant use of 'stable' and 'edk2' in the branch naming proposal.

Proposal: stable/*
Example: stable/202011

Thanks,

Mike

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Leif Lindholm
Sent: Tuesday, December 15, 2020 9:17 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com) <afish@apple.com>;
Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean Brogan' <sean.brogan@microsoft.com>; 'Bret
Barkelew' <Bret.Barkelew@microsoft.com>
Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Hi Mike,

This looks fine to me.
I will add a potential tweak that I won't strongly advocate for, but
think should be considered:
We don't technically need a branch for this; a tag could be pushed
directly.

On Tue, Dec 15, 2020 at 16:53:09 +0000, Kinney, Michael D wrote:
Hello,

The following bug has been fixed on edk2/master

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&amp;reserved=0

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53858d6acaa15a348bad7c&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&amp;reserved=0

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/edk2-stable*
Example: stable/edk2-stable202011
For the bikeshedding part, if we're doing the branches, I support
using the stable/ prefix, but I also think this obviates the need to
include the word stable in the portion after /.
Since branches unlike tags don't have global namespace, I also think
there is no need for the edk2 portion of the name.
So an example branch name could be:
stable/202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.
This would of course mandate the use of branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01
Sounds good to me.

Best Regards,

Leif

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.

Thank you,

Mike



Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Bret Barkelew <bret.barkelew@...>
 

FWIW, we tried both branches and tags in Mu, and have gotten more mileage out of branches. We will still do tags periodically (to establish a point at which all the sub repos were put through a full validation run), but our platform consumers have shown a preference for just living on the stabilized branch.

- Bret

From: Kinney, Michael D<mailto:michael.d.kinney@intel.com>
Sent: Tuesday, December 15, 2020 10:57 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@nuviainc.com<mailto:leif@nuviainc.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Andrew Fish (afish@apple.com)<mailto:afish@apple.com>; Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com)<mailto:lersek@redhat.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Subject: [EXTERNAL] RE: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Hi Leif,

I think you are suggesting that a local branch could be created from edk2-stable202011 and the
2 commits cherry-picked onto that local branch and then create a tag on that local branch and
only push the new tag to edk2 repo (e.g. edk2-stable202011.01). Correct?

I think with this approach, we would wait for the community to request a new stable dot tag
(e.g. edk2-stable202011.01) with a specific set of commits.

Another advantage of branch vs tag is that platforms that want to always use an edk2-stable*
tag with all the known critical bug fixes can pull the branch to get the latest fixes. Or select
a tag on the branch or a specific sha on the branch based on their platform requirements. If
a platform has to wait for a new stable dot tag then the platform can not test with those critical
fixes directly from the edk2 repo. They would have to create their own downstream.

I think between the CI use case and this downstream platform use case, a branch has more
advantages than a tag.

I am fine with removing the redundant use of 'stable' and 'edk2' in the branch naming proposal.

Proposal: stable/*
Example: stable/202011

Thanks,

Mike

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Leif Lindholm
Sent: Tuesday, December 15, 2020 9:17 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com) <afish@apple.com>;
Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean Brogan' <sean.brogan@microsoft.com>; 'Bret
Barkelew' <Bret.Barkelew@microsoft.com>
Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Hi Mike,

This looks fine to me.
I will add a potential tweak that I won't strongly advocate for, but
think should be considered:
We don't technically need a branch for this; a tag could be pushed
directly.

On Tue, Dec 15, 2020 at 16:53:09 +0000, Kinney, Michael D wrote:
Hello,

The following bug has been fixed on edk2/master

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&amp;reserved=0

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53858d6acaa15a348bad7c&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&amp;reserved=0

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/edk2-stable*
Example: stable/edk2-stable202011
For the bikeshedding part, if we're doing the branches, I support
using the stable/ prefix, but I also think this obviates the need to
include the word stable in the portion after /.
Since branches unlike tags don't have global namespace, I also think
there is no need for the edk2 portion of the name.
So an example branch name could be:
stable/202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.
This would of course mandate the use of branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01
Sounds good to me.

Best Regards,

Leif

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.

Thank you,

Mike



Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Michael D Kinney
 

Hi Leif,

I think you are suggesting that a local branch could be created from edk2-stable202011 and the
2 commits cherry-picked onto that local branch and then create a tag on that local branch and
only push the new tag to edk2 repo (e.g. edk2-stable202011.01). Correct?

I think with this approach, we would wait for the community to request a new stable dot tag
(e.g. edk2-stable202011.01) with a specific set of commits.

Another advantage of branch vs tag is that platforms that want to always use an edk2-stable*
tag with all the known critical bug fixes can pull the branch to get the latest fixes. Or select
a tag on the branch or a specific sha on the branch based on their platform requirements. If
a platform has to wait for a new stable dot tag then the platform can not test with those critical
fixes directly from the edk2 repo. They would have to create their own downstream.

I think between the CI use case and this downstream platform use case, a branch has more
advantages than a tag.

I am fine with removing the redundant use of 'stable' and 'edk2' in the branch naming proposal.

Proposal: stable/*
Example: stable/202011

Thanks,

Mike

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Leif Lindholm
Sent: Tuesday, December 15, 2020 9:17 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com) <afish@apple.com>;
Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean Brogan' <sean.brogan@microsoft.com>; 'Bret
Barkelew' <Bret.Barkelew@microsoft.com>
Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Hi Mike,

This looks fine to me.
I will add a potential tweak that I won't strongly advocate for, but
think should be considered:
We don't technically need a branch for this; a tag could be pushed
directly.

On Tue, Dec 15, 2020 at 16:53:09 +0000, Kinney, Michael D wrote:
Hello,

The following bug has been fixed on edk2/master

https://bugzilla.tianocore.org/show_bug.cgi?id=3111
https://github.com/tianocore/edk2/pull/1226

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f53858d6acaa15a348bad7c
https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/edk2-stable*
Example: stable/edk2-stable202011
For the bikeshedding part, if we're doing the branches, I support
using the stable/ prefix, but I also think this obviates the need to
include the word stable in the portion after /.
Since branches unlike tags don't have global namespace, I also think
there is no need for the edk2 portion of the name.
So an example branch name could be:
stable/202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.
This would of course mandate the use of branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01
Sounds good to me.

Best Regards,

Leif

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.

Thank you,

Mike



Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Leif Lindholm
 

Hi Mike,

This looks fine to me.
I will add a potential tweak that I won't strongly advocate for, but
think should be considered:
We don't technically need a branch for this; a tag could be pushed
directly.

On Tue, Dec 15, 2020 at 16:53:09 +0000, Kinney, Michael D wrote:
Hello,

The following bug has been fixed on edk2/master

https://bugzilla.tianocore.org/show_bug.cgi?id=3111
https://github.com/tianocore/edk2/pull/1226

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f53858d6acaa15a348bad7c
https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/edk2-stable*
Example: stable/edk2-stable202011
For the bikeshedding part, if we're doing the branches, I support
using the stable/ prefix, but I also think this obviates the need to
include the word stable in the portion after /.
Since branches unlike tags don't have global namespace, I also think
there is no need for the edk2 portion of the name.
So an example branch name could be:
stable/202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.
This would of course mandate the use of branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01
Sounds good to me.

Best Regards,

Leif

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.

Thank you,

Mike


[RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

Michael D Kinney
 

Hello,

The following bug has been fixed on edk2/master

https://bugzilla.tianocore.org/show_bug.cgi?id=3111
https://github.com/tianocore/edk2/pull/1226

This bug is also considered a critical bug against edk2-stable202011. The behavior
of the Variable Lock Protocol was changed in a non-backwards compatible manner in
edk2-stable202011 and this is impacting some downstream platforms. The following
2 commits on edk2/master restore the original behavior of the Variable Lock Protocol.

https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f53858d6acaa15a348bad7c
https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968

The request here is to create a supported branch from edk2-stable202011 tag and apply
these 2 commits as critical bug fixes on the supported branch.

Since we started using the edk2-stable* tag process, there has not been a request to create
a supported branch from one of those tags. As a result, there are a couple opens that
need to be addressed:

1) Supported branch naming convention.

Proposal: stable/edk2-stable*
Example: stable/edk2-stable202011

2) CI requirements for supported branches.

Proposal: Update .azurepipelines yml files to also trigger on stable/* branches
and update GitHub settings so stable/* branches are protected branches.

3) Release requirements for supported branches.

Proposal: If there are a significant number of critical fixes applied to
a stable/edk2-stable* branch, then a request for a release can be made that
would trigger focused testing of the supported branch and creation of a new
release. If all testing passes, then a tag is created on the stable/edk2-stable*
branch and a release is created on GitHub that summarizes the set of critical
fixes and the testing performed.

Proposal: edk2-stable<YYYY><MM>.<XX>
Example : edk2-stable201111.01

Please let me know if you have any feedback or comments on this proposal. The goal
is to close on this topic this week.

Thank you,

Mike


Re: The code that creates the TCG Event Log needs an audit

Yao, Jiewen
 

Besides document, we filed below EDKII Bugzilla during code revisit:

3087 EDK2 Code unassigned@tianocore.org UNCO --- TCG: EFI_EXIT_BOOT_SERVICES_INVOCATION is not recorded when ExitBootService Fails Tue 21:10
3088 EDK2 Code unassigned@tianocore.org UNCO --- Enforce CRTM version check in Tcg2Pei Tue 21:09
3089 EDK2 Code unassigned@tianocore.org UNCO --- Deprecate MemoryOverwriteRequestControlLock module Tue 21:09
3090 EDK2 Code unassigned@tianocore.org UNCO --- Tcg2Smm should translate the Manufacture ID to ACPI PNP ID for _HID name string Tue 21:08

Thank you
Yao Jiewen

-----Original Message-----
From: Zimmer, Vincent <vincent.zimmer@intel.com>
Sent: Friday, December 11, 2020 1:34 AM
To: Yao, Jiewen <jiewen.yao@intel.com>; rfc@edk2.groups.io;
dick_wilkins@phoenix.com
Subject: RE: The code that creates the TCG Event Log needs an audit

Responsive to Jiewen's message below one can find "Understanding the
Trusted Boot Chain Implementation" at the following links:

HTML: https://tianocore-docs.github.io/edk2-TrustedBootChain/release-
1.00/
PDF: https://tianocore-docs.github.io/edk2-TrustedBootChain/release-
1.00/edk2-TrustedBootChain-release-1.00.pdf
MOBI: https://tianocore-docs.github.io/edk2-TrustedBootChain/release-
1.00/edk2-TrustedBootChain-release-1.00.mobi
EPUB: https://tianocore-docs.github.io/edk2-TrustedBootChain/release-
1.00/edk2-TrustedBootChain-release-1.00.epub

These binaries are compiled from https://github.com/tianocore-docs/edk2-
TrustedBootChain. Feel free to post any feedback to this list or the latter
repo (issues, PR's), too.

Vincent

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@intel.com>
Sent: Tuesday, November 17, 2020 9:55 PM
To: rfc@edk2.groups.io; dick_wilkins@phoenix.com
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Zimmer, Vincent
<vincent.zimmer@intel.com>
Subject: RE: The code that creates the TCG Event Log needs an audit

Good suggestion. Thanks Dick.
Vincent and I have plan to refresh our TPM2 whitepaper recently.
We will definitely take it into consideration, to add more detail on
describing the EDK2 intent and implementation.

Thank you
Yao Jiewen

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Dick
Wilkins
Sent: Wednesday, November 18, 2020 2:23 AM
To: rfc@edk2.groups.io
Subject: [edk2-rfc] The code that creates the TCG Event Log needs an
audit

[RFC] The code that creates the TCG Event Log needs an audit Problem
Statement The TCG support code included in the EDK2 tree is in place
to enable the two major features provided by a platform TPM. 1) To
"seal" secrets in to TPM memory (i.e., Bitlocker keys), and 2) to
enable remote attestation and verification of a platform's security
status after boot ("measured boot").
The first feature is widely being used. Use of the second has been
described in NIST SP 800-155 but not widely implemented. The industry
and several standard groups are attempting to enable this attestation
and verification process. To make that happen they need, not just the
PCR recorded measurements, but also the accompanying event log. The
even log is used by a verifier to understand the how PCR values were
created and decide if those values have a negative security effect on a
platform.
Researchers, attempting to implement proof-of-concept verifiers that
can parse the event logs produced by the wide variety of platform
types across the industry, have generally found they are unable to
parse the logs. They have found problems with missing data,
misunderstandings of what should have been logged, and outright code
bugs.
Enablement of measured boot and verification is a primary purpose of
the code in \SecurityPkg\Tcg and supporting functions. Since the EDK2
code is the implementation of this support most widely used across the
industry, the community needs to make sure it provides its intended
functionality.
Proposals
We need to audit the existing code to make sure it is doing what it is
supposed to do per specification and is as bug free as we can make it.
And we need to make sure it continues to provide correct functionality
as it is updated and maintained.
To make sure the code is doing what it is supposed to do, it has been
suggested that the community audit the existing code and develop a
design document describing the existing implementation, including each
event type enumerated along with a specification of its contents. The
process of reviewing the code to provide this document would have a
positive side effect of doing a code inspection that may result in
finding current implementation bugs.
It has been reported that the TCG specifications may be hard to
understand and that may result in implementations that do not provide
the intended functionality. Also, the TCG specs point to UEFI specs
for some details and as the specifications drift over time, this may
result in implementor confusion and errors.
With a document describing the EDK2 intent and implementation details,
members of TCG workgroups and the team implementing the proof-of-
concept parser/verifier can provide input on where implementation has
diverged from the intent of the relevant specifications.
To insure the EDK2 code continues to function properly, the community
also needs to provide tests for this code to reduce the likelihood of
future regressions in functionality.


Dick Wilkins, Ph.D.
Principal Technology Liaison
Phoenix Technologies, Ltd.
Dick_Wilkins@phoenix.com<mailto:Dick_Wilkins@phoenix.com>
+1-425-503-4639 Cell





281 - 300 of 747