Date   

Re: [edk2-devel] [RFC] BZ 2067 BaseTools/Scripts: Add GetUtcDateTime.py for edk2-stable201908 stable tag.

Chiu, Chasel <chasel.chiu@...>
 

Hi Leif,

Thanks for the valuable feedbacks and suggestions.
I will re-write script and re-send code review.

Regards,
Chasel

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
Lindholm
Sent: Wednesday, August 14, 2019 2:30 AM
To: Gao, Liming <liming.gao@...>
Cc: Chiu, Chasel <chasel.chiu@...>; rfc@edk2.groups.io; Feng, Bob C
<bob.c.feng@...>; devel@edk2.groups.io; Cetola, Stephano
<stephano.cetola@...>; Laszlo Ersek (lersek@...)
<lersek@...>; afish@...; Kinney, Michael D
<michael.d.kinney@...>
Subject: Re: [edk2-devel] [RFC] BZ 2067 BaseTools/Scripts: Add
GetUtcDateTime.py for edk2-stable201908 stable tag.

I am not fundamentally opposed to merging a simple script that does not affect
other code in the tree.

*But* the fact that we have multiple occurrences of this this time around *is*
a bit of a concern for me. Yes, they won't affect the workings of anything else
as part of the release. But they will not have had any chance to be actually used
by others.

For this particular script, I am also not very keen on the implementation. It
manually parses the command line and prints usage instead of using argparse.
And it contains the sys.exit(Main()) antipattern, which does not play well with
Python3 asynchronous i/o (and hence is a bad habit to get into).

Since this script is truly trivial, I am OK for it to be included *if* it is rewritten
using argparse and not calling sys.exit.

Best Regards,

Leif

On Tue, Aug 13, 2019 at 01:42:23PM +0000, Gao, Liming wrote:
This is a small helper script. I am OK to add it for edk2-stable201908 stable
tag.

Thanks
Liming
From: Chiu, Chasel
Sent: Monday, August 12, 2019 3:45 PM
To: rfc@edk2.groups.io
Cc: Gao, Liming <liming.gao@...>; Feng, Bob C
<bob.c.feng@...>; devel@edk2.groups.io
Subject: [RFC] BZ 2067 BaseTools/Scripts: Add GetUtcDateTime.py for
edk2-stable201908 stable tag.


Hello,

I would like to add below simple script to 201908 stable tag, review was sent
on August 8th:

A script that can return UTC date and time in ascii format which is convenient
for patching build time information in any binary.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067
Patch: https://edk2.groups.io/g/devel/topic/32797962#45177

Thanks!
Chasel


