Date   

[edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Dandan Bi <dandan.bi@...>
 

Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler/.../ StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear and easy to maintain, 2) make platform flexible to choose any handler library they need, and it also can reduce image size since the unused handlers can be excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to cover the new NULL class library to make sure this change doesn't impact any platform.
After this separation, StatusCodeHandler module usage will like below, and it's also very flexible for platform to cover more handler libraries to meet their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf
...
}


Thanks,
Dandan


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

Samer El-Haj-Mahmoud
 

Leif,

I received additional feedback on this proposal.

We should add the UEFI Shell Specification to this new process. This includes adding a bugzilla.tianocore.org product category and a new Github repository for the "UEFI Shell Specification".

Thanks,
--Samer

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-
Haj-Mahmoud via groups.io
Sent: Wednesday, May 20, 2020 6:19 AM
To: rfc@edk2.groups.io; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>; ray.ni@...; leif@...;
devel@edk2.groups.io
Cc: Felixp@...; Doran, Mark <mark.doran@...>; Andrew Fish
<afish@...>; Laszlo Ersek <lersek@...>; Kinney, Michael D
<michael.d.kinney@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>
Subject: Re: [edk2-devel] [edk2-rfc] [RFCv2] code-first process for UEFI-forum
specifications

Are there any additional comments on the code first process for UEFI
specifications?

When should we expect the process to *actually* start being used?

Thanks,
--Samer

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Samer
El-Haj- Mahmoud via groups.io
Sent: Thursday, May 14, 2020 5:11 PM
To: rfc@edk2.groups.io; ray.ni@...; leif@...;
devel@edk2.groups.io
Cc: Felixp@...; Doran, Mark <mark.doran@...>; Andrew Fish
<afish@...>; Laszlo Ersek <lersek@...>; Kinney, Michael D
<michael.d.kinney@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>
Subject: Re: [edk2-rfc] [RFCv2] code-first process for UEFI-forum
specifications

Leif, Ray,

I have not seen any discussion on this thread since March(!)...

Please see my comments below.


-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Ni, Ray
via Groups.Io
Sent: Wednesday, March 25, 2020 1:15 AM
To: rfc@edk2.groups.io; leif@...; devel@edk2.groups.io
Cc: Felixp@...; Doran, Mark <mark.doran@...>; Andrew Fish
<afish@...>; Laszlo Ersek <lersek@...>; Kinney, Michael
D <michael.d.kinney@...>
Subject: Re: [edk2-rfc] [RFCv2] code-first process for UEFI-forum
specifications


## 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, in the Github flavour of markdown, in a file (or split
across several files) with .md suffix.
What's the case when multiple .MD files are needed?

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


## 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. But
a tag in a comment would be *highly* recommended.
If a protocol is enhanced to provide more interfaces with increased
revision number, would you like the protocol name to be prefixed
with
BZ####?
Or just the new interfaces added to the protocol are prefixed the BZ####?
I think just prefixing the new interfaces can meet the purpose.
I think pre-fixing the new interfaces is sufficient. Otherwise, you
need to modify all code using the existing interfaces (for build
verification)


But the protocol definition is changed, it also needs to be prefixed
according to this flow.
Can you clarify a bit more?
A changed protocol definition is not backwards compatible, and
typically results in a new protocol GUID. In that case, it really
becomes a new definition and need to be pre-fixed per this rule. Right?


### File names
New public header files need the prefix. I.e.
`Bz1234MyNewProtocol.h` Private header files do not need the prefix.

### Contents

The tagging must follow the coding style used by each affected codebase.
Examples:

| Released in spec | Draft version in tree | Comment |
| --- | --- | --- |
| `FunctionName` | `Bz1234FunctionName` | |
| `HEADER_MACRO` | `BZ1234_HEADER_MACRO` |
|

If FunctionName or HEADER_MACRO is defined in non-public header
files, I don't think they require the prefix. Do you agree?

For data structures or enums, any new or non-backwards-compatible
structs or fields require a prefix. As above, growing an existing
array in an existing struct requires no prefix.

| `typedef SOME_STRUCT` | `BZ1234_SOME_STRUCT` | Typedef only
[2] |
| `StructField` | `Bz1234StructField` | In existing struct[3] |
| `typedef SOME_ENUM` | `BZ1234_SOME_ENUM` | Typedef only
[2] |

[2] If the struct or enum definition is separate from the typedef
in the
public
header, the definition does not need the prefix.
What does "separate" mean?
Does it mean "struct or enum in the public header BzXXX.h don't need
the prefix"?
If yes, then I think macros defined in BzXXX.h also don't need the prefix.

