Message-ID: <ed41ccf1-8f2d-6d4a-7692-7a3465aca73a@intel.com>
Date:   Tue, 31 Jan 2023 18:25:04 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; 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:     Dave Hansen <dave.hansen@intel.com>,
        "Chen, Yian" <yian.chen@intel.com>, <linux-kernel@vger.kernel.org>,
        <x86@kernel.org>, Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Ravi Shankar <ravi.v.shankar@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Paul Lai <paul.c.lai@intel.com>
References: <20230110055204.3227669-1-yian.chen@intel.com>
 <20230110055204.3227669-4-yian.chen@intel.com>
 <693d8332-3b86-3dcf-fc87-5c3a08a752db@intel.com>
 <ad2da884-c8c8-bc57-e21f-452a08cb10cc@intel.com>
 <b9e73d06-bd95-7c54-3ff1-f9e43c9967a4@intel.com>
 <9e0a8b20-cb76-b06d-67fb-f8942df5a2f7@intel.com>
 <f8352c29-6b9f-2711-ddf4-223a6806f42f@intel.com>
From:   Sohil Mehta <sohil.mehta@intel.com>
In-Reply-To: <f8352c29-6b9f-2711-ddf4-223a6806f42f@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d01qSEQ2QTNTb3lFNEdrS3BaSDZqOWJsVXlFN1pOdGdWUE4ydTk1Y1hkZVpT?=
 =?utf-8?B?N0NyYVJkNlBZdXRITGpOTjN3Slc5QmU1dzRxWitLWDN3ZGkrRFR4RmFKUWxw?=
 =?utf-8?B?dzI4QkNqeVEzWUo5Q1hqRmNaa0RDMFBuQzI1cWkvYjVucHk4WXBxRXE2eEhl?=
 =?utf-8?B?dlRFVHhMT0Y2RW8rNmRjb1FNZjBwa2h2L2k2UGJOK29hZkF2dGJPZ244NHQy?=
 =?utf-8?B?aWVpckF1ZlFwa3JEWjZNZElWaElNbzljM1lGcFgyS2kvbk9POFJxcHR1TkxK?=
 =?utf-8?B?VTNoaUUvTCtEOWgwT1Fmc2dITjE4RFlzSUt1UjdjdENUbERWQitZeGE3RHlk?=
 =?utf-8?B?aExZVitaTXd5U1RuSmJhWXcrL2JtY1YxVmltRkpLMk5CT0tkUjZQS0ozMy9D?=
 =?utf-8?B?VDBEbDlYZm05S1lCdjNMY3A1eVh6VmpsZVRhZTlLZlB0RmRidGEySFB3TWtS?=
 =?utf-8?B?alM4K2Zpam1oZUVYYWhKLzhPMU50aU1KZ0UwNTMrWVZSOXRiU3ErQkxXVGtV?=
 =?utf-8?B?c3hVQnowSkJYRlRyUlhNMG5KQXhRdDcwQUcydm8vc0dUdzNYVHUrekZkc3V6?=
 =?utf-8?B?RHVzYTZsVHlsd0RSL3o3Z3BCQ1JySHFVNTlRNE9OTE8xYkNhMlBySEE4Z1BR?=
 =?utf-8?B?c1daZmtDa3NxQWwyZ2Z2MXc5N2hMNDVmZVZlemp4dDJDV0NPdkt0ZS9hTURi?=
 =?utf-8?B?ZDJLeERGNGJpdUxFbVo0KzZNZnhmNm9lczhMM2xPRUljcmZYdUtZaFJ0UjBU?=
 =?utf-8?B?WkE3QTZKUW5PcEgzdSsvaWc0ZXhrcEVjSTB0djJuampFZkZYaTF6SU9KRmNZ?=
 =?utf-8?B?UW9JV3ZHRHRROU94VmNGb25SNTB6aHZSNFEyNzh6WnF5aDhYenJFRFlxSVpT?=
 =?utf-8?B?L252RDBJbGlFNlNiNnlKd2pYNy9pVTVqL0RNT0NTeDFMUDVSR1ZCTC9kUDVn?=
 =?utf-8?B?TlVZMTlvUERsZEpEeHVia09XcnlXNC9QTGtESVRWcU9yVXNzSVRUM0VDaG93?=
 =?utf-8?B?Rm5HcWpmNXZXZlgwdmxpZE9abm00alh2WWtVdDM4cWsrd25Xc2J0U0JWUGw2?=
 =?utf-8?B?L1RuSC9vVDFmK2srTks1dm9GM0RYeEpyRk5DV1lEbEx3UnVlVnRldys4ZUNw?=
 =?utf-8?B?eDV1V2wraVVzZ2JpWjFTcVp1ZzNEK1RyWTJxOTdFbDRBa1AydGxEeGlKN2Rn?=
 =?utf-8?B?azhZOExwd2FsMTJWMzZ6aE40SktiNEtzN0gyaEhsbUdJVUhPWFlBNDIwZjNI?=
 =?utf-8?B?NEVwcHNoR3pMczF2dHVwSGtwOEF1ZXhFdGxzcHI5V3dtdzQ4Nktscm53WExj?=
 =?utf-8?B?ckRyWjNhNW1YbkRHMjZwQ2VLbDlJdzZhOUlqOXBGc0s0NEhQYiswTmhvVjJI?=
 =?utf-8?B?YnhSK0F1YmM0b0xRaENRamhUYVZyb2piVElHZzA1L0pMUU90bjhOdTZJMThG?=
 =?utf-8?B?ekU4LzNHcWRCSUhBUGRqWVJhMml5cVVhSlJzc2UzQnZlek0rT2lVL1BNOGFm?=
 =?utf-8?B?T2Ntc3NzODdoYjYwNGpKcHZqa3I4aWFhNHpzL0doK1VSeVRhcmUwaUFURC9S?=
 =?utf-8?B?YVY1V3BqeEVLcVo4K3NlcWVrSlNQM1N3bGpQb3I5bncvcWl3MjZ3TXI2disz?=
 =?utf-8?B?MTYzWTRXT2JXZFBoRDgrbzNMMDlrL1paWU1wekR2ZExxWWYxSGZUQzRScEMr?=
 =?utf-8?B?NzFLT2w3YW9SRmhReEVjSGw5dm5jUno3Y0FlbFAxQ0dVUXc4d1MxcTM1KzVQ?=
 =?utf-8?B?bFFCQkRWNjlQMnpYOEIwTCtFQTVpVHYwTThOT3VSQTVZRVpkUzA0WTF5S3o3?=
 =?utf-8?B?WjRXN2cyWE9mcGRUd2xSdkVqS3QzeHlLVlp1QytoUjZNcWRTL1F1SmFMVDBX?=
 =?utf-8?B?YzVHMDEzY2RVcFFyd1VsWHc0ZkxEanlabGtNQzE0TWZpUXVtWllXYy9CaUsx?=
 =?utf-8?B?Q1FVTTRLK1puL3BlQjJNVXJFUmU2UHQzSzljMmZZKzUxM2xjUjNHZHhUeXJZ?=
 =?utf-8?B?cEljWG5uSURMWHZvOXR1eHVrSnZRM2lVcU9aRHNEN3RCekJtZ0NNbmdITVZt?=
 =?utf-8?B?Q1pGTWZSb0dlMXhlcFNlc2FXeVdwRFRWT3dpWi9RRXZQNGhLa3loOEhVODl6?=
 =?utf-8?B?cU1ZY3o0MTlvU0JrclV2UXFKRXhHdDlmMUlRRjd1UEl6UnhHSm04dnIyOWhr?=
 =?utf-8?B?ZFE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 96137740-e416-42e0-38f7-08db03fb8827
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3320.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2023 02:25:06.1190
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: aeX81wUz7CRlajReR4JuuJvSZdw2kno9SM3i9EPOpRtkeC8PccQu1SrisSPVpyXpTw4SGWuFl2w/H/E0h49HQA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR11MB6247
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 1/12/2023 10:48 AM, Dave Hansen wrote:
> 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.

