Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753619AbdLHNUK (ORCPT ); Fri, 8 Dec 2017 08:20:10 -0500 Received: from mail-pg0-f46.google.com ([74.125.83.46]:39753 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753079AbdLHNUE (ORCPT ); Fri, 8 Dec 2017 08:20:04 -0500 X-Google-Smtp-Source: AGs4zMZJi4KWyWeAF3zyfJez4tOPgh+owsDtWqZQkAoXpb8Rlmv9Q+Mkjt9O1p+cnfvEezfdmia/7A== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] LDT improvements From: Andy Lutomirski X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Fri, 8 Dec 2017 05:20:00 -0800 Cc: Ingo Molnar , Andy Lutomirski , Borislav Petkov , X86 ML , "linux-kernel@vger.kernel.org" , Brian Gerst , David Laight , Kees Cook , Peter Zijlstra Message-Id: <6363C18D-D84A-40E4-8ED4-FE996609467B@amacapital.net> References: <48fe5cf1382d6a95c7b1837415882edcc81a9781.1512631324.git.luto@kernel.org> <20171207124347.p7kdj7q4qqs3ivri@pd.tnic> <665F1CA8-D012-4465-B5F7-E81E088847DB@amacapital.net> <20171208073454.dicyefwncsihq7sm@gmail.com> To: Thomas Gleixner Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vB8DKEg8024734 Content-Length: 1777 Lines: 45 > On Dec 8, 2017, at 1:34 AM, Thomas Gleixner wrote: > >> On Fri, 8 Dec 2017, Ingo Molnar wrote: >> * Andy Lutomirski wrote: >>> I don't love mucking with user address space. I'm also quite nervous about >>> putting it in our near anything that could pass an access_ok check, since we're >>> totally screwed if the bad guys can figure out how to write to it. >> >> Hm, robustness of the LDT address wrt. access_ok() is a valid concern. >> >> Can we have vmas with high addresses, in the vmalloc space for example? >> IIRC the GPU code has precedents in that area. >> >> Since this is x86-64, limitation of the vmalloc() space is not an issue. >> >> I like Thomas's solution: >> >> - have the LDT in a regular mmap space vma (hence per process ASLR randomized), >> but with the system bit set. >> >> - That would be an advantage even for non-PTI kernels, because mmap() is probably >> more randomized than kmalloc(). > > Randomization is pointless as long as you can get the LDT address in user > space, i.e. w/o UMIP. You only get the LDT selector, not the address. > >> - It would also be a cleaner approach all around, and would avoid the fixmap >> complications and the scheduler muckery. > > The error code of such an access is always 0x03. So I added a special > handler, which checks whether the address is in the LDT map range and > verifies that the access bit in the descriptor is 0. If that's the case it > sets it and returns. If not, the thing dies. That works. What if you are in kernel mode and try to return to a context with SS or CS pointing to a non-accessed segment? Or what if you try to schedule to a context with fs or, worse, gs pointing to such a segment? > > Thanks, > > tglx