Re: [RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in Edk2/BaseTools for 201908 stable tag

Leif Lindholm
 

Hi Liming,

This is the other one. As I said, the fact that we are slipping
multiple scripts in *just* before freeze is a concern for me.

I have no objection to the code here though.

I would however request that Sean is set as author on patch 1/2 as he
was the original author of the script. (This was easy for me to find
out because the commit message was exemplary.)

Best Regards,

Leif

On Tue, Aug 13, 2019 at 01:49:24PM +0000, Gao, Liming wrote:
I see this patch was sent a week ago. This is a standalone tool. There is no impact on normal build and boot. I am OK to add it for 201908 stable tag.

Thanks
Liming
From: Jin, Eric
Sent: Monday, August 12, 2019 3:09 PM
To: rfc@edk2.groups.io
Cc: Gao, Liming <liming.gao@...>; Jin, Eric <eric.jin@...>; devel@edk2.groups.io; Feng, Bob C <bob.c.feng@...>
Subject: [RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in Edk2/BaseTools for 201908 stable tag

Hi All,

It is the request to Enable Windows Firmware Update Driver Tool in Edk2/BaseTools and catch the Q3 tag.
The new tool will leverage the edk2-pytool-library to generate the cat/inf file based on the cap file. The output driver package can be trigged in Windows OS to complete capsule update.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1837

Patch link: https://edk2.groups.io/g/devel/topic/32780378#44992

Best Regards
Eric


Re: [RFC] BZ 2067 BaseTools/Scripts: Add GetUtcDateTime.py for edk2-stable201908 stable tag.

Leif Lindholm
 

I am not fundamentally opposed to merging a simple script that does
not affect other code in the tree.

*But* the fact that we have multiple occurrences of this this time
around *is* a bit of a concern for me. Yes, they won't affect the
workings of anything else as part of the release. But they will not
have had any chance to be actually used by others.

For this particular script, I am also not very keen on the
implementation. It manually parses the command line and prints usage
instead of using argparse.
And it contains the sys.exit(Main()) antipattern, which does not play
well with Python3 asynchronous i/o (and hence is a bad habit to get
into).

Since this script is truly trivial, I am OK for it to be included *if*
it is rewritten using argparse and not calling sys.exit.

Best Regards,

Leif

On Tue, Aug 13, 2019 at 01:42:23PM +0000, Gao, Liming wrote:
This is a small helper script. I am OK to add it for edk2-stable201908 stable tag.

Thanks
Liming
From: Chiu, Chasel
Sent: Monday, August 12, 2019 3:45 PM
To: rfc@edk2.groups.io
Cc: Gao, Liming <liming.gao@...>; Feng, Bob C <bob.c.feng@...>; devel@edk2.groups.io
Subject: [RFC] BZ 2067 BaseTools/Scripts: Add GetUtcDateTime.py for edk2-stable201908 stable tag.


Hello,

I would like to add below simple script to 201908 stable tag, review was sent on August 8th:

A script that can return UTC date and time in ascii format which is convenient for patching build time information in any binary.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067
Patch: https://edk2.groups.io/g/devel/topic/32797962#45177

Thanks!
Chasel


Re: CPU hotplug using SMM with QEMU+OVMF

Laszlo Ersek
 

On 08/13/19 18:09, Laszlo Ersek wrote:
On 08/13/19 16:16, Laszlo Ersek wrote:
(06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
rebase code.

(07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
Aha, so this is the SMM-only register you mention in step (03). Is the
register specified in the Intel SDM?


(08) New CPU: (Flash) Get message - Enable SMI.

(09) Host CPU: (SMM) Send SMI to the new CPU only.

(10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
TSEG.
What code does the new CPU execute after it completes step (10)? Does it
halt?


(11) Host CPU: (SMM) Restore 38000.
These steps (i.e., (06) through (11)) don't appear RAS-specific. The
only platform-specific feature seems to be SMI masking register, which
could be extracted into a new SmmCpuFeaturesLib API.

Thus, would you please consider open sourcing firmware code for steps
(06) through (11)?


Alternatively -- and in particular because the stack for step (01)
concerns me --, we could approach this from a high-level, functional
perspective. The states that really matter are the relocated SMBASE for
the new CPU, and the state of the full system, right at the end of step
(11).

When the SMM setup quiesces during normal firmware boot, OVMF could use
existent (finalized) SMBASE infomation to *pre-program* some virtual
QEMU hardware, with such state that would be expected, as "final" state,
of any new hotplugged CPU. Afterwards, if / when the hotplug actually
happens, QEMU could blanket-apply this state to the new CPU, and
broadcast a hardware SMI to all CPUs except the new one.

The hardware SMI should tell the firmware that the rest of the process
-- step (12) below, and onward -- is being requested.

If I understand right, this approach would produce an firmware & system
state that's identical to what's expected right after step (11):

- all SMBASEs relocated
- all preexistent CPUs in SMM
- new CPU halted / blocked from launch
- DRAM at 0x30000 / 0x38000 contains OS-owned data

Is my understanding correct that this is the expected state after step
(11)?
Revisiting some of my notes from earlier, such as
<https://bugzilla.redhat.com/show_bug.cgi?id=1454803#c46> -- apologies,
private BZ... --, we discussed some of this stuff with Mike on the phone
in April.

And, it looked like generating a hardware SMI in QEMU, in association
with the hotplug action that was being requested through the QEMU
monitor, would be the right approach.

By now I have forgotten about that discussion -- hence "revisiting my
notes"--, but luckily, it seems consistent with what I've proposed
above, under "alternatively".

Thanks,
Laszlo


Re: CPU hotplug using SMM with QEMU+OVMF

Laszlo Ersek
 

On 08/13/19 16:16, Laszlo Ersek wrote:

Yingwen and Jiewen suggested the following process.

Legend:

- "New CPU": CPU being hot-added
- "Host CPU": existing CPU
- (Flash): code running from flash
- (SMM): code running from SMRAM

Steps:

(01) New CPU: (Flash) enter reset vector, Global SMI disabled by
default.
- What does "Global SMI disabled by default" mean? In particular, what
is "global" here?

Do you mean that the CPU being hot-plugged should mask (by default)
broadcast SMIs? What about directed SMIs? (An attacker could try that
too.)

And what about other processors? (I'd assume step (01)) is not
relevant for other processors, but "global" is quite confusing here.)

- Does this part require a new branch somewhere in the OVMF SEC code?
How do we determine whether the CPU executing SEC is BSP or
hot-plugged AP?

- How do we tell the hot-plugged AP where to start execution? (I.e. that
it should execute code at a particular pflash location.)

For example, in MpInitLib, we start a specific AP with INIT-SIPI-SIPI,
where "SIPI" stores the startup address in the "Interrupt Command
Register" (which is memory-mapped in xAPIC mode, and an MSR in x2APIC
mode, apparently). That doesn't apply here -- should QEMU auto-start
the new CPU?

- What memory is used as stack by the new CPU, when it runs code from
flash?

QEMU does not emulate CAR (Cache As RAM). The new CPU doesn't have
access to SMRAM. And we cannot use AcpiNVS or Reserved memory, because
a malicious OS could use other CPUs -- or PCI device DMA -- to attack
the stack (unless QEMU forcibly paused other CPUs upon hotplug; I'm
not sure).

- If an attempt is made to hotplug multiple CPUs in quick succession,
does something serialize those attempts?

Again, stack usage could be a concern, even with Cache-As-RAM --
HyperThreads (logical processors) on a single core don't have
dedicated cache.

Does CPU hotplug apply only at the socket level? If the CPU is
multi-core, what is responsible for hot-plugging all cores present in
the socket?


(02) New CPU: (Flash) configure memory control to let it access global
host memory.
In QEMU/KVM guests, we don't have to enable memory explicitly, it just
exists and works.

In OVMF X64 SEC, we can't access RAM above 4GB, but that shouldn't be an
issue per se.


(03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
-- I am waiting for hot-add message.
Maybe we can simplify this in QEMU by broadcasting an SMI to existent
processors immediately upon plugging the new CPU.


(NOTE: Host CPU can only send
instruction in SMM mode. -- The register is SMM only)
Sorry, I don't follow -- what register are we talking about here, and
why is the BSP needed to send anything at all? What "instruction" do you
have in mind?


(04) Host CPU: (OS) get message from board that a new CPU is added.
(GPIO -> SCI)

(05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU
will not enter CPU because SMI is disabled)
I don't understand the OS involvement here. But, again, perhaps QEMU can
force all existent CPUs into SMM immediately upon adding the new CPU.


(06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
rebase code.

(07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
Aha, so this is the SMM-only register you mention in step (03). Is the
register specified in the Intel SDM?


(08) New CPU: (Flash) Get message - Enable SMI.

(09) Host CPU: (SMM) Send SMI to the new CPU only.

(10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
TSEG.
What code does the new CPU execute after it completes step (10)? Does it
halt?


(11) Host CPU: (SMM) Restore 38000.
These steps (i.e., (06) through (11)) don't appear RAS-specific. The
only platform-specific feature seems to be SMI masking register, which
could be extracted into a new SmmCpuFeaturesLib API.

Thus, would you please consider open sourcing firmware code for steps
(06) through (11)?


Alternatively -- and in particular because the stack for step (01)
concerns me --, we could approach this from a high-level, functional
perspective. The states that really matter are the relocated SMBASE for
the new CPU, and the state of the full system, right at the end of step
(11).

When the SMM setup quiesces during normal firmware boot, OVMF could use
existent (finalized) SMBASE infomation to *pre-program* some virtual
QEMU hardware, with such state that would be expected, as "final" state,
of any new hotplugged CPU. Afterwards, if / when the hotplug actually
happens, QEMU could blanket-apply this state to the new CPU, and
broadcast a hardware SMI to all CPUs except the new one.

The hardware SMI should tell the firmware that the rest of the process
-- step (12) below, and onward -- is being requested.

If I understand right, this approach would produce an firmware & system
state that's identical to what's expected right after step (11):

- all SMBASEs relocated
- all preexistent CPUs in SMM
- new CPU halted / blocked from launch
- DRAM at 0x30000 / 0x38000 contains OS-owned data

Is my understanding correct that this is the expected state after step
(11)?

Three more comments on the "SMBASE pre-config" approach:

- the virtual hardware providing this feature should become locked after
the configuration, until next platform reset

- the pre-config should occur via simple hardware accesses, so that it
can be replayed at S3 resume, i.e. as part of the S3 boot script

- from the pre-configured state, and the APIC ID, QEMU itself could
perhaps calculate the SMI stack location for the new processor.


(12) Host CPU: (SMM) Update located data structure to add the new CPU
information. (This step will involve CPU_SERVICE protocol)
I commented on EFI_SMM_CPU_SERVICE_PROTOCOL in upon bullet (4) of
<https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c4>.

Calling EFI_SMM_ADD_PROCESSOR looks justified.

What are some of the other member functions used for? The scary one is
EFI_SMM_REGISTER_EXCEPTION_HANDLER.


===================== (now, the next SMI will bring all CPU into TSEG)
OK... but what component injects that SMI, and when?


(13) New CPU: (Flash) run MRC code, to init its own memory.
Why is this needed esp. after step (10)? The new CPU has accessed DRAM
already. And why are we executing code from pflash, rather than from
SMRAM, given that we're past SMBASE relocation?


(14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.

(15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in.
I'm confused by these steps. I thought that step (12) would complete the
hotplug, by updating the administrative data structures internally. And
the next SMI -- raised for the usual purposes, such as a software SMI
for variable access -- would be handled like it always is, except it
would also pull the new CPU into SMM too.

Thanks!
Laszlo


CPU hotplug using SMM with QEMU+OVMF

Laszlo Ersek
 

Hi,

this message is a problem statement, and an initial recommendation for
solving it, from Jiewen, Paolo, Yingwen, and others. I'm cross-posting
the thread starter to the <devel@edk2.groups.io>, <rfc@edk2.groups.io>
and <qemu-devel@...> lists. Please use "Reply All" when
commenting.

In response to the initial posting, I plan to ask a number of questions.

The related TianoCore bugzillas are:

https://bugzilla.tianocore.org/show_bug.cgi?id=1512
https://bugzilla.tianocore.org/show_bug.cgi?id=1515

SMM is used as a security barrier between the OS kernel and the
firmware. When a CPU is plugged into a running system where this barrier
exists fine otherwise, the new CPU can be considered a means to attack
SMM. When the next SMI is raised (globally, or targeted at the new CPU),
the SMBASE for that CPU is still at 0x30000, which is normal RAM, not
SMRAM. Therefore the OS could place attack code in that area prior to
the SMI. Once in SMM, the new CPU would execute OS-owned code (from
normal RAM) with access to SMRAM and to other SMM-protected stuff, such
as flash. [I stole a few words from Paolo here.]

Jiewen summarized the problem as follows:

- Asset: SMM

- Adversary:

- System Software Attacker, who can control any OS memory or silicon
register from OS level, or read write BIOS data.

- Simple hardware attacker, who can hot add or hot remove a CPU.

- Non-adversary: The attacker cannot modify the flash BIOS code or
read only BIOS data. The flash part itself is treated as TCB and
protected.

- Threat: The attacker may hot add or hot remove a CPU, then modify
system memory to tamper the SMRAM content, or trigger SMI to get the
privilege escalation by executing code in SMM mode.

We'd like to solve this problem for QEMU/KVM and OVMF.

(At the moment, CPU hotplug doesn't work with OVMF *iff* OVMF was built
with -D SMM_REQUIRE. SMBASE relocation never happens for the new CPU,
the SMM infrastructure in edk2 doesn't know about the new CPU, and so
when the first SMI is broadcast afterwards, we crash. We'd like this
functionality to *work*, in the first place -- but securely at that, so
that an actively malicious guest kernel can't break into SMM.)

Yingwen and Jiewen suggested the following process.

Legend:

- "New CPU": CPU being hot-added
- "Host CPU": existing CPU
- (Flash): code running from flash
- (SMM): code running from SMRAM

Steps:

(01) New CPU: (Flash) enter reset vector, Global SMI disabled by
default.

(02) New CPU: (Flash) configure memory control to let it access global
host memory.

(03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI) --
I am waiting for hot-add message. (NOTE: Host CPU can only send
instruction in SMM mode. -- The register is SMM only)

(04) Host CPU: (OS) get message from board that a new CPU is added.
(GPIO -> SCI)

(05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU will
not enter CPU because SMI is disabled)

(06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM rebase
code.

(07) Host CPU: (SMM) Send message to New CPU to Enable SMI.

(08) New CPU: (Flash) Get message - Enable SMI.

(09) Host CPU: (SMM) Send SMI to the new CPU only.

(10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
TSEG.

(11) Host CPU: (SMM) Restore 38000.

(12) Host CPU: (SMM) Update located data structure to add the new CPU
information. (This step will involve CPU_SERVICE protocol)

===================== (now, the next SMI will bring all CPU into TSEG)

(13) New CPU: (Flash) run MRC code, to init its own memory.

(14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.

(15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in.

Thanks
Laszlo


Re: [RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in Edk2/BaseTools for 201908 stable tag

Liming Gao
 

I see this patch was sent a week ago. This is a standalone tool. There is no impact on normal build and boot. I am OK to add it for 201908 stable tag.

Thanks
Liming
From: Jin, Eric
Sent: Monday, August 12, 2019 3:09 PM
To: rfc@edk2.groups.io
Cc: Gao, Liming <liming.gao@...>; Jin, Eric <eric.jin@...>; devel@edk2.groups.io; Feng, Bob C <bob.c.feng@...>
Subject: [RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in Edk2/BaseTools for 201908 stable tag

Hi All,

It is the request to Enable Windows Firmware Update Driver Tool in Edk2/BaseTools and catch the Q3 tag.
The new tool will leverage the edk2-pytool-library to generate the cat/inf file based on the cap file. The output driver package can be trigged in Windows OS to complete capsule update.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1837

Patch link: https://edk2.groups.io/g/devel/topic/32780378#44992

Best Regards
Eric


Re: [RFC] BZ 2067 BaseTools/Scripts: Add GetUtcDateTime.py for edk2-stable201908 stable tag.

Liming Gao
 

This is a small helper script. I am OK to add it for edk2-stable201908 stable tag.

Thanks
Liming
From: Chiu, Chasel
Sent: Monday, August 12, 2019 3:45 PM
To: rfc@edk2.groups.io
Cc: Gao, Liming <liming.gao@...>; Feng, Bob C <bob.c.feng@...>; devel@edk2.groups.io
Subject: [RFC] BZ 2067 BaseTools/Scripts: Add GetUtcDateTime.py for edk2-stable201908 stable tag.


Hello,

I would like to add below simple script to 201908 stable tag, review was sent on August 8th:

A script that can return UTC date and time in ascii format which is convenient for patching build time information in any binary.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067
Patch: https://edk2.groups.io/g/devel/topic/32797962#45177

Thanks!
Chasel


Re: [RFC] BZ 1772 MdeModulePkg: Transfer reset data for 201908 stable tag

Gao, Zhichao
 

It is an recommended feature change. But the specific function isn't implemented with any platform yet. So it wouldn't affect any section of the edk2.
And it changed a lot of platform dsc files(or module package dsc files) in both edk2 and edk2-paltform. That may take time for the review work.
I think it is fine if this feature doesn't catch the end-line of the software-freeze.

Thanks,
Zhichao

From: Gao, Liming
Sent: Monday, August 12, 2019 4:55 PM
To: Gao, Zhichao <zhichao.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io
Subject: RE: [RFC] BZ 1772 MdeModulePkg: Transfer reset data for 201908 stable tag

Zhichao:
Do you propose this feature for 201908 stable tag?

From: Gao, Zhichao
Sent: Monday, August 12, 2019 4:33 PM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Gao, Liming <liming.gao@...<mailto:liming.gao@...>>
Subject: [RFC] BZ 1772 MdeModulePkg: Transfer reset data

HI,

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1772

Before the ResetData of ResetSystem is limit by ResetType and ResetStatus. As the Uefi spec update to 2.8, there is no limit any longer.
Here we introduce a new API ResetSystemWithSubtype to transfer a null string and GUID data with all ResetType to reset system.
It is useful for capsule update to get a specific GUID to do some special operation with specific phase. That can be implemented in platform code thru Reset Notify protocol.
Here is the guids:
gEdkiiCapsuleArmedResetGuid = {0xc6b4eea7, 0xfce2, 0x4625, {0x9c, 0x4f, 0xc4, 0xb0, 0x82, 0x37, 0xae, 0x23}}
gEdkiiCapsuleUpdateCompleteResetGuid = {0x5d512714, 0xa4df, 0x4e46, {0xb6, 0xc7, 0xbc, 0x9f, 0x97, 0x9d, 0x59, 0xa0}}

Thanks,
Zhichao


Re: [RFC] BZ 1772 MdeModulePkg: Transfer reset data for 201908 stable tag

Liming Gao
 

Zhichao:
Do you propose this feature for 201908 stable tag?

From: Gao, Zhichao
Sent: Monday, August 12, 2019 4:33 PM
To: rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@...>
Subject: [RFC] BZ 1772 MdeModulePkg: Transfer reset data

HI,

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1772

Before the ResetData of ResetSystem is limit by ResetType and ResetStatus. As the Uefi spec update to 2.8, there is no limit any longer.
Here we introduce a new API ResetSystemWithSubtype to transfer a null string and GUID data with all ResetType to reset system.
It is useful for capsule update to get a specific GUID to do some special operation with specific phase. That can be implemented in platform code thru Reset Notify protocol.
Here is the guids:
gEdkiiCapsuleArmedResetGuid = {0xc6b4eea7, 0xfce2, 0x4625, {0x9c, 0x4f, 0xc4, 0xb0, 0x82, 0x37, 0xae, 0x23}}
gEdkiiCapsuleUpdateCompleteResetGuid = {0x5d512714, 0xa4df, 0x4e46, {0xb6, 0xc7, 0xbc, 0x9f, 0x97, 0x9d, 0x59, 0xa0}}

Thanks,
Zhichao


UEFI accessibility mandate

Ethin Probst <harlydavidsen@...>
 

Hello all,

I'm new here, and was recommended to the TianoCore project by someone over at the UEFI forum. I've run across TianoCore before, and like the project.
Before anyone gets worried by the subject line, no, this is not any kind of legal thing. Its just something I believe needs to happen. :)
Back in 2016-2017 I contacted the UEFI forum about two problems, one of which was the format of the spec, which I figured out on my own. The other problem was not so easily dealt with. Te other problem relates to accessibility of UEFI-compliant systems and platform firmware to persons with disabilities. As it currently stands, such a thing is nonexistent. To be fair, I completely understand the difficulty that such a thing would require, and I would fully agree if we still used the PC-AT BIOS systems -- yes, indeed, I would never suggest this kind of thing on such a system given that there was no actual standard of any kind for BIOSes. However, now that UEFI is here, we have such a possibility.
As it currently stands, people with low vision or blind people have access to their computers in the general sense (I am blind myself). We can do pretty much anything anyone else could do. We can code, play games, all that. There are few things that we cannot do. One of those things is managing our systems firmware in the preboot environment.
As it stands now, I can only boot other OSes or disks via memorization. While that worked on BIOS machines (I have, or had, an old Toshiba laptop that was BIOS-based), it no longer works because UEFI is mercurial. When I access the boot menu now, I play a game of chance. If the cards are in my favor, the OS I want to boot boots, and I can go on my way. But if the cards aren't in my favor, I end up making something happen that was unintended, and, worst of all, I have no idea what I did.
However, the boot menu is only one portion of a platform firmware UI. What about the setup utility or other utilities offered by computer manufacturers? What about diagnostic utilities, bootloaders, etc? What do I do with those? Well, I only have one option -- sited assistance. If I go into my computers setup utility, I cannot trust myself and say to myself, "OK, I know what I'm doing. All I need to do is change x and save and quit." No, I can't do that, because memorizing such a complex interface is extremely difficult, and its something I wouldn't expect anyone to do.
My proposal is simple, and I'm posting it here because I'd like comments and feedback before it actually gets implemented (it will take a lot of time, I'm sure): mandate, in the UEFI specification, that accessibility features for persons with disabilities must be implemented and documented, and, if such features are not implemented, then that vendor is not compliant with the specification. Place strict minimum requirements for what the accessibility features should do and how they should work.
Now, I'm sure someone out there will ask me how this can be done. Well, that's why I've joined the group -- though as I familiarize myself with EDK2 development and all that I may actually be able to participate as more than just an accessibility expert, of sorts.
As a side note, I have been blind all my life. I was born with retinopathy of prematurity (ROP), which resulted because I was born at 26 weeks. My retina was detached, and, though the doctors attempted to fix it, it would not remain attached, and there is no chance of it getting fixed now. I would neither want nor care for such a cure, however. I have lived my entire life blind, and while the thought of gaining site back is appealing, I am unwilling to go through the years and years of rewiring and reconditioning of my brain that would be required for me to survive with site. To me, it is simply not worth the cost.
But back to the discussion at hand: I would be happy to discuss how the accessibility features would work and what would be required. Even standardizing, through the specification, a key combination to toggle the accessibility features would be nice, as that would alleviate the major problem of a blind person buying a new computer and not knowing how to enable the accessibility features. The overarching goal would be to make the preboot environment (including applications run within it) accessible and usable by blind and visually impaired people as a boot service only. It would be superfluous to make this a runtime service, as all major OSes already have accessibility features. Plus, managing such a thing would be impossible to do.
This email has gotten quite long, so I will suspend the discussion of functionality and how I would like it to work for a future email once everyone has gotten on board.

Thank you for your time and consideration.


[RFC] BZ 1772 MdeModulePkg: Transfer reset data

Gao, Zhichao
 

HI,

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1772

Before the ResetData of ResetSystem is limit by ResetType and ResetStatus. As the Uefi spec update to 2.8, there is no limit any longer.
Here we introduce a new API ResetSystemWithSubtype to transfer a null string and GUID data with all ResetType to reset system.
It is useful for capsule update to get a specific GUID to do some special operation with specific phase. That can be implemented in platform code thru Reset Notify protocol.
Here is the guids:
gEdkiiCapsuleArmedResetGuid = {0xc6b4eea7, 0xfce2, 0x4625, {0x9c, 0x4f, 0xc4, 0xb0, 0x82, 0x37, 0xae, 0x23}}
gEdkiiCapsuleUpdateCompleteResetGuid = {0x5d512714, 0xa4df, 0x4e46, {0xb6, 0xc7, 0xbc, 0x9f, 0x97, 0x9d, 0x59, 0xa0}}

Thanks,
Zhichao


[RFC] BZ 2067 BaseTools/Scripts: Add GetUtcDateTime.py for edk2-stable201908 stable tag.

Chiu, Chasel <chasel.chiu@...>
 

Hello,

I would like to add below simple script to 201908 stable tag, review was sent on August 8th:

A script that can return UTC date and time in ascii format which is convenient for patching build time information in any binary.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067
Patch: https://edk2.groups.io/g/devel/topic/32797962#45177

Thanks!
Chasel


[RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in Edk2/BaseTools for 201908 stable tag

Eric Jin <eric.jin@...>
 

Hi All,

It is the request to Enable Windows Firmware Update Driver Tool in Edk2/BaseTools and catch the Q3 tag.
The new tool will leverage the edk2-pytool-library to generate the cat/inf file based on the cap file. The output driver package can be trigged in Windows OS to complete capsule update.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1837

Patch link: https://edk2.groups.io/g/devel/topic/32780378#44992

Best Regards
Eric


Re: [edk2-devel] [RFC] Fine-grained review ownership for MdeModulePkg

Wu, Hao A
 

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Tuesday, July 16, 2019 9:53 PM
To: Wu, Hao A
Cc: rfc@edk2.groups.io; devel@edk2.groups.io; Andrew Fish; Laszlo Ersek;
Kinney, Michael D; Wang, Jian J; Ni, Ray; Zeng, Star
Subject: Re: [edk2-devel] [RFC] Fine-grained review ownership for
MdeModulePkg

Hi Hao Wu,

Are you ready to send out a v1 yet? (Or did I miss it?)
I would prefer to get this in before the GetMaintainer.py script, and
after the comment updates to Maintainers.txt.

Sorry Leif,

You did not miss anything.
I was planning to send out the patch after your proposed changes are pushed.

Now, I have sent out the patch at:
https://edk2.groups.io/g/devel/message/43827

Best Regards,
Hao Wu



Best Regards,

Leif

On Mon, Jun 24, 2019 at 01:16:05AM +0000, Wu, Hao A wrote:
Hello all,

With Leif's comment on the better usage of the wildcard character & 'X:' tag:
https://edk2.groups.io/g/devel/message/42587

The list is updated as shown below.

Also, I forgot to mention that some directory/file may be classified into
multiple classes. I think it is a valid case, for example:

MdeModulePkg/Library/SmmMemoryAllocationProfileLib

matches both 'Memory Management' and 'SMM' sections:

Memory Management - F: MdeModulePkg/*Mem*/
SMM - F: MdeModulePkg/*Smm*/

Then, reviewers from both classes should be Cc-ed when changes are
made in
the above library.

If the updated list is good enough, the next step will be determining the
reviewer(s) for each feature in the list.


The updated list:
ACPI:
F: MdeModulePkg/Include/*/*Acpi*.h
F: MdeModulePkg/Universal/Acpi/

BDS:
F: MdeModulePkg/*BootManager*/
X: MdeModulePkg/Application/BootManagerMenuApp/
F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
F: MdeModulePkg/Universal/BdsDxe/
F: MdeModulePkg/Universal/LoadFileOnFv2/
F: MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.*

Console:
F: MdeModulePkg/Include/Guid/ConnectConInEvent.h
F: MdeModulePkg/Include/Guid/Console*.h
F: MdeModulePkg/Include/Guid/StandardErrorDevice.h
F: MdeModulePkg/Include/Guid/TtyTerm.h
F: MdeModulePkg/Universal/Console/
X: MdeModulePkg/Universal/Console/GraphicsOutputDxe/

Core (PEI, DXE and Runtime):
F: MdeModulePkg/*SectionExtract*/
F: MdeModulePkg/Core/Dxe/
X: MdeModulePkg/Core/Dxe/Gcd/
X: MdeModulePkg/Core/Dxe/Mem/
F: MdeModulePkg/Core/DxeIplPeim/
F: MdeModulePkg/Core/Pei/
X: MdeModulePkg/Core/Pei/Memory/
X: MdeModulePkg/Core/Pei/PciCfg2/
X: MdeModulePkg/Core/Pei/Reset/
X: MdeModulePkg/Core/Pei/StatusCode/
F: MdeModulePkg/Core/RuntimeDxe/
F: MdeModulePkg/Include/Guid/Crc32GuidedSectionExtraction.h
F: MdeModulePkg/Include/Guid/EventExitBootServiceFailed.h
F: MdeModulePkg/Include/Guid/IdleLoopEvent.h
F: MdeModulePkg/Include/Guid/LoadModuleAtFixedAddress.h
F: MdeModulePkg/Include/Library/SecurityManagementLib.h
F: MdeModulePkg/Library/DxeSecurityManagementLib/
F: MdeModulePkg/Universal/PlatformDriOverrideDxe/
F: MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c

Debug:
F: MdeModulePkg/*Debug*/
X: MdeModulePkg/Universal/EbcDxe/EbcDebugger/
F: MdeModulePkg/Include/Guid/DebugMask.h
F: MdeModulePkg/Include/Library/DebugAgentLib.h
F: MdeModulePkg/Include/Ppi/Debug.h

Decompress:
F: MdeModulePkg/Include/Guid/LzmaDecompress.h
F: MdeModulePkg/Library/*Decompress*/

Device:
F: MdeModulePkg/*Serial*/
X: MdeModulePkg/Library/PlatformHookLibSerialPortPpi/
F: MdeModulePkg/Bus/
X: MdeModulePkg/Bus/Pci/IncompatiblePciDeviceSupportDxe/
X: MdeModulePkg/Bus/Pci/PciBusDxe/
X: MdeModulePkg/Bus/Pci/PciHostBridgeDxe/
F: MdeModulePkg/Include/*/*Ata*.h
F: MdeModulePkg/Include/*/*NonDiscoverableDevice*.h
F: MdeModulePkg/Include/*/*NvmExpress*.h
F: MdeModulePkg/Include/*/*SerialPort*.h
F: MdeModulePkg/Include/*/*SdMmc*.h
F: MdeModulePkg/Include/*/*Ufs*.h
F: MdeModulePkg/Include/*/*Usb*.h
F: MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
F: MdeModulePkg/Include/Guid/RecoveryDevice.h
F: MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
F: MdeModulePkg/Include/Protocol/Ps2Policy.h
F: MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/

Disk:
F: MdeModulePkg/Universal/Disk/

EBC:
F: MdeModulePkg/Include/*/*Ebc*.h
F: MdeModulePkg/Include/Protocol/DebuggerConfiguration.h
F: MdeModulePkg/Universal/EbcDxe/

Firmware Update:
F: MdeModulePkg/*Capsule*/
F: MdeModulePkg/Include/*/*Capsule*.h
F: MdeModulePkg/Include/Library/DisplayUpdateProgressLib.h
F: MdeModulePkg/Include/Library/FmpAuthenticationLib.h
F: MdeModulePkg/Include/Protocol/EsrtManagement.h
F: MdeModulePkg/Include/Protocol/FirmwareManagementProgress.h
F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
F: MdeModulePkg/Library/FmpAuthenticationLibNull/
F: MdeModulePkg/Universal/Esrt*/

Graphic:
F: MdeModulePkg/*Logo*/
F: MdeModulePkg/Include/*/*Logo*.h
F: MdeModulePkg/Include/Library/BmpSupportLib.h
F: MdeModulePkg/Include/Library/FrameBufferBltLib.h
F: MdeModulePkg/Library/BaseBmpSupportLib/
F: MdeModulePkg/Library/FrameBufferBltLib/
F: MdeModulePkg/Universal/Console/GraphicsOutputDxe/

HII/UI:
F: MdeModulePkg/*FileExplorer*/
F: MdeModulePkg/*Hii*/
F: MdeModulePkg/*Ui*/
F: MdeModulePkg/Application/BootManagerMenuApp/
F: MdeModulePkg/Include/*/*FileExplorer*.h
F: MdeModulePkg/Include/*/*FormBrowser*.h
F: MdeModulePkg/Include/*/*Hii*.h
F: MdeModulePkg/Include/Library/CustomizedDisplayLib.h
F: MdeModulePkg/Include/Protocol/DisplayProtocol.h
F: MdeModulePkg/Library/CustomizedDisplayLib/
F: MdeModulePkg/Universal/DisplayEngineDxe/
F: MdeModulePkg/Universal/SetupBrowserDxe/

IPMI:
F: MdeModulePkg/Include/*/*Ipmi*.h
F: MdeModulePkg/Library/*Ipmi*/

Memory Management:
F: MdeModulePkg/*Mem*/
F: MdeModulePkg/Core/Dxe/Gcd/
F: MdeModulePkg/Include/*/*Mem*.h
F: MdeModulePkg/Include/*/*IoMmu*.h

PCD:
F: MdeModulePkg/Application/DumpDynPcd/
F: MdeModulePkg/Include/*/*Pcd*.h
F: MdeModulePkg/Universal/PCD/

PCI Bus:
F: MdeModulePkg/*PciHostBridge*/
F: MdeModulePkg/Bus/Pci/IncompatiblePciDeviceSupportDxe/
F: MdeModulePkg/Bus/Pci/PciBusDxe/
F: MdeModulePkg/Core/Pei/PciCfg2/
F: MdeModulePkg/Include/Library/PciHostBridgeLib.h
F: MdeModulePkg/Universal/PcatSingleSegmentPciCfg2Pei/

Performance:
F: MdeModulePkg/Include/*/*Perf*.h
F: MdeModulePkg/Library/*Perf*/

Reset:
F: MdeModulePkg/*Reset*/
F: MdeModulePkg/Include/*/*Reset*.h

S3:
F: MdeModulePkg/*LockBox*/
F: MdeModulePkg/Include/*/*BootScript*.h
F: MdeModulePkg/Include/*/*LockBox*.h
F: MdeModulePkg/Include/*/*S3*.h
F: MdeModulePkg/Library/*S3*/

SMBIOS:
F: MdeModulePkg/Universal/Smbios*/

SMM:
F: MdeModulePkg/*Smi*/
F: MdeModulePkg/*Smm*/
F: MdeModulePkg/Include/*/*Smi*.h
F: MdeModulePkg/Include/*/*Smm*.h

Status Code:
F: MdeModulePkg/*StatusCode*/
F: MdeModulePkg/Include/*/*StatusCode*.h

Variable:
F: MdeModulePkg/*Var*/
F: MdeModulePkg/Include/*/*FaultTolerantWrite*.h
F: MdeModulePkg/Include/*/*Var*.h
F: MdeModulePkg/Include/Guid/SystemNvDataGuid.h
F: MdeModulePkg/Include/Protocol/SwapAddressRange.h
F: MdeModulePkg/Universal/FaultTolerantWrite*/

Misc:
F: MdeModulePkg/Application/HelloWorld/
F: MdeModulePkg/Include/Guid/F: MdeModulePkgTokenSpace.h
F: MdeModulePkg/Include/Guid/MtcVendor.h
F: MdeModulePkg/Include/Guid/ZeroGuid.h
F: MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
F: MdeModulePkg/Include/Library/PlatformHookLib.h
F: MdeModulePkg/Include/Library/RecoveryLib.h
F: MdeModulePkg/Include/Library/SortLib.h
F: MdeModulePkg/Include/Library/TpmMeasurementLib.h
F: MdeModulePkg/Include/Protocol/Dpc.h
F: MdeModulePkg/Include/Protocol/LoadPe32Image.h
F: MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h
F: MdeModulePkg/Include/Protocol/Print2.h
F: MdeModulePkg/Library/BaseHobLibNull/
F: MdeModulePkg/Library/BasePlatformHookLibNull/
F: MdeModulePkg/Library/BaseSortLib/
F: MdeModulePkg/Library/CpuExceptionHandlerLibNull/
F: MdeModulePkg/Library/DxePrintLibPrint2Protocol/
F: MdeModulePkg/Library/PeiRecoveryLibNull/
F: MdeModulePkg/Library/PlatformHookLibSerialPortPpi/
F: MdeModulePkg/Library/TpmMeasurementLibNull/
F: MdeModulePkg/Library/UefiSortLib/
F: MdeModulePkg/Universal/DevicePathDxe/
F: MdeModulePkg/Universal/DriverHealthManagerDxe/
F: MdeModulePkg/Universal/DriverSampleDxe/
F: MdeModulePkg/Universal/FvSimpleFileSystemDxe/
F: MdeModulePkg/Universal/LegacyRegion2Dxe/
F: MdeModulePkg/Universal/Metronome/
F: MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/
F: MdeModulePkg/Universal/PrintDxe/
F: MdeModulePkg/Universal/RegularExpressionDxe/
F: MdeModulePkg/Universal/TimestampDxe/
F: MdeModulePkg/Universal/WatchdogTimerDxe/


Best Regards,
Hao Wu


Re: [edk2-devel] [RFC] Fine-grained review ownership for MdeModulePkg

Leif Lindholm
 

Hi Hao Wu,

Are you ready to send out a v1 yet? (Or did I miss it?)
I would prefer to get this in before the GetMaintainer.py script, and
after the comment updates to Maintainers.txt.

Best Regards,

Leif

On Mon, Jun 24, 2019 at 01:16:05AM +0000, Wu, Hao A wrote:
Hello all,

With Leif's comment on the better usage of the wildcard character & 'X:' tag:
https://edk2.groups.io/g/devel/message/42587

The list is updated as shown below.

Also, I forgot to mention that some directory/file may be classified into
multiple classes. I think it is a valid case, for example:

MdeModulePkg/Library/SmmMemoryAllocationProfileLib

matches both 'Memory Management' and 'SMM' sections:

Memory Management - F: MdeModulePkg/*Mem*/
SMM - F: MdeModulePkg/*Smm*/

Then, reviewers from both classes should be Cc-ed when changes are made in
the above library.

If the updated list is good enough, the next step will be determining the
reviewer(s) for each feature in the list.


The updated list:
ACPI:
F: MdeModulePkg/Include/*/*Acpi*.h
F: MdeModulePkg/Universal/Acpi/

BDS:
F: MdeModulePkg/*BootManager*/
X: MdeModulePkg/Application/BootManagerMenuApp/
F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
F: MdeModulePkg/Universal/BdsDxe/
F: MdeModulePkg/Universal/LoadFileOnFv2/
F: MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.*

Console:
F: MdeModulePkg/Include/Guid/ConnectConInEvent.h
F: MdeModulePkg/Include/Guid/Console*.h
F: MdeModulePkg/Include/Guid/StandardErrorDevice.h
F: MdeModulePkg/Include/Guid/TtyTerm.h
F: MdeModulePkg/Universal/Console/
X: MdeModulePkg/Universal/Console/GraphicsOutputDxe/

Core (PEI, DXE and Runtime):
F: MdeModulePkg/*SectionExtract*/
F: MdeModulePkg/Core/Dxe/
X: MdeModulePkg/Core/Dxe/Gcd/
X: MdeModulePkg/Core/Dxe/Mem/
F: MdeModulePkg/Core/DxeIplPeim/
F: MdeModulePkg/Core/Pei/
X: MdeModulePkg/Core/Pei/Memory/
X: MdeModulePkg/Core/Pei/PciCfg2/
X: MdeModulePkg/Core/Pei/Reset/
X: MdeModulePkg/Core/Pei/StatusCode/
F: MdeModulePkg/Core/RuntimeDxe/
F: MdeModulePkg/Include/Guid/Crc32GuidedSectionExtraction.h
F: MdeModulePkg/Include/Guid/EventExitBootServiceFailed.h
F: MdeModulePkg/Include/Guid/IdleLoopEvent.h
F: MdeModulePkg/Include/Guid/LoadModuleAtFixedAddress.h
F: MdeModulePkg/Include/Library/SecurityManagementLib.h
F: MdeModulePkg/Library/DxeSecurityManagementLib/
F: MdeModulePkg/Universal/PlatformDriOverrideDxe/
F: MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c

Debug:
F: MdeModulePkg/*Debug*/
X: MdeModulePkg/Universal/EbcDxe/EbcDebugger/
F: MdeModulePkg/Include/Guid/DebugMask.h
F: MdeModulePkg/Include/Library/DebugAgentLib.h
F: MdeModulePkg/Include/Ppi/Debug.h

Decompress:
F: MdeModulePkg/Include/Guid/LzmaDecompress.h
F: MdeModulePkg/Library/*Decompress*/

Device:
F: MdeModulePkg/*Serial*/
X: MdeModulePkg/Library/PlatformHookLibSerialPortPpi/
F: MdeModulePkg/Bus/
X: MdeModulePkg/Bus/Pci/IncompatiblePciDeviceSupportDxe/
X: MdeModulePkg/Bus/Pci/PciBusDxe/
X: MdeModulePkg/Bus/Pci/PciHostBridgeDxe/
F: MdeModulePkg/Include/*/*Ata*.h
F: MdeModulePkg/Include/*/*NonDiscoverableDevice*.h
F: MdeModulePkg/Include/*/*NvmExpress*.h
F: MdeModulePkg/Include/*/*SerialPort*.h
F: MdeModulePkg/Include/*/*SdMmc*.h
F: MdeModulePkg/Include/*/*Ufs*.h
F: MdeModulePkg/Include/*/*Usb*.h
F: MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
F: MdeModulePkg/Include/Guid/RecoveryDevice.h
F: MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
F: MdeModulePkg/Include/Protocol/Ps2Policy.h
F: MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/

Disk:
F: MdeModulePkg/Universal/Disk/

EBC:
F: MdeModulePkg/Include/*/*Ebc*.h
F: MdeModulePkg/Include/Protocol/DebuggerConfiguration.h
F: MdeModulePkg/Universal/EbcDxe/

Firmware Update:
F: MdeModulePkg/*Capsule*/
F: MdeModulePkg/Include/*/*Capsule*.h
F: MdeModulePkg/Include/Library/DisplayUpdateProgressLib.h
F: MdeModulePkg/Include/Library/FmpAuthenticationLib.h
F: MdeModulePkg/Include/Protocol/EsrtManagement.h
F: MdeModulePkg/Include/Protocol/FirmwareManagementProgress.h
F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
F: MdeModulePkg/Library/FmpAuthenticationLibNull/
F: MdeModulePkg/Universal/Esrt*/

Graphic:
F: MdeModulePkg/*Logo*/
F: MdeModulePkg/Include/*/*Logo*.h
F: MdeModulePkg/Include/Library/BmpSupportLib.h
F: MdeModulePkg/Include/Library/FrameBufferBltLib.h
F: MdeModulePkg/Library/BaseBmpSupportLib/
F: MdeModulePkg/Library/FrameBufferBltLib/
F: MdeModulePkg/Universal/Console/GraphicsOutputDxe/

HII/UI:
F: MdeModulePkg/*FileExplorer*/
F: MdeModulePkg/*Hii*/
F: MdeModulePkg/*Ui*/
F: MdeModulePkg/Application/BootManagerMenuApp/
F: MdeModulePkg/Include/*/*FileExplorer*.h
F: MdeModulePkg/Include/*/*FormBrowser*.h
F: MdeModulePkg/Include/*/*Hii*.h
F: MdeModulePkg/Include/Library/CustomizedDisplayLib.h
F: MdeModulePkg/Include/Protocol/DisplayProtocol.h
F: MdeModulePkg/Library/CustomizedDisplayLib/
F: MdeModulePkg/Universal/DisplayEngineDxe/
F: MdeModulePkg/Universal/SetupBrowserDxe/

IPMI:
F: MdeModulePkg/Include/*/*Ipmi*.h
F: MdeModulePkg/Library/*Ipmi*/

Memory Management:
F: MdeModulePkg/*Mem*/
F: MdeModulePkg/Core/Dxe/Gcd/
F: MdeModulePkg/Include/*/*Mem*.h
F: MdeModulePkg/Include/*/*IoMmu*.h

PCD:
F: MdeModulePkg/Application/DumpDynPcd/
F: MdeModulePkg/Include/*/*Pcd*.h
F: MdeModulePkg/Universal/PCD/

PCI Bus:
F: MdeModulePkg/*PciHostBridge*/
F: MdeModulePkg/Bus/Pci/IncompatiblePciDeviceSupportDxe/
F: MdeModulePkg/Bus/Pci/PciBusDxe/
F: MdeModulePkg/Core/Pei/PciCfg2/
F: MdeModulePkg/Include/Library/PciHostBridgeLib.h
F: MdeModulePkg/Universal/PcatSingleSegmentPciCfg2Pei/

Performance:
F: MdeModulePkg/Include/*/*Perf*.h
F: MdeModulePkg/Library/*Perf*/

Reset:
F: MdeModulePkg/*Reset*/
F: MdeModulePkg/Include/*/*Reset*.h

S3:
F: MdeModulePkg/*LockBox*/
F: MdeModulePkg/Include/*/*BootScript*.h
F: MdeModulePkg/Include/*/*LockBox*.h
F: MdeModulePkg/Include/*/*S3*.h
F: MdeModulePkg/Library/*S3*/

SMBIOS:
F: MdeModulePkg/Universal/Smbios*/

SMM:
F: MdeModulePkg/*Smi*/
F: MdeModulePkg/*Smm*/
F: MdeModulePkg/Include/*/*Smi*.h
F: MdeModulePkg/Include/*/*Smm*.h

Status Code:
F: MdeModulePkg/*StatusCode*/
F: MdeModulePkg/Include/*/*StatusCode*.h

Variable:
F: MdeModulePkg/*Var*/
F: MdeModulePkg/Include/*/*FaultTolerantWrite*.h
F: MdeModulePkg/Include/*/*Var*.h
F: MdeModulePkg/Include/Guid/SystemNvDataGuid.h
F: MdeModulePkg/Include/Protocol/SwapAddressRange.h
F: MdeModulePkg/Universal/FaultTolerantWrite*/

Misc:
F: MdeModulePkg/Application/HelloWorld/
F: MdeModulePkg/Include/Guid/F: MdeModulePkgTokenSpace.h
F: MdeModulePkg/Include/Guid/MtcVendor.h
F: MdeModulePkg/Include/Guid/ZeroGuid.h
F: MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
F: MdeModulePkg/Include/Library/PlatformHookLib.h
F: MdeModulePkg/Include/Library/RecoveryLib.h
F: MdeModulePkg/Include/Library/SortLib.h
F: MdeModulePkg/Include/Library/TpmMeasurementLib.h
F: MdeModulePkg/Include/Protocol/Dpc.h
F: MdeModulePkg/Include/Protocol/LoadPe32Image.h
F: MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h
F: MdeModulePkg/Include/Protocol/Print2.h
F: MdeModulePkg/Library/BaseHobLibNull/
F: MdeModulePkg/Library/BasePlatformHookLibNull/
F: MdeModulePkg/Library/BaseSortLib/
F: MdeModulePkg/Library/CpuExceptionHandlerLibNull/
F: MdeModulePkg/Library/DxePrintLibPrint2Protocol/
F: MdeModulePkg/Library/PeiRecoveryLibNull/
F: MdeModulePkg/Library/PlatformHookLibSerialPortPpi/
F: MdeModulePkg/Library/TpmMeasurementLibNull/
F: MdeModulePkg/Library/UefiSortLib/
F: MdeModulePkg/Universal/DevicePathDxe/
F: MdeModulePkg/Universal/DriverHealthManagerDxe/
F: MdeModulePkg/Universal/DriverSampleDxe/
F: MdeModulePkg/Universal/FvSimpleFileSystemDxe/
F: MdeModulePkg/Universal/LegacyRegion2Dxe/
F: MdeModulePkg/Universal/Metronome/
F: MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/
F: MdeModulePkg/Universal/PrintDxe/
F: MdeModulePkg/Universal/RegularExpressionDxe/
F: MdeModulePkg/Universal/TimestampDxe/
F: MdeModulePkg/Universal/WatchdogTimerDxe/


Best Regards,
Hao Wu


Re: [RFC PATCH 2/3] Maintainers.txt: add wildcard path association for Arm/AArch64

Leif Lindholm
 

On Thu, Jul 04, 2019 at 06:14:04AM +0000, Wu, Hao A wrote:
I do met a little problem that for a patch that touches multiple features,
the contacts order in the output is not ideally perfect:

Content in Maintainers.txt:
'''
MdeModulePkg
F: MdeModulePkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
M: Jian J Wang <jian.j.wang@...>
M: Hao A Wu <hao.a.wu@...>

F: MdeModulePkg/*Ufs*/
R: Ufs Guy <ufs@...>

F: MdeModulePkg/Include/*Hii*.h
F: MdeModulePkg/*Hii*/
R: Hii Guy <hii@...>
'''

Script output:
'''
$ py BaseTools/Scripts/GetMaintainer.py HEAD
MdeModulePkg/Bus/Pci/UfsPciHcDxe/UfsPciHcDxe.inf
MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.uni
Jian J Wang <jian.j.wang@...>
Hao A Wu <hao.a.wu@...>
Ufs Guy <ufs@...>
devel@edk2.groups.io
Hii Guy <hii@...>
'''

The 'Hii Guy' is at the end of the list.
Totally agree. The idea was to keep the first revision simple.
Another thing missing (that I would argue is even more important than
listed order), is an indication of *why* said person is listed.

But this is a rather minor problem and does not impact the use at all.
Good. I will respin the set based on Laszlo's feedback on previous
version and resubmit.

Best Regards,

Leif


Re: [RFC PATCH 2/3] Maintainers.txt: add wildcard path association for Arm/AArch64

Wu, Hao A
 

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Wednesday, July 03, 2019 6:44 PM
To: Wu, Hao A
Cc: devel@edk2.groups.io
Subject: Re: [RFC PATCH 2/3] Maintainers.txt: add wildcard path association
for Arm/AArch64

On Wed, Jul 03, 2019 at 07:52:46AM +0000, Wu, Hao A wrote:
-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Saturday, June 15, 2019 4:21 AM
To: devel@edk2.groups.io
Cc: Feng, Bob C; Gao, Liming; Andrew Fish; Laszlo Ersek; Kinney, Michael
D;
Wu, Hao A
Subject: [RFC PATCH 2/3] Maintainers.txt: add wildcard path association
for
Arm/AArch64

Add Ard and Leif as responsible for any path matching
F: */Arm/
F: */AArch64/

Signed-off-by: Leif Lindholm <leif.lindholm@...>
---
Maintainers.txt | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index cd32f9b00170..e415f51468d5 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -82,6 +82,14 @@ EDK II Releases:
W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
Release-
Planning
M: Liming Gao <liming.gao@...>

+EDK II Architectures:
+---------------------
+ARM, AARCH64
+F: */AArch64/
+F: */Arm/

Hello Leif,

I want to confirm a couple of usage model for the wildcard character.

Maybe they have been explained with your response to Laszlo's comments,
but I just want to double-confirm with my using cases.

1. Matching multiple levels of directories

For the below 2 folders:
MdeModulePkg/Bus/Ufs/
MdeModulePkg/Bus/Pci/UfsPciHcDxe/

I can use:
MdeModulePkg/*Ufs*/

to match them all, right?
Yes, that is how it currently works (I think?). It is unclear to me if
there is consensus on how we want it to work in the future.

Yes, the proposed BaseTools script is working for:
MdeModulePkg/*Ufs*/

to match changes made in both directories.

I am also fine (and prefer) for the wildcard character to match multiple
levels of folders.



2. Matching header files (usually within the Include/ directory)

In some cases, a feature may include some drivers + some include header
files. So for the below case:
MdeModulePkg/Include/Library/HiiLib.h
MdeModulePkg/Include/Guid/HiiResourceSampleHii.h
MdeModulePkg/Universal/HiiDatabaseDxe/
MdeModulePkg/Universal/HiiResourcesSampleDxe/
MdeModulePkg/Library/UefiHiiLib/

Should I use:
MdeModulePkg/*Hii*/

to match the drivers(libraries) and the headers all or should I use:
MdeModulePkg/*Hii*/
MdeModulePkg/Include/*Hii*.h
My view is that this second option would be required.
If MdeModulePkg/*Hii*/ matches on the .h files, that is effectively a
bug - is that the behaviour you are currently seeing?

The script is working like the 2nd option, and I think it is expected.
So, there seems to me no bug in my tests.


I do met a little problem that for a patch that touches multiple features,
the contacts order in the output is not ideally perfect:

Content in Maintainers.txt:
'''
MdeModulePkg
F: MdeModulePkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
M: Jian J Wang <jian.j.wang@...>
M: Hao A Wu <hao.a.wu@...>

F: MdeModulePkg/*Ufs*/
R: Ufs Guy <ufs@...>

F: MdeModulePkg/Include/*Hii*.h
F: MdeModulePkg/*Hii*/
R: Hii Guy <hii@...>
'''

Script output:
'''
$ py BaseTools/Scripts/GetMaintainer.py HEAD
MdeModulePkg/Bus/Pci/UfsPciHcDxe/UfsPciHcDxe.inf
MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.uni
Jian J Wang <jian.j.wang@...>
Hao A Wu <hao.a.wu@...>
Ufs Guy <ufs@...>
devel@edk2.groups.io
Hii Guy <hii@...>
'''

The 'Hii Guy' is at the end of the list.

But this is a rather minor problem and does not impact the use at all.

Best Regards,
Hao Wu


Best Regards,

Leif


Re: [edk2-devel] [RFC][PATCH 1/1] Maintainers.txt: Drop deprecated SourceForge SVN link

Wu, Hao A
 

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Wu, Hao A
Sent: Wednesday, July 03, 2019 3:21 PM
To: devel@edk2.groups.io; rfc@edk2.groups.io
Cc: lersek@...; Gao, Liming; Andrew Fish; Leif Lindholm; Kinney,
Michael D; Justen, Jordan L
Subject: Re: [edk2-devel] [RFC][PATCH 1/1] Maintainers.txt: Drop
deprecated SourceForge SVN link

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Laszlo Ersek
Sent: Thursday, June 27, 2019 7:59 PM
To: Wu, Hao A; devel@edk2.groups.io; rfc@edk2.groups.io
Cc: Gao, Liming; Andrew Fish; Leif Lindholm; Kinney, Michael D; Justen,
Jordan L
Subject: Re: [edk2-devel] [RFC][PATCH 1/1] Maintainers.txt: Drop
deprecated SourceForge SVN link

+Jordan

Hello all,

If there is no other comment, I plan to push this patch (with Laszlo's
feedback addressed) and stop the sync for the SourceForge SVN mirror.

Thanks all, patch pushed via commit 03835a8c73.

Best Regards,
Hao Wu



Best Regards,
Hao Wu



On 06/27/19 07:50, Hao A Wu wrote:
The commit will remove the deprecated edk2 SVN mirror at:
https://svn.code.sf.net/p/edk2/code/trunk/edk2

After this commit, the above minnor will not be synced with the changes
(1) s/minnor/mirror/

made in the GitHub upstream.

Cc: Liming Gao <liming.gao@...>
Cc: Andrew Fish <afish@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Leif Lindholm <leif.lindholm@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Signed-off-by: Hao A Wu <hao.a.wu@...>
---
Maintainers.txt | 1 -
1 file changed, 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index e52f044bec..e4eb37d641 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -43,7 +43,6 @@ W: http://www.tianocore.org/edk2/
L: https://edk2.groups.io/g/devel/
T: git - https://github.com/tianocore/edk2.git
T: git (mirror) - https://bitbucket.org/tianocore/edk2.git
-T: svn (read-only, deprecated) -
https://svn.code.sf.net/p/edk2/code/trunk/edk2

Tianocore Stewards
------------------
Reviewed-by: Laszlo Ersek <lersek@...>



Re: [RFC PATCH 2/3] Maintainers.txt: add wildcard path association for Arm/AArch64

Wu, Hao A
 

-----Original Message-----
From: Wu, Hao A
Sent: Wednesday, July 03, 2019 3:53 PM
To: 'Leif Lindholm'
Cc: devel@edk2.groups.io
Subject: RE: [RFC PATCH 2/3] Maintainers.txt: add wildcard path association
for Arm/AArch64

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Saturday, June 15, 2019 4:21 AM
To: devel@edk2.groups.io
Cc: Feng, Bob C; Gao, Liming; Andrew Fish; Laszlo Ersek; Kinney, Michael D;
Wu, Hao A
Subject: [RFC PATCH 2/3] Maintainers.txt: add wildcard path association for
Arm/AArch64

Add Ard and Leif as responsible for any path matching
F: */Arm/
F: */AArch64/

Signed-off-by: Leif Lindholm <leif.lindholm@...>
---
Maintainers.txt | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index cd32f9b00170..e415f51468d5 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -82,6 +82,14 @@ EDK II Releases:
W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-
Planning
M: Liming Gao <liming.gao@...>

+EDK II Architectures:
+---------------------
+ARM, AARCH64
+F: */AArch64/
+F: */Arm/

Hello Leif,

I want to confirm a couple of usage model for the wildcard character.

Maybe they have been explained with your response to Laszlo's comments,
but I just want to double-confirm with my using cases.

1. Matching multiple levels of directories

For the below 2 folders:
MdeModulePkg/Bus/Ufs/
MdeModulePkg/Bus/Pci/UfsPciHcDxe/

I can use:
MdeModulePkg/*Ufs*/

to match them all, right?


2. Matching header files (usually within the Include/ directory)

In some cases, a feature may include some drivers + some include header
files. So for the below case:
MdeModulePkg/Include/Library/HiiLib.h
MdeModulePkg/Include/Guid/HiiResourceSampleHii.h
MdeModulePkg/Universal/HiiDatabaseDxe/
MdeModulePkg/Universal/HiiResourcesSampleDxe/
MdeModulePkg/Library/UefiHiiLib/

Should I use:
MdeModulePkg/*Hii*/

to match the drivers(libraries) and the headers all or should I use:
MdeModulePkg/*Hii*/
MdeModulePkg/Include/*Hii*.h

instead?

Best Regards,
Hao Wu

Posting to the rfc list as well.

Best Regards,
Hao Wu




+M: Leif Lindholm <leif.lindholm@...>
+M: Ard Biesheuvel <ard.biesheuvel@...>
+
EDK II Packages:
----------------
ArmPkg
--
2.11.0