* [PATCH 0/3] iio: adc: exynos-adc: Add support for S5PV210
From: Paweł Chmiel @ 2018-12-07 19:11 UTC (permalink / raw)
To: jic23
Cc: mark.rutland, linux-iio, xc-racer2, pmeerw, freeman.liu,
marcus.folkesson, lars, krzk, linux-samsung-soc, kgene, geert,
pawel.mikolaj.chmiel, devicetree, smohanad, vilhelm.gray, robh+dt,
linux-arm-kernel, baolin.wang, rdunlap, arnaud.pouliquen,
linux-kernel, broonie, knaack.h, eugen.hristev
This patchset adds support for S5PV210 adc variant to exynos-adc driver.
Jonathan Bakker (3):
iio: adc: exynos-adc: Add S5PV210 variant
iio: adc: Allow selection of Exynos ADC on S5PV210
dt-bindings: iio: adc: exynos-adc: Add S5PV210 variant
.../bindings/iio/adc/samsung,exynos-adc.txt | 4 +++-
drivers/iio/adc/Kconfig | 2 +-
drivers/iio/adc/exynos_adc.c | 14 ++++++++++++++
3 files changed, 18 insertions(+), 2 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] dt-bindings: iio: adc: exynos-adc: Add S5PV210 variant
From: Paweł Chmiel @ 2018-12-07 19:11 UTC (permalink / raw)
To: jic23
Cc: mark.rutland, linux-iio, xc-racer2, pmeerw, freeman.liu,
marcus.folkesson, lars, krzk, linux-samsung-soc, kgene, geert,
pawel.mikolaj.chmiel, devicetree, smohanad, vilhelm.gray, robh+dt,
linux-arm-kernel, baolin.wang, rdunlap, arnaud.pouliquen,
linux-kernel, broonie, knaack.h, eugen.hristev
In-Reply-To: <20181207191136.5464-1-pawel.mikolaj.chmiel@gmail.com>
From: Jonathan Bakker <xc-racer2@live.ca>
Add information about new compatible for S5PV210
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
.../devicetree/bindings/iio/adc/samsung,exynos-adc.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt
index 6c49db7f8ad2..a10c1f89037d 100644
--- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt
@@ -11,7 +11,7 @@ New driver handles the following
Required properties:
- compatible: Must be "samsung,exynos-adc-v1"
- for exynos4412/5250 and s5pv210 controllers.
+ for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
Must be "samsung,exynos3250-adc" for
@@ -28,6 +28,8 @@ Required properties:
the ADC in s3c2443 and compatibles
Must be "samsung,s3c6410-adc" for
the ADC in s3c6410 and compatibles
+ Must be "samsung,s5pv210-adc" for
+ the ADC in s5pv210 and compatibles
- reg: List of ADC register address range
- The base address and range of ADC register
- The base address and range of ADC_PHY register (every
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] gpio: gpio-omap: Revert deferred wakeup quirk handling for regressions
From: Tony Lindgren @ 2018-12-07 19:08 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot
Cc: Grygorii Strashko, Aaro Koskinen, Keerthy, Tero Kristo,
linux-gpio, Russell King, Ladislav Michl, linux-omap,
linux-arm-kernel
Commit ec0daae685b2 ("gpio: omap: Add level wakeup handling for omap4
based SoCs") attempted to fix omap4 GPIO wakeup handling as it was
blocking deeper SoC idle states. However this caused a regression for
GPIOs during runtime having over second long latencies for Ethernet
GPIO interrupt as reportedy by Russell King <rmk+kernel@armlinux.org.uk>.
Let's fix this issue by doing a partial revert of the breaking commit.
We still want to keep the quirk handling around as it is also used for
OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER.
The real fix for omap4 GPIO wakeup handling involves fixes for
omap_set_gpio_trigger() and omap_gpio_unmask_irq() and will be posted
separately. And we must keep the wakeup bit enabled during runtime
because of module doing clock autogating with autoidle configured.
Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
Fixes: ec0daae685b2 ("gpio: omap: Add level wakeup handling for omap4
based SoCs")
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/gpio/gpio-omap.c | 64 ++++------------------------------------
1 file changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -32,7 +32,6 @@
#define OMAP4_GPIO_DEBOUNCINGTIME_MASK 0xFF
#define OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER BIT(2)
-#define OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN BIT(1)
struct gpio_regs {
u32 irqenable1;
@@ -379,18 +378,9 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio,
readl_relaxed(bank->base + bank->regs->fallingdetect);
if (likely(!(bank->non_wakeup_gpios & gpio_bit))) {
- /* Defer wkup_en register update until we idle? */
- if (bank->quirks & OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN) {
- if (trigger)
- bank->context.wake_en |= gpio_bit;
- else
- bank->context.wake_en &= ~gpio_bit;
- } else {
- omap_gpio_rmw(base, bank->regs->wkup_en, gpio_bit,
- trigger != 0);
- bank->context.wake_en =
- readl_relaxed(bank->base + bank->regs->wkup_en);
- }
+ omap_gpio_rmw(base, bank->regs->wkup_en, gpio_bit, trigger != 0);
+ bank->context.wake_en =
+ readl_relaxed(bank->base + bank->regs->wkup_en);
}
/* This part needs to be executed always for OMAP{34xx, 44xx} */
@@ -942,44 +932,6 @@ omap2_gpio_disable_level_quirk(struct gpio_bank *bank)
bank->base + bank->regs->risingdetect);
}
-/*
- * On omap4 and later SoC variants a level interrupt with wkup_en
- * enabled blocks the GPIO functional clock from idling until the GPIO
- * instance has been reset. To avoid that, we must set wkup_en only for
- * idle for level interrupts, and clear level registers for the duration
- * of idle. The level interrupts will be still there on wakeup by their
- * nature.
- */
-static void __maybe_unused
-omap4_gpio_enable_level_quirk(struct gpio_bank *bank)
-{
- /* Update wake register for idle, edge bits might be already set */
- writel_relaxed(bank->context.wake_en,
- bank->base + bank->regs->wkup_en);
-
- /* Clear level registers for idle */
- writel_relaxed(0, bank->base + bank->regs->leveldetect0);
- writel_relaxed(0, bank->base + bank->regs->leveldetect1);
-}
-
-static void __maybe_unused
-omap4_gpio_disable_level_quirk(struct gpio_bank *bank)
-{
- /* Restore level registers after idle */
- writel_relaxed(bank->context.leveldetect0,
- bank->base + bank->regs->leveldetect0);
- writel_relaxed(bank->context.leveldetect1,
- bank->base + bank->regs->leveldetect1);
-
- /* Clear saved wkup_en for level, it will be set for next idle again */
- bank->context.wake_en &= ~(bank->context.leveldetect0 |
- bank->context.leveldetect1);
-
- /* Update wake with only edge configuration */
- writel_relaxed(bank->context.wake_en,
- bank->base + bank->regs->wkup_en);
-}
-
/*---------------------------------------------------------------------*/
static int omap_mpuio_suspend_noirq(struct device *dev)
@@ -1412,12 +1364,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
omap_set_gpio_dataout_mask_multiple;
}
- if (bank->quirks & OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN) {
- bank->funcs.idle_enable_level_quirk =
- omap4_gpio_enable_level_quirk;
- bank->funcs.idle_disable_level_quirk =
- omap4_gpio_disable_level_quirk;
- } else if (bank->quirks & OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER) {
+ if (bank->quirks & OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER) {
bank->funcs.idle_enable_level_quirk =
omap2_gpio_enable_level_quirk;
bank->funcs.idle_disable_level_quirk =
@@ -1806,8 +1753,7 @@ static const struct omap_gpio_platform_data omap4_pdata = {
.regs = &omap4_gpio_regs,
.bank_width = 32,
.dbck_flag = true,
- .quirks = OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER |
- OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN,
+ .quirks = OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER,
};
static const struct of_device_id omap_gpio_match[] = {
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: OMAP4430 SDP with KS8851: very slow networking
From: Tony Lindgren @ 2018-12-07 19:03 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: netdev, Grygorii Strashko, linux-omap, linux-arm-kernel
In-Reply-To: <20181207181420.GS6707@atomide.com>
* Tony Lindgren <tony@atomide.com> [181207 18:14]:
> Hi,
>
> * Russell King - ARM Linux <linux@armlinux.org.uk> [181207 18:01]:
> > Hi Tony,
> >
> > You know most of what's been going on from IRC, but here's the patch
> > which gets me:
> >
> > 1) working interrupts for networking
> > 2) solves the stuck-wakeup problem
> >
> > It also contains some of the debug bits I added.
>
> This is excellent news :) Will test today.
Yes your patch seems to work great based on brief testing :)
> > I think what this means is that we should strip out ec0daae685b2
> > ("gpio: omap: Add level wakeup handling for omap4 based SoCs").
>
> Yes the only reason for the wakeup quirk was the stuck wakeup
> state seen on omap4, it can be just dropped if this works.
> Adding Grygorii to Cc too.
I'll post a partial revert for commit ec0daae685b2 ("gpio: omap:
Add level wakeup handling for omap4 based SoCs") shortly.
Thanks,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 8/8] mfd: axp20x: Add supported cells for AXP803
From: Vasily Khoruzhick @ 2018-12-07 18:58 UTC (permalink / raw)
To: Lee Jones
Cc: Mark Rutland, devicetree, quentin.schulz, linux-pm, Maxime Ripard,
Sebastian Reichel, linux-kernel, Chen-Yu Tsai, Rob Herring,
Oskari Lemmela, arm-linux
In-Reply-To: <20181207164011.GI26661@dell>
On Fri, Dec 7, 2018 at 8:40 AM Lee Jones <lee.jones@linaro.org> wrote:
> My OCD-dar is going crazy.
>
> Why haven't you used the same alignment as is already there?
>
> If it starts to run over 80-chars then bring the others back.
>
> Also why is there a single liner shoved in the middle of the
> multi-line entries? Please move the singles to the top or the
> bottom.
Hi Lee,
Could you please reformat it in the way that makes your OCD-dar happy?
It would be really nice to get
AC and battery support for APX8x3 merged -- it'll make Pinebook and
Teres-I pretty well supported by mainline kernel.
Thanks,
Vasily
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Patch v2] arm: dts: qcom: msm8998: Fixup clock to use xo_board
From: Andy Gross @ 2018-12-07 18:58 UTC (permalink / raw)
To: linux-arm-msm; +Cc: Stephen Boyd, Andy Gross, linux-arm-kernel, Bjorn Andersson
This patch sets the msm8998 xo clock name back to xo_board. Recent
clock tree changes fixed the clock tree and the change to the xo name
is causing issues where msm8998 boards do not boot properly. Let's
change it back and leave the xo label on it.
Fixes: 634da3307b08 (arm64: dts: qcom: msm8998: correct xo clock name)
Signed-off-by: Andy Gross <andy.gross@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 49f0fee..8d41b69 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -54,10 +54,11 @@
};
clocks {
- xo: xo {
+ xo: xo-board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <19200000>;
+ clock-output-names = "xo_board";
};
sleep_clk {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm: dts: meson: Fix IRQ trigger type for macirq
From: Emiliano Ingrassia @ 2018-12-07 18:51 UTC (permalink / raw)
To: Carlo Caione
Cc: mark.rutland, devicetree, martin.blumenstingl, khilman, robh+dt,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20181207105231.25593-3-ccaione@baylibre.com>
Hi Carlo,
tests[0] conducted on an Odroid-C1+ board equipped with a Meson8b SoC
have shown an high packet loss (90% and more) during a simple ping
test from a laptop to the board.
Testing the two patches separately clearly showed that this depends on the
removal of the "eee-broken-1000t" flag from the board PHY description
in the relative device tree.
About the first patch (MAC IRQ type), no tests have shown an evidence
that it is needed. I suggest you to conduct some test on real hardware
as I do to confirm or disprove my tests.
Thanks for your work,
Emiliano
[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009397.html
On Fri, Dec 07, 2018 at 10:52:31AM +0000, Carlo Caione wrote:
> A long running stress test on a custom board shipping an AXG SoCs and a
> Realtek RTL8211F PHY revealed that after a few hours the connection
> speed would drop drastically, from ~1000Mbps to ~3Mbps. At the same time
> the 'macirq' (eth0) IRQ would stop being triggered at all and as
> consequence the GMAC IRQs never ACKed.
>
> After a painful investigation the problem seemed to be due to a wrong
> defined IRQ type for the GMAC IRQ that should be LEVEL_HIGH instead of
> EDGE_RISING.
>
> The change in the macirq IRQ type also solved another long standing
> issue affecting this SoC/PHY where EEE was causing the network
> connection to die after stressing it with iperf3 (even though much
> sooner). It's now possible to remove the 'eee-broken-1000t' quirk as
> well.
>
> Fixes: 9c15795a4f96 ("ARM: dts: meson8b-odroidc1: ethernet support")
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> ---
> arch/arm/boot/dts/meson.dtsi | 2 +-
> arch/arm/boot/dts/meson8b-odroidc1.dts | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
> index 0d9faf1a51ea..a86b89086334 100644
> --- a/arch/arm/boot/dts/meson.dtsi
> +++ b/arch/arm/boot/dts/meson.dtsi
> @@ -263,7 +263,7 @@
> compatible = "amlogic,meson6-dwmac", "snps,dwmac";
> reg = <0xc9410000 0x10000
> 0xc1108108 0x4>;
> - interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "macirq";
> status = "disabled";
> };
> diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts b/arch/arm/boot/dts/meson8b-odroidc1.dts
> index 58669abda259..a951a6632d0c 100644
> --- a/arch/arm/boot/dts/meson8b-odroidc1.dts
> +++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
> @@ -221,7 +221,6 @@
> /* Realtek RTL8211F (0x001cc916) */
> eth_phy: ethernet-phy@0 {
> reg = <0>;
> - eee-broken-1000t;
> interrupt-parent = <&gpio_intc>;
> /* GPIOH_3 */
> interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
> --
> 2.19.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC] ARM: dts: Introduce wilddt function instead of listing imx boards
From: Leonard Crestez @ 2018-12-07 18:35 UTC (permalink / raw)
To: Masahiro Yamada, Rob Herring, Arnd Bergmann, Olof Johansson,
Shawn Guo
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Marek,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, Fabio Estevam,
moderated for non-subscribers
The dts makefiles go through a lot of pointless churn when boards are
added. Many SOCs (such as imx) have very simple naming conventions for
all boards using a certain SOC and board listings can be easily
collapsed using wildcards.
Add a "wilddt" function and use it for imx6/7
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/boot/dts/Makefile | 203 ++++---------------------------------
1 file changed, 19 insertions(+), 184 deletions(-)
If useful in v2 the wilddt function can be split into a separate patch
for "scripts/Makefile.lib"
A few other arches also have DT wildcards but not on a per-soc basis, in
theory they could $(call wilddt,*)
I'm not sure if $dtstree is used correctly here?
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b0e966d625b9..42e6ba453adf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1,6 +1,15 @@
# SPDX-License-Identifier: GPL-2.0
+
+dtstree := $(srctree)/$(src)
+
+# return list of .dtb for all .dts matching $1 in current directory
+# Example usage: dtb-$CONFIG_SOC_ABC123 += $(call wilddt,abc123-*)
+define wilddt
+ $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard $(dtstree)/$(1).dts))
+endef
+
dtb-$(CONFIG_ARCH_ALPINE) += \
alpine-db.dtb
dtb-$(CONFIG_MACH_ARTPEC6) += \
artpec6-devboard.dtb
dtb-$(CONFIG_MACH_ASM9260) += \
@@ -384,199 +393,25 @@ dtb-$(CONFIG_SOC_IMX53) += \
imx53-tx53-x03x.dtb \
imx53-tx53-x13x.dtb \
imx53-usbarmory.dtb \
imx53-voipac-bsb.dtb
dtb-$(CONFIG_SOC_IMX6Q) += \
- imx6dl-apf6dev.dtb \
- imx6dl-aristainetos_4.dtb \
- imx6dl-aristainetos_7.dtb \
- imx6dl-aristainetos2_4.dtb \
- imx6dl-aristainetos2_7.dtb \
- imx6dl-colibri-eval-v3.dtb \
- imx6dl-cubox-i.dtb \
- imx6dl-cubox-i-emmc-som-v15.dtb \
- imx6dl-cubox-i-som-v15.dtb \
- imx6dl-dfi-fs700-m60.dtb \
- imx6dl-gw51xx.dtb \
- imx6dl-gw52xx.dtb \
- imx6dl-gw53xx.dtb \
- imx6dl-gw54xx.dtb \
- imx6dl-gw551x.dtb \
- imx6dl-gw552x.dtb \
- imx6dl-gw553x.dtb \
- imx6dl-gw560x.dtb \
- imx6dl-gw5903.dtb \
- imx6dl-gw5904.dtb \
- imx6dl-hummingboard.dtb \
- imx6dl-hummingboard-emmc-som-v15.dtb \
- imx6dl-hummingboard-som-v15.dtb \
- imx6dl-hummingboard2.dtb \
- imx6dl-hummingboard2-emmc-som-v15.dtb \
- imx6dl-hummingboard2-som-v15.dtb \
- imx6dl-icore.dtb \
- imx6dl-icore-mipi.dtb \
- imx6dl-icore-rqs.dtb \
- imx6dl-mamoj.dtb \
- imx6dl-nit6xlite.dtb \
- imx6dl-nitrogen6x.dtb \
- imx6dl-phytec-mira-rdk-nand.dtb \
- imx6dl-phytec-pbab01.dtb \
- imx6dl-rex-basic.dtb \
- imx6dl-riotboard.dtb \
- imx6dl-sabreauto.dtb \
- imx6dl-sabrelite.dtb \
- imx6dl-sabresd.dtb \
- imx6dl-savageboard.dtb \
- imx6dl-ts4900.dtb \
- imx6dl-ts7970.dtb \
- imx6dl-tx6dl-comtft.dtb \
- imx6dl-tx6s-8034.dtb \
- imx6dl-tx6s-8034-mb7.dtb \
- imx6dl-tx6s-8035.dtb \
- imx6dl-tx6s-8035-mb7.dtb \
- imx6dl-tx6u-801x.dtb \
- imx6dl-tx6u-80xx-mb7.dtb \
- imx6dl-tx6u-8033.dtb \
- imx6dl-tx6u-8033-mb7.dtb \
- imx6dl-tx6u-811x.dtb \
- imx6dl-tx6u-81xx-mb7.dtb \
- imx6dl-udoo.dtb \
- imx6dl-wandboard.dtb \
- imx6dl-wandboard-revb1.dtb \
- imx6dl-wandboard-revd1.dtb \
- imx6q-apalis-eval.dtb \
- imx6q-apalis-ixora.dtb \
- imx6q-apalis-ixora-v1.1.dtb \
- imx6q-apf6dev.dtb \
- imx6q-arm2.dtb \
- imx6q-b450v3.dtb \
- imx6q-b650v3.dtb \
- imx6q-b850v3.dtb \
- imx6q-cm-fx6.dtb \
- imx6q-cubox-i.dtb \
- imx6q-cubox-i-emmc-som-v15.dtb \
- imx6q-cubox-i-som-v15.dtb \
- imx6q-dfi-fs700-m60.dtb \
- imx6q-dhcom-pdk2.dtb \
- imx6q-display5-tianma-tm070-1280x768.dtb \
- imx6q-dmo-edmqmx6.dtb \
- imx6q-dms-ba16.dtb \
- imx6q-evi.dtb \
- imx6q-gk802.dtb \
- imx6q-gw51xx.dtb \
- imx6q-gw52xx.dtb \
- imx6q-gw53xx.dtb \
- imx6q-gw5400-a.dtb \
- imx6q-gw54xx.dtb \
- imx6q-gw551x.dtb \
- imx6q-gw552x.dtb \
- imx6q-gw553x.dtb \
- imx6q-gw560x.dtb \
- imx6q-gw5903.dtb \
- imx6q-gw5904.dtb \
- imx6q-h100.dtb \
- imx6q-hummingboard.dtb \
- imx6q-hummingboard-emmc-som-v15.dtb \
- imx6q-hummingboard-som-v15.dtb \
- imx6q-hummingboard2.dtb \
- imx6q-hummingboard2-emmc-som-v15.dtb \
- imx6q-hummingboard2-som-v15.dtb \
- imx6q-icore.dtb \
- imx6q-icore-mipi.dtb \
- imx6q-icore-ofcap10.dtb \
- imx6q-icore-ofcap12.dtb \
- imx6q-icore-rqs.dtb \
- imx6q-kp-tpc.dtb \
- imx6q-marsboard.dtb \
- imx6q-mccmon6.dtb \
- imx6q-nitrogen6x.dtb \
- imx6q-nitrogen6_max.dtb \
- imx6q-nitrogen6_som2.dtb \
- imx6q-novena.dtb \
- imx6q-phytec-mira-rdk-emmc.dtb \
- imx6q-phytec-mira-rdk-nand.dtb \
- imx6q-phytec-pbab01.dtb \
- imx6q-pistachio.dtb \
- imx6q-rex-pro.dtb \
- imx6q-sabreauto.dtb \
- imx6q-sabrelite.dtb \
- imx6q-sabresd.dtb \
- imx6q-savageboard.dtb \
- imx6q-sbc6x.dtb \
- imx6q-tbs2910.dtb \
- imx6q-ts4900.dtb \
- imx6q-ts7970.dtb \
- imx6q-tx6q-1010.dtb \
- imx6q-tx6q-1010-comtft.dtb \
- imx6q-tx6q-1020.dtb \
- imx6q-tx6q-1020-comtft.dtb \
- imx6q-tx6q-1036.dtb \
- imx6q-tx6q-1036-mb7.dtb \
- imx6q-tx6q-10x0-mb7.dtb \
- imx6q-tx6q-1110.dtb \
- imx6q-tx6q-11x0-mb7.dtb \
- imx6q-udoo.dtb \
- imx6q-utilite-pro.dtb \
- imx6q-var-dt6customboard.dtb \
- imx6q-wandboard.dtb \
- imx6q-wandboard-revb1.dtb \
- imx6q-wandboard-revd1.dtb \
- imx6q-zii-rdu2.dtb \
- imx6qp-nitrogen6_max.dtb \
- imx6qp-nitrogen6_som2.dtb \
- imx6qp-phytec-mira-rdk-nand.dtb \
- imx6qp-sabreauto.dtb \
- imx6qp-sabresd.dtb \
- imx6qp-tx6qp-8037.dtb \
- imx6qp-tx6qp-8037-mb7.dtb \
- imx6qp-tx6qp-8137.dtb \
- imx6qp-tx6qp-8137-mb7.dtb \
- imx6qp-wandboard-revd1.dtb \
- imx6qp-zii-rdu2.dtb
+ $(call wilddt,imx6dl-*) \
+ $(call wilddt,imx6q-*) \
+ $(call wilddt,imx6qp-*)
dtb-$(CONFIG_SOC_IMX6SL) += \
- imx6sl-evk.dtb \
- imx6sl-warp.dtb
+ $(call wilddt,imx6sl-*)
dtb-$(CONFIG_SOC_IMX6SLL) += \
- imx6sll-evk.dtb
+ $(call wilddt,imx6sll-*)
dtb-$(CONFIG_SOC_IMX6SX) += \
- imx6sx-nitrogen6sx.dtb \
- imx6sx-sabreauto.dtb \
- imx6sx-sdb-reva.dtb \
- imx6sx-sdb-sai.dtb \
- imx6sx-sdb.dtb \
- imx6sx-softing-vining-2000.dtb \
- imx6sx-udoo-neo-basic.dtb \
- imx6sx-udoo-neo-extended.dtb \
- imx6sx-udoo-neo-full.dtb
+ $(call wilddt,imx6sx-*)
dtb-$(CONFIG_SOC_IMX6UL) += \
- imx6ul-14x14-evk.dtb \
- imx6ul-ccimx6ulsbcexpress.dtb \
- imx6ul-ccimx6ulsbcpro.dtb \
- imx6ul-geam.dtb \
- imx6ul-isiot-emmc.dtb \
- imx6ul-isiot-nand.dtb \
- imx6ul-liteboard.dtb \
- imx6ul-opos6uldev.dtb \
- imx6ul-pico-hobbit.dtb \
- imx6ul-tx6ul-0010.dtb \
- imx6ul-tx6ul-0011.dtb \
- imx6ul-tx6ul-mainboard.dtb \
- imx6ull-14x14-evk.dtb \
- imx6ull-colibri-eval-v3.dtb \
- imx6ull-colibri-wifi-eval-v3.dtb \
- imx6ulz-14x14-evk.dtb
+ $(call wilddt,imx6ul-*) \
+ $(call wilddt,imx6ull-*) \
+ $(call wilddt,imx6ulz-*)
dtb-$(CONFIG_SOC_IMX7D) += \
- imx7d-cl-som-imx7.dtb \
- imx7d-colibri-emmc-eval-v3.dtb \
- imx7d-colibri-eval-v3.dtb \
- imx7d-nitrogen7.dtb \
- imx7d-pico-pi.dtb \
- imx7d-sbc-imx7.dtb \
- imx7d-sdb.dtb \
- imx7d-sdb-sht11.dtb \
- imx7s-colibri-eval-v3.dtb \
- imx7s-warp.dtb
+ $(call wilddt,imx7[ds]-*)
dtb-$(CONFIG_SOC_LS1021A) += \
ls1021a-moxa-uc-8410a.dtb \
ls1021a-qds.dtb \
ls1021a-twr.dtb
dtb-$(CONFIG_SOC_VF610) += \
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [REPOST PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()
From: Doug Anderson @ 2018-12-07 18:40 UTC (permalink / raw)
To: Catalin Marinas
Cc: mhocko, Benjamin Herrenschmidt, linux-sh, Peter Zijlstra,
kgdb-bugreport, Will Deacon, LKML, dalias, paulus, mpe,
H. Peter Anvin, sparclinux, Daniel Thompson, Yoshinori Sato,
linux-hexagon, x86, Russell King - ARM Linux, Ingo Molnar,
ying.huang, jhogan, linux-snps-arc, rppt, bp, Thomas Gleixner,
Linux ARM, christophe.leroy, Vineet Gupta, linux-mips,
Ralf Baechle, rkuo, paul.burton, Jason Wessel, Andrew Morton,
linuxppc-dev, David Miller
In-Reply-To: <20181207174231.GD11961@arrakis.emea.arm.com>
Hi,
On Fri, Dec 7, 2018 at 9:42 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote:
> > Douglas Anderson (4):
> > kgdb: Remove irq flags from roundup
> > kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
> > kgdb: Don't round up a CPU that failed rounding up before
> > kdb: Don't back trace on a cpu that didn't round up
>
> FWIW, trying these on arm64 (ThunderX2) with CONFIG_KGDB_TESTS_ON_BOOT=y
> on top of 4.20-rc5 doesn't boot. It looks like they leave interrupts
> disabled when they shouldn't and it trips over the BUG at
> mm/vmalloc.c:1380 (called via do_fork -> copy_process).
>
> Now, I don't think these patches make things worse on arm64 since prior
> to them the kgdb boot tests on arm64 were stuck in a loop (RUN
> singlestep).
Thanks for the report! ...actually, I'd never tried CONFIG_KGDB_TESTS
before. ...so I tried them now:
A) chromeos-4.19 tree on qcom-sdm845 without this series: booted up OK
B) chromeos-4.19 tree on qcom-sdm845 with this series: booted up OK
C) v4.20-rc5-90-g30002dd008ed on rockchip-rk3399 (kevin) with this
series: booted up OK
Example output from B) above:
localhost ~ # dmesg | grep kgdbts
[ 2.139814] KGDB: Registered I/O driver kgdbts
[ 2.144582] kgdbts:RUN plant and detach test
[ 2.165333] kgdbts:RUN sw breakpoint test
[ 2.172990] kgdbts:RUN bad memory access test
[ 2.178640] kgdbts:RUN singlestep test 1000 iterations
[ 2.187765] kgdbts:RUN singlestep [0/1000]
[ 2.559596] kgdbts:RUN singlestep [100/1000]
[ 2.931419] kgdbts:RUN singlestep [200/1000]
[ 3.303474] kgdbts:RUN singlestep [300/1000]
[ 3.675121] kgdbts:RUN singlestep [400/1000]
[ 4.046867] kgdbts:RUN singlestep [500/1000]
[ 4.418920] kgdbts:RUN singlestep [600/1000]
[ 4.790824] kgdbts:RUN singlestep [700/1000]
[ 5.162479] kgdbts:RUN singlestep [800/1000]
[ 5.534103] kgdbts:RUN singlestep [900/1000]
[ 5.902299] kgdbts:RUN do_fork for 100 breakpoints
[ 8.463900] KGDB: Unregistered I/O driver kgdbts, debugger disabled
...so I guess I'm a little confused. Either I have a different config
than you do or something is special about your machine?
NOTE: In general I've never considered "single step" as reliable in
kgdb. I mostly use kgdb as "after the fact" crash debugging to
analyze local variables / memory / other tasks. If it worked that'd
actually be kinda great, but at least when I started using kgdb years
ago I learned that it didn't work and stopped trying...
-Doug
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 4/7] riscv/vdso: don't clear PG_reserved
From: Palmer Dabbelt @ 2018-12-07 18:45 UTC (permalink / raw)
To: david
Cc: linux-s390, aou, akpm, david, linux-kernel, willy, mhocko,
linux-mm, linux-m68k, linux-mediatek, linux-riscv, linuxppc-dev,
tklauser, linux-arm-kernel
In-Reply-To: <20181205122851.5891-5-david@redhat.com>
On Wed, 05 Dec 2018 04:28:48 PST (-0800), david@redhat.com wrote:
> The VDSO is part of the kernel image and therefore the struct pages are
> marked as reserved during boot.
>
> As we install a special mapping, the actual struct pages will never be
> exposed to MM via the page tables. We can therefore leave the pages
> marked as reserved.
>
> Cc: Palmer Dabbelt <palmer@sifive.com>
> Cc: Albert Ou <aou@eecs.berkeley.edu>
> Cc: Tobias Klauser <tklauser@distanz.ch>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> arch/riscv/kernel/vdso.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c
> index 582cb153eb24..0cd044122234 100644
> --- a/arch/riscv/kernel/vdso.c
> +++ b/arch/riscv/kernel/vdso.c
> @@ -54,7 +54,6 @@ static int __init vdso_init(void)
> struct page *pg;
>
> pg = virt_to_page(vdso_start + (i << PAGE_SHIFT));
> - ClearPageReserved(pg);
> vdso_pagelist[i] = pg;
> }
> vdso_pagelist[i] = virt_to_page(vdso_data);
I'm going to assume this will go in through another tree along with the rest of
the set assuming everyone else is happy with it.
Acked-by: Palmer Dabbelt <palmer@sifive.com>
Thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: pinctrl: Add devicetree bindings for MT6797 SoC Pinctrl
From: Olof Johansson @ 2018-12-07 18:41 UTC (permalink / raw)
To: LinusW
Cc: Sean Wang, Linux Kernel Mailing List, Rob Herring, linux-gpio,
ARM-SoC Maintainers, moderated list:ARM/Mediatek SoC...,
Amit Kucheria, Manivannan Sadhasivam, Matthias Brugger,
Linux ARM Mailing List
In-Reply-To: <CACRpkdYCsh3AfmV-7ym-ffjp2k-kaNRqY1O3rd9h-WoUPYM_bw@mail.gmail.com>
On Wed, Dec 5, 2018 at 4:01 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Dec 3, 2018 at 2:08 AM Matthias Brugger <matthias.bgg@gmail.com> wrote:
> > On 15/11/2018 11:04, Linus Walleij wrote:
> > > On Wed, Nov 7, 2018 at 6:49 PM Manivannan Sadhasivam
> > > <manivannan.sadhasivam@linaro.org> wrote:
> > >
> > >> Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
> > >>
> > >> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > >
> > > Patch applied.
> > >
> >
> > Could you provide a stable tree for me, so that I can take the dts parts?
> > I just realized that my build is broken because of the missing dt-bindings
> > header file.
>
> Since I pulled other changes on top it is too late for me to put that
> in an immutable branch and merge into my tree separately,
> you would have to pull in the whole "devel" branch from the
> pin control tree.
>
> What we sometimes do is simply apply the *EXACT* same patch
> to two git trees. Git will cope with that as long as they are
> absolutely *IDENTICAL*. (The patch will appear twice in the
> git log with different hashes but they will merge without
> problems, a bit unelegant but it works.)
>
> So in your situation I would extract this patch from the pinctrl
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=devel&id=95d2f00657ad4c2c3eacd8a871a7aa022c3fe7d9
> and apply it with some notice to the maintainers about
> the situation.
>
> ARM SoC folks: agreed?
So, applying the patches in parallel is fine, but this made me look at
the actual patches and file contents, and they seem to be a bit messy.
This feedback is more to the MT maintainers/developers than you, Linus
(obviously):
These header files are huge, and they're inconsistent in the way they
define these constants:
include/dt-bindings/pinctrl/mt7623-pinfunc.h:
#define MT7623_PIN_21_PCM_TX_FUNC_GPIO21 (MTK_PIN_NO(21) | 0)
#define MT7623_PIN_21_PCM_TX_FUNC_PCM_TX (MTK_PIN_NO(21) | 1)
#define MT7623_PIN_21_PCM_TX_FUNC_MRG_TX (MTK_PIN_NO(21) | 2)
#define MT7623_PIN_21_PCM_TX_FUNC_MRG_RX (MTK_PIN_NO(21) | 3)
#define MT7623_PIN_21_PCM_TX_FUNC_PCM_RX (MTK_PIN_NO(21) | 4)
#define MT7623_PIN_21_PCM_TX_FUNC_CONN_DSP_JMS (MTK_PIN_NO(21) | 5)
#define MT7623_PIN_21_PCM_TX_FUNC_AP_PCM_TX (MTK_PIN_NO(21) | 6)
include/dt-bindings/pinctrl/mt6397-pinfunc.h:
#define MT6397_PIN_24_ROW4__FUNC_GPIO24 (MTK_PIN_NO(24) | 0)
#define MT6397_PIN_24_ROW4__FUNC_ROW4 (MTK_PIN_NO(24) | 1)
#define MT6397_PIN_24_ROW4__FUNC_EINT22_1X (MTK_PIN_NO(24) | 2)
#define MT6397_PIN_24_ROW4__FUNC_SCL2_3X (MTK_PIN_NO(24) | 3)
#define MT6397_PIN_24_ROW4__FUNC_TEST_IN15 (MTK_PIN_NO(24) | 6)
#define MT6397_PIN_24_ROW4__FUNC_TEST_OUT15 (MTK_PIN_NO(24) | 7)
include/dt-bindings/pinctrl/mt6797-pinfunc.h:
#define MT6797_GPIO34__FUNC_GPIO34 (MTK_PIN_NO(34) | 0)
#define MT6797_GPIO34__FUNC_CMFLASH (MTK_PIN_NO(34) | 1)
#define MT6797_GPIO34__FUNC_CLKM0 (MTK_PIN_NO(34) | 2)
#define MT6797_GPIO34__FUNC_UDI_NTRST (MTK_PIN_NO(34) | 3)
#define MT6797_GPIO34__FUNC_SCP_JTAG_TRSTN (MTK_PIN_NO(34) | 4)
#define MT6797_GPIO34__FUNC_CONN_MCU_TRST_B (MTK_PIN_NO(34) | 5)
#define MT6797_GPIO34__FUNC_MD_UTXD0 (MTK_PIN_NO(34) | 6)
#define MT6797_GPIO34__FUNC_C2K_DM_JTINTP (MTK_PIN_NO(34) | 7)
So, is it a pin or a GPIO and why does 6797 use different naming
scheme? Why do some of them have __FUNC and some _FUNC? Why do some
have the non-gpio function as part of the name and some do not?
Also, "pin 24 row 4 func row4"? Seems to have very limited value to
describe it in that manner, it's just overly verbose without adding
information.
Some other SoCs tend to use a pinctrl specifier that is two-cell <pin
function> instead of trying to pack them into one integer. That seems
a lot more practical, especially since the base GPIO function seems to
generically be '0'. So the pin number would go in the first cell, and
the function in the second.
Finally, I don't see how the header file is used in the code at all?
The main idea behind the dt bindings header files is that they would
provide shared constants between the DT and the driver in the kernel.
If the constants are never used (i.e. they're just register values,
like today), then there's no need to merge the dt header with the
driver at all, it should go with the DT contents instead. So, for
example, if you used something like a format of <pin function>
properties, the header file could contain both the string
representation of the function for debug, as well as the values, all
derived from one place. Today all you have string representations for
is "func0".."func15" through mtk_gpio_functions[]. Seems like an
improvement all around?
-Olof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 13/13] arm64: docs: document pointer authentication
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
Now that we've added code to support pointer authentication, add some
documentation so that people can figure out if/how to use it.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Reviewed-by: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: Andrew Jones <drjones@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
Documentation/arm64/booting.txt | 8 +++
Documentation/arm64/cpu-feature-registers.txt | 8 +++
Documentation/arm64/elf_hwcaps.txt | 12 ++++
Documentation/arm64/pointer-authentication.txt | 93 ++++++++++++++++++++++++++
4 files changed, 121 insertions(+)
create mode 100644 Documentation/arm64/pointer-authentication.txt
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 8d0df62c3fe0..8df9f4658d6f 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -205,6 +205,14 @@ Before jumping into the kernel, the following conditions must be met:
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
- The DT or ACPI tables must describe a GICv2 interrupt controller.
+ For CPUs with pointer authentication functionality:
+ - If EL3 is present:
+ SCR_EL3.APK (bit 16) must be initialised to 0b1
+ SCR_EL3.API (bit 17) must be initialised to 0b1
+ - If the kernel is entered at EL1:
+ HCR_EL2.APK (bit 40) must be initialised to 0b1
+ HCR_EL2.API (bit 41) must be initialised to 0b1
+
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level.
diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt
index 7964f03846b1..d4b4dd1fe786 100644
--- a/Documentation/arm64/cpu-feature-registers.txt
+++ b/Documentation/arm64/cpu-feature-registers.txt
@@ -184,12 +184,20 @@ infrastructure:
x--------------------------------------------------x
| Name | bits | visible |
|--------------------------------------------------|
+ | GPI | [31-28] | y |
+ |--------------------------------------------------|
+ | GPA | [27-24] | y |
+ |--------------------------------------------------|
| LRCPC | [23-20] | y |
|--------------------------------------------------|
| FCMA | [19-16] | y |
|--------------------------------------------------|
| JSCVT | [15-12] | y |
|--------------------------------------------------|
+ | API | [11-8] | y |
+ |--------------------------------------------------|
+ | APA | [7-4] | y |
+ |--------------------------------------------------|
| DPB | [3-0] | y |
x--------------------------------------------------x
diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt
index ea819ae024dd..13d6691b37be 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -182,3 +182,15 @@ HWCAP_FLAGM
HWCAP_SSBS
Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
+
+HWCAP_PACA
+
+ Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
+ ID_AA64ISAR1_EL1.API == 0b0001, as described by
+ Documentation/arm64/pointer-authentication.txt.
+
+HWCAP_PACG
+
+ Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
+ ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
+ Documentation/arm64/pointer-authentication.txt.
diff --git a/Documentation/arm64/pointer-authentication.txt b/Documentation/arm64/pointer-authentication.txt
new file mode 100644
index 000000000000..5baca42ba146
--- /dev/null
+++ b/Documentation/arm64/pointer-authentication.txt
@@ -0,0 +1,93 @@
+Pointer authentication in AArch64 Linux
+=======================================
+
+Author: Mark Rutland <mark.rutland@arm.com>
+Date: 2017-07-19
+
+This document briefly describes the provision of pointer authentication
+functionality in AArch64 Linux.
+
+
+Architecture overview
+---------------------
+
+The ARMv8.3 Pointer Authentication extension adds primitives that can be
+used to mitigate certain classes of attack where an attacker can corrupt
+the contents of some memory (e.g. the stack).
+
+The extension uses a Pointer Authentication Code (PAC) to determine
+whether pointers have been modified unexpectedly. A PAC is derived from
+a pointer, another value (such as the stack pointer), and a secret key
+held in system registers.
+
+The extension adds instructions to insert a valid PAC into a pointer,
+and to verify/remove the PAC from a pointer. The PAC occupies a number
+of high-order bits of the pointer, which varies dependent on the
+configured virtual address size and whether pointer tagging is in use.
+
+A subset of these instructions have been allocated from the HINT
+encoding space. In the absence of the extension (or when disabled),
+these instructions behave as NOPs. Applications and libraries using
+these instructions operate correctly regardless of the presence of the
+extension.
+
+The extension provides five separate keys to generate PACs - two for
+instruction addresses (APIAKey, APIBKey), two for data addresses
+(APDAKey, APDBKey), and one for generic authentication (APGAKey).
+
+
+Basic support
+-------------
+
+When CONFIG_ARM64_PTR_AUTH is selected, and relevant HW support is
+present, the kernel will assign random key values to each process at
+exec*() time. The keys are shared by all threads within the process, and
+are preserved across fork().
+
+Presence of address authentication functionality is advertised via
+HWCAP_PACA, and generic authentication functionality via HWCAP_PACG.
+
+The number of bits that the PAC occupies in a pointer is 55 minus the
+virtual address size configured by the kernel. For example, with a
+virtual address size of 48, the PAC is 7 bits wide.
+
+Recent versions of GCC can compile code with APIAKey-based return
+address protection when passed the -msign-return-address option. This
+uses instructions in the HINT space (unless -march=armv8.3-a or higher
+is also passed), and such code can run on systems without the pointer
+authentication extension.
+
+In addition to exec(), keys can also be reinitialized to random values
+using the PR_PAC_RESET_KEYS prctl. A bitmask of PR_PAC_APIAKEY,
+PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY and PR_PAC_APGAKEY
+specifies which keys are to be reinitialized; specifying 0 means "all
+keys".
+
+
+Debugging
+---------
+
+When CONFIG_ARM64_PTR_AUTH is selected, and HW support for address
+authentication is present, the kernel will expose the position of TTBR0
+PAC bits in the NT_ARM_PAC_MASK regset (struct user_pac_mask), which
+userspace can acquire via PTRACE_GETREGSET.
+
+The regset is exposed only when HWCAP_PACA is set. Separate masks are
+exposed for data pointers and instruction pointers, as the set of PAC
+bits can vary between the two. Note that the masks apply to TTBR0
+addresses, and are not valid to apply to TTBR1 addresses (e.g. kernel
+pointers).
+
+Additionally, when CONFIG_CHECKPOINT_RESTORE is also set, the kernel
+will expose the NT_ARM_PACA_KEYS and NT_ARM_PACG_KEYS regsets (struct
+user_pac_address_keys and struct user_pac_generic_keys). These can be
+used to get and set the keys for a thread.
+
+
+Virtualization
+--------------
+
+Pointer authentication is not currently supported in KVM guests. KVM
+will mask the feature bits from ID_AA64ISAR1_EL1, and attempted use of
+the feature will result in an UNDEFINED exception being injected into
+the guest.
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 10/13] arm64: add prctl control for resetting ptrauth keys
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
Add an arm64-specific prctl to allow a thread to reinitialize its
pointer authentication keys to random values. This can be useful when
exec() is not used for starting new processes, to ensure that different
processes still have different keys.
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
arch/arm64/include/asm/pointer_auth.h | 3 +++
arch/arm64/include/asm/processor.h | 4 +++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/pointer_auth.c | 47 +++++++++++++++++++++++++++++++++++
include/uapi/linux/prctl.h | 8 ++++++
kernel/sys.c | 8 ++++++
6 files changed, 71 insertions(+)
create mode 100644 arch/arm64/kernel/pointer_auth.c
diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
index 89190d93c850..7797bc346c6b 100644
--- a/arch/arm64/include/asm/pointer_auth.h
+++ b/arch/arm64/include/asm/pointer_auth.h
@@ -59,6 +59,8 @@ static inline void ptrauth_keys_switch(struct ptrauth_keys *keys)
__ptrauth_key_install(APGA, keys->apga);
}
+extern int ptrauth_prctl_reset_keys(struct task_struct *tsk, unsigned long arg);
+
/*
* The EL0 pointer bits used by a pointer authentication code.
* This is dependent on TBI0 being enabled, or bits 63:56 would also apply.
@@ -82,6 +84,7 @@ do { \
ptrauth_keys_switch(&(tsk)->thread_info.keys_user)
#else /* CONFIG_ARM64_PTR_AUTH */
+#define ptrauth_prctl_reset_keys(tsk, arg) (-EINVAL)
#define ptrauth_strip_insn_pac(lr) (lr)
#define ptrauth_thread_init_user(tsk)
#define ptrauth_thread_switch(tsk)
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 6b0d4dff5012..40ccfb7605b6 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -46,6 +46,7 @@
#include <asm/hw_breakpoint.h>
#include <asm/lse.h>
#include <asm/pgtable-hwdef.h>
+#include <asm/pointer_auth.h>
#include <asm/ptrace.h>
#include <asm/types.h>
@@ -270,6 +271,9 @@ extern void __init minsigstksz_setup(void);
#define SVE_SET_VL(arg) sve_set_current_vl(arg)
#define SVE_GET_VL() sve_get_current_vl()
+/* PR_PAC_RESET_KEYS prctl */
+#define PAC_RESET_KEYS(tsk, arg) ptrauth_prctl_reset_keys(tsk, arg)
+
/*
* For CONFIG_GCC_PLUGIN_STACKLEAK
*
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 4c8b13bede80..096740ab81d2 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -57,6 +57,7 @@ arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
arm64-obj-$(CONFIG_CRASH_CORE) += crash_core.o
arm64-obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
arm64-obj-$(CONFIG_ARM64_SSBD) += ssbd.o
+arm64-obj-$(CONFIG_ARM64_PTR_AUTH) += pointer_auth.o
obj-y += $(arm64-obj-y) vdso/ probes/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/pointer_auth.c b/arch/arm64/kernel/pointer_auth.c
new file mode 100644
index 000000000000..b9f6f5f3409a
--- /dev/null
+++ b/arch/arm64/kernel/pointer_auth.c
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/errno.h>
+#include <linux/prctl.h>
+#include <linux/random.h>
+#include <linux/sched.h>
+#include <asm/cpufeature.h>
+#include <asm/pointer_auth.h>
+
+int ptrauth_prctl_reset_keys(struct task_struct *tsk, unsigned long arg)
+{
+ struct ptrauth_keys *keys = &tsk->thread_info.keys_user;
+ unsigned long addr_key_mask = PR_PAC_APIAKEY | PR_PAC_APIBKEY |
+ PR_PAC_APDAKEY | PR_PAC_APDBKEY;
+ unsigned long key_mask = addr_key_mask | PR_PAC_APGAKEY;
+
+ if (!system_supports_address_auth() && !system_supports_generic_auth())
+ return -EINVAL;
+
+ if (!arg) {
+ ptrauth_keys_init(keys);
+ ptrauth_keys_switch(keys);
+ return 0;
+ }
+
+ if (arg & ~key_mask)
+ return -EINVAL;
+
+ if (((arg & addr_key_mask) && !system_supports_address_auth()) ||
+ ((arg & PR_PAC_APGAKEY) && !system_supports_generic_auth()))
+ return -EINVAL;
+
+ if (arg & PR_PAC_APIAKEY)
+ get_random_bytes(&keys->apia, sizeof(keys->apia));
+ if (arg & PR_PAC_APIBKEY)
+ get_random_bytes(&keys->apib, sizeof(keys->apib));
+ if (arg & PR_PAC_APDAKEY)
+ get_random_bytes(&keys->apda, sizeof(keys->apda));
+ if (arg & PR_PAC_APDBKEY)
+ get_random_bytes(&keys->apdb, sizeof(keys->apdb));
+ if (arg & PR_PAC_APGAKEY)
+ get_random_bytes(&keys->apga, sizeof(keys->apga));
+
+ ptrauth_keys_switch(keys);
+
+ return 0;
+}
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index b17201edfa09..b4875a93363a 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -220,4 +220,12 @@ struct prctl_mm_map {
# define PR_SPEC_DISABLE (1UL << 2)
# define PR_SPEC_FORCE_DISABLE (1UL << 3)
+/* Reset arm64 pointer authentication keys */
+#define PR_PAC_RESET_KEYS 54
+# define PR_PAC_APIAKEY (1UL << 0)
+# define PR_PAC_APIBKEY (1UL << 1)
+# define PR_PAC_APDAKEY (1UL << 2)
+# define PR_PAC_APDBKEY (1UL << 3)
+# define PR_PAC_APGAKEY (1UL << 4)
+
#endif /* _LINUX_PRCTL_H */
diff --git a/kernel/sys.c b/kernel/sys.c
index 123bd73046ec..64b5a230f38d 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -121,6 +121,9 @@
#ifndef SVE_GET_VL
# define SVE_GET_VL() (-EINVAL)
#endif
+#ifndef PAC_RESET_KEYS
+# define PAC_RESET_KEYS(a, b) (-EINVAL)
+#endif
/*
* this is where the system-wide overflow UID and GID are defined, for
@@ -2476,6 +2479,11 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
return -EINVAL;
error = arch_prctl_spec_ctrl_set(me, arg2, arg3);
break;
+ case PR_PAC_RESET_KEYS:
+ if (arg3 || arg4 || arg5)
+ return -EINVAL;
+ error = PAC_RESET_KEYS(me, arg2);
+ break;
default:
error = -EINVAL;
break;
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 11/13] arm64: add ptrace regsets for ptrauth key management
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
Add two new ptrace regsets, which can be used to request and change the
pointer authentication keys of a thread. NT_ARM_PACA_KEYS gives access
to the instruction/data address keys, and NT_ARM_PACG_KEYS to the
generic authentication key.
The regsets are only exposed if the kernel is compiled with
CONFIG_CHECKPOINT_RESTORE=y, as the intended use case is checkpointing
and restoring processes that are using pointer authentication. Normally
applications or debuggers should not need to know the keys (and exposing
the keys is a security risk), so the regsets are not exposed by default.
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
arch/arm64/include/uapi/asm/ptrace.h | 18 +++++++++
arch/arm64/kernel/ptrace.c | 72 ++++++++++++++++++++++++++++++++++++
include/uapi/linux/elf.h | 2 +
3 files changed, 92 insertions(+)
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index c2f249bcd829..fafa7f6decf9 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -236,6 +236,24 @@ struct user_pac_mask {
__u64 insn_mask;
};
+/* pointer authentication keys (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS) */
+
+struct user_pac_address_keys {
+ __u64 apiakey_lo;
+ __u64 apiakey_hi;
+ __u64 apibkey_lo;
+ __u64 apibkey_hi;
+ __u64 apdakey_lo;
+ __u64 apdakey_hi;
+ __u64 apdbkey_lo;
+ __u64 apdbkey_hi;
+};
+
+struct user_pac_generic_keys {
+ __u64 apgakey_lo;
+ __u64 apgakey_hi;
+};
+
#endif /* __ASSEMBLY__ */
#endif /* _UAPI__ASM_PTRACE_H */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 6c1f63cb6c4e..f18f14c64d1e 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -979,6 +979,56 @@ static int pac_mask_get(struct task_struct *target,
return user_regset_copyout(&pos, &count, &kbuf, &ubuf, &uregs, 0, -1);
}
+
+#ifdef CONFIG_CHECKPOINT_RESTORE
+static int pac_address_keys_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ if (!system_supports_address_auth())
+ return -EINVAL;
+
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread_info.keys_user, 0, -1);
+}
+
+static int pac_address_keys_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ if (!system_supports_address_auth())
+ return -EINVAL;
+
+ return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread_info.keys_user, 0, -1);
+}
+
+static int pac_generic_keys_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ if (!system_supports_generic_auth())
+ return -EINVAL;
+
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread_info.keys_user.apga, 0, -1);
+}
+
+static int pac_generic_keys_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ if (!system_supports_generic_auth())
+ return -EINVAL;
+
+ return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread_info.keys_user.apga, 0, -1);
+}
+#endif /* CONFIG_CHECKPOINT_RESTORE */
#endif /* CONFIG_ARM64_PTR_AUTH */
enum aarch64_regset {
@@ -995,6 +1045,10 @@ enum aarch64_regset {
#endif
#ifdef CONFIG_ARM64_PTR_AUTH
REGSET_PAC_MASK,
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ REGSET_PACA_KEYS,
+ REGSET_PACG_KEYS,
+#endif
#endif
};
@@ -1074,6 +1128,24 @@ static const struct user_regset aarch64_regsets[] = {
.get = pac_mask_get,
/* this cannot be set dynamically */
},
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ [REGSET_PACA_KEYS] = {
+ .core_note_type = NT_ARM_PACA_KEYS,
+ .n = sizeof(struct user_pac_address_keys) / sizeof(u64),
+ .size = sizeof(u64),
+ .align = sizeof(u64),
+ .get = pac_address_keys_get,
+ .set = pac_address_keys_set,
+ },
+ [REGSET_PACG_KEYS] = {
+ .core_note_type = NT_ARM_PACG_KEYS,
+ .n = sizeof(struct user_pac_generic_keys) / sizeof(u64),
+ .size = sizeof(u64),
+ .align = sizeof(u64),
+ .get = pac_generic_keys_get,
+ .set = pac_generic_keys_set,
+ },
+#endif
#endif
};
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index 3f23273d690c..c1afbc592531 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -421,6 +421,8 @@ typedef struct elf64_shdr {
#define NT_ARM_SYSTEM_CALL 0x404 /* ARM system call number */
#define NT_ARM_SVE 0x405 /* ARM Scalable Vector Extension registers */
#define NT_ARM_PAC_MASK 0x406 /* ARM pointer authentication code masks */
+#define NT_ARM_PACA_KEYS 0x407 /* ARM pointer authentication address keys */
+#define NT_ARM_PACG_KEYS 0x408 /* ARM pointer authentication generic key */
#define NT_ARC_V2 0x600 /* ARCv2 accumulator/extra registers */
#define NT_VMCOREDD 0x700 /* Vmcore Device Dump Note */
#define NT_MIPS_DSP 0x800 /* MIPS DSP ASE registers */
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 12/13] arm64: enable pointer authentication
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
Now that all the necessary bits are in place for userspace, add the
necessary Kconfig logic to allow this to be enabled.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/Kconfig | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index ea2ab0330e3a..5279a8646fc6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1188,6 +1188,29 @@ config ARM64_CNP
endmenu
+menu "ARMv8.3 architectural features"
+
+config ARM64_PTR_AUTH
+ bool "Enable support for pointer authentication"
+ default y
+ help
+ Pointer authentication (part of the ARMv8.3 Extensions) provides
+ instructions for signing and authenticating pointers against secret
+ keys, which can be used to mitigate Return Oriented Programming (ROP)
+ and other attacks.
+
+ This option enables these instructions at EL0 (i.e. for userspace).
+
+ Choosing this option will cause the kernel to initialise secret keys
+ for each process at exec() time, with these keys being
+ context-switched along with the process.
+
+ The feature is detected at runtime. If the feature is not present in
+ hardware it will not be advertised to userspace nor will it be
+ enabled.
+
+endmenu
+
config ARM64_SVE
bool "ARM Scalable Vector Extension support"
default y
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 02/13] arm64: add pointer authentication register bits
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
The ARMv8.3 pointer authentication extension adds:
* New fields in ID_AA64ISAR1 to report the presence of pointer
authentication functionality.
* New control bits in SCTLR_ELx to enable this functionality.
* New system registers to hold the keys necessary for this
functionality.
* A new ESR_ELx.EC code used when the new instructions are affected by
configurable traps
This patch adds the relevant definitions to <asm/sysreg.h> and
<asm/esr.h> for these, to be used by subsequent patches.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/esr.h | 3 ++-
arch/arm64/include/asm/sysreg.h | 30 ++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 23602a0083ad..52233f00d53d 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -30,7 +30,8 @@
#define ESR_ELx_EC_CP14_LS (0x06)
#define ESR_ELx_EC_FP_ASIMD (0x07)
#define ESR_ELx_EC_CP10_ID (0x08) /* EL2 only */
-/* Unallocated EC: 0x09 - 0x0B */
+#define ESR_ELx_EC_PAC (0x09) /* EL2 and above */
+/* Unallocated EC: 0x0A - 0x0B */
#define ESR_ELx_EC_CP14_64 (0x0C)
/* Unallocated EC: 0x0d */
#define ESR_ELx_EC_ILL (0x0E)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 842fb9572661..cb6d7a2a2316 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -183,6 +183,19 @@
#define SYS_TTBR1_EL1 sys_reg(3, 0, 2, 0, 1)
#define SYS_TCR_EL1 sys_reg(3, 0, 2, 0, 2)
+#define SYS_APIAKEYLO_EL1 sys_reg(3, 0, 2, 1, 0)
+#define SYS_APIAKEYHI_EL1 sys_reg(3, 0, 2, 1, 1)
+#define SYS_APIBKEYLO_EL1 sys_reg(3, 0, 2, 1, 2)
+#define SYS_APIBKEYHI_EL1 sys_reg(3, 0, 2, 1, 3)
+
+#define SYS_APDAKEYLO_EL1 sys_reg(3, 0, 2, 2, 0)
+#define SYS_APDAKEYHI_EL1 sys_reg(3, 0, 2, 2, 1)
+#define SYS_APDBKEYLO_EL1 sys_reg(3, 0, 2, 2, 2)
+#define SYS_APDBKEYHI_EL1 sys_reg(3, 0, 2, 2, 3)
+
+#define SYS_APGAKEYLO_EL1 sys_reg(3, 0, 2, 3, 0)
+#define SYS_APGAKEYHI_EL1 sys_reg(3, 0, 2, 3, 1)
+
#define SYS_ICC_PMR_EL1 sys_reg(3, 0, 4, 6, 0)
#define SYS_AFSR0_EL1 sys_reg(3, 0, 5, 1, 0)
@@ -432,9 +445,13 @@
/* Common SCTLR_ELx flags. */
#define SCTLR_ELx_DSSBS (1UL << 44)
+#define SCTLR_ELx_ENIA (1 << 31)
+#define SCTLR_ELx_ENIB (1 << 30)
+#define SCTLR_ELx_ENDA (1 << 27)
#define SCTLR_ELx_EE (1 << 25)
#define SCTLR_ELx_IESB (1 << 21)
#define SCTLR_ELx_WXN (1 << 19)
+#define SCTLR_ELx_ENDB (1 << 13)
#define SCTLR_ELx_I (1 << 12)
#define SCTLR_ELx_SA (1 << 3)
#define SCTLR_ELx_C (1 << 2)
@@ -528,11 +545,24 @@
#define ID_AA64ISAR0_AES_SHIFT 4
/* id_aa64isar1 */
+#define ID_AA64ISAR1_GPI_SHIFT 28
+#define ID_AA64ISAR1_GPA_SHIFT 24
#define ID_AA64ISAR1_LRCPC_SHIFT 20
#define ID_AA64ISAR1_FCMA_SHIFT 16
#define ID_AA64ISAR1_JSCVT_SHIFT 12
+#define ID_AA64ISAR1_API_SHIFT 8
+#define ID_AA64ISAR1_APA_SHIFT 4
#define ID_AA64ISAR1_DPB_SHIFT 0
+#define ID_AA64ISAR1_APA_NI 0x0
+#define ID_AA64ISAR1_APA_ARCHITECTED 0x1
+#define ID_AA64ISAR1_API_NI 0x0
+#define ID_AA64ISAR1_API_IMP_DEF 0x1
+#define ID_AA64ISAR1_GPA_NI 0x0
+#define ID_AA64ISAR1_GPA_ARCHITECTED 0x1
+#define ID_AA64ISAR1_GPI_NI 0x0
+#define ID_AA64ISAR1_GPI_IMP_DEF 0x1
+
/* id_aa64pfr0 */
#define ID_AA64PFR0_CSV3_SHIFT 60
#define ID_AA64PFR0_CSV2_SHIFT 56
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 09/13] arm64: perf: strip PAC when unwinding userspace
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
When the kernel is unwinding userspace callchains, we can't expect that
the userspace consumer of these callchains has the data necessary to
strip the PAC from the stored LR.
This patch has the kernel strip the PAC from user stackframes when the
in-kernel unwinder is used. This only affects the LR value, and not the
FP.
This only affects the in-kernel unwinder. When userspace performs
unwinding, it is up to userspace to strip PACs as necessary (which can
be determined from DWARF information).
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/pointer_auth.h | 7 +++++++
arch/arm64/kernel/perf_callchain.c | 6 +++++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
index 5721228836c1..89190d93c850 100644
--- a/arch/arm64/include/asm/pointer_auth.h
+++ b/arch/arm64/include/asm/pointer_auth.h
@@ -65,6 +65,12 @@ static inline void ptrauth_keys_switch(struct ptrauth_keys *keys)
*/
#define ptrauth_pac_mask() GENMASK(54, VA_BITS)
+/* Only valid for EL0 TTBR0 instruction pointers */
+static inline unsigned long ptrauth_strip_insn_pac(unsigned long ptr)
+{
+ return ptr & ~ptrauth_pac_mask();
+}
+
#define ptrauth_thread_init_user(tsk) \
do { \
struct task_struct *__ptiu_tsk = (tsk); \
@@ -76,6 +82,7 @@ do { \
ptrauth_keys_switch(&(tsk)->thread_info.keys_user)
#else /* CONFIG_ARM64_PTR_AUTH */
+#define ptrauth_strip_insn_pac(lr) (lr)
#define ptrauth_thread_init_user(tsk)
#define ptrauth_thread_switch(tsk)
#endif /* CONFIG_ARM64_PTR_AUTH */
diff --git a/arch/arm64/kernel/perf_callchain.c b/arch/arm64/kernel/perf_callchain.c
index bcafd7dcfe8b..94754f07f67a 100644
--- a/arch/arm64/kernel/perf_callchain.c
+++ b/arch/arm64/kernel/perf_callchain.c
@@ -18,6 +18,7 @@
#include <linux/perf_event.h>
#include <linux/uaccess.h>
+#include <asm/pointer_auth.h>
#include <asm/stacktrace.h>
struct frame_tail {
@@ -35,6 +36,7 @@ user_backtrace(struct frame_tail __user *tail,
{
struct frame_tail buftail;
unsigned long err;
+ unsigned long lr;
/* Also check accessibility of one struct frame_tail beyond */
if (!access_ok(VERIFY_READ, tail, sizeof(buftail)))
@@ -47,7 +49,9 @@ user_backtrace(struct frame_tail __user *tail,
if (err)
return NULL;
- perf_callchain_store(entry, buftail.lr);
+ lr = ptrauth_strip_insn_pac(buftail.lr);
+
+ perf_callchain_store(entry, lr);
/*
* Frame pointers should strictly progress back up the stack
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 07/13] arm64: add basic pointer authentication support
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
This patch adds basic support for pointer authentication, allowing
userspace to make use of APIAKey, APIBKey, APDAKey, APDBKey, and
APGAKey. The kernel maintains key values for each process (shared by all
threads within), which are initialised to random values at exec() time.
The ID_AA64ISAR1_EL1.{APA,API,GPA,GPI} fields are exposed to userspace,
to describe that pointer authentication instructions are available and
that the kernel is managing the keys. Two new hwcaps are added for the
same reason: PACA (for address authentication) and PACG (for generic
authentication).
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Tested-by: Adam Wallis <awallis@codeaurora.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/pointer_auth.h | 75 +++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/thread_info.h | 4 ++
arch/arm64/include/uapi/asm/hwcap.h | 2 +
arch/arm64/kernel/cpufeature.c | 13 ++++++
arch/arm64/kernel/cpuinfo.c | 2 +
arch/arm64/kernel/process.c | 4 ++
6 files changed, 100 insertions(+)
create mode 100644 arch/arm64/include/asm/pointer_auth.h
diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
new file mode 100644
index 000000000000..fc7ffe8e326f
--- /dev/null
+++ b/arch/arm64/include/asm/pointer_auth.h
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+#ifndef __ASM_POINTER_AUTH_H
+#define __ASM_POINTER_AUTH_H
+
+#include <linux/random.h>
+
+#include <asm/cpufeature.h>
+#include <asm/sysreg.h>
+
+#ifdef CONFIG_ARM64_PTR_AUTH
+/*
+ * Each key is a 128-bit quantity which is split across a pair of 64-bit
+ * registers (Lo and Hi).
+ */
+struct ptrauth_key {
+ unsigned long lo, hi;
+};
+
+/*
+ * We give each process its own keys, which are shared by all threads. The keys
+ * are inherited upon fork(), and reinitialised upon exec*().
+ */
+struct ptrauth_keys {
+ struct ptrauth_key apia;
+ struct ptrauth_key apib;
+ struct ptrauth_key apda;
+ struct ptrauth_key apdb;
+ struct ptrauth_key apga;
+};
+
+static inline void ptrauth_keys_init(struct ptrauth_keys *keys)
+{
+ if (system_supports_address_auth())
+ get_random_bytes(keys, sizeof(struct ptrauth_key) * 4);
+
+ if (system_supports_generic_auth())
+ get_random_bytes(&keys->apga, sizeof(struct ptrauth_key));
+}
+
+#define __ptrauth_key_install(k, v) \
+do { \
+ struct ptrauth_key __pki_v = (v); \
+ write_sysreg_s(__pki_v.lo, SYS_ ## k ## KEYLO_EL1); \
+ write_sysreg_s(__pki_v.hi, SYS_ ## k ## KEYHI_EL1); \
+} while (0)
+
+static inline void ptrauth_keys_switch(struct ptrauth_keys *keys)
+{
+ if (system_supports_address_auth()) {
+ __ptrauth_key_install(APIA, keys->apia);
+ __ptrauth_key_install(APIB, keys->apib);
+ __ptrauth_key_install(APDA, keys->apda);
+ __ptrauth_key_install(APDB, keys->apdb);
+ }
+
+ if (system_supports_generic_auth())
+ __ptrauth_key_install(APGA, keys->apga);
+}
+
+#define ptrauth_thread_init_user(tsk) \
+do { \
+ struct task_struct *__ptiu_tsk = (tsk); \
+ ptrauth_keys_init(&__ptiu_tsk->thread_info.keys_user); \
+ ptrauth_keys_switch(&__ptiu_tsk->thread_info.keys_user); \
+} while (0)
+
+#define ptrauth_thread_switch(tsk) \
+ ptrauth_keys_switch(&(tsk)->thread_info.keys_user)
+
+#else /* CONFIG_ARM64_PTR_AUTH */
+#define ptrauth_thread_init_user(tsk)
+#define ptrauth_thread_switch(tsk)
+#endif /* CONFIG_ARM64_PTR_AUTH */
+
+#endif /* __ASM_POINTER_AUTH_H */
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index cb2c10a8f0a8..ea9272fb52d4 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -28,6 +28,7 @@
struct task_struct;
#include <asm/memory.h>
+#include <asm/pointer_auth.h>
#include <asm/stack_pointer.h>
#include <asm/types.h>
@@ -43,6 +44,9 @@ struct thread_info {
u64 ttbr0; /* saved TTBR0_EL1 */
#endif
int preempt_count; /* 0 => preemptable, <0 => bug */
+#ifdef CONFIG_ARM64_PTR_AUTH
+ struct ptrauth_keys keys_user;
+#endif
};
#define thread_saved_pc(tsk) \
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 2bcd6e4f3474..22efc70aa0a1 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -49,5 +49,7 @@
#define HWCAP_ILRCPC (1 << 26)
#define HWCAP_FLAGM (1 << 27)
#define HWCAP_SSBS (1 << 28)
+#define HWCAP_PACA (1 << 29)
+#define HWCAP_PACG (1 << 30)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f8e3c3568a79..6daa2f451eb9 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1154,6 +1154,12 @@ static void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused)
#endif /* CONFIG_ARM64_RAS_EXTN */
#ifdef CONFIG_ARM64_PTR_AUTH
+static void cpu_enable_address_auth(struct arm64_cpu_capabilities const *cap)
+{
+ sysreg_clear_set(sctlr_el1, 0, SCTLR_ELx_ENIA | SCTLR_ELx_ENIB |
+ SCTLR_ELx_ENDA | SCTLR_ELx_ENDB);
+}
+
static bool has_address_auth(const struct arm64_cpu_capabilities *entry,
int __unused)
{
@@ -1431,6 +1437,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.capability = ARM64_HAS_ADDRESS_AUTH,
.type = ARM64_CPUCAP_SYSTEM_FEATURE,
.matches = has_address_auth,
+ .cpu_enable = cpu_enable_address_auth,
},
{
.desc = "Generic authentication (architected algorithm)",
@@ -1504,6 +1511,12 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_SVE_SHIFT, FTR_UNSIGNED, ID_AA64PFR0_SVE, CAP_HWCAP, HWCAP_SVE),
#endif
HWCAP_CAP(SYS_ID_AA64PFR1_EL1, ID_AA64PFR1_SSBS_SHIFT, FTR_UNSIGNED, ID_AA64PFR1_SSBS_PSTATE_INSNS, CAP_HWCAP, HWCAP_SSBS),
+#ifdef CONFIG_ARM64_PTR_AUTH
+ { .desc = "HWCAP_PACA", .type = ARM64_CPUCAP_SYSTEM_FEATURE, .matches = has_address_auth,
+ .hwcap_type = CAP_HWCAP, .hwcap = HWCAP_PACA },
+ { .desc = "HWCAP_PACG", .type = ARM64_CPUCAP_SYSTEM_FEATURE, .matches = has_generic_auth,
+ .hwcap_type = CAP_HWCAP, .hwcap = HWCAP_PACG },
+#endif
{},
};
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index bcc2831399cb..e7c7cad8dd85 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -82,6 +82,8 @@ static const char *const hwcap_str[] = {
"ilrcpc",
"flagm",
"ssbs",
+ "paca",
+ "pacg",
NULL
};
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index d9a4c2d6dd8b..17a6b4dd6e46 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -57,6 +57,7 @@
#include <asm/fpsimd.h>
#include <asm/mmu_context.h>
#include <asm/processor.h>
+#include <asm/pointer_auth.h>
#include <asm/stacktrace.h>
#ifdef CONFIG_STACKPROTECTOR
@@ -429,6 +430,7 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
contextidr_thread_switch(next);
entry_task_switch(next);
uao_thread_switch(next);
+ ptrauth_thread_switch(next);
/*
* Complete any pending TLB or cache maintenance on this CPU in case
@@ -496,4 +498,6 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
void arch_setup_new_exec(void)
{
current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
+
+ ptrauth_thread_init_user(current);
}
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 06/13] arm64/cpufeature: detect pointer authentication
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
So that we can dynamically handle the presence of pointer authentication
functionality, wire up probing code in cpufeature.c.
From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now
has four fields describing the presence of pointer authentication
functionality:
* APA - address authentication present, using an architected algorithm
* API - address authentication present, using an IMP DEF algorithm
* GPA - generic authentication present, using an architected algorithm
* GPI - generic authentication present, using an IMP DEF algorithm
This patch checks for both address and generic authentication,
separately. It is assumed that if all CPUs support an IMP DEF algorithm,
the same algorithm is used across all CPUs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/cpucaps.h | 8 +++-
arch/arm64/include/asm/cpufeature.h | 12 +++++
arch/arm64/kernel/cpufeature.c | 90 +++++++++++++++++++++++++++++++++++++
3 files changed, 109 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 6e2d254c09eb..62fc48604263 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -54,7 +54,13 @@
#define ARM64_HAS_CRC32 33
#define ARM64_SSBS 34
#define ARM64_WORKAROUND_1188873 35
+#define ARM64_HAS_ADDRESS_AUTH_ARCH 36
+#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF 37
+#define ARM64_HAS_ADDRESS_AUTH 38
+#define ARM64_HAS_GENERIC_AUTH_ARCH 39
+#define ARM64_HAS_GENERIC_AUTH_IMP_DEF 40
+#define ARM64_HAS_GENERIC_AUTH 41
-#define ARM64_NCAPS 36
+#define ARM64_NCAPS 42
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 7e2ec64aa414..1c8393ffabff 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -514,6 +514,18 @@ static inline bool system_supports_cnp(void)
cpus_have_const_cap(ARM64_HAS_CNP);
}
+static inline bool system_supports_address_auth(void)
+{
+ return IS_ENABLED(CONFIG_ARM64_PTR_AUTH) &&
+ cpus_have_const_cap(ARM64_HAS_ADDRESS_AUTH);
+}
+
+static inline bool system_supports_generic_auth(void)
+{
+ return IS_ENABLED(CONFIG_ARM64_PTR_AUTH) &&
+ cpus_have_const_cap(ARM64_HAS_GENERIC_AUTH);
+}
+
#define ARM64_SSBD_UNKNOWN -1
#define ARM64_SSBD_FORCE_DISABLE 0
#define ARM64_SSBD_KERNEL 1
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index aec5ecb85737..f8e3c3568a79 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -141,9 +141,17 @@ static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
};
static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
+ ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+ FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_GPI_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+ FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_GPA_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_LRCPC_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_FCMA_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_JSCVT_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+ FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_API_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+ FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_APA_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_DPB_SHIFT, 4, 0),
ARM64_FTR_END,
};
@@ -1145,6 +1153,36 @@ static void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused)
}
#endif /* CONFIG_ARM64_RAS_EXTN */
+#ifdef CONFIG_ARM64_PTR_AUTH
+static bool has_address_auth(const struct arm64_cpu_capabilities *entry,
+ int __unused)
+{
+ u64 isar1 = read_sanitised_ftr_reg(SYS_ID_AA64ISAR1_EL1);
+ bool api, apa;
+
+ apa = cpuid_feature_extract_unsigned_field(isar1,
+ ID_AA64ISAR1_APA_SHIFT) > 0;
+ api = cpuid_feature_extract_unsigned_field(isar1,
+ ID_AA64ISAR1_API_SHIFT) > 0;
+
+ return apa || api;
+}
+
+static bool has_generic_auth(const struct arm64_cpu_capabilities *entry,
+ int __unused)
+{
+ u64 isar1 = read_sanitised_ftr_reg(SYS_ID_AA64ISAR1_EL1);
+ bool gpi, gpa;
+
+ gpa = cpuid_feature_extract_unsigned_field(isar1,
+ ID_AA64ISAR1_GPA_SHIFT) > 0;
+ gpi = cpuid_feature_extract_unsigned_field(isar1,
+ ID_AA64ISAR1_GPI_SHIFT) > 0;
+
+ return gpa || gpi;
+}
+#endif /* CONFIG_ARM64_PTR_AUTH */
+
static const struct arm64_cpu_capabilities arm64_features[] = {
{
.desc = "GIC system register CPU interface",
@@ -1368,6 +1406,58 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.cpu_enable = cpu_enable_cnp,
},
#endif
+#ifdef CONFIG_ARM64_PTR_AUTH
+ {
+ .desc = "Address authentication (architected algorithm)",
+ .capability = ARM64_HAS_ADDRESS_AUTH_ARCH,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .sys_reg = SYS_ID_AA64ISAR1_EL1,
+ .sign = FTR_UNSIGNED,
+ .field_pos = ID_AA64ISAR1_APA_SHIFT,
+ .min_field_value = ID_AA64ISAR1_APA_ARCHITECTED,
+ .matches = has_cpuid_feature,
+ },
+ {
+ .desc = "Address authentication (IMP DEF algorithm)",
+ .capability = ARM64_HAS_ADDRESS_AUTH_IMP_DEF,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .sys_reg = SYS_ID_AA64ISAR1_EL1,
+ .sign = FTR_UNSIGNED,
+ .field_pos = ID_AA64ISAR1_API_SHIFT,
+ .min_field_value = ID_AA64ISAR1_API_IMP_DEF,
+ .matches = has_cpuid_feature,
+ },
+ {
+ .capability = ARM64_HAS_ADDRESS_AUTH,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = has_address_auth,
+ },
+ {
+ .desc = "Generic authentication (architected algorithm)",
+ .capability = ARM64_HAS_GENERIC_AUTH_ARCH,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .sys_reg = SYS_ID_AA64ISAR1_EL1,
+ .sign = FTR_UNSIGNED,
+ .field_pos = ID_AA64ISAR1_GPA_SHIFT,
+ .min_field_value = ID_AA64ISAR1_GPA_ARCHITECTED,
+ .matches = has_cpuid_feature,
+ },
+ {
+ .desc = "Generic authentication (IMP DEF algorithm)",
+ .capability = ARM64_HAS_GENERIC_AUTH_IMP_DEF,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .sys_reg = SYS_ID_AA64ISAR1_EL1,
+ .sign = FTR_UNSIGNED,
+ .field_pos = ID_AA64ISAR1_GPI_SHIFT,
+ .min_field_value = ID_AA64ISAR1_GPI_IMP_DEF,
+ .matches = has_cpuid_feature,
+ },
+ {
+ .capability = ARM64_HAS_GENERIC_AUTH,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = has_generic_auth,
+ },
+#endif /* CONFIG_ARM64_PTR_AUTH */
{},
};
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 08/13] arm64: expose user PAC bit positions via ptrace
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
When pointer authentication is in use, data/instruction pointers have a
number of PAC bits inserted into them. The number and position of these
bits depends on the configured TCR_ELx.TxSZ and whether tagging is
enabled. ARMv8.3 allows tagging to differ for instruction and data
pointers.
For userspace debuggers to unwind the stack and/or to follow pointer
chains, they need to be able to remove the PAC bits before attempting to
use a pointer.
This patch adds a new structure with masks describing the location of
the PAC bits in userspace instruction and data pointers (i.e. those
addressable via TTBR0), which userspace can query via PTRACE_GETREGSET.
By clearing these bits from pointers (and replacing them with the value
of bit 55), userspace can acquire the PAC-less versions.
This new regset is exposed when the kernel is built with (user) pointer
authentication support, and the address authentication feature is
enabled. Otherwise, the regset is hidden.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/pointer_auth.h | 8 ++++++++
arch/arm64/include/uapi/asm/ptrace.h | 7 +++++++
arch/arm64/kernel/ptrace.c | 38 +++++++++++++++++++++++++++++++++++
include/uapi/linux/elf.h | 1 +
4 files changed, 54 insertions(+)
diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
index fc7ffe8e326f..5721228836c1 100644
--- a/arch/arm64/include/asm/pointer_auth.h
+++ b/arch/arm64/include/asm/pointer_auth.h
@@ -2,9 +2,11 @@
#ifndef __ASM_POINTER_AUTH_H
#define __ASM_POINTER_AUTH_H
+#include <linux/bitops.h>
#include <linux/random.h>
#include <asm/cpufeature.h>
+#include <asm/memory.h>
#include <asm/sysreg.h>
#ifdef CONFIG_ARM64_PTR_AUTH
@@ -57,6 +59,12 @@ static inline void ptrauth_keys_switch(struct ptrauth_keys *keys)
__ptrauth_key_install(APGA, keys->apga);
}
+/*
+ * The EL0 pointer bits used by a pointer authentication code.
+ * This is dependent on TBI0 being enabled, or bits 63:56 would also apply.
+ */
+#define ptrauth_pac_mask() GENMASK(54, VA_BITS)
+
#define ptrauth_thread_init_user(tsk) \
do { \
struct task_struct *__ptiu_tsk = (tsk); \
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index a36227fdb084..c2f249bcd829 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -229,6 +229,13 @@ struct user_sve_header {
SVE_PT_SVE_OFFSET + SVE_PT_SVE_SIZE(vq, flags) \
: SVE_PT_FPSIMD_OFFSET + SVE_PT_FPSIMD_SIZE(vq, flags))
+/* pointer authentication masks (NT_ARM_PAC_MASK) */
+
+struct user_pac_mask {
+ __u64 data_mask;
+ __u64 insn_mask;
+};
+
#endif /* __ASSEMBLY__ */
#endif /* _UAPI__ASM_PTRACE_H */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 1710a2d01669..6c1f63cb6c4e 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -46,6 +46,7 @@
#include <asm/debug-monitors.h>
#include <asm/fpsimd.h>
#include <asm/pgtable.h>
+#include <asm/pointer_auth.h>
#include <asm/stacktrace.h>
#include <asm/syscall.h>
#include <asm/traps.h>
@@ -956,6 +957,30 @@ static int sve_set(struct task_struct *target,
#endif /* CONFIG_ARM64_SVE */
+#ifdef CONFIG_ARM64_PTR_AUTH
+static int pac_mask_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ /*
+ * The PAC bits can differ across data and instruction pointers
+ * depending on TCR_EL1.TBID*, which we may make use of in future, so
+ * we expose separate masks.
+ */
+ unsigned long mask = ptrauth_pac_mask();
+ struct user_pac_mask uregs = {
+ .data_mask = mask,
+ .insn_mask = mask,
+ };
+
+ if (!system_supports_address_auth())
+ return -EINVAL;
+
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf, &uregs, 0, -1);
+}
+#endif /* CONFIG_ARM64_PTR_AUTH */
+
enum aarch64_regset {
REGSET_GPR,
REGSET_FPR,
@@ -968,6 +993,9 @@ enum aarch64_regset {
#ifdef CONFIG_ARM64_SVE
REGSET_SVE,
#endif
+#ifdef CONFIG_ARM64_PTR_AUTH
+ REGSET_PAC_MASK,
+#endif
};
static const struct user_regset aarch64_regsets[] = {
@@ -1037,6 +1065,16 @@ static const struct user_regset aarch64_regsets[] = {
.get_size = sve_get_size,
},
#endif
+#ifdef CONFIG_ARM64_PTR_AUTH
+ [REGSET_PAC_MASK] = {
+ .core_note_type = NT_ARM_PAC_MASK,
+ .n = sizeof(struct user_pac_mask) / sizeof(u64),
+ .size = sizeof(u64),
+ .align = sizeof(u64),
+ .get = pac_mask_get,
+ /* this cannot be set dynamically */
+ },
+#endif
};
static const struct user_regset_view user_aarch64_view = {
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index c5358e0ae7c5..3f23273d690c 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -420,6 +420,7 @@ typedef struct elf64_shdr {
#define NT_ARM_HW_WATCH 0x403 /* ARM hardware watchpoint registers */
#define NT_ARM_SYSTEM_CALL 0x404 /* ARM system call number */
#define NT_ARM_SVE 0x405 /* ARM Scalable Vector Extension registers */
+#define NT_ARM_PAC_MASK 0x406 /* ARM pointer authentication code masks */
#define NT_ARC_V2 0x600 /* ARCv2 accumulator/extra registers */
#define NT_VMCOREDD 0x700 /* Vmcore Device Dump Note */
#define NT_MIPS_DSP 0x800 /* MIPS DSP ASE registers */
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
In subsequent patches we're going to expose ptrauth to the host kernel
and userspace, but things are a bit trickier for guest kernels. For the
time being, let's hide ptrauth from KVM guests.
Regardless of how well-behaved the guest kernel is, guest userspace
could attempt to use ptrauth instructions, triggering a trap to EL2,
resulting in noise from kvm_handle_unknown_ec(). So let's write up a
handler for the PAC trap, which silently injects an UNDEF into the
guest, as if the feature were really missing.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
---
arch/arm64/kvm/handle_exit.c | 18 ++++++++++++++++++
arch/arm64/kvm/sys_regs.c | 8 ++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 35a81bebd02b..ab35929dcb3c 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -173,6 +173,23 @@ static int handle_sve(struct kvm_vcpu *vcpu, struct kvm_run *run)
return 1;
}
+/*
+ * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into
+ * a NOP).
+ */
+static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ /*
+ * We don't currently support ptrauth in a guest, and we mask the ID
+ * registers to prevent well-behaved guests from trying to make use of
+ * it.
+ *
+ * Inject an UNDEF, as if the feature really isn't present.
+ */
+ kvm_inject_undefined(vcpu);
+ return 1;
+}
+
static exit_handle_fn arm_exit_handlers[] = {
[0 ... ESR_ELx_EC_MAX] = kvm_handle_unknown_ec,
[ESR_ELx_EC_WFx] = kvm_handle_wfx,
@@ -195,6 +212,7 @@ static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_BKPT32] = kvm_handle_guest_debug,
[ESR_ELx_EC_BRK64] = kvm_handle_guest_debug,
[ESR_ELx_EC_FP_ASIMD] = handle_no_fpsimd,
+ [ESR_ELx_EC_PAC] = kvm_handle_ptrauth,
};
static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 22fbbdbece3c..1ca592d38c3c 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1040,6 +1040,14 @@ static u64 read_id_reg(struct sys_reg_desc const *r, bool raz)
kvm_debug("SVE unsupported for guests, suppressing\n");
val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
+ } else if (id == SYS_ID_AA64ISAR1_EL1) {
+ const u64 ptrauth_mask = (0xfUL << ID_AA64ISAR1_APA_SHIFT) |
+ (0xfUL << ID_AA64ISAR1_API_SHIFT) |
+ (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
+ (0xfUL << ID_AA64ISAR1_GPI_SHIFT);
+ if (val & ptrauth_mask)
+ kvm_debug("ptrauth unsupported for guests, suppressing\n");
+ val &= ~ptrauth_mask;
} else if (id == SYS_ID_AA64MMFR1_EL1) {
if (val & (0xfUL << ID_AA64MMFR1_LOR_SHIFT))
kvm_debug("LORegions unsupported for guests, suppressing\n");
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 05/13] arm64: Don't trap host pointer auth use to EL2
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
To allow EL0 (and/or EL1) to use pointer authentication functionality,
we must ensure that pointer authentication instructions and accesses to
pointer authentication keys are not trapped to EL2.
This patch ensures that HCR_EL2 is configured appropriately when the
kernel is booted at EL2. For non-VHE kernels we set HCR_EL2.{API,APK},
ensuring that EL1 can access keys and permit EL0 use of instructions.
For VHE kernels host EL0 (TGE && E2H) is unaffected by these settings,
and it doesn't matter how we configure HCR_EL2.{API,APK}, so we don't
bother setting them.
This does not enable support for KVM guests, since KVM manages HCR_EL2
itself when running VMs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
---
arch/arm64/include/asm/kvm_arm.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index c8825c5a8dd0..f9123fe8fcf3 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -24,6 +24,8 @@
/* Hyp Configuration Register (HCR) bits */
#define HCR_FWB (UL(1) << 46)
+#define HCR_API (UL(1) << 41)
+#define HCR_APK (UL(1) << 40)
#define HCR_TEA (UL(1) << 37)
#define HCR_TERR (UL(1) << 36)
#define HCR_TLOR (UL(1) << 35)
@@ -87,7 +89,7 @@
HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW | HCR_TLOR | \
HCR_FMO | HCR_IMO)
#define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF)
-#define HCR_HOST_NVHE_FLAGS (HCR_RW)
+#define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK)
#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
/* TCR_EL2 Registers bits */
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 03/13] arm64/kvm: consistently handle host HCR_EL2 flags
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
In KVM we define the configuration of HCR_EL2 for a VHE HOST in
HCR_HOST_VHE_FLAGS, but we don't have a similar definition for the
non-VHE host flags, and open-code HCR_RW. Further, in head.S we
open-code the flags for VHE and non-VHE configurations.
In future, we're going to want to configure more flags for the host, so
lets add a HCR_HOST_NVHE_FLAGS defintion, and consistently use both
HCR_HOST_VHE_FLAGS and HCR_HOST_NVHE_FLAGS in the kvm code and head.S.
We now use mov_q to generate the HCR_EL2 value, as we use when
configuring other registers in head.S.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
---
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/kernel/head.S | 5 ++---
arch/arm64/kvm/hyp/switch.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 6f602af5263c..c8825c5a8dd0 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -87,6 +87,7 @@
HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW | HCR_TLOR | \
HCR_FMO | HCR_IMO)
#define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF)
+#define HCR_HOST_NVHE_FLAGS (HCR_RW)
#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
/* TCR_EL2 Registers bits */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 4471f570a295..b207a2ce4bc6 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -496,10 +496,9 @@ ENTRY(el2_setup)
#endif
/* Hyp configuration. */
- mov x0, #HCR_RW // 64-bit EL1
+ mov_q x0, HCR_HOST_NVHE_FLAGS
cbz x2, set_hcr
- orr x0, x0, #HCR_TGE // Enable Host Extensions
- orr x0, x0, #HCR_E2H
+ mov_q x0, HCR_HOST_VHE_FLAGS
set_hcr:
msr hcr_el2, x0
isb
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 7cc175c88a37..f6e02cc4d856 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -157,7 +157,7 @@ static void __hyp_text __deactivate_traps_nvhe(void)
mdcr_el2 |= MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT;
write_sysreg(mdcr_el2, mdcr_el2);
- write_sysreg(HCR_RW, hcr_el2);
+ write_sysreg(HCR_HOST_NVHE_FLAGS, hcr_el2);
write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
}
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 00/13] ARMv8.3 pointer authentication userspace support
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
Hi,
This series adds support for the ARMv8.3 pointer authentication extension,
enabling userspace return address protection with GCC 7 and above.
(The previous version also had in-kernel pointer authentication patches
as RFC; these will be updated and sent at a later time.)
Changes since v5 [1]:
- Exposed all 5 keys (not just APIAKey) [Will]
- New prctl for reinitializing keys [Will]
- New ptrace options for getting and setting keys [Will]
- Keys now per-thread instead of per-mm [Catalin]
- Fixed cpufeature detection for late CPUs [Suzuki]
- Added comments for ESR_ELx_EC_* definitions [Will]
- Rebased onto v4.20-rc5
This series is based on v4.20-rc5. The aarch64 bootwrapper [2] does the
necessary EL3 setup.
The patches are also available at:
git://linux-arm.org/linux-km.git ptrauth-user
Extension Overview
==================
The ARMv8.3 pointer authentication extension adds functionality to detect
modification of pointer values, mitigating certain classes of attack such as
stack smashing, and making return oriented programming attacks harder.
The extension introduces the concept of a pointer authentication code (PAC),
which is stored in some upper bits of pointers. Each PAC is derived from the
original pointer, another 64-bit value (e.g. the stack pointer), and a secret
128-bit key.
New instructions are added which can be used to:
* Insert a PAC into a pointer
* Strip a PAC from a pointer
* Authenticate strip a PAC from a pointer
If authentication succeeds, the code is removed, yielding the original pointer.
If authentication fails, bits are set in the pointer such that it is guaranteed
to cause a fault if used.
These instructions can make use of four keys:
* APIAKey (A.K.A. Instruction A key)
* APIBKey (A.K.A. Instruction B key)
* APDAKey (A.K.A. Data A key)
* APDBKey (A.K.A. Data B Key)
A subset of these instruction encodings have been allocated from the HINT
space, and will operate as NOPs on any ARMv8-A parts which do not feature the
extension (or if purposefully disabled by the kernel). Software using only this
subset of the instructions should function correctly on all ARMv8-A parts.
Additionally, instructions are added to authenticate small blocks of memory in
similar fashion, using APGAKey (A.K.A. Generic key).
This series
===========
This series enables userspace to use any pointer authentication instructions,
using any of the 5 keys. The keys are initialised and maintained per-process
(shared by all threads).
For the time being, this series hides pointer authentication functionality from
KVM guests. Amit Kachhap is currently looking into supporting pointer
authentication in guests.
Setting uprobes on pointer authentication instructions is not yet supported, and
may cause the application to behave in unexpected ways.
Feedback and comments are welcome.
Thanks,
Kristina
[1] https://lore.kernel.org/lkml/20181005084754.20950-1-kristina.martsenko@arm.com/
[2] git://git.kernel.org/pub/scm/linux/kernel/git/mark/boot-wrapper-aarch64.git
Kristina Martsenko (3):
arm64: add comments about EC exception levels
arm64: add prctl control for resetting ptrauth keys
arm64: add ptrace regsets for ptrauth key management
Mark Rutland (10):
arm64: add pointer authentication register bits
arm64/kvm: consistently handle host HCR_EL2 flags
arm64/kvm: hide ptrauth from guests
arm64: Don't trap host pointer auth use to EL2
arm64/cpufeature: detect pointer authentication
arm64: add basic pointer authentication support
arm64: expose user PAC bit positions via ptrace
arm64: perf: strip PAC when unwinding userspace
arm64: enable pointer authentication
arm64: docs: document pointer authentication
Documentation/arm64/booting.txt | 8 ++
Documentation/arm64/cpu-feature-registers.txt | 8 ++
Documentation/arm64/elf_hwcaps.txt | 12 +++
Documentation/arm64/pointer-authentication.txt | 93 +++++++++++++++++++++
arch/arm64/Kconfig | 23 ++++++
arch/arm64/include/asm/cpucaps.h | 8 +-
arch/arm64/include/asm/cpufeature.h | 12 +++
arch/arm64/include/asm/esr.h | 17 ++--
arch/arm64/include/asm/kvm_arm.h | 3 +
arch/arm64/include/asm/pointer_auth.h | 93 +++++++++++++++++++++
arch/arm64/include/asm/processor.h | 4 +
arch/arm64/include/asm/sysreg.h | 30 +++++++
arch/arm64/include/asm/thread_info.h | 4 +
arch/arm64/include/uapi/asm/hwcap.h | 2 +
arch/arm64/include/uapi/asm/ptrace.h | 25 ++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/cpufeature.c | 103 +++++++++++++++++++++++
arch/arm64/kernel/cpuinfo.c | 2 +
arch/arm64/kernel/head.S | 5 +-
arch/arm64/kernel/perf_callchain.c | 6 +-
arch/arm64/kernel/pointer_auth.c | 47 +++++++++++
arch/arm64/kernel/process.c | 4 +
arch/arm64/kernel/ptrace.c | 110 +++++++++++++++++++++++++
arch/arm64/kvm/handle_exit.c | 18 ++++
arch/arm64/kvm/hyp/switch.c | 2 +-
arch/arm64/kvm/sys_regs.c | 8 ++
include/uapi/linux/elf.h | 3 +
include/uapi/linux/prctl.h | 8 ++
kernel/sys.c | 8 ++
29 files changed, 653 insertions(+), 14 deletions(-)
create mode 100644 Documentation/arm64/pointer-authentication.txt
create mode 100644 arch/arm64/include/asm/pointer_auth.h
create mode 100644 arch/arm64/kernel/pointer_auth.c
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 01/13] arm64: add comments about EC exception levels
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
To make it clear which exceptions can't be taken to EL1 or EL2, add
comments next to the ESR_ELx_EC_* macro definitions.
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
arch/arm64/include/asm/esr.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 676de2ec1762..23602a0083ad 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -29,23 +29,23 @@
#define ESR_ELx_EC_CP14_MR (0x05)
#define ESR_ELx_EC_CP14_LS (0x06)
#define ESR_ELx_EC_FP_ASIMD (0x07)
-#define ESR_ELx_EC_CP10_ID (0x08)
+#define ESR_ELx_EC_CP10_ID (0x08) /* EL2 only */
/* Unallocated EC: 0x09 - 0x0B */
#define ESR_ELx_EC_CP14_64 (0x0C)
/* Unallocated EC: 0x0d */
#define ESR_ELx_EC_ILL (0x0E)
/* Unallocated EC: 0x0F - 0x10 */
#define ESR_ELx_EC_SVC32 (0x11)
-#define ESR_ELx_EC_HVC32 (0x12)
-#define ESR_ELx_EC_SMC32 (0x13)
+#define ESR_ELx_EC_HVC32 (0x12) /* EL2 only */
+#define ESR_ELx_EC_SMC32 (0x13) /* EL2 and above */
/* Unallocated EC: 0x14 */
#define ESR_ELx_EC_SVC64 (0x15)
-#define ESR_ELx_EC_HVC64 (0x16)
-#define ESR_ELx_EC_SMC64 (0x17)
+#define ESR_ELx_EC_HVC64 (0x16) /* EL2 and above */
+#define ESR_ELx_EC_SMC64 (0x17) /* EL2 and above */
#define ESR_ELx_EC_SYS64 (0x18)
#define ESR_ELx_EC_SVE (0x19)
/* Unallocated EC: 0x1A - 0x1E */
-#define ESR_ELx_EC_IMP_DEF (0x1f)
+#define ESR_ELx_EC_IMP_DEF (0x1f) /* EL3 only */
#define ESR_ELx_EC_IABT_LOW (0x20)
#define ESR_ELx_EC_IABT_CUR (0x21)
#define ESR_ELx_EC_PC_ALIGN (0x22)
@@ -68,7 +68,7 @@
/* Unallocated EC: 0x36 - 0x37 */
#define ESR_ELx_EC_BKPT32 (0x38)
/* Unallocated EC: 0x39 */
-#define ESR_ELx_EC_VECTOR32 (0x3A)
+#define ESR_ELx_EC_VECTOR32 (0x3A) /* EL2 only */
/* Unallocted EC: 0x3B */
#define ESR_ELx_EC_BRK64 (0x3C)
/* Unallocated EC: 0x3D - 0x3F */
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox