From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964830AbcBYTj5 (ORCPT ); Thu, 25 Feb 2016 14:39:57 -0500 Received: from mail-oi0-f41.google.com ([209.85.218.41]:36290 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933377AbcBYTjz (ORCPT ); Thu, 25 Feb 2016 14:39:55 -0500 MIME-Version: 1.0 In-Reply-To: References: <3e36be110724896e32a4a1fe73bacb349d3cba94.1456262295.git.luto@kernel.org> <56CE9897.6080702@zytor.com> From: Andy Lutomirski Date: Thu, 25 Feb 2016 11:39:35 -0800 Message-ID: Subject: Re: [tip:x86/urgent] x86/entry/32: Add an ASM_CLAC to entry_SYSENTER_32 To: Brian Gerst Cc: Linus Torvalds , "H. Peter Anvin" , Linux Kernel Mailing List , "linux-tip-commits@vger.kernel.org" , Thomas Gleixner , Borislav Petkov , Peter Zijlstra , Ingo Molnar , Denys Vlasenko Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 25, 2016 at 11:31 AM, Brian Gerst wrote: > On Thu, Feb 25, 2016 at 1:30 PM, Linus Torvalds > wrote: >> On Thu, Feb 25, 2016 at 10:20 AM, Andy Lutomirski wrote: >>> >>> Ideally we'd fix this up and restore flags on sysexit. At least >>> failing to restore arithmetic flags isn't an info leak because the >>> exit code clobbers them with entirely predictable data. I doubt >>> anyone cares all that much if we clobber AC. >> >> As long as the "clobber AC" is purely about clearing it, it's probably fine. >> >> Although there may be programs that set AC in order to actually get >> notified about alignment issues (perhaps for portability reasons, >> perhaps for small performance reasons). Clearing it will make those >> programs still work, but they lose the checking. >> >>> I wrote a test for NT and the test fails for a different reason: our >>> TF handling appears broken as well. (Our sysenter TF handling is >>> *crap*, but it seems to work on 64-bit kernels at least.) >> >> TF should be entirely immaterial for system calls. Why would we care? >> We need it for correct handling of real traps, but not for the system >> call case afaik. Returning with TF clear is the right thing, since >> we're not returning *to* the system call instruction, but the >> instruction after. >> >>> My personal preference would be to add the missing popf. >> >> I don't mind adding the popf, but it won't help for iopl. Only iret >> restores iopl, if I recall correctly (but maybe I don't, and I'm too >> lazy to take the 30 seconds to look it up). >> >> Linus > > According to the SDM, popf will change IOPL only at CPL0, which is why > Xen (which runs at CPL1 on 32-bit) has a paravirt hook for it. But maybe we can ditch that paravirt hook and just modify regs->flags in sys_iopl. Xen never uses sysexit at all: /* XEN PV guests always use IRET path */ ALTERNATIVE "testl %eax, %eax; jz .Lsyscall_32_done", \ "jmp .Lsyscall_32_done", X86_FEATURE_XENPV and if we add the missing popf, we should be good to go. --Andy