[3] Individual fields in newly added typedefd struct do not need
prefix,
the
struct already carried the prefix.

Variable prefixes indicating global scope ('g' or 'm') go before
the BZ
prefix.

| `gSomeGuid` | `gBz1234SomeGuid` | |

Local identifiers, including module-global ones (m-prefixed) do
not require a BZ prefix.
I think only the names (struct type name, enum type name, interface
name, protocol/ppi name) defined in public header files need the BZ
prefix when the public header doesn't have prefix.
Right?
The way I read it, *all* new (and non-backward modified) identifiers
(typedef struct, typedef enum, and new structfield in existing struct)
need to be pre-fixed, regardless if the filename is prefixed or not.
Correct?


IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Bret Barkelew <bret.barkelew@...>
 

Rebecca,

I was able to confirm that it was an issue with Git for Windows. Looks like it’s fixed in current snapshots and will be in the next release:
https://github.com/git-for-windows/git/issues/2598

Also, ATTN: @Michael Kubacki<mailto:Michael.Kubacki@...>

- Bret

From: Bret Barkelew<mailto:Bret.Barkelew@...>
Sent: Wednesday, May 27, 2020 10:45 AM
To: Rebecca Cran<mailto:rebecca@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Andrew Fish<mailto:afish@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>; Kinney, Michael D<mailto:michael.d.kinney@...>; Leif Lindholm (Nuvia address)<mailto:leif@...>
Subject: RE: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

That’s not a bad idea: I should try with my WSL install.

I’m on the same version of Git for Windows, and think I’ll open it as an issue to the maintainer.

For now, going though the paces is just as useful to me as getting a viable environment (after all, PRs soon!), so I don’t mind trying another OS or install if that’s what it takes.

- Bret

From: Rebecca Cran<mailto:rebecca@...>
Sent: Wednesday, May 27, 2020 9:07 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Andrew Fish<mailto:afish@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>; Kinney, Michael D<mailto:michael.d.kinney@...>; Leif Lindholm (Nuvia address)<mailto:leif@...>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

On 5/27/2020 6:12 AM, Laszlo Ersek wrote:

So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git:
mine's in C:\Program Files\Git\cmd\git.exe .

It's version "git version 2.26.2.windows.1".

Of course it's possible it's just the same MINGW version that's been put
into its own installer.


I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed at
/usr/lib/git/git-send-email line 1548.


So I ended up copying it to one of my FreeBSD systems and sent it from
there.


--
Rebecca Cran


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Laszlo Ersek
 

On 05/28/20 00:07, Rebecca Cran wrote:

I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed at
/usr/lib/git/git-send-email line 1548.
That's different -- in this case, peer certificate verification was
attempted, but it failed, because the root certificate in the peer's
cert chain is not trusted by your system (your openSUSE WSL environment).

The fix for that should be identical to what you'd do on a standalone
openSUSE installation -- (1) figure out what CA cert is the root of the
peer's cert chain, and (2) decide consciously whether you trust that CA
cert to sign other certificates, (3) import said CA cert persistently
into your "store of trusted CA certs".

Examples:

(1) I think one command that works is:

$ openssl s_client -showcerts -connect HOST:PORT </dev/null

(2) up to you :)

(3a) On RHEL, this would mean copying the CA certificate under
"/etc/pki/ca-trust/source/anchors/", in PEM format, and then running the
"update-ca-trust extract" command. (Both actions need root (uid=0)
access, of course.)

(3b) For a user session (i.e., not system-wide), git-send-email also
takes "--smtp-ssl-cert-path":

--smtp-ssl-cert-path
Path to a store of trusted CA certificates for SMTP SSL/TLS
certificate validation (either a directory that has been
processed by c_rehash, or a single file containing one or
more PEM format certificates concatenated together: see
verify(1) -CAfile and -CApath for more information on
these). Set it to an empty string to disable certificate
verification. Defaults to the value of the
sendemail.smtpsslcertpath configuration variable, if set,
or the backing SSL library's compiled-in default otherwise
(which should be the best choice on most platforms).

Thanks
Laszlo


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Bret Barkelew <bret.barkelew@...>
 

That’s not a bad idea: I should try with my WSL install.

I’m on the same version of Git for Windows, and think I’ll open it as an issue to the maintainer.

For now, going though the paces is just as useful to me as getting a viable environment (after all, PRs soon!), so I don’t mind trying another OS or install if that’s what it takes.

- Bret

From: Rebecca Cran<mailto:rebecca@...>
Sent: Wednesday, May 27, 2020 9:07 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Andrew Fish<mailto:afish@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>; Kinney, Michael D<mailto:michael.d.kinney@...>; Leif Lindholm (Nuvia address)<mailto:leif@...>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

