* [Dev] [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Ard Biesheuvel @ 2018-06-19 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuUZTG0q4f2T=+HjEijUCLb7KNXok9RJHOXOKNs2iap5p7m5Q@mail.gmail.com>
On 19 June 2018 at 17:14, Yang Zhang <yang.zhang@96boards.org> wrote:
>
>
> On 18 June 2018 at 14:22, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>
>> On 18 June 2018 at 14:21, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Mon, Jun 18, 2018 at 9:45 AM, Linus Walleij
>> > <linus.walleij@linaro.org> wrote:
>> >> This is a proposal for how to handle the non-discoverable
>> >> 96boards plug-in expansion boards called "mezzanines" in the
>> >> Linux kernel. It is a working RFC series meant for discussion
>> >> at the moment.
>> >>
>> >> The RFC was done on the brand new Ultra96 board from Xilinx
>> >> with a Secure96 mezzanine expansion board. The main part
>> >> is in patch 4, the rest is enabling and examples.
>> >>
>> >> The code can be obtained from here:
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96
>> >>
>> >> You can for example probably augment the DTS file for any
>> >> upstream-supported 96board and get the Secure96 going with
>> >> it with minor efforts.
>> >
>> > Hi Linus,
>> >
>> > Thanks for your work on solving this long-standing problem. I've just
>> > read through your patches briefly and have a few thoughts:
>> >
>> > - I really like the idea of having C code deal with the mezzanine
>> > connector itself, acting as an intermediate to tie a number of
>> > boards to a number of add-on cards, this seems much simpler than
>> > trying to do everything with overlays or one of the other more
>> > generic mechanisms.
>> >
>> > - I don't like the idea of having the bus driver contain a list of
>> > possible
>> > add-ons, this seems to go against our usual driver model. What
>> > I think we want instead is to make the connector itself a proper
>> > bus_type, to allow drivers to register against it as loadable modules,
>> > and devices (maybe limited to one device) being created as probed
>> > from DT or some other method as you describe.
>> >
>> > - You export symbols in the mezzanine_* namespace, which I think
>> > is a bit too generic and should perhaps contain something related
>> > to 96boards in its name to make it less ambiguous. I suspect we
>> > would add a number of further connectors for hats, capes, lures etc,
>> > which could all be described as mezzanines. One open question
>> > is how we structure the commonality between the various
>> > connectors, but we can defer that until we have more than one
>> > or two of them.
>> >
>>
>> Hello all,
>>
>> We should also consider firmware use of the mezzanines. For instance,
>> the Secure96 has a RNG which UEFI may want to use so the early boot
>> code can access is for KASLR. It also has a TPM, which should not be
>> reset/reinitialized/etc by the OS if we want to make meaningful use of
>> it.
>>
>> Also, given that we can (and do) already describe topologies involving
>> mezzanines by ignoring the connector altogether (which is not entirely
>> unreasonable given the fact that we [as Linaro/96boards] dropped the
>> ball on this one and did not mandate discoverability for mezzanines).
>
>
> The design guideline has been reviewed by many inside/outside linaro through
> the mezzanine at lists.96boards.org and 96b-spec-sig
> <96b-spec-sig@96boards.org> published as recommended/strongly recommended
> item from day one. 'dropping the ball' is a strong conclusion.
>
Apologies for using a term that you seem to take issue with. Are you
saying the spec currently recommends it?
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Will Deacon @ 2018-06-19 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-Mad64U63jjuKGjhg=h2wdoEKm2vywzATBYr-t_UY_bQ@mail.gmail.com>
On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
> On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
> > Hi Ard,
> >
> > Sorry, I forgot to reply to this.
> >
> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
> >> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
> >> >> To protect against KSMA(Kernel Space Mirroring Attack), make
> >> >> tramp_pg_dir read-only. The principle of KSMA is to insert a
> >> >> carefully constructed PGD entry into the translation table.
> >> >> The type of this entry is block, which maps the kernel text
> >> >> and its access permissions bits are 01. The user process can
> >> >> then modify kernel text directly through this mapping. In this
> >> >> way, an arbitrary write can be converted to multiple arbitrary
> >> >> writes.
> >> >>
> >> >> Signed-off-by: YaoJun <yaojun8558363@gmail.com>
> >> >> ---
> >> >> arch/arm64/mm/mmu.c | 4 ++++
> >> >> 1 file changed, 4 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
> >> >> --- a/arch/arm64/mm/mmu.c
> >> >> +++ b/arch/arm64/mm/mmu.c
> >> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
> >> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> >> >> prot, pgd_pgtable_alloc, 0);
> >> >>
> >> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
> >> >> + (unsigned long)tramp_pg_dir,
> >> >> + PGD_SIZE, PAGE_KERNEL_RO);
> >> >
> >> > Hmm, I like the idea but is there a risk that the page table has been mapped
> >> > as part of a block entry, which we can't safely split at this point (i.e.
> >> > we'll run into one of the BUG_ONs in the mapping code)?
> >> >
> >>
> >> We'd need to create a separate segment for it initially so the mapping
> >> is already at the right granularity.
> >
> > Why do you think that's the case? I can't see anything that guarantees this
> > for the page table itself.
> >
>
> We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
> obviously, but that shouldn't hurt since that segment is relatively
> tiny anyway.
Ah right, with NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS, I agree that we're good.
Ideally, we'd move {idmap,swapper,tramp}_pg_dir into .rodata...
Will
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Ard Biesheuvel @ 2018-06-19 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619152805.GN13984@arm.com>
On 19 June 2018 at 17:28, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
>> On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
>> > Hi Ard,
>> >
>> > Sorry, I forgot to reply to this.
>> >
>> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
>> >> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
>> >> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
>> >> >> To protect against KSMA(Kernel Space Mirroring Attack), make
>> >> >> tramp_pg_dir read-only. The principle of KSMA is to insert a
>> >> >> carefully constructed PGD entry into the translation table.
>> >> >> The type of this entry is block, which maps the kernel text
>> >> >> and its access permissions bits are 01. The user process can
>> >> >> then modify kernel text directly through this mapping. In this
>> >> >> way, an arbitrary write can be converted to multiple arbitrary
>> >> >> writes.
>> >> >>
>> >> >> Signed-off-by: YaoJun <yaojun8558363@gmail.com>
>> >> >> ---
>> >> >> arch/arm64/mm/mmu.c | 4 ++++
>> >> >> 1 file changed, 4 insertions(+)
>> >> >>
>> >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> >> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
>> >> >> --- a/arch/arm64/mm/mmu.c
>> >> >> +++ b/arch/arm64/mm/mmu.c
>> >> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
>> >> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
>> >> >> prot, pgd_pgtable_alloc, 0);
>> >> >>
>> >> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
>> >> >> + (unsigned long)tramp_pg_dir,
>> >> >> + PGD_SIZE, PAGE_KERNEL_RO);
>> >> >
>> >> > Hmm, I like the idea but is there a risk that the page table has been mapped
>> >> > as part of a block entry, which we can't safely split at this point (i.e.
>> >> > we'll run into one of the BUG_ONs in the mapping code)?
>> >> >
>> >>
>> >> We'd need to create a separate segment for it initially so the mapping
>> >> is already at the right granularity.
>> >
>> > Why do you think that's the case? I can't see anything that guarantees this
>> > for the page table itself.
>> >
>>
>> We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
>> obviously, but that shouldn't hurt since that segment is relatively
>> tiny anyway.
>
> Ah right, with NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS, I agree that we're good.
> Ideally, we'd move {idmap,swapper,tramp}_pg_dir into .rodata...
>
idmap and tramp yes, but swapper needs to be modifiable at runtime, no?
^ permalink raw reply
* [PATCH] clk: meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL
From: Jerome Brunet @ 2018-06-19 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528892771.2292.2.camel@baylibre.com>
On Wed, 2018-06-13 at 14:26 +0200, Jerome Brunet wrote:
> On Wed, 2018-06-13 at 14:20 +0200, Neil Armstrong wrote:
> > On Amlogic Meson GXBB & GXL platforms, the SCPI Cortex-M4 Co-Processor
> > seems to be dependent on the FCLK_DIV2 to be operationnal.
> >
> > The issue occured since v4.17-rc1 by freezing the kernel boot when
> > the 'schedutil' cpufreq governor was selected as default :
> >
> > [ 12.071837] scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version
> > domain-0 init dvfs: 4
> > [ 12.087757] hctosys: unable to open rtc device (rtc0)
> > [ 12.087907] cfg80211: Loading compiled-in X.509 certificates for regulatory database
> > [ 12.102241] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> >
> > But when disabling the MMC driver, the boot finished but cpufreq failed to
> > change the CPU frequency :
> >
> > [ 12.153045] cpufreq: __target_index: Failed to change cpu frequency: -5
> >
> > A bisect between v4.16 and v4.16-rc1 gave the 05f814402d61 commit to be
> > the first bad commit.
> > This commit added support for the missing clock gates before the fixed PLL
> > fixed dividers (FCLK_DIVx) and the clock framework basically disabled
> > all the unused fixed dividers, thus disabled a critical clock path for
> > the SCPI Co-Processor.
> >
> > This patch simply sets the FCLK_DIV2 gate as critical to ensure
> > nobody can disable it.
> >
> > Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates")
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> Good catch !
> We'll probably have to check the axg family as well
SCPI is not enabled on AXG at this time. We'll deal with it when the time comes.
patch applied.
Thx
^ permalink raw reply
* [PATCH v10 13/14] cpufreq: Add module to register cpufreq on Krait CPUs
From: Craig Tatlor @ 2018-06-19 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529415925-28915-14-git-send-email-sricharan@codeaurora.org>
The pvs refuse check is incorrect... With downstream it says it isn't
blown and that it is 11, which also happens on upstream if I import it's
efuse reading code from an older revision, or comment out the check.
Also, I'm still getting my issue about clocks above 2,147,483,647hz
however I think this may be related to the division in the hfpll driver
so I'll have a debug around there.
On Tue, Jun 19, 2018 at 07:15:24PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> Register a cpufreq-generic device whenever we detect that a
> "qcom,krait" compatible CPU is present in DT.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> [Sricharan: updated to use dev_pm_opp_set_prop_name and
> nvmem apis]
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> [Thierry Escande: update to add support for opp-supported-hw]
> Signed-off-by: Thierry Escande <thierry.escande@linaro.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> [v10] updated to add support for opp-supported-hw given by
> Thierry Escande <thierry.escande@linaro.org>
>
> drivers/cpufreq/Kconfig.arm | 10 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/cpufreq-dt-platdev.c | 5 +
> drivers/cpufreq/qcom-cpufreq.c | 201 +++++++++++++++++++++++++++++++++++
> 4 files changed, 217 insertions(+)
> create mode 100644 drivers/cpufreq/qcom-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 7f56fe5..87e5d8d 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -134,6 +134,16 @@ config ARM_OMAP2PLUS_CPUFREQ
> depends on ARCH_OMAP2PLUS
> default ARCH_OMAP2PLUS
>
> +config ARM_QCOM_CPUFREQ
> + bool "CPUfreq driver for the QCOM SoCs with KRAIT processors"
> + depends on ARCH_QCOM
> + select PM_OPP
> + help
> + This enables the CPUFreq driver for Qualcomm SoCs with
> + KRAIT processors.
> +
> + If in doubt, say N.
> +
> config ARM_S3C_CPUFREQ
> bool
> help
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 8d24ade..c591e1e 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
> obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
> obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
> +obj-$(CONFIG_ARM_QCOM_CPUFREQ) += qcom-cpufreq.o
> obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
> obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
> obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 3b585e4..e2e9a99 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -127,6 +127,11 @@
> { .compatible = "ti,am43", },
> { .compatible = "ti,dra7", },
>
> + { .compatible = "qcom,ipq8064", },
> + { .compatible = "qcom,apq8064", },
> + { .compatible = "qcom,msm8974", },
> + { .compatible = "qcom,msm8960", },
> +
> { }
> };
>
> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
> new file mode 100644
> index 0000000..1d4ab54
> --- /dev/null
> +++ b/drivers/cpufreq/qcom-cpufreq.c
> @@ -0,0 +1,201 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018, The Linux Foundation. All rights reserved.
> +
> +#include <linux/cpu.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
> +#include <linux/slab.h>
> +
> +static void __init get_krait_bin_format_a(int *speed, int *pvs, int *pvs_ver,
> + struct nvmem_cell *pvs_nvmem, u8 *buf)
> +{
> + u32 pte_efuse;
> +
> + pte_efuse = *((u32 *)buf);
> +
> + *speed = pte_efuse & 0xf;
> + if (*speed == 0xf)
> + *speed = (pte_efuse >> 4) & 0xf;
> +
> + if (*speed == 0xf) {
> + *speed = 0;
> + pr_warn("Speed bin: Defaulting to %d\n", *speed);
> + } else {
> + pr_info("Speed bin: %d\n", *speed);
> + }
> +
> + *pvs = (pte_efuse >> 10) & 0x7;
> + if (*pvs == 0x7)
> + *pvs = (pte_efuse >> 13) & 0x7;
> +
> + if (*pvs == 0x7) {
> + *pvs = 0;
> + pr_warn("PVS bin: Defaulting to %d\n", *pvs);
> + } else {
> + pr_info("PVS bin: %d\n", *pvs);
> + }
> +
> + kfree(buf);
> +}
> +
> +static void __init get_krait_bin_format_b(int *speed, int *pvs, int *pvs_ver,
> + struct nvmem_cell *pvs_nvmem, u8 *buf)
> +{
> + u32 pte_efuse, redundant_sel;
> +
> + pte_efuse = *((u32 *)buf);
> + redundant_sel = (pte_efuse >> 24) & 0x7;
> + *speed = pte_efuse & 0x7;
> +
> + /* 4 bits of PVS are in efuse register bits 31, 8-6. */
> + *pvs = ((pte_efuse >> 28) & 0x8) | ((pte_efuse >> 6) & 0x7);
> + *pvs_ver = (pte_efuse >> 4) & 0x3;
> +
> + switch (redundant_sel) {
> + case 1:
> + *speed = (pte_efuse >> 27) & 0xf;
> + break;
> + case 2:
> + *pvs = (pte_efuse >> 27) & 0xf;
> + break;
> + }
> +
> + /* Check SPEED_BIN_BLOW_STATUS */
> + if (pte_efuse & BIT(3)) {
> + pr_info("Speed bin: %d\n", *speed);
> + } else {
> + pr_warn("Speed bin not set. Defaulting to 0!\n");
> + *speed = 0;
> + }
> +
> + /* Check PVS_BLOW_STATUS */
> + pte_efuse = *(((u32 *)buf) + 4);
> + if (pte_efuse) {
> + pr_info("PVS bin: %d\n", *pvs);
> + } else {
> + pr_warn("PVS bin not set. Defaulting to 0!\n");
> + *pvs = 0;
> + }
> +
> + pr_info("PVS version: %d\n", *pvs_ver);
> + kfree(buf);
> +}
> +
> +static int __init qcom_cpufreq_populate_opps(struct nvmem_cell *pvs_nvmem,
> + struct opp_table **tbl1,
> + struct opp_table **tbl2)
> +{
> + int speed = 0, pvs = 0, pvs_ver = 0, cpu, ret;
> + struct device *cpu_dev;
> + u8 *buf;
> + size_t len;
> + char pvs_name[] = "speedXX-pvsXX-vXX";
> + u32 hw_version;
> +
> + buf = nvmem_cell_read(pvs_nvmem, &len);
> + if (len == 4)
> + get_krait_bin_format_a(&speed, &pvs, &pvs_ver, pvs_nvmem, buf);
> + else if (len == 8)
> + get_krait_bin_format_b(&speed, &pvs, &pvs_ver, pvs_nvmem, buf);
> + else
> + pr_warn("Unable to read nvmem data. Defaulting to 0!\n");
> +
> + snprintf(pvs_name, sizeof(pvs_name), "speed%d-pvs%d-v%d",
> + speed, pvs, pvs_ver);
> +
> + hw_version = (1 << speed);
> +
> + for (cpu = 0; cpu < num_possible_cpus(); cpu++) {
> + cpu_dev = get_cpu_device(cpu);
> + if (!cpu_dev)
> + return -ENODEV;
> +
> + tbl1[cpu] = dev_pm_opp_set_prop_name(cpu_dev, pvs_name);
> + if (IS_ERR(tbl1[cpu])) {
> + ret = PTR_ERR(tbl1[cpu]);
> + tbl1[cpu] = 0;
> + pr_warn("failed to add OPP name %s\n", pvs_name);
> + return ret;
> + }
> +
> + tbl2[cpu] = dev_pm_opp_set_supported_hw(cpu_dev, &hw_version,
> + 1);
> + if (IS_ERR(tbl2[cpu])) {
> + ret = PTR_ERR(tbl2[cpu]);
> + tbl2[cpu] = 0;
> + pr_warn("failed to set supported hw version\n");
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int __init qcom_cpufreq_driver_init(void)
> +{
> + struct platform_device *pdev;
> + struct device *cpu_dev;
> + struct device_node *np;
> + struct nvmem_cell *pvs_nvmem;
> + struct opp_table *tbl1[NR_CPUS] = { NULL }, *tbl2[NR_CPUS] = { NULL };
> + int ret, cpu = 0;
> +
> + cpu_dev = get_cpu_device(0);
> + if (!cpu_dev)
> + return -ENODEV;
> +
> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> + if (!np)
> + return -ENOENT;
> +
> + if (!of_device_is_compatible(np, "operating-points-v2-krait-cpu")) {
> + ret = -ENOENT;
> + goto free_np;
> + }
> +
> + pvs_nvmem = of_nvmem_cell_get(np, NULL);
> + if (IS_ERR(pvs_nvmem)) {
> + dev_err(cpu_dev, "Could not get nvmem cell\n");
> + ret = PTR_ERR(pvs_nvmem);
> + goto free_np;
> + }
> +
> + ret = qcom_cpufreq_populate_opps(pvs_nvmem, tbl1, tbl2);
> + if (ret)
> + goto free_opp_name;
> +
> + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> + if (IS_ERR(pdev)) {
> + ret = PTR_ERR(pdev);
> + goto free_opp_name;
> + }
> +
> + of_node_put(np);
> +
> + return 0;
> +
> +free_opp_name:
> + while (tbl1[cpu]) {
> + dev_pm_opp_put_prop_name(tbl1[cpu]);
> + cpu++;
> + }
> +
> + cpu = 0;
> + while (tbl2[cpu]) {
> + dev_pm_opp_put_supported_hw(tbl2[cpu]);
> + cpu++;
> + }
> +
> +free_np:
> + of_node_put(np);
> +
> + return ret;
> +}
> +late_initcall(qcom_cpufreq_driver_init);
> +
> +MODULE_DESCRIPTION("Qualcomm CPUfreq driver");
> +MODULE_AUTHOR("Stephen Boyd <sboyd@codeaurora.org>");
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
>
^ permalink raw reply
* [Dev] [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Ard Biesheuvel @ 2018-06-19 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuUZTHOuzQm3y-yF6cad9y1UgsK+6R2w7vSzz7MkkYCdYd3hA@mail.gmail.com>
On 19 June 2018 at 17:26, Yang Zhang <yang.zhang@96boards.org> wrote:
> Yes.
>
> https://github.com/96boards/documentation/blob/master/mezzanine/files/mezzanine-design-guidelines.pdf
>
> Under Configuration data section
>
OK, fair enough. Do any such mezzanines exist yet? Should we offer
more guidance on how exactly this discovery should be implemented?
> On 19 June 2018 at 16:25, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>
>> On 19 June 2018 at 17:14, Yang Zhang <yang.zhang@96boards.org> wrote:
>> >
>> >
>> > On 18 June 2018 at 14:22, Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> > wrote:
>> >>
>> >> On 18 June 2018 at 14:21, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > On Mon, Jun 18, 2018 at 9:45 AM, Linus Walleij
>> >> > <linus.walleij@linaro.org> wrote:
>> >> >> This is a proposal for how to handle the non-discoverable
>> >> >> 96boards plug-in expansion boards called "mezzanines" in the
>> >> >> Linux kernel. It is a working RFC series meant for discussion
>> >> >> at the moment.
>> >> >>
>> >> >> The RFC was done on the brand new Ultra96 board from Xilinx
>> >> >> with a Secure96 mezzanine expansion board. The main part
>> >> >> is in patch 4, the rest is enabling and examples.
>> >> >>
>> >> >> The code can be obtained from here:
>> >> >>
>> >> >>
>> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96
>> >> >>
>> >> >> You can for example probably augment the DTS file for any
>> >> >> upstream-supported 96board and get the Secure96 going with
>> >> >> it with minor efforts.
>> >> >
>> >> > Hi Linus,
>> >> >
>> >> > Thanks for your work on solving this long-standing problem. I've just
>> >> > read through your patches briefly and have a few thoughts:
>> >> >
>> >> > - I really like the idea of having C code deal with the mezzanine
>> >> > connector itself, acting as an intermediate to tie a number of
>> >> > boards to a number of add-on cards, this seems much simpler than
>> >> > trying to do everything with overlays or one of the other more
>> >> > generic mechanisms.
>> >> >
>> >> > - I don't like the idea of having the bus driver contain a list of
>> >> > possible
>> >> > add-ons, this seems to go against our usual driver model. What
>> >> > I think we want instead is to make the connector itself a proper
>> >> > bus_type, to allow drivers to register against it as loadable
>> >> > modules,
>> >> > and devices (maybe limited to one device) being created as probed
>> >> > from DT or some other method as you describe.
>> >> >
>> >> > - You export symbols in the mezzanine_* namespace, which I think
>> >> > is a bit too generic and should perhaps contain something related
>> >> > to 96boards in its name to make it less ambiguous. I suspect we
>> >> > would add a number of further connectors for hats, capes, lures
>> >> > etc,
>> >> > which could all be described as mezzanines. One open question
>> >> > is how we structure the commonality between the various
>> >> > connectors, but we can defer that until we have more than one
>> >> > or two of them.
>> >> >
>> >>
>> >> Hello all,
>> >>
>> >> We should also consider firmware use of the mezzanines. For instance,
>> >> the Secure96 has a RNG which UEFI may want to use so the early boot
>> >> code can access is for KASLR. It also has a TPM, which should not be
>> >> reset/reinitialized/etc by the OS if we want to make meaningful use of
>> >> it.
>> >>
>> >> Also, given that we can (and do) already describe topologies involving
>> >> mezzanines by ignoring the connector altogether (which is not entirely
>> >> unreasonable given the fact that we [as Linaro/96boards] dropped the
>> >> ball on this one and did not mandate discoverability for mezzanines).
>> >
>> >
>> > The design guideline has been reviewed by many inside/outside linaro
>> > through
>> > the mezzanine at lists.96boards.org and 96b-spec-sig
>> > <96b-spec-sig@96boards.org> published as recommended/strongly
>> > recommended
>> > item from day one. 'dropping the ball' is a strong conclusion.
>> >
>>
>> Apologies for using a term that you seem to take issue with. Are you
>> saying the spec currently recommends it?
>
>
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Punit Agrawal @ 2018-06-19 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619151425.GH13685@dhcp22.suse.cz>
Michal Hocko <mhocko@kernel.org> writes:
> On Tue 19-06-18 15:54:26, Punit Agrawal wrote:
> [...]
>> In terms of $SUBJECT, I wonder if it's worth taking the original patch
>> as a temporary fix (it'll also be easier to backport) while we work on
>> fixing these other issues and enabling memoryless nodes.
>
> Well, x86 already does that but copying this antipatern is not really
> nice. So it is good as a quick fix but it would be definitely much
> better to have a robust fix. Who knows how many other places might hit
> this. You certainly do not want to add a hack like this all over...
Completely agree! I was only suggesting it as a temporary measure,
especially as it looked like a proper fix might be invasive.
Another fix might be to change the node specific allocation to node
agnostic allocations. It isn't clear why the allocation is being
requested from a specific node. I think Lorenzo suggested this in one of
the threads.
I've started putting together a set fixing the issues identified in this
thread. It should give a better idea on the best course of action.
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Will Deacon @ 2018-06-19 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu81zgvcLd-N_MMENykxcm6ENvvfCuWOoMGsrfUf9Usy5g@mail.gmail.com>
On Tue, Jun 19, 2018 at 05:29:03PM +0200, Ard Biesheuvel wrote:
> On 19 June 2018 at 17:28, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
> >> On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
> >> > Hi Ard,
> >> >
> >> > Sorry, I forgot to reply to this.
> >> >
> >> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
> >> >> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
> >> >> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
> >> >> >> To protect against KSMA(Kernel Space Mirroring Attack), make
> >> >> >> tramp_pg_dir read-only. The principle of KSMA is to insert a
> >> >> >> carefully constructed PGD entry into the translation table.
> >> >> >> The type of this entry is block, which maps the kernel text
> >> >> >> and its access permissions bits are 01. The user process can
> >> >> >> then modify kernel text directly through this mapping. In this
> >> >> >> way, an arbitrary write can be converted to multiple arbitrary
> >> >> >> writes.
> >> >> >>
> >> >> >> Signed-off-by: YaoJun <yaojun8558363@gmail.com>
> >> >> >> ---
> >> >> >> arch/arm64/mm/mmu.c | 4 ++++
> >> >> >> 1 file changed, 4 insertions(+)
> >> >> >>
> >> >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> >> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
> >> >> >> --- a/arch/arm64/mm/mmu.c
> >> >> >> +++ b/arch/arm64/mm/mmu.c
> >> >> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
> >> >> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> >> >> >> prot, pgd_pgtable_alloc, 0);
> >> >> >>
> >> >> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
> >> >> >> + (unsigned long)tramp_pg_dir,
> >> >> >> + PGD_SIZE, PAGE_KERNEL_RO);
> >> >> >
> >> >> > Hmm, I like the idea but is there a risk that the page table has been mapped
> >> >> > as part of a block entry, which we can't safely split at this point (i.e.
> >> >> > we'll run into one of the BUG_ONs in the mapping code)?
> >> >> >
> >> >>
> >> >> We'd need to create a separate segment for it initially so the mapping
> >> >> is already at the right granularity.
> >> >
> >> > Why do you think that's the case? I can't see anything that guarantees this
> >> > for the page table itself.
> >> >
> >>
> >> We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
> >> obviously, but that shouldn't hurt since that segment is relatively
> >> tiny anyway.
> >
> > Ah right, with NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS, I agree that we're good.
> > Ideally, we'd move {idmap,swapper,tramp}_pg_dir into .rodata...
> >
>
> idmap and tramp yes, but swapper needs to be modifiable at runtime, no?
Right, but couldn't we swizzle the permissions in e.g. set_pmd? We could
even predicate that on a sanity check of the prot.
Will
^ permalink raw reply
* [PATCHv3 00/19] arm64: invoke syscalls with pt_regs
From: Mark Rutland @ 2018-06-19 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-1-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:51PM +0100, Mark Rutland wrote:
> This series reworks arm64's syscall handling to minimize the propagation
> of user-controlled register values into speculated code paths. As with
> x86 [1], a wrapper is generated for each syscall, which extracts the
> argument from a struct pt_regs. During kernel entry from userspace,
> registers are zeroed.
>
> The arm64 kernel code directly invokes some syscalls which the x86 code
> doesn't, so I've added ksys_* wrappers for these, following the x86
> example. The rest of the series is arm64-specific.
>
> I've pushed the series out to my arm64/syscall-regs branch [2] on
> kernel.org.
>
> Since v1 [3]:
> * Rebase atop of arm64 for-next/core (for SSBD conflicts)
> * Move ksys_personality logic into <linux/syscalls.h>
> * Move kcompat_sys_* wrappers to <linux/compat.h>
> * Fix scno bounds check to use unsigned comparison
> * Fix sve_user_reset() call in el0_svc_handler()
> * Add BUILD_BUG() to the !CONFIG_ARM64_SVE stubs
> * Accumulate acked-by / reviewed-by tags
>
> Since v2 [4]:
> * Rebase to v4.18-rc1
> * Take upper 32 RES0 bits of SCTLR_ELx into account
> * Accumulate acks
>
> Thanks,
> Mark.
>
> [1] https://lkml.kernel.org/r/20180330093720.6780-1-linux at dominikbrodowski.net
> [2] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
> [3] https://lkml.kernel.org/r/20180514094640.27569-1-mark.rutland at arm.com
> [4] https://lkml.kernel.org/r/20180601112441.37810-1-mark.rutland at arm.com
>
> Mark Rutland (19):
> arm64: consistently use unsigned long for thread flags
> arm64: move SCTLR_EL{1,2} assertions to <asm/sysreg.h>
> arm64: introduce sysreg_clear_set()
> arm64: kill config_sctlr_el1()
> arm64: kill change_cpacr()
> arm64: move sve_user_{enable,disable} to <asm/fpsimd.h>
> arm64: remove sigreturn wrappers
> arm64: convert raw syscall invocation to C
> arm64: convert syscall trace logic to C
> arm64: convert native/compat syscall entry to C
> arm64: don't reload GPRs after apply_ssbd
> arm64: zero GPRs upon entry from EL0
I realised that along with these two, we also no longer need to reload
the GPRs for entry tracking, so I've added the following to my local
copy of the series.
Mark.
---->8----
>From b47791fe74fce8bb48696ab0cdda48a9bae0e397 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Tue, 19 Jun 2018 12:49:54 +0100
Subject: [PATCH] arm64: don't restore GPRs when context tracking
Now that syscalls are invoked with pt_regs, we no longer need to ensure
that the argument regsiters are live in the entry assembly, and it's
fine to not restore them after context_tracking_user_exit() has
corrupted them.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/entry.S | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 39440c2ee66d..6b7789d72064 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -41,19 +41,9 @@
* Context tracking subsystem. Used to instrument transitions
* between user and kernel mode.
*/
- .macro ct_user_exit, syscall = 0
+ .macro ct_user_exit
#ifdef CONFIG_CONTEXT_TRACKING
bl context_tracking_user_exit
- .if \syscall == 1
- /*
- * Save/restore needed during syscalls. Restore syscall arguments from
- * the values already saved on stack during kernel_entry.
- */
- ldp x0, x1, [sp]
- ldp x2, x3, [sp, #S_X2]
- ldp x4, x5, [sp, #S_X4]
- ldp x6, x7, [sp, #S_X6]
- .endif
#endif
.endm
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Ard Biesheuvel @ 2018-06-19 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619153754.GO13984@arm.com>
On 19 June 2018 at 17:37, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jun 19, 2018 at 05:29:03PM +0200, Ard Biesheuvel wrote:
>> On 19 June 2018 at 17:28, Will Deacon <will.deacon@arm.com> wrote:
>> > On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
>> >> On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
>> >> > Hi Ard,
>> >> >
>> >> > Sorry, I forgot to reply to this.
>> >> >
>> >> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
>> >> >> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
>> >> >> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
>> >> >> >> To protect against KSMA(Kernel Space Mirroring Attack), make
>> >> >> >> tramp_pg_dir read-only. The principle of KSMA is to insert a
>> >> >> >> carefully constructed PGD entry into the translation table.
>> >> >> >> The type of this entry is block, which maps the kernel text
>> >> >> >> and its access permissions bits are 01. The user process can
>> >> >> >> then modify kernel text directly through this mapping. In this
>> >> >> >> way, an arbitrary write can be converted to multiple arbitrary
>> >> >> >> writes.
>> >> >> >>
>> >> >> >> Signed-off-by: YaoJun <yaojun8558363@gmail.com>
>> >> >> >> ---
>> >> >> >> arch/arm64/mm/mmu.c | 4 ++++
>> >> >> >> 1 file changed, 4 insertions(+)
>> >> >> >>
>> >> >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> >> >> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
>> >> >> >> --- a/arch/arm64/mm/mmu.c
>> >> >> >> +++ b/arch/arm64/mm/mmu.c
>> >> >> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
>> >> >> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
>> >> >> >> prot, pgd_pgtable_alloc, 0);
>> >> >> >>
>> >> >> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
>> >> >> >> + (unsigned long)tramp_pg_dir,
>> >> >> >> + PGD_SIZE, PAGE_KERNEL_RO);
>> >> >> >
>> >> >> > Hmm, I like the idea but is there a risk that the page table has been mapped
>> >> >> > as part of a block entry, which we can't safely split at this point (i.e.
>> >> >> > we'll run into one of the BUG_ONs in the mapping code)?
>> >> >> >
>> >> >>
>> >> >> We'd need to create a separate segment for it initially so the mapping
>> >> >> is already at the right granularity.
>> >> >
>> >> > Why do you think that's the case? I can't see anything that guarantees this
>> >> > for the page table itself.
>> >> >
>> >>
>> >> We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
>> >> obviously, but that shouldn't hurt since that segment is relatively
>> >> tiny anyway.
>> >
>> > Ah right, with NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS, I agree that we're good.
>> > Ideally, we'd move {idmap,swapper,tramp}_pg_dir into .rodata...
>> >
>>
>> idmap and tramp yes, but swapper needs to be modifiable at runtime, no?
>
> Right, but couldn't we swizzle the permissions in e.g. set_pmd? We could
> even predicate that on a sanity check of the prot.
>
Swizzle the permissions of the entire .rodata segment? That sounds
doable, but there is a whole class of data that belongs in this
category, and I think PaX/grsecurity had an API for that (but I don't
think anyone is upstreaming that yet). So let's not reinvent that
wheel for swapper_pg_dir only.
^ permalink raw reply
* [PATCHv3 13/19] kernel: add ksys_personality()
From: Catalin Marinas @ 2018-06-19 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-14-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:04PM +0100, Mark Rutland wrote:
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 73810808cdf2..14312d334345 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -80,6 +80,7 @@ union bpf_attr;
> #include <linux/unistd.h>
> #include <linux/quota.h>
> #include <linux/key.h>
> +#include <linux/personality.h>
> #include <trace/syscall.h>
>
> #ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
> @@ -1277,4 +1278,14 @@ static inline long ksys_truncate(const char __user *pathname, loff_t length)
> return do_sys_truncate(pathname, length);
> }
>
> +static inline unsigned int ksys_personality(unsigned int personality)
> +{
> + unsigned int old = current->personality;
> +
> + if (personality != 0xffffffff)
> + set_personality(personality);
> +
> + return old;
> +}
> +
> #endif
It looks like this is identical to sys_personality() in
kernel/exec_domain.c. Should you call ksys_personality() from there
directly (a few lines saved)?
--
Catalin
^ permalink raw reply
* [PATCHv3 15/19] arm64: remove in-kernel call to sys_personality()
From: Catalin Marinas @ 2018-06-19 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-16-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:06PM +0100, Mark Rutland wrote:
> With pt_regs syscall wrappers, the calling convention for
> sys_personality() will change. Use ksys_personality(), which is
> functionally equivalent.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCHv3 16/19] arm64: use {COMPAT, }SYSCALL_DEFINE0 for sigreturn
From: Catalin Marinas @ 2018-06-19 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-17-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:07PM +0100, Mark Rutland wrote:
> We don't currently annotate our various sigreturn functions as syscalls,
> as we need to do to use pt_regs syscall wrappers.
>
> Let's mark them as real syscalls.
>
> For compat_sys_sigreturn and compat_sys_rt_sigreturn, this changes the
> return type from int to long, matching the prototypes in sys32.c.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx53: Add 'ARM platform' node
From: Sebastian Reichel @ 2018-06-19 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529329939-14117-1-git-send-email-festevam@gmail.com>
Hi,
On Mon, Jun 18, 2018 at 10:52:17AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> As per the i.MX53 Reference Manual add an entry for the
> 'ARM platform' region in the device tree.
>
> This is needed for accessing the ARM_GPC register to set the
> DBGEN bit, so that the debug clocks can be turned on.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
-- Sebastian
> ---
> arch/arm/boot/dts/imx53.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index 1a7a7bb..a70fbf4 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -672,6 +672,11 @@
> status = "disabled";
> };
>
> + arm_platform: arm-platform at 63fa0000 {
> + compatible = "fsl,imx53-arm-plat", "fsl,imx51-arm-plat";
> + reg = <0x63fa0000 0x28>;
> + };
> +
> owire: owire at 63fa4000 {
> compatible = "fsl,imx53-owire", "fsl,imx21-owire";
> reg = <0x63fa4000 0x4000>;
> --
> 2.7.4
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/35578c63/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: dts: imx53: Add a label for the PMU node
From: Sebastian Reichel @ 2018-06-19 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529329939-14117-2-git-send-email-festevam@gmail.com>
Hi,
On Mon, Jun 18, 2018 at 10:52:18AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Add a label for the PMU node so that the board dts may be able to
> pass the 'secure-reg-access' property like this:
>
> &pmu {
> secure-reg-access;
> };
>
> This also makes it consistent with the PMU node in imx6qdl.dtsi
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
-- Sebastian
> arch/arm/boot/dts/imx53.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index a70fbf4..263bd39f 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -113,7 +113,7 @@
> };
> };
>
> - pmu {
> + pmu: pmu {
> compatible = "arm,cortex-a8-pmu";
> interrupt-parent = <&tzic>;
> interrupts = <77>;
> --
> 2.7.4
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/46dda09f/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Will Deacon @ 2018-06-19 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-x-e+M7_28m=zMeZ2=1p6DXWvu2L4K988jpfYjK+=JaA@mail.gmail.com>
On Tue, Jun 19, 2018 at 05:40:26PM +0200, Ard Biesheuvel wrote:
> On 19 June 2018 at 17:37, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Jun 19, 2018 at 05:29:03PM +0200, Ard Biesheuvel wrote:
> >> On 19 June 2018 at 17:28, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
> >> >> On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
> >> >> > Hi Ard,
> >> >> >
> >> >> > Sorry, I forgot to reply to this.
> >> >> >
> >> >> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
> >> >> >> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
> >> >> >> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
> >> >> >> >> To protect against KSMA(Kernel Space Mirroring Attack), make
> >> >> >> >> tramp_pg_dir read-only. The principle of KSMA is to insert a
> >> >> >> >> carefully constructed PGD entry into the translation table.
> >> >> >> >> The type of this entry is block, which maps the kernel text
> >> >> >> >> and its access permissions bits are 01. The user process can
> >> >> >> >> then modify kernel text directly through this mapping. In this
> >> >> >> >> way, an arbitrary write can be converted to multiple arbitrary
> >> >> >> >> writes.
> >> >> >> >>
> >> >> >> >> Signed-off-by: YaoJun <yaojun8558363@gmail.com>
> >> >> >> >> ---
> >> >> >> >> arch/arm64/mm/mmu.c | 4 ++++
> >> >> >> >> 1 file changed, 4 insertions(+)
> >> >> >> >>
> >> >> >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> >> >> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
> >> >> >> >> --- a/arch/arm64/mm/mmu.c
> >> >> >> >> +++ b/arch/arm64/mm/mmu.c
> >> >> >> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
> >> >> >> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> >> >> >> >> prot, pgd_pgtable_alloc, 0);
> >> >> >> >>
> >> >> >> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
> >> >> >> >> + (unsigned long)tramp_pg_dir,
> >> >> >> >> + PGD_SIZE, PAGE_KERNEL_RO);
> >> >> >> >
> >> >> >> > Hmm, I like the idea but is there a risk that the page table has been mapped
> >> >> >> > as part of a block entry, which we can't safely split at this point (i.e.
> >> >> >> > we'll run into one of the BUG_ONs in the mapping code)?
> >> >> >> >
> >> >> >>
> >> >> >> We'd need to create a separate segment for it initially so the mapping
> >> >> >> is already at the right granularity.
> >> >> >
> >> >> > Why do you think that's the case? I can't see anything that guarantees this
> >> >> > for the page table itself.
> >> >> >
> >> >>
> >> >> We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
> >> >> obviously, but that shouldn't hurt since that segment is relatively
> >> >> tiny anyway.
> >> >
> >> > Ah right, with NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS, I agree that we're good.
> >> > Ideally, we'd move {idmap,swapper,tramp}_pg_dir into .rodata...
> >> >
> >>
> >> idmap and tramp yes, but swapper needs to be modifiable at runtime, no?
> >
> > Right, but couldn't we swizzle the permissions in e.g. set_pmd? We could
> > even predicate that on a sanity check of the prot.
> >
>
> Swizzle the permissions of the entire .rodata segment? That sounds
> doable, but there is a whole class of data that belongs in this
> category, and I think PaX/grsecurity had an API for that (but I don't
> think anyone is upstreaming that yet). So let's not reinvent that
> wheel for swapper_pg_dir only.
I wasn't thinking of the whole .rodata segment -- just the page containing
the entry being modified, but ok. I was hoping to avoid getting involved
with the PaX/grsec stuff as it seems rather toxic from what I've seen.
Will
^ permalink raw reply
* [PATCHv3 17/19] arm64: use SYSCALL_DEFINE6() for mmap
From: Catalin Marinas @ 2018-06-19 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-18-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:08PM +0100, Mark Rutland wrote:
> We don't currently annotate our mmap implementation as a syscall, as we
> need to do to use pt_regs syscall wrappers.
>
> Let's mark it as a real syscall.
>
> There should be no functional change as a result of this patch.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 3/3] ARM: mx5: Set the DBGEN bit in ARM_GPC register
From: Sebastian Reichel @ 2018-06-19 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529329939-14117-3-git-send-email-festevam@gmail.com>
Hi,
On Mon, Jun 18, 2018 at 10:52:19AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> On i.MX51/i.MX53 it is necessery to set the DBGEN bit in
> ARM_GPC register in order to turn on the debug clocks.
>
> The DBGEN bit of ARM_GPC register has the following description
> in the i.MX53 Reference Manual:
>
> "This allows the user to manually activate clocks within the debug
> system. This register bit directly controls the platform's dbgen_out
> output signal which connects to the DAP_SYS to enable all debug clocks.
> Once enabled, the clocks cannot be disabled except by asserting the
> disable_trace input of the DAP_SYS."
>
> Based on a previous patch from Sebastian Reichel.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
-- Sebastian
> arch/arm/mach-imx/common.h | 1 +
> arch/arm/mach-imx/cpu-imx5.c | 38 ++++++++++++++++++++++++++++++++++++++
> arch/arm/mach-imx/mach-imx53.c | 2 ++
> 3 files changed, 41 insertions(+)
>
> diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
> index c8d68e9..db78329 100644
> --- a/arch/arm/mach-imx/common.h
> +++ b/arch/arm/mach-imx/common.h
> @@ -62,6 +62,7 @@ void imx_gpc_set_arm_power_up_timing(u32 sw2iso, u32 sw);
> void imx_gpc_set_arm_power_down_timing(u32 sw2iso, u32 sw);
> void imx25_pm_init(void);
> void imx27_pm_init(void);
> +void imx5_pmu_init(void);
>
> enum mxc_cpu_pwr_mode {
> WAIT_CLOCKED, /* wfi only */
> diff --git a/arch/arm/mach-imx/cpu-imx5.c b/arch/arm/mach-imx/cpu-imx5.c
> index 4f2d1c7..6c5a055 100644
> --- a/arch/arm/mach-imx/cpu-imx5.c
> +++ b/arch/arm/mach-imx/cpu-imx5.c
> @@ -117,3 +117,41 @@ int mx53_revision(void)
> return mx5_cpu_rev;
> }
> EXPORT_SYMBOL(mx53_revision);
> +
> +#define ARM_GPC 0x4
> +#define DBGEN BIT(16)
> +
> +/*
> + * This enables the DBGEN bit in ARM_GPC register, which is
> + * required for accessing some performance counter features.
> + * Technically it is only required while perf is used, but to
> + * keep the source code simple we just enable it all the time
> + * when the kernel configuration allows using the feature.
> + */
> +void imx5_pmu_init(void)
> +{
> + void __iomem *arm_plat_base;
> + struct device_node *np;
> + u32 gpc;
> +
> + if (!IS_ENABLED(CONFIG_ARM_PMU))
> + return;
> +
> + np = of_find_compatible_node(NULL, NULL, "arm,cortex-a8-pmu");
> + if (!np)
> + return;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx51-arm-plat");
> + if (!np)
> + return;
> +
> + arm_plat_base = of_iomap(np, 0);
> + if (!arm_plat_base) {
> + pr_warn("Unable to map ARM platform registers\n");
> + return;
> + }
> +
> + gpc = readl_relaxed(arm_plat_base + ARM_GPC);
> + gpc |= DBGEN;
> + writel_relaxed(gpc, arm_plat_base + ARM_GPC);
> +}
> diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
> index 07c2e8d..15fba89 100644
> --- a/arch/arm/mach-imx/mach-imx53.c
> +++ b/arch/arm/mach-imx/mach-imx53.c
> @@ -32,6 +32,8 @@ static void __init imx53_dt_init(void)
> {
> imx_src_init();
>
> + imx5_pmu_init();
> +
> imx_aips_allow_unprivileged_access("fsl,imx53-aipstz");
> }
>
> --
> 2.7.4
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/956e0d5d/attachment-0001.sig>
^ permalink raw reply
* [PATCHv3 18/19] arm64: convert compat wrappers to C
From: Catalin Marinas @ 2018-06-19 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-19-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:09PM +0100, Mark Rutland wrote:
> In preparation for converting to pt_regs syscall wrappers, convert our
> existing compat wrappers to C. This will allow the pt_regs wrappers to
> be automatically generated, and will allow for the compat register
> manipulation to be folded in with the pt_regs accesses.
>
> To avoid confusion with the upcoming pt_regs wrappers and existing
> compat wrappers provided by core code, the C wrappers are renamed to
> compat_sys_aarch32_<syscall>.
>
> With the assembly wrappers gone, we can get rid of entry32.S and the
> associated boilerplate.
>
> Note that these must call the ksys_* syscall entry points, as the usual
> sys_* entry points will be modified to take a single pt_regs pointer
> argument.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Ard Biesheuvel @ 2018-06-19 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619155001.GP13984@arm.com>
On 19 June 2018 at 17:50, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jun 19, 2018 at 05:40:26PM +0200, Ard Biesheuvel wrote:
>> On 19 June 2018 at 17:37, Will Deacon <will.deacon@arm.com> wrote:
>> > On Tue, Jun 19, 2018 at 05:29:03PM +0200, Ard Biesheuvel wrote:
>> >> On 19 June 2018 at 17:28, Will Deacon <will.deacon@arm.com> wrote:
>> >> > On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
>> >> >> On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
>> >> >> > Hi Ard,
>> >> >> >
>> >> >> > Sorry, I forgot to reply to this.
>> >> >> >
>> >> >> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
>> >> >> >> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
>> >> >> >> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
>> >> >> >> >> To protect against KSMA(Kernel Space Mirroring Attack), make
>> >> >> >> >> tramp_pg_dir read-only. The principle of KSMA is to insert a
>> >> >> >> >> carefully constructed PGD entry into the translation table.
>> >> >> >> >> The type of this entry is block, which maps the kernel text
>> >> >> >> >> and its access permissions bits are 01. The user process can
>> >> >> >> >> then modify kernel text directly through this mapping. In this
>> >> >> >> >> way, an arbitrary write can be converted to multiple arbitrary
>> >> >> >> >> writes.
>> >> >> >> >>
>> >> >> >> >> Signed-off-by: YaoJun <yaojun8558363@gmail.com>
>> >> >> >> >> ---
>> >> >> >> >> arch/arm64/mm/mmu.c | 4 ++++
>> >> >> >> >> 1 file changed, 4 insertions(+)
>> >> >> >> >>
>> >> >> >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> >> >> >> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
>> >> >> >> >> --- a/arch/arm64/mm/mmu.c
>> >> >> >> >> +++ b/arch/arm64/mm/mmu.c
>> >> >> >> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
>> >> >> >> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
>> >> >> >> >> prot, pgd_pgtable_alloc, 0);
>> >> >> >> >>
>> >> >> >> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
>> >> >> >> >> + (unsigned long)tramp_pg_dir,
>> >> >> >> >> + PGD_SIZE, PAGE_KERNEL_RO);
>> >> >> >> >
>> >> >> >> > Hmm, I like the idea but is there a risk that the page table has been mapped
>> >> >> >> > as part of a block entry, which we can't safely split at this point (i.e.
>> >> >> >> > we'll run into one of the BUG_ONs in the mapping code)?
>> >> >> >> >
>> >> >> >>
>> >> >> >> We'd need to create a separate segment for it initially so the mapping
>> >> >> >> is already at the right granularity.
>> >> >> >
>> >> >> > Why do you think that's the case? I can't see anything that guarantees this
>> >> >> > for the page table itself.
>> >> >> >
>> >> >>
>> >> >> We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
>> >> >> obviously, but that shouldn't hurt since that segment is relatively
>> >> >> tiny anyway.
>> >> >
>> >> > Ah right, with NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS, I agree that we're good.
>> >> > Ideally, we'd move {idmap,swapper,tramp}_pg_dir into .rodata...
>> >> >
>> >>
>> >> idmap and tramp yes, but swapper needs to be modifiable at runtime, no?
>> >
>> > Right, but couldn't we swizzle the permissions in e.g. set_pmd? We could
>> > even predicate that on a sanity check of the prot.
>> >
>>
>> Swizzle the permissions of the entire .rodata segment? That sounds
>> doable, but there is a whole class of data that belongs in this
>> category, and I think PaX/grsecurity had an API for that (but I don't
>> think anyone is upstreaming that yet). So let's not reinvent that
>> wheel for swapper_pg_dir only.
>
> I wasn't thinking of the whole .rodata segment -- just the page containing
> the entry being modified, but ok.
That means we will need to map .rodata down to pages as well, or at
least avoid contiguous mappings.
> I was hoping to avoid getting involved
> with the PaX/grsec stuff as it seems rather toxic from what I've seen.
>
Indeed.
^ permalink raw reply
* [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Rob Herring @ 2018-06-19 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
On Mon, Jun 18, 2018 at 1:45 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This is a proposal for how to handle the non-discoverable
> 96boards plug-in expansion boards called "mezzanines" in the
> Linux kernel. It is a working RFC series meant for discussion
> at the moment.
>
> The RFC was done on the brand new Ultra96 board from Xilinx
> with a Secure96 mezzanine expansion board. The main part
> is in patch 4, the rest is enabling and examples.
>
> The code can be obtained from here:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96
>
> You can for example probably augment the DTS file for any
> upstream-supported 96board and get the Secure96 going with
> it with minor efforts.
>
> TODO:
>
> - Proper device tree bindings for the connector, for now
> look at the example.
>
> - Discuss whether to actually do this or just take it all and
> flush it down the drain because the community doesn't like
> it. I'm not one of those especially infatuated with my own code,
> I always stay by the old programming project management mantra
> to calculate to make one version and throw it away as stepping
> stone to a good final design.
>
> - Placement: putting this in drivers/bus is just an example.
> drivers/platform/96boards-mezzanines is fine too, maybe better?
>
> - I am especially curious about input from Andy and Mika from
> the Intel/ACPI camp on what they have seen for non-discoverable
> plug-in boards. Does this problem even exist in the Intel
> world, or not...
>
> Background:
>
> - These boards connect on a custom connector on this family
> of boards. The relationship is many-to-many with the connector
> as nexus. The electronic standard for the connector is specified:
> https://github.com/96boards/documentation/blob/master/Specifications/96Boards-CE-Specification.pdf
> Example mezzanines:
> https://www.96boards.org/documentation/mezzanine/
>
> - These boards have siblings on other platforms, the problem
> scope is similar with BeagleBone "capes":
> https://beagleboard.org/capes
> Raspberry Pi expansion boards:
> https://www.abelectronics.co.uk/products/18/raspberry-pi-expansion-boards
> Intel Edison, Galileo, Joule also have expansion boards.
>
> Idea: add a driver for the connector itself and tie it in to
> the device tree with a compatible string. Since the boards
> are non-discoverable two mechanisms are provided to discover
> them:
>
> - Add a very simple device tree node with just a compatible
> string for the board in the node. This will be simple to
> add from e.g. a boot loader or as an overlay from userspace.
>
> board {
> compatible = "96boards,secure96";
> };
>
>
> - Echo 1 > boardname into a sysfs file to populate the
> board and echo 0 > boardname to depopulate it. This
> makes it easy to even switch out expansion boards at
> runtime, if allowed by the electronics.
>
> > cd /sys/devices/platform/connector
> > echo 1 > secure96
> lscon connector: called mezzanine_store on secure96
> lscon connector: populate secure96
> at24 1-0050: 2048 byte 24c128 EEPROM, writable, 128 bytes/write
> atmel-ecc 1-0060: configuration zone is unlocked
> tpm_tis_spi spi0.0: 2.0 TPM (device-id 0x1B, rev-id 16)
> (...)
>
> What this patch set does not do:
>
> - It does not use device tree or ACPI DSDT or any other
> hardware decription language to model the contents of the
> board per se. Instead the boards buses are populated
> directly with platform devices.
>
> Predictable complaints about this design:
>
> Q: This is not device tree overlays. Why is it not device
> tree overlays?
>
> A1: Right tool for the job, overlays are complex and the
> plan to get it in place seems to be spanning years, this
> is a few devices on simple busses and it works today.
> Using this approach I can already work on shaping up
> drivers for the mezzanine board devices as proved by:
> https://marc.info/?l=linux-crypto-vger&m=152820660120590&w=2
> https://marc.info/?l=linux-crypto-vger&m=152820662820595&w=2
> (...)
>
> I can work on drivers for the chips on the
> Secure96 mezzanine board. It's just an example of
> what the mezzanine community can do.
> Now they are hacking around in userspace instead of
> doing/reusing kernel drivers for their stuff:
> https://github.com/jbech-linaro/secure96
>
> This way we can bring developers for these components
> into the kernel community instead of telling them to
> wait for some big infrastructure that comes later
> before they can contribute their stuff.
>
> A2: Overlays does not solve the problem if the system runs
> ACPI, and what about if the same connector[s] appear
> on a server board, servers use ACPI. Also notice
> that Intel have development boards with non-discoverable
> expansion boards as well. They just will not use
> device tree.
>
> A3: Overlays is Big Upfront Design.
> https://en.wikipedia.org/wiki/Big_Design_Up_Front
> This way of designing things is associated with the
> (pejorative term) "waterfall model" which is out of
> fashion as a way of doing development. I think I am not
> the only one slightly annoyed by the fact that device
> tree overlays is now starting to look like a very
> big very upfront design. It's just not possible to get
> something up and running in small iterative steps with
> device tree overlays. Instead huge efforts are
> required and it involves major possible showstoppers
> and uncertain outcome as indicated by Frank's TODO:
> https://elinux.org/Frank's_Evolving_Overlay_Thoughts
I don't agree. This can be broken down into various smaller mostly
independent problems. Overlay handling is mostly an orthogonal
problem. The exception is that we need to ensure bindings allow a
decoupling of upstream of the connector and downstream of the
connector so the downstream part can be a reusable overlay. Defining
anything while ignoring this known criteria would be a mistake.
The list is roughly like this:
- Connector node binding and probing infrastructure
- GPIO (already done w/ gpio-map binding)
- I2C
- SPI
- Pinmux
- clocks
- OF graph (displays, cameras, etc.)
- USB (re-use the USB connector binding for non-standard connectors)
- Userspace interface
We don't have to support every interface from the start. The bindings
and corresponding kernel support can be designed 1-by-1 for the most
part. Start with something simple like a GPIO LED on a mezzanine. Once
the base is functionality is there, the other parts can be worked on
incrementally. We can punt any overlay handling to the bootloader
initially. That punts all the issues around overlays like designing a
userspace interface, where overlays are located (filesystem, passed
from bootloader, built into the kernel), when they are loaded, and how
to specify which overlays to load. Most of Frank's list is related to
these issues.
Rob
^ permalink raw reply
* [PATCHv3 13/19] kernel: add ksys_personality()
From: Mark Rutland @ 2018-06-19 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619154541.7uugqiquxzkcpfwj@armageddon.cambridge.arm.com>
On Tue, Jun 19, 2018 at 04:45:41PM +0100, Catalin Marinas wrote:
> On Mon, Jun 18, 2018 at 01:03:04PM +0100, Mark Rutland wrote:
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index 73810808cdf2..14312d334345 100644
> > --- a/include/linux/syscalls.h
> > +++ b/include/linux/syscalls.h
> > @@ -80,6 +80,7 @@ union bpf_attr;
> > #include <linux/unistd.h>
> > #include <linux/quota.h>
> > #include <linux/key.h>
> > +#include <linux/personality.h>
> > #include <trace/syscall.h>
> >
> > #ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
> > @@ -1277,4 +1278,14 @@ static inline long ksys_truncate(const char __user *pathname, loff_t length)
> > return do_sys_truncate(pathname, length);
> > }
> >
> > +static inline unsigned int ksys_personality(unsigned int personality)
> > +{
> > + unsigned int old = current->personality;
> > +
> > + if (personality != 0xffffffff)
> > + set_personality(personality);
> > +
> > + return old;
> > +}
> > +
> > #endif
>
> It looks like this is identical to sys_personality() in
> kernel/exec_domain.c. Should you call ksys_personality() from there
> directly (a few lines saved)?
I had originally done so [1], but Christophe preferred that I open-code
the logic [2].
Thanks,
Mark.
[1] https://lkml.kernel.org/r/20180514094640.27569-13-mark.rutland at arm.com
[2] https://lkml.kernel.org/r/20180514120756.GA11638 at infradead.org
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Will Deacon @ 2018-06-19 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-fA61TbOWOfMbwffyJEzMDKrOSOOw0nbNbeO-xm8YbaA@mail.gmail.com>
On Tue, Jun 19, 2018 at 05:51:46PM +0200, Ard Biesheuvel wrote:
> On 19 June 2018 at 17:50, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Jun 19, 2018 at 05:40:26PM +0200, Ard Biesheuvel wrote:
> >> On 19 June 2018 at 17:37, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Tue, Jun 19, 2018 at 05:29:03PM +0200, Ard Biesheuvel wrote:
> >> >> On 19 June 2018 at 17:28, Will Deacon <will.deacon@arm.com> wrote:
> >> >> > On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
> >> >> >> On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
> >> >> >> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
> >> >> >> >> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
> >> >> >> >> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
> >> >> >> >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> >> >> >> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
> >> >> >> >> >> --- a/arch/arm64/mm/mmu.c
> >> >> >> >> >> +++ b/arch/arm64/mm/mmu.c
> >> >> >> >> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
> >> >> >> >> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> >> >> >> >> >> prot, pgd_pgtable_alloc, 0);
> >> >> >> >> >>
> >> >> >> >> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
> >> >> >> >> >> + (unsigned long)tramp_pg_dir,
> >> >> >> >> >> + PGD_SIZE, PAGE_KERNEL_RO);
> >> >> >> >> >
> >> >> >> >> > Hmm, I like the idea but is there a risk that the page table has been mapped
> >> >> >> >> > as part of a block entry, which we can't safely split at this point (i.e.
> >> >> >> >> > we'll run into one of the BUG_ONs in the mapping code)?
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> We'd need to create a separate segment for it initially so the mapping
> >> >> >> >> is already at the right granularity.
> >> >> >> >
> >> >> >> > Why do you think that's the case? I can't see anything that guarantees this
> >> >> >> > for the page table itself.
> >> >> >> >
> >> >> >>
> >> >> >> We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
> >> >> >> obviously, but that shouldn't hurt since that segment is relatively
> >> >> >> tiny anyway.
> >> >> >
> >> >> > Ah right, with NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS, I agree that we're good.
> >> >> > Ideally, we'd move {idmap,swapper,tramp}_pg_dir into .rodata...
> >> >> >
> >> >>
> >> >> idmap and tramp yes, but swapper needs to be modifiable at runtime, no?
> >> >
> >> > Right, but couldn't we swizzle the permissions in e.g. set_pmd? We could
> >> > even predicate that on a sanity check of the prot.
> >> >
> >>
> >> Swizzle the permissions of the entire .rodata segment? That sounds
> >> doable, but there is a whole class of data that belongs in this
> >> category, and I think PaX/grsecurity had an API for that (but I don't
> >> think anyone is upstreaming that yet). So let's not reinvent that
> >> wheel for swapper_pg_dir only.
> >
> > I wasn't thinking of the whole .rodata segment -- just the page containing
> > the entry being modified, but ok.
>
> That means we will need to map .rodata down to pages as well, or at
> least avoid contiguous mappings.
Doesn't it already avoid those?
Will
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Ard Biesheuvel @ 2018-06-19 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619155512.GQ13984@arm.com>
On 19 June 2018 at 17:55, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jun 19, 2018 at 05:51:46PM +0200, Ard Biesheuvel wrote:
>> On 19 June 2018 at 17:50, Will Deacon <will.deacon@arm.com> wrote:
>> > On Tue, Jun 19, 2018 at 05:40:26PM +0200, Ard Biesheuvel wrote:
>> >> On 19 June 2018 at 17:37, Will Deacon <will.deacon@arm.com> wrote:
>> >> > On Tue, Jun 19, 2018 at 05:29:03PM +0200, Ard Biesheuvel wrote:
>> >> >> On 19 June 2018 at 17:28, Will Deacon <will.deacon@arm.com> wrote:
>> >> >> > On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
>> >> >> >> On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
>> >> >> >> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
>> >> >> >> >> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
>> >> >> >> >> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
>> >> >> >> >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> >> >> >> >> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
>> >> >> >> >> >> --- a/arch/arm64/mm/mmu.c
>> >> >> >> >> >> +++ b/arch/arm64/mm/mmu.c
>> >> >> >> >> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
>> >> >> >> >> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
>> >> >> >> >> >> prot, pgd_pgtable_alloc, 0);
>> >> >> >> >> >>
>> >> >> >> >> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
>> >> >> >> >> >> + (unsigned long)tramp_pg_dir,
>> >> >> >> >> >> + PGD_SIZE, PAGE_KERNEL_RO);
>> >> >> >> >> >
>> >> >> >> >> > Hmm, I like the idea but is there a risk that the page table has been mapped
>> >> >> >> >> > as part of a block entry, which we can't safely split at this point (i.e.
>> >> >> >> >> > we'll run into one of the BUG_ONs in the mapping code)?
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> We'd need to create a separate segment for it initially so the mapping
>> >> >> >> >> is already at the right granularity.
>> >> >> >> >
>> >> >> >> > Why do you think that's the case? I can't see anything that guarantees this
>> >> >> >> > for the page table itself.
>> >> >> >> >
>> >> >> >>
>> >> >> >> We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
>> >> >> >> obviously, but that shouldn't hurt since that segment is relatively
>> >> >> >> tiny anyway.
>> >> >> >
>> >> >> > Ah right, with NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS, I agree that we're good.
>> >> >> > Ideally, we'd move {idmap,swapper,tramp}_pg_dir into .rodata...
>> >> >> >
>> >> >>
>> >> >> idmap and tramp yes, but swapper needs to be modifiable at runtime, no?
>> >> >
>> >> > Right, but couldn't we swizzle the permissions in e.g. set_pmd? We could
>> >> > even predicate that on a sanity check of the prot.
>> >> >
>> >>
>> >> Swizzle the permissions of the entire .rodata segment? That sounds
>> >> doable, but there is a whole class of data that belongs in this
>> >> category, and I think PaX/grsecurity had an API for that (but I don't
>> >> think anyone is upstreaming that yet). So let's not reinvent that
>> >> wheel for swapper_pg_dir only.
>> >
>> > I wasn't thinking of the whole .rodata segment -- just the page containing
>> > the entry being modified, but ok.
>>
>> That means we will need to map .rodata down to pages as well, or at
>> least avoid contiguous mappings.
>
> Doesn't it already avoid those?
>
You are right, it does.
^ permalink raw reply
* [PATCH -tip v6 05/27] ARM: kprobes: Remove jprobe arm implementation
From: Masami Hiramatsu @ 2018-06-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152942424698.15209.15245996287444292393.stgit@devbox>
Remove arch dependent setjump/longjump functions
and unused fields in kprobe_ctlblk for jprobes
from arch/arm.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/include/asm/kprobes.h | 2 -
arch/arm/include/asm/probes.h | 1
arch/arm/probes/kprobes/core.c | 114 ----------------------------------------
3 files changed, 117 deletions(-)
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 59655459da59..82290f212d8e 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -44,8 +44,6 @@ struct prev_kprobe {
struct kprobe_ctlblk {
unsigned int kprobe_status;
struct prev_kprobe prev_kprobe;
- struct pt_regs jprobe_saved_regs;
- char jprobes_stack[MAX_STACK_SIZE];
};
void arch_remove_kprobe(struct kprobe *);
diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
index 1e5b9bb92270..991c9127c650 100644
--- a/arch/arm/include/asm/probes.h
+++ b/arch/arm/include/asm/probes.h
@@ -51,7 +51,6 @@ struct arch_probes_insn {
* We assume one instruction can consume at most 64 bytes stack, which is
* 'push {r0-r15}'. Instructions consume more or unknown stack space like
* 'str r0, [sp, #-80]' and 'str r0, [sp, r1]' should be prohibit to probe.
- * Both kprobe and jprobe use this macro.
*/
#define MAX_STACK_SIZE 64
diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index e90cc8a08186..23562111c511 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -47,9 +47,6 @@
(unsigned long)(addr) + \
(size))
-/* Used as a marker in ARM_pc to note when we're in a jprobe. */
-#define JPROBE_MAGIC_ADDR 0xffffffff
-
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
@@ -521,117 +518,6 @@ void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
regs->ARM_lr = (unsigned long)&kretprobe_trampoline;
}
-int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
-{
- struct jprobe *jp = container_of(p, struct jprobe, kp);
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
- long sp_addr = regs->ARM_sp;
- long cpsr;
-
- kcb->jprobe_saved_regs = *regs;
- memcpy(kcb->jprobes_stack, (void *)sp_addr, MIN_STACK_SIZE(sp_addr));
- regs->ARM_pc = (long)jp->entry;
-
- cpsr = regs->ARM_cpsr | PSR_I_BIT;
-#ifdef CONFIG_THUMB2_KERNEL
- /* Set correct Thumb state in cpsr */
- if (regs->ARM_pc & 1)
- cpsr |= PSR_T_BIT;
- else
- cpsr &= ~PSR_T_BIT;
-#endif
- regs->ARM_cpsr = cpsr;
-
- preempt_disable();
- return 1;
-}
-
-void __kprobes jprobe_return(void)
-{
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
-
- __asm__ __volatile__ (
- /*
- * Setup an empty pt_regs. Fill SP and PC fields as
- * they're needed by longjmp_break_handler.
- *
- * We allocate some slack between the original SP and start of
- * our fabricated regs. To be precise we want to have worst case
- * covered which is STMFD with all 16 regs so we allocate 2 *
- * sizeof(struct_pt_regs)).
- *
- * This is to prevent any simulated instruction from writing
- * over the regs when they are accessing the stack.
- */
-#ifdef CONFIG_THUMB2_KERNEL
- "sub r0, %0, %1 \n\t"
- "mov sp, r0 \n\t"
-#else
- "sub sp, %0, %1 \n\t"
-#endif
- "ldr r0, ="__stringify(JPROBE_MAGIC_ADDR)"\n\t"
- "str %0, [sp, %2] \n\t"
- "str r0, [sp, %3] \n\t"
- "mov r0, sp \n\t"
- "bl kprobe_handler \n\t"
-
- /*
- * Return to the context saved by setjmp_pre_handler
- * and restored by longjmp_break_handler.
- */
-#ifdef CONFIG_THUMB2_KERNEL
- "ldr lr, [sp, %2] \n\t" /* lr = saved sp */
- "ldrd r0, r1, [sp, %5] \n\t" /* r0,r1 = saved lr,pc */
- "ldr r2, [sp, %4] \n\t" /* r2 = saved psr */
- "stmdb lr!, {r0, r1, r2} \n\t" /* push saved lr and */
- /* rfe context */
- "ldmia sp, {r0 - r12} \n\t"
- "mov sp, lr \n\t"
- "ldr lr, [sp], #4 \n\t"
- "rfeia sp! \n\t"
-#else
- "ldr r0, [sp, %4] \n\t"
- "msr cpsr_cxsf, r0 \n\t"
- "ldmia sp, {r0 - pc} \n\t"
-#endif
- :
- : "r" (kcb->jprobe_saved_regs.ARM_sp),
- "I" (sizeof(struct pt_regs) * 2),
- "J" (offsetof(struct pt_regs, ARM_sp)),
- "J" (offsetof(struct pt_regs, ARM_pc)),
- "J" (offsetof(struct pt_regs, ARM_cpsr)),
- "J" (offsetof(struct pt_regs, ARM_lr))
- : "memory", "cc");
-}
-
-int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
-{
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
- long stack_addr = kcb->jprobe_saved_regs.ARM_sp;
- long orig_sp = regs->ARM_sp;
- struct jprobe *jp = container_of(p, struct jprobe, kp);
-
- if (regs->ARM_pc == JPROBE_MAGIC_ADDR) {
- if (orig_sp != stack_addr) {
- struct pt_regs *saved_regs =
- (struct pt_regs *)kcb->jprobe_saved_regs.ARM_sp;
- printk("current sp %lx does not match saved sp %lx\n",
- orig_sp, stack_addr);
- printk("Saved registers for jprobe %p\n", jp);
- show_regs(saved_regs);
- printk("Current registers\n");
- show_regs(regs);
- BUG();
- }
- *regs = kcb->jprobe_saved_regs;
- memcpy((void *)stack_addr, kcb->jprobes_stack,
- MIN_STACK_SIZE(stack_addr));
- preempt_enable_no_resched();
- return 1;
- }
- return 0;
-}
-
int __kprobes arch_trampoline_kprobe(struct kprobe *p)
{
return 0;
^ 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