<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-linux/arch/powerpc/kernel/head_32.h, branch jd/unified-crypt-queue</title>
<subtitle>WireGuard for the Linux kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-linux/atom/arch/powerpc/kernel/head_32.h?h=jd%2Funified-crypt-queue</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-linux/atom/arch/powerpc/kernel/head_32.h?h=jd%2Funified-crypt-queue'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/'/>
<updated>2020-03-10T04:16:42Z</updated>
<entry>
<title>Merge branch 'fixes' into next</title>
<updated>2020-03-10T04:16:42Z</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2020-03-10T04:16:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=819723a8a2fb66678fe15d177ae56af38163f364'/>
<id>urn:sha1:819723a8a2fb66678fe15d177ae56af38163f364</id>
<content type='text'>
Merge in our fixes branch. In particular we want to merge the TM and KUAP fixes,
so we can add selftests for them in next.
</content>
</entry>
<entry>
<title>powerpc: Don't use thread struct for saving SRR0/1 on syscall.</title>
<updated>2020-02-19T11:46:08Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2020-01-31T11:34:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=c06f0aff035ed5a7eaff5daa8e11e7ad28ab0d54'/>
<id>urn:sha1:c06f0aff035ed5a7eaff5daa8e11e7ad28ab0d54</id>
<content type='text'>
CR0 can be saved later, and CTR can also be used for saving.

Keep SRR1 in r9 and stash SRR0 in CTR, this avoids using thread_struct
in memory for that.

