On 1/7/2019 9:05 AM, Eric Dong wrote:
Enhance debug message format to let them easy to read.
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
.../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 17 +++--
1 file changed, 11
Take care not to dereference BlockEntry if it may be pointing past
the end of the page table we are manipulating. It is only a read,
and thus harmless, but HeapGuard triggers on it so let's fix it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Wire up the access flag (AF) page table attribute to the EFI_MEMORY_RP
permission attribute, so that attempts to read from such a region will
trigger an access flag fault.
Note that this is a stronger notion than just read protection, since
it now implies that any write or execute attempt is
Register for the EndOfDxe event, and use it to invoke the new
ArmMmuLib code that remaps all page tables as read-only. This
should limit the impact of arbitrary write exploits, since they
can no longer be abused to modify tightened memory permissions.
Contributed-under: TianoCore Contribution
Currently, we always invalidate the TLBs entirely after making
any modification to the page tables. Now that we have introduced
strict memory permissions in quite a number of places, such
modifications occur much more often, and it is better for performance
to flush only those TLB entries that are
Now that we are getting more serious about implementing secure boot
on ARM systems, by putting the code that manipulated the variable
store in a secure partition, it makes sense to give some attention
to the non-secure side as well, since having secure authenticated
variables is moot if we can
As a hardening measure, implement support for remapping all page
tables read-only at a certain point during the boot (end of DXE
is the most appropriate trigger).
This should make it a lot more difficult to take advantage of
write exploits to defeat authentication checks, since the
attacker can
Ignore calls to ArmSetMemoryAttributes () when the region described
is outside of the 32-bit addressable range. This memory is not
mapped in the first place, and the current code does not deal with
the high bits correctly, resulting in hangs.
Contributed-under: TianoCore Contribution Agreement
GCC for 32-bit ARM chokes on .aslc files when running with LTO
enabled. Since LTO has no benefit whatsoever here, just disable
it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
BaseTools/Conf/tools_def.template | 2 +-
1 file changed, 1 insertion(+),
During cleanup in case of initialization failure, some driver
bindings are not installed. Using abstractions in UEFILib takes
care of it.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1428
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal
---
An issue was seen in IScsiDxe in NetworkPkg where driver cleanup after
initialization failure was not done right. Bug 1428 was filed in this regard.
As per discussions with Mike, it was also discussed that having UEFILib
provide protocol uninstallation abstraction would help to avoid these
issues
Provided functions in UEFILib that abstract driver model protocol
uninstallation. This helps drivers to install and uninstall protocols
using a library to keep things seemless.
Also, add a helper function to operate upon protocol installation and
uninstallation instead of every function doing it
From: jiansonx
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1396
Add a new API GetVariable3, which can return the attributes of a variable
during reading it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiansong Xu
Cc: Liming Gao GetVariable.
+
+**/
+EFI_STATUS
Hello Liming,
I am not touching APIs for Install and am OK keeping Uninstall API same as what
I had in patch 1/4. I thought it would be easier for the developer to keep the
interface similar to install but I do not have a strong preference either way.
If you are OK with the Uninstall API as in
Hi, Ashish
The changes to NetworkPkg is good to me. Please add the package maintainer's
name to the cc list of the patch mail in future, thanks.
Reviewed-by: Fu Siyuan
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ashish
> Singhal
>
Reviewed-by: Siyuan Fu
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ashish
> Singhal
> Sent: Saturday, January 5, 2019 7:07 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH v2 4/4] NetworkPkg/IScsiDxe:
V2:
1. Initialize CpuFeaturesData->MpService in CpuInitDataInitialize
and make this function been called at the begin of the
initialization.
2. let all other functions use CpuFeaturesData->MpService install
of locate the protocol itself.
V1:
GetProcessorIndex function calls GetMpPpi to
AP should not use PeiServices. The patch serial fix one issue related to this.
This serial also include one patch used to refine the debug message.
Eric Dong (2):
UefiCpuPkg/RegisterCpuFeaturesLib: Enhance debug message.
UefiCpuPkg/RegisterCpuFeaturesLib: Avoid AP calls PeiService.
Enhance debug message format to let them easy to read.
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
.../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git
Ashish:
UefiLib implementation simplification doesn't require to change library APIs.
UninstallApi() interfaces are not required to be updated. Below Install API can
still be kept. I don't think we need to keep the same interfaces for Install
and Uninstall APIs.
20 matches
Mail list logo
