Has there been any progress on this "code-first process" proposal? Any timeline on when we should expect it to be launched?

Thanks,
--Samer


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Felix
Polyudov via Groups.Io
Sent: Friday, February 14, 2020 10:30 AM
To: rfc@edk2.groups.io; 'leif@...' <leif@...>;
devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for
UEFI-forum specifications

Leif,

The process does not in fact change the UEFI bylaws - the change is
that the development (of both specification and code) happens in the
open. The resulting specification update is then submitted to the
appropriate working goup as an Engineering Change Request (ECR), and
voted on. For the UEFI Forum, this is a change in workflow, not a change in process.

I think it would be good to add more details regarding the interaction between edk2 and UEFI forum.
Here is what I suggest:
Each specification update Bugzilla ticket must have a sponsor. A sponsor is a person or a company that will be presenting change request to the UEFI forum.
A sponsor has to be identified early in the process. Preferably along with Buzilla ticket creation.
It is sponsor's responsibility to officially submit ECR to the UEFI forum by creating a mantis ticket with a Bugzilla link.
There are two reasons to create mantis ticket early in the process:
- Creation of the ticket exposes the effort to the UEFI forum thus enabling early feedback from the members(via Bugzilla), which may reduce number of iterations in the
implement --> get feedback --> re-implement cycle.
- edk2 effort will be taken into consideration while scheduling future
specification releases


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.



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.

The process does not in fact change the UEFI bylaws - the change is
that the development (of both specification and code) happens in the
open. The resulting specification update is then submitted to the
appropriate working goup as an Engineering Change Request (ECR), and
voted on. For the UEFI Forum, this is a change in workflow, not a change in process.

Has there been any progress on this "code-first process" proposal? Any timeline on when we should expect it to be launched?

Thanks,
--Samer


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Felix
Polyudov via Groups.Io
Sent: Friday, February 14, 2020 10:30 AM
To: rfc@edk2.groups.io; 'leif@...' <leif@...>;
devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for
UEFI-forum specifications

Leif,

The process does not in fact change the UEFI bylaws - the change is
that the development (of both specification and code) happens in the
open. The resulting specification update is then submitted to the
appropriate working goup as an Engineering Change Request (ECR), and
voted on. For the UEFI Forum, this is a change in workflow, not a change in process.

I think it would be good to add more details regarding the interaction between edk2 and UEFI forum.
Here is what I suggest:
Each specification update Bugzilla ticket must have a sponsor. A sponsor is a person or a company that will be presenting change request to the UEFI forum.
A sponsor has to be identified early in the process. Preferably along with Buzilla ticket creation.
It is sponsor's responsibility to officially submit ECR to the UEFI forum by creating a mantis ticket with a Bugzilla link.
There are two reasons to create mantis ticket early in the process:
- Creation of the ticket exposes the effort to the UEFI forum thus enabling early feedback from the members(via Bugzilla), which may reduce number of iterations in the
implement --> get feedback --> re-implement cycle.
- edk2 effort will be taken into consideration while scheduling future
specification releases


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.



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.

Has there been any progress on this "code-first process" proposal? Any timeline on when we should expect it to be launched?

Thanks,
--Samer


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Felix Polyudov via Groups.Io
Sent: Friday, February 14, 2020 10:30 AM
To: rfc@edk2.groups.io; 'leif@...' <leif@...>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

Leif,

The process does not in fact change the UEFI bylaws - the change is
that the development (of both specification and code) happens in the
open. The resulting specification update is then submitted to the
appropriate working goup as an Engineering Change Request (ECR), and
voted on. For the UEFI Forum, this is a change in workflow, not a change in process.

I think it would be good to add more details regarding the interaction between edk2 and UEFI forum.
Here is what I suggest:
Each specification update Bugzilla ticket must have a sponsor. A sponsor is a person or a company that will be presenting change request to the UEFI forum.
A sponsor has to be identified early in the process. Preferably along with Buzilla ticket creation.
It is sponsor's responsibility to officially submit ECR to the UEFI forum by creating a mantis ticket with a Bugzilla link.
There are two reasons to create mantis ticket early in the process:
- Creation of the ticket exposes the effort to the UEFI forum thus enabling early feedback from the members(via Bugzilla), which may reduce number of iterations in the
implement --> get feedback --> re-implement cycle.
- edk2 effort will be taken into consideration while scheduling future specification releases


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.



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.

There are two infrequent issues in variable.

Ming Huang (2):
MdeModulePkg/Variable: Remove some debug print for runtime
MdeModulePkg/Variable: Move FindVariable after AutoUpdateLangVariable

