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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 17 May 2017 16:06:07 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Miroslav Lichvar <mlichvar@...hat.com>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Prarit Bhargava <prarit@...hat.com>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH RFC 0/3] Improve stability of system clock

On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar <mlichvar@...hat.com> wrote:
> On Wed, May 17, 2017 at 10:02:00AM -0700, John Stultz wrote:
>> On Wed, May 17, 2017 at 9:57 AM, Miroslav Lichvar <mlichvar@...hat.com> wrote:
>> > On Wed, May 17, 2017 at 09:30:31AM -0700, John Stultz wrote:
>> >> Could you submit your linux-tktest infrastructure to the kselftests dir?
>> >
>> > I can, but it's a mess that breaks frequently as the timekeeping and
>> > other kernel code changes. Are you sure you want that in the kernel
>> > tree? :)
>>
>> Being a mess is a slight concern, but as for breaking, if its
>> in-kernel, then folks can't make changes that break it, right?
>
> It duplicates/stubs quite a few kernel functions that are needed to
> compile and link the timekeeping.c file into an executable. See
> linux-tktest/missing.c. If their signature changes, or new functions
> are needed, it will break.

Hopefully we can fix it in the kernel as well then?

Or maybe it will help inform how we could refactor the time code to
better support the simulation code?

> Is there a better way to run the timekeeping code in an userspace
> application? I suspect it would need something like the Linux Kernel
> Library project.

I dunno. There's probably a cleaner way to go about it, but I also
feel like the benefit of just having the test in the kernel tree is
that it can be managed as a unified whole, rather then the test being
a separate thing and always playing catchup to kernel changes.

thanks
-john

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