Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support NuGet.org and ApiKey authentication #2

Merged
merged 1 commit into from
Oct 9, 2018

Conversation

spbrogan
Copy link
Member

@spbrogan spbrogan commented Oct 9, 2018

Update details for Public packages

Update details for Public packages
@spbrogan
Copy link
Member Author

spbrogan commented Oct 9, 2018

This should resolve microsoft/mu#28

@spbrogan spbrogan merged commit 7a314c5 into release/20180529 Oct 9, 2018
@spbrogan spbrogan deleted the personal/sebrogan/nugetupdates branch October 9, 2018 03:23
corthon pushed a commit that referenced this pull request Oct 15, 2018
Update details for Public packages
corthon pushed a commit that referenced this pull request Jan 22, 2019
1) Add a new file Common/caching.py
    a.	Allows for automated caching of repeated class functions, class
        properties, and non-class functions
    b.	When called the first time the value is cached and if called a
        second time, the cached result is called, not the function.
    c.	When used, this saves lots of memory since the actual function
        pointers are replaced with smaller data elements.
    d.  note that not all features are used yet.
2) Fix AutoGen/GenMake and AutoGen/GetC to not call into private member
    variables of ModuleAutoGen class
    a. use the existing accessor properties for the data
3) Change AutoGen classes to remove a exception for duplicate members in
    __new__ and use ?in? testing to speed up
