Received-SPF: pass (google.com: domain of linux-kernel+bounces-34444-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <e83eb3e8-6d08-462b-9ffe-d843e439d7da@intel.com>
Date: Mon, 22 Jan 2024 16:18:06 -0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH bpf 2/3] x86/mm: Disallow vsyscall page read for
 copy_from_kernel_nofault()
To: Hou Tao <houtao@huaweicloud.com>, <x86@kernel.org>, <bpf@vger.kernel.org>
CC: Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski
	<luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner
	<tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov
	<bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
	<linux-kernel@vger.kernel.org>, xingwei lee <xrivendell7@gmail.com>, "Jann
 Horn" <jannh@google.com>, <houtao1@huawei.com>
References: <20240119073019.1528573-1-houtao@huaweicloud.com>
 <20240119073019.1528573-3-houtao@huaweicloud.com>
Content-Language: en-US
From: Sohil Mehta <sohil.mehta@intel.com>
In-Reply-To: <20240119073019.1528573-3-houtao@huaweicloud.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TzM4OUlkbHhzRmZhenMrNzZrNmc0T2hSMnN5Y3daQkx3N2dpZ05vMk1kUi9s?=
 =?utf-8?B?cHBnVmFVemY5TG9XYmFKdWREVC92cG5HbDNKN0IzdjdtODlPOWR6NEtUT2pP?=
 =?utf-8?B?WC90R3hvQ0szZFRjZTFhaE9mbmV1cXpKVFRCa3R2T3FIZ0FyTFprbm8wRE9Y?=
 =?utf-8?B?akpYOTRWSjJlc1ZVLzVsWFRaVHN5ODdDNGRzdFZRa3FFOFVITFdDV2lLVmw0?=
 =?utf-8?B?a2g2b0FrN0RVbXpzQkgzaDlFK0ZVWmRxN3FsNkIzbzF2L0VQbkxCZGhvL1NU?=
 =?utf-8?B?b1hkOU80ZDJvQndQMFhoVHVTYlVueS82TklYN2orbHhjTC91bGtJZEpldUtv?=
 =?utf-8?B?NFREKys3TWRWb0FQQ2FuZGlXYit1cGVEQW4vbU4zd280NXdvK1kvQ2VrL1ZL?=
 =?utf-8?B?Y0g0OHpmSzNRNGYyU1Y5bEFOZ2JuT2hrYU5OY2MvOXVKQithMGZCTlkvUnlE?=
 =?utf-8?B?SmR3N2VES1A3UStsQXZxa0hnc0JHWElPQXJDamZVKzRScHNCVGJhZFJsc09I?=
 =?utf-8?B?SktBTHFrOVR6U1ZlcWp1TzAxNDM0QXFURXp6enVieWQxSUxuYzNxbnVibmlI?=
 =?utf-8?B?SzlFejZTZlg2YnJmbnJTak1XSGp2dUhRM3ZybEY5eFRnWE9hb1FSaXdPOGtp?=
 =?utf-8?B?RDhINFd0bklRRDVYUEgzcVc2d2lMOVdsWHVEa0xrc2dEdUxpY0dpK2FhY2RN?=
 =?utf-8?B?dFR2Y25XemtueHhLdXNFNEs3QTY2NDc3eGxSN01lV3dTY054eVRWaDhUVVlM?=
 =?utf-8?B?M3pMME8rQ2tUUGM4VTNZM1ZsSzkrQlpsK21PUS9NQW91UHptUkJwRllYeVA4?=
 =?utf-8?B?N1YyT1VDejJJQWE5QktJOG81c1VRa1JOSmZhRlQvRXpPckpOeTdRRHdqVUEy?=
 =?utf-8?B?TFlqaitzMmdCSnhZbnF2UitEY1NMb0tGSFFJUzNaS3ZmVWEyb0d1TEE3L2pi?=
 =?utf-8?B?OHVSTklSSUxPNUNYSlc2cXhMbldIbG5udlVJRS80a3p6MVY0TllYekQrWVhn?=
 =?utf-8?B?SytGU2xFZ2MrQWxrQVZuMnJvMXVaTkFmMk9weGNjaTJaN1pMVEpaT2tyN2to?=
 =?utf-8?B?RHN2MFdhSG9xL3RRcHhMdTYxaTRWYXQ2cVQ1bVNUT2F4RFdDUjUzMDBzNE9t?=
 =?utf-8?B?KzQ0VEdWaG4zcXpvcWd2WUU5c010ZkNtV1luaDlpcTF5STJTYnlmMENBNVRy?=
 =?utf-8?B?OFRDT1JSaUlacWJWSVBXK3NoUnVyODJaMEJrREJHRWkwQ3c0QWJLSS9GS1Bp?=
 =?utf-8?B?TEZPWGVBVEFyam5LbUtxb09ZN1JNVFBjTkx2MHQ1RFltbTlBOHJ6YWpzc2Yr?=
 =?utf-8?B?TVIxcDdOUE9TalhVM2tCekcxWWY1dzFnQ1k5cWVIQ2YvQktKVUlwSk9jdkRa?=
 =?utf-8?B?cm03RzJZc3NVcjRGNXdxUGxIcERGeU43MjI5UEpzU2ZEK1hIMVl2UUFrNi9C?=
 =?utf-8?B?dG9xVzdtckdPemVSSWQzb3oxemlFK3lla1V5QkY3WlJjdlppTXdhVitiV0hs?=
 =?utf-8?B?T0M1VU9ZTDM3R3V3MzVCZFFyWHgrRS92VzBXNHY3NEhGNTNLR3BBSmpPTHky?=
 =?utf-8?B?WENvMG9SUzkxeXE3TmtHY1B2STdicEIveFBteWRMYnp2RzlmUzlzSGpnN1Nk?=
 =?utf-8?B?WnFrazFkK0pRb3h3MUFaeTJCeUpsVnpQTVpsOXBXSUVQVHk0eGJBN1phcTE3?=
 =?utf-8?B?d0MvREtsRlNyb0FuZHFZSkRCSFluZ3gyT2VKTXpDblZZdjRyOG1PNVEyNG9w?=
 =?utf-8?B?STcrMUNYNnBXVjhDMG1oTWJZdTd2dm9xY1dIVDVxUEJTdkNLVitqMzBkZmxw?=
 =?utf-8?B?UnNsTWpSei9YUWdqT2VEak9GQXo1Q20rQXowWWVmbnl5cW4xMkpHUHROVDdE?=
 =?utf-8?B?Q1dDMzlQbHpoa0lTeHJYYUI1bjBmMGJQTEZQaEZtSExSWXp5Mmk0czljRlRF?=
 =?utf-8?B?VEZwNkJITks2aVUxUXorU2lXUER5anZVVVJ3ZGpZZWtERE8yNlhpMXN0NE9a?=
 =?utf-8?B?NnFWZTU2TFBhT3V6aU52V0N3WCtDakJNbGJqYVRSeS85RDJQZ2ZaalVlMVJw?=
 =?utf-8?B?UkdaMmVsYkhpT20reUN6V1RLeFdQVzF4YUhCa001MGdydlhuYmR4YkRIbC9B?=
 =?utf-8?Q?LVqIcvxU3SeSnNJi2iBeF9o6G?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a741c60-44a9-4e95-dad2-08dc1ba8c6a7
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3320.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2024 00:18:08.2607
 (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: o1lSPeTXb0MuKSM2dRqKwt1c5pEr3Fp1ImjOllzqNRXUMne7tctLk1fNaSY7EqkA9nIG0Azp2IHV/hrqfU6h6Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7901
X-OriginatorOrg: intel.com

On 1/18/2024 11:30 PM, Hou Tao wrote:
> From: Hou Tao <houtao1@huawei.com>
> 
> When trying to use copy_from_kernel_nofault() to read vsyscall page
> through a bpf program, the following oops was reported:
> 
>   BUG: unable to handle page fault for address: ffffffffff600000
>   #PF: supervisor read access in kernel mode
>   #PF: error_code(0x0000) - not-present page
>   PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0
>   Oops: 0000 [#1] PREEMPT SMP PTI
>   CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58
>   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
>   RIP: 0010:copy_from_kernel_nofault+0x6f/0x110
>   ......
>   Call Trace:
>    <TASK>
>    ? copy_from_kernel_nofault+0x6f/0x110
>    bpf_probe_read_kernel+0x1d/0x50
>    bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d
>    trace_call_bpf+0xc5/0x1c0
>    perf_call_bpf_enter.isra.0+0x69/0xb0
>    perf_syscall_enter+0x13e/0x200
>    syscall_trace_enter+0x188/0x1c0
>    do_syscall_64+0xb5/0xe0
>    entry_SYSCALL_64_after_hwframe+0x6e/0x76
>    </TASK>
>   ......
>   ---[ end trace 0000000000000000 ]---
> 
> The oops happens as follows: A bpf program uses bpf_probe_read_kernel()
> to read from vsyscall page, bpf_probe_read_kernel() invokes
> copy_from_kernel_nofault() in turn and then invokes __get_user_asm(). A
> page fault exception is triggered accordingly, but handle_page_fault()
> considers the vsyscall page address as a userspace address instead of
> a kernel space address, so the fix-up set-up by bpf isn't applied.

This comment and the one in the code below seem contradictory and
confusing. Do we want the vsyscall page address to be considered as a
userspace address or not?

IIUC, the issue here is that the vsyscall page (in xonly mode) is not
really mapped and therefore running copy_from_kernel_nofault() on this
address is incorrect. This patch fixes this by making
copy_from_kernel_nofault() return an error for a vsyscall address.


> Because the exception happens in kernel space and page fault handling is
> disabled, page_fault_oops() is invoked and an oops happens.
> 
> Fix it by disallowing vsyscall page read for copy_from_kernel_nofault().
> 

[Maybe I have misunderstood the issue here and following questions are
not even relevant.]

But, what about vsyscall=emulate? In that mode the page is actually
mapped. Would we want the page read to go through then?

> Originally-from: Thomas Gleixner <tglx@linutronix.de>

Documentation/process/maintainer-tip.rst says to use "Originally-by:"


> diff --git a/arch/x86/mm/maccess.c b/arch/x86/mm/maccess.c
> index 6993f026adec9..bb454e0abbfcf 100644
> --- a/arch/x86/mm/maccess.c
> +++ b/arch/x86/mm/maccess.c
> @@ -3,6 +3,8 @@
>  #include <linux/uaccess.h>
>  #include <linux/kernel.h>
>  
> +#include "mm_internal.h"
> +
>  #ifdef CONFIG_X86_64
>  bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
>  {
> @@ -15,6 +17,10 @@ bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
>  	if (vaddr < TASK_SIZE_MAX + PAGE_SIZE)
>  		return false;
>  
> +	/* vsyscall page is also considered as userspace address. */

A bit more explanation about why this should happen might be useful.

> +	if (is_vsyscall_vaddr(vaddr))
> +		return false;
> +
>  	/*
>  	 * Allow everything during early boot before 'x86_virt_bits'
>  	 * is initialized.  Needed for instruction decoding in early