From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754298AbdKAIGx (ORCPT <rfc822;w@1wt.eu>);
        Wed, 1 Nov 2017 04:06:53 -0400
Received: from mail-wr0-f195.google.com ([209.85.128.195]:46931 "EHLO
        mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754246AbdKAIGq (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 1 Nov 2017 04:06:46 -0400
X-Google-Smtp-Source: ABhQp+TYs183wAhMzoYsGAK7/rUSExXHyXGlPuuETBeN3RZk/uvRsWULD/hz74bo6GlBhrmS7jTrOQ==
Date: Wed, 1 Nov 2017 09:06:42 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>, moritz.lipp@iaik.tugraz.at,
        daniel.gruss@iaik.tugraz.at, michael.schwarz@iaik.tugraz.at,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Kees Cook <keescook@google.com>, Hugh Dickins <hughd@google.com>,
        X86 ML <x86@kernel.org>
Subject: Re: [PATCH 12/23] x86, kaiser: map dynamically-allocated LDTs
Message-ID: <20171101080642.6rvmrt3ec6d27zki@gmail.com>
References: <20171031223146.6B47C861@viggo.jf.intel.com>
 <20171031223208.F271E813@viggo.jf.intel.com>
 <CALCETrVbGHJUeZP2X36s-gUcEywpv_uuAwZRVAJWL5U8DijPkQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrVbGHJUeZP2X36s-gUcEywpv_uuAwZRVAJWL5U8DijPkQ@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Andy Lutomirski <luto@kernel.org> wrote:

> On Tue, Oct 31, 2017 at 3:32 PM, Dave Hansen
> <dave.hansen@linux.intel.com> wrote:
> >
> > Normally, a process just has a NULL mm->context.ldt.  But, we
> > have a syscall for a process to set a new one.  If a process does
> > that, we need to map the new LDT.
> >
> > The original KAISER patch missed this case.
> 
> Tglx suggested that we instead increase the padding at the top of the
> user address space from 4k to 64k and put the LDT there.  This is a
> slight ABI break, but I'd be rather surprised if anything noticed,
> especially because the randomized vdso currently regularly lands there
> (IIRC), so any user code that explicitly uses those 60k already
> collides with the vdso.
> 
> I can make this happen.

Yes, let's try that.

Thanks,

	Ingo