Saves 3 cycles (ie 1%) in null_syscall selftest on 8xx.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/b94c3bc03bac9431fec2dadb686384c481889422.1580470483.git.christophe.leroy@c-s.fr
</content>
</entry>
<entry>
<title>powerpc/32: Warn and return ENOSYS on syscalls from kernel</title>
<updated>2020-02-19T11:46:08Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2020-01-31T11:34:54Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=9e27086292aa880921a0f2b8501e5189d5efcf03'/>
<id>urn:sha1:9e27086292aa880921a0f2b8501e5189d5efcf03</id>
<content type='text'>
Since commit b86fb88855ea ("powerpc/32: implement fast entry for
syscalls on non BOOKE") and commit 1a4b739bbb4f ("powerpc/32:
implement fast entry for syscalls on BOOKE"), syscalls from
kernel are unexpected and can have catastrophic consequences
as it will destroy the kernel stack.

Test MSR_PR on syscall entry. In case syscall is from kernel,
emit a warning and return ENOSYS error.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/8ee3bdbbdfdfc64ca7001e90c43b2aee6f333578.1580470482.git.christophe.leroy@c-s.fr
</content>
</entry>
<entry>
<title>powerpc/32s: Fix DSI and ISI exceptions for CONFIG_VMAP_STACK</title>
<updated>2020-02-18T10:31:11Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2020-02-15T10:14:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=232ca1eecafed8c54491017f0612c33d8c742d74'/>
<id>urn:sha1:232ca1eecafed8c54491017f0612c33d8c742d74</id>
<content type='text'>
hash_page() needs to read page tables from kernel memory. When entire
kernel memory is mapped by BATs, which is normally the case when
CONFIG_STRICT_KERNEL_RWX is not set, it works even if the page hosting
the page table is not referenced in the MMU hash table.

However, if the page where the page table resides is not covered by
a BAT, a DSI fault can be encountered from hash_page(), and it loops
forever. This can happen when CONFIG_STRICT_KERNEL_RWX is selected
and the alignment of the different regions is too small to allow
covering the entire memory with BATs. This also happens when
CONFIG_DEBUG_PAGEALLOC is selected or when booting with 'nobats'
flag.

Also, if the page containing the kernel stack is not present in the
MMU hash table, registers cannot be saved and a recursive DSI fault
is encountered.

To allow hash_page() to properly do its job at all time and load the
MMU hash table whenever needed, it must run with data MMU disabled.
This means it must be called before re-enabling data MMU. To allow
this, registers clobbered by hash_page() and create_hpte() have to
be saved in the thread struct together with SRR0, SSR1, DAR and DSISR.
It is also necessary to ensure that DSI prolog doesn't overwrite
regs saved by prolog of the current running exception. That means:
- DSI can only use SPRN_SPRG_SCRATCH0
- Exceptions must free SPRN_SPRG_SCRATCH0 before writing to the stack.

This also fixes the Oops reported by Erhard when create_hpte() is
called by add_hash_page().

Due to prolog size increase, a few more exceptions had to get split
in two parts.

Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
Reported-by: Erhard F. &lt;erhard_f@mailbox.org&gt;
Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Tested-by: Erhard F. &lt;erhard_f@mailbox.org&gt;
Tested-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206501
Link: https://lore.kernel.org/r/64a4aa44686e9fd4b01333401367029771d9b231.1581761633.git.christophe.leroy@c-s.fr
</content>
</entry>
<entry>
<title>powerpc/32s: Enable CONFIG_VMAP_STACK</title>
<updated>2020-01-27T11:37:24Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2019-12-21T08:32:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=cd08f109e26231b279bcc0388428afcac6408ec6'/>
<id>urn:sha1:cd08f109e26231b279bcc0388428afcac6408ec6</id>
<content type='text'>
A few changes to retrieve DAR and DSISR from struct regs
instead of retrieving them directly, as they may have
changed due to a TLB miss.

Also modifies hash_page() and friends to work with virtual
data addresses instead of physical ones. Same on load_up_fpu()
and load_up_altivec().

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
[mpe: Fix tovirt_vmstack call in head_32.S to fix CHRP build]
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/2e2509a242fd5f3e23df4a06530c18060c4d321e.1576916812.git.christophe.leroy@c-s.fr
</content>
</entry>
<entry>
<title>powerpc/32: Add early stack overflow detection with VMAP stack.</title>
<updated>2020-01-27T11:35:49Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2019-12-21T08:32:29Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=3978eb78517c1fc06dd75405d732af45c80f5bd2'/>
<id>urn:sha1:3978eb78517c1fc06dd75405d732af45c80f5bd2</id>
<content type='text'>
To avoid recursive faults, stack overflow detection has to be
performed before writing in the stack in exception prologs.

Do it by checking the alignment. If the stack pointer alignment is
wrong, it means it is pointing to the following or preceding page.

Without VMAP stack, a stack overflow is catastrophic. With VMAP
stack, a stack overflow isn't destructive, so don't panic. Kill
the task with SIGSEGV instead.

A dedicated overflow stack is set up for each CPU.

  lkdtm: Performing direct entry EXHAUST_STACK
  lkdtm: Calling function with 512 frame size to depth 32 ...
  lkdtm: loop 32/32 ...
  lkdtm: loop 31/32 ...
  lkdtm: loop 30/32 ...
  lkdtm: loop 29/32 ...
  lkdtm: loop 28/32 ...
  lkdtm: loop 27/32 ...
  lkdtm: loop 26/32 ...
  lkdtm: loop 25/32 ...
  lkdtm: loop 24/32 ...
  lkdtm: loop 23/32 ...
  lkdtm: loop 22/32 ...
  lkdtm: loop 21/32 ...
  lkdtm: loop 20/32 ...
  Kernel stack overflow in process test[359], r1=c900c008
  Oops: Kernel stack overflow, sig: 6 [#1]
  BE PAGE_SIZE=4K MMU=Hash PowerMac
  Modules linked in:
  CPU: 0 PID: 359 Comm: test Not tainted 5.3.0-rc7+ #2225
  NIP:  c0622060 LR: c0626710 CTR: 00000000
  REGS: c0895f48 TRAP: 0000   Not tainted  (5.3.0-rc7+)
  MSR:  00001032 &lt;ME,IR,DR,RI&gt;  CR: 28004224  XER: 00000000
  GPR00: c0626ca4 c900c008 c783c000 c07335cc c900c010 c07335cc c900c0f0 c07335cc
  GPR08: c900c0f0 00000001 00000000 00000000 28008222 00000000 00000000 00000000
  GPR16: 00000000 00000000 10010128 10010000 b799c245 10010158 c07335cc 00000025
  GPR24: c0690000 c08b91d4 c068f688 00000020 c900c0f0 c068f668 c08b95b4 c08b91d4
  NIP [c0622060] format_decode+0x0/0x4d4
  LR [c0626710] vsnprintf+0x80/0x5fc
  Call Trace:
  [c900c068] [c0626ca4] vscnprintf+0x18/0x48
  [c900c078] [c007b944] vprintk_store+0x40/0x214
  [c900c0b8] [c007bf50] vprintk_emit+0x90/0x1dc
  [c900c0e8] [c007c5cc] printk+0x50/0x60
  [c900c128] [c03da5b0] recursive_loop+0x44/0x6c
  [c900c338] [c03da5c4] recursive_loop+0x58/0x6c
  [c900c548] [c03da5c4] recursive_loop+0x58/0x6c
  [c900c758] [c03da5c4] recursive_loop+0x58/0x6c
  [c900c968] [c03da5c4] recursive_loop+0x58/0x6c
  [c900cb78] [c03da5c4] recursive_loop+0x58/0x6c
  [c900cd88] [c03da5c4] recursive_loop+0x58/0x6c
  [c900cf98] [c03da5c4] recursive_loop+0x58/0x6c
  [c900d1a8] [c03da5c4] recursive_loop+0x58/0x6c
  [c900d3b8] [c03da5c4] recursive_loop+0x58/0x6c
  [c900d5c8] [c03da5c4] recursive_loop+0x58/0x6c
  [c900d7d8] [c03da5c4] recursive_loop+0x58/0x6c
  [c900d9e8] [c03da5c4] recursive_loop+0x58/0x6c
  [c900dbf8] [c03da5c4] recursive_loop+0x58/0x6c
  [c900de08] [c03da67c] lkdtm_EXHAUST_STACK+0x30/0x4c
  [c900de18] [c03da3e8] direct_entry+0xc8/0x140
  [c900de48] [c029fb40] full_proxy_write+0x64/0xcc
  [c900de68] [c01500f8] __vfs_write+0x30/0x1d0
  [c900dee8] [c0152cb8] vfs_write+0xb8/0x1d4
  [c900df08] [c0152f7c] ksys_write+0x58/0xe8
  [c900df38] [c0014208] ret_from_syscall+0x0/0x34
  --- interrupt: c01 at 0xf806664
      LR = 0x1000c868
  Instruction dump:
  4bffff91 80010014 7c832378 7c0803a6 38210010 4e800020 3d20c08a 3ca0c089
  8089a0cc 38a58f0c 38600001 4ba2d494 &lt;9421ffe0&gt; 7c0802a6 bfc10018 7c9f2378

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/1b89c121b4070c7ee99e4f22cc178f15a736b07b.1576916812.git.christophe.leroy@c-s.fr
</content>
</entry>
<entry>
<title>powerpc/32: prepare for CONFIG_VMAP_STACK</title>
<updated>2020-01-26T11:15:09Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2019-12-21T08:32:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=028474876f472c3b6eee633aed528a1206609657'/>
<id>urn:sha1:028474876f472c3b6eee633aed528a1206609657</id>
<content type='text'>
To support CONFIG_VMAP_STACK, the kernel has to activate Data MMU
Translation for accessing the stack. Before doing that it must save
SRR0, SRR1 and also DAR and DSISR when relevant, in order to not
loose them in case there is a Data TLB Miss once the translation is
reactivated.

This patch adds fields in thread struct for saving those registers.
It prepares entry_32.S to handle exception entry with
Data MMU Translation enabled and alters EXCEPTION_PROLOG macros to
save SRR0, SRR1, DAR and DSISR then reenables Data MMU.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/a775a1fea60f190e0f63503463fb775310a2009b.1576916812.git.christophe.leroy@c-s.fr
</content>
</entry>
<entry>
<title>powerpc/32: add a macro to get and/or save DAR and DSISR on stack.</title>
<updated>2020-01-26T11:15:09Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2019-12-21T08:32:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=c9c84fd945bbaadbf69d953be308e6f35737fef6'/>
<id>urn:sha1:c9c84fd945bbaadbf69d953be308e6f35737fef6</id>
<content type='text'>
Refactor reading and saving of DAR and DSISR in exception vectors.

This will ease the implementation of VMAP stack.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/1286b3e51b07727c6b4b05f2df9af3f9b1717fb5.1576916812.git.christophe.leroy@c-s.fr
</content>
</entry>
<entry>
<title>powerpc/32: move MSR_PR test into EXCEPTION_PROLOG_0</title>
<updated>2020-01-26T11:15:09Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2019-12-21T08:32:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=5ae8fabc644632d31babbc7162aa876c79aaadb3'/>
<id>urn:sha1:5ae8fabc644632d31babbc7162aa876c79aaadb3</id>
<content type='text'>
In order to simplify  VMAP stack implementation, move
MSR_PR test into EXCEPTION_PROLOG_0.

This requires to not modify cr0 between EXCEPTION_PROLOG_0
and EXCEPTION_PROLOG_1.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/5c8b5bba692b92654dbd363a229a1ba91db725bb.1576916812.git.christophe.leroy@c-s.fr
</content>
</entry>
<entry>
<title>powerpc/32: Add EXCEPTION_PROLOG_0 in head_32.h</title>
<updated>2020-01-26T11:15:08Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2019-12-21T08:32:23Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=1f1c4d0122eebd204468684f21f0270ea8a4999d'/>
<id>urn:sha1:1f1c4d0122eebd204468684f21f0270ea8a4999d</id>
<content type='text'>
This patch creates a macro for the very first part of
exception prolog, this will help when implementing
CONFIG_VMAP_STACK

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/2249fe62f481121a180e9655ad2b998093f318f3.1576916812.git.christophe.leroy@c-s.fr
</content>
</entry>
</feed>
