Date   

Re: Q: Side effects of incrementing gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size?

Aaron Young
 

Thanks Laszlo! Very helpful.

-Aaron

On 02/11/2020 01:15 AM, Laszlo Ersek wrote:
-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536


Re: Q: Side effects of incrementing gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size?

Laszlo Ersek
 

Hi Aaron,

On 02/10/20 21:15, aaron.young@... wrote:

 Hello, After adding some GPU cards to our system (each containing a
16GB BAR), we ran out of MEM64 BAR space as indicated by the following
OVMF DEBUG output:

--------
[...]
-----------

 Incrementing gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size from the
default value (0x800000000) to 0x2000000000 fixed the issue and should
allow enough space to add several (7 or so) GPUs to the system.

 However, we are concerned about side-effects of such a change.

 So, my question is: Could incrementing PcdPciMmio64Size cause any
negative side effects?

 Thanks in advance for any help/comments/suggestions...
Please refer to the following thread:

* [edk2-discuss]
[OVMF] resource assignment fails for passthrough PCI GPU

https://edk2.groups.io/g/discuss/message/59

The gist is that

(a) you can increase the 64-bit MMIO aperture without rebuilding OVMF,
like this (on the QEMU command line):

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

(This sets a 64GiB aperture)

(b) Implementing such a change in the DSC file(s) statically is not
recommended, as it could prevent guests from booting on hosts that
support EPT (= nested paging on Intel CPUs) but only support 36 physical
address bits.

(c) Sizing the aperture in OVMF dynamically to whatever the host CPU's
phys address width supports would also not be ideal, due to guest RAM
consumption and possible VM migration problems. QEMU doesn't even report
the host CPU's phys address width accurately to the guest, at the
moment, AIUI.

Thanks
Laszlo


Q: Side effects of incrementing gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size?

Aaron Young
 

Hello, After adding some GPU cards to our system (each containing a 16GB BAR), we ran out of MEM64 BAR space as indicated by the following OVMF DEBUG output:

--------
PciHostBridge: SubmitResources for PciRoot(0x0)
I/O: Granularity/SpecificFlag = 0 / 01
Length/Alignment = 0x1000 / 0xFFF
Mem: Granularity/SpecificFlag = 32 / 00
Length/Alignment = 0x3100000 / 0xFFFFFF
Mem: Granularity/SpecificFlag = 64 / 00
Length/Alignment = 0x804000000 / 0x3FFFFFFFF
PciBus: HostBridge->SubmitResources() - Success
PciHostBridge: NotifyPhase (AllocateResources)
RootBridge: PciRoot(0x0)
* Mem64: Base/Length/Alignment =**
**FFFFFFFFFFFFFFFF/804000000/3FFFFFFFF - Out Of**
**Resource!*
Mem: Base/Length/Alignment = C0000000/3100000/FFFFFF - Success
I/O: Base/Length/Alignment = C000/1000/FFF - Success
Call PciHostBridgeResourceConflict().
PciHostBridge: Resource conflict happens!
RootBridge[0]:
I/O: Length/Alignment = 0x1000 / 0xFFF
Mem: Length/Alignment = 0x3100000 / 0xFFFFFF
Granularity/SpecificFlag = 32 / 00
Mem: Length/Alignment = 0x0 / 0x0
Granularity/SpecificFlag = 32 / 06 (Prefetchable)
Mem: Length/Alignment = 0x804000000 / 0x3FFFFFFFF
Granularity/SpecificFlag = 64 / 00
Mem: Length/Alignment = 0x0 / 0x0
Granularity/SpecificFlag = 64 / 06 (Prefetchable)
Bus: Length/Alignment = 0x1 / 0x0
PciBus: HostBridge->NotifyPhase(AllocateResources) -
Out of Resources

-----------

Incrementing gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size from the default value (0x800000000) to 0x2000000000 fixed the issue and should allow enough space to add several (7 or so) GPUs to the system.

However, we are concerned about side-effects of such a change.

So, my question is: Could incrementing PcdPciMmio64Size cause any negative side effects?

Thanks in advance for any help/comments/suggestions...

-Aaron Young


Enhancement to CryptoPkg/BaseHashApiLib

Sukerkar, Amol N
 

Hi Mike, Jian and Jiewen,

