Received: by 10.223.185.116 with SMTP id b49csp3783127wrg; Tue, 13 Feb 2018 07:42:35 -0800 (PST) X-Google-Smtp-Source: AH8x224R7TfYNDJV0ng1zpJDQEDTqp4vGeNuQ8E3/OXc6JjVQ7QSNzWw3U6U9JxHIomuWHvG02ny X-Received: by 10.101.86.15 with SMTP id l15mr1346957pgs.340.1518536555321; Tue, 13 Feb 2018 07:42:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518536555; cv=none; d=google.com; s=arc-20160816; b=Ly1JdIf+F2bG+PveF0r+qAl1DDH2FNftTPJqy8I3FhtdEidLFEX0eGEMaecvLZ9Unp fxisQ+Ad+2EWPJMzjzH+Pxg1ZD0btv7RhdIvEjj43hn0xPYROLFjBnZ2J+AhM4bXb6Nv gfOpZUhe8n6XkVeDKnpSZiFPyK8zoxpb4E0IleFKR/PzDGqn2zMDcJgvAY7OtgSxsf8f R7S1QPuvRMkLvvD+Cdp7AgOZij98XSB3WyuJnpvloLg3jKW3AdzuGcbBM7I7tKg25IIM CWTEaxtnBbz8tV38ukY9CWH4Mtnn25lBvzLSA7PQM73T19hBVn86UwA/c24jMiVcPZxY pecQ== 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-signature :arc-authentication-results; bh=E/qFKAGgQ09N+ZZLPSiuMk62X7ZhUBM7+zOD3wESLrw=; b=EhXSzqIBd/n/Npyd9y4gEpMWgq+jfhBWSSbVC4sNs4DGOHshTIwZOjNgBY2xN5ILid 8OudmDZJ7S6vGFyW1CICjfTAzzIALmD0KHVsYS1JukpEAfquR74k5JNNrXYlZuekOm/H ILp5Bx7D0QaldHcbZiIlTmIJFo9kOVsTGUlyCFNCreeWL4F/G4NIstYlg3p9DjA9MReA xnDqRvmNgfcDQpDe6Y++gN+GeSBgseQy2OVqgz4dZLvdpsFiE9XijPWssWrUGYJ4xrqK Nbp2qq8b1T27R/cxlXvvtPdXRQ06YseCU6hZPBqt7hiT43t+d363Jkq5CmwdLdQHVg3c GqCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=hQkguDbq; dkim=fail header.i=@chromium.org header.s=google header.b=ku3Yx7Tx; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m9si1491750pgs.269.2018.02.13.07.42.20; Tue, 13 Feb 2018 07:42:35 -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=fail header.i=@google.com header.s=20161025 header.b=hQkguDbq; dkim=fail header.i=@chromium.org header.s=google header.b=ku3Yx7Tx; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934390AbeBMPlp (ORCPT + 99 others); Tue, 13 Feb 2018 10:41:45 -0500 Received: from mail-vk0-f65.google.com ([209.85.213.65]:41475 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933425AbeBMPlo (ORCPT ); Tue, 13 Feb 2018 10:41:44 -0500 Received: by mail-vk0-f65.google.com with SMTP id g186so11051657vkd.8 for ; Tue, 13 Feb 2018 07:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E/qFKAGgQ09N+ZZLPSiuMk62X7ZhUBM7+zOD3wESLrw=; b=hQkguDbqJmVodPxF3eLl1bTMynT2jejDyn/FWg3AFUT5Kc239qaZFQasoeXJJbHw38 9HUva6lWYNEdXNFOEGWqmUNkgxRZaql0FKiEUJIagkVrLbE/7zOeCaj6RefEnwiFGhG7 LpoUUw1uly/c1hwPTHIohVVNemmxx5B2yRrQ+m6LxgcB0nW4+0VpiAvJgx1W0uhaeTa5 YMV5OAus7b51B06XuCNmbbz4mH4W2ez5p4OhYnLX8aCxh+XgqoDdbHmeDM61bAfEcVVE o1C5+k2JicPXuvnzd6DL5AoAZFAqZo+CI6hHKqreVVZbHNautCr9iASlvqAM78jHOtG+ geGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E/qFKAGgQ09N+ZZLPSiuMk62X7ZhUBM7+zOD3wESLrw=; b=ku3Yx7TxCJ+T1uCW/XJ94BkTSjY1HzSSjjljNYS27lmBac7u2JxbqKhxGBh1DmnQcc JYNz5jvjweKQH4o353zwcBsjTK3xUKVYzUqIjp+B1Gek+sXbi99SzT6RjpzQ87EanHdn gn//Gw2yGYBbHuIZB2AMMgf5tfsP8UQpe5jt8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E/qFKAGgQ09N+ZZLPSiuMk62X7ZhUBM7+zOD3wESLrw=; b=E2xQwX4160f0AnLgtpDjVM0EDYlwPlFHSs9kW0fJVRVlcT/li9fMGTGAEy4WQuJSmJ pujD6Zriu2FBdxnvvarxuoAvXl4T0t1YKWyQcnFTufBZrvKJReCJPViG2gA3GXP6D8Hn 4arKb36QTlpiVarBMRSe+JqsY2+KwR8xdAS3ZIMK5yrOp3xZHPjlfV7+3CyIAFZXCGiX TpCrkkOhbHPh1h/yLdW3IKUrcyhgZC12L6r+hvP4YCPZwVsymJ1u+nvULaUtFP3ROUcv Lje+pBxIleFXVOQQDMgXfBtwq+bylZg2LSH4LiDprZwlTQj6Vn76iznAvxk1VZpA5IUP gAfg== X-Gm-Message-State: APf1xPCoW3MfDF3/fMvp5DuON8ii5zdneNVk87N2YwTM3Rinhjq766dB lOzIcK9K0qU3PQHbVkVMFvtIZoJd3z8t+ts2kBtHbg== X-Received: by 10.31.201.133 with SMTP id z127mr1542067vkf.129.1518536503197; Tue, 13 Feb 2018 07:41:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.67.196 with HTTP; Tue, 13 Feb 2018 07:41:42 -0800 (PST) In-Reply-To: References: From: Kees Cook Date: Tue, 13 Feb 2018 07:41:42 -0800 X-Google-Sender-Auth: CYNLML8GzfCUkWArgd45aG5fCQQ Message-ID: Subject: Re: move stack-protector availability out of Kconfig To: whiteheadm@acm.org Cc: Andrew Morton , Masahiro Yamada , Arnd Bergmann , Josh Triplett , Nick Piggin , Laura Abbott , Linux Kernel Mailing List 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 Tue, Feb 13, 2018 at 7:27 AM, tedheadster wrote: > Kees, > I have a question about this patch. When I configure a kernel for > ARCH=i386 it sets these Kconfig variables this way: > > HAVE_CC_STACKPROTECTOR=y > CC_STACKPROTECTOR_AUTO=y > > CC_STACKPROTECTOR_NONE=n > CC_STACKPROTECTOR_REGULAR=n > CC_STACKPROTECTOR_STRONG=n > > It seems to me that at least _one_ of the last _three_ variables > should be set to 'y' with the defaults that are being set, probably > CC_STACKPOINTER_NONE=y. All of them being 'n' doesn't make sense to > me. The last three are a defined state and map to specific flags. _AUTO just tries its best to find any working flag. After some redesign to Kconfig, this may improve so that Kconfig maps directly to things that right now only the Makefile can determine. That's under development now. > As a side note, these defaults set X86_32_LAZY_GS=n (depends on X86_32 > [=y] && CC_STACKPROTECTOR_NONE [=n]) which causes the x86_32 kernels > to hang. I'll discuss that in a different email thread, but just > wanted to say how I came upon this. I'd tested this combination, but I must have missed something. I'll go read the other email... -Kees -- Kees Cook Pixel Security