linux-kernel - Re: [PATCH] x86: convert x86_platform

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Oct 2017 10:11:12 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Juergen Gross <jgross@...e.com>,
        Marcos Paulo de Souza <marcos.souza.org@...il.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        John Stultz <john.stultz@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kvm@...r.kernel.org, xen-devel <xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH] x86: convert x86_platform_ops to timespec64

On Fri, Oct 13, 2017 at 10:45 PM, Boris Ostrovsky
<boris.ostrovsky@...cle.com> wrote:
> On 10/13/2017 02:37 PM, Arnd Bergmann wrote:
>> The x86 platform operations are fairly isolated, so we can
>> change them from using timespec to timespec64. I checked that
>> All the users and callers are safe, and there is only one
>> critical function that is broken beyond 2106:
>>
>> pvclock_read_wallclock() uses a 32-bit number of seconds since
>> the epoch to communicate the boot time between host and guest
>> in a virtual environment. This will work until 2106, but we
>> should ideally find a replacement anyway. I've added a comment
>> about it there.
>>
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>> ---
>>  arch/x86/include/asm/intel_mid_vrtc.h        |  4 ++--
>>  arch/x86/include/asm/mc146818rtc.h           |  4 ++--
>>  arch/x86/include/asm/pvclock.h               |  2 +-
>>  arch/x86/include/asm/x86_init.h              |  6 +++---
>>  arch/x86/kernel/kvmclock.c                   |  4 ++--
>>  arch/x86/kernel/pvclock.c                    | 12 +++++++++---
>>  arch/x86/kernel/rtc.c                        | 16 ++++++++--------
>>  arch/x86/platform/intel-mid/intel_mid_vrtc.c | 10 +++++-----
>>  arch/x86/xen/time.c                          | 10 +++++-----
>>  9 files changed, 37 insertions(+), 31 deletions(-)
>
> Xen bits:
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@...cle.com>

Thanks!

Since you've looked at it overall, do you have an opinion on the question
how to fix the PV interface to deal with the pvclock_wall_clock overflow?

Should we add a new version now and deprecate the existing one, or
do you think that y2106 is far enough out that we should just ignore the
problem?

> with a couple of nits:
>
>> @@ -136,11 +136,17 @@ void pvclock_read_wallclock(struct pvclock_wall_clock *wall_clock,
>>               rmb();          /* fetch time before checking version */
>>       } while ((wall_clock->version & 1) || (version != wall_clock->version));
>>
>> +     /*
>> +      * Note: wall_clock->sec is a u32 value, so it can only store dates
>> +      * between 1970 and 2106. To allow times beyond that, we need to
>> +      * create a new hypercall interface with an extended pvclock_wall_clock
>> +      * structure like ARM has.
>> +      */
>
> I think this comment block should be moved up above 'now.tv_sec  =
> wall_clock->sec;'

right, changed.

>>       delta = pvclock_clocksource_read(vcpu_time);    /* time since system boot */
>>       delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
>
> Now that tv_sec is a 64-bit quantity the cast can be dropped.

Ok dropped. In the meantime I had noticed two more problems with the
patch that I did not see earlier when I tested with another patch applied
as well. The kbuild test robot reported the exact same problems, and I've
done a few hundred randconfig builds without the other patch now, so
I'm fairly confident that there are no other problems like those.

I'll follow up with a v2 patch soon.

       Arnd