Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp1898565img; Wed, 27 Feb 2019 07:17:58 -0800 (PST) X-Google-Smtp-Source: AHgI3Ib5zuuWWpfbROB5DXlZKgQlfei9xS2/JFiJJscbLNIJ4ex4v+2yMHKQqwCDtBU/bIPqbOM4 X-Received: by 2002:a62:4414:: with SMTP id r20mr2164296pfa.37.1551280678537; Wed, 27 Feb 2019 07:17:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551280678; cv=none; d=google.com; s=arc-20160816; b=ngfFvFNh22GDBBooRcBfD/CUrDfnAW2beFqWP3o579cflBmQ7HTmNZVoDvc3fL591y pFhxpkcgZOPOlYteiYM8NBqvab5yHGgX0cJ/x8v8AKbb3JMct4CLxyY2d7BmKU1/4b+3 N9UO/U5vdGM53pUXWo7OnOXYjJ/fOCHA4Hc4NpMptUNwAuD8vH3LkOl/+N2pay0dtzxx lyQWZWy4v8XMyoLQtC4g1bs8JK11mwDwj8VIFCyFHSVF7N8mmE5GVQ/gFRWoHB0fy7P7 CgyenZWcvqnBIlOcRRoOKbjn0Qcti0sRXXm727xQJgUOiW/Eivbn7PG2jVedVDlQdTDC oJ1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=3ifN+qa57h9Avh7/sipr8FPTxp64CCwfmEdM0I/rVVk=; b=aoYiJEjAQvhySHNLOID1kHpFX11TuNLoQbJXOgWqRrxZmG9X9mhs0r0kCAk7cNI1Cx BwxV8Rf//+TCWZtUELZUqyv/VlKzkoNrj15+F3Hq6EZ8k4Q6RTBZZhjikMr5upTTwI6K A9qnKdRw+tdnNs1lOseEbZ/0hbvnGk+gBRN9t0cCAfQmAcxEaIxF9PwXj0R1kiVDiSiW K8BUn31BK4lo8bruGLf52er+8p75PYnKxpsU/yy5PcCIisvmK4PRoTEQalZLk1zZAF4B RENdbA1xDnMZyOOX7yIQGJKNDSZQ6rchIHhMcUPlex9DKh9m+ZH17czaQzWc5JBCr4hu dmDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p1si15109958plk.260.2019.02.27.07.17.41; Wed, 27 Feb 2019 07:17:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730589AbfB0ORu (ORCPT + 99 others); Wed, 27 Feb 2019 09:17:50 -0500 Received: from relay.sw.ru ([185.231.240.75]:50984 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728462AbfB0ORt (ORCPT ); Wed, 27 Feb 2019 09:17:49 -0500 Received: from [172.16.25.12] by relay.sw.ru with esmtp (Exim 4.91) (envelope-from ) id 1gz01l-0004gy-02; Wed, 27 Feb 2019 17:17:41 +0300 Subject: Re: [PATCH 5/6] objtool: Add UACCESS validation To: Peter Zijlstra , torvalds@linux-foundation.org, tglx@linutronix.de, hpa@zytor.com, julien.thierry@arm.com, will.deacon@arm.com, luto@amacapital.net, mingo@kernel.org, catalin.marinas@arm.com, james.morse@arm.com, valentin.schneider@arm.com, brgerst@gmail.com, jpoimboe@redhat.com, luto@kernel.org, bp@alien8.de, dvlasenk@redhat.com Cc: linux-kernel@vger.kernel.org, glider@google.com, dvyukov@google.com References: <20190225124330.613028745@infradead.org> <20190225125232.191698923@infradead.org> <20190227140830.GP32494@hirez.programming.kicks-ass.net> From: Andrey Ryabinin Message-ID: <19b35cb1-9527-2e15-6deb-9ce7c1ef1d66@virtuozzo.com> Date: Wed, 27 Feb 2019 17:17:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <20190227140830.GP32494@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/27/19 5:08 PM, Peter Zijlstra wrote: > On Mon, Feb 25, 2019 at 01:43:35PM +0100, Peter Zijlstra wrote: >> It is important that UACCESS regions are as small as possible; >> furthermore the UACCESS state is not scheduled, so doing anything that >> might directly call into the scheduler will cause random code to be >> ran with UACCESS enabled. >> >> Teach objtool too track UACCESS state and warn about any CALL made >> while UACCESS is enabled. This very much includes the __fentry__() >> tracing calls and __preempt_schedule() calls. >> >> Note that exceptions _do_ save/restore the UACCESS state, and therefore >> they can drive preemption. This also means that all exception handlers >> must have an otherwise dedundant UACCESS disable instruction; >> therefore ignore this warning for !STT_FUNC code (exception handlers >> are not normal functions). >> >> It also provides a UACCESS_SAFE() annotation which allows explicit >> annotation. This is meant to be used for future things like: >> unsafe_copy_{to,from}_user(). >> >> Signed-off-by: Peter Zijlstra (Intel) > > So KASAN is wildly unhappy.. > > I can't actually find any definitions of those functions, so I can't > very well mark the safe, even if we wanted to. > They are macro-generated. Use 'git grep DEFINE_ASAN' > --- > >>> arch/x86/kernel/signal.o: warning: objtool: restore_sigcontext()+0x59: call to __asan_store8_noabort() with UACCESS enabled