On 5/27/2020 6:12 AM, Laszlo Ersek wrote:

So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git:
mine's in C:\Program Files\Git\cmd\git.exe .

It's version "git version 2.26.2.windows.1".

Of course it's possible it's just the same MINGW version that's been put
into its own installer.


I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed at
/usr/lib/git/git-send-email line 1548.


So I ended up copying it to one of my FreeBSD systems and sent it from
there.


--
Rebecca Cran


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Andrew Fish <afish@...>
 

Rebecca,

I cheated and used smtpServer = relay.apple.com and smtpEncryption = tls. Seems relay.apple.com does not require authentication and it just worked.

I used an internal git mailing list to figure all this out, but seems the easy button was an smtpServer setup to be easy to use with git sendmail. It might be worth while to have folks reach out inside their companies to see if there are existing known good recipes?

Thanks,

Andrew Fish

On May 27, 2020, at 3:07 PM, Rebecca Cran <rebecca@...> wrote:

On 5/27/2020 6:12 AM, Laszlo Ersek wrote:

So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git: mine's in C:\Program Files\Git\cmd\git.exe .

It's version "git version 2.26.2.windows.1".

Of course it's possible it's just the same MINGW version that's been put into its own installer.


I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /usr/lib/git/git-send-email line 1548.


So I ended up copying it to one of my FreeBSD systems and sent it from there.


--
Rebecca Cran





Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Rebecca Cran
 

On 5/27/2020 6:12 AM, Laszlo Ersek wrote:

So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git: mine's in C:\Program Files\Git\cmd\git.exe .

It's version "git version 2.26.2.windows.1".

Of course it's possible it's just the same MINGW version that's been put into its own installer.


I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /usr/lib/git/git-send-email line 1548.


So I ended up copying it to one of my FreeBSD systems and sent it from there.


--
Rebecca Cran


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Laszlo Ersek
 

On 05/27/20 03:52, Bret Barkelew wrote:
So, today I followed the Wiki (that I had never seen) and now I’m staring down the barrel of this fellow…
[cid:image002.png@...]

[Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL.
To use SSL please install IO::Socket::SSL with version>=2.007 at /usr/share/perl5/core_perl/Net/SMTP.pm line 270.]

Anyone have thoughts? I’mma go get a scotch.
I think your perl installation and your git installation may come from
different sources, and the perl install may not satisfy the git
install's dependencies.

In GNU/Linux distribution lingo, I'd call this either a distribution
error, or (maybe more precisely) a git package error. Normally the git
package should spell out the pre-requisite package names, along with the
minimum required package version(s). And the package manager should
enforce that, when installing git.

Other people appear to have encountered a similiar issue before:

https://github.com/Homebrew/homebrew-core/issues/24210#issuecomment-366831944

https://github.com/msys2/MSYS2-packages/issues/1152

https://bugs.archlinux.org/task/54326

https://bugs.archlinux.org/task/62948


When I check on my laptop now, I see:

$ rpm --query --requires git-email
[...]
perl(Net::SMTP::SSL)
[...]

and recursively,

$ rpm --query --requires perl-Net-SMTP-SSL
[...]
perl(IO::Socket::SSL)
[...]

In other words, whenever it was that I ran "yum install git-email" (for
gaining access to the "git-send-email" command), yum made sure that
"perl-Net-SMTP-SSL" and "perl-IO-Socket-SSL" would both be pulled in.

(Assuming the RPM spec files spelled out minimum versions on the
dependencies, yum would enforce those particular versions too.)

So, it could be a MINGW64 packaging bug, perhaps.

Thanks,
Laszlo


Re: PKCS7 Authenticated Variable Enrollment

Guomin Jiang
 

I am sorry that I have not the use case, and I plan to investigating it after August.

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of
divneil.r.wadhawan@...
Sent: Wednesday, May 27, 2020 6:54 PM
To: Jiang, Guomin <guomin.jiang@...>; rfc@edk2.groups.io
Subject: Re: [edk2-rfc] PKCS7 Authenticated Variable Enrollment

Hi Goumin,

I had discussion internally, and I got hold off tools from:
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per
EFI_VARIABLE_AUTHENTICATION_2.

So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which uses
PKCS7 format and PKCS7_verify works?

Regards,
Divneil


Re: PKCS7 Authenticated Variable Enrollment

Wadhawan, Divneil R
 

Hi Goumin,

I had discussion internally, and I got hold off tools from: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per EFI_VARIABLE_AUTHENTICATION_2.

