From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.44838.1683189907965050397 for ; Thu, 04 May 2023 01:45:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WgzNJ9HM; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683189907; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=1xFplbTkSzNFPQt8PYHTejJ5sgPcfc9uCiq92ojxZuU=; b=WgzNJ9HMbON72tlDFPtwSVKfgIwLsT19fL9X+urG21MWHKIR2aaGI4gh7BdyCJz99syr46 2w+2OJPvwguUr1TkvBm8FdsIZ0cXLK1fRjTThCrNBKF2d5A9+x1SFJdw3QuINBnF/H19Fh xWU/wE1K9s2qcPnR7uc8ITU33iQsy8g= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-240-OPo3YA4fMn64ZyJ6X6xfzw-1; Thu, 04 May 2023 04:45:03 -0400 X-MC-Unique: OPo3YA4fMn64ZyJ6X6xfzw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7847E1C051A7; Thu, 4 May 2023 08:45:03 +0000 (UTC) Received: from [10.39.193.249] (unknown [10.39.193.249]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 82E45492C13; Thu, 4 May 2023 08:45:02 +0000 (UTC) Message-ID: <0cf211a5-ddb1-c2a7-1be4-1776c7068496@redhat.com> Date: Thu, 4 May 2023 10:45:00 +0200 MIME-Version: 1.0 To: edk2-devel-groups-io Cc: Michael Kinney , Andrew Fish , Michael Brown , Gerd Hoffmann From: "Laszlo Ersek" Subject: purpose of EFI_LOCK X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, what benefit does EFI_LOCK add, over direct gBS->RaiseTPL() and gBS->RestoreTPL() calls? Considering just the two APIs EfiAcquireLock() and EfiReleaseLock(): - The "Lock" field (effectively, lock status field) is useless; it is only written to, never read (outside of ASSERT()s) - The "OwnerTpl" and "Tpl" fields are just convenience storage for the new TPL we raise to, and the old TPL we restore. Considering the EfiAcquireLockOrFail() API as well: - This does read the "Lock" (lock status) field, and if it is EfiLockAcquired, the RaiseTPL() call is refused. So the idea here seems to be to ensure a *strict* rise in the TPL. Namely, the RaiseTPL() in EfiAcquireLockOrFail() would still succeed after the RaiseTPL() in EfiAcquireLock() -- it is valid to "raise" the TPL to the current TPL --, but the lock status check prevents that. - However (#1), this same "strict" raise would be possible by just calling RaiseTPL() again, and comparing the returned old TPL against the TPL we've just set as new. If the old TPL is strictly lower, then we've just "acquired the lock", otherwise we've "already been holding" the lock. So, from this perspective, EfiAcquireLockOrFail() doesn't add much. - Furthermore (#2), if another agent raised the TPL already, but didn't use our particlar EFI_LOCK object to do that, then the status stored in "EFI_LOCK.Lock" will not be able to track anything. So what is EFI_LOCK good for? Effectively I'm disturbed by the *name* "EFI_LOCK". A lock (or mutex) is supposed to protect some shared resource. If two agents access the resource without first acquiring the lock, there's trouble. Therefore the resource itself becomes qualified as "requiring protection by the lock, at all times". However, the "current TPL" is *not* a resource like that. It's a UEFI spec level concept; the RaiseTPL and RestoreTPL boot services are available to any agents; those agents are *not* required to go through any kind of extra mutual exclusion. I've also considered that maybe EFI_LOCK could provide some protection against inadvertently *lowering* the TPL via RaiseTPL() (which is undefined behavior, per spec). But I don't see how -- EfiAcquireLockOrFail() will happily lower the TPL if the Lock field is EfiLockReleased, but another agent has meanwhile raised the TPL strictly above the Tpl field. Please explain. :) Thanks! Laszlo