Re: [PATCH v15 0/6] arm64: Reorganize the unwinder and implement stack trace reliability checks

From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Mark Brown <broonie@kernel.org>, Will Deacon <will@kernel.org>
Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org,
	nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com,
	catalin.marinas@arm.com, jamorris@linux.microsoft.com,
	linux-arm-kernel@lists.infradead.org,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v15 0/6] arm64: Reorganize the unwinder and implement stack trace reliability checks
Date: Fri, 24 Jun 2022 17:15:31 -0500	[thread overview]
Message-ID: <3180d0d3-2a92-13cd-2342-39b8400e3306@linux.microsoft.com> (raw)
In-Reply-To: <YrWjH4H7KxLAqfph@sirena.org.uk>

On 6/24/22 06:42, Mark Brown wrote:
> On Thu, Jun 23, 2022 at 06:32:24PM +0100, Will Deacon wrote:
>> On Fri, Jun 17, 2022 at 04:07:11PM -0500, madvenka@linux.microsoft.com wrote:
> 
>>> as HAVE_RELIABLE_STACKTRACE depends on STACK_VALIDATION which is not present
>>> yet. This patch will be added in the future once Objtool is enhanced to
>>> provide stack validation in some form.
> 
>> Given that it's not at all obvious that we're going to end up using objtool
>> for arm64, does this patch series gain us anything in isolation?
> 
> Having the reliability information seems like it should be useful in
> general even without doing live patching - we can use it to annotate
> stack traces to warn people about anything that might be suspect in
> there.  For live patching it's probably something we'll want regardless
> of the use of objtool, it's one more robustness check which always
> helps.

Hi Mark, Will,

Your comments got me to thinking about the Objtool patch series I have sent earlier.

Since the general feeling is that Objtool is unlikely to be our path to livepatch on ARM64, I think that I can implement what I want in a simpler way as a kernel-only solution. The kernel already has a decoder. I don't need
to provide one. In the kernel-only solution, I don't have to worry about relocations, alternatives, etc, etc.

The number of patches would be about half of the original series with simpler code in many of the patches.

The amount of memory consumed by the CFI entries will most likely be just a fraction of the original series.

I will investigate this. If it works and turns out to be a lot simpler, I will send this as v3 of the livepatch
patch series. Also, if this works, we can replace the various reliability checks with just a single fp validation
check in the unwinder.

Thanks for the input.

Madhavan