So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which uses PKCS7 format and PKCS7_verify works?

Regards,
Divneil


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Tomas Pilar (tpilar)
 

This will probably be down to the [send-email] section of git config, do you have smtpEncryption enabled by any chance?

You could also try updating the required package:
perl -MCPAN -e 'install "IO::Socket::SSL"'

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret Barkelew via groups.io
Sent: 27 May 2020 02:53
To: Andrew Fish <afish@...>; Laszlo Ersek <lersek@...>
Cc: devel@edk2.groups.io; spbrogan@...; rfc@edk2.groups.io; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Kinney, Michael D <michael.d.kinney@...>; Leif Lindholm (Nuvia address) <leif@...>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

So, today I followed the Wiki (that I had never seen) and now I'm staring down the barrel of this fellow...
[cid:image001.png@...]

[Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL.
To use SSL please install IO::Socket::SSL with version>=2.007 at /usr/share/perl5/core_perl/Net/SMTP.pm line 270.]

Anyone have thoughts? I'mma go get a scotch.

- Bret

From: Andrew Fish<mailto:afish@...>
Sent: Monday, May 25, 2020 11:28 AM
To: Laszlo Ersek<mailto:lersek@...>
Cc: Bret Barkelew<mailto:Bret.Barkelew@...>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>; Kinney, Michael D<mailto:michael.d.kinney@...>; Leif Lindholm (Nuvia address)<mailto:leif@...>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process



On May 25, 2020, at 11:10 AM, Laszlo Ersek <lersek@...<mailto:lersek@...>> wrote:

Hi Andrew,

On 05/25/20 06:09, Andrew Fish wrote:

I also found I had to Bing/Google to find the detailed instructions I
needed as a developer, as the Wiki seems to assume you just know the
Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; please disregard my message below in
that case).

I wrote the following wiki article originally in 2016:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FLaszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers&;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C2e084613c24f433ca0a508d800d978de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260281325061578&amp;sdata=nIMHQLnu8F%2F%2BTMMsLKVXbWnO6AWE9WuUu5k1TK4HgTQ%3D&amp;reserved=0

I wrote it specifically for developers & maintainers with no (or almost
no) prior git / mailing list experience. Multiple developers confirmed
later that the article had helped them.
Laszlo,

Your wiki article was very very helpful. I just could not find it from the Tianocre wiki. It would be good if we could link to it from here [1], maybe as add to this: "Are you new to using git? If so, then the New to git page may be helpful."?

There are a lot folks who use git but don't use the email based review so they have never setup git with emali before. Your wiki, plus me figuring out the magic internal SMTP reflector (I reached out on an internal git malling list) is what got me unblocked.

[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Development-Process&;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C2e084613c24f433ca0a508d800d978de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260281325061578&amp;sdata=XPx6jrloPC9LW0iCecZuFmaz3JgjCSQYeF0PEyGW4I0%3D&amp;reserved=0

Thanks,

Andrew Fish

Thanks
Laszlo

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Bret Barkelew <bret.barkelew@...>
 

So, today I followed the Wiki (that I had never seen) and now I’m staring down the barrel of this fellow…
[cid:image002.png@...]

[Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL.
To use SSL please install IO::Socket::SSL with version>=2.007 at /usr/share/perl5/core_perl/Net/SMTP.pm line 270.]

Anyone have thoughts? I’mma go get a scotch.

- Bret

From: Andrew Fish<mailto:afish@...>
Sent: Monday, May 25, 2020 11:28 AM
To: Laszlo Ersek<mailto:lersek@...>
Cc: Bret Barkelew<mailto:Bret.Barkelew@...>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>; Kinney, Michael D<mailto:michael.d.kinney@...>; Leif Lindholm (Nuvia address)<mailto:leif@...>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process



On May 25, 2020, at 11:10 AM, Laszlo Ersek <lersek@...> wrote:

Hi Andrew,

On 05/25/20 06:09, Andrew Fish wrote:

I also found I had to Bing/Google to find the detailed instructions I
needed as a developer, as the Wiki seems to assume you just know the
Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; please disregard my message below in
that case).

I wrote the following wiki article originally in 2016:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FLaszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers&;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C2e084613c24f433ca0a508d800d978de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260281325061578&amp;sdata=nIMHQLnu8F%2F%2BTMMsLKVXbWnO6AWE9WuUu5k1TK4HgTQ%3D&amp;reserved=0

I wrote it specifically for developers & maintainers with no (or almost
no) prior git / mailing list experience. Multiple developers confirmed
later that the article had helped them.
Laszlo,

