From 7bb497092a34a2bbb16bad5385a0487dee18a769 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Wed, 11 Jul 2018 11:40:36 +0200 Subject: efi/cper: Avoid using get_seconds() get_seconds() is deprecated because of the 32-bit time overflow in y2038/y2106 on 32-bit architectures. The way it is used in cper_next_record_id() causes an overflow in 2106 when unsigned UTC seconds overflow, even on 64-bit architectures. This starts using ktime_get_real_seconds() to give us more than 32 bits of timestamp on all architectures, and then changes the algorithm to use 39 bits for the timestamp after the y2038 wrap date, plus an always-1 bit at the top. This gives us another 127 epochs of 136 years, with strictly monotonically increasing sequence numbers across boots. This is almost certainly overkill, but seems better than just extending the deadline from 2038 to 2106. Signed-off-by: Arnd Bergmann Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-5-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar --- drivers/firmware/efi/cper.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) (limited to 'drivers/firmware/efi/cper.c') diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c index 3bf0dca378a6..b73fc4cab083 100644 --- a/drivers/firmware/efi/cper.c +++ b/drivers/firmware/efi/cper.c @@ -48,8 +48,21 @@ u64 cper_next_record_id(void) { static atomic64_t seq; - if (!atomic64_read(&seq)) - atomic64_set(&seq, ((u64)get_seconds()) << 32); + if (!atomic64_read(&seq)) { + time64_t time = ktime_get_real_seconds(); + + /* + * This code is unlikely to still be needed in year 2106, + * but just in case, let's use a few more bits for timestamps + * after y2038 to be sure they keep increasing monotonically + * for the next few hundred years... + */ + if (time < 0x80000000) + atomic64_set(&seq, (ktime_get_real_seconds()) << 32); + else + atomic64_set(&seq, 0x8000000000000000ull | + ktime_get_real_seconds() << 24); + } return atomic64_inc_return(&seq); } -- cgit v1.2.3 From e8f4194d9b98aa13f9f567a0056bbf683d2b1ab8 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Fri, 20 Jul 2018 10:47:25 +0900 Subject: efi/cper: Use consistent types for UUIDs The commit: 2f74f09bce4f ("efi: parse ARM processor error") ... brought inconsistency in UUID types which are used across the CPER. Fix this by moving to use guid_t API everywhere. Signed-off-by: Andy Shevchenko Signed-off-by: Ard Biesheuvel Cc: Hans de Goede Cc: Linus Torvalds Cc: Lukas Wunner Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tyler Baicar Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180720014726.24031-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar --- drivers/firmware/efi/cper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/firmware/efi/cper.c') diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c index b73fc4cab083..a7902fccdcfa 100644 --- a/drivers/firmware/efi/cper.c +++ b/drivers/firmware/efi/cper.c @@ -472,7 +472,7 @@ cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data *gdata else goto err_section_too_small; #if defined(CONFIG_ARM64) || defined(CONFIG_ARM) - } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_ARM)) { + } else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { struct cper_sec_proc_arm *arm_err = acpi_hest_get_payload(gdata); printk("%ssection_type: ARM processor error\n", newpfx); -- cgit v1.2.3