linux-kernel - Re: [PATCH] Add VDSO time function support for x86 32-bit kernel

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

Date:	Tue, 11 Dec 2012 17:29:44 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	linux-kernel@...r.kernel.org, ak@...ux.intel.com,
	aarcange@...hat.com, john.stultz@...aro.org,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH] Add VDSO time function support for x86 32-bit kernel

[cc: Jeremy Fitzhardinge -- you wrote some of this]

On Tue, Dec 11, 2012 at 12:40 PM, Stefani Seibold <stefani@...bold.net> wrote:
> Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
>> On Tue, Dec 11, 2012 at 8:11 AM,  <stefani@...bold.net> wrote:
>> > --- a/arch/x86/vdso/vclock_gettime.c
>> > +++ b/arch/x86/vdso/vclock_gettime.c
>> > @@ -59,14 +59,23 @@ notrace static cycle_t vread_tsc(void)
>> >
>> >  static notrace cycle_t vread_hpet(void)
>> >  {
>> > +#ifdef CONFIG_X86_64
>> >         return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 0xf0);
>> > +#else
>> > +       return readl(VVAR(vsyscall_hpet) + HPET_COUNTER);
>> > +#endif
>> >  }
>>
>> Is 0xf0 not equal to HPET_COUNTER?
>>
>
> Yes, but HPET_COUNTER is more readable.

Sorry -- read it backwards.  Can you change the 64-bit one as well?

>
>> >
>> >  notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
>> >  {
>> >         long ret;
>> > +#ifdef CONFIG_X86_64
>> >         asm("syscall" : "=a" (ret) :
>> >             "0" (__NR_clock_gettime),"D" (clock), "S" (ts) : "memory");
>> > +#else
>> > +       asm("int $0x80" : "=a" (ret) :
>> > +           "a" (__NR_clock_gettime), "b" (clock), "c" (ts) : "memory");
>> > +#endif
>> >         return ret;
>> >  }
>>
>> __kernel_vsyscall is probably much faster if you can figure out how to
>> call it from here :)
>>
>
> Yes i know. Thats one of my problems, because i cannot call
> __kernel_vsyscall directly due the relocation. Any idea?

What actually goes wrong?  I think that if calling __kernel_vsyscall
like a normal symbol doesn't work then it's a bug in the relocation.

What's the point of this relocation?  It appears thoroughly useless in
the !compat case.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/