Your wiki article was very very helpful. I just could not find it from the Tianocre wiki. It would be good if we could link to it from here [1], maybe as add to this: "Are you new to using git? If so, then the New to git page may be helpful."?

There are a lot folks who use git but don't use the email based review so they have never setup git with emali before. Your wiki, plus me figuring out the magic internal SMTP reflector (I reached out on an internal git malling list) is what got me unblocked.

[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Development-Process&;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C2e084613c24f433ca0a508d800d978de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260281325061578&amp;sdata=XPx6jrloPC9LW0iCecZuFmaz3JgjCSQYeF0PEyGW4I0%3D&amp;reserved=0

Thanks,

Andrew Fish

Thanks
Laszlo


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Bret Barkelew <bret.barkelew@...>
 

Samer,

Have you had a chance to review Mike’s PR process? Any thoughts as comparison?

- Bret
________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Samer El-Haj-Mahmoud via groups.io <samer.el-haj-mahmoud@...>
Sent: Tuesday, May 26, 2020 7:39:55 AM
To: rfc@edk2.groups.io <rfc@edk2.groups.io>; lersek@... <lersek@...>; Andrew Fish <afish@...>
Cc: Bret Barkelew <Bret.Barkelew@...>; devel@edk2.groups.io <devel@edk2.groups.io>; spbrogan@... <spbrogan@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Kinney, Michael D <michael.d.kinney@...>; Leif Lindholm (Nuvia address) <leif@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

I agree with Andrew. I also found Laszlo's "unkempt guide" very useful. In addition, there is a short page by Peter Batard that adds more details on the commits validation, patchset generation, and e-mail submission: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fpbatard%2Fec1c9d1dd6e7144b07a09b057b1735a8&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdca587d1198049354a6f08d80182b15a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261008123224059&amp;sdata=e%2Bk1gQubOWY8gWlQAUAmjIIaqQMv6p%2FMqjUHcntVm1g%3D&amp;reserved=0


-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek
via groups.io
Sent: Tuesday, May 26, 2020 7:18 AM
To: Andrew Fish <afish@...>
Cc: Bret Barkelew <Bret.Barkelew@...>; devel@edk2.groups.io;
spbrogan@...; rfc@edk2.groups.io; Desimone, Nathaniel L
<nathaniel.l.desimone@...>; Mike Kinney
<michael.d.kinney@...>; Leif Lindholm (Nuvia address)
<leif@...>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based
Code Review Process

On 05/25/20 20:28, Andrew Fish wrote:


On May 25, 2020, at 11:10 AM, Laszlo Ersek <lersek@...> wrote:

Hi Andrew,

On 05/25/20 06:09, Andrew Fish wrote:

I also found I had to Bing/Google to find the detailed instructions
I needed as a developer, as the Wiki seems to assume you just know
the Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; please disregard my message below in
that case).

I wrote the following wiki article originally in 2016:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FLaszlo%27s-unkemp&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdca587d1198049354a6f08d80182b15a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261008123224059&amp;sdata=hwAXd7kabi4mQyTEr7AWlEyA4yHDkdwG8zr1lirgmA4%3D&amp;reserved=0
t-git-guide-for-edk2-contributors-and-maintainers

I wrote it specifically for developers & maintainers with no (or
almost
no) prior git / mailing list experience. Multiple developers
confirmed later that the article had helped them.
Laszlo,

Your wiki article was very very helpful. I just could not find it from the
Tianocre wiki. It would be good if we could link to it from here [1], maybe as
add to this: "Are you new to using git? If so, then the New to git page may be
helpful."?

The article at [1] is an official document, while the "unkempt guide" is not
official. The unkempt guide starts by deferring to [1]. I didn't think the official
document should point to my unofficial one, and/or we should create a loop
of links.

That said, if someone else updates [1] with a pointer, I won't protest.
That's just something that I (having authored the unkempt guide) would not
propose myself.

I do agree that the wiki search facilities on github are basic. What has mostly
worked for me is clicking the Pages arrow, and then entering a *very simple*
search term in the drop-down search box. For example, if I do that now, and
only enter "git", then the "unkempt guide" is listed (with other hits of
course). I think this search box is basically for searching article titles.


There are a lot folks who use git but don't use the email based review so
they have never setup git with emali before. Your wiki, plus me figuring out
the magic internal SMTP reflector (I reached out on an internal git malling list)
is what got me unblocked.

It's great that you have access to such infrastructure at Apple!

Thanks!
Laszlo



[1]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Developme&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdca587d1198049354a6f08d80182b15a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261008123234063&amp;sdata=UqY5uoxqMamf5PkFLOJ20YKE1aWTZRqGnEYuK93AxiA%3D&amp;reserved=0
nt-Process

