linux-kernel - Re: [PATCH] x86/vdso: Remove direct HPET access through the vDSO

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]

Message-ID: <CALCETrVbJDCth147POzTu2A0wVqZiwR4Qm7G=Lsvu4QA61Sfzg@mail.gmail.com>
Date:	Fri, 8 Apr 2016 08:59:08 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Waiman Long <waiman.long@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>
Subject: Re: [PATCH] x86/vdso: Remove direct HPET access through the vDSO

On Apr 8, 2016 3:36 AM, "Borislav Petkov" <bp@...en8.de> wrote:
>
> On Thu, Apr 07, 2016 at 05:16:59PM -0700, Andy Lutomirski wrote:
> > Allowing user code to map the HPET is problematic.  HPET
> > implementations are notoriously buggy, and there are probably many
> > machines on which even MMIO reads from bogus HPET addresses are
> > problematic.
> >
> > We have a report that the Dell Precision M2800 with:
> >
> > ACPI: HPET 0x00000000C8FE6238 000038 (v01 DELL   CBX3  01072009 AMI. 00000005)
> >
> > is either so slow when accessing the HPET or actually hangs in some
> > regard, causing soft lockups to be reported if users do unexpected
> > things to the HPET.
> >
> > The vclock HPET code has also always been a questionable speedup.
> > Accessing an HPET is exceedingly slow (on the order of several
> > microseconds), so the added overhead in requiring a syscall to read
> > the HPET is a small fraction of the total code of accessing it.
> >
> > To avoid future problems, let's just delete the code entirely.
> >
> > In the long run, this could actually be a speedup.  Waiman Long as a
> > patch to optimize the case where multiple CPUs contend for the HPET,
> > but that won't help unless all the accesses are mediated by the
> > kernel.
> >
> > Cc: Waiman Long <waiman.long@....com>
> > Reported-by: Rasmus Villemoes <linux@...musvillemoes.dk>
> > Signed-off-by: Andy Lutomirski <luto@...nel.org>
> > ---
> >  arch/x86/entry/vdso/vclock_gettime.c  | 15 ---------------
> >  arch/x86/entry/vdso/vdso-layout.lds.S |  5 ++---
> >  arch/x86/entry/vdso/vma.c             | 11 -----------
> >  arch/x86/include/asm/clocksource.h    |  9 ++++-----
> >  arch/x86/kernel/hpet.c                |  1 -
> >  arch/x86/kvm/trace.h                  |  3 +--
> >  6 files changed, 7 insertions(+), 37 deletions(-)
>
> I like diffstats which remove more lines than add :)
>
> In any case, I'm not well versed in the vdso game but from my experience
> so far, I'm starting to believe that the 'H' in HPET stands for
> Horrific. So the less people get exposed to it, the better.
>
> A question though: userspace does not rely on the hpet page being always
> present and can do fallback. IOW, we're not breaking any existing
> usages, right?

It shouldn't break anything.  It'll just cause the vdso to issue a
real syscall instead of reading the HPET directly.  I strongly doubt
there's user code that pokes the HPET mapping outside the vdso, since
it would have broken when we moved the HPET mapping out of the fixmap
to a randomized address.

>
> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.