audk/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableLockRequestToLock.c

97 lines
3.7 KiB
C
Raw Normal View History

/** @file
Temporary location of the RequestToLock shim code while projects
are moved to VariablePolicy. Should be removed when deprecated.
Copyright (c) Microsoft Corporation.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
#include <Uefi.h>
#include <Library/DebugLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/VariablePolicyLib.h>
#include <Library/VariablePolicyHelperLib.h>
#include <Protocol/VariableLock.h>
/**
DEPRECATED. THIS IS ONLY HERE AS A CONVENIENCE WHILE PORTING.
Mark a variable that will become read-only after leaving the DXE phase of
execution. Write request coming from SMM environment through
EFI_SMM_VARIABLE_PROTOCOL is allowed.
@param[in] This The VARIABLE_LOCK_PROTOCOL instance.
@param[in] VariableName A pointer to the variable name that will be made
read-only subsequently.
@param[in] VendorGuid A pointer to the vendor GUID that will be made
read-only subsequently.
@retval EFI_SUCCESS The variable specified by the VariableName and
the VendorGuid was marked as pending to be
read-only.
@retval EFI_INVALID_PARAMETER VariableName or VendorGuid is NULL.
Or VariableName is an empty string.
@retval EFI_ACCESS_DENIED EFI_END_OF_DXE_EVENT_GROUP_GUID or
EFI_EVENT_GROUP_READY_TO_BOOT has already been
signaled.
@retval EFI_OUT_OF_RESOURCES There is not enough resource to hold the lock
request.
**/
EFI_STATUS
EFIAPI
VariableLockRequestToLock (
IN CONST EDKII_VARIABLE_LOCK_PROTOCOL *This,
IN CHAR16 *VariableName,
IN EFI_GUID *VendorGuid
)
{
EFI_STATUS Status;
VARIABLE_POLICY_ENTRY *NewPolicy;
MdeModulePkg/VariableLock: downgrade compatibility warnings to DEBUG_WARN Commit a18a9bde36d2 ("MdeModulePkg/Variable/RuntimeDxe: Restore Variable Lock Protocol behavior", 2020-12-15), for bug 3111, added two such sets of debug messages that: (a) are relevant for developers, (b) yet should not necessarily poke end-users, because no functionality suffers in practice. Both message sets are in function VariableLockRequestToLock(): the first is a generic interface deprecation warning; the second is the double-locking situation, which we permit for compatibility (return status EFI_SUCCESS). Both message sets should be emitted with the DEBUG_WARN mask, not the most serious DEBUG_ERROR mask. On some platforms, the serial console carries both terminal traffic, and grave (DEBUG_ERROR-only) log messages. On such platforms, both message sets may be perceived as a nuisance by end-users, as there is nothing they can do, and there's nothing they *should* do -- in practice, nothing malfunctions. (Such a platform is ArmVirtQemu, built with "-D DEBUG_PRINT_ERROR_LEVEL=0x80000000".) Cc: Bret Barkelew <bret.barkelew@microsoft.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3410 Fixes: a18a9bde36d2ffc12df29cdced1efa1f8f9f2021 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210521204037.11980-1-lersek@redhat.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2021-05-21 22:40:37 +02:00
DEBUG ((DEBUG_WARN, "!!! DEPRECATED INTERFACE !!! %a() will go away soon!\n", __FUNCTION__));
DEBUG ((DEBUG_WARN, "!!! DEPRECATED INTERFACE !!! Please move to use Variable Policy!\n"));
DEBUG ((DEBUG_WARN, "!!! DEPRECATED INTERFACE !!! Variable: %g %s\n", VendorGuid, VariableName));
NewPolicy = NULL;
Status = CreateBasicVariablePolicy (
VendorGuid,
VariableName,
VARIABLE_POLICY_NO_MIN_SIZE,
VARIABLE_POLICY_NO_MAX_SIZE,
VARIABLE_POLICY_NO_MUST_ATTR,
VARIABLE_POLICY_NO_CANT_ATTR,
VARIABLE_POLICY_TYPE_LOCK_NOW,
&NewPolicy
);
if (!EFI_ERROR (Status)) {
Status = RegisterVariablePolicy (NewPolicy);
//
// If the error returned is EFI_ALREADY_STARTED, we need to check the
// current database for the variable and see whether it's locked. If it's
MdeModulePkg/VariableLock: downgrade compatibility warnings to DEBUG_WARN Commit a18a9bde36d2 ("MdeModulePkg/Variable/RuntimeDxe: Restore Variable Lock Protocol behavior", 2020-12-15), for bug 3111, added two such sets of debug messages that: (a) are relevant for developers, (b) yet should not necessarily poke end-users, because no functionality suffers in practice. Both message sets are in function VariableLockRequestToLock(): the first is a generic interface deprecation warning; the second is the double-locking situation, which we permit for compatibility (return status EFI_SUCCESS). Both message sets should be emitted with the DEBUG_WARN mask, not the most serious DEBUG_ERROR mask. On some platforms, the serial console carries both terminal traffic, and grave (DEBUG_ERROR-only) log messages. On such platforms, both message sets may be perceived as a nuisance by end-users, as there is nothing they can do, and there's nothing they *should* do -- in practice, nothing malfunctions. (Such a platform is ArmVirtQemu, built with "-D DEBUG_PRINT_ERROR_LEVEL=0x80000000".) Cc: Bret Barkelew <bret.barkelew@microsoft.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3410 Fixes: a18a9bde36d2ffc12df29cdced1efa1f8f9f2021 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210521204037.11980-1-lersek@redhat.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2021-05-21 22:40:37 +02:00
// locked, we're still fine, but also generate a DEBUG_WARN message so the
// duplicate lock can be removed.
//
if (Status == EFI_ALREADY_STARTED) {
Status = ValidateSetVariable (VariableName, VendorGuid, 0, 0, NULL);
if (Status == EFI_WRITE_PROTECTED) {
MdeModulePkg/VariableLock: downgrade compatibility warnings to DEBUG_WARN Commit a18a9bde36d2 ("MdeModulePkg/Variable/RuntimeDxe: Restore Variable Lock Protocol behavior", 2020-12-15), for bug 3111, added two such sets of debug messages that: (a) are relevant for developers, (b) yet should not necessarily poke end-users, because no functionality suffers in practice. Both message sets are in function VariableLockRequestToLock(): the first is a generic interface deprecation warning; the second is the double-locking situation, which we permit for compatibility (return status EFI_SUCCESS). Both message sets should be emitted with the DEBUG_WARN mask, not the most serious DEBUG_ERROR mask. On some platforms, the serial console carries both terminal traffic, and grave (DEBUG_ERROR-only) log messages. On such platforms, both message sets may be perceived as a nuisance by end-users, as there is nothing they can do, and there's nothing they *should* do -- in practice, nothing malfunctions. (Such a platform is ArmVirtQemu, built with "-D DEBUG_PRINT_ERROR_LEVEL=0x80000000".) Cc: Bret Barkelew <bret.barkelew@microsoft.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3410 Fixes: a18a9bde36d2ffc12df29cdced1efa1f8f9f2021 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210521204037.11980-1-lersek@redhat.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2021-05-21 22:40:37 +02:00
DEBUG ((DEBUG_WARN, " Variable: %g %s is already locked!\n", VendorGuid, VariableName));
Status = EFI_SUCCESS;
} else {
DEBUG ((DEBUG_ERROR, " Variable: %g %s can not be locked!\n", VendorGuid, VariableName));
Status = EFI_ACCESS_DENIED;
}
}
}
if (EFI_ERROR (Status)) {
DEBUG ((DEBUG_ERROR, "%a - Failed to lock variable %s! %r\n", __FUNCTION__, VariableName, Status));
}
if (NewPolicy != NULL) {
FreePool (NewPolicy);
}
return Status;
}