Thanks,

Andrew Fish

Thanks
Laszlo

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Tomas Pilar (tpilar)
 

I actually agree with you, when we migrated from reviewboard to github pull requests, I was sorely disappointed with the PR functionality and ergonomics.

Tomas Pilar

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Rebecca Cran via groups.io
Sent: 14 May 2020 22:47
To: rfc@edk2.groups.io; bret.barkelew@...; Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; lersek@...
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

On 5/14/20 3:26 PM, Bret Barkelew via groups.io wrote:

I feel like this process is a good compromise. It�s not perfect (frankly, I�m a fan of enforced squash merges, which can maintain bisectability if managed well), but it allows for rapid iteration, ease of contribution, and approaches the workflow that many who have never used email to maintain a project would be familiar with.

It�s code management for the Instagram generation, and I for one welcome our new insect overlords.
Or at least, that's what Microsoft is betting on! :D

Personally, I remain unconvinced about the usability of Github Pull Requests for a project the size of EDK2, but I hope to be proven wrong.


--
Rebecca Cran





IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Samer El-Haj-Mahmoud
 

I agree with Andrew. I also found Laszlo's "unkempt guide" very useful. In addition, there is a short page by Peter Batard that adds more details on the commits validation, patchset generation, and e-mail submission: https://gist.github.com/pbatard/ec1c9d1dd6e7144b07a09b057b1735a8

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek
via groups.io
Sent: Tuesday, May 26, 2020 7:18 AM
To: Andrew Fish <afish@...>
Cc: Bret Barkelew <Bret.Barkelew@...>; devel@edk2.groups.io;
spbrogan@...; rfc@edk2.groups.io; Desimone, Nathaniel L
<nathaniel.l.desimone@...>; Mike Kinney
<michael.d.kinney@...>; Leif Lindholm (Nuvia address)
<leif@...>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based
Code Review Process

On 05/25/20 20:28, Andrew Fish wrote:


On May 25, 2020, at 11:10 AM, Laszlo Ersek <lersek@...> wrote:

Hi Andrew,

On 05/25/20 06:09, Andrew Fish wrote:

I also found I had to Bing/Google to find the detailed instructions
I needed as a developer, as the Wiki seems to assume you just know
the Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; please disregard my message below in
that case).

I wrote the following wiki article originally in 2016:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkemp
t-git-guide-for-edk2-contributors-and-maintainers

I wrote it specifically for developers & maintainers with no (or
almost
no) prior git / mailing list experience. Multiple developers
confirmed later that the article had helped them.
Laszlo,

Your wiki article was very very helpful. I just could not find it from the
Tianocre wiki. It would be good if we could link to it from here [1], maybe as
add to this: "Are you new to using git? If so, then the New to git page may be
helpful."?

The article at [1] is an official document, while the "unkempt guide" is not
official. The unkempt guide starts by deferring to [1]. I didn't think the official
document should point to my unofficial one, and/or we should create a loop
of links.

That said, if someone else updates [1] with a pointer, I won't protest.
That's just something that I (having authored the unkempt guide) would not
propose myself.

I do agree that the wiki search facilities on github are basic. What has mostly
worked for me is clicking the Pages arrow, and then entering a *very simple*
search term in the drop-down search box. For example, if I do that now, and
only enter "git", then the "unkempt guide" is listed (with other hits of
course). I think this search box is basically for searching article titles.


There are a lot folks who use git but don't use the email based review so
they have never setup git with emali before. Your wiki, plus me figuring out
the magic internal SMTP reflector (I reached out on an internal git malling list)
is what got me unblocked.

It's great that you have access to such infrastructure at Apple!

Thanks!
Laszlo



[1]
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developme
nt-Process

Thanks,

Andrew Fish

Thanks
Laszlo

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Laszlo Ersek
 

On 05/25/20 20:28, Andrew Fish wrote:


On May 25, 2020, at 11:10 AM, Laszlo Ersek <lersek@...> wrote:

Hi Andrew,

On 05/25/20 06:09, Andrew Fish wrote:

I also found I had to Bing/Google to find the detailed instructions I
needed as a developer, as the Wiki seems to assume you just know the
Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; please disregard my message below in
that case).

I wrote the following wiki article originally in 2016:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

I wrote it specifically for developers & maintainers with no (or almost
no) prior git / mailing list experience. Multiple developers confirmed
later that the article had helped them.
Laszlo,

