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 S1755003AbdEFI3F (ORCPT <rfc822;w@1wt.eu>);
        Sat, 6 May 2017 04:29:05 -0400
Received: from mrelay.tugraz.at ([129.27.2.203]:11968 "EHLO mrelay.tugraz.at"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750907AbdEFI26 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 6 May 2017 04:28:58 -0400
Subject: Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map
 kernel in user mode
To: Jann Horn <jannh@google.com>
References: <9df77051-ac01-bfe9-3cf7-4c2ecbcb9292@iaik.tugraz.at>
 <CAG48ez2UB0iv50091h8-Xucp93GKdx=uyqD_HQY2YfAP_zqwSg@mail.gmail.com>
 <CAG48ez1b0_WmjHABWukEcnLrV+beotynnAwz_scRss45uVB93g@mail.gmail.com>
CC: kernel list <linux-kernel@vger.kernel.org>,
        <kernel-hardening@lists.openwall.com>,
        "clementine.maurice@iaik.tugraz.at" 
        <clementine.maurice@iaik.tugraz.at>,
        "moritz.lipp@iaik.tugraz.at" <moritz.lipp@iaik.tugraz.at>,
        Michael Schwarz <michael.schwarz@iaik.tugraz.at>,
        Richard Fellner <richard.fellner@student.tugraz.at>,
        <kirill.shutemov@linux.intel.com>, "Ingo Molnar" <mingo@kernel.org>,
        "anders.fogh@gdata-adan.de" <anders.fogh@gdata-adan.de>
From: Daniel Gruss <daniel.gruss@iaik.tugraz.at>
Message-ID: <dd7fd5dd-8038-a871-bdee-7b253078b933@iaik.tugraz.at>
Date: Sat, 6 May 2017 10:28:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAG48ez1b0_WmjHABWukEcnLrV+beotynnAwz_scRss45uVB93g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [80.110.159.138]
X-ClientProxiedBy: EXCG01-EXT.iaik.tugraz.at (2002:811b:98d3::811b:98d3) To
 EXCG01-INT.iaik.tugraz.at (2002:811b:981a::811b:981a)
X-TM-AS-Product-Ver: SMEX-12.0.0.1464-8.100.1062-23052.002
X-TM-AS-Result: No--3.258700-0.000000-31
X-TM-AS-MatchedID: 150567-700075-139010-711432-703523-702638-709185-703267-7
        04473-703938-702762-148004-148040-148133-41000-42000-42003
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-TUG-Backscatter-control: IqAlG2Mm08USmfDJcRVXXA
X-Spam-Scanner: SpamAssassin 3.003001 
X-Spam-Score-relay: -1.9
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2017-05-05 17:53, Jann Horn wrote:
> Ah, I think I understand. The kernel stacks are mapped, but
> cpu_current_top_of_stack isn't, so you can't find the stack until after the CR3
> switch in the syscall handler?

That's the idea. Only the absolute minimum that is required for a 
context switch remains mapped (+ it is mapped at an offset which does 
not depend on KASLR -> we do not leak the KASLR offsets).

From mboxrd@z Thu Jan  1 00:00:00 1970
References: <9df77051-ac01-bfe9-3cf7-4c2ecbcb9292@iaik.tugraz.at>
 <CAG48ez2UB0iv50091h8-Xucp93GKdx=uyqD_HQY2YfAP_zqwSg@mail.gmail.com>
 <CAG48ez1b0_WmjHABWukEcnLrV+beotynnAwz_scRss45uVB93g@mail.gmail.com>
From: Daniel Gruss <daniel.gruss@iaik.tugraz.at>
Message-ID: <dd7fd5dd-8038-a871-bdee-7b253078b933@iaik.tugraz.at>
Date: Sat, 6 May 2017 10:28:30 +0200
MIME-Version: 1.0
In-Reply-To: <CAG48ez1b0_WmjHABWukEcnLrV+beotynnAwz_scRss45uVB93g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map
 kernel in user mode
To: Jann Horn <jannh@google.com>
Cc: kernel list <linux-kernel@vger.kernel.org>, kernel-hardening@lists.openwall.com, "clementine.maurice@iaik.tugraz.at" <clementine.maurice@iaik.tugraz.at>, "moritz.lipp@iaik.tugraz.at" <moritz.lipp@iaik.tugraz.at>, Michael Schwarz <michael.schwarz@iaik.tugraz.at>, Richard Fellner <richard.fellner@student.tugraz.at>, kirill.shutemov@linux.intel.com, Ingo
 Molnar <mingo@kernel.org>, "anders.fogh@gdata-adan.de" <anders.fogh@gdata-adan.de>
List-ID: <kernel-hardening.lists.openwall.com>

On 2017-05-05 17:53, Jann Horn wrote:
> Ah, I think I understand. The kernel stacks are mapped, but
> cpu_current_top_of_stack isn't, so you can't find the stack until after the CR3
> switch in the syscall handler?

That's the idea. Only the absolute minimum that is required for a 
context switch remains mapped (+ it is mapped at an offset which does 
not depend on KASLR -> we do not leak the KASLR offsets).