Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1183098imu; Tue, 11 Dec 2018 14:18:29 -0800 (PST) X-Google-Smtp-Source: AFSGD/VUvGUcilk/i21dxR+bQqPrBYDWA25yOg34M4/eW/j+C6KusFh+RCQItCtgVHvOmXmd+FZd X-Received: by 2002:a63:cc12:: with SMTP id x18mr16073445pgf.33.1544566709165; Tue, 11 Dec 2018 14:18:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544566709; cv=none; d=google.com; s=arc-20160816; b=XJk+2fSwQyd4zzeeyjmwe0HzCHoxOhAbbLgRGDLEtdviUzhpywM6ykvMVb5M57SGrI wu7n39Z2xdM421/xuPrRf6HhT3ullvKPlYeU/kR0nyk8tXKOYQw9S8aid3amlyAGU1V7 hkxaYX0Fpzl79ycYyMZ/JQ2PM+pm2H4Bob26YwcBUDtb36LOowDFUUkx3RYKQEAKpulL YjlcN9+MhWQppLzQ1oWAJgc+zt4gd73YZO++I5tZStt1svLbB3Xb+9O4YzwsGFGjrj4p PWeyT9PgMKTbt3l8QgLrZmOTTZ9UTnL+U8fK1HW7P/pTfH92JoynVRsuPIM14mQkFRcG I/ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=XKR+ReJ0864Qvbh/bo6/Z5NNZOp0pWOHHTdGMquZaLk=; b=iw1q1cw+Bez/Y89vWM5tMOe+RUeWLtJH5h+XgW3GYqlOkhIHVBx0redmdGOglWNde6 a4qWmut3KY1gGRznD0ABFXjQlQ165B7pIWA6pjEpEg8WD1Si5MlARR7yykK1IeveCoF2 laHLRJXTIdR4xlPmJpBoA8inNZBgueeNlBuNMWlS5ZUGov09A9/mDHCz2Gebn9g+5GtS ZML52CNbc2GEppFhIs8Q41sFLOPXfFmuf0Ad10R0EFjgiT8GQXeQ1uycGBhrbU1ZLR4q OTyevO81HBITw7ENugXPc2CivbVcyXc+4URgiqRjAWqgtjNwqK+XRFWgIhdcLHPKbnRA bxHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a81si13809053pfj.195.2018.12.11.14.18.14; Tue, 11 Dec 2018 14:18:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726599AbeLKWPl (ORCPT + 99 others); Tue, 11 Dec 2018 17:15:41 -0500 Received: from pegase1.c-s.fr ([93.17.236.30]:51476 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726581AbeLKWPi (ORCPT ); Tue, 11 Dec 2018 17:15:38 -0500 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 43DvQc2388z9v0sP; Tue, 11 Dec 2018 23:15:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id i4ZDwfpi6__X; Tue, 11 Dec 2018 23:15:36 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 43DvQc1MzNz9v0sN; Tue, 11 Dec 2018 23:15:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 67CBF8B818; Tue, 11 Dec 2018 23:15:36 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id E5ORCR9wb88g; Tue, 11 Dec 2018 23:15:36 +0100 (CET) Received: from localhost.localdomain (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id E65B08B812; Tue, 11 Dec 2018 23:15:35 +0100 (CET) Subject: Re: [RFC PATCH v2 11/11] powerpc/book3s32: Implement Kernel Userspace Access Protection To: Russell Currey , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <76d777b36e54e7b8d4c196405decc712fc5eaf45.1543356926.git.christophe.leroy@c-s.fr> <98e37def51328f58d8c2ceb60edd4b3da7b6f2ef.1543356926.git.christophe.leroy@c-s.fr> From: Christophe Leroy Message-ID: Date: Tue, 11 Dec 2018 20:46:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/11/2018 05:25 AM, Russell Currey wrote: > On Wed, 2018-11-28 at 09:27 +0000, Christophe Leroy wrote: >> This patch implements Kernel Userspace Access Protection for >> book3s/32. >> >> Due to limitations of the processor page protection capabilities, >> the protection is only against writing. read protection cannot be >> achieved using page protection. >> >> In order to provide the protection, Ku and Ks keys are modified in >> Userspace Segment registers, and different PP bits are used to: >> >> PP01 provides RW for Key 0 and RO for Key 1 >> PP10 provides RW for all >> PP11 provides RO for all >> >> Today PP10 is used for RW pages and PP11 for RO pages. This patch >> modifies page protection to PP01 for RW pages. >> >> Then segment registers are set to Ku 0 and Ks 1. When kernel needs >> to write to RW pages, the associated segment register is changed to >> Ks 0 in order to allow write access to the kernel. >> >> In order to avoid having the read all segment registers when >> locking/unlocking the access, some data is kept in the thread_struct >> and saved on stack on exceptions. The field identifies both the >> first unlocked segment and the first segment following the last >> unlocked one. When no segment is unlocked, it contains value 0. >> >> Signed-off-by: Christophe Leroy > > Hey Christophe, I tried to test this and got a machine check after the > kernel starts init. A program check you mean ? > > Vector: 700 (Program Check) at [ef0b5e70] > pc: 00000ca4 > lr: b7e1a030 > sp: ef0b5f30 > msr: 81002 > current = 0xef0b8000 > pid = 1, comm = init > > Testing with mac99 model in qemu. That's pretty surprising. At 0xca4 there is nothing particular for me. This is a handler for system call. Do you have the same ? How can this trigger a program check ? According to the MSR, the check is due to an illegal instruction (bit 12). An we are with MMU off. c0000c00 : c0000c00: 7d 50 43 a6 mtsprg 0,r10 c0000c04: 7d 71 43 a6 mtsprg 1,r11 c0000c08: 7d 40 00 26 mfcr r10 c0000c0c: 7d 7b 02 a6 mfsrr1 r11 c0000c10: 71 6b 40 00 andi. r11,r11,16384 c0000c14: 3d 61 40 00 addis r11,r1,16384 c0000c18: 41 82 00 14 beq c0000c2c c0000c1c: 7d 73 42 a6 mfsprg r11,3 c0000c20: 81 6b fb d8 lwz r11,-1064(r11) c0000c24: 39 6b 20 00 addi r11,r11,8192 c0000c28: 3d 6b 40 00 addis r11,r11,16384 c0000c2c: 39 6b ff 40 addi r11,r11,-192 c0000c30: 91 4b 00 a8 stw r10,168(r11) c0000c34: 91 8b 00 40 stw r12,64(r11) c0000c38: 91 2b 00 34 stw r9,52(r11) c0000c3c: 7d 50 42 a6 mfsprg r10,0 c0000c40: 91 4b 00 38 stw r10,56(r11) c0000c44: 7d 91 42 a6 mfsprg r12,1 c0000c48: 91 8b 00 3c stw r12,60(r11) c0000c4c: 7d 48 02 a6 mflr r10 c0000c50: 91 4b 00 a0 stw r10,160(r11) c0000c54: 7d 9a 02 a6 mfsrr0 r12 c0000c58: 7d 3b 02 a6 mfsrr1 r9 c0000c5c: 90 2b 00 14 stw r1,20(r11) c0000c60: 90 2b 00 00 stw r1,0(r11) c0000c64: 3c 2b c0 00 addis r1,r11,-16384 c0000c68: 39 40 10 02 li r10,4098 c0000c6c: 7d 40 01 24 mtmsr r10 c0000c70: 90 0b 00 10 stw r0,16(r11) c0000c74: 3d 40 72 65 lis r10,29285 c0000c78: 39 4a 67 73 addi r10,r10,26483 c0000c7c: 91 4b 00 08 stw r10,8(r11) c0000c80: 90 6b 00 1c stw r3,28(r11) c0000c84: 90 8b 00 20 stw r4,32(r11) c0000c88: 90 ab 00 24 stw r5,36(r11) c0000c8c: 90 cb 00 28 stw r6,40(r11) c0000c90: 90 eb 00 2c stw r7,44(r11) c0000c94: 91 0b 00 30 stw r8,48(r11) c0000c98: 39 40 0c 01 li r10,3073 c0000c9c: 91 4b 00 b0 stw r10,176(r11) c0000ca0: 39 40 10 32 li r10,4146 c0000ca4: 51 2a 04 20 rlwimi r10,r9,0,16,16 c0000ca8: 48 01 13 5d bl c0012004 Christophe > > - Russell >