Firmware Test Suite

uefirttime - Avoid using TimeZone 2047

Bug #1933503 reported by Samer EL-Haj-Mahmoud
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Firmware Test Suite
Fix Released
Undecided
Ivan Hu

Bug Description

FWTS uefirttime test tries to change the TimeZone to 0 (UTC) if it is not already 0. Otherwise, it tries to change it to 2047 (local time): https://git.launchpad.net/fwts/tree/src/uefi/uefirttime/uefirttime.c#n344

Some systems do not support the 2047 local time, and enforces time to always be in UTC. This can for instance be either an enforced BIOS behavior, or configurable via a user BIOS Setup option.

an the FWTS test avoid using this potentially problematic TZ value (with the special "local time" meaning), and instead use another UTC value (e.g. 01 for UTC+1) to confirm the TimeZone change functionality? This is similar to what SCT does in pre-boot testing of the same Get/SetTime interface: https://github.com/tianocore/edk2-test/blob/master/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TimeServices/BlackBoxTest/TimeServicesBBTestFunction.c#L616

If there is a need to test "local time" support, maybe that can be a separate test, since not all platforms support local time.

Alex Hung (alexhung)
Changed in fwts:
assignee: nobody → Ivan Hu (ivan.hu)
Revision history for this message
Ivan Hu (ivan.hu) wrote :

@Samer

Thanks for the info.
Could you provide the fwts result logs for those that haven't the "local time" support?
So that I could figure out how's the uefirttime test going.

Changed in fwts:
status: New → In Progress
Revision history for this message
Samer EL-Haj-Mahmoud (samerelhaj) wrote :

The logs are as below, I am only showing the failed test in uefirttime. All other uefirttime tests have passed.

uefirttime: UEFI Runtime service time interface tests.
--------------------------------------------------------------------------------
...
...
Test 4 of 36: Test UEFI RT service set time interface.
FAILED [HIGH] UEFIRuntimeSetTimeTimezone: Test 4, Failed to set timezone with
UEFI runtime service.
...
...
================================================================================
15 passed, 1 failed, 0 warning, 0 aborted, 20 skipped, 0 info only.
================================================================================

What this firmware is doing is that if you call SetVariable() at runtime with a TZ of EFI_UNSPECIFIED_TIMEZONE (2047), then the FW will force the value stored to be UTC+0 (0) instead of returning an error. This is done by the FW in order to maintain consistent UTC based RTC across different sources of time (UEFI variables, ACPI Time and Alarm Device), etc.. There could be a FW Setup configuration setting to enable/disable the "local time" functionality.

Revision history for this message
Ivan Hu (ivan.hu) wrote :

Thanks for your information.

Revisit the test, I recalled that the test with value EFI_UNSPECIFIED_TIMEZONE (2047) instead of value 1 in SCT is on purpose. Please refer to https://lists.ubuntu.com/archives/fwts-devel/2017-November/010038.html. Basically it is because we found some HP platforms will use the exact time zone value on earth in the UEFI plugfest, although 1 is allowed by UEFI spec, but not the actual value users will use.

The value EFI_UNSPECIFIED_TIMEZONE(2047) is actually defined in UEFI specification. If firmware not support it, the status code returned value EFI_INVALID_PARAMETER of settime may be expected.

I think the real issue here is that the FW do something instead of returned an error when EFI_UNSPECIFIED_TIMEZONE is not supported. Will it cause the end users setting Local time but get unexpected behaviors?

Currently, I think it is better to keep testing with EFI_UNSPECIFIED_TIMEZONE(2047) instead of changing the value that allow the firmware which not support EFI_UNSPECIFIED_TIMEZONE value to pass the test. Maybe add some advice information for notice on this failure will be a good idea.

Revision history for this message
Ivan Hu (ivan.hu) wrote :

Advice patch has sent for review,
http://patchwork<email address hidden>/

Revision history for this message
Samer EL-Haj-Mahmoud (samerelhaj) wrote :

Thanks Ivan. This is a good approach. I am fine with the patch

Alex Hung (alexhung)
Changed in fwts:
status: In Progress → Fix Committed
Alex Hung (alexhung)
Changed in fwts:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.