linux-kernel - [PATCH] pstore: use ktime_get_real_fast_ns() instead of _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20171108160056.3042976-1-arnd@arndb.de>
Date:   Wed,  8 Nov 2017 17:00:14 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Kees Cook <keescook@...omium.org>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Arnd Bergmann <arnd@...db.de>, Stephen Boyd <sboyd@...eaurora.org>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: [PATCH] pstore: use ktime_get_real_fast_ns() instead of __getnstimeofday()

I noticed that __getnstimeofday() is a rather odd interface, with
a number of quirks:

- The caller may come from NMI context, but the implementation is not NMI safe
- The calling conventions are different from any other timekeeping functions
- The naming doesn't fit into the 'ktime_get_*()' scheme

This addresses the above issues by using a completely different
method to get the time: ktime_get_real_fast_ns() is NMI safe and
doesn't print a warning when called with the timekeeping suspended,
and we can easily transform the result into a timespec structure. Since
ktime_get_real_fast_ns() was not exported to modules, I also add the
export.

The behavior for the suspended case changes, we now return the time
if we can find it out rather than setting it to zero. We could still
change that but this would require exporting the 'timekeeping_suspended'
to modules.

I'm not trying to address y2038-safety at this point, but plan to
do that later with a more complex patch.

Cc: Kees Cook <keescook@...omium.org>
Signed-off-by: Arnd Bergmann <arnd@...db.de>
---
It would be helpful to get this merged into v4.15-rc1, since I have
some other cleanups that depend on this. Please have a look to see if
this makes sense to you.
---
 fs/pstore/platform.c      | 5 +----
 kernel/time/timekeeping.c | 1 +
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index ec7199e859d2..086e491faf04 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -482,10 +482,7 @@ void pstore_record_init(struct pstore_record *record,
 	record->psi = psinfo;
 
 	/* Report zeroed timestamp if called before timekeeping has resumed. */
-	if (__getnstimeofday(&record->time)) {
-		record->time.tv_sec = 0;
-		record->time.tv_nsec = 0;
-	}
+	record->time = ns_to_timespec(ktime_get_real_fast_ns());
 }
 
 /*
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 353f7bd1eeb0..198afa78bf69 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -528,6 +528,7 @@ u64 ktime_get_real_fast_ns(void)
 {
 	return __ktime_get_real_fast_ns(&tk_fast_mono);
 }
+EXPORT_SYMBOL_GPL(ktime_get_real_fast_ns);
 
 /**
  * halt_fast_timekeeper - Prevent fast timekeeper from accessing clocksource.
-- 
2.9.0