4)	Work on ModuleAutoGen class
    a.	Change all properties that use caching to use @caching_property
        (see #1 above)
    b.	Change all properties that do not use caching to use standard python
        decorator "@Property"
    c.	Change all cases where a dictionary/set/list/object was created
        and then immediately updated to use constructor parameters
    d.	Refactor each property function to remove the internal variable
        that is no longer needed (this helps find items like #2 above)
    e.  Refactor _ApplyBuildRule with optional parameter to work around
        circular dependency with BinaryFileList.

Note that 4e was almost certainly unintended as the functions were acting on
incomplete information since they were directly accessing private instance
variables at the same time another function on the stack was creating the same
private isntance data.

This overall changes behavior slightly, but makes the codebase smaller and
easier to read.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
corthon pushed a commit that referenced this pull request Jan 22, 2019
Update details for Public packages
corthon pushed a commit that referenced this pull request Mar 20, 2019
Update details for Public packages
corthon pushed a commit that referenced this pull request Mar 20, 2019
Update details for Public packages
corthon pushed a commit that referenced this pull request Mar 20, 2019
Update details for Public packages
corthon pushed a commit that referenced this pull request Mar 21, 2019
Update details for Public packages
corthon pushed a commit that referenced this pull request Nov 21, 2019
MpInitLib sets X2ApicEnable in two places.
1. CollectProcessorCount()
   This function is called when MpInitLibInitialize() hasn't been
   called before.
   It sets X2ApicEnable and later in the same function it configures
   all CPUs to operate in X2 APIC mode.
2. MpInitLibInitialize()
   The X2ApicEnable setting happens when this function is called in
   second time. But after that setting, no code consumes that flag.

With the above analysis and with the purpose of simplifying the code,
the X2ApicEnable in #1 is changed to local variable and the #2 can be
changed to remove the setting of X2ApicEnable.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
corthon pushed a commit that referenced this pull request Sep 7, 2021
MpInitLib contains a function MicrocodeDetect() which is called by
all threads as an AP procedure.
Today this function contains below code:

    if (CurrentRevision != LatestRevision) {
      AcquireSpinLock(&CpuMpData->MpLock);
      DEBUG ((
        EFI_D_ERROR,
        "Updated microcode signature [0x%08x] does not match \
        loaded microcode signature [0x%08x]\n",
        CurrentRevision, LatestRevision
        ));
      ReleaseSpinLock(&CpuMpData->MpLock);
    }

When the if-check is passed, the code may call into PEI services:
1. AcquireSpinLock
   When the PcdSpinTimeout is not 0, TimerLib
   GetPerformanceCounterProperties() is called. And some of the
   TimerLib implementations would get the information cached in
   HOB. But AP procedure cannot call PEI services to retrieve the
   HOB list.

2. DEBUG
   Certain DebugLib relies on ReportStatusCode services and the
   ReportStatusCode PPI is retrieved through the PEI services.
   DebugLibSerialPort should be used.
   But when SerialPortLib is implemented to depend on PEI services,
   even using DebugLibSerialPort can still cause AP calls PEI
   services resulting hang.

It causes a lot of debugging effort on the platform side.

There are 2 options to fix the problem:
1. make sure platform DSC chooses the proper DebugLib and set the
   PcdSpinTimeout to 0. So that AcquireSpinLock and DEBUG don't call
   PEI services.
2. remove the AcquireSpinLock and DEBUG call from the procedure.

Option #2 is preferred because it's not practical to ask every
platform DSC to be written properly.

Following option #2, there are two sub-options:
2.A. Just remove the if-check.
2.B. Capture the CurrentRevision and ExpectedRevision in the memory
     for each AP and print them together from BSP.

The patch follows option 2.B.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
kenlautner pushed a commit that referenced this pull request Sep 13, 2022
The AP vector consists of 2 parts:
1. the initial 16-bit code that should be under 1MB and page aligned.
2. the 32-bit/64-bit code that can be anywhere in the memory with any
   alignment.

The need of part #2 is because the memory under 1MB is temporary
"stolen" for use and will "give" back after all AP wake up. The range
of memory is not marked as code page in page table. CPU may trigger
exception as soon as NX is enabled.

The part #2 memory allocation can be done in the MpInitLibInitialize.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Javagedes added a commit that referenced this pull request Jun 14, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
kenlautner pushed a commit that referenced this pull request Oct 17, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
kenlautner pushed a commit that referenced this pull request Oct 17, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
kenlautner pushed a commit that referenced this pull request Oct 18, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
kenlautner pushed a commit that referenced this pull request Oct 18, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
kenlautner pushed a commit that referenced this pull request Oct 19, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
kenlautner pushed a commit that referenced this pull request Oct 20, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
kenlautner pushed a commit that referenced this pull request Oct 23, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
kenlautner pushed a commit that referenced this pull request Dec 16, 2023
Root cause:
1. Before DisableReadonlyPageWriteProtect() is called, the return
address (#1) is pushed in shadow stack.
2. CET is disabled.
3. DisableReadonlyPageWriteProtect() returns to #1.
4. Page table is modified.
5. EnableReadonlyPageWriteProtect() is called, but the return
address (#2) is not pushed in shadow stack.
6. CET is enabled.
7. EnableReadonlyPageWriteProtect() returns to #2.
#CP exception happens because the actual return address (#2)
doesn't match the return address stored in shadow stack (#1).

Analysis:
Shadow stack will stop update after CET disable (DisableCet() in
DisableReadOnlyPageWriteProtect), but normal smi stack will be
continue updated with the function called and return
(DisableReadOnlyPageWriteProtect & EnableReadOnlyPageWriteProtect),
thus leading stack mismatch after CET re-enabled (EnableCet() in
EnableReadOnlyPageWriteProtect).

According SDM Vol 3, 6.15-Control Protection Exception:
Normal smi stack and shadow stack must be matched when CET enable,
otherwise CP Exception will happen, which is caused by a near RET
instruction.

CET is disabled in DisableCet(), while can be enabled in
EnableCet(). This way won't cause the problem because they are
implemented in a way that return address of DisableCet() is
poped out from shadow stack (Incsspq performs a pop to increases
the shadow stack) and EnableCet() doesn't use "RET" but "JMP" to
return to caller. So calling EnableCet() and DisableCet() doesn't
have the same issue as calling DisableReadonlyPageWriteProtect()
and EnableReadonlyPageWriteProtect().

With above root cause & analysis, define below 2 macros instead of
functions for WP & CET operation:
WRITE_UNPROTECT_RO_PAGES (Wp, Cet)
WRITE_PROTECT_RO_PAGES (Wp, Cet)
Because DisableCet() & EnableCet() must be in the same function
to avoid shadow stack and normal SMI stack mismatch.

Note: WRITE_UNPROTECT_RO_PAGES () must be called pair with
WRITE_PROTECT_RO_PAGES () in same function.

Change-Id: I4e126697efcd8dbfb4887da034d8691bfca969e3
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
kenlautner pushed a commit that referenced this pull request Dec 16, 2023
## Description

Ensures LIBRARY_CLASS as specified in the library override INF defines
section is the same value as the library class specified in the override
line.

## Example of mismatch
``` cmd
ERROR - EDK2 #2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib]
```

closes #314

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

Ensured mismatched library override was caught, and INF's with multiple
LIBRARY_CLASS definitions will not raise an error if one of the
definitions matches.

## Integration Instructions

N/A
os-d pushed a commit to os-d/mu_basecore that referenced this pull request Jun 3, 2024
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535

Bug Details:
PixieFail Bug microsoft#2
CVE-2023-45230
CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
CWE-119 Improper Restriction of Operations within the Bounds
 of a Memory Buffer

Changes Overview:
> -UINT8 *
> +EFI_STATUS
>  Dhcp6AppendOption (
> -  IN OUT UINT8   *Buf,
> -  IN     UINT16  OptType,
> -  IN     UINT16  OptLen,
> -  IN     UINT8   *Data
> +  IN OUT EFI_DHCP6_PACKET  *Packet,
> +  IN OUT UINT8             **PacketCursor,
> +  IN     UINT16            OptType,
> +  IN     UINT16            OptLen,
> +  IN     UINT8             *Data
>    );

Dhcp6AppendOption() and variants can return errors now.  All callsites
are adapted accordingly.

It gets passed in EFI_DHCP6_PACKET as additional parameter ...

> +  //
> +  // Verify the PacketCursor is within the packet
> +  //
> +  if (  (*PacketCursor < Packet->Dhcp6.Option)
> +     || (*PacketCursor >= Packet->Dhcp6.Option +
 (Packet->Size - sizeof (EFI_DHCP6_HEADER))))
> +  {
> +    return EFI_INVALID_PARAMETER;
> +  }

... so it can look at Packet->Size when checking buffer space.
Also to allow Packet->Length updates.

Lots of checks added.

Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>

Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
Flickdm pushed a commit that referenced this pull request Jun 17, 2024
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535

Bug Details:
PixieFail Bug #2
CVE-2023-45230
CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
CWE-119 Improper Restriction of Operations within the Bounds
 of a Memory Buffer

Changes Overview:
> -UINT8 *
> +EFI_STATUS
>  Dhcp6AppendOption (
> -  IN OUT UINT8   *Buf,
> -  IN     UINT16  OptType,
> -  IN     UINT16  OptLen,
> -  IN     UINT8   *Data
> +  IN OUT EFI_DHCP6_PACKET  *Packet,
> +  IN OUT UINT8             **PacketCursor,
> +  IN     UINT16            OptType,
> +  IN     UINT16            OptLen,
> +  IN     UINT8             *Data
>    );

Dhcp6AppendOption() and variants can return errors now.  All callsites
are adapted accordingly.

It gets passed in EFI_DHCP6_PACKET as additional parameter ...

> +  //
> +  // Verify the PacketCursor is within the packet
> +  //
> +  if (  (*PacketCursor < Packet->Dhcp6.Option)
> +     || (*PacketCursor >= Packet->Dhcp6.Option +
 (Packet->Size - sizeof (EFI_DHCP6_HEADER))))
> +  {
> +    return EFI_INVALID_PARAMETER;
> +  }

... so it can look at Packet->Size when checking buffer space.
Also to allow Packet->Length updates.

Lots of checks added.

Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>

Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
Flickdm pushed a commit that referenced this pull request Jun 17, 2024
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535

Bug Details:
PixieFail Bug #2
CVE-2023-45230
CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
CWE-119 Improper Restriction of Operations within the Bounds
 of a Memory Buffer

Changes Overview:
> -UINT8 *
> +EFI_STATUS
>  Dhcp6AppendOption (
> -  IN OUT UINT8   *Buf,
> -  IN     UINT16  OptType,
> -  IN     UINT16  OptLen,
> -  IN     UINT8   *Data
> +  IN OUT EFI_DHCP6_PACKET  *Packet,
> +  IN OUT UINT8             **PacketCursor,
> +  IN     UINT16            OptType,
> +  IN     UINT16            OptLen,
> +  IN     UINT8             *Data
>    );

Dhcp6AppendOption() and variants can return errors now.  All callsites
are adapted accordingly.

It gets passed in EFI_DHCP6_PACKET as additional parameter ...

> +  //
> +  // Verify the PacketCursor is within the packet
> +  //
> +  if (  (*PacketCursor < Packet->Dhcp6.Option)
> +     || (*PacketCursor >= Packet->Dhcp6.Option +
 (Packet->Size - sizeof (EFI_DHCP6_HEADER))))
> +  {
> +    return EFI_INVALID_PARAMETER;
> +  }

... so it can look at Packet->Size when checking buffer space.
Also to allow Packet->Length updates.

Lots of checks added.

Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>

Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
apop5 pushed a commit to apop5/mu_basecore that referenced this pull request Jan 2, 2025
This patch does not impact functionality. It aims to clarify the
synchronization flow between the BSP and APs to enhance code
readability and understanding:

Steps microsoft#6 and microsoft#11 are the basic synchronization requirements for all
cases.

Steps microsoft#1 is additional requirements if the MmCpuSyncModeTradition
mode is selected.

Steps microsoft#1, microsoft#2, microsoft#3, microsoft#4, microsoft#5, microsoft#7, microsoft#8, microsoft#9, and microsoft#10 are additional
requirements if the system needs to configure the MTRR.

Steps microsoft#9 and microsoft#10 are additional requirements if the system needs to
support the mSmmDebugAgentSupport.

Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
apop5 pushed a commit to apop5/mu_basecore that referenced this pull request Jan 2, 2025
… func

This patch is for PiSmmCpuDxeSmm driver to add one round wait/release sync
for BSP and AP to perform the SMM CPU Platform Hook before executing MMI
Handler: SmmCpuPlatformHookBeforeMmiHandler (). With the function, SMM CPU
driver can perform the platform specific items after one round BSP and AP
sync (to make sure all APs in SMI) and before the MMI handlers.

After the change, steps microsoft#1 and microsoft#2 are additional requirements if the
MmCpuSyncModeTradition mode is selected.

Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant