Received: by 10.223.176.5 with SMTP id f5csp2152110wra; Thu, 8 Feb 2018 09:13:50 -0800 (PST) X-Google-Smtp-Source: AH8x225KrY1BnUeyj4icjzzA0S0Qk6Zm892pr1hBCqYvXzylsFFWV1Sn1shKisjsJXFlB08Cv8ih X-Received: by 2002:a17:902:7848:: with SMTP id e8-v6mr1292638pln.386.1518110030203; Thu, 08 Feb 2018 09:13:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518110030; cv=none; d=google.com; s=arc-20160816; b=NrVfzcAYBRyPc3RLezbSK76l1a+JQbhplZRfSwUm0HYH9Ex5FblfBLEPM/81WhbZaz VZIlgmfMwKqYlV3G7ZbHnkArdJixhrM2aS8gM8l8p4PA/rHauEweqIfp83GCigTOnC5d 7OcjdgkyjzrTecN60YF0cgGaZCWUStjUh6W9cB9PsoiYwlzH6a4of08ofkCSaD4pRIw0 s0cRROuHpXR1FK5nYMWKBj7o1bOWlDnLR9IQZH5f6EGqr7i1WJCLok9yFuLUcjJDNhzh jyyEJ0UdDV8/0ZcrTvOYPWEIjACtbelVeKt821oDeqZ3GJIqcbSnCgTO9/N84dGVePNw 7xzQ== 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 :references:in-reply-to:mime-version:dkim-signature:dkim-filter :arc-authentication-results; bh=quo+TnQYI1nQ1NEGeCSzEqQDTsshMji9fJJVl6g8SZk=; b=RfH2B7caxDK0EG+OnwKclxCQbADc/4pFRa7NmwuiQsue4VKf6S0ZejEwNkNRpTzESX g6HEzm7+mjTeTmVDDBRUWFoVAaIWWKY5HH4xqqhKPm+THGboFq4czmg7RRHX1GlVLlv+ NcLsl+Qu+ArrAuCpwz4ClJPSwcgFI2x0RvUeJRhDnHZ+IcOeimhgfKPt9nRnvbtTuMXg dS2mikcdriavTZ2bcz6PsBIqR1+ndl6ns6xNIMF7nziH1+TaSJZh9PwUXBVSdJTAz2ur SM4z3nkJGZfyOHH+LaMTNzTQVJQJdB1eSEXN8Lxu0iYBhwQDpEOShDdvfwkH6/trNCFT Uk6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=NJ9vc7ER; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j8-v6si233478plk.87.2018.02.08.09.13.34; Thu, 08 Feb 2018 09:13:50 -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; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=NJ9vc7ER; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752246AbeBHRMp (ORCPT + 99 others); Thu, 8 Feb 2018 12:12:45 -0500 Received: from conssluserg-06.nifty.com ([210.131.2.91]:51948 "EHLO conssluserg-06.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752214AbeBHRMn (ORCPT ); Thu, 8 Feb 2018 12:12:43 -0500 Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com [209.85.217.172]) (authenticated) by conssluserg-06.nifty.com with ESMTP id w18HCa4C027269; Fri, 9 Feb 2018 02:12:37 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com w18HCa4C027269 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1518109957; bh=quo+TnQYI1nQ1NEGeCSzEqQDTsshMji9fJJVl6g8SZk=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=NJ9vc7ERTGdvx3VcXbmmq7ulofKvs1E4FWGVEO4C3henOZ5mh8aOpZ7yPPrgk7M3r mZIrzx7s1eanIuRaJWTCUVBFdcX4jbf2ZFx0neGWl7+lOP+sBStREL7MgxcetoZ7Jh IjxEn4k3UJCRYfPDYESWaNAcKPWNkWvhyruKSMfUomqoP277csvfXmD8yVev/NdlXQ smq+ecR8K+61jChLSW6y4qF/9uf5QhXEna5Z2ih7QGFzsKYsvCNFhjypL+DMXVNS3s WaEFFBhYo7GAmf8q5sCcg1w8Yy7/h3Pn4BU01vJSgicRJdqkbyqB6PPLTkZdWgxGn8 ++Jh6OFvoIMrw== X-Nifty-SrcIP: [209.85.217.172] Received: by mail-ua0-f172.google.com with SMTP id i5so3358545uai.10; Thu, 08 Feb 2018 09:12:36 -0800 (PST) X-Gm-Message-State: APf1xPDsVbhAo0yhhmq1ll9sUpJnmaxqKLljzDsZhTlKz7i0IeElsNgQ qSCTrv13Wf4LmhNAbWC7coFwUvjIWYzrIRFRzEI= X-Received: by 10.176.83.76 with SMTP id y12mr1233045uay.109.1518109955782; Thu, 08 Feb 2018 09:12:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.83.212 with HTTP; Thu, 8 Feb 2018 09:11:55 -0800 (PST) In-Reply-To: References: <1517986811-27819-1-git-send-email-schwidefsky@de.ibm.com> <1517986811-27819-7-git-send-email-schwidefsky@de.ibm.com> <20180207100726.GB31392@amd> <1518005275.3677.112.camel@infradead.org> <20180207131719.4aeb316e@mschwideX1> From: Masahiro Yamada Date: Fri, 9 Feb 2018 02:11:55 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 6/6] s390: introduce execute-trampolines for branches To: Kees Cook , Linus Torvalds Cc: Martin Schwidefsky , David Woodhouse , Pavel Machek , Linux Kernel Mailing List , linux-s390 , Heiko Carstens , Christian Borntraeger , Cornelia Huck , David Hildenbrand , Greg Kroah-Hartman , Jon Masters , Marcus Meissner , Jiri Kosina , Dominik Brodowski , Alan Cox , Ulf Magnusson 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 2018-02-08 9:57 GMT+09:00 Kees Cook : > On Thu, Feb 8, 2018 at 10:44 AM, Masahiro Yamada > wrote: >> 2018-02-08 2:55 GMT+09:00 Linus Torvalds : >>> What I would really want - and this is entirely unrelated to this >>> particular case - is to have those damn compiler option tests as part >>> of the config phase in general. We now have about a million of these >>> crazy things, where we have config options that simply depend on which >>> compiler we have, and we have no sane way to show them at >>> configuration time. >>> >>> Though Andrew's tree I got yet another ugly hack >>> (CONFIG_CC_STACKPROTECTOR_AUTO) that handles just _one_ special case >>> by turning it into a special magic Kconfig entry in the main Makefile. >>> See commit 44c6dc940b19 ("Makefile: introduce >>> CONFIG_CC_STACKPROTECTOR_AUTO"). I wasn't sure if I really wanted it, >>> and honestly, I'm still thinking of just reverting it, because it's >>> _so_ ugly and _so_ wrong. >>> >>> What we need is an extension to the Kconfig language itself so that we can do >>> >>> config CC_HAS_RETPOLINE >>> cc_option "-mindirect-branch=thunk -mindirect-branch-table" >>> >>> or something. And then we can make sane _conditional_ dependencies at >>> Kconfig time, and our makefiles would be much cleaner too when you >>> could just do >>> >>> cflags-$(USE_RETPOLINE) += -mfunction-return=thunk -mindirect-branch-table >>> >>> because the validity of the C compiler flag has been tested when configuring. >>> >>> And then we could add that warning at configure time (or just disable >>> the option there thanks to "depends on CC_HAS_xyz" logic). >>> >>> All our compiler option handling right now is just nasty nasty nasty crud. >>> >>> Adding more people in the hopes that somebody gets motivated.. I've >>> talked about this before, so far we haven't made any progress. >> >> >> Sorry for slow progress. >> >> I agreed this before, and still motivated. >> (because I also motivated to remove kbuild cache. >> This turned out not so clever as I first thought) >> >> I was trying to do this, but in this development cycle >> I spent most of my time to flush out lots of piled up Kconfig patches. >> Sorry. >> >> Unless somebody is working, I will. I sent the first draft. For people interested, I pushed the series in the following too. git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git kconfig-opt-shell-rfc -- Best Regards Masahiro Yamada