.../Universal/Variable/RuntimeDxe/Variable.c | 44 ++++++++++----------
1 file changed, 21 insertions(+), 23 deletions(-)

-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Friday, February 7, 2020 6:13 AM
To: brbarkel@...; rfc@edk2.groups.io
Cc: edk2-devel@...
Subject: RE: [edk2-rfc] [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries,
and Implementation for VariableLock Alternative

Thanks, Bret.

Comments below.

-----Original Message-----
From: brbarkel via [] <brbarkel=microsoft.com@[]>
Sent: Friday, February 7, 2020 5:49 AM
To: Yao; Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries,
and Implementation for VariableLock Alternative

Sorry, Jiewen. I missed this email when it came in...

1. We have 2 variable related protocol - EDKII_VARIABLE_LOCK_PROTOCOL

and EDKII_VAR_CHECK_PROTOCOL. Do you want to deprecate both? Or only
deprecate EDKII_VARIABLE_LOCK_PROTOCOL?

I think we would recommend deprecating both. Is there much consumption of
the VarCheck protocol? A platform could always opt to include both (or all 3!),
but they wouldn't be able to immediately tell which engine rejected the
SetVariable.

[Jiewen] Right. That is my understanding- deprecate both.
I saw you only mention to deprecate VarLock, but not VarCheck. That is why I
get confused.

I don’t recommend we have 3 engines. Too burden to maintain the code.

One possible option is to implement VarLockProtocol and VarCheckProtocol on
top of VarPolicyProtocol. (like a thunk)
As such, there is no impact on the existing private platform code, with the
benefit that one central engine controls everything.
Later, we can check platform one by one. After the last one is migrated, we can
remove VarLock and VarCheck thunk.

2. The Function - DumpVariablePolicy() - makes me confused in the

beginning.

In my thought, "Dump" means to show some debug message. But here, you
want to return the policy. Can we change the name to GetVariablePolicy()?

I see your point about possible confusion. I think we would try to clarify this in
the function documentation. Due to the code-first approach we've taken on

this,

we already have partners who have implemented the policy with
DumpVariablePolicy as the name and it doesn't seem like a huge problem.

3. The function - DisableVariablePolicy(). Does it disable current policy

engine?

Does it disable any future policy engine? Does it block RegisterVariablePolicy()
call?

Disable turns off the enforcement. You should still be able to register new
policies for auditing purposes (they will still be returned by

DumpVariablePolicy),

but no SetVariables will be rejected.

4. The function - LockVariablePolicy() - Can it lock the DisableVariablePolicy()

call?

Correct. Once the interface is locked, it cannot be disabled. Locking should be
performed at EndOfDxe or ReadyToBoot or wherever the platform TCB is.

5. The use case "In MFG Mode Variable Policy Engine is disabled, thus these

VPD variables can be created. These variables are locked with lock policy type
LockNow, so that these variables can't be tampered with in Customer Mode."

Correct. The MfgMode is just a suggestion and is entirely up to the platform.

Our

MfgMode (which has not been open-sourced yet, but we're working on it) will
call DisableVariablePolicy because our threat model indicates that

compromising

MfgMode is a total compromise (there are many other attack vectors once
MfgMode is compromised). As such, we protect it extensively. But there is
nothing in the core or extra code that would automatically disable the policy
engine for any platform that didn't want that. It is up to the platform, however,
to make sure they lock the policy engine (similar to locking SMM).

[Jiewen] OK, if my understanding is correct, the DisablePolicy() should only be
called in some special environment, but NOT a normal feature involved in the
normal boot.

Then I am feeling we should separate the DisablePolicy from this protocol,
because this interface is very dangerous. I don’t want any driver call it by
mistake.

Can we split the VARIABLE_POLICY to VARIABLE_POLICY (normal boot usage) +
VARIABLE_POLICY_CONTROL (very special usage)

Like below:

typedef struct {
UINT64 Revision;
REGISTER_VARIABLE_POLICY RegisterVariablePolicy;
DUMP_VARIABLE_POLICY DumpVariablePolicy;
LOCK_VARIABLE_POLICY LockVariablePolicy;
} _VARIABLE_POLICY_PROTOCOL;

typedef struct {
UINT64 Revision;
DISABLE_VARIABLE_POLICY DisableVariablePolicy;
IS_VARIABLE_POLICY_ENABLED IsVariablePolicyEnabled;
} _VARIABLE_POLICY_CONTROL_PROTOCOL;

VARIABLE_POLICY_PROTOCOL is always installed.

In normal boot, the VARIABLE_POLICY_CONTROL_PROTOCOL is NOT installed.
As such, the policy is always enforced.
The VARIABLE_POLICY_CONTROL_PROTOCOL is only installed in some special
mode, controlled by PCD - maybe.
A platform may choose to:
1) Use static PCD to always disable VARIABLE_POLICY_CONTROL_PROTOCOL
installation.
2) Use dynamic PCD to control VARIABLE_POLICY_CONTROL_PROTOCOL
installation only in special mode.