Based on our discussion, I have compiled the enhancements/changes to be made to BaseHashApiLib instance in CryptoPkg in the Bugzilla, https://bugzilla.tianocore.org/show_bug.cgi?id=2511.

Please go over the changes and provide comments/feedback. Once I have confirmation that I have captured all the identified changes, I will begin implementation.

Thanks,
Amol


Re: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Wang, Sunny (HPS SW)
 

Hi Bret,

Your proposal looks good to me, and most of my questions/concerns were already answered/solved by the GOOD discussion between you and Jiewen.

For now, I just have one remaining question. Can we also make DumpVariablePolicy as a platform choice?
DumpVariablePolicy would also expose the information about how to pass the check to the attacker. If my understanding is correct, the attacker can even use the information to unlock the variable locked by LOCK_ON_VAR_STATE type policy. Therefore, If the DumpVariablePolicy is just to allow platform tests to audit the entire policy list, can we add a PCD or a build flag check to disable it in release build? Of course, I also agree with Jiewen's point about making DisableVarPolicy as a platform choice.

By the way, I had the other question that I already got the answer from the code and your document. Since it hasn't been discussed, I think it would be good to share the answer with others. The question is how VariablePolicy deals with the multiple RegisterVariablePolicy calls with the same variable name and GUID. The answer is that the first registered policy will be the winner. The later calls (from attackers) with the same name and GUID will just get EFI_ALREADY_STARTED and fail to register the compromised policy. Therefore, RegisterVariablePolicy looks good to me as well.


Regards,
Sunny Wang

-----Original Message-----
From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On Behalf Of Bret Barkelew via Groups.Io
Sent: Wednesday, January 29, 2020 9:36 AM
To: rfc@edk2.groups.io
Subject: [edk2-rfc] [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


Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Yao, Jiewen
 

Add devel@edk2.groups.io.

-----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


Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Yao, Jiewen
 

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


Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

brbarkel@...
 

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).


Re: [EXTERNAL] Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Bret Barkelew <bret.barkelew@...>
 

Kevin,

Agreed and we were sensitive to that in our codebase as well. Surface and other consumers had drivers expecting VarLock and we didn’t want to have to rewrite them all (at least not immediately).

If you take a look at the MuVarPolicyFoundationDxe driver in the extras branch…
It contains a number of features that we considered fundamental for building complex constructions, but we’re (strictly speaking) a core part of the Variable Policy infrastructure.
One of those features is installing a VarLock interface that leverages Variable Policy.

https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra/MsCorePkg/MuVarPolicyFoundationDxe

Is that something you think you could work with (renamed, of course 😉).

- Bret

From: Kevin D Davis<mailto:kevin.davis@...>
Sent: Tuesday, February 4, 2020 3:31 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@...>
Cc: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Subject: [EXTERNAL] Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Bret,

We like the new functionality.

Our concern is our customers / we will need to modify all of the code that are consumers of EDKII_VARIABLE_LOCK_PROTOCOL to use the new protocols. If you could review that issue we would be 100% happy.

Of course, that’s not always appropriate and we understand.

