[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1f471c85-dcda-ed3f-299e-8baf68fb55fd@redhat.com>
Date: Wed, 8 Nov 2017 18:24:37 +0100
From: Denys Vlasenko <dvlasenk@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Anvin <hpa@...or.com>, Borislav Petkov <bp@...e.de>,
Vlastimil Babka <vbabka@...e.cz>,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Brian Gerst <brgerst@...il.com>,
Jonathan Corbet <corbet@....net>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
ricardo.neri-calderon@...ux.intel.com,
Chris Metcalf <cmetcalf@...lanox.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Andrew Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>, ray.huang@....com,
"Michael S. Tsirkin" <mst@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Chen Yucong <slaoub@...il.com>, Ingo Molnar <mingo@...nel.org>,
Jiri Slaby <jslaby@...e.cz>, Shuah Khan <shuah@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions
On 11/08/2017 06:14 PM, Paolo Bonzini wrote:
> On 08/11/2017 18:09, Denys Vlasenko wrote:
>> On 11/08/2017 05:57 PM, Linus Torvalds wrote:
>>> On Wed, Nov 8, 2017 at 8:53 AM, Denys Vlasenko <dvlasenk@...hat.com>
>>> wrote:
>>>> We can postpone enabling UMIP by default by a year or so.
>>>> By this time, new Wine will be on majority of users' machines.
>>>
>>> So you are suggesting we run unnecessarily insecure, only in order to
>>> not do the emulation that we already have the code for and that the
>>> patch implements?
>>
>> We ran insecure in this way for ~25 years.
>>
>>> Why?
>>
>> To avoid having to maintain more obscure, rarely executed code.
>
> As a start, you could propose a patch to disable the emulation code
> through a sysctl or Kconfig symbol.
This way, the emulation code will still be in the kernel, and still
need to be maintained.
In my opinion, if we do emulate these insns, then adding even more code
to disable that emulation is not worth doing.
> I would be surprised if it takes
> more time than what you've spent writing emails in this thread.
Yes, I not only f**ing retarded, I'm also lazy. Thanks guys...
Powered by blists - more mailing lists