Received-SPF: pass (google.com: domain of linux-kernel+bounces-184758-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Jiri Olsa <olsajiri@gmail.com>
Date: Tue, 21 May 2024 12:11:57 +0200
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "olsajiri@gmail.com" <olsajiri@gmail.com>,
	"oleg@redhat.com" <oleg@redhat.com>,
	"songliubraving@fb.com" <songliubraving@fb.com>,
	"luto@kernel.org" <luto@kernel.org>,
	"mhiramat@kernel.org" <mhiramat@kernel.org>,
	"andrii@kernel.org" <andrii@kernel.org>,
	"debug@rivosinc.com" <debug@rivosinc.com>,
	"john.fastabend@gmail.com" <john.fastabend@gmail.com>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"ast@kernel.org" <ast@kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
	"yhs@fb.com" <yhs@fb.com>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"linux-trace-kernel@vger.kernel.org" <linux-trace-kernel@vger.kernel.org>,
	"bp@alien8.de" <bp@alien8.de>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support
Message-ID: <ZkxzbSq3bS2loTJI@krava>
References: <a8b7be15e6dbb1e8f2acaee7dae21fec7775194c.camel@intel.com>
 <Zj_enIB_J6pGJ6Nu@krava>
 <20240513185040.416d62bc4a71e79367c1cd9c@kernel.org>
 <c56ae75e9cf0878ac46185a14a18f6ff7e8f891a.camel@intel.com>
 <ZkKE3qT1X_Jirb92@krava>
 <20240515113525.GB6821@redhat.com>
 <0fa9634e9ac0d30d513eefe6099f5d8d354d93c1.camel@intel.com>
 <20240515154202.GE6821@redhat.com>
 <Zkp6mT2xag29dLTR@krava>
 <81afa4ccc661a1598b659958164c7a73cf211d21.camel@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <81afa4ccc661a1598b659958164c7a73cf211d21.camel@intel.com>

On Tue, May 21, 2024 at 01:31:53AM +0000, Edgecombe, Rick P wrote:
> On Mon, 2024-05-20 at 00:18 +0200, Jiri Olsa wrote:
> > anyway I think we can fix that in another way by using the optimized
> > trampoline,
> > but returning to the user space through iret when shadow stack is detected
> > (as I did in the first version, before you adjusted it to the sysret path).
> > 
> > we need to update the return address on stack only when returning through the
> > trampoline, but we can jump to original return address directly from syscall
> > through iret.. which is slower, but with shadow stack we don't care
> > 
> > basically the only change is adding the shstk_is_enabled check to the
> > following condition in SYSCALL_DEFINE0(uretprobe):
> > 
> > ????????if (regs->sp != sp || shstk_is_enabled())
> > ????????????????return regs->ax;
> 
> On the surface it sounds reasonable. Thanks.
> 
> And then I guess if tradeoffs are seen differently in the future, and we want to
> enable the fast path for shadow stack we can go with your other solution. So
> this just simply fixes things functionally without much code.

yes, if we want to enable the fast path for shadow stack in future
we'll need to remove that shstk_is_enabled and push extra frame on
shadow stack

jirka