Messages in this thread | | | From | Andy Lutomirski <> | Date | Sat, 5 Mar 2016 18:59:07 -0800 | Subject | Re: soft lockup when passing vvar address to write(2) |
| |
On Mar 5, 2016 1:04 AM, "Ingo Molnar" <mingo@kernel.org> wrote: > > > * Thomas Gleixner <tglx@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
| |