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: <1437405004-1296-1-git-send-email-daniel.thompson@linaro.org>
Date:	Mon, 20 Jul 2015 16:09:59 +0100
From:	Daniel Thompson <daniel.thompson@...aro.org>
To:	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>
Cc:	Daniel Thompson <daniel.thompson@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	patches@...aro.org, linaro-kernel@...ts.linaro.org,
	John Stultz <john.stultz@...aro.org>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	Marc Zyngier <marc.zyngier@....com>,
	Andre Przywara <andre.przywara@....com>
Subject: [PATCH v2 0/5] arm64: alternative: Provide if/else/endif assembler macros

Will: This is a split out version of previous patch, as requested. I have
      retained a patch at the send of the series to nix alternative_insn
      but there's no need to take this one for 4.3. Likewise I've fully
      split out all the switch-over patches so you can just drop them
      if they bring any merge trouble.

The existing alternative_insn macro has some limitations that make it
hard to work with. In particular the fact it takes instructions from it
own macro arguments means it doesn't play very nicely with C pre-processor
macros because the macro arguments look like a string to the C
pre-processor. Workarounds are (probably) possible but things start to
look ugly.

This patchset introduces new macros that allow instructions to be
presented to the assembler as normal and overcomes these limitations,
together with patches to switch all existing users to the new macros.

My view is that these if_not/else/endif macros are more readable
than the original macro and that alone might be enough to justify them.
However below is an concrete example of an alterntive sequence that is
needlessly hard to write without them because ICC_PMR_EL1 is a C
pre-processor macro.

 	.macro	disable_irq, tmp
 	mov	\tmp, #ICC_PMR_EL1_MASKED
alternative_if_not ARM64_HAS_SYSREG_GIC_CPUIF
	msr	daifset, #2
alternative_else
 	msr_s	ICC_PMR_EL1, \tmp
alternative_endif
	.endm

The new macros have received a fair degree of testing because I have
based my (not published since March) pseudo-NMI patch set on them.

v2:

 * Split big patch out into atomized components (Will Deacon).
   To show where I would like to go I have retained a patch to remove
   assembler_insn() from the code base although, based on Will's email
   I don't anticipate this patch being taken for 4.3.

 * Add some comments to make clear the constraints imposed on alternative
   sequences.

Daniel Thompson (5):
  arm64: alternative: Provide if/else/endif assembler macros
  arm64: mm: Adopt new alternative assembler macros
  arm64: kernel: Adopt new alternative assembler macros
  arm64: kvm: Adopt new alternative assembler macros
  arm64: alternative: Remove alternative_insn macro

 arch/arm64/include/asm/alternative.h | 40 ++++++++++++++++++++++++++++++------
 arch/arm64/kernel/entry.S            | 29 ++++++++++++--------------
 arch/arm64/kvm/hyp.S                 | 12 +++++++++--
 arch/arm64/mm/cache.S                |  7 ++++++-
 4 files changed, 63 insertions(+), 25 deletions(-)

--
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