On Mar 5, 2016 1:04 AM, "Ingo Molnar" <mi...@kernel.org> wrote: > > > * Thomas Gleixner <t...@linutronix.de> wrote: > > > On Fri, 4 Mar 2016, Andy Lutomirski wrote: > > > Thomas, I still think we should consider just deleting the HPET vclock > > > code and accept the syscall overhead on systems that are stuck using > > > HPET. If fast syscalls are available (which should include every > > > system with HPET, unless there are some 32-bit AMD systems lying > > > around), then the overhead in a syscall is *tiny* compared to the code > > > of the HPET read itself. > > > > No objection from my side, really. > > Seconded. HPET hardware overhead is typically horrifically large in any case, > no > need to memory map it and expose hardware breakages to user-space ...
I'll do it for 4.7. > > It's also a (mild) security hole: a well-known HPET address can be abused as a > statistical trampoline periodically cycling through 'dangerous' instruction > values. That weakness has closed for quite a while -- it's mapped NX and it's randomized. I'm also not planning to revert the mapping security improvement -- even if we remove the HPET code, it still applies to kvmclock and to anything else that gets added in the future. It's also very little code. --Andy