CR4 and CR0 are always restored to a known state during kexec. So,
running with LASS enabled should not happen during early boot.

machine_kexec()
-> relocate_kernel()
   -> identity_mapped()

> 	/*
> 	 * Set cr0 to a known state:
> 	 *  - Paging enabled
> 	 *  - Alignment check disabled
> 	 *  - Write protect disabled
> 	 *  - No task switch
> 	 *  - Don't do FP software emulation.
> 	 *  - Protected mode enabled
> 	 */
> 	movq	%cr0, %rax
> 	andq	$~(X86_CR0_AM | X86_CR0_WP | X86_CR0_TS | X86_CR0_EM), %rax
> 	orl	$(X86_CR0_PG | X86_CR0_PE), %eax
> 	movq	%rax, %cr0
> 
> 	/*
> 	 * Set cr4 to a known state:
> 	 *  - physical address extension enabled
> 	 *  - 5-level paging, if it was enabled before
> 	 */
> 	movl	$X86_CR4_PAE, %eax
> 	testq	$X86_CR4_LA57, %r13
> 	jz	1f
> 	orl	$X86_CR4_LA57, %eax
> 1:
> 	movq	%rax, %cr4
> 
> 	jmp 1f
> 1:

Dave, does this address your concern or were you looking for something
else? Is there some path other than kexec that should also be audited
for this scenario?