Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp728066rwb; Thu, 12 Jan 2023 11:28:36 -0800 (PST) X-Google-Smtp-Source: AMrXdXsfy1bp4W+6F5EodwAn/US09nLZkl6sV1JkLPS9Nt3vEV0KE6bx3rR7oG8FnlrtscdH+DFt X-Received: by 2002:a17:90a:fa8f:b0:229:1fa9:6912 with SMTP id cu15-20020a17090afa8f00b002291fa96912mr271105pjb.39.1673551716754; Thu, 12 Jan 2023 11:28:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673551716; cv=none; d=google.com; s=arc-20160816; b=rmV7NfEP5UZQ26aAHcXwlZ42q5WtT823IPUKN/rTzHjx8WQOF06MhRLm3eB2bqGAAO NSMW32Wc0jXowro46AYwJxXNvDYwbgY6IvcMS7HF39/O0yfZz0Qzf6OQJsFFhvtHRMq7 fCEIhlC0JtEfgxsn40+PbGLjzFbKpV3KRTKMjSICobIq9S0X5d1LGGYKWrZ2Z46YVOa/ NC3+jj9Ot2X//woefb+hABvPiEwH5impaVCln+gqQ6WJBDg8tCIyHzrkcEo6hm1xYCKX 5/l+r5wl4fB2SuO6RSsh2zjRegTUR9d0H/AystPpe9Dj/54ifYskL14uuBd2UVwTXAaM fEgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:user-agent:mime-version:date :message-id:dkim-signature; bh=H0U0PSipXsq95JF1w8R+flWoUndSqtzXfJ9/CGKpfp8=; b=kOq6BCHqrUtLM17Di8CfKQ4/L4ThiRtM8gmztp25jO/sVF6lDyvB+O59TYaCfTMP2F CAgAs0Tu8mAK6LE+/OMrv2WG0zs2EIjzHcI/9fz7qlTfz8XQAhzjz9UAUOKKhFn94KEm mJ7qeEFtcoYysdKf63gMe6HzXFyWHUyxLWc+6XAHn6SsclQeRfKCH4phMjG2wKohrIk4 lkPjTqrmaBRd+22Zsgw3FLapd3Mm3sDxBxLpVwyKwC52wN1jW05q88CnadD0v1nGDZgc p0GrqlsuWGHsHFRiB0+zZWY0vXcoaXl9F6oMSdamZuMhcJCCazt8K9RLRlexjnSxNN0i awZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=duE1bCU0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lx1-20020a17090b4b0100b0021929c5bd92si23310413pjb.127.2023.01.12.11.28.30; Thu, 12 Jan 2023 11:28:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=duE1bCU0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240314AbjALTIF (ORCPT + 50 others); Thu, 12 Jan 2023 14:08:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239769AbjALTHV (ORCPT ); Thu, 12 Jan 2023 14:07:21 -0500 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6587BC96 for ; Thu, 12 Jan 2023 10:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673549354; x=1705085354; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=10RfZkZb5SV9PwBP5TlGcgRhGBrbMjAk6DG5J/1Q6Iw=; b=duE1bCU0A8omxOVlXyTbKFfFdYnDBvMocJKlJykzn27qRskSmsXFVGtG M3uSII2rhyQ3bS8baDvHa0/iyuaUHZwxXf89olSbWxMF4zPfo2ICRT+gI KwNFCAYODK3VMXHEMGQuv9FjXMqLT5nbFiR06BmYl7cy6/3z19zOHxmJR IX93L8n19Xf6+KhxMZBWi3yH+j6CKlJutKFP1zNJuElwCMpbpg/O//V68 FmKLzWmf0Tv13Ox+zLNsoavK0ITGwqQbw0uWHbaVnrCwmpEW/R8UHRXpR rtNl0pY06Sb25/UpEWI6ovcCdPx4/vEw+nh6TYUdghl6S23reV7tLZZaS A==; X-IronPort-AV: E=McAfee;i="6500,9779,10588"; a="303491672" X-IronPort-AV: E=Sophos;i="5.97,211,1669104000"; d="scan'208";a="303491672" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2023 10:48:35 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10588"; a="746646078" X-IronPort-AV: E=Sophos;i="5.97,211,1669104000"; d="scan'208";a="746646078" Received: from mdarpino-mobl.amr.corp.intel.com (HELO [10.209.117.208]) ([10.209.117.208]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2023 10:48:34 -0800 Message-ID: Date: Thu, 12 Jan 2023 10:48:33 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH 3/7] x86/cpu: Disable kernel LASS when patching kernel alternatives Content-Language: en-US To: "Chen, Yian" , Sohil Mehta , linux-kernel@vger.kernel.org, x86@kernel.org, Andy Lutomirski , Dave Hansen , Ravi Shankar , Tony Luck , Paul Lai References: <20230110055204.3227669-1-yian.chen@intel.com> <20230110055204.3227669-4-yian.chen@intel.com> <693d8332-3b86-3dcf-fc87-5c3a08a752db@intel.com> <9e0a8b20-cb76-b06d-67fb-f8942df5a2f7@intel.com> From: Dave Hansen In-Reply-To: <9e0a8b20-cb76-b06d-67fb-f8942df5a2f7@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/12/23 10:36, Chen, Yian wrote: > On 1/11/2023 4:37 PM, Dave Hansen wrote: >> On 1/11/23 16:27, Chen, Yian wrote: >>>> It seems we are implicitly relying on the on stac() and clac() >>>> calls that are added for SMAP. Have you tried running with SMAP >>>> disabled i.e "clearcpuid=smap"? >>>> >>> Yes, I tested with clearcpuid=smap. >> It works by accident, then. >> >> clearcpuid=smap means that the kernel should be running as if >> CPUID.(EAX=07H,ECX=0H):EBX.SMAP[bit 20]==0.  STAC/CLAC should #UD in >> that case. >> > It could be something wrong in my Simics simulation environment. Also, Andy Cooper made a very good point: when the kernel enables paging, it's running with a low address so that the instruction pointer stays valid as paging becomes enabled. But, if LASS were enabled and enforced at that point, you'd get a LASS fault and go kablooey. Can you see what simics does in that case, and also make sure we're clearing CR4.LASS when enabling paging? That would obviate the need to do it later in C code too.