Your wiki article was very very helpful. I just could not find it from the Tianocre wiki. It would be good if we could link to it from here [1], maybe as add to this: "Are you new to using git? If so, then the New to git page may be helpful."?
The article at [1] is an official document, while the "unkempt guide" is
not official. The unkempt guide starts by deferring to [1]. I didn't
think the official document should point to my unofficial one, and/or we
should create a loop of links.

That said, if someone else updates [1] with a pointer, I won't protest.
That's just something that I (having authored the unkempt guide) would
not propose myself.

I do agree that the wiki search facilities on github are basic. What has
mostly worked for me is clicking the Pages arrow, and then entering a
*very simple* search term in the drop-down search box. For example, if I
do that now, and only enter "git", then the "unkempt guide" is listed
(with other hits of course). I think this search box is basically for
searching article titles.


There are a lot folks who use git but don't use the email based review so they have never setup git with emali before. Your wiki, plus me figuring out the magic internal SMTP reflector (I reached out on an internal git malling list) is what got me unblocked.
It's great that you have access to such infrastructure at Apple!

Thanks!
Laszlo



[1] https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

Thanks,

Andrew Fish

Thanks
Laszlo


[RFC]: StandAloneMM in OP-TEE

Sahil Malhotra <sahil.malhotra@...>
 

Hi All,


We are working on enabling the Secure Storage of Variables for Secure UEFI.

Let me give you a brief idea of what we are doing.

 

We need StandAlone Management Mode to run in the Secure Environment.

For that in EDK2 we already have the MmCommunicationDxe Runtime Driver which communicates with StMM running in Secure Partition in Secure World.

But this driver is based on SPM (Secure Partition Manager) running in the ATF.

 

As we are aware that ATF can run either in SPM mode or SPD mode, Both are mutually exclusive.

So we cannot have both the StMM running in Secure Partition as well as OP-TEE or any other Secure OS running in Secure World.

 

On many systems, there are many other secure operations needed to be done that can be done by Secure OS only.

So in these systems we need to make the StMM and Secure OS work together.

 

As part of doing this only, we have created a kind of Secure Partition within OP-TEE in which StMM can work as a kind of TA, and other TAs cannot interfere with the working of this Secure Partition.

Other TAs can run in parallel to StMM on top of OP-TEE, We can get the work done by StMM by OP-TEE SMC calls only.

It will be like this as shown in the below image.

 

                                                     Secure World

+-----------------------------------------------------------+

|   +-----------------------+    +------------------------+ |

|   |                       |    | +--------------------+ | |

|   |                       |    | |                    | | |

|   |   Trusted Application |    | |                    | | |

|   |                       |    | |                    | | |

|   |                       |    | |      StMM          | | |

|   +-----------------------+    | |                    | | |

|                                | |                    | | |

|                                | |                    | | |

|                                | +--------------------+ | |

|                                |                        | |

|                  OP-TEE        |                        | |

|                                |                        | |

|                                |     Secure Partition   | |

|                                |                        | |

|                                |                        | |

|                                |                        | |

|                                +------------------------+ |

+-----------------------------------------------------------+

 

So with this approach of running StMM in an exclusive secure partition with OP-TEE, StMM and TAs can work together.

In this way StMM binary which is compiled is also environment-agnostic, Same StMM binary can work whether it is running as part of OP-TEE or Standalone in Secure Word.

If OP-TEE is responsible for running StMM, firmware implementations, like U-Boot, can use it to store UEFI variables.


Now for implementing the whole system of Secure Variable Storage for Secure UEFI.

 

We need to make changes in MmCommunicationDxe Runtime Driver and OpteeLib

Let's discuss one by one the changes:

  • MmCommunicationDxe – Currently it is based on SPM SMC calls that get landed into ATF and do the required work.
    • Now since StMM is running as part of OP-TEE, we need to change these into OP-TEE SMC calls.
  • OpteeLib – Currently OpteeLib cannot be used with the Runtime Drivers.
    • We need to change its configuration so that it can be used with a Runtime Driver.

 

So for making these changes we have following approaches:

  • MmCommunicationDxe
    • We can have the code for SPM SMC calling and OPTEE SMC calling in the same driver under some compile time flags, but it will make the code nasty.
    • Another approach can be writing a new driver under the name of MmCommunicationOpteeDxe in ArmPkg/Drivers/.
  • OpteeLib
    • We can make necessary changes to make it work with Runtime Driver.
    • Other approach we can make Runtime Driver of Optee also in ArmPkg/Drivers/

 

So please review the mail and approaches for making the changes and let us know your views.


Regards,

Sahil Malhotra


Re: PKCS7 Authenticated Variable Enrollment

Guomin Jiang
 

Hi Wadhawan,

I will check it after August because I am busy recently.

