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;
Message-ID: <de08c24f-782d-69e5-6547-6efe0c4ca94a@intel.com>
Date:   Wed, 11 Jan 2023 18:49:39 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [PATCH 4/7] x86/vsyscall: Setup vsyscall to compromise LASS
 protection
Content-Language: en-US
To:     "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-5-yian.chen@intel.com>
 <c2012105-0af6-6720-5a24-719dec775fed@intel.com>
 <adf3a609-656f-82a2-6a4e-199a12de298b@intel.com>
From:   Sohil Mehta <sohil.mehta@intel.com>
In-Reply-To: <adf3a609-656f-82a2-6a4e-199a12de298b@intel.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cEpuVjlvTWxIU2c1ZEswdFJxalVzUmFqTll2eGQwWFZ0UjBSUkJRZXI0V1ZO?=
 =?utf-8?B?WGJCQURLQTRPUU54MTZXVnJZUVhxVU5qYUw4M0ZtNzZBcFljdlBhVVJoUTh6?=
 =?utf-8?B?SVVmbHdERmtzakFxa3BuZlh3QW9QTUp5cGZJR3ZLRzJKUFo5QmhtaU0vTldP?=
 =?utf-8?B?MWxPZ1FaNC9lZ3V6Wm5mU3Rxb0xjT2FrUWxmUllmM2pzaHl1VEh5eCs1Y3ov?=
 =?utf-8?B?WW5CSm1JcUsyMWYrM0tzejlvbkxnYk5GR3dxK2dKQ2ZyVUlGSnpTTWptSVBG?=
 =?utf-8?B?UFpJWHRHSmQyUmNzRWtsNTJNVmszTU9rUmlVWEF0RFllblFNQVhycFJFekRB?=
 =?utf-8?B?TUhRSEZwbkNWNC9sREErWHFQT1E4NHdUMitWMGE0UmtIcG1BOWQxdU5QY2Nu?=
 =?utf-8?B?ZDBmWkNKaW1QalVRcm0vYmEwcXlSblhqWFFCNDdKZGFyM3FtWUY2ZHFGbWJO?=
 =?utf-8?B?aHY3K2l2YVNNSW5tb0REN3lyUUNlU0NBUm9kdHhwa3EvK1B6OGZxTWNlWXR1?=
 =?utf-8?B?UVFxNHhhLzV3NVZBQ01LSkk1SUlTSFZweWhtZEVsSWgxNnJwWEZBOGloWXo2?=
 =?utf-8?B?SVNDVkI5a1A1RFY4cEJmc3NjYUduR3l1dlJCZTFtdHduZ3dENTVmV1VhalJ2?=
 =?utf-8?B?QmJXOWJ2c3NidVNueTBZYklQM0tHcDd4YWJwemloTjZUdmdEWE1KQnpnWkJP?=
 =?utf-8?B?dnJkYUFBc3plTXlONE8rMVZZVDhHaXViYVFnSWM5MEtFYTh0cFR0b0c0R3Bt?=
 =?utf-8?B?RkpzbDlhUy9JNUJsZW1Rd2RzcGtRVEtCYmRDMmVIL3g5ZTBGOUoxY2k0YXMy?=
 =?utf-8?B?ZTNCNG5xNTZVdkRseUNBVUoybTY0c2V0aE45T1lhOVh6aWE2dXlrRFNDN2dn?=
 =?utf-8?B?QVlaNjk1bnd4aXdXRmMvNUJnblZlNGRHUXordFJUbExNK1ptQXZqTjhaQ291?=
 =?utf-8?B?L3lKa2ZFUTJweGpUR2pDU2orMVRYWVljRXRsZ0lJM1ozMktFRGpXeE5hZC83?=
 =?utf-8?B?ekZEQmtpL1diclVvcHZiYWE1elBCR3M2YlpwSEVwTTczNi8ycHY2UTlmTTJ0?=
 =?utf-8?B?WFZYOUc5U0lDSDZta2hIK1RRRE9PcTNRZ3RnYjU3V2U2c2Y0bEM4Y1NOaFVC?=
 =?utf-8?B?U3lEdHYxZWpUK0dzeS9GVHBGdCtjTjI1L0VySS91eU5haXJ3M3BRK2IzNjRy?=
 =?utf-8?B?QW9BY3h5blhaRjVWSjRuNkNwL01WWThIQjk0TktDcTN0ekpCZytPZVZVSm5s?=
 =?utf-8?B?bWRhRk0xRTFVQnRBTW1zVDdFWXE0WWpqc0VqZEFaenM4L2tiWnQ2cmJtaUlF?=
 =?utf-8?B?L1IvVXVVRDRXWG1EV29kbURxeTJGUDZ0UHJSWE5HTVZtNjF3dGZpYUFORzEv?=
 =?utf-8?B?V2NHQXRpYzRCUEQxY3ZGbDFWYjJVZmxqKzkrZVYveUJCcnN5TkR1R3BOK2cx?=
 =?utf-8?B?aVRWeStyM0hWR3FmdFU4VjdyM3RVdXpNdHA1RHNMOGsvTXlRbGQreXJqbGQw?=
 =?utf-8?B?TXBtYUorS0FEQnBzMlJDMVZQZjZxVmw2blpSM0NLMFVhRk5xVnl5Y2QwUG01?=
 =?utf-8?B?QVdTLzdjbE04REJtTVNVUHFMVHQvTUdEWHE5bmFKdXhiaGNTRjcrS2NHaEti?=
 =?utf-8?B?ekdST2pzN3VEaEk0MUNkSjM0SEsrcUFNR2dGWno2OXNiSHNWdEFwcmFxZnp1?=
 =?utf-8?B?NE44TVh5TGRVL0twbVZpNzAvblFPYUdWbk90ODA5a2RydVVyOVF2Yks0THZz?=
 =?utf-8?B?UHBWOWlzaHkyek05STZIWjU2Ni9iVVJ6T1c4K3g3V2JRa3pQSVdoNkdqRW9u?=
 =?utf-8?B?WU0wVDBUKzlOV1BnQkRCSnZzVUFUaGhzYlhkL080OU45VTNoeGRLYjNiQzVB?=
 =?utf-8?B?UWlqdVppVnNqQ29vZ1pxaGpWM2o5M1Q4T01UUW1VN2F4VVlTNDdLckEwZzhZ?=
 =?utf-8?B?Y1Qycm5ENVdiS1BsNFpSUWV4Tys4SEgxWTROWjNhYUp4akRlSVgrbEsrWXFq?=
 =?utf-8?B?cU9SV3NNVDFPVkRVdExSQ2YrU3pNVDFKS09paHlsS1JwY3hrZkRidis3K0h5?=
 =?utf-8?B?ZjlKb2pUUHh5cEticjJkdEYySk80N2xVa1RvNk5nWFVvZTliaWg1eTVUQTRo?=
 =?utf-8?Q?LgOx6GtVurqtIw1hZDvcCeR2n?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e9d25487-dfae-49ac-b585-08daf447a74c
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3320.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2023 02:49:41.7867
 (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: wwOHmpHe5Onmz/1bhXtmn3g22nsHEPSXxThtvnqJPvh74mV+jDhFeDGW4NbMPQcAasg8qx+KR61Et24vEmv7GA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4858
X-OriginatorOrg: intel.com
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_NONE,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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> The existing documentation here is incorrect. The default vsyscall 
>> mode is actually xonly. This has been so since:
>> commit 625b7b7f79c6 (x86/vsyscall: Change the default vsyscall mode to 
>> xonly)
>>
> Yes, you are right. but this patch can overwrite and correct existing 
> one. I am assuming we don't need to correct the existing document first 
> before update it for LASS.
> 

We should fix this independent of the LASS enabling. I sent a patch 
earlier today to address it. I apologize, I missed cc'ing you.

https://lore.kernel.org/lkml/20230111193211.1987047-1-sohil.mehta@intel.com/

>>> +            In newer versions of Intel platforms that come with
>>
>> Words such as "newer" in the kernel start losing meaning very quickly. 
>> Also, this comment looks out of place in between the vsyscall 
>> sub-options.
>>
>>> +            LASS(Linear Address Space separation) protection,
>>> +            vsyscall is disabled by default. Enabling vsyscall
>>> +            via the parameter overrides LASS protection.
>>> +
> Sure, I will take out this part change.

Actually, having some text here might be ok. I mistook it to be placed 
between the sub-options. But avoid merging it with the previous 
paragraph as is the case right now.

>> Instead of doing this dance, can we provide a simplified behavior to 
>> the user/admin and move the decision making to compile time?
>>
> Current strategy is to disable vsyscall by default only for LASS capable 
> platforms. So that the dynamic decision is likely a necessary.
> 

Making this dynamic and platform dependent would make things hard to 
debug and isolate. It would be a perfect recipe for "But, it works on my 
system!" type of issues.

Let's see what others have to say.

-Sohil