Received: by 10.223.185.116 with SMTP id b49csp4227680wrg; Tue, 13 Feb 2018 15:15:50 -0800 (PST) X-Google-Smtp-Source: AH8x227iXxaDcvTP6gLVnUoFuj7Km4Zc0OVsqMAOA+9J/1O5gPUKr1uPXv8aLsH1neHEHG1t7bus X-Received: by 2002:a17:902:9897:: with SMTP id s23-v6mr2521588plp.238.1518563750674; Tue, 13 Feb 2018 15:15:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518563750; cv=none; d=google.com; s=arc-20160816; b=lQNJgvIfdMnt9nojCb2q5voCKWm1sYZCbuDxuaQYjaLMfTbfMkqvj7rT113+ifso6V s28TA2rV7O+j9Y0HQJAuBiwxUQz8LTgl/0pn7LVj19qeWMfur9awHrEvFBNefswsp8ao temDvvnMH2s/mebY7aPIeyH1u4V09NH/cjyhgSxXEdm6yIdkM8KMnbWPaWoAuU+azY29 E8YpMo7lFaOBJ6eHnvWOIChpAEAlL0qhJAS+kNMu1rILFBU1QymMIXrxd0kwq04ID2LP gfJEJWtrA5PlgM6t2NU3+Ct9ulXyw/bbMwHLJJJtNoo/UQiH/H+RU8X9Eb/nQiCWac5q eUxg== 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:reply-to:mime-version:dkim-signature :arc-authentication-results; bh=od1E0ZHAOWUqsJTUea+zgFkBI9tVIVSGB7oakK9nVLQ=; b=xokZhi0bPYCWt4JwmS100XCwWd9Esq7Ez0C3Fwuk8860faGPA3zGpchrcAxnXsme3S azGFhlzSEr4jAoZxgU3HPJdjALusf/w848dSX1xXVAalnLOmcuMnspxS7grpxxMIsbkj IQrnMRuxi2tZdHh1sjfftUmps18mIdghwQJnQMlwQ8nzxnBfVDWb2gncFVK3r6t0AJXx 7rCCPTYkqR3Cl9nDMFeFE4etqNzjIdcv8UzWn8liA2TkFbXMLxNRUYjhy4SG0Y39pyOL hhFxv4Bx8/UOxLeHplxVgZXca2BUKj80bpkZG+1D3Re8B0uoDS2x0t7jbO4/X1VvRnVH bH5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WLmc1V4z; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u87si662034pfj.41.2018.02.13.15.15.35; Tue, 13 Feb 2018 15:15: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=@gmail.com header.s=20161025 header.b=WLmc1V4z; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966083AbeBMXOg (ORCPT + 99 others); Tue, 13 Feb 2018 18:14:36 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:51653 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966003AbeBMXOf (ORCPT ); Tue, 13 Feb 2018 18:14:35 -0500 Received: by mail-it0-f66.google.com with SMTP id 193so10257966iti.1 for ; Tue, 13 Feb 2018 15:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=od1E0ZHAOWUqsJTUea+zgFkBI9tVIVSGB7oakK9nVLQ=; b=WLmc1V4zyRJhd0wSNZC/Ik2ztVw3gFM7b8f4rAhnJBP/p/41zrk0cardGK9flM6Gs8 Ap1jCQCKMZmQyrraOn6e27VfMVBro7EfFtcZxfEveBW17PWbdvlf7XSanDoMezwajPkm JwV+ftrTi34uyILnXG1y+x2+vdSxjeEm4CKlCK6HiqgdTigD+P351xSULd+zC63WRm/5 rOU1XieAsJ9xiARAnqu1hVBsf90/aZFhVrz39s8l0zMd0LEmKEObcj8GFKUEMiQyV6D3 38Wh4kYs6lGV2ZwPNQ6c+GbJnc/ytDxHf8z9Qa3oKXU/ikTHIQqJ+W+aIu9vjloDUIqa Di3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=od1E0ZHAOWUqsJTUea+zgFkBI9tVIVSGB7oakK9nVLQ=; b=ma5LK234KVx81Z0isPqj0HXBQK67Whm+p1LlMIwEw71x5H925IjymIn9Gy2QpqgQWX 7XVk8mROhJlY1k7wSH9uaDCUcm04Y6gk2ZBay8eKKUfpTW23/jjVxRYLwa5ztX8tMLHj FCQyZAP7mK/MWTShoUuCrlWiliXwd6eSgEu+BvOpiKIdhVOhV97qED/Oi8h+y6LLIhAe bVao6Ql5LqmrHTE5FKj2g5UFkEmDuy2xO9NAs5fWUFd/HVrs+vT/B1Huke48btYTAqtf uRmR4bVzQux2qxM23ehD1lWGQ30BjsF/XOyPUi8l6xVx6J+HRIGzVU/TKLDrPFpmOyB5 a25A== X-Gm-Message-State: APf1xPCjFwow6EXB9q6abfeY7llU903ulFcULvsg0u84Mt0WgWfgj8Rk tEL94AulhFP4GFWN78eEdEyLbefddDWWwnrAgg== X-Received: by 10.36.172.91 with SMTP id m27mr3915953iti.143.1518563674650; Tue, 13 Feb 2018 15:14:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.153.2 with HTTP; Tue, 13 Feb 2018 15:14:13 -0800 (PST) Reply-To: whiteheadm@acm.org In-Reply-To: References: <20180213165159.GR695913@devbig577.frc2.facebook.com> From: tedheadster Date: Tue, 13 Feb 2018 18:14:13 -0500 Message-ID: Subject: Re: x86/stack protector: X86_32_LAZY_GS=n hangs kernel on old processors To: Kees Cook Cc: Tejun Heo , jeremy@xensource.com, Rusty Russell , Ingo Molnar , 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 4:37 PM, Kees Cook wrote: > On Tue, Feb 13, 2018 at 8:57 AM, tedheadster wrote: >> Changing X86_32_LAZY_GS to 'y' does not cause the kernel to hang. >> >>> On Tue, Feb 13, 2018 at 11:40:17AM -0500, tedheadster wrote: >>>> in your patch "x86: make lazy %gs optional on x86_32" were you able >>>> to test it on really old processors? In 4.16.0-rc1, X86_32_LAZY_GS got >>>> toggled from 'y' to 'n' in my default config because of changes to the >>>> stack protector code. It hangs my ancient i486 test machine right >>>> after 'Booting the kernel'. >>> >>> I didn't have access to an i486 at the time or ever since, so it >>> wasn't tested there. If this is specific to i486, flagging it so in >>> the config probably isn't the end of the world at this point. >> >> Tejun, >> I will be able to test this on other 32bit hardware at the end of >> the week. Hopefully I'll be able to identify which processors it does >> not work on (i486/i586/i686). > > So, this is the exact opposite of my tests: if I had X86_32_LAZY_GS=y > and stack protector enabled (via _AUTO), the boot would hang. This > change solved that for me: > > config X86_32_LAZY_GS > def_bool y > - depends on X86_32 && !CC_STACKPROTECTOR > + depends on X86_32 && CC_STACKPROTECTOR_NONE > > since stack-protector in _AUTO mode had to reorganize that logic. It > seemed LAZY_GS isn't compatible with stack-protector, so I made sure > to retain that. What are your other configs? > Kees, I am running the 4.16-rc1 release. My arch/x86/Kconfig has this logic: config X86_32_LAZY_GS def_bool y depends on X86_32 && CC_STACKPROTECTOR_NONE I get a hang on i486 when I choose any of these configuration options: CONFIG_CC_STACKPROTECTOR_AUTO=y CONFIG_CC_STACKPROTECTOR_REGULAR=y CONFIG_CC_STACKPROTECTOR_STRONG=y Also, CONFIG_X86_32_LAZY_GS does not appear in any of these config files, not even as "# CONFIG_X86_32_LAZY_GS is not set", which I thought was strange. The only configuration that works on i486 is: CONFIG_CC_STACKPROTECTOR_NONE=y CONFIG_X86_32_LAZY_GS=y Now it gets interesting. All four of these configurations boots successfully when compiled for, and run on, a Pentium 4 M (CONFIG_PENTIUM4). So it certainly is related to what version of the processor you use. I will continue to try other configuration combinations and report back. - Matthew