Best Regards
Guomin

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Wadhawan,
Divneil R
Sent: Friday, May 1, 2020 2:19 AM
To: rfc@edk2.groups.io
Cc: Wadhawan, Divneil R <divneil.r.wadhawan@...>
Subject: [edk2-rfc] PKCS7 Authenticated Variable Enrollment

Hi,

I am trying to test if the enrollment of Authenticated Variables is possible
with verification of signature with different key sizes.
File: AuthService.c :: Function: VerifyTimeBasedPayload() -> Pkcs7Verify() So,
to achieve that, I did the following:

a. Generate the KEK.auth
uuidgen --random > GUID.txt

openssl req -newkey rsa:3072 -nodes -keyout PK.key -new -x509 -sha384 -
days 3650 -subj "/CN=my Platform Key/" -out PK.crt
openssl x509 -outform DER -in PK.crt -out PK.cer

openssl req -newkey rsa:3072 -nodes -keyout KEK.key -new -x509 -sha384
-days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
openssl x509 -outform DER -in KEK.crt -out KEK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

b. Enroll PK.cer from BIOS menu in custom mode

c. Hack the KEK enrollment connected to BIOS Menu (HII interface) and
disable custom mode and then gRT->SetVariable() on input data
File: SecureBootConfigImpl.c :: Function: EnrollKeyExchangeKey()

I found that the KEK.auth format is rejected by VerifyTimeBasedPayload() in
(CompareMem (SigData + 13, &mSha256OidValue, sizeof
(mSha256OidValue)) != 0)) {

So, I did a hexdump of KEK.auth and could see that data is not as expected.
Here's the dump I have of KEK.auth

//EFI_Time (16 bytes)
0000000 e5 07 03 10 0e 39 00 00 00 00 00 00 00 00 00 00

// WIN_CERTIFICATE_UEFI_GUID (16bytes + 8bytes) // SigData starts at value
0x30 post WIN_CERTIFICATE_UEFI_GUID. At offset of 13 from 0x30 the code
expects sha256 OID
0000020 0e 07 00 00 00 02 f1 0e 9d d2 af 4a df 68 ee 49
0000040 8a a9 34 7d 37 56 65 a7 30 82 06 f2 06 09 2a 86

0000060 48 86 f7 0d 01 07 02 a0 82 06 e3 30 82 06 df 02

// sha256 oid starts from here: 60 86 48 01 65 03 04 02 (last 8 bytes + 1byte in
next line)
0000100 01 01 31 0f 30 0d 06 09 60 86 48 01 65 03 04 02
0000120 01 05 00 30 0b 06 09 2a 86 48 86 f7 0d 01 07 01

So, the sha256 oid is present but is at a far away offset. Can you please help
in identifying the problem component.
I also wanted to talk about the oid value of sha256 present, where as sha384
is used.
The above data dump is same in terms of offset for RSA2048/SHA256
KEK.auth I have based this method on the understanding that, if we have
some OS interface to set the variables, it will pass the KEK.auth directly into
gRT->SetVariable().

Regards,
Divneil


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Andrew Fish <afish@...>
 

On May 25, 2020, at 11:10 AM, Laszlo Ersek <lersek@...> wrote:

Hi Andrew,

On 05/25/20 06:09, Andrew Fish wrote:

I also found I had to Bing/Google to find the detailed instructions I
needed as a developer, as the Wiki seems to assume you just know the
Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; please disregard my message below in
that case).

I wrote the following wiki article originally in 2016:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

I wrote it specifically for developers & maintainers with no (or almost
no) prior git / mailing list experience. Multiple developers confirmed
later that the article had helped them.
Laszlo,

Your wiki article was very very helpful. I just could not find it from the Tianocre wiki. It would be good if we could link to it from here [1], maybe as add to this: "Are you new to using git? If so, then the New to git page may be helpful."?

There are a lot folks who use git but don't use the email based review so they have never setup git with emali before. Your wiki, plus me figuring out the magic internal SMTP reflector (I reached out on an internal git malling list) is what got me unblocked.

[1] https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

Thanks,

Andrew Fish

Thanks
Laszlo


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Laszlo Ersek
 

Hi Andrew,

On 05/25/20 06:09, Andrew Fish wrote:

I also found I had to Bing/Google to find the detailed instructions I
needed as a developer, as the Wiki seems to assume you just know the
Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; please disregard my message below in
that case).

I wrote the following wiki article originally in 2016:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

I wrote it specifically for developers & maintainers with no (or almost
no) prior git / mailing list experience. Multiple developers confirmed
later that the article had helped them.

Thanks
Laszlo

441 - 460 of 789