Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1726670ybt; Mon, 15 Jun 2020 07:56:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzd5gqptDhjueYT/IoNaCYzPa03q76ZmboupWVEukaJQGsy1ZeKsjQUpE90OrjO9UhktKBH X-Received: by 2002:a50:e881:: with SMTP id f1mr23256553edn.98.1592232966746; Mon, 15 Jun 2020 07:56:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592232966; cv=none; d=google.com; s=arc-20160816; b=KksiJ00fP+Sxu4i1V9T4G0VdyRTxkM38B6tWyAJH6MmuhrgFCTHb0t8lFK1UyRYLo0 /XuOfRXq2TdO+ry3N/xq3yUEZAWyr+afdCIELvtR9fcYJiW04d2CJ+NOcZ4/UdIpJ5F2 k5ncEAix5XItv+wgNQY4DF/2Wu7gjTVy/gfe0dSGMRiVS+0Rxb0y0h7EJmLSk47BRNb/ 67s46bBBAHo7MUqSSVjsS/nMkTWqvdZB3vcCyXQKmTxD9Hn3d3B2vWphwyhC8CLEtulO 6rtiKX0MddlQcta2WEQ8UE8iqHF95zg0aiOsXaCgF7jr+IaYF+WjIW3y+9Q8LH7Gi5JX 7QRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=TO/UlS5nQwaskSKkWnxhtbr58cxMAZAbeQDdoacE6pI=; b=heM6zwjr05mqI1q9MsaMDF4oGn8zuzTLRtAV8Pj2fWqrfasrp1DhQPTSq0sxfvBuDd ZrH3TfxOqgPwPv9Sz8gcaIutAFo5TbKmNJPswWOWnFo2KjQ1sSOIjjZFrzHdBTCiY6LD hAt20BH6eepysEY2crML4VkV73bvTnONRBwgYfj2cwDKNIAjjX2WLhKho0zcigZtIPZ9 u9hejAxU843d3aGUABiT6xe07OGzZiFEAOaSZ0DUHSphJifGEbz2ISGjHz+1m0y2Ezit RSp4UEPoM7tFe91TgX8QMt5/nr7mjJHiZUIpOaOu3ffBKfNLl0ehKtBoroehYfZVeHuD YJhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=pGbdVD61; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk19si8484280edb.446.2020.06.15.07.55.44; Mon, 15 Jun 2020 07:56:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=pGbdVD61; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730789AbgFOOxq (ORCPT + 99 others); Mon, 15 Jun 2020 10:53:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730529AbgFOOxp (ORCPT ); Mon, 15 Jun 2020 10:53:45 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90ACEC061A0E for ; Mon, 15 Jun 2020 07:53:44 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id r9so14958335wmh.2 for ; Mon, 15 Jun 2020 07:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TO/UlS5nQwaskSKkWnxhtbr58cxMAZAbeQDdoacE6pI=; b=pGbdVD61bJ5VXk7tPHS9VeyRR1c449xy+yOAiFLWktnxVI5RGEPjXKHzyoAQ/HB7Xv g/jTZqHr8NXLeCjbGKe7oW7GrT8VdnM20DSsCwZ0R5/gMhf5zpOWfx74tRx1aCqYAEyT MUezcBhiKZRgvqGVf6acB/crB0YnbfkBZrFbZL+IH2LiJKXCPkOmDTqMP3iuDGAUGYCB I2BBhxF8G6hQ31pMB4dwjOp73L+bMb/fkN4QOU9cYT7po6BQF6rOCoCxxLM/Hge69Szf RqNpg0f80hMy8P/P7NDKZFxLi4kV6HghZOkM5Nx6oKs9p34w8bDqlJLE5Ejf1GWKq/bW huzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TO/UlS5nQwaskSKkWnxhtbr58cxMAZAbeQDdoacE6pI=; b=ffCEfZR/JGzKfZUzO30Vj6LC/QnvpRTMnPmaAelQohSD0Sr19Noi31hzBYZLQcqHYY ArvBYkspGSI6w6jjqtSTs0PLTidtl9Cpi2B/3NYFjsh5BJc1owe+98KjSsmm3ctz9Diz M653dJWlKn/fXJYRI2JX/RNvhq5BA26Qtze5MMlYVzo8uHT5t7fWesU7U0cuFRcYW6DW RjJYDGCudHSqPMYcWrRgpDBFgeeXnVkF0HE+ykK6ahvzEGX8yLGo6x+WQJc9UWvxjAV5 1rzrWDWt7w05PwQmmwcYaDntDD1bP/iVy3gUXPbrEo8oIPWM4w7q8t6VyRYylyiqO/sl WeUw== X-Gm-Message-State: AOAM531arr0W2ThR3gpnPvsnqhcyvK/09IcoGDbyCecdZGIV3prNv9Jl WwynQ7ZyPp4mpSOY8BjVkTungw== X-Received: by 2002:a7b:c76a:: with SMTP id x10mr13701463wmk.16.1592232823049; Mon, 15 Jun 2020 07:53:43 -0700 (PDT) Received: from google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id s8sm25864689wrg.50.2020.06.15.07.53.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2020 07:53:42 -0700 (PDT) Date: Mon, 15 Jun 2020 16:53:36 +0200 From: Marco Elver To: Peter Zijlstra Cc: Dmitry Vyukov , Andrey Konovalov , Mark Rutland , Borislav Petkov , Thomas Gleixner , Ingo Molnar , clang-built-linux , "Paul E. McKenney" , Alexander Potapenko , kasan-dev , LKML , the arch/x86 maintainers , Andrew Morton , Josh Poimboeuf Subject: Re: [PATCH -tip v3 1/2] kcov: Make runtime functions noinstr-compatible Message-ID: <20200615145336.GA220132@google.com> References: <20200608110108.GB2497@hirez.programming.kicks-ass.net> <20200611215538.GE4496@worktop.programming.kicks-ass.net> <20200612114900.GA187027@google.com> <20200615142949.GT2531@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200615142949.GT2531@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.13.2 (2019-12-18) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 15 Jun 2020, Peter Zijlstra wrote: > On Mon, Jun 15, 2020 at 09:53:06AM +0200, Marco Elver wrote: > > > > Disabling KCOV for smp_processor_id now moves the crash elsewhere. In > > the case of KASAN into its 'memcpy' wrapper, called after > > __this_cpu_read in fixup_bad_iret. This is making me suspicious, > > because it shouldn't be called from the noinstr functions. > > With your .config, objtool complains about exactly that though: > > vmlinux.o: warning: objtool: fixup_bad_iret()+0x8e: call to memcpy() leaves .noinstr.text section > > The utterly gruesome thing below 'cures' that. Is __memcpy() generally available? I think that bypasses KASAN and whatever else. > > For KCSAN the crash still happens in check_preemption_disabled, in the > > inlined native_save_fl function (apparently on its 'pushf'). If I turn > > fixup_bad_iret's __this_cpu_read into a raw_cpu_read (to bypass > > check_preemption_disabled), no more crash with KCSAN. > > vmlinux.o: warning: objtool: debug_smp_processor_id()+0x0: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section > vmlinux.o: warning: objtool: check_preemption_disabled()+0x1f: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section > vmlinux.o: warning: objtool: __this_cpu_preempt_check()+0x4: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section > > That could be either of those I suppose, did you have the NOP patches > on? Let me try... those seem to placate objtool at least. > > I do see a fair amount of __kasan_check*() crud though: > > vmlinux.o: warning: objtool: rcu_nmi_exit()+0x44: call to __kasan_check_read() leaves .noinstr.text section > vmlinux.o: warning: objtool: rcu_dynticks_eqs_enter()+0x1c: call to __kasan_check_write() leaves .noinstr.text section > vmlinux.o: warning: objtool: rcu_nmi_enter()+0x46: call to __kasan_check_read() leaves .noinstr.text section > vmlinux.o: warning: objtool: rcu_dynticks_eqs_exit()+0x21: call to __kasan_check_write() leaves .noinstr.text section > vmlinux.o: warning: objtool: __rcu_is_watching()+0x1c: call to __kasan_check_read() leaves .noinstr.text section > vmlinux.o: warning: objtool: debug_locks_off()+0x1b: call to __kasan_check_write() leaves .noinstr.text section > > That wasn't supported to happen with the __no_sanitize patches on (which > I didn't forget). Aah, I think we've lost a bunch of patches.. /me goes > rummage. > > This: > > https://lkml.kernel.org/r/20200603114051.896465666@infradead.org > > that cures the rcu part of that. > > Let me go look at your KCSAN thing now... I tried to find the stack that is used by the crashing code -- which led me to entry_stack? So I tried this: --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -370,7 +370,7 @@ struct x86_hw_tss { #define IO_BITMAP_OFFSET_INVALID (__KERNEL_TSS_LIMIT + 1) struct entry_stack { - unsigned long words[64]; + unsigned long words[128]; }; struct entry_stack_page { No more crash. But that's probably not what we want. Just a datapoint. > --- > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > index af75109485c26..031a21fb5a741 100644 > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > @@ -675,6 +675,14 @@ struct bad_iret_stack { > struct pt_regs regs; > }; > > +void __always_inline __badcpy(void *dst, void *src, int nr) > +{ > + unsigned long *d = dst, *s = src; > + nr /= sizeof(unsigned long); > + while (nr--) > + *(d++) = *(s++); > +} > + If we can use __memcpy() here, that would probably solve that. Thanks, -- Marco