lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210729145210.GP4670@sirena.org.uk>
Date:   Thu, 29 Jul 2021 15:52:10 +0100
From:   Mark Brown <broonie@...nel.org>
To:     "Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>
Cc:     Mark Rutland <mark.rutland@....com>, jpoimboe@...hat.com,
        ardb@...nel.org, nobuta.keiya@...itsu.com,
        sjitindarsingh@...il.com, catalin.marinas@....com, will@...nel.org,
        jmorris@...ei.org, pasha.tatashin@...een.com, jthierry@...hat.com,
        linux-arm-kernel@...ts.infradead.org,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v6 3/3] arm64: Create a list of SYM_CODE functions,
 check return PC against list

On Thu, Jul 29, 2021 at 09:06:26AM -0500, Madhavan T. Venkataraman wrote:
> On 7/28/21 12:25 PM, Mark Rutland wrote:
> > On Wed, Jun 30, 2021 at 05:33:56PM -0500, madvenka@...ux.microsoft.com wrote:

> > Since some of the above is speculative (e.g. the bit about optprobes),
> > and as code will change over time, I think we should have a much terser
> > comment, e.g.

> > 	/*
> > 	 * As SYM_CODE functions don't follow the usual calling
> > 	 * conventions, we assume by default that any SYM_CODE function
> > 	 * cannot be unwound reliably.
> > 	 *
> > 	 * Note that this includes exception entry/return sequences and
> > 	 * trampoline for ftrace and kprobes.
> > 	 */

> Just to confirm, are you suggesting that I remove the entire large comment
> detailing the various cases and replace the whole thing with the terse comment?
> I did the large comment because of Mark Brown's input that we must be verbose
> about all the cases so that it is clear in the future what the different
> cases are and how we handle them in this code. As the code evolves, the comments
> would evolve.

I do agree with Mark that this has probably gone from one extreme to the
other and could be cut back a lot - originally it didn't reference there
being complicated cases like the trampoline at all IIRC so you needed
external knowledge to figure out that those cases were handled.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