|
Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
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)
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)
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
|
|
|
Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
toggle quoted messageShow quoted text
-----Original Message-----
From: gaoliming <gaoliming@...>
Sent: Tuesday, December 15, 2020 5:19 PM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish'
<afish@...>; 'Leif Lindholm' <leif@...>; lersek@...; 'Sean Brogan' <sean.brogan@...>;
'Bret Barkelew' <Bret.Barkelew@...>
Subject: 回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Mike:
-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@...>
发送时间: 2020年12月16日 8:25
收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
gaoliming@...; Andrew Fish (afish@...)
<afish@...>; Leif Lindholm <leif@...>; Laszlo Ersek
<lersek@...> (lersek@...) <lersek@...>; 'Sean
Brogan' <sean.brogan@...>; 'Bret Barkelew'
<Bret.Barkelew@...>; Kinney, Michael D
<michael.d.kinney@...>
主题: [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)
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/1226This 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/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968The 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)
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
toggle quoted messageShow quoted text
-----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@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; rfc@edk2.groups.io; devel@edk2.groups.io; gaoliming@...;
Andrew Fish (afish@...) <afish@...>; Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>;
Sean Brogan <sean.brogan@...>
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@...>
Sent: Tuesday, December 15, 2020 10:57 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@...<mailto:leif@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; Andrew Fish (afish@...)<mailto:afish@...>; Laszlo Ersek <lersek@...>
(lersek@...)<mailto:lersek@...>; Sean Brogan<mailto:sean.brogan@...>; Bret
Barkelew<mailto:Bret.Barkelew@...>
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@...>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@...; Andrew Fish (afish@...)
<afish@...>;
Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>;
'Bret
Barkelew' <Bret.Barkelew@...>
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&
sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&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&sdata=
pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&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&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b40
24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b40
24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&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)
Makes sense. Let's go with the branch.
Mike: yes, that was what I was suggesting wrt cherry-picking and pushing.
Best Regards,
Leif
toggle quoted messageShow quoted text
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@...>
Sent: Tuesday, December 15, 2020 10:57 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@...<mailto:leif@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; Andrew Fish (afish@...)<mailto:afish@...>; Laszlo Ersek <lersek@...> (lersek@...)<mailto:lersek@...>; Sean Brogan<mailto:sean.brogan@...>; Bret Barkelew<mailto:Bret.Barkelew@...>
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@...>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@...; Andrew Fish (afish@...) <afish@...>;
Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>; 'Bret
Barkelew' <Bret.Barkelew@...>
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&sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&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&sdata=pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&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&sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&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&sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&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@...> Sent: Tuesday, December 15, 2020 10:57 AM To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@...<mailto:leif@...>; Kinney, Michael D<mailto:michael.d.kinney@...> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; Andrew Fish (afish@...)<mailto:afish@...>; Laszlo Ersek <lersek@...> (lersek@...)<mailto:lersek@...>; Sean Brogan<mailto:sean.brogan@...>; Bret Barkelew<mailto:Bret.Barkelew@...> 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@...>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@...; Andrew Fish (afish@...) <afish@...>;
Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>; 'Bret
Barkelew' <Bret.Barkelew@...>
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&sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&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&sdata=pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&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&sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&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&sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&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)
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
toggle quoted messageShow quoted text
-----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@...>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@...; Andrew Fish (afish@...) <afish@...>;
Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>; 'Bret
Barkelew' <Bret.Barkelew@...>
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)
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)
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/1226This 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/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968The 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
Besides document, we filed below EDKII Bugzilla during code revisit:
3087 EDK2 Code unassigned@... UNCO --- TCG: EFI_EXIT_BOOT_SERVICES_INVOCATION is not recorded when ExitBootService Fails Tue 21:10
3088 EDK2 Code unassigned@... UNCO --- Enforce CRTM version check in Tcg2Pei Tue 21:09
3089 EDK2 Code unassigned@... UNCO --- Deprecate MemoryOverwriteRequestControlLock module Tue 21:09
3090 EDK2 Code unassigned@... UNCO --- Tcg2Smm should translate the Manufacture ID to ACPI PNP ID for _HID name string Tue 21:08
Thank you
Yao Jiewen
toggle quoted messageShow quoted text
-----Original Message-----
From: Zimmer, Vincent <vincent.zimmer@...>
Sent: Friday, December 11, 2020 1:34 AM
To: Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io;
dick_wilkins@...
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@...>
Sent: Tuesday, November 17, 2020 9:55 PM
To: rfc@edk2.groups.io; dick_wilkins@...
Cc: Yao, Jiewen <jiewen.yao@...>; Zimmer, Vincent
<vincent.zimmer@...>
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@...<mailto:Dick_Wilkins@...>
+1-425-503-4639 Cell
|
|
|
Re: The code that creates the TCG Event Log needs an audit
Zimmer, Vincent
toggle quoted messageShow quoted text
-----Original Message----- From: Yao, Jiewen <jiewen.yao@...> Sent: Tuesday, November 17, 2020 9:55 PM To: rfc@edk2.groups.io; dick_wilkins@... Cc: Yao, Jiewen <jiewen.yao@...>; Zimmer, Vincent <vincent.zimmer@...> 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@...<mailto:Dick_Wilkins@...>
+1-425-503-4639 Cell
|
|
|
RFC: Adding support for ARM (RNDR etc.) to RngDxe
Rebecca Cran <rebecca@...>
Currently, RngDxe in SecurityPkg only supports Intel, with RdRand support. This RFC is to start a discussion about adding support for ARM. I have a Git branch with support for the optional ARMv8.5 RNDR instruction at https://github.com/bcran/edk2/commits/bcran-rndr which moves the existing Intel support into a Rand directory, and adds code to support RNDR in a new AArch64 directory. There are other RNG implementations available for ARM, including platform-specific approaches on Graviton ( https://lwn.net/Articles/790304/) and other platforms, so a more thorough rearchitecting/redesign may be desired. -- Rebecca Cran
|
|
|
Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
Maybe you can upload the content to https://edk2.groups.io/g/devel/files/Designs, where we hold the design review ppt, etc. I assume we want to discuss below two APIs implementation, right? 1) RngLib 2) EFI_RNG_PROTOCOL Thank you Yao Jiewen
-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Leif Lindholm
Sent: Thursday, December 10, 2020 8:52 PM
To: Sami Mujawar <Sami.Mujawar@...>
Cc: devel@edk2.groups.io; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>; Ard Biesheuvel <Ard.Biesheuvel@...>;
rebecca@...; rfc@edk2.groups.io; Yao, Jiewen
<jiewen.yao@...>; Kumar, Rahul1 <rahul1.kumar@...>; nd
<nd@...>
Subject: Re: [edk2-rfc] [edk2-devel] RFC: Adding support for ARM (RNDR etc.)
to RngDxe
Hi Sami,
JPGs work, but preferably published in a location where they're
unlikely to be deleted, and posted as URLs.
https://app.diagrams.net/ doesn't require a licensed application to
edit, and can be "saved to github" for example.
Please make sure to use the diagrams to support/clarify the mailing
list conversation rather than replacing it.
Best Regards,
Leif
On Thu, Dec 10, 2020 at 11:26:26 +0000, Sami Mujawar wrote:
Hi All,
I am working on the TRNG FW API interface and will share more details for the discussion soon.
We had some thoughts about streamlining the RngDxe implementations
and would like to share some diagrams for the discussion.
My diagrams are in Visio that I can export as JPG images. However, I
am open to switching to any other suggested tool.
Hi Leif,
Can you suggest on how we can collaborate to share diagrams/documents, please?
Regards,
Sami Mujawar
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer
El-Haj-Mahmoud via groups.io
Sent: 09 December 2020 04:48 AM
To: devel@edk2.groups.io
Cc: rfc@edk2.groups.io; Jiewen Yao <jiewen.yao@...>; Rahul Kumar <rahul1.kumar@...>
Subject: Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
There is also the TRNG FW API, which is an architected SMC firmware
interface:
https://developer.arm.com/documentation/den0098/latest/
________________________________
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
<devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of
Rebecca Cran via groups.io
<rebecca@...<mailto:rebecca@...
Sent: Tuesday, December 8, 2020, 11:33 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Jiewen Yao; Rahul Kumar
Subject: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
Currently, RngDxe in SecurityPkg only supports Intel, with RdRand support.
This RFC is to start a discussion about adding support for ARM.
I have a Git branch with support for the optional ARMv8.5 RNDR
instruction at https://github.com/bcran/edk2/commits/bcran-rndr which
moves the existing Intel support into a Rand directory, and adds code to
support RNDR in a new AArch64 directory.
There are other RNG implementations available for ARM, including
platform-specific approaches on Graviton
(https://lwn.net/Articles/790304/) and other platforms, so a more
thorough rearchitecting/redesign may be desired.
--
Rebecca Cran
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to
any other person, use it for any purpose, or store or copy the information in
any medium. Thank you.
|
|
|
Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
Hi Sami, JPGs work, but preferably published in a location where they're unlikely to be deleted, and posted as URLs. https://app.diagrams.net/ doesn't require a licensed application to edit, and can be "saved to github" for example. Please make sure to use the diagrams to support/clarify the mailing list conversation rather than replacing it. Best Regards, Leif
On Thu, Dec 10, 2020 at 11:26:26 +0000, Sami Mujawar wrote: Hi All,
I am working on the TRNG FW API interface and will share more details for the discussion soon.
We had some thoughts about streamlining the RngDxe implementations
and would like to share some diagrams for the discussion.
My diagrams are in Visio that I can export as JPG images. However, I
am open to switching to any other suggested tool.
Hi Leif,
Can you suggest on how we can collaborate to share diagrams/documents, please?
Regards,
Sami Mujawar
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-Haj-Mahmoud via groups.io
Sent: 09 December 2020 04:48 AM
To: devel@edk2.groups.io
Cc: rfc@edk2.groups.io; Jiewen Yao <jiewen.yao@...>; Rahul Kumar <rahul1.kumar@...>
Subject: Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
There is also the TRNG FW API, which is an architected SMC firmware interface:
https://developer.arm.com/documentation/den0098/latest/
________________________________
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of Rebecca Cran via groups.io <rebecca@...<mailto:rebecca@...>>
Sent: Tuesday, December 8, 2020, 11:33 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Jiewen Yao; Rahul Kumar
Subject: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
Currently, RngDxe in SecurityPkg only supports Intel, with RdRand support.
This RFC is to start a discussion about adding support for ARM.
I have a Git branch with support for the optional ARMv8.5 RNDR
instruction at https://github.com/bcran/edk2/commits/bcran-rndr which
moves the existing Intel support into a Rand directory, and adds code to
support RNDR in a new AArch64 directory.
There are other RNG implementations available for ARM, including
platform-specific approaches on Graviton
(https://lwn.net/Articles/790304/) and other platforms, so a more
thorough rearchitecting/redesign may be desired.
--
Rebecca Cran
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
|
Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
Sami Mujawar <sami.mujawar@...>
Hi All, I am working on the TRNG FW API interface and will share more details for the discussion soon. We had some thoughts about streamlining the RngDxe implementations and would like to share some diagrams for the discussion. My diagrams are in Visio that I can export as JPG images. However, I am open to switching to any other suggested tool. Hi Leif, Can you suggest on how we can collaborate to share diagrams/documents, please? Regards, Sami Mujawar From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-Haj-Mahmoud via groups.io Sent: 09 December 2020 04:48 AM To: devel@edk2.groups.io Cc: rfc@edk2.groups.io; Jiewen Yao <jiewen.yao@...>; Rahul Kumar <rahul1.kumar@...> Subject: Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe There is also the TRNG FW API, which is an architected SMC firmware interface: https://developer.arm.com/documentation/den0098/latest/________________________________ From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of Rebecca Cran via groups.io <rebecca@...<mailto:rebecca@...>> Sent: Tuesday, December 8, 2020, 11:33 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Jiewen Yao; Rahul Kumar Subject: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe Currently, RngDxe in SecurityPkg only supports Intel, with RdRand support. This RFC is to start a discussion about adding support for ARM. I have a Git branch with support for the optional ARMv8.5 RNDR instruction at https://github.com/bcran/edk2/commits/bcran-rndr which moves the existing Intel support into a Rand directory, and adds code to support RNDR in a new AArch64 directory. There are other RNG implementations available for ARM, including platform-specific approaches on Graviton ( https://lwn.net/Articles/790304/) and other platforms, so a more thorough rearchitecting/redesign may be desired. -- Rebecca Cran IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
|
Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
There is also the TRNG FW API, which is an architected SMC firmware interface: https://developer.arm.com/documentation/den0098/latest/________________________________ From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Rebecca Cran via groups.io <rebecca@...> Sent: Tuesday, December 8, 2020, 11:33 PM To: devel@edk2.groups.io Cc: rfc@edk2.groups.io; Jiewen Yao; Rahul Kumar Subject: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe Currently, RngDxe in SecurityPkg only supports Intel, with RdRand support. This RFC is to start a discussion about adding support for ARM. I have a Git branch with support for the optional ARMv8.5 RNDR instruction at https://github.com/bcran/edk2/commits/bcran-rndr which moves the existing Intel support into a Rand directory, and adds code to support RNDR in a new AArch64 directory. There are other RNG implementations available for ARM, including platform-specific approaches on Graviton ( https://lwn.net/Articles/790304/) and other platforms, so a more thorough rearchitecting/redesign may be desired. -- Rebecca Cran IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
|
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
toggle quoted messageShow quoted text
-----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@...<mailto:Dick_Wilkins@...>
+1-425-503-4639 Cell
|
|
|
