From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web12.1822.1608582758795591517 for ; Mon, 21 Dec 2020 12:32:38 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bsRLWAkG; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608582758; 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: in-reply-to:in-reply-to:references:references; bh=ZRYDfn0WE9V7Gg4B/DUEVV1twe67h9dnWg+kn0kbAyw=; b=bsRLWAkGcMGaw7/dVlEjQgRTdZx51k5I2aH/tJSC2FkBc1wqelMfykpAhAmnFw+cBqITIm y1c1o4lbXiEdJFChdoe0fFfLNrOh3bSVRCgDbBQXJ7UMSr10Cd0QxLu90A0AdRKWn78lUk xGbDDwJvQO8spwBJJKoGmnfOPWMQFbs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-265-jwLL0B-GMfaDl4IYs0oLqA-1; Mon, 21 Dec 2020 15:32:34 -0500 X-MC-Unique: jwLL0B-GMfaDl4IYs0oLqA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 83CD3800D53; Mon, 21 Dec 2020 20:32:32 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-71.ams2.redhat.com [10.36.114.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id BC4D110013C1; Mon, 21 Dec 2020 20:32:30 +0000 (UTC) Subject: Re: [edk2-devel] [edk2-platforms PATCH] Marvell/RealTimeClockLib: Allow only Unix Epoch in LibSetWakeupTime From: "Laszlo Ersek" To: devel@edk2.groups.io, mw@semihalf.com Cc: leif@nuviainc.com, ard.biesheuvel@arm.com, jaz@semihalf.com, kostap@marvell.com References: <20201221163710.19729-1-mw@semihalf.com> <4f9497c7-0097-3a92-6b52-ece4a6defa9f@redhat.com> Message-ID: <1191b863-3779-2751-e47e-deef8adc73f5@redhat.com> Date: Mon, 21 Dec 2020 21:32:29 +0100 MIME-Version: 1.0 In-Reply-To: <4f9497c7-0097-3a92-6b52-ece4a6defa9f@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 12/21/20 21:09, Laszlo Ersek wrote: > Hi Marcin, > > On 12/21/20 17:37, Marcin Wojtas wrote: >> Because the Armada RTC uses a 32-bit counter for seconds, >> the maximum time span is just over 136 years. >> Time is stored in Unix Epoch format, so it starts in 1970, >> Therefore it can not exceed the year 2106. >> >> The issue emerged during ACS test case, which does not pass >> Unix Epoch-relative time and caused EfiTimeToEpoch to assert. >> >> Signed-off-by: Marcin Wojtas >> --- >> Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c >> index a811fd368e..40ab01ed41 100644 >> --- a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c >> +++ b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c >> @@ -179,6 +179,16 @@ LibSetWakeupTime ( >> { >> UINTN WakeupSeconds; >> >> + // >> + // Because the Armada RTC uses a 32-bit counter for seconds, >> + // the maximum time span is just over 136 years. >> + // Time is stored in Unix Epoch format, so it starts in 1970, >> + // Therefore it can not exceed the year 2106. >> + // >> + if ((Time->Year < 1970) || (Time->Year >= 2106)) { >> + return EFI_UNSUPPORTED; >> + } >> + >> // Convert time to raw seconds >> WakeupSeconds = EfiTimeToEpoch (Time); >> if (WakeupSeconds > MAX_UINT32) { >> > > please see: > > - edk2-platforms commit fbdfe8c4100d ("Silicon/Marvell/RealTimeClockLib: > make EpochSeconds, WakeupSeconds UINTN", 2020-12-21) -- part of this is > already visible in the context above, > > - edk2 commit c06635ea3f4b ("EmbeddedPkg/TimeBaseLib: remove useless > truncation to 32-bit", 2020-12-21). > > If you advance the edk2 submodule reference in edk2-platforms to or past > c06635ea3f4b, then the "Time->Year >= 2106" condition will be covered > already, by the (WakeupSeconds > MAX_UINT32) check. (Oops, sorry, I forgot that edk2-platforms consumes edk2 *only* through PACKAGES_PATH, and never through a submodule; so please adjust the above submodule statement accordingly.) BTW, is this library instance ever built for 32-bit ARM? Because in that case (== UINTN meaning UINT32), checking Year against 2106 makes sense as well. While build-testing the above-noted patches, I tried to build them for 32-bit ARM too, but that arch did not seem applicable: while the following command works: build \ -a AARCH64 \ -b NOOPT \ -p Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc \ -t GCC5 \ -m EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf the same with "-a ARM" fails, with the following error message: edk2-platforms/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc(...): error 4000: Instance of library class [ArmSoftFloatLib] is not found in [edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf] [ARM] consumed by module [edk2/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf] which implies that "Armada80x0McBin.dsc" is never actually built for ARM. ... Hm, the following platforms: - Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc - Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc do build the library for ARM. So this patch seems justified after all, as-posted (i.e., including the year 2106 check). Reviewed-by: Laszlo Ersek Thanks Laszlo > > Preventing ASSERT (JulianDate >= EPOCH_JULIAN_DATE) from firing in > EfiGetEpochDays() still makes sense, so the (Time->Year < 1970) check > can still be added usefully, I think. > > Thanks > Laszlo >