lkml.org 
[lkml]   [2018]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v2 11/11] powerpc/book3s32: Implement Kernel Userspace Access Protection
From
Date


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 <christophe.leroy@c-s.fr>
>
> 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 <SystemCall>:
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 <SystemCall+0x2c>
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 <transfer_to_handler>

Christophe

>
> - Russell
>

\
 
 \ /
  Last update: 2018-12-11 23:16    [W:0.049 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site