Thank you
Yao Jiewen

-----Original Message-----
From: brbarkel via [] <brbarkel=microsoft.com@[]>
Sent: Friday, February 7, 2020 5:49 AM
To: Yao; Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries,
and Implementation for VariableLock Alternative

Sorry, Jiewen. I missed this email when it came in...

1. We have 2 variable related protocol - EDKII_VARIABLE_LOCK_PROTOCOL

and EDKII_VAR_CHECK_PROTOCOL. Do you want to deprecate both? Or only
deprecate EDKII_VARIABLE_LOCK_PROTOCOL?

I think we would recommend deprecating both. Is there much consumption of
the VarCheck protocol? A platform could always opt to include both (or all 3!),
but they wouldn't be able to immediately tell which engine rejected the
SetVariable.

2. The Function - DumpVariablePolicy() - makes me confused in the beginning.

In my thought, "Dump" means to show some debug message. But here, you
want to return the policy. Can we change the name to GetVariablePolicy()?

I see your point about possible confusion. I think we would try to clarify this in
the function documentation. Due to the code-first approach we've taken on this,
we already have partners who have implemented the policy with
DumpVariablePolicy as the name and it doesn't seem like a huge problem.

3. The function - DisableVariablePolicy(). Does it disable current policy engine?

Does it disable any future policy engine? Does it block RegisterVariablePolicy()
call?

Disable turns off the enforcement. You should still be able to register new
policies for auditing purposes (they will still be returned by DumpVariablePolicy),
but no SetVariables will be rejected.

4. The function - LockVariablePolicy() - Can it lock the DisableVariablePolicy()

call?

Correct. Once the interface is locked, it cannot be disabled. Locking should be
performed at EndOfDxe or ReadyToBoot or wherever the platform TCB is.

5. The use case "In MFG Mode Variable Policy Engine is disabled, thus these

VPD variables can be created. These variables are locked with lock policy type
LockNow, so that these variables can't be tampered with in Customer Mode."

