All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
	dave.martin@arm.com, linux-arm-kernel@lists.infradead.org,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v2 07/10] arm64: asm: Provide a mechanism for generating ELF note for BTI
Date: Wed, 6 May 2020 16:39:06 +0100	[thread overview]
Message-ID: <20200506153906.GF5299@sirena.org.uk> (raw)
In-Reply-To: <20200506134433.GA12453@willie-the-truck>


[-- Attachment #1.1: Type: text/plain, Size: 1198 bytes --]

On Wed, May 06, 2020 at 02:44:34PM +0100, Will Deacon wrote:
> On Wed, May 06, 2020 at 01:38:55PM +0100, Mark Brown wrote:

> > Right, I was just expecting to have the ifdefs selecting the flags to
> > emit in the middle of the asm macro definiton rather than separately - I
> > didn't see a huge win in defining a macro with the only user being
> > another macro.  I can do something along those lines though.

> With my suggestion, we still only have the 'emit_aarch64_feature_1_and'
> macro, it just provides a way to override the properties if we need that
> later on. All I'm proposing is adding the optional feat parameter, which
> defaults to all of the properties we know about.

> > That will result in us emitting the note with no flags set which
> > *should* be totally fine but is a bit unusual and feels like tempting
> > fate.

> Nah, that's just the dummy .macro definition.

I see - I had been reading the idea as being to have the macro outside
the #ifdef for BTI so that it's usable separately from that and that
you'd just not updated the ifdefs while sketching it out.  I think I've
got a sensible way of achieving that without too much pain though so it
should be fine anyway.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-05-06 15:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29 21:16 [PATCH v2 00/10] arm64: BTI kernel and vDSO support Mark Brown
2020-04-29 21:16 ` [PATCH v2 01/10] arm64: bti: Support building kernel C code using BTI Mark Brown
2020-05-05 16:50   ` Dave Martin
2020-05-05 17:31     ` Mark Brown
2020-05-06 12:24       ` Amit Kachhap
2020-04-29 21:16 ` [PATCH v2 02/10] arm64: asm: Override SYM_FUNC_START when building the kernel with BTI Mark Brown
2020-05-05 14:56   ` Will Deacon
2020-05-05 15:18     ` Mark Brown
2020-05-05 16:08       ` Will Deacon
2020-05-05 17:21         ` Mark Brown
2020-05-06  7:10           ` Will Deacon
2020-05-06 10:41             ` Mark Brown
2020-05-06 10:50               ` Will Deacon
2020-05-06 11:43                 ` Mark Brown
2020-05-06 12:27                   ` Will Deacon
2020-05-06 13:03                     ` Mark Brown
2020-05-06 13:40                 ` Dave Martin
2020-05-06 14:45                   ` Will Deacon
2020-05-06 15:25                     ` Mark Brown
2020-05-06 15:48                       ` Will Deacon
2020-05-06 15:33                     ` Dave Martin
2020-04-29 21:16 ` [PATCH v2 03/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel Mark Brown
2020-04-29 21:16 ` [PATCH v2 04/10] arm64: bpf: Annotate JITed code for BTI Mark Brown
2020-04-29 21:16 ` [PATCH v2 05/10] arm64: mm: Mark executable text as guarded pages Mark Brown
2020-04-29 21:16 ` [PATCH v2 06/10] arm64: bti: Provide Kconfig for kernel mode BTI Mark Brown
2020-04-29 21:16 ` [PATCH v2 07/10] arm64: asm: Provide a mechanism for generating ELF note for BTI Mark Brown
2020-05-05 14:58   ` Will Deacon
2020-05-05 16:51     ` Dave Martin
2020-05-05 17:06     ` Mark Brown
2020-05-06 11:26       ` Will Deacon
2020-05-06 12:38         ` Mark Brown
2020-05-06 13:44           ` Will Deacon
2020-05-06 15:39             ` Mark Brown [this message]
2020-04-29 21:16 ` [PATCH v2 08/10] arm64: vdso: Annotate " Mark Brown
2020-04-29 21:16 ` [PATCH v2 09/10] arm64: vdso: Force the vDSO to be linked as BTI when built " Mark Brown
2020-04-29 21:16 ` [PATCH v2 10/10] arm64: vdso: Map the vDSO text with guarded pages " Mark Brown
2020-04-30 17:18 ` [PATCH v2 00/10] arm64: BTI kernel and vDSO support Catalin Marinas
2020-04-30 17:23   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200506153906.GF5299@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Vincenzo.Frascino@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.martin@arm.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.