Kevin D Davis
Insyde Software


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<mailto:Bret.Barkelew@...>
Sent: Tuesday, January 28, 2020 5:36 PM
To: rfc@edk2.groups.io<mailto: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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorthon%2Fedk2%2Ftree%2Fpersonal%2Fbrbarkel%2Fvar_policy_rfc_core&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdaa80648c1244dbfd32108d7a9ca13f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164558782121558&sdata=0tKS5gx17R0dsBpEXjCEK6AIh1B5R6yVyQi55BTReHo%3D&reserved=0>
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorthon%2Fedk2%2Ftree%2Fpersonal%2Fbrbarkel%2Fvar_policy_rfc_extra&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdaa80648c1244dbfd32108d7a9ca13f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164558782121558&sdata=1hlFTGKyzxbaA1BM48zRZEMt%2FyJU3%2Ft96YY0REUY5gs%3D&reserved=0>

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorthon%2Fedk2%2Fcompare%2Fmaster...corthon%3Apersonal%2Fbrbarkel%2Fvar_policy_rfc_core&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdaa80648c1244dbfd32108d7a9ca13f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164558782131553&sdata=0hIT%2FOYBtfpXg6XH97IMcNusYJxa6k8E5qAhCWZ6djA%3D&reserved=0>
https://github.com/corthon/edk2/compare/personal/brbarkel/var_policy_rfc_core...corthon:personal/brbarkel/var_policy_rfc_extra<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorthon%2Fedk2%2Fcompare%2Fpersonal%2Fbrbarkel%2Fvar_policy_rfc_core...corthon%3Apersonal%2Fbrbarkel%2Fvar_policy_rfc_extra&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdaa80648c1244dbfd32108d7a9ca13f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164558782141545&sdata=wqv2WuSxZBuIB2LaMCh5P4YblQQEKGRXEdg%2FjlhCBlY%3D&reserved=0>

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorthon%2Fedk2%2Fblob%2Fpersonal%2Fbrbarkel%2Fvar_policy_rfc_core%2FRFC%2520VariablePolicy%2520Proposal%2520Presentation.pptx&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdaa80648c1244dbfd32108d7a9ca13f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164558782141545&sdata=37mYO3wTQS%2BUsdQW88mi%2B5aglkqDogR5msPZwIGZdLg%3D&reserved=0> https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Whitepaper.docx<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorthon%2Fedk2%2Fblob%2Fpersonal%2Fbrbarkel%2Fvar_policy_rfc_core%2FRFC%2520VariablePolicy%2520Whitepaper.docx&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdaa80648c1244dbfd32108d7a9ca13f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164558782151542&sdata=SNug18tr6iC1VMg72mEiIPykL5LQr2aI8yGq%2B7K9tTE%3D&reserved=0>
(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


Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Yao, Jiewen
 

HI Bret
Thanks for the work. The design doc is very good.

Some feedback/questions below:


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?
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()?
3. The function - DisableVariablePolicy(). Does it disable current policy engine? Does it disable any future policy engine? Does it block RegisterVariablePolicy() call?
4. The function - LockVariablePolicy() - Can it lock the DisableVariablePolicy() call?
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."

This seems a perfect potential attack point. If the attacker wants to modify a read-only variable. He or she may trigger the MFG mode, then no variable is locked. Then the attacker can update the RO variable then reset the system to normal mode. Is that threat considered?

Thank you
Yao Jiewen


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret Barkelew via Groups.Io
Sent: Tuesday, February 4, 2020 4:08 PM
To: devel@edk2.groups.io; rfc@edk2.groups.io
Subject: Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

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<mailto:Bret.Barkelew@...>
Sent: Tuesday, January 28, 2020 5:36 PM
To: rfc@edk2.groups.io<mailto: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


Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Kevin@Insyde <kevin.davis@...>
 

Bret,

We like the new functionality.

Our concern is our customers / we will need to modify all of the code that are consumers of EDKII_VARIABLE_LOCK_PROTOCOL to use the new protocols. If you could review that issue we would be 100% happy.

Of course, that’s not always appropriate and we understand.

Kevin D Davis
Insyde Software

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



Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

Michael D Kinney
 

Leif,

A few comments included below.

Thanks,

Mike

-----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.
I recommend we use MarkDown. GitHub flavored MarkDown
may be a good choice so an ECR can be viewed from the
web view of GitHub. This also support text based patch
reviews of the ECR content.

(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.
I recommend using branches in the existing edk2-staging
repository for changes that only impact EDK II firmware
components/tools.



## 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?)
It would be good to clarify when the BZ### prefix is required
and not required and to describe a few more use cases. Here
are a few. I am sure this list will be expanded when real
examples are implemented.

1) New/modified interfaces require prefix.
a) New structures. Only top level struct require a prefix. Fields and sub structures do not.
2) New public header file names need prefix (e.g. Bz0001MyNewProtocol.h)
3) New GUID global variables need a prefix (e.g. gBz0001MyNewProtocolGuid)
4) Adding a field, enum, or #define to existing interface require a prefix
5) Internal interfaces and implementation elements do not need a prefix.

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.
I prefer Alternative 1 to follow EDK II C Coding Standard.

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



Re: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Bret Barkelew <bret.barkelew@...>
 

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<mailto:Bret.Barkelew@...>
Sent: Tuesday, January 28, 2020 5:36 PM
To: rfc@edk2.groups.io<mailto: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


[RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Bret Barkelew <bret.barkelew@...>
 

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


Re: [RFC] code-first process for UEFI-forum specifications

Laszlo Ersek
 

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


[RFC] code-first process for UEFI-forum specifications

Leif Lindholm
 

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
* 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 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.

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,
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.


Re: [edk2-devel] [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Laszlo Ersek
 

On 01/10/20 10:39, Ni, Ray wrote:
So, the impact is every platform DSC needs to be updated to reference the correct path of the UefiDevicePath lib after your merge.
I agree -- I expect that most if not all platform DSC files will need
updates. That's because the most frugal approach for a platform is to
use the self-contained UefiDevicePathLib instance only in very early DXE
phase modules (DXE core, and DevicePathDxe itself), and use the thin
UefiDevicePathLibDevicePathProtocol instance in all other DXE modules.

See e.g. Ray's OvmfPkg commit 5c3481b0b611 ("OvmfPkg: Use the new
DevicePathLib for all platforms", 2013-08-19).

See also ArmVirtPkg commit f9dff9028950 ("ArmVirtPkg: use protocol-based
DevicePathLib instance for most DXE modules", 2018-04-30), which
provides more explanation.

Thanks,
Laszlo

Let's wait for at least 2 weeks for feedbacks.

Thanks,
Ray

From: Gao, Zhichao <zhichao.gao@...>
Sent: Friday, January 10, 2020 3:47 PM
To: Ni, Ray <ray.ni@...>; devel@edk2.groups.io; 'rfc@edk2.groups.io' <rfc@edk2.groups.io>
Cc: Gao, Liming <liming.gao@...>; Kinney, Michael D <michael.d.kinney@...>; vit9696@...
Subject: RE: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Ray,
I prefer to merge these two lib instance into one folder and remove the duplicated code.
I can change all the required change in open source repo. But not sure how many close source platforms would be affected.
This action should make all the close platform owners aware of it and changing their platform code to consume the new lib instance.

#2: OK. That makes sense to consume the new device path node if appear.

Thanks,
Zhichao

From: Ni, Ray
Sent: Friday, January 10, 2020 3:36 PM
To: Gao, Zhichao <zhichao.gao@...<mailto:zhichao.gao@...>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
Cc: Gao, Liming <liming.gao@...<mailto:liming.gao@...>>; Kinney, Michael D <michael.d.kinney@...<mailto:michael.d.kinney@...>>; vit9696@...<mailto:vit9696@...>
Subject: RE: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Zhichao,
What's your recommendation regarding this?

Back to your 2nd question, drivers/applications consuming UefiDevicePathLibOptionalDevicePathProtocol
can firstly use the firmware built-in from-text and to-text conversion, then use its own conversion logic if
the firmware doesn't contain built-in from-text or to-text conversion.
Considering a case that an application is released in year 2015, it can recognize the new device path node
introduced after 2015 in a new system.

Thanks,
Ray

From: Gao, Zhichao <zhichao.gao@...<mailto:zhichao.gao@...>>
Sent: Friday, January 10, 2020 11:04 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
Cc: Gao, Liming <liming.gao@...<mailto:liming.gao@...>>; Kinney, Michael D <michael.d.kinney@...<mailto:michael.d.kinney@...>>; vit9696@...<mailto:vit9696@...>; Ni, Ray <ray.ni@...<mailto:ray.ni@...>>
Subject: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

HI all,

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
In the MdePkg, there are two folder for the DevicePathLib:

1. MdePkg\Library\UefiDevicePathLib
2. MdePkg\Library\UefiDevicePathLibDevicePathProtocol

UefiDevicePathLibDevicePathProtocol is created to use the protocol to reduce the driver size which consume the DevicePathLib.
But it has duplicate code with #1. So I want to merge these two folder into one. But many platform implementations consume #2.
If we merge #2 into #1, there might be a lot of platform changes for both close source and open source.
Can anyone give me some suggestions about this? Do we have a progress to retire some implementation in the edk2 repor?

There is another question about MdePkg\Library\UefiDevicePathLib\UefiDevicePathLibOptionalDevicePathProtocol.inf.
This one implements the interface to choose the protocol first, then change to local implementation if no protocol is available.
It requires a fix and it is already sent to the community. But what's the purpose?
Local implementation, i.e. MdePkg\Library\UefiDevicePathLib\ UefiDevicePathLib.inf, can make sure its usable. And it can't reduce the driver size. If it is useless, can we directly remove it?

Thanks,
Zhichao





Re: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Ni, Ray
 

So, the impact is every platform DSC needs to be updated to reference the correct path of the UefiDevicePath lib after your merge.

Let's wait for at least 2 weeks for feedbacks.

Thanks,
Ray

From: Gao, Zhichao <zhichao.gao@...>
Sent: Friday, January 10, 2020 3:47 PM
To: Ni, Ray <ray.ni@...>; devel@edk2.groups.io; 'rfc@edk2.groups.io' <rfc@edk2.groups.io>
Cc: Gao, Liming <liming.gao@...>; Kinney, Michael D <michael.d.kinney@...>; vit9696@...
Subject: RE: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Ray,
I prefer to merge these two lib instance into one folder and remove the duplicated code.
I can change all the required change in open source repo. But not sure how many close source platforms would be affected.
This action should make all the close platform owners aware of it and changing their platform code to consume the new lib instance.

#2: OK. That makes sense to consume the new device path node if appear.

Thanks,
Zhichao

From: Ni, Ray
Sent: Friday, January 10, 2020 3:36 PM
To: Gao, Zhichao <zhichao.gao@...<mailto:zhichao.gao@...>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
Cc: Gao, Liming <liming.gao@...<mailto:liming.gao@...>>; Kinney, Michael D <michael.d.kinney@...<mailto:michael.d.kinney@...>>; vit9696@...<mailto:vit9696@...>
Subject: RE: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Zhichao,
What's your recommendation regarding this?

Back to your 2nd question, drivers/applications consuming UefiDevicePathLibOptionalDevicePathProtocol
can firstly use the firmware built-in from-text and to-text conversion, then use its own conversion logic if
the firmware doesn't contain built-in from-text or to-text conversion.
Considering a case that an application is released in year 2015, it can recognize the new device path node
introduced after 2015 in a new system.

Thanks,
Ray

From: Gao, Zhichao <zhichao.gao@...<mailto:zhichao.gao@...>>
Sent: Friday, January 10, 2020 11:04 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
Cc: Gao, Liming <liming.gao@...<mailto:liming.gao@...>>; Kinney, Michael D <michael.d.kinney@...<mailto:michael.d.kinney@...>>; vit9696@...<mailto:vit9696@...>; Ni, Ray <ray.ni@...<mailto:ray.ni@...>>
Subject: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

HI all,

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
In the MdePkg, there are two folder for the DevicePathLib:

1. MdePkg\Library\UefiDevicePathLib
2. MdePkg\Library\UefiDevicePathLibDevicePathProtocol

UefiDevicePathLibDevicePathProtocol is created to use the protocol to reduce the driver size which consume the DevicePathLib.
But it has duplicate code with #1. So I want to merge these two folder into one. But many platform implementations consume #2.
If we merge #2 into #1, there might be a lot of platform changes for both close source and open source.
Can anyone give me some suggestions about this? Do we have a progress to retire some implementation in the edk2 repor?

There is another question about MdePkg\Library\UefiDevicePathLib\UefiDevicePathLibOptionalDevicePathProtocol.inf.
This one implements the interface to choose the protocol first, then change to local implementation if no protocol is available.
It requires a fix and it is already sent to the community. But what's the purpose?
Local implementation, i.e. MdePkg\Library\UefiDevicePathLib\ UefiDevicePathLib.inf, can make sure its usable. And it can't reduce the driver size. If it is useless, can we directly remove it?

Thanks,
Zhichao


Re: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Gao, Zhichao
 

Ray,
I prefer to merge these two lib instance into one folder and remove the duplicated code.
I can change all the required change in open source repo. But not sure how many close source platforms would be affected.
This action should make all the close platform owners aware of it and changing their platform code to consume the new lib instance.

#2: OK. That makes sense to consume the new device path node if appear.

Thanks,
Zhichao

From: Ni, Ray
Sent: Friday, January 10, 2020 3:36 PM
To: Gao, Zhichao <zhichao.gao@...>; devel@edk2.groups.io; 'rfc@edk2.groups.io' <rfc@edk2.groups.io>
Cc: Gao, Liming <liming.gao@...>; Kinney, Michael D <michael.d.kinney@...>; vit9696@...
Subject: RE: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Zhichao,
What's your recommendation regarding this?

Back to your 2nd question, drivers/applications consuming UefiDevicePathLibOptionalDevicePathProtocol
can firstly use the firmware built-in from-text and to-text conversion, then use its own conversion logic if
the firmware doesn't contain built-in from-text or to-text conversion.
Considering a case that an application is released in year 2015, it can recognize the new device path node
introduced after 2015 in a new system.

Thanks,
Ray

From: Gao, Zhichao <zhichao.gao@...<mailto:zhichao.gao@...>>
Sent: Friday, January 10, 2020 11:04 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
Cc: Gao, Liming <liming.gao@...<mailto:liming.gao@...>>; Kinney, Michael D <michael.d.kinney@...<mailto:michael.d.kinney@...>>; vit9696@...<mailto:vit9696@...>; Ni, Ray <ray.ni@...<mailto:ray.ni@...>>
Subject: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

HI all,

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
In the MdePkg, there are two folder for the DevicePathLib:

1. MdePkg\Library\UefiDevicePathLib
2. MdePkg\Library\UefiDevicePathLibDevicePathProtocol

UefiDevicePathLibDevicePathProtocol is created to use the protocol to reduce the driver size which consume the DevicePathLib.
But it has duplicate code with #1. So I want to merge these two folder into one. But many platform implementations consume #2.
If we merge #2 into #1, there might be a lot of platform changes for both close source and open source.
Can anyone give me some suggestions about this? Do we have a progress to retire some implementation in the edk2 repor?

There is another question about MdePkg\Library\UefiDevicePathLib\UefiDevicePathLibOptionalDevicePathProtocol.inf.
This one implements the interface to choose the protocol first, then change to local implementation if no protocol is available.
It requires a fix and it is already sent to the community. But what's the purpose?
Local implementation, i.e. MdePkg\Library\UefiDevicePathLib\ UefiDevicePathLib.inf, can make sure its usable. And it can't reduce the driver size. If it is useless, can we directly remove it?

Thanks,
Zhichao


Re: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

Ni, Ray
 

Zhichao,
What's your recommendation regarding this?

Back to your 2nd question, drivers/applications consuming UefiDevicePathLibOptionalDevicePathProtocol
can firstly use the firmware built-in from-text and to-text conversion, then use its own conversion logic if
the firmware doesn't contain built-in from-text or to-text conversion.
Considering a case that an application is released in year 2015, it can recognize the new device path node
introduced after 2015 in a new system.

Thanks,
Ray

From: Gao, Zhichao <zhichao.gao@...>
Sent: Friday, January 10, 2020 11:04 AM
To: devel@edk2.groups.io; 'rfc@edk2.groups.io' <rfc@edk2.groups.io>
Cc: Gao, Liming <liming.gao@...>; Kinney, Michael D <michael.d.kinney@...>; vit9696@...; Ni, Ray <ray.ni@...>
Subject: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

HI all,

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
In the MdePkg, there are two folder for the DevicePathLib:

1. MdePkg\Library\UefiDevicePathLib
2. MdePkg\Library\UefiDevicePathLibDevicePathProtocol

UefiDevicePathLibDevicePathProtocol is created to use the protocol to reduce the driver size which consume the DevicePathLib.
But it has duplicate code with #1. So I want to merge these two folder into one. But many platform implementations consume #2.
If we merge #2 into #1, there might be a lot of platform changes for both close source and open source.
Can anyone give me some suggestions about this? Do we have a progress to retire some implementation in the edk2 repor?

There is another question about MdePkg\Library\UefiDevicePathLib\UefiDevicePathLibOptionalDevicePathProtocol.inf.
This one implements the interface to choose the protocol first, then change to local implementation if no protocol is available.
It requires a fix and it is already sent to the community. But what's the purpose?
Local implementation, i.e. MdePkg\Library\UefiDevicePathLib\ UefiDevicePathLib.inf, can make sure its usable. And it can't reduce the driver size. If it is useless, can we directly remove it?

Thanks,
Zhichao

541 - 560 of 786