From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6605C43381 for ; Fri, 22 Feb 2019 23:55:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B07D52075C for ; Fri, 22 Feb 2019 23:55:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JmxBXnSW"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="EnFZjWYA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B07D52075C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=18Ubwx1t/wJreSV5tmcQWemxbB8r59qebOoCsZ6rmxU=; b=JmxBXnSWZEmS9m oHRRQp65cJZImEOYTTpFuJYF6TGQk5sOEJcA1FHEPVY0u4zEMJZaOQvR5m1otHlFzPZLBWqJGQ7F7 vA4TzQBMxeTJbW3Nf0FIi8Cp6xm0dEGiiag+B80kuUxO0S+B0kWEPLOWR8RmE7rHWn2H/3oiVVFTM IkgXrsiLS7vE77N94lcDQXN3uib8GOF8PwnW+b+ERZitcsoFxae7HczgpjPk3jxybf9YSWyqujPl5 OzoYsbM7VupXnGWC5qZaqdBugIwbBwgdzyaedxOwkyqqTPxkhjK7HlMZf2HGn61H8merzpJVI1OUx kDcno8QDGeIQCpQINcvA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gxKfS-0002Wz-6a; Fri, 22 Feb 2019 23:55:46 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gxKfN-0002WA-Lc for linux-arm-kernel@lists.infradead.org; Fri, 22 Feb 2019 23:55:43 +0000 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A50C72086A for ; Fri, 22 Feb 2019 23:55:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550879738; bh=17mG8B8lMHG5wfQsv/g1N0tTizuAj4ppTtNUCXlyCk4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EnFZjWYANcSBQy9/w9c+EgPuNNGZIV6T4u2tF6pcg8j9KL6D3XtsfMJKDAVoQqxY+ nwsE0uaOSFeMGOdeCvwIsXBbWX2hZ+wruIBm2FAO6vfSGTqr9tPINUC4viFURcUtzj AJkxWcwiXLY3er+hISWK8VuG8sNX+658sai83cyc= Received: by mail-wr1-f51.google.com with SMTP id n2so4091104wrw.8 for ; Fri, 22 Feb 2019 15:55:38 -0800 (PST) X-Gm-Message-State: AHQUAuYFQnCbZ+NAGozhOHmPaCfnhBtORtrE45XL9YoURWp6SmaPC59W VDWlgR8ki+tIrKuJv+pjlg5JtVmkNCjcNUCerxGJrA== X-Google-Smtp-Source: AHgI3Ib0CVIzhDnShAg0pz7M8k6P8KKBcQ9vQpJz+0avB23uRG3JQ06jBt1Y/4c3dqcHimd7PnhigfylGtd89yvYuaE= X-Received: by 2002:a5d:6252:: with SMTP id m18mr4445431wrv.199.1550879737087; Fri, 22 Feb 2019 15:55:37 -0800 (PST) MIME-Version: 1.0 References: <20ABBED1-E505-45F6-8520-FB93786DF9A9@zytor.com> <20190216103044.GR32494@hirez.programming.kicks-ass.net> <9e037d68-75e7-1beb-0c9c-33a7ffeced1b@zytor.com> <20190219090409.GW32494@hirez.programming.kicks-ass.net> <20190219124808.GG8501@fuggles.cambridge.arm.com> <20190222222635.GK14054@worktop.programming.kicks-ass.net> In-Reply-To: <20190222222635.GK14054@worktop.programming.kicks-ass.net> From: Andy Lutomirski Date: Fri, 22 Feb 2019 15:55:25 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH] objtool: STAC/CLAC validation To: Peter Zijlstra X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190222_155541_745949_779E0507 X-CRM114-Status: GOOD ( 22.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Denys Vlasenko , Brian Gerst , Julien Thierry , Catalin Marinas , Josh Poimboeuf , Will Deacon , Linux List Kernel Mailing , valentin.schneider@arm.com, Ingo Molnar , James Morse , Andrew Lutomirski , "H. Peter Anvin" , Borislav Petkov , Thomas Gleixner , Linus Torvalds , Ingo Molnar , "linux-alpha@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Feb 22, 2019 at 2:26 PM Peter Zijlstra wrote: > > On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote: > > > But correct :) > > > I agree, that a function which is doing the actual copy should be callable, > > but random other functions? NO! > > So find the below patch -- which spotted fail in ptrace.c > > It has an AC_SAFE(func) annotation which allows marking specific > functions as safe to call. The patch includes 2 instances which were > required to make arch/x86 'build': > > arch/x86/ia32/ia32_signal.o: warning: objtool: ia32_restore_sigcontext()+0x3d: call to native_load_gs_index() with AC set > arch/x86/kernel/ptrace.o: warning: objtool: genregs_get()+0x8e: call to getreg() with AC set > > It also screams (provided one has CONFIG_FUNCTION_TRACE=y) about the > lack of notrace annotations on functions marked AC_SAFE(): > > arch/x86/kernel/ptrace.o: warning: objtool: getreg()+0x0: call to __fentry__() with AC set > > It builds arch/x86 relatively clean; it only complains about some > redundant CLACs in entry_64.S because it doesn't understand interrupts > and I've not bothered creating an annotation for them yet. > > arch/x86/entry/entry_64.o: warning: objtool: .altinstr_replacement+0x4d: redundant CLAC > arch/x86/entry/entry_64.o: warning: objtool: .altinstr_replacement+0x5a: redundant CLAC > ... > arch/x86/entry/entry_64.o: warning: objtool: .altinstr_replacement+0xb1: redundant CLAC Does objtool understand altinstr? If it understands that this is an altinstr associated with a not-actually-a-fuction (i.e. END not ENDPROC) piece of code, it could suppress this warning. > > -static unsigned long getreg(struct task_struct *task, unsigned long offset) > +static notrace unsigned long getreg(struct task_struct *task, unsigned long offset) > { > switch (offset) { > case offsetof(struct user_regs_struct, cs): > @@ -444,6 +444,7 @@ static unsigned long getreg(struct task_struct *task, unsigned long offset) > > return *pt_regs_access(task_pt_regs(task), offset); > } > +AC_SAFE(getreg); This takes the address and could plausibly suppress some optimizations. > > +#if defined(CONFIG_STACK_VALIDATION) && !defined(BUILD_VDSO) && !defined(BUILD_VDSO32) > +/* > + * This macro marks functions as AC-safe, that is, it is safe to call from an > + * EFLAGS.AC enabled region (typically user_access_begin() / > + * user_access_end()). > + * > + * These functions in turn will only call AC-safe functions themselves (which > + * precludes tracing, including __fentry__ and scheduling, including > + * preempt_enable). > + * > + * AC-safe functions will obviously also not change EFLAGS.AC themselves. > + * > + * Since STAC/CLAC are OPL-0 only, this is all irrelevant for VDSO builds > + * (and the generated symbol reference will in fact cause link failures). > + */ > +#define AC_SAFE(func) \ > + static void __used __section(.discard.ac_safe) \ > + *__func_ac_safe_##func = func Are we okay with annotating function *declarations* in a way that their addresses get taken whenever the declaration is processed? It would be nice if we could avoid this. I'm wondering if we can just change the code that does getreg() and load_gs_index() so it doesn't do it with AC set. Also, what about paravirt kernels? They'll call into PV code for load_gs_index() with AC set. --Andy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel