[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFw7P7LYNFQzy6nrn9DDn5a0UdYYQNx_7sibShvZPLEcmg@mail.gmail.com>
Date: Wed, 7 Aug 2013 12:47:53 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Grazvydas Ignotas <notasas@...il.com>,
Felipe Contreras <felipe.contreras@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...e.hu>,
Denys Vlasenko <dvlasenk@...hat.com>
Subject: Re: [PATCH 0/1] (Was: Linux 3.11-rc4)
On Wed, Aug 7, 2013 at 12:27 PM, Oleg Nesterov <oleg@...hat.com> wrote:
>
> I guess Grazvydas only meant the "unnecessary" align/len/type checks.
Yeah, some of them may be a bit questionable, but we don't necessarily
know what each microarchitecture does for unsupported ("undefined")
situations.
Intel actually has a lot of errata for their CPU's that they won't
fix, and they tend to be all about exactly the kinds of things that
the architecture manuals say "don't do this". Things like "TSS segment
crosses a page, and you take a page fault in the middle of a task
switch" etc.
Now, I do agree that the debug registers are *much* less likely to
have those kinds of really subtle issues, so maybe relaxing some of
the tests might be reasonable. I'd be a bit nervous about it, but if
it's *only* the length/alignment, and Intel people can be convinced
that it doesn't result in any nasty undefined behavior (as long as the
address is in user space), maybe we could make that change just to
make it easier for Wine.
But the kernel address checking definitely needs to stay around for
security reasons.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists