I tried going back to a January commit
cf4d5fa114d4825eb59f82e48ccd683eb9a4b442 UPSTREAM: crypto: salsa20 - fix blkcipher_walk API usage

and it worked for me on caroline

Thanks.  I'll do a bisect.

I'll bet it's KPTI missing a mapping somewhere...

semenzato@luigi:~/.../third_party/kernel/v3.18$ git bisect log
# bad: [a2b13ac7448907a7cc272f1cb16e8e6e520092bd] UPSTREAM: KVM: X86: Fix load RFLAGS w/o the fixed bit
# good: [cf4d5fa114d4825eb59f82e48ccd683eb9a4b442] UPSTREAM: crypto: salsa20 - fix blkcipher_walk API usage
git bisect start 'a2b13ac7448907a7cc272f1cb16e8e6e520092bd' 'cf4d5fa114d4825eb'
# good: [fc3884617930ff550c3192353e22ff5a1d97111c] CHROMIUM: iwl7000: chromeOS: move genetlink.h and crypto.h below rhashtable.h
git bisect good fc3884617930ff550c3192353e22ff5a1d97111c
# skip: [953ddc2e38dd1219dc9e656af711428bb2c83de4] ANDROID: FROMLIST: binder: add spinlock to protect binder_node
git bisect skip 953ddc2e38dd1219dc9e656af711428bb2c83de4
# good: [e8eae3e19046d9cda7e11d96ba8e42e862c9afcb] ANDROID: FROMLIST: android: binder: Add allocator selftest
git bisect good e8eae3e19046d9cda7e11d96ba8e42e862c9afcb
# bad: [479af323cfd21deb24890cf6c7b3c881aa1e7687] UPSTREAM: x86, tls, ldt: Stop checking lm in LDT_empty
git bisect bad 479af323cfd21deb24890cf6c7b3c881aa1e7687
# bad: [70a45c0200e3436587ed1a698927a387bbff1a7c] UPSTREAM: ALSA: seq: Don't allow resizing pool in use
git bisect bad 70a45c0200e3436587ed1a698927a387bbff1a7c
# good: [1b2110766b1e20761e32454f31f02381a8c0c2d3] BACKPORT: tpm_tis: Move ilb_base_addr to tpm_tis_data
git bisect good 1b2110766b1e20761e32454f31f02381a8c0c2d3
# good: [7b395110babfce6eff2db92067e4923659f8866b] CHROMIUM: iwl7000: mvm: allow unknown crypto RX outside aggregation
git bisect good 7b395110babfce6eff2db92067e4923659f8866b
# skip: [8df5862c8b40b48f54102968f8210749aa211fd4] CHROMIUM: iwl7000: Merge core35 driver updates
git bisect skip 8df5862c8b40b48f54102968f8210749aa211fd4
# bad: [b3f52b891347ee623ec4e5ce6ee637d7005aab7b] CHROMIUM: Revert "net: socket ioctl to reset connections matching local address"
git bisect bad b3f52b891347ee623ec4e5ce6ee637d7005aab7b
# bad: [330699d6c2a0d8ef5c32066c750ab8a4d107c524] BACKPORT: x86/entry/64: Don't use IST entry for #BP stack
git bisect bad 330699d6c2a0d8ef5c32066c750ab8a4d107c524
# good: [841e3be21933ab800961ea9cf7847f0582fe72ed] BACKPORT: tpm: Keep CLKRUN enabled throughout the duration of transmit_cmd()
git bisect good 841e3be21933ab800961ea9cf7847f0582fe72ed


So this seems to be the bad patch.

I know Andy.  Should Guido and I have a chat with him?


commit 330699d6c2a0d8ef5c32066c750ab8a4d107c524 (HEAD, refs/bisect/bad)
Author:     Andy Lutomirski <luto@kernel.org>
AuthorDate: Thu Jul 23 15:37:48 2015 -0700
Commit:     chrome-bot <chrome-bot@chromium.org>
CommitDate: Wed Apr 11 14:55:44 2018 -0700

    BACKPORT: x86/entry/64: Don't use IST entry for #BP stack
    
    There's nothing IST-worthy about #BP/int3.  We don't allow kprobes
    in the small handful of places in the kernel that run at CPL0 with
    an invalid stack, and 32-bit kernels have used normal interrupt
    gates for #BP forever.
    
    Furthermore, we don't allow kprobes in places that have usergs while
    in kernel mode, so "paranoid" is also unnecessary.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    
    BUG=chromium:831269
    TEST=Build and boot
    
    Change-Id: I2bb5aece3c789aa3d845d03c9b57f10daf30fd60
    [backport: Context and file name changes. Changes in trap_init do not apply.]
    Signed-off-by: Guenter Roeck <groeck@chromium.org>
    (cherry picked from commit d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9)
    Reviewed-on: https://chromium-review.googlesource.com/1005885
    Reviewed-by: Dylan Reid <dgreid@chromium.org>

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 9c24797e8039..a46834d89f9a 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1345,7 +1345,7 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
 #endif /* CONFIG_HYPERV */
 
 idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
-idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
+idtentry int3 do_int3 has_error_code=0
 idtentry stack_segment do_stack_segment has_error_code=1
 #ifdef CONFIG_XEN
 idtentry xen_debug do_debug has_error_code=0
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index de801f22128a..2097c8efc437 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -334,7 +334,6 @@ exit:
 }
 NOKPROBE_SYMBOL(do_general_protection);
 
-/* May run on IST stack. */
 dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
 {
        enum ctx_state prev_state;
@@ -367,15 +366,9 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
                        SIGTRAP) == NOTIFY_STOP)
                goto exit;
 
-       /*
-        * Let others (NMI) know that the debug stack is in use
-        * as we may switch to the interrupt stack.
-        */
-       debug_stack_usage_inc();
        preempt_conditional_sti(regs);
        do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL);
        preempt_conditional_cli(regs);
-       debug_stack_usage_dec();
 exit:
        exception_exit(prev_state);
 }

Actually, I suspect that this patch is interfering with some previous security patch which we created or backported.

At this point I invoke the help of the security folks.

It looks like Guenter did the backport and may have done some of the other security backports -- any ideas?

Also, did you try to revert just that one commit and see if it starts working?

Unfortunate but not too surprising. I agree with Kees - probably something essential is missing from the backport. If reverting this patch makes it work, I would suggest to go with it. Otherwise, we'll have to dig into it.

#7 yes, reverting this on ToT is possible and makes the bug go away.  Thanks!

Revert at https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1069421

This was fixed with a revert.  Please see issue 831269 (restricted).