Pre-Allocate Page Table Memory in ArmMmuLib #220
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
os-d
reviewed
Mar 14, 2024
TaylorBeebe
force-pushed
the
pre_alloc_page_table_mem
branch
from
330b413 to
d2d49fb
Compare
…on to protocol fetching of page table pool
TaylorBeebe
force-pushed
the
pre_alloc_page_table_mem
branch
from
d2d49fb to
5488b7c
Compare
kuqin12
reviewed
Apr 18, 2024
os-d
approved these changes
Apr 24, 2024
os-d
reviewed
Apr 24, 2024
github-actions
bot
added
the
impact:breaking-change
TaylorBeebe
added
the
type:design-change
kuqin12
approved these changes
Apr 24, 2024
os-d
pushed a commit
to os-d/mu_silicon_arm_tiano
that referenced
this pull request
Jul 19, 2024
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
os-d
pushed a commit
to os-d/mu_silicon_arm_tiano
that referenced
this pull request
Jul 19, 2024
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
os-d
pushed a commit
to os-d/mu_silicon_arm_tiano
that referenced
this pull request
Jul 19, 2024
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
os-d
pushed a commit
to os-d/mu_silicon_arm_tiano
that referenced
this pull request
Jul 19, 2024
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
os-d
pushed a commit
to os-d/mu_silicon_arm_tiano
that referenced
this pull request
Jul 22, 2024
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
os-d
pushed a commit
that referenced
this pull request
Jul 22, 2024
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Jan 17, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Feb 5, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Feb 11, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Feb 13, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Feb 13, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Feb 17, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Feb 17, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Feb 24, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
to apop5/mu_silicon_arm_tiano
that referenced
this pull request
Feb 24, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
apop5
pushed a commit
that referenced
this pull request
Mar 3, 2025
Allocating memory when memory protection is active can cause the below
infinite loop:
1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
2. ArmSetMemoryRegionReadOnly ()
3. SetMemoryRegionAttribute()
4. UpdateRegionMapping()
5. UpdateRegionMappingRecursive()
6. AllocatePages() -> Need memory for a translation table entry
7. CoreAllocatePages()
8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
9. gCpu->SetMemoryAttributes()
10. Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN
prior to installing the CpuArch protocol. However, when we transition to
setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation
during table spits to prevent the infinite loop.
- [x] 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, ...
- [x] 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, ...
Tested on SBSA by creating the scenario where the infinite loop (without
the XN remap routine in place) and booting successfully. This was also
tested using the EFI_MEMORY_RP on free memory feature branch.
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC
modules will need to switch those module types to use ArmMmuPeiLib.
```
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Allocating memory when memory protection is active can cause the below infinite loop:
To fix this previously, CpuDxe would update conventional memory to be XN prior to installing the CpuArch protocol. However, when we transition to setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation during table spits to prevent the infinite loop.
flow, or firmware?
validation improvement, ...
in build or boot behavior?
a function in a new library class in a pre-existing module, ...
outside direct code modifications (and comments)?
on an a separate Web page, ...
How This Was Tested
Tested on SBSA by creating the scenario where the infinite loop (without the XN remap routine in place) and booting successfully. This was also tested using the EFI_MEMORY_RP on free memory feature branch.
Integration Instructions
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC modules will need to switch those module types to use ArmMmuPeiLib.