From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 115195336B for ; Fri, 4 Oct 2024 05:22:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728019380; cv=none; b=a+9/DjqXroc1VWNfJdcBP4bWtoPoRpvJMSPUt23wwkIAjRAMncru92mA0IgvVMGCFcEqJ+BqUHyDGxLgGaAn7aFQDOWv7NiWfniaegWZ452bl/IuVAfZJ1coCmVArjWNhEeGdrxyd2Z843XguWoGZfHHCwgIc6fw1ptTc/LQdik= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728019380; c=relaxed/simple; bh=h2KOwXGuTl8YL616M034HB2Af84RJl0wNEM+e6ELGpA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UX+hQkThEUK00mtBY2cMMVXlDCbEd4OhWJdEDrQxbhSiO58ayXEJfXi3Reu+NOZN6lcMbPFFA2psywlrdn6ZiQV1LArtx+sEeekcnLodJY/OcChGEI7iYBqtE8qM8KNdAryrXmEfiN2BE09BhenP59WheWq78L1zHUTymgq9BAQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=R5UqaS2J; arc=none smtp.client-ip=91.218.175.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="R5UqaS2J" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1728019375; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lrfQ1i8tmMnvMbKBi8z6qLedVp5+8gOVmXGH6LKyfxY=; b=R5UqaS2JO180imhgB488/5NX0x4SzMGXAd8rVnZf+Frak3WNNqs1WUw6ufnQyv1s3W0tB7 kyIM71IMZ/VgkfMjP9zGoIDid0xzEiewVSeFFMlLG3B2KyMfqtlNNmA3oXV7M0UOm6rdrt XU5BnsFLBEXGJf2aGYTJthENB4ZAWYo= Date: Thu, 3 Oct 2024 22:22:48 -0700 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: yet another approach Was: [PATCH bpf-next v3 4/5] bpf, x86: Add jit support for private stack Content-Language: en-GB To: Alexei Starovoitov Cc: Kumar Kartikeya Dwivedi , bpf , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Kernel Team , Martin KaFai Lau References: <20240926234506.1769256-1-yonghong.song@linux.dev> <8b6c1eb1-de43-4ddb-b2b6-48256bdacddb@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yonghong Song In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 10/3/24 3:32 PM, Alexei Starovoitov wrote: > On Thu, Oct 3, 2024 at 1:44 PM Yonghong Song wrote: >>> Looks like the idea needs more thought. >>> >>> in_task_stack() won't recognize the private stack, >>> so it will look like stack overflow and double fault. >>> >>> do you have CONFIG_VMAP_STACK ? >> Yes, my above test runs fine withCONFIG_VMAP_STACK. Let me guard private stack support with >> CONFIG_VMAP_STACK for now. Not sure whether distributions enable >> CONFIG_VMAP_STACK or not. > Good! but I'm surprised it makes a difference. That only for the test case I tried. Now I tried the whole bpf selftests with CONFIG_VMAP_STACK on. There are still some failures. Some of them due to stack protector. I disabled stack protector and then those stack protector error gone. But some other errors show up like below: [ 27.186581] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 27.187480] BUG: unable to handle page fault for address: ffff888109572800 [ 27.188299] #PF: supervisor instruction fetch in kernel mode [ 27.189085] #PF: error_code(0x0011) - permissions violation or [ 27.736844] BUG: unable to handle page fault for address: 0000000080000000 [ 27.737759] #PF: supervisor instruction fetch in kernel mode [ 27.738631] #PF: error_code(0x0010) - not-present page [ 27.739455] PGD 0 P4D 0 [ 27.739818] Oops: Oops: 0010 [#1] PREEMPT SMP PTI ... Some further investigations are needed. > Please still root cause the crash without VMAP_STACK. Sure. Let me investigate cases with VMAP_STACK first and then will try to look at it without VMAP_STACK. > > We need to do a lot more homework here before proceeding. > Look at arch/x86/kernel/dumpstack_64.c > At least we need new stack_type for priv stack. > stack_type_unknown doesn't inspire confidence. > Need to make sure stack trace is still reliable with priv stack. > Though it may look appealing from performance pov. > We may need to go back to r9 approach with push/pop around calls, > since that is surely keeping unwinder happy > while this approach will have to teach unwinder. Good point.