linux-kernel - Re: [RFC PATCH v2 11/11] powerpc/book3s32: Implement Kernel Userspace Access Protection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fa21d262-1d44-6303-94a5-37fe2f060132@c-s.fr>
Date:   Tue, 11 Dec 2018 20:46:24 +0000
From:   Christophe Leroy <christophe.leroy@....fr>
To:     Russell Currey <ruscur@...sell.cc>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH v2 11/11] powerpc/book3s32: Implement Kernel Userspace
 Access Protection



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@....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
>