Correct. The MfgMode is just a suggestion and is entirely up to the platform. Our
MfgMode (which has not been open-sourced yet, but we're working on it) will
call DisableVariablePolicy because our threat model indicates that compromising
MfgMode is a total compromise (there are many other attack vectors once
MfgMode is compromised). As such, we protect it extensively. But there is
nothing in the core or extra code that would automatically disable the policy
engine for any platform that didn't want that. It is up to the platform, however,
to make sure they lock the policy engine (similar to locking SMM).

On Feb 4, 2020, at 2:07 AM, Bret Barkelew via Groups.Io <bret.barkelew@...> wrote:


Expanding the audience beyond the RFC list….
If no one has additional input, I’ll try to start formatting these as patches later this week. Thanks!

- Bret

From: Bret Barkelew
Sent: Tuesday, January 28, 2020 5:36 PM
To: rfc@edk2.groups.io
Subject: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

All,

VariablePolicy is our proposal for an expanded “VarLock-like” interface to constrain and govern platform variables.
I brought this up back in May to get initial comments on the interface and implications of the interface and the approach. We implemented it in Mu over the summer and it is not our defacto variable solution. It plugs in easily to the existing variable infrastructure, but does want to control some of the things that are currently managed by VarLock.

There are also some tweaks that would be needed if this were desired to be 100% optional code, but that’s no different than the current VarLock implementation which has implementation code directly tied to some of the common variable code.

I’ve structured this RFC in two pieces:
The Core piece represents the minimum changes needed to implement Variable Policy and integrate it into Variable Services. It contains core driver code, central libraries and headers, and DXE driver for the protocol interface.
The Extras piece contains recommended code for a full-feature implementation including a replacement for the VarLock protocol that enables existing code to continue functioning as-is. It also contains unit and integration tests. And as a bonus, it has a Rust implementation of the core business logic for Variable Policy.

The code can be found in the following two branches:
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_core
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra

A convenient way to see all the changes in one place is to look at a comparison:
https://github.com/corthon/edk2/compare/master...corthon:personal/brbarkel/var_policy_rfc_core
https://github.com/corthon/edk2/compare/personal/brbarkel/var_policy_rfc_core...corthon:personal/brbarkel/var_policy_rfc_extra

There’s additional documentation in the PPT and DOC files in the core branch:
https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Proposal%20Presentation.pptx https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Whitepaper.docx
(You’d need to download those to view.)

My ultimate intention for this is to submit it as a series of patches for acceptance into EDK2 as a replacement for VarLock. For now, I’m just looking for initial feedback on any broad changes that might be needed to get this into shape for more detailed code review on the devel list.

Thanks!

- Bret

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On
Behalf Of Laszlo Ersek
Sent: Monday, January 20, 2020 10:42 AM
To: rfc@edk2.groups.io; leif@...;
devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first
process for UEFI-forum specifications

On 01/20/20 17:58, Leif Lindholm wrote:

This is a proposal for a process by which new

features can be added to UEFI

forum specifications after first having been designed

and prototyped in the

open.

This process lets changes and the development of new

features happen in the

open, without violating the UEFI forum bylaws which

prevent publication of

code for in-draft features/changes.

The process does not in fact change the UEFI bylaws -

the change is that the

development (of both specification and code) happens

in the open. The resulting

specification update is then submitted to the

appropriate working goup as an

Engineering Change Request (ECR), and voted on. For

the UEFI Forum, this is a

change in workflow, not a change in process.

ECRs are tracked in a UEFI Forum Mantis instance,

access restricted to UEFI

Forum Members. TianoCore will enable this new process

by providing areas on

https://bugzilla.tianocore.org/ to track both

specification updates and

reference implementations and new repositories under
https://github.com/tianocore/ dedicated to hold "code

first".

## Bugzilla

bugzilla.tianocore.oorg will have a product category

each for

s/oorg/org/

* ACPI Specification
* PI Specification
* UEFI Specification

Each product category will have a separate components

for

* Specification
* Reference implementation


## Github
New repositories will be added for holding the text

changes and the source code.

Specification text changes will be held within the

affected source repository.

This seems to require that the specifications be
available as something
"patchable" (e.g. GitBook source code), and offered in
some public git repo.

(This one may break down where we have a

specification change affecting multiple

specifications, but at that point we can track it

with multiple BZ entries)

Initially, edk2-spec-update will be created to hold

the reference

implementations. Additional repositories for

implementing reference features in

additional open source projects can be added in the

future, as required.

## Intended workflow
The entity initiating a specifiation update raises a

Bugzilla in the appropriate

area in bugzilla.tianocore.org. This entry contains

the outline of the change,

and the full initial draft text is attached.

How does this play together with *patches* for specs
(see above)?
Attaching patches to BZs is not good practice. Should
we attach complete
renderings of the patched (huge) specs?

If multiple specification updates are interdependent,

especially if between

different specifications, then multiple bugzilla

entries should be created.

These bugzilla entries *must* be linked together with

dependencies.

After the BZs have been created, new branches should

be created in the relevant

repositories for each bugzilla - the branch names

should be BZ####, where ####

describes the bugzilla ID assigned, optionally

followed by a '-' and something

more descriptive. If multipls bugzilla entries must

coexist on a single branch,

s/multipls/multiple/

one of them is designated the 'top-level', with

dependencies properly tracked.

That BZ will be the one naming the branch.


## Source code
In order to ensure draft code does not accidentally

leak into production use,

and to signify when the changeover from draft to

final happens, *all* new or

modified[1] identifiers need to be prefixed with the

relevant BZ####.

[1] Modified in a non-backwards-compatible way. If,

for example, a statically

sized array is grown - this does not need to be

prefixed. (Question: but a

tag in a comment?)

The tagging must follow the coding style used by each

affected codebase.

Examples:

| Released in spec | Draft version in tree | Comment

|

| --- | --- | ---

|

| FunctionName | Bz1234FunctionName | EDK2

|

| function_name | bz1234_function_name | Linux

|

| HEADER_MACRO | BZ1234_HEADER_MACRO | EDK2,

Linux |

Alternative 1)
Variable prefixes indicating global scope ('g' or

'm') go before the BZ prefix.

Alternative 2)
Variable prefixes indicating global scope ('g' or

'm') go after the BZ prefix.

Sounds good to me in general.

I think we'll have to work out the nuances of the
coding style in
practice, while actually developing such additions. I
can't name
anything specific that's missing from the proposal, but
I'm quite sure
we'll find corner cases in practice.

Thanks
Laszlo