Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3730972imm; Fri, 25 May 2018 10:33:58 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo3zfvp7/p0nT699s8KU8OTOleA55VaYtIZ4h2i+c8LsW+VwInuccSyyNr5Uhw5EbGhwltB X-Received: by 2002:a17:902:6b47:: with SMTP id g7-v6mr3501598plt.251.1527269638166; Fri, 25 May 2018 10:33:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527269638; cv=none; d=google.com; s=arc-20160816; b=c0aMqcibJUg6qz1G+in3nSEi+itCrYT3gVeBHQ6kYDUWUGntertY4WF4umf15khc53 keB0CvRfTujU7eLQL1Zo87FzJQcB/zhy7VZcWo2qPXqxEPkS2IUO7DyPym/EZRFY7vRR 87PPZRGcQUsebkaSogi/uQqVXhiQZN4sihN7KQ91dR0EBPiHJjs2RylI71ITrXx6j5H7 Zq3NKUVLpw2yKVcyY4bx+VYmhG8IwdwsieHb/8Bh/j8Wo4BX0H0VJ8fRanr2TdeCEMeJ +LHbmg4lHyqJdMua3jGm6WS3wEHXxh7z4vFa1JWkW5K0x74IScl6Z71pVjklgQqjV2ZZ g60w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=UXiGDs71XC8ves/8AzI5f0oCIXWSgMZv/qN24zX0V9A=; b=py/iRKScqRU8Fuc5t7L4DxA6XCKtkTWqIGOfwd5brjuxBOsGSS/U75CLm775YErOan m7vOxXOIcnffb5d0NkWEyU79ULDaoriJNYwllGkhFPninvT1lqUEtwQcC2GP3qrYOwC4 n/AupVFB+XDHioLHlgB5WAXPbw7mkEiVisAQj/oaD8fYU9DHjbfCleToRe14ct+WHi2q Al/ehtSAw/IslJDNg1KhlkoaPsGOmVlvgGAFFMFd2//c1Ol68n/FjAlVe5iAdT/HJqh2 HXqf3qeSX12a76ERxD2g76BfqQofRqfpbvwmsSQs8uE3iIVFpUJzeiyFo3OnYyAyvbwV QWzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=tVCAZvIR; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p29-v6si3027660pgn.663.2018.05.25.10.33.42; Fri, 25 May 2018 10:33:58 -0700 (PDT) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=tVCAZvIR; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967408AbeEYRcG (ORCPT + 99 others); Fri, 25 May 2018 13:32:06 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:35360 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967305AbeEYRcE (ORCPT ); Fri, 25 May 2018 13:32:04 -0400 Received: by mail-pl0-f68.google.com with SMTP id i5-v6so3538956plt.2 for ; Fri, 25 May 2018 10:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UXiGDs71XC8ves/8AzI5f0oCIXWSgMZv/qN24zX0V9A=; b=tVCAZvIRnwcBzA1m9yn4jr72was9kKaog6r5JcByMcIJVscnAd3arYccEA5GPmgTjP 1FmR06GCjamRZWMx6BQ2whyKXiuHgA4qeJMkvvoPbcaC7+c2GivZrPKmHYYXkpYqHJVI YGFig55KY1JKO+d+Uz2R+CvcX1+5AyaJ54EYIvjA1EjUY9EqE9bWc3tiZhESN3v1Avmm cJCtsrXJWxHTq49+xrQLYQt9yFw21cJpKABLiQZ/NU84N5KWhfJYvD/fn3o3SME4wjGU CIHH4iEKIkxr1KQqfyw7T/CRTw1gidLydRdJcKIv/MpsGnMKFVpvjRjboQJJnvkBoLB7 tx7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UXiGDs71XC8ves/8AzI5f0oCIXWSgMZv/qN24zX0V9A=; b=QXmG1Fri/LcGADEvH2MB81tYpZ+8exoXVdShprnRfDf5spy+Vg1/DPHyeKQrLWgY33 cAZuFECLszRdOBAkDtLityRDBgcc3c6KOCyKzejGy86zVGZHRslW2lfbw//zR/n8ceT+ 8hJRtwgCZAtNQUb/9aox4bV2j6BTpg5aWYGhwBuabDi9AA60hXtDI4p0sUp2IgFwPF1o 52mecYOTWsxWsQIeBu0tu8d9mb2+v/FvOIOHQ9iNdXZqsNC5FTG7gef/bVQMakFA2LhY 8XLEIRXp7KZ2tzFFv88o+LptzMjyL9lmp9nVI8+4wbETh0ACPABCKlleVKf/KVKlfmZU uhUw== X-Gm-Message-State: ALKqPwdvU7Ti7ygfY8Efk2sn62B6SPFJEs3dTsvB05yR6JRCAX3THa8i YTQbVfJWvAkjSWHvVyesVbMiBf6kow5NLGfBb6aVCg== X-Received: by 2002:a17:902:d891:: with SMTP id b17-v6mr3608363plz.0.1527269523884; Fri, 25 May 2018 10:32:03 -0700 (PDT) MIME-Version: 1.0 References: <26B017D5-4063-46CB-8768-B0E5E7CD3838@zytor.com> <319FB971-ABB6-4BE7-969B-D87D84853196@zytor.com> <31A5469A-176F-451F-886A-ECD649DDC78C@zytor.com> In-Reply-To: <31A5469A-176F-451F-886A-ECD649DDC78C@zytor.com> From: Nick Desaulniers Date: Fri, 25 May 2018 10:31:51 -0700 Message-ID: Subject: Re: [clang] stack protector and f1f029c7bf To: hpa@zytor.com Cc: Alistair Strachan , Manoj Gupta , Matthias Kaehlcke , Greg Hackmann , sedat.dilek@gmail.com, tstellar@redhat.com, LKML , Kees Cook Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 25, 2018 at 9:53 AM wrote: > On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers wrote: > >On Fri, May 25, 2018 at 9:33 AM wrote: > >> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers > > wrote: > >When you say > > > >> It still should be available as as inline, however, but now "extern > >inline". > > > >Am I understanding correctly that native_save_fl should be inlined into > >all > >call sites (modulo the problematic pv_irq_ops.save_fl case)? Because > >for > >these two assembly implementations, it's not, but maybe there's > >something > >missing in my implementation? > Yes, that's what "extern inline" means. Maybe it needs a must inline annotation, but that's really messed up. I don't think it's possible to inline a function from an external translation unit without something like LTO. If I move the implementation of native_save_fl() to a separate .c (with out of line assembly) or .S, neither clang nor gcc will inline that assembly to any call sites, whether the declaration of native_save_fl() looks like: extern inline unsigned long native_save_fl(void); or __attribute__((always_inline)) extern inline unsigned long native_save_fl(void); I think an external copy is the best approach for the paravirt code: diff --git a/arch/x86/kernel/irqflags.c b/arch/x86/kernel/irqflags.c new file mode 100644 index 000000000000..e173ba8bee7b --- /dev/null +++ b/arch/x86/kernel/irqflags.c @@ -0,0 +1,24 @@ +#include + +extern unsigned long native_save_fl_no_stack_protector(void); +extern void native_restore_fl_no_stack_protector(unsigned long flags); + +asm( +".pushsection .text;" +".global native_save_fl_no_stack_protector;" +".type native_save_fl_no_stack_protector, @function;" +"native_save_fl_no_stack_protector:" +"pushf;" +"pop %" _ASM_AX ";" +"ret;" +".popsection"); + +asm( +".pushsection .text;" +".global native_restore_fl_no_stack_protector;" +".type native_restore_fl_no_stack_protector, @function;" +"native_restore_fl_no_stack_protector:" +"push %" _ASM_DI ";" +"popf;" +"ret;" +".popsection"); diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 02d6f5cf4e70..8824d01c0c35 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -61,6 +61,7 @@ obj-y += alternative.o i8253.o hw_breakpoint.o obj-y += tsc.o tsc_msr.o io_delay.o rtc.o obj-y += pci-iommu_table.o obj-y += resource.o +obj-y += irqflags.o obj-y += process.o obj-y += fpu/ --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -322,9 +322,12 @@ struct pv_time_ops pv_time_ops = { .steal_clock = native_steal_clock, }; +extern unsigned long native_save_fl_no_stack_protector(void); +extern void native_restore_fl_no_stack_protector(unsigned long flags); + __visible struct pv_irq_ops pv_irq_ops = { - .save_fl = __PV_IS_CALLEE_SAVE(native_save_fl), - .restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl), + .save_fl = __PV_IS_CALLEE_SAVE(native_save_fl_no_stack_protector), + .restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl_no_stack_protector), .irq_disable = __PV_IS_CALLEE_SAVE(native_irq_disable), .irq_enable = __PV_IS_CALLEE_SAVE(native_irq_enable), .safe_halt = native_safe_halt, Thoughts? -- Thanks, ~Nick Desaulniers