* [GIT PULL 1/5] ARM: defconfig: exynos for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:49 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-5.4
for you to fetch changes up to 86759eeb32f70193ca7ebd50cc9b70ccb73d3d89:
ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in (2019-09-02 17:38:20 +0200)
----------------------------------------------------------------
Samsung defconfig changes for v5.4
1. Enable AHCI platform driver on exynos defconfig for Exynos5250-based
Arndale board,
2. Make Max77802 PMIC regulator driver a built-in on multi_v7 defconfig
as it is essential early during boot.
----------------------------------------------------------------
Marek Szyprowski (2):
ARM: exynos_defconfig: Enable AHCI-platform SATA driver
ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in
arch/arm/configs/exynos_defconfig | 5 ++++-
arch/arm/configs/multi_v7_defconfig | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/5] soc: samsung: Second pull for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:49 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit 40d8aff614f71ab3cab20785b4f213e3802d4e87:
soc: samsung: chipid: Convert exynos-chipid driver to use the regmap API (2019-08-15 20:25:25 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.4-2
for you to fetch changes up to 28578825ede61834a2c46e7f9a89012c4c7a667f:
soc: samsung: chipid: Select missing dependency for EXYNOS_CHIPID (2019-08-22 20:16:20 +0200)
----------------------------------------------------------------
Samsung soc drivers changes for v5.4, part 2
Fixes and cleanups for recently introduced Exynos chipid driver.
----------------------------------------------------------------
Colin Ian King (1):
soc: samsung: chipid: Fix memory leak in error path
Sylwester Nawrocki (2):
soc: samsung: chipid: Remove the regmap lookup error log
soc: samsung: chipid: Select missing dependency for EXYNOS_CHIPID
drivers/soc/samsung/Kconfig | 1 +
drivers/soc/samsung/exynos-chipid.c | 18 +++++++++++-------
2 files changed, 12 insertions(+), 7 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 3/5] ARM: dts: exynos: Second pull for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:50 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit bfb77169306d5d560a8b62eebaf6d69d02e8d152:
ARM: dts: exynos: Add CAM power domain to Exynos5422/5800 (2019-08-12 19:02:59 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.4-2
for you to fetch changes up to 51c88919e52873c83f8be0c8f5d0ffd654f1ef4a:
ARM: dts: exynos: Enable GPU/Mali T604 on Arndale board (2019-09-04 19:25:33 +0200)
----------------------------------------------------------------
Samsung DTS ARM changes for v5.4, part 2
1. Fix Exynos542x Chromebooks boot with multi_v7 defconfig,
2. Add GPU (Mali) support to Exynos5250 boards,
3. Minor cleanup for Exynos3250 ADC.
----------------------------------------------------------------
Guillaume Gardet (4):
ARM: dts: exynos: Fix min/max buck4 for GPU on Arndale board
ARM: dts: exynos: Add GPU/Mali T604 node to Exynos5250
ARM: dts: exynos: Enable GPU/Mali T604 on Chromebook Snow
ARM: dts: exynos: Enable GPU/Mali T604 on Arndale board
Krzysztof Kozlowski (1):
ARM: dts: exynos: Remove not accurate secondary ADC compatible
Marek Szyprowski (1):
ARM: dts: exynos: Mark LDO10 as always-on on Peach Pit/Pi Chromebooks
arch/arm/boot/dts/exynos3250.dtsi | 3 +-
arch/arm/boot/dts/exynos5250-arndale.dts | 9 +++--
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 5 +++
arch/arm/boot/dts/exynos5250.dtsi | 47 +++++++++++++++++++++++++++
arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 +
6 files changed, 62 insertions(+), 4 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 4/5] ARM: samsung: mach for v5.4, second (replacing previous)
From: Krzysztof Kozlowski @ 2019-09-04 17:50 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
Hi,
Replaces previous pull (and it includes it).
Best regards,
Krzysztof
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-5.4-2
for you to fetch changes up to c663d542bfb40eeeb6d393ed155c23a4666d65e1:
MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers (2019-08-22 21:04:45 +0200)
----------------------------------------------------------------
Samsung mach/soc changes for v5.4
1. Minor fixup in plat and mach code (S3C platforms),
2. Enable exynos-chipid driver to provide SoC related information,
3. Extend the patterns for Samsung maintainer entries to cover all
important files.
----------------------------------------------------------------
Krzysztof Kozlowski (1):
MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers
Linus Walleij (1):
ARM: samsung: Include GPIO driver header
Masahiro Yamada (1):
ARM: s3c64xx: squash samsung_usb_phy.h into setup-usb-phy.c
Pankaj Dubey (1):
ARM: exynos: Enable exynos-chipid driver
MAINTAINERS | 9 +++++++--
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-s3c64xx/setup-usb-phy.c | 5 +++++
arch/arm/plat-samsung/include/plat/gpio-core.h | 1 +
arch/arm/plat-samsung/include/plat/usb-phy.h | 2 --
include/linux/usb/samsung_usb_phy.h | 17 -----------------
6 files changed, 14 insertions(+), 21 deletions(-)
delete mode 100644 include/linux/usb/samsung_usb_phy.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] firmware: meson_sm: use %*ph to print small buffer
From: Andy Shevchenko @ 2019-09-04 17:48 UTC (permalink / raw)
To: Kevin Hilman, Neil Armstrong, linux-arm-kernel, linux-amlogic
Cc: Andy Shevchenko
Use %*ph format to print small buffer as hex string.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/firmware/meson/meson_sm.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/firmware/meson/meson_sm.c b/drivers/firmware/meson/meson_sm.c
index 8d908a8e0d20..8ea27af435da 100644
--- a/drivers/firmware/meson/meson_sm.c
+++ b/drivers/firmware/meson/meson_sm.c
@@ -231,19 +231,7 @@ static ssize_t serial_show(struct device *dev, struct device_attribute *attr,
return ret;
}
- ret = sprintf(buf, "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x\n",
- id_buf[SM_CHIP_ID_OFFSET + 0],
- id_buf[SM_CHIP_ID_OFFSET + 1],
- id_buf[SM_CHIP_ID_OFFSET + 2],
- id_buf[SM_CHIP_ID_OFFSET + 3],
- id_buf[SM_CHIP_ID_OFFSET + 4],
- id_buf[SM_CHIP_ID_OFFSET + 5],
- id_buf[SM_CHIP_ID_OFFSET + 6],
- id_buf[SM_CHIP_ID_OFFSET + 7],
- id_buf[SM_CHIP_ID_OFFSET + 8],
- id_buf[SM_CHIP_ID_OFFSET + 9],
- id_buf[SM_CHIP_ID_OFFSET + 10],
- id_buf[SM_CHIP_ID_OFFSET + 11]);
+ ret = sprintf(buf, "%12phN\n", &id_buf[SM_CHIP_ID_OFFSET]);
kfree(id_buf);
--
2.23.0.rc1
_______________________________________________
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 5/5] arm64: exynos: Enable exynos-chipid driver
From: Krzysztof Kozlowski @ 2019-09-04 17:50 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Bartlomiej Zolnierkiewicz, Pankaj Dubey,
linux-kernel, Krzysztof Kozlowski, Kukjin Kim, Sylwester Nawrocki,
linux-arm-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
From: Pankaj Dubey <pankaj.dubey@samsung.com>
Enable Exynos Chipid driver for accessing SoC related information.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4778c775de1b..8a098fb4f04c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -77,6 +77,7 @@ config ARCH_BRCMSTB
config ARCH_EXYNOS
bool "ARMv8 based Samsung Exynos SoC family"
select COMMON_CLK_SAMSUNG
+ select EXYNOS_CHIPID
select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
select EXYNOS_PMU
select HAVE_S3C2410_WATCHDOG if WATCHDOG
--
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
* Applied "ASoC: sirf-audio: use devm_platform_ioremap_resource() to simplify code" to the asoc tree
From: Mark Brown @ 2019-09-04 17:53 UTC (permalink / raw)
To: YueHaibing
Cc: kstewart, alsa-devel, linux-kernel, gregkh, tiwai, yuehaibing,
baohua, lgirdwood, Hulk Robot, Mark Brown, linux-arm-kernel,
pakki001, tglx, perex, allison
In-Reply-To: <20190904083412.18700-1-yuehaibing@huawei.com>
The patch
ASoC: sirf-audio: use devm_platform_ioremap_resource() to simplify code
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 2f302d476c960fdf8481399a46b8df92408d06e2 Mon Sep 17 00:00:00 2001
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 4 Sep 2019 16:34:12 +0800
Subject: [PATCH] ASoC: sirf-audio: use devm_platform_ioremap_resource() to
simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190904083412.18700-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/sirf-audio-codec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/codecs/sirf-audio-codec.c b/sound/soc/codecs/sirf-audio-codec.c
index 9009a7407b7a..a061d78473ac 100644
--- a/sound/soc/codecs/sirf-audio-codec.c
+++ b/sound/soc/codecs/sirf-audio-codec.c
@@ -459,7 +459,6 @@ static int sirf_audio_codec_driver_probe(struct platform_device *pdev)
int ret;
struct sirf_audio_codec *sirf_audio_codec;
void __iomem *base;
- struct resource *mem_res;
sirf_audio_codec = devm_kzalloc(&pdev->dev,
sizeof(struct sirf_audio_codec), GFP_KERNEL);
@@ -468,8 +467,7 @@ static int sirf_audio_codec_driver_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, sirf_audio_codec);
- mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, mem_res);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
2.20.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 1/1] KVM: inject data abort if instruction cannot be decoded
From: Heinrich Schuchardt @ 2019-09-04 18:07 UTC (permalink / raw)
To: Marc Zyngier
Cc: Peter Maydell, Daniel P . Berrangé, Suzuki K Pouloze,
Heinrich Schuchardt, Julien Thierry, linux-kernel, James Morse,
Stefan Hajnoczi, kvmarm, linux-arm-kernel
If an application tries to access memory that is not mapped, an error
ENOSYS, "load/store instruction decoding not implemented" may occur.
QEMU will hang with a register dump.
Instead create a data abort that can be handled gracefully by the
application running in the virtual environment.
Now the virtual machine can react to the event in the most appropriate
way - by recovering, by writing an informative log, or by rebooting.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
virt/kvm/arm/mmio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c
index a8a6a0c883f1..0cbed7d6a0f4 100644
--- a/virt/kvm/arm/mmio.c
+++ b/virt/kvm/arm/mmio.c
@@ -161,8 +161,8 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
if (ret)
return ret;
} else {
- kvm_err("load/store instruction decoding not implemented\n");
- return -ENOSYS;
+ kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
+ return 1;
}
rt = vcpu->arch.mmio_decode.rt;
--
2.23.0.rc1
_______________________________________________
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: [GIT PULL] i.MX clock changes for 5.4
From: Stephen Boyd @ 2019-09-04 18:13 UTC (permalink / raw)
To: Shawn Guo
Cc: Stefan Agner, linux-imx, kernel, Fabio Estevam, linux-clk,
linux-arm-kernel
In-Reply-To: <20190825115505.GA20454@X250>
Quoting Shawn Guo (2019-08-25 04:55:06)
> Hi Stephen,
>
> This is the i.MX clock changes I collected for 5.4. Please help pull,
> and keep commit 6ad7cb7122ce ("clk: imx8: Add DSP related clocks")
> stable, as I pulled it into my DT branch as dependency. Thanks!
>
> Shawn
>
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/clk-imx-5.4
>
> for you to fetch changes up to 760e548e7f885d89bf2dfab4838df9379edd19fc:
>
> clk: imx: imx8mn: fix audio pll setting (2019-08-24 21:04:27 +0200)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
_______________________________________________
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 1/1] soc: qcom: geni: Provide parameter error checking
From: Bjorn Andersson @ 2019-09-04 18:27 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-msm, agross, linux-kernel, linux-arm-kernel
In-Reply-To: <20190904084554.GF26880@dell>
On Wed 04 Sep 01:45 PDT 2019, Lee Jones wrote:
> On Tue, 03 Sep 2019, Bjorn Andersson wrote:
>
> > On Tue 03 Sep 06:50 PDT 2019, Lee Jones wrote:
> >
> > > When booting with ACPI, the Geni Serial Engine is not set as the I2C/SPI
> > > parent and thus, the wrapper (parent device) is unassigned. This causes
> > > the kernel to crash with a null dereference error.
> > >
> >
> > Now I see what you did in 8bc529b25354; i.e. stubbed all the other calls
> > between the SE and wrapper.
> >
> > Do you think it would be possible to resolve the _DEP link to QGP[01]
> > somehow?
>
> I looked at QGP{0,1}, but did not see it represented in the current
> Device Tree implementation and thus failed to identify it. Do you
> know what it is? Does it have a driver in Linux already?
>
QGP0 is the same hardware block as &qupv3_id_0, but apparently both are
only representing a smaller part - and different ones.
But conceptually both represents the wrapper...
> > For the clocks workarounds this could be resolved by us
> > representing that relationship using device_link and just rely on
> > pm_runtime to propagate the clock state.
>
> That is not allowed when booting ACPI. The Clock/Regulator frameworks
> are not to be used in this use-case, hence why all of the calls to
> these frameworks are "stubbed out". If we wanted to properly
> implement power management, we would have to create a driver/subsystem
> similar to the "Windows-compatible System Power Management Controller"
> (PEP). Without documentation for the PEP, this would be an impossible
> task. A request for the aforementioned documentation has been put in
> to Lenovo/Qualcomm. Hopefully something appears soon.
>
I see, so the PEP states needs to be parsed and associated with each
device and we would use pm_runtime to toggle between the states and
device_links to ensure that _DEP nodes are powered in appropriate order.
That seems reasonable and straight forward and the reliance on
pm_runtime will make the DT case cleaner as well.
> > For the DMA operation, iiuc it's the wrapper that implements the DMA
> > engine involved, but I'm guessing the main reason for mapping buffers on
> > the wrapper is so that it ends up being associated with the iommu
> > context of the wrapper.
>
> Judging by the code alone, the wrapper doesn't sound like it does much
> at all. It seems to only have a single (version) register (at least
> that is the only register that's used). The only registers it
> reads/writes are those of the calling device, whether that be I2C, SPI
> or UART.
>
> Device Tree represents the wrapper's relationship with the I2C (and
> SPI/UART) Serial Engine (SE) devices as parent-child ones, with the
> wrapper being the parent and SE the child. Whether this is a true
> representation of the hardware or just a tactic used for convenience
> is not clear, but the same representation does not exist in ACPI.
>
> In the current Linux implementation, the buffer belongs to the SE
> (obtained by the child (e.g. I2C) SE by fetching the parent's
> (wrapper's) device data using the standard platform helpers) but the
> register-set used to control the DMA transactions belong to the SE
> devices.
>
Yeah, I saw this as well. If all the SEs where the wrappers iommu domain
things should work fine by mapping it on the se->dev, regardless of the
device's being linked together.
The remaining relationship to the wrapper would then be reduced to the
read of the version to check for 1.0 or 1.1 hardware in the SPI driver,
which can be replaced by the assumption that we're on 1.1.
> > Are the SMMU contexts at all represented in the ACPI world and if so do
> > you know how the wrapper vs SEs are bound to contexts? Can we map on
> > se->dev when wrapper is NULL (or perhaps always?)?
>
> Yes, the SMMU devices are represented in ACPI (MMU0) and (MMU1). They
> share the same register addresses as the SMMU devices located in
> arch/arm64/boot/dts/qcom/sdm845.dtsi.
>
Right but this only describes the IOMMU devices, I don't see any
information about how individual client devices relates to the various
IOMMU contexts.
> With this simple parameter checking patch, the SE falls back to using
> FIFO mode to transmit data and continues to work flawlessly. IMHO
> this should be applied in the first instance, as it fixes a real (null
> dereference) bug which currently resides in the Mainline kernel.
>
Per the current driver design the wrapper device is the parent of the
SE, I should have seen that 8bc529b25354 was the beginning of a game of
whac-a-mole circumventing this design. Sorry for not spotting this
earlier.
But if this is the one whack left to get the thing to boot then I think
we should merge it.
> Moving forward we can try to come up with a suitable plan to implement
> DMA in the ACPI use-case - but again, this is feature adding work
> which should be carried out against -next, where as this patch needs
> to go in via the current -rcs ASAP.
>
Sounds good.
Regards,
Bjorn
> > > Fixes: 8bc529b25354 ("soc: qcom: geni: Add support for ACPI")
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > Since we are already at -rc7 this patch should be processed ASAP - thank you.
> > >
> > > drivers/soc/qcom/qcom-geni-se.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
> > > index d5cf953b4337..7d622ea1274e 100644
> > > --- a/drivers/soc/qcom/qcom-geni-se.c
> > > +++ b/drivers/soc/qcom/qcom-geni-se.c
> > > @@ -630,6 +630,9 @@ int geni_se_tx_dma_prep(struct geni_se *se, void *buf, size_t len,
> > > struct geni_wrapper *wrapper = se->wrapper;
> > > u32 val;
> > >
> > > + if (!wrapper)
> > > + return -EINVAL;
> > > +
> > > *iova = dma_map_single(wrapper->dev, buf, len, DMA_TO_DEVICE);
> > > if (dma_mapping_error(wrapper->dev, *iova))
> > > return -EIO;
> > > @@ -663,6 +666,9 @@ int geni_se_rx_dma_prep(struct geni_se *se, void *buf, size_t len,
> > > struct geni_wrapper *wrapper = se->wrapper;
> > > u32 val;
> > >
> > > + if (!wrapper)
> > > + return -EINVAL;
> > > +
> > > *iova = dma_map_single(wrapper->dev, buf, len, DMA_FROM_DEVICE);
> > > if (dma_mapping_error(wrapper->dev, *iova))
> > > return -EIO;
>
> --
> 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
* Re: [GIT PULL] SOC: TI soc updates for 5.4
From: Arnd Bergmann @ 2019-09-04 18:45 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Olof Johansson, arm-soc, linux-kernel@vger.kernel.org, Linux ARM,
Kevin Hilman
In-Reply-To: <3af4da24-2246-ff94-b83d-2b6ada4fc362@oracle.com>
On Wed, Sep 4, 2019 at 7:35 PM <santosh.shilimkar@oracle.com> wrote:
> On 9/4/19 6:13 AM, Arnd Bergmann wrote:
> > On Tue, Aug 27, 2019 at 5:12 AM Santosh Shilimkar
> >
> > Do you have any dependencies on -rc2 in your changes? If not,
> > could you please resubmit after rebasing? I can also just
> > cherry-pick those three commits if that's easier.
> >
> No dependencies. Can you please cherry pick them this time ?
> Will use rc1 for future pull request(s). Thanks !!
Ok, done.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
From: Ard Biesheuvel @ 2019-09-04 18:51 UTC (permalink / raw)
To: skodde; +Cc: Mark Rutland, linux-efi, linux-arm-kernel
In-Reply-To: <CAJrUJt-_B2DD3+538Ubq6s_3dyW3+EgFDY=RoLHBM8DUzJh_Fw@mail.gmail.com>
On Sat, 31 Aug 2019 at 10:20, skodde <skodde@gmail.com> wrote:
>
> On Thu, Aug 15, 2019 at 8:17 AM skodde <skodde@gmail.com> wrote:
> > On Thu, Aug 15, 2019 at 7:21 AM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > > On Thu, 15 Aug 2019 at 14:03, Mark Rutland <mark.rutland@arm.com> wrote:
> > > > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote:
> > > > > The kernel boots fine with that option disabled, but strangely
> > > > > presents the same error when disabling only CONFIG_RANDOMIZE_BASE.
> > > >
> > > > That shouldn't be possible, given the IS_ENABLED(CONFIG_RANDOMIZE_BASE)
> > > > guard around the efi_get_random_bytes() call, so something sounds wrong.
> > > >
> > > > Maybe there's a problem with stale objects. If you're not doing so
> > > > already, could you try a clean build with CONFIG_RANDOMIZE_BASE
> > > > deselected?
> > > >
> > > Also, can you try booting with the nokaslr command line option added?
> >
> > You were right, I haven't tried with nokaslr, but it worked fine by
> > rebuilding the kernel after a distclean with CONFIG_RANDOMIZE_BASE
> > disabled and CONFIG_GCC_PLUGIN_STACKLEAK enabled. That's what I was
> > expecting the first time and this is the reason why I mentioned it.
> > I've been recompiling too many times, sorry about that.
> >
> > Anyhow, the main issue is the efi_get_random_bytes() fail with
> > CONFIG_GCC_PLUGIN_STACKLEAK enabled, and that's still valid.
>
> Now the configuration that was working on 5.8 fails on 5.11 (haven't
> tried 5.9 or 5.10):
>
What do these version numbers mean? v5.8 vs v5.11??
> - CONFIG_GCC_PLUGIN_STACKLEAK=n && CONFIG_RANDOMIZE_BASE=y (working on 5.8)
>
> Loading Linux 5.2.11-00015-g0cc3335a89ac ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: ERROR: efi_get_random_bytes() failed
> EFI stub: ERROR: Failed to relocate kernel
To be honest, this looks like a firmware issue. Its implementation of
EFI_RNG_PROTOCOL is throwing an error.
I guess we could choose to handle this error more gracefully, but the
result above is the expected behavior when EFI_RNG_PROTOCOL throws an
error.
> Error: Image at 00079560000 start failed: Load Error
> Unloading driver at 0x00079560000
>
>
> - CONFIG_GCC_PLUGIN_STACKLEAK=n && CONFIG_RANDOMIZE_BASE=y && nokaslr
>
> Loading Linux 5.2.11-00015-g0cc3335a89ac ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: KASLR disabled on kernel command line
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> EFI stub: ERROR: Unable to construct new device tree.
> EFI stub: ERROR: Failed to update FDT and exit boot services
> Error: Image at 00079561000 start failed: Load Error
> Unloading driver at 0x00079561000
>
This looks unrelated. update_fdt() is faling, but we don't know why.
Could you add some debug prints at the various return sites to figure
out why it is failing?
>
> After getting back to the bootloader, loading a known working kernel
> fails (but it works fine after a reboot):
>
> Loading Linux 5.2.8-00016-ga0d5f389a536 ...
>
> Synchronous Exception at 0x00000000B652157C
> PC 0x0000B652157C
> PC 0x0000B65226B4
> PC 0x0000B6522EE0
> PC 0x0000B646BB10
> PC 0x0000B6468580
> PC 0x0000B6524600
> PC 0x0000B6420078
> PC 0x0000B6485CFC
> PC 0x0000B64849B4
> PC 0x0000B648586C
> PC 0x0000B64849B4
> PC 0x0000B6485E68
> PC 0x0000B6485EC0
> PC 0x0000B647C5C8
> PC 0x0000B647C2C8
> PC 0x0000B647C658
> PC 0x0000B647C2C8
> PC 0x0000B64784A8
> PC 0x0000B646F1FC
> PC 0x0000B6485CFC
> PC 0x0000B64849B4
> PC 0x0000B648586C
> PC 0x0000B64849B4
> PC 0x0000B6483C94
> PC 0x0000B64785A4
> PC 0x0000B6478794
> PC 0x0000B647880C
> PC 0x0000B652532C
> PC 0x00003F95B714 (0x00003F952000+0x00009714) [ 1] DxeCore.dll
> PC 0x0000B66CC440 (0x0000B66B9000+0x00013440) [ 2] UiApp.dll
> PC 0x0000B66CCD8C (0x0000B66B9000+0x00013D8C) [ 2] UiApp.dll
> PC 0x0000BF73D880 (0x0000BF729000+0x00014880) [ 3] SetupBrowser.dll
> PC 0x0000BF737BFC (0x0000BF729000+0x0000EBFC) [ 3] SetupBrowser.dll
> PC 0x0000B66C2700 (0x0000B66B9000+0x00009700) [ 4] UiApp.dll
> PC 0x00003F95B714 (0x00003F952000+0x00009714) [ 5] DxeCore.dll
> PC 0x0000BF71AEBC (0x0000BF711000+0x00009EBC) [ 6] BdsDxe.dll
> PC 0x0000BF721C8C (0x0000BF711000+0x00010C8C) [ 6] BdsDxe.dll
> PC 0x00003F95F470 (0x00003F952000+0x0000D470) [ 7] DxeCore.dll
> [ 1] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> [ 2] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
> [ 3] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe/DEBUG/SetupBrowser.dll
> [ 4] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
> [ 5] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> [ 6] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll
> [ 7] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>
> X0 0xAFAFAFAFAFAFAFAF X1 0x0000000000008000 X2
> 0xFFFFFFFFFFEFFFFF X3 0x0000000000008000
> X4 0x00000000B6530000 X5 0x00000000B652CAE0 X6
> 0x000000007B4FE000 X7 0x00000000B6468258
> X8 0x0000000000001000 X9 0x0000000000000002 X10
> 0xFFFFFFFFFFFFFFFF X11 0x00000000B648A182
> X12 0x00000000B6489FAC X13 0x00000000B648A15C X14
> 0x0000000000000014 X15 0x00000000000000FF
> X16 0x0000000000001510 X17 0x00000000B5A3AA40 X18
> 0x000000000000005C X19 0x0000000000000401
> X20 0x0000000000000001 X21 0x000000002D3C2808 X22
> 0x00000000B652CAB0 X23 0x000000006DB08FA4
> X24 0x0000000000000000 X25 0x000000007A96E000 X26
> 0x000000000000000F X27 0x0000000000000FFF
> X28 0x00000000B646B000 FP 0x000000003F950BD0 LR 0x00000000B65226B4
>
> V0 0x0000000000000000 4049C00000000000 V1 0x0000000000000000
> 3FE0000000000000
> V2 0x0000000000000000 40D1AD0000000000 V3 0xFFBFDFDF6FEFFFDF
> FFFFFFFFFFEFFED5
> V4 0xF7FFF5EF41FBEFFF FFFFBFFFFFFFFFBC V5 0xFFFFFFFFAFB8FFFB
> FFBFFFFFD7FFDDF6
> V6 0x8BFFB1B7FFFB7FFE F7EFFFFFFFFFFFFF V7 0x7BFFFFBF55FFD7D7
> FFFFFFFFDB7FFFFF
> V8 0x0000000000000000 FFFFFFFFFFDDFF9F V9 0x0000000000000000
> FFFEFBF3976793FF
> V10 0x0000000000000000 FFFFFFFFFF7FFFDF V11 0x0000000000000000
> F77FFEFDFFFFF3FF
> V12 0x0000000000000000 FFFFFFFF3D554FFF V13 0x0000000000000000
> FFFFFFFFBDE0EABF
> V14 0x0000000000000000 FFFFFFFFE7EEFFAD V15 0x0000000000000000
> FFDFFFFF7DFEFFFB
> V16 0xEEA8FDDFFFFFDFFF FFFFFFFFB7FE56FF V17 0xBF3B955BDBFFFFFF
> FFF7F9EFFFFFBFFF
> V18 0x7FBFFDEF7FEBFFAF FFFFFFBF8FEFFFDF V19 0xFEBFFF7FFFFDFFFF
> FFFFFFFFF5FF7DF5
> V20 0xFFFFFFFFFFFFFFFF FFFFFFFFC7ED54FF V21 0xF7FFFEEEFFFFFF7F
> DAFEFFDFFFF7FBF5
> V22 0xFBE6FFFFFFFFFFFF FFFFFFFFFFFFFFFF V23 0xFFF5FFFFFF7FFFFF
> FFFFFFFFFFFFFF7F
> V24 0xFFFFFFFF7FFEFFFF FFFFEF7FFFFFFFFF V25 0xEB8EFFF7FFFFF7FE
> FFFFFFFFFD7FFFFD
> V26 0x3FFFFDFFFFFF5FFF FFCF7EFFFFFFFFFF V27 0xAFBFFEF9FFFFFFFF
> DDFBBFFBBDC4BE5F
> V28 0xFFFFFFDFFFF7EFDF 9DCD7CF3FFFFFFCF V29 0xDFFFFFFFFFFFFFFF
> BAF7D6FE7FFFDFFF
> V30 0xDFF7FFFFFFBFFFFD FFFFDFFFFFFFFFFF V31 0xCA4F7F47DAF7DBFB
> FFFFFFFFFFF76E77
>
> SP 0x000000003F950BD0 ELR 0x00000000B652157C SPSR 0x60000209 FPSR
> 0x00000010
> ESR 0x96000004 FAR 0xAFAFAFAFAFAFAFBF
>
> ESR : EC 0x25 IL 0x1 ISS 0x00000004
>
> Data abort: Translation fault, zeroth level
>
> Stack dump:
> 000003F950AD0: 000000003F950C70 000000003F96454C FFFFFFFFFF7FFFDF
> 0000000000000000
> 000003F950AF0: 000000003F950C90 000000003F96454C 000000003F950B60
> 00000000BF6F9EAC
> 000003F950B10: 00000000B91B4398 00000000BE909498 000000003F950B30
> 000000003F95F5D4
> 000003F950B30: 000000003F950B60 000000003F960758 000000003F97407C
> 000000003F95F5D4
> 000003F950B50: 000000003F950B80 D7AB00003F960910 000000003F950B80
> 000000003F9612DC
> 000003F950B70: 000000004201DB9E 000000003F974078 000000003F950BA0
> 000000003F961364
> 000003F950B90: 000000003F974070 0000000000000000 000000003F950BD0
> 000000003F96323C
> 000003F950BB0: 000000003F950BD0 000000003F960B14 000000003F976618
> 000000007B50DFFF
> > 000003F950BD0: 000000003F950C10 00000000B65226B4 00000000B5A3E8A0 00000000B5A3E8A0
> 000003F950BF0: 0000000000000000 00000000000CEC80 0000000000000000
> 0000000000001000
> 000003F950C10: 000000003F950C70 00000000B6522EE0 00000000000CEC80
> 00000000B5A3E8A0
> 000003F950C30: 0000000000000000 0000000000001000 000000007A96E000
> 0000000000000000
> 000003F950C50: 0000000000007FFF 000000000000000F 0000000000001000
> 00000000B646B000
> 000003F950C70: 000000003F950CD0 00000000B646BB10 0000000000000000
> 0000000000000BA1
> 000003F950C90: 0000000000000000 00000000B5A3E8A0 000000007A96E000
> 0000000000000FFF
> 000003F950CB0: 0000000000BA0A00 0000000000000001 0000000000001000
> 000000003F95F5D4
> ASSERT [ArmCpuDxe]
> /home/skodde/macchiatobin/edk/uefi-marvell/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(271):
> ((BOOLEAN)(0==1))
>
>
> - CONFIG_GCC_PLUGIN_STACKLEAK=y && CONFIG_RANDOMIZE_BASE=n
>
> Loading Linux 5.2.11-00015-g0cc3335a89ac ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd081]
> [...]
>
> All good here.
>
> This time I did a distclean before each build.
>
>
> 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: next/master boot: 310 boots: 11 failed, 292 passed with 6 offline, 1 untried/unknown (next-20190904)
From: Mark Brown @ 2019-09-04 19:27 UTC (permalink / raw)
To: khilman, Matthias Brugger, linux-mediatek, linux-arm-kernel
Cc: kernel-build-reports
In-Reply-To: <5d700b15.1c69fb81.2abcd.479b@mx.google.com>
[-- Attachment #1.1: Type: text/plain, Size: 959 bytes --]
On Wed, Sep 04, 2019 at 12:05:57PM -0700, kernelci.org bot wrote:
Since 30th August -next fails to boot with no kernel output on
mt7622-rfb1:
> arm64:
> defconfig:
> gcc-8:
> mt7622-rfb1: 1 failed lab
>
> defconfig+CONFIG_RANDOMIZE_BASE=y:
> gcc-8:
> mt7622-rfb1: 1 failed lab
There's logging from ATF so it looks like we try to boot the kernel:
Starting kernel ...
[ATF][ 36.199793]save kernel info
[ATF][ 36.202824]Kernel_EL2
[ATF][ 36.205580]Kernel is 64Bit
[ATF][ 36.208768]pc=0x40080000, r0=0x5cf48000, r1=0x0
INFO: BL3-1: Preparing for EL3 exit to normal world, Kernel
INFO: BL3-1: Next image address = 0x40080000
INFO: BL3-1: Next image spsr = 0x3c9
[ATF][ 36.227037]el3_exit
but no output. More details including full logs at:
https://kernelci.org/boot/id/5d6fe70059b514164ef1224d/
https://kernelci.org/boot/id/5d6fe6e259b514164ef12243/
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.
From: Mathieu Poirier @ 2019-09-04 19:47 UTC (permalink / raw)
To: Greg KH
Cc: Jon Corbet, Coresight ML, open list:DOCUMENTATION,
linux-arm-kernel, Suzuki K. Poulose, Mike Leach
In-Reply-To: <20190904161737.GA20662@kroah.com>
On Wed, 4 Sep 2019 at 10:17, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Sep 04, 2019 at 10:05:51AM -0600, Mathieu Poirier wrote:
> > On Tue, 3 Sep 2019 at 23:48, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Sep 03, 2019 at 04:51:40PM -0600, Mathieu Poirier wrote:
> > > > On Tue, 3 Sep 2019 at 13:59, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Thu, Aug 29, 2019 at 10:33:19PM +0100, Mike Leach wrote:
> > > > > > Update document to include the new sysfs features added during this
> > > > > > patchset.
> > > > > >
> > > > > > Updated to reflect the new sysfs component nameing schema.
> > > > > >
> > > > > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > > > > ---
> > > > > > .../testing/sysfs-bus-coresight-devices-etm4x | 183 +++++++++++-------
> > > > > > 1 file changed, 115 insertions(+), 68 deletions(-)
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > > index 36258bc1b473..112c50ae9986 100644
> > > > > > --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > > @@ -1,4 +1,4 @@
> > > > > > -What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
> > > > > > +What: /sys/bus/coresight/devices/etm<N>/enable_source
> > > > >
> > > > > You are renaming sysfs directories that have been around since:
> > > > >
> > > > > > Date: April 2015
> > > > >
> > > > > ???
> > > > >
> > > > > Really?
> > > > >
> > > > > That's brave.
> > > >
> > > >
> > > > When I worked on the coresight sysfs ABI a while back I specifically
> > > > added it at the "testing" level as I was well aware that things could
> > > > change in the future. According to the guidelines in the
> > > > documentation userspace can rely on it which was accurate since the
> > > > interface didn't change for 4 years. But the guidelines also mention
> > > > that changes can occur before the interfaces are move to stables, and
> > > > that programs are encouraged to manifest their interest by adding
> > > > their name to the "users" field.
> > > >
> > > > The interface was changed in 5.2 to support coresight from ACPI and
> > > > make things easier to understand for users. It is a lot more
> > > > intuitive to associate an ETM tracer with the CPU it belongs to by
> > > > referring to the CPU number than the memory mapped address. Given the
> > > > "testing" status of the interface and the absence of registered users
> > > > I decided to move forward with the change. If "testing" is too strict
> > > > for that I suggest to add an "experimental" category where it would be
> > > > more acceptable to change things as subsystems mature.
> > >
> > > "testing" is not really "testing" if you have userspace tools/programs
> > > assuming the location and contents of specific files in sysfs.
> > >
> > > You can change things in sysfs by creating new files, but to do
> > > wholesale renaming like you did here can be very dangerous as you might
> > > be breaking things.
> >
> > Yes, something I have definitely considered.
> >
> > > Usually new files are created, not existing ones
> > > moved.
> >
> > In this case it would have meant a new symbolic link for every
> > coresight device, so twice a many entries under
> > $(SYS)/bus/coresight/device/. That would have been a lot of clutter
> > and an increasing source of problems as the number of CPU and sinks
> > increases. To me, and given the permissive definition of "testing"
> > found in the documentation, a clean break was a better option.
>
> Well, "testing" doesn't really matter in the end, if a tool/user relies
> on it, we have to keep it working properly.
>
> > > What tools use these today? What is going to break?
> >
> > Other than local shell scripts I am not aware of any tools using these
> > today. I am certainly open to discuss a better alternative but right
> > now, I just don't see one.
>
> Be aware that you might have to change this back if there is any
> objections.
>
We have an agreement.
Regards,
Mathieu
_______________________________________________
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 1/1] soc: qcom: geni: Provide parameter error checking
From: Lee Jones @ 2019-09-04 20:01 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: linux-arm-msm, agross, linux-kernel, linux-arm-kernel
In-Reply-To: <20190904182732.GE574@tuxbook-pro>
On Wed, 04 Sep 2019, Bjorn Andersson wrote:
> On Wed 04 Sep 01:45 PDT 2019, Lee Jones wrote:
>
> > On Tue, 03 Sep 2019, Bjorn Andersson wrote:
> >
> > > On Tue 03 Sep 06:50 PDT 2019, Lee Jones wrote:
> > >
> > > > When booting with ACPI, the Geni Serial Engine is not set as the I2C/SPI
> > > > parent and thus, the wrapper (parent device) is unassigned. This causes
> > > > the kernel to crash with a null dereference error.
> > > >
> > >
> > > Now I see what you did in 8bc529b25354; i.e. stubbed all the other calls
> > > between the SE and wrapper.
> > >
> > > Do you think it would be possible to resolve the _DEP link to QGP[01]
> > > somehow?
> >
> > I looked at QGP{0,1}, but did not see it represented in the current
> > Device Tree implementation and thus failed to identify it. Do you
> > know what it is? Does it have a driver in Linux already?
>
> QGP0 is the same hardware block as &qupv3_id_0, but apparently both are
> only representing a smaller part - and different ones.
>
> But conceptually both represents the wrapper...
... which doesn't actually do anything in the Linux implementation.
It only has one register. :)
> > > For the clocks workarounds this could be resolved by us
> > > representing that relationship using device_link and just rely on
> > > pm_runtime to propagate the clock state.
> >
> > That is not allowed when booting ACPI. The Clock/Regulator frameworks
> > are not to be used in this use-case, hence why all of the calls to
> > these frameworks are "stubbed out". If we wanted to properly
> > implement power management, we would have to create a driver/subsystem
> > similar to the "Windows-compatible System Power Management Controller"
> > (PEP). Without documentation for the PEP, this would be an impossible
> > task. A request for the aforementioned documentation has been put in
> > to Lenovo/Qualcomm. Hopefully something appears soon.
> >
>
> I see, so the PEP states needs to be parsed and associated with each
> device and we would use pm_runtime to toggle between the states and
> device_links to ensure that _DEP nodes are powered in appropriate order.
>
> That seems reasonable and straight forward and the reliance on
> pm_runtime will make the DT case cleaner as well.
Essentially yes. The issue is translating the ACPI tables into
actions to be taken by the Linux Power Management APIs. Again, we've
requested documentation. Now, we wait ...
> > > For the DMA operation, iiuc it's the wrapper that implements the DMA
> > > engine involved, but I'm guessing the main reason for mapping buffers on
> > > the wrapper is so that it ends up being associated with the iommu
> > > context of the wrapper.
> >
> > Judging by the code alone, the wrapper doesn't sound like it does much
> > at all. It seems to only have a single (version) register (at least
> > that is the only register that's used). The only registers it
> > reads/writes are those of the calling device, whether that be I2C, SPI
> > or UART.
> >
> > Device Tree represents the wrapper's relationship with the I2C (and
> > SPI/UART) Serial Engine (SE) devices as parent-child ones, with the
> > wrapper being the parent and SE the child. Whether this is a true
> > representation of the hardware or just a tactic used for convenience
> > is not clear, but the same representation does not exist in ACPI.
> >
> > In the current Linux implementation, the buffer belongs to the SE
> > (obtained by the child (e.g. I2C) SE by fetching the parent's
> > (wrapper's) device data using the standard platform helpers) but the
> > register-set used to control the DMA transactions belong to the SE
> > devices.
> >
>
> Yeah, I saw this as well. If all the SEs where the wrappers iommu domain
> things should work fine by mapping it on the se->dev, regardless of the
> device's being linked together.
This is my assumption too.
> The remaining relationship to the wrapper would then be reduced to the
> read of the version to check for 1.0 or 1.1 hardware in the SPI driver,
> which can be replaced by the assumption that we're on 1.1.
Also correct. You would be left with a huge duplication of code
across each of the SEs however.
> > > Are the SMMU contexts at all represented in the ACPI world and if so do
> > > you know how the wrapper vs SEs are bound to contexts? Can we map on
> > > se->dev when wrapper is NULL (or perhaps always?)?
> >
> > Yes, the SMMU devices are represented in ACPI (MMU0) and (MMU1). They
> > share the same register addresses as the SMMU devices located in
> > arch/arm64/boot/dts/qcom/sdm845.dtsi.
>
> Right but this only describes the IOMMU devices, I don't see any
> information about how individual client devices relates to the various
> IOMMU contexts.
I see some _DEPs which detail the MMU{0,1}, but that's about it.
> > With this simple parameter checking patch, the SE falls back to using
> > FIFO mode to transmit data and continues to work flawlessly. IMHO
> > this should be applied in the first instance, as it fixes a real (null
> > dereference) bug which currently resides in the Mainline kernel.
> >
>
> Per the current driver design the wrapper device is the parent of the
> SE, I should have seen that 8bc529b25354 was the beginning of a game of
> whac-a-mole circumventing this design. Sorry for not spotting this
> earlier.
Right, but that doesn't mean that the current driver design is
correct. ACPI, which is in theory a description of the hardware
doesn't seem to think so. It looks more like we do this in Linux as a
convenience function to link the devices. Instead this 'parent' seems
to be represented as a very small register space at the end of the SE
banks.
> But if this is the one whack left to get the thing to boot then I think
> we should merge it.
Amazing, thank you!
Do you know how we go about getting this merged? We only potentially
have 0.5 weeks (1.5 weeks if there is an -rc8 [doubtful]), so we need
to move fast. Would you be prepared to send it to Linus for -fixes?
I'd do it myself, but this is a little out of my remit.
Nothing heard from Andy for a very long time.
> > Moving forward we can try to come up with a suitable plan to implement
> > DMA in the ACPI use-case - but again, this is feature adding work
> > which should be carried out against -next, where as this patch needs
> > to go in via the current -rcs ASAP.
>
> Sounds good.
Great.
--
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
* Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Gerald Schaefer @ 2019-09-04 20:16 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, linux-arm-kernel, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Dan Williams,
Vlastimil Babka, Sri Krishna chowdary, Ard Biesheuvel,
Greg Kroah-Hartman, linux-mips, Ralf Baechle, linux-kernel,
Paul Burton, Mike Rapoport, Vineet Gupta, Martin Schwidefsky,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com>
On Tue, 3 Sep 2019 13:31:46 +0530
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
> page table helpers or addition of new ones.
>
> Test page table and memory pages creating it's entries at various level are
> all allocated from system memory with required alignments. If memory pages
> with required size and alignment could not be allocated, then all depending
> individual tests are skipped.
This looks very useful, thanks. Of course, s390 is quite special and does
not work nicely with this patch (yet), mostly because of our dynamic page
table levels/folding. Still need to figure out what can be fixed in the arch
code and what would need to be changed in the test module. See below for some
generic comments/questions.
At least one real bug in the s390 code was already revealed by this, which
is very nice. In pmd/pud_bad(), we also check large pmds/puds for sanity,
instead of reporting them as bad, which is apparently not how it is expected.
[...]
> +/*
> + * Basic operations
> + *
> + * mkold(entry) = An old and not a young entry
> + * mkyoung(entry) = A young and not an old entry
> + * mkdirty(entry) = A dirty and not a clean entry
> + * mkclean(entry) = A clean and not a dirty entry
> + * mkwrite(entry) = A write and not a write protected entry
> + * wrprotect(entry) = A write protected and not a write entry
> + * pxx_bad(entry) = A mapped and non-table entry
> + * pxx_same(entry1, entry2) = Both entries hold the exact same value
> + */
> +#define VADDR_TEST (PGDIR_SIZE + PUD_SIZE + PMD_SIZE + PAGE_SIZE)
Why is P4D_SIZE missing in the VADDR_TEST calculation?
[...]
> +
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> +static void pud_clear_tests(pud_t *pudp)
> +{
> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
> + pud_clear(pudp);
> + WARN_ON(!pud_none(READ_ONCE(*pudp)));
> +}
For pgd/p4d/pud_clear(), we only clear if the page table level is present
and not folded. The memset() here overwrites the table type bits, so
pud_clear() will not clear anything on s390 and the pud_none() check will
fail.
Would it be possible to OR a (larger) random value into the table, so that
the lower 12 bits would be preserved?
> +
> +static void pud_populate_tests(struct mm_struct *mm, pud_t *pudp, pmd_t *pmdp)
> +{
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pud_bad().
> + */
> + pmd_clear(pmdp);
> + pud_clear(pudp);
> + pud_populate(mm, pudp, pmdp);
> + WARN_ON(pud_bad(READ_ONCE(*pudp)));
> +}
This will populate the pud with a pmd pointer that does not point to the
beginning of the pmd table, but to the second entry (because of how
VADDR_TEST is constructed). This will result in failing pud_bad() check
on s390. Not sure why/how it works on other archs, but would it be possible
to align pmdp down to the beginning of the pmd table (and similar for the
other pxd_populate_tests)?
[...]
> +
> + p4d_free(mm, saved_p4dp);
> + pud_free(mm, saved_pudp);
> + pmd_free(mm, saved_pmdp);
> + pte_free(mm, (pgtable_t) virt_to_page(saved_ptep));
pgtable_t is arch-specific, and on s390 it is not a struct page pointer,
but a pte pointer. So this will go wrong, also on all other archs (if any)
where pgtable_t is not struct page.
Would it be possible to use pte_free_kernel() instead, and just pass
saved_ptep directly?
Regards,
Gerald
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/3] Broadcom defconfig-arm64 changes for 5.4
From: Arnd Bergmann @ 2019-09-04 20:19 UTC (permalink / raw)
To: Stefan Wahren
Cc: Stefan Wahren, Florian Fainelli, Kevin Hilman, arm-soc,
bcm-kernel-feedback-list, Linux ARM, Olof Johansson,
Nicolas Saenz Julienne
In-Reply-To: <4fd4b848-669d-00c5-144b-deab7a62a263@gmx.net>
On Wed, Sep 4, 2019 at 7:06 PM Stefan Wahren <wahrenst@gmx.net> wrote:
> Am 04.09.19 um 15:02 schrieb Arnd Bergmann:
> > On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
> >>
> >> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
> >>
> >> are available in the Git repository at:
> >>
> >> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig-arm64
> >>
> >> for you to fetch changes up to d6cc9ddd23f8b113797152896462b27e2b213ece:
> >>
> >> Merge tag 'tags/bcm2835-defconfig-64-next-2019-08-15' into defconfig-arm64/next (2019-08-15 11:38:29 -0700)
> >>
> >> ----------------------------------------------------------------
> >> This pull request contains Broadcom ARM64-based SoCs defconfig updates
> >> for 5.4, please pull the following:
> >>
> >> - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file
> > Pulled into arm/defconfig.
> >
> > The way we work at the moment, there is no real need to split changes
> > to the arm32 and arm64 defconfig files into separate pull requests or even
> > separate patches.
>
> this is new to me. My understanding was to separate all changes between
> arm32 and arm64 changes.
Right, that was the policy for a long time, but it has gradually gotten
more relaxed.
> So this isn't necessary for the DT arm/arm64 changes, too?
I would still like to see large pull requests get split up into logical
chunks, and the 32/64 split tends to be a natural boundary for
many things, but I think there are cases where it makes more
sense to combine. For instance, the raspberry pi changes tend
to go together for 32/64, so a single pull request is best here.
OTOH, if there are many changes for one Broadcom platform, in
addition to a couple of patches each for the other platforms,
a good split might be
a) bcm283{5678}, both 32-bit and 64-bit combined
b) random other 32-bit DT changes
c) random other 64-bit DT changes
As a rule of thumb, the best pull requests are those
that clearly tell what goes on in the branch using a
tag/commit description in a couple of paragraphs without
enumerating unrelated items. (same as a changeset
commit message actually).
The branches we currently have are
arm/fixes
arm/defconfig
arm/drivers
arm/dt
arm/soc
arm/late
Each of them contain 32-bit and 64-bit changes across all platforms.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v12 00/12] namei: openat2(2) path resolution restrictions
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
This patchset is being developed here:
<https://github.com/cyphar/linux/tree/resolveat/master>
Patch changelog:
v12:
* Remove @how->reserved field from openat2(2), and instead use the
(struct, size) design for syscall extensions.
* Implement copy_struct_{to,from}_user() to unify (struct, size)
syscall extension designs (as well as make them slightly more
efficient by using memchr_inv() as well as using buffers and
avoiding repeated access_ok() checks for trailing byte operations).
* Port sched_setattr(), perf_event_attr(), and clone3() to use the
new helpers.
v11: <https://lore.kernel.org/lkml/20190820033406.29796-1-cyphar@cyphar.com/>
<https://lore.kernel.org/lkml/20190728010207.9781-1-cyphar@cyphar.com/>
v10: <https://lore.kernel.org/lkml/20190719164225.27083-1-cyphar@cyphar.com/>
v09: <https://lore.kernel.org/lkml/20190706145737.5299-1-cyphar@cyphar.com/>
v08: <https://lore.kernel.org/lkml/20190520133305.11925-1-cyphar@cyphar.com/>
v07: <https://lore.kernel.org/lkml/20190507164317.13562-1-cyphar@cyphar.com/>
v06: <https://lore.kernel.org/lkml/20190506165439.9155-1-cyphar@cyphar.com/>
v05: <https://lore.kernel.org/lkml/20190320143717.2523-1-cyphar@cyphar.com/>
v04: <https://lore.kernel.org/lkml/20181112142654.341-1-cyphar@cyphar.com/>
v03: <https://lore.kernel.org/lkml/20181009070230.12884-1-cyphar@cyphar.com/>
v02: <https://lore.kernel.org/lkml/20181009065300.11053-1-cyphar@cyphar.com/>
v01: <https://lore.kernel.org/lkml/20180929103453.12025-1-cyphar@cyphar.com/>
The need for some sort of control over VFS's path resolution (to avoid
malicious paths resulting in inadvertent breakouts) has been a very
long-standing desire of many userspace applications. This patchset is a
revival of Al Viro's old AT_NO_JUMPS[1,2] patchset (which was a variant
of David Drysdale's O_BENEATH patchset[3] which was a spin-off of the
Capsicum project[4]) with a few additions and changes made based on the
previous discussion within [5] as well as others I felt were useful.
In line with the conclusions of the original discussion of AT_NO_JUMPS,
the flag has been split up into separate flags. However, instead of
being an openat(2) flag it is provided through a new syscall openat2(2)
which provides several other improvements to the openat(2) interface (see the
patch description for more details). The following new LOOKUP_* flags are
added:
* LOOKUP_NO_XDEV blocks all mountpoint crossings (upwards, downwards,
or through absolute links). Absolute pathnames alone in openat(2) do
not trigger this.
* LOOKUP_NO_MAGICLINKS blocks resolution through /proc/$pid/fd-style
links. This is done by blocking the usage of nd_jump_link() during
resolution in a filesystem. The term "magic-links" is used to match
with the only reference to these links in Documentation/, but I'm
happy to change the name.
It should be noted that this is different to the scope of
~LOOKUP_FOLLOW in that it applies to all path components. However,
you can do openat2(NO_FOLLOW|NO_MAGICLINKS) on a magic-link and it
will *not* fail (assuming that no parent component was a
magic-link), and you will have an fd for the magic-link.
* LOOKUP_BENEATH disallows escapes to outside the starting dirfd's
tree, using techniques such as ".." or absolute links. Absolute
paths in openat(2) are also disallowed. Conceptually this flag is to
ensure you "stay below" a certain point in the filesystem tree --
but this requires some additional to protect against various races
that would allow escape using "..".
Currently LOOKUP_BENEATH implies LOOKUP_NO_MAGICLINKS, because it
can trivially beam you around the filesystem (breaking the
protection). In future, there might be similar safety checks done as
in LOOKUP_IN_ROOT, but that requires more discussion.
In addition, two new flags are added that expand on the above ideas:
* LOOKUP_NO_SYMLINKS does what it says on the tin. No symlink
resolution is allowed at all, including magic-links. Just as with
LOOKUP_NO_MAGICLINKS this can still be used with NOFOLLOW to open an
fd for the symlink as long as no parent path had a symlink
component.
* LOOKUP_IN_ROOT is an extension of LOOKUP_BENEATH that, rather than
blocking attempts to move past the root, forces all such movements
to be scoped to the starting point. This provides chroot(2)-like
protection but without the cost of a chroot(2) for each filesystem
operation, as well as being safe against race attacks that chroot(2)
is not.
If a race is detected (as with LOOKUP_BENEATH) then an error is
generated, and similar to LOOKUP_BENEATH it is not permitted to cross
magic-links with LOOKUP_IN_ROOT.
The primary need for this is from container runtimes, which
currently need to do symlink scoping in userspace[6] when opening
paths in a potentially malicious container. There is a long list of
CVEs that could have bene mitigated by having RESOLVE_THIS_ROOT
(such as CVE-2017-1002101, CVE-2017-1002102, CVE-2018-15664, and
CVE-2019-5736, just to name a few).
And further, several semantics of file descriptor "re-opening" are now
changed to prevent attacks like CVE-2019-5736 by restricting how
magic-links can be resolved (based on their mode). This required some
other changes to the semantics of the modes of O_PATH file descriptor's
associated /proc/self/fd magic-links. openat2(2) has the ability to
further restrict re-opening of its own O_PATH fds, so that users can
make even better use of this feature.
Finally, O_EMPTYPATH was added so that users can do /proc/self/fd-style
re-opening without depending on procfs. The new restricted semantics for
magic-links are applied here too.
In order to make all of the above more usable, I'm working on
libpathrs[7] which is a C-friendly library for safe path resolution. It
features a userspace-emulated backend if the kernel doesn't support
openat2(2). Hopefully we can get userspace to switch to using it, and
thus get openat2(2) support for free once it's ready.
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Jann Horn <jannh@google.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: David Drysdale <drysdale@google.com>
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
[1]: https://lwn.net/Articles/721443/
[2]: https://lore.kernel.org/patchwork/patch/784221/
[3]: https://lwn.net/Articles/619151/
[4]: https://lwn.net/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (12):
lib: introduce copy_struct_{to,from}_user helpers
clone3: switch to copy_struct_from_user()
sched_setattr: switch to copy_struct_{to,from}_user()
perf_event_open: switch to copy_struct_from_user()
namei: obey trailing magic-link DAC permissions
procfs: switch magic-link modes to be more sane
open: O_EMPTYPATH: procfs-less file descriptor re-opening
namei: O_BENEATH-style path resolution flags
namei: LOOKUP_IN_ROOT: chroot-like path resolution
namei: aggressively check for nd->root escape on ".." resolution
open: openat2(2) syscall
selftests: add openat2(2) selftests
Documentation/filesystems/path-lookup.rst | 12 +-
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/include/uapi/asm/fcntl.h | 39 +-
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/include/uapi/asm/fcntl.h | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
fs/fcntl.c | 2 +-
fs/internal.h | 1 +
fs/namei.c | 270 ++++++++++--
fs/open.c | 100 ++++-
fs/proc/base.c | 20 +-
fs/proc/fd.c | 23 +-
fs/proc/namespaces.c | 2 +-
include/linux/fcntl.h | 21 +-
include/linux/fs.h | 8 +-
include/linux/namei.h | 9 +
include/linux/syscalls.h | 14 +-
include/linux/uaccess.h | 5 +
include/uapi/asm-generic/fcntl.h | 4 +
include/uapi/asm-generic/unistd.h | 5 +-
include/uapi/linux/fcntl.h | 42 ++
include/uapi/linux/sched.h | 2 +
kernel/events/core.c | 45 +-
kernel/fork.c | 34 +-
kernel/sched/core.c | 85 +---
lib/Makefile | 2 +-
lib/struct_user.c | 182 ++++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/memfd_test.c | 7 +-
tools/testing/selftests/openat2/.gitignore | 1 +
tools/testing/selftests/openat2/Makefile | 8 +
tools/testing/selftests/openat2/helpers.c | 167 ++++++++
tools/testing/selftests/openat2/helpers.h | 118 +++++
.../testing/selftests/openat2/linkmode_test.c | 333 +++++++++++++++
.../testing/selftests/openat2/openat2_test.c | 106 +++++
.../selftests/openat2/rename_attack_test.c | 127 ++++++
.../testing/selftests/openat2/resolve_test.c | 402 ++++++++++++++++++
53 files changed, 1971 insertions(+), 248 deletions(-)
create mode 100644 lib/struct_user.c
create mode 100644 tools/testing/selftests/openat2/.gitignore
create mode 100644 tools/testing/selftests/openat2/Makefile
create mode 100644 tools/testing/selftests/openat2/helpers.c
create mode 100644 tools/testing/selftests/openat2/helpers.h
create mode 100644 tools/testing/selftests/openat2/linkmode_test.c
create mode 100644 tools/testing/selftests/openat2/openat2_test.c
create mode 100644 tools/testing/selftests/openat2/rename_attack_test.c
create mode 100644 tools/testing/selftests/openat2/resolve_test.c
--
2.23.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 v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
A common pattern for syscall extensions is increasing the size of a
struct passed from userspace, such that the zero-value of the new fields
result in the old kernel behaviour (allowing for a mix of userspace and
kernel vintages to operate on one another in most cases). This is done
in both directions -- hence two helpers -- though it's more common to
have to copy user space structs into kernel space.
Previously there was no common lib/ function that implemented
the necessary extension-checking semantics (and different syscalls
implemented them slightly differently or incompletely[1]). A future
patch replaces all of the common uses of this pattern to use the new
copy_struct_{to,from}_user() helpers.
[1]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
similar checks to copy_struct_from_user() while rt_sigprocmask(2)
always rejects differently-sized struct arguments.
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
include/linux/uaccess.h | 5 ++
lib/Makefile | 2 +-
lib/struct_user.c | 182 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 188 insertions(+), 1 deletion(-)
create mode 100644 lib/struct_user.c
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 34a038563d97..0ad9544a1aee 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -230,6 +230,11 @@ static inline unsigned long __copy_from_user_inatomic_nocache(void *to,
#endif /* ARCH_HAS_NOCACHE_UACCESS */
+extern int copy_struct_to_user(void __user *dst, size_t usize,
+ const void *src, size_t ksize);
+extern int copy_struct_from_user(void *dst, size_t ksize,
+ const void __user *src, size_t usize);
+
/*
* probe_kernel_read(): safely attempt to read from a location
* @dst: pointer to the buffer that shall take the data
diff --git a/lib/Makefile b/lib/Makefile
index 29c02a924973..d86c71feaf0a 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -28,7 +28,7 @@ endif
CFLAGS_string.o := $(call cc-option, -fno-stack-protector)
endif
-lib-y := ctype.o string.o vsprintf.o cmdline.o \
+lib-y := ctype.o string.o struct_user.o vsprintf.o cmdline.o \
rbtree.o radix-tree.o timerqueue.o xarray.o \
idr.o extable.o \
sha1.o chacha.o irq_regs.o argv_split.o \
diff --git a/lib/struct_user.c b/lib/struct_user.c
new file mode 100644
index 000000000000..7301ab1bbe98
--- /dev/null
+++ b/lib/struct_user.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2019 SUSE LLC
+ * Copyright (C) 2019 Aleksa Sarai <cyphar@cyphar.com>
+ */
+
+#include <linux/types.h>
+#include <linux/export.h>
+#include <linux/uaccess.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+
+#define BUFFER_SIZE 64
+
+/*
+ * "memset(p, 0, size)" but for user space buffers. Caller must have already
+ * checked access_ok(p, size).
+ */
+static int __memzero_user(void __user *p, size_t s)
+{
+ const char zeros[BUFFER_SIZE] = {};
+ while (s > 0) {
+ size_t n = min(s, sizeof(zeros));
+
+ if (__copy_to_user(p, zeros, n))
+ return -EFAULT;
+
+ p += n;
+ s -= n;
+ }
+ return 0;
+}
+
+/**
+ * copy_struct_to_user: copy a struct to user space
+ * @dst: Destination address, in user space.
+ * @usize: Size of @dst struct.
+ * @src: Source address, in kernel space.
+ * @ksize: Size of @src struct.
+ *
+ * Copies a struct from kernel space to user space, in a way that guarantees
+ * backwards-compatibility for struct syscall arguments (as long as future
+ * struct extensions are made such that all new fields are *appended* to the
+ * old struct, and zeroed-out new fields have the same meaning as the old
+ * struct).
+ *
+ * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
+ * The recommended usage is something like the following:
+ *
+ * SYSCALL_DEFINE2(foobar, struct foo __user *, uarg, size_t, usize)
+ * {
+ * int err;
+ * struct foo karg = {};
+ *
+ * // do something with karg
+ *
+ * err = copy_struct_to_user(uarg, usize, &karg, sizeof(karg));
+ * if (err)
+ * return err;
+ *
+ * // ...
+ * }
+ *
+ * There are three cases to consider:
+ * * If @usize == @ksize, then it's copied verbatim.
+ * * If @usize < @ksize, then kernel space is "returning" a newer struct to an
+ * older user space. In order to avoid user space getting incomplete
+ * information (new fields might be important), all trailing bytes in @src
+ * (@ksize - @usize) must be zerored, otherwise -EFBIG is returned.
+ * * If @usize > @ksize, then the kernel is "returning" an older struct to a
+ * newer user space. The trailing bytes in @dst (@usize - @ksize) will be
+ * zero-filled.
+ *
+ * Returns (in all cases, some data may have been copied):
+ * * -EFBIG: (@usize < @ksize) and there are non-zero trailing bytes in @src.
+ * * -EFAULT: access to user space failed.
+ */
+int copy_struct_to_user(void __user *dst, size_t usize,
+ const void *src, size_t ksize)
+{
+ size_t size = min(ksize, usize);
+ size_t rest = abs(ksize - usize);
+
+ if (unlikely(usize > PAGE_SIZE))
+ return -EFAULT;
+ if (unlikely(!access_ok(dst, usize)))
+ return -EFAULT;
+
+ /* Deal with trailing bytes. */
+ if (usize < ksize) {
+ if (memchr_inv(src + size, 0, rest))
+ return -EFBIG;
+ } else if (usize > ksize) {
+ if (__memzero_user(dst + size, rest))
+ return -EFAULT;
+ }
+ /* Copy the interoperable parts of the struct. */
+ if (__copy_to_user(dst, src, size))
+ return -EFAULT;
+ return 0;
+}
+EXPORT_SYMBOL(copy_struct_to_user);
+
+/**
+ * copy_struct_from_user: copy a struct from user space
+ * @dst: Destination address, in kernel space. This buffer must be @ksize
+ * bytes long.
+ * @ksize: Size of @dst struct.
+ * @src: Source address, in user space.
+ * @usize: (Alleged) size of @src struct.
+ *
+ * Copies a struct from user space to kernel space, in a way that guarantees
+ * backwards-compatibility for struct syscall arguments (as long as future
+ * struct extensions are made such that all new fields are *appended* to the
+ * old struct, and zeroed-out new fields have the same meaning as the old
+ * struct).
+ *
+ * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
+ * The recommended usage is something like the following:
+ *
+ * SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize)
+ * {
+ * int err;
+ * struct foo karg = {};
+ *
+ * err = copy_struct_from_user(&karg, sizeof(karg), uarg, size);
+ * if (err)
+ * return err;
+ *
+ * // ...
+ * }
+ *
+ * There are three cases to consider:
+ * * If @usize == @ksize, then it's copied verbatim.
+ * * If @usize < @ksize, then the user space has passed an old struct to a
+ * newer kernel. The rest of the trailing bytes in @dst (@ksize - @usize)
+ * are to be zero-filled.
+ * * If @usize > @ksize, then the user space has passed a new struct to an
+ * older kernel. The trailing bytes unknown to the kernel (@usize - @ksize)
+ * are checked to ensure they are zeroed, otherwise -E2BIG is returned.
+ *
+ * Returns (in all cases, some data may have been copied):
+ * * -E2BIG: (@usize > @ksize) and there are non-zero trailing bytes in @src.
+ * * -E2BIG: @usize is "too big" (at time of writing, >PAGE_SIZE).
+ * * -EFAULT: access to user space failed.
+ */
+int copy_struct_from_user(void *dst, size_t ksize,
+ const void __user *src, size_t usize)
+{
+ size_t size = min(ksize, usize);
+ size_t rest = abs(ksize - usize);
+
+ if (unlikely(usize > PAGE_SIZE))
+ return -EFAULT;
+ if (unlikely(!access_ok(src, usize)))
+ return -EFAULT;
+
+ /* Deal with trailing bytes. */
+ if (usize < ksize)
+ memset(dst + size, 0, rest);
+ else if (usize > ksize) {
+ const void __user *addr = src + size;
+ char buffer[BUFFER_SIZE] = {};
+
+ while (rest > 0) {
+ size_t bufsize = min(rest, sizeof(buffer));
+
+ if (__copy_from_user(buffer, addr, bufsize))
+ return -EFAULT;
+ if (memchr_inv(buffer, 0, bufsize))
+ return -E2BIG;
+
+ addr += bufsize;
+ rest -= bufsize;
+ }
+ }
+ /* Copy the interoperable parts of the struct. */
+ if (__copy_from_user(dst, src, size))
+ return -EFAULT;
+ return 0;
+}
+EXPORT_SYMBOL(copy_struct_from_user);
--
2.23.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 v12 02/12] clone3: switch to copy_struct_from_user()
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
The change is very straightforward, and takes advantage of the (very
minor) efficiency improvements in copy_struct_from_user() -- that the
memchr_inv() check is done on a buffer instead of one-at-at-time with
get_user().
Additionally, explicitly define CLONE_ARGS_SIZE_VER0 to match the other
users of the struct-extension pattern.
Cc: Christian Brauner <christian@brauner.io>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
include/uapi/linux/sched.h | 2 ++
kernel/fork.c | 34 ++++++----------------------------
2 files changed, 8 insertions(+), 28 deletions(-)
diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h
index b3105ac1381a..0945805982b4 100644
--- a/include/uapi/linux/sched.h
+++ b/include/uapi/linux/sched.h
@@ -47,6 +47,8 @@ struct clone_args {
__aligned_u64 tls;
};
+#define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
+
/*
* Scheduling policies
*/
diff --git a/kernel/fork.c b/kernel/fork.c
index 2852d0e76ea3..70c10d9b429a 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2528,39 +2528,17 @@ SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp,
#ifdef __ARCH_WANT_SYS_CLONE3
noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
struct clone_args __user *uargs,
- size_t size)
+ size_t usize)
{
+ int err;
struct clone_args args;
- if (unlikely(size > PAGE_SIZE))
- return -E2BIG;
-
- if (unlikely(size < sizeof(struct clone_args)))
+ if (unlikely(usize < CLONE_ARGS_SIZE_VER0))
return -EINVAL;
- if (unlikely(!access_ok(uargs, size)))
- return -EFAULT;
-
- if (size > sizeof(struct clone_args)) {
- unsigned char __user *addr;
- unsigned char __user *end;
- unsigned char val;
-
- addr = (void __user *)uargs + sizeof(struct clone_args);
- end = (void __user *)uargs + size;
-
- for (; addr < end; addr++) {
- if (get_user(val, addr))
- return -EFAULT;
- if (val)
- return -E2BIG;
- }
-
- size = sizeof(struct clone_args);
- }
-
- if (copy_from_user(&args, uargs, size))
- return -EFAULT;
+ err = copy_struct_from_user(&args, sizeof(args), uargs, usize);
+ if (err)
+ return err;
*kargs = (struct kernel_clone_args){
.flags = args.flags,
--
2.23.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 v12 03/12] sched_setattr: switch to copy_struct_{to, from}_user()
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
The change is very straightforward, and takes advantage of the (very
minor) efficiency improvements in copy_struct_{to,from}_user() -- that
the memchr_inv() check is done on a buffer instead of one-at-at-time
with get_user() or put_user().
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
kernel/sched/core.c | 85 ++++++---------------------------------------
1 file changed, 10 insertions(+), 75 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 010d578118d6..2f58b07d3468 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4900,9 +4900,6 @@ static int sched_copy_attr(struct sched_attr __user *uattr, struct sched_attr *a
u32 size;
int ret;
- if (!access_ok(uattr, SCHED_ATTR_SIZE_VER0))
- return -EFAULT;
-
/* Zero the full structure, so that a short copy will be nice: */
memset(attr, 0, sizeof(*attr));
@@ -4910,45 +4907,19 @@ static int sched_copy_attr(struct sched_attr __user *uattr, struct sched_attr *a
if (ret)
return ret;
- /* Bail out on silly large: */
- if (size > PAGE_SIZE)
- goto err_size;
-
/* ABI compatibility quirk: */
if (!size)
size = SCHED_ATTR_SIZE_VER0;
-
if (size < SCHED_ATTR_SIZE_VER0)
goto err_size;
- /*
- * If we're handed a bigger struct than we know of,
- * ensure all the unknown bits are 0 - i.e. new
- * user-space does not rely on any kernel feature
- * extensions we dont know about yet.
- */
- if (size > sizeof(*attr)) {
- unsigned char __user *addr;
- unsigned char __user *end;
- unsigned char val;
-
- addr = (void __user *)uattr + sizeof(*attr);
- end = (void __user *)uattr + size;
-
- for (; addr < end; addr++) {
- ret = get_user(val, addr);
- if (ret)
- return ret;
- if (val)
- goto err_size;
- }
- size = sizeof(*attr);
+ ret = copy_struct_from_user(attr, sizeof(*attr), uattr, size);
+ if (ret) {
+ if (ret == -E2BIG)
+ goto err_size;
+ return ret;
}
- ret = copy_from_user(attr, uattr, size);
- if (ret)
- return -EFAULT;
-
if ((attr->sched_flags & SCHED_FLAG_UTIL_CLAMP) &&
size < SCHED_ATTR_SIZE_VER1)
return -EINVAL;
@@ -5105,51 +5076,15 @@ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param)
return retval;
}
-static int sched_read_attr(struct sched_attr __user *uattr,
- struct sched_attr *attr,
- unsigned int usize)
-{
- int ret;
-
- if (!access_ok(uattr, usize))
- return -EFAULT;
-
- /*
- * If we're handed a smaller struct than we know of,
- * ensure all the unknown bits are 0 - i.e. old
- * user-space does not get uncomplete information.
- */
- if (usize < sizeof(*attr)) {
- unsigned char *addr;
- unsigned char *end;
-
- addr = (void *)attr + usize;
- end = (void *)attr + sizeof(*attr);
-
- for (; addr < end; addr++) {
- if (*addr)
- return -EFBIG;
- }
-
- attr->size = usize;
- }
-
- ret = copy_to_user(uattr, attr, attr->size);
- if (ret)
- return -EFAULT;
-
- return 0;
-}
-
/**
* sys_sched_getattr - similar to sched_getparam, but with sched_attr
* @pid: the pid in question.
* @uattr: structure containing the extended parameters.
- * @size: sizeof(attr) for fwd/bwd comp.
+ * @usize: sizeof(attr) for fwd/bwd comp.
* @flags: for future extension.
*/
SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, uattr,
- unsigned int, size, unsigned int, flags)
+ unsigned int, usize, unsigned int, flags)
{
struct sched_attr attr = {
.size = sizeof(struct sched_attr),
@@ -5157,8 +5092,8 @@ SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, uattr,
struct task_struct *p;
int retval;
- if (!uattr || pid < 0 || size > PAGE_SIZE ||
- size < SCHED_ATTR_SIZE_VER0 || flags)
+ if (!uattr || pid < 0 || usize > PAGE_SIZE ||
+ usize < SCHED_ATTR_SIZE_VER0 || flags)
return -EINVAL;
rcu_read_lock();
@@ -5188,7 +5123,7 @@ SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, uattr,
rcu_read_unlock();
- retval = sched_read_attr(uattr, &attr, size);
+ retval = copy_struct_to_user(uattr, usize, &attr, sizeof(attr));
return retval;
out_unlock:
--
2.23.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 v12 04/12] perf_event_open: switch to copy_struct_from_user()
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
The change is very straightforward, and takes advantage of the (very
minor) efficiency improvements in copy_struct_from_user() -- that the
memchr_inv() check is done on a buffer instead of one-at-at-time with
get_user().
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
kernel/events/core.c | 45 ++++++++------------------------------------
1 file changed, 8 insertions(+), 37 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0463c1151bae..fe5f58443ba6 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10498,55 +10498,26 @@ static int perf_copy_attr(struct perf_event_attr __user *uattr,
u32 size;
int ret;
- if (!access_ok(uattr, PERF_ATTR_SIZE_VER0))
- return -EFAULT;
-
- /*
- * zero the full structure, so that a short copy will be nice.
- */
+ /* Zero the full structure, so that a short copy will be nice. */
memset(attr, 0, sizeof(*attr));
ret = get_user(size, &uattr->size);
if (ret)
return ret;
- if (size > PAGE_SIZE) /* silly large */
- goto err_size;
-
- if (!size) /* abi compat */
+ /* ABI compatibility quirk: */
+ if (!size)
size = PERF_ATTR_SIZE_VER0;
-
if (size < PERF_ATTR_SIZE_VER0)
goto err_size;
- /*
- * If we're handed a bigger struct than we know of,
- * ensure all the unknown bits are 0 - i.e. new
- * user-space does not rely on any kernel feature
- * extensions we dont know about yet.
- */
- if (size > sizeof(*attr)) {
- unsigned char __user *addr;
- unsigned char __user *end;
- unsigned char val;
-
- addr = (void __user *)uattr + sizeof(*attr);
- end = (void __user *)uattr + size;
-
- for (; addr < end; addr++) {
- ret = get_user(val, addr);
- if (ret)
- return ret;
- if (val)
- goto err_size;
- }
- size = sizeof(*attr);
+ ret = copy_struct_from_user(attr, sizeof(*attr), uattr, size);
+ if (ret) {
+ if (ret == -E2BIG)
+ goto err_size;
+ return ret;
}
- ret = copy_from_user(attr, uattr, size);
- if (ret)
- return -EFAULT;
-
attr->size = size;
if (attr->__reserved_1)
--
2.23.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 v12 05/12] namei: obey trailing magic-link DAC permissions
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
The ability for userspace to "re-open" file descriptors through
/proc/self/fd has been a very useful tool for all sorts of usecases
(container runtimes are one common example). However, the current
interface for doing this has resulted in some pretty subtle security
holes. Userspace can re-open a file descriptor with more permissions
than the original, which can result in cases such as /proc/$pid/exe
being re-opened O_RDWR at a later date even though (by definition)
/proc/$pid/exe cannot be opened for writing. When combined with O_PATH
the results can get even more confusing.
We cannot block this outright. Aside from userspace already depending on
it, it's a useful feature which can actually increase the security of
userspace. For instance, LXC keeps an O_PATH of the container's
/dev/pts/ptmx that gets re-opened to create new ptys and then uses
TIOCGPTPEER to get the slave end. This allows for pty allocation without
resolving paths inside an (untrusted) container's rootfs. There isn't a
trivial way of doing this that is as straight-forward and safe as O_PATH
re-opening.
Instead we have to restrict it in such a way that it doesn't break
(good) users but does block potential attackers. The solution applied in
this patch is to restrict *re-opening* (not resolution through)
magic-links by requiring that mode of the link be obeyed. Normal
symlinks have modes of a+rwx but magic-links have other modes. These
magic-link modes were historically ignored during path resolution, but
they've now been re-purposed for more useful ends.
It is also necessary to define semantics for the mode of an O_PATH
descriptor, since re-opening a magic-link through an O_PATH needs to be
just as restricted as the corresponding magic-link -- otherwise the
above protection can be bypassed. There are two distinct cases:
1. The target is a regular file (not a magic-link). Userspace depends
on being able to re-open the O_PATH of a regular file, so we must
define the mode to be a+rwx.
2. The target is a magic-link. In this case, we simply copy the mode of
the magic-link. This results in an O_PATH of a magic-link
effectively acting as a no-op in terms of how much re-opening
privileges a process has.
CAP_DAC_OVERRIDE can be used to override all of these restrictions, but
we only permit &init_userns's capabilities to affect these semantics.
The reason for this is that there isn't a clear way to track what
user_ns is the original owner of a given O_PATH chain -- thus an
unprivileged user could create a new userns and O_PATH the file
descriptor, owning it. All signs would indicate that the user really
does have CAP_DAC_OVERRIDE over the new descriptor and the protection
would be bypassed. We thus opt for the more conservative approach.
I have run this patch on several machines for several days. So far, the
only processes which have hit this case ("loadkeys" and "kbd_mode" from
the kbd package[1]) gracefully handle the permission error and do not
cause any user-visible problems. In order to give users a heads-up, a
warning is output to dmesg whenever may_open_magiclink() refuses access.
[1]: http://git.altlinux.org/people/legion/packages/kbd.git
Suggested-by: Andy Lutomirski <luto@kernel.org>
Suggested-by: Christian Brauner <christian@brauner.io>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
Documentation/filesystems/path-lookup.rst | 12 +--
fs/internal.h | 1 +
fs/namei.c | 105 +++++++++++++++++++---
fs/open.c | 3 +-
fs/proc/fd.c | 23 ++++-
include/linux/fs.h | 4 +
include/linux/namei.h | 1 +
7 files changed, 130 insertions(+), 19 deletions(-)
diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
index 434a07b0002b..a57d78ec8bee 100644
--- a/Documentation/filesystems/path-lookup.rst
+++ b/Documentation/filesystems/path-lookup.rst
@@ -1310,12 +1310,14 @@ longer needed.
``LOOKUP_JUMPED`` means that the current dentry was chosen not because
it had the right name but for some other reason. This happens when
following "``..``", following a symlink to ``/``, crossing a mount point
-or accessing a "``/proc/$PID/fd/$FD``" symlink. In this case the
-filesystem has not been asked to revalidate the name (with
-``d_revalidate()``). In such cases the inode may still need to be
-revalidated, so ``d_op->d_weak_revalidate()`` is called if
+or accessing a "``/proc/$PID/fd/$FD``" symlink (also known as a "magic
+link"). In this case the filesystem has not been asked to revalidate the
+name (with ``d_revalidate()``). In such cases the inode may still need
+to be revalidated, so ``d_op->d_weak_revalidate()`` is called if
``LOOKUP_JUMPED`` is set when the look completes - which may be at the
-final component or, when creating, unlinking, or renaming, at the penultimate component.
+final component or, when creating, unlinking, or renaming, at the
+penultimate component. ``LOOKUP_MAGICLINK_JUMPED`` is set alongside
+``LOOKUP_JUMPED`` if a magic-link was traversed.
Final-component flags
~~~~~~~~~~~~~~~~~~~~~
diff --git a/fs/internal.h b/fs/internal.h
index 315fcd8d237c..f48449a43626 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -119,6 +119,7 @@ struct open_flags {
int acc_mode;
int intent;
int lookup_flags;
+ fmode_t opath_mask;
};
extern struct file *do_filp_open(int dfd, struct filename *pathname,
const struct open_flags *op);
diff --git a/fs/namei.c b/fs/namei.c
index 209c51a5226c..54d57dad0f91 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -872,7 +872,7 @@ void nd_jump_link(struct path *path)
nd->path = *path;
nd->inode = nd->path.dentry->d_inode;
- nd->flags |= LOOKUP_JUMPED;
+ nd->flags |= LOOKUP_JUMPED | LOOKUP_MAGICLINK_JUMPED;
}
static inline void put_link(struct nameidata *nd)
@@ -1066,6 +1066,7 @@ const char *get_link(struct nameidata *nd)
return ERR_PTR(error);
nd->last_type = LAST_BIND;
+ nd->flags &= ~LOOKUP_MAGICLINK_JUMPED;
res = READ_ONCE(inode->i_link);
if (!res) {
const char * (*get)(struct dentry *, struct inode *,
@@ -3501,16 +3502,73 @@ static int do_tmpfile(struct nameidata *nd, unsigned flags,
return error;
}
-static int do_o_path(struct nameidata *nd, unsigned flags, struct file *file)
+/**
+ * may_reopen_magiclink - Check permissions for opening a trailing magic-link
+ * @upgrade_mask: the upgrade-mask of the magic-link
+ * @acc_mode: ACC_MODE which the user is attempting
+ *
+ * We block magic-link re-opening if the @upgrade_mask is more strict than the
+ * @acc_mode being requested, unless the user is capable(CAP_DAC_OVERRIDE).
+ *
+ * Returns 0 if successful, -EACCES on error.
+ */
+static int may_open_magiclink(fmode_t upgrade_mask, int acc_mode)
{
- struct path path;
- int error = path_lookupat(nd, flags, &path);
- if (!error) {
- audit_inode(nd->name, path.dentry, 0);
- error = vfs_open(&path, file);
- path_put(&path);
- }
- return error;
+ /*
+ * We only allow for init_userns to be able to override magic-links.
+ * This is done to avoid cases where an unprivileged userns could take
+ * an O_PATH of the fd, resulting in it being very unclear whether
+ * CAP_DAC_OVERRIDE should work on the new O_PATH fd (given that it
+ * pipes through to the underlying file).
+ */
+ if (capable(CAP_DAC_OVERRIDE))
+ return 0;
+
+ if ((acc_mode & MAY_READ) &&
+ !(upgrade_mask & (FMODE_READ | FMODE_PATH_READ)))
+ goto err;
+ if ((acc_mode & MAY_WRITE) &&
+ !(upgrade_mask & (FMODE_WRITE | FMODE_PATH_WRITE)))
+ goto err;
+
+ return 0;
+
+err:
+ pr_warn_ratelimited("%s[%d]: magic-link re-open blocked ('%s%s%s' requested with an upgrade-mask of '%s%s%s%s')",
+ current->comm, task_pid_nr(current),
+ (acc_mode & MAY_READ) ? "r" : "",
+ (acc_mode & MAY_WRITE) ? "w" : "",
+ (acc_mode & MAY_EXEC) ? "x" : "",
+ (upgrade_mask & FMODE_READ) ? "r" : "",
+ (upgrade_mask & FMODE_PATH_READ) ? "R" : "",
+ (upgrade_mask & FMODE_WRITE) ? "w" : "",
+ (upgrade_mask & FMODE_PATH_WRITE) ? "W" : "");
+ return -EACCES;
+}
+
+static int trailing_magiclink(struct nameidata *nd, int acc_mode,
+ fmode_t *opath_mask)
+{
+ struct inode *inode = nd->link_inode;
+ fmode_t upgrade_mask = 0;
+
+ /* Was the trailing_symlink() a magic-link? */
+ if (!(nd->flags & LOOKUP_MAGICLINK_JUMPED))
+ return 0;
+
+ /*
+ * Figure out the upgrade-mask of the link_inode. Since these aren't
+ * strictly POSIX semantics we don't do an acl_permission_check() here,
+ * so we only care that at least one bit is set for each upgrade-mode.
+ */
+ if (inode->i_mode & S_IRUGO)
+ upgrade_mask |= FMODE_PATH_READ;
+ if (inode->i_mode & S_IWUGO)
+ upgrade_mask |= FMODE_PATH_WRITE;
+ /* Restrict the O_PATH upgrade-mask of the caller. */
+ if (opath_mask)
+ *opath_mask &= upgrade_mask;
+ return may_open_magiclink(upgrade_mask, acc_mode);
}
static struct file *path_openat(struct nameidata *nd,
@@ -3526,13 +3584,38 @@ static struct file *path_openat(struct nameidata *nd,
if (unlikely(file->f_flags & __O_TMPFILE)) {
error = do_tmpfile(nd, flags, op, file);
} else if (unlikely(file->f_flags & O_PATH)) {
- error = do_o_path(nd, flags, file);
+ /* Inlined path_lookupat() with a trailing_magiclink() check. */
+ fmode_t opath_mask = op->opath_mask;
+ const char *s = path_init(nd, flags);
+
+ while (!(error = link_path_walk(s, nd))
+ && ((error = lookup_last(nd)) > 0)) {
+ s = trailing_symlink(nd);
+ error = trailing_magiclink(nd, op->acc_mode, &opath_mask);
+ if (error)
+ s = ERR_PTR(error);
+ }
+ if (!error)
+ error = complete_walk(nd);
+
+ if (!error && nd->flags & LOOKUP_DIRECTORY)
+ if (!d_can_lookup(nd->path.dentry))
+ error = -ENOTDIR;
+ if (!error) {
+ audit_inode(nd->name, nd->path.dentry, 0);
+ error = vfs_open(&nd->path, file);
+ file->f_mode |= opath_mask;
+ }
+ terminate_walk(nd);
} else {
const char *s = path_init(nd, flags);
while (!(error = link_path_walk(s, nd)) &&
(error = do_last(nd, file, op)) > 0) {
nd->flags &= ~(LOOKUP_OPEN|LOOKUP_CREATE|LOOKUP_EXCL);
s = trailing_symlink(nd);
+ error = trailing_magiclink(nd, op->acc_mode, NULL);
+ if (error)
+ s = ERR_PTR(error);
}
terminate_walk(nd);
}
diff --git a/fs/open.c b/fs/open.c
index a59abe3c669a..806a75d685e1 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1001,8 +1001,9 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o
acc_mode |= MAY_APPEND;
op->acc_mode = acc_mode;
-
op->intent = flags & O_PATH ? 0 : LOOKUP_OPEN;
+ /* For O_PATH backwards-compatibility we default to an all-set mask. */
+ op->opath_mask = FMODE_PATH_READ | FMODE_PATH_WRITE;
if (flags & O_CREAT) {
op->intent |= LOOKUP_CREATE;
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index 81882a13212d..9b7d8becb002 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -104,11 +104,30 @@ static void tid_fd_update_inode(struct task_struct *task, struct inode *inode,
task_dump_owner(task, 0, &inode->i_uid, &inode->i_gid);
if (S_ISLNK(inode->i_mode)) {
+ /*
+ * Always set +x (depending on the fmode type), since there
+ * currently aren't FMODE_PATH_EXEC restrictions and there is
+ * no O_MAYEXEC yet. This might change in the future, in which
+ * case we will restrict +x.
+ */
unsigned i_mode = S_IFLNK;
+ if (f_mode & FMODE_PATH)
+ i_mode |= S_IXGRP;
+ else
+ i_mode |= S_IXUSR;
+ /*
+ * Construct the mode bits based on the open-mode. The u+rwx
+ * bits are for "ordinary" open modes while g+rwx are for
+ * O_PATH modes.
+ */
if (f_mode & FMODE_READ)
- i_mode |= S_IRUSR | S_IXUSR;
+ i_mode |= S_IRUSR;
if (f_mode & FMODE_WRITE)
- i_mode |= S_IWUSR | S_IXUSR;
+ i_mode |= S_IWUSR;
+ if (f_mode & FMODE_PATH_READ)
+ i_mode |= S_IRGRP;
+ if (f_mode & FMODE_PATH_WRITE)
+ i_mode |= S_IWGRP;
inode->i_mode = i_mode;
}
security_task_to_inode(task, inode);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 997a530ff4e9..a9ad596b28e2 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -173,6 +173,10 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
/* File does not contribute to nr_files count */
#define FMODE_NOACCOUNT ((__force fmode_t)0x20000000)
+/* File is an O_PATH descriptor which can be upgraded to (read, write). */
+#define FMODE_PATH_READ ((__force fmode_t)0x40000000)
+#define FMODE_PATH_WRITE ((__force fmode_t)0x80000000)
+
/*
* Flag for rw_copy_check_uvector and compat_rw_copy_check_uvector
* that indicates that they should check the contents of the iovec are
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 9138b4471dbf..bd6d3eb7764d 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -49,6 +49,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
#define LOOKUP_ROOT 0x2000
#define LOOKUP_EMPTY 0x4000
#define LOOKUP_DOWN 0x8000
+#define LOOKUP_MAGICLINK_JUMPED 0x10000
extern int path_pts(struct path *path);
--
2.23.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 v12 06/12] procfs: switch magic-link modes to be more sane
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
Now that magic-link modes are obeyed for file re-opening purposes, some
of the pre-existing magic-link modes need to be adjusted to be more
semantically correct.
The most blatant example of this is /proc/self/exe, which had a mode of
a+rwx even though tautologically the file could never be opened for
writing (because it is the current->mm of a live process).
With the new O_PATH restrictions, changing the default mode of these
magic-links allows us to avoid delayed-access attacks such as we saw in
CVE-2019-5736.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
fs/proc/base.c | 20 ++++++++++----------
fs/proc/namespaces.c | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ebea9501afb8..297242174402 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -133,9 +133,9 @@ struct pid_entry {
#define DIR(NAME, MODE, iops, fops) \
NOD(NAME, (S_IFDIR|(MODE)), &iops, &fops, {} )
-#define LNK(NAME, get_link) \
- NOD(NAME, (S_IFLNK|S_IRWXUGO), \
- &proc_pid_link_inode_operations, NULL, \
+#define LNK(NAME, MODE, get_link) \
+ NOD(NAME, (S_IFLNK|(MODE)), \
+ &proc_pid_link_inode_operations, NULL, \
{ .proc_get_link = get_link } )
#define REG(NAME, MODE, fops) \
NOD(NAME, (S_IFREG|(MODE)), NULL, &fops, {})
@@ -3028,9 +3028,9 @@ static const struct pid_entry tgid_base_stuff[] = {
REG("numa_maps", S_IRUGO, proc_pid_numa_maps_operations),
#endif
REG("mem", S_IRUSR|S_IWUSR, proc_mem_operations),
- LNK("cwd", proc_cwd_link),
- LNK("root", proc_root_link),
- LNK("exe", proc_exe_link),
+ LNK("cwd", S_IRWXUGO, proc_cwd_link),
+ LNK("root", S_IRWXUGO, proc_root_link),
+ LNK("exe", S_IRUGO|S_IXUGO, proc_exe_link),
REG("mounts", S_IRUGO, proc_mounts_operations),
REG("mountinfo", S_IRUGO, proc_mountinfo_operations),
REG("mountstats", S_IRUSR, proc_mountstats_operations),
@@ -3429,11 +3429,11 @@ static const struct pid_entry tid_base_stuff[] = {
REG("numa_maps", S_IRUGO, proc_pid_numa_maps_operations),
#endif
REG("mem", S_IRUSR|S_IWUSR, proc_mem_operations),
- LNK("cwd", proc_cwd_link),
- LNK("root", proc_root_link),
- LNK("exe", proc_exe_link),
+ LNK("cwd", S_IRWXUGO, proc_cwd_link),
+ LNK("root", S_IRWXUGO, proc_root_link),
+ LNK("exe", S_IRUGO|S_IXUGO, proc_exe_link),
REG("mounts", S_IRUGO, proc_mounts_operations),
- REG("mountinfo", S_IRUGO, proc_mountinfo_operations),
+ REG("mountinfo", S_IRUGO, proc_mountinfo_operations),
#ifdef CONFIG_PROC_PAGE_MONITOR
REG("clear_refs", S_IWUSR, proc_clear_refs_operations),
REG("smaps", S_IRUGO, proc_pid_smaps_operations),
diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c
index dd2b35f78b09..cd1e130913f7 100644
--- a/fs/proc/namespaces.c
+++ b/fs/proc/namespaces.c
@@ -94,7 +94,7 @@ static struct dentry *proc_ns_instantiate(struct dentry *dentry,
struct inode *inode;
struct proc_inode *ei;
- inode = proc_pid_make_inode(dentry->d_sb, task, S_IFLNK | S_IRWXUGO);
+ inode = proc_pid_make_inode(dentry->d_sb, task, S_IFLNK | S_IRUGO);
if (!inode)
return ERR_PTR(-ENOENT);
--
2.23.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 v12 07/12] open: O_EMPTYPATH: procfs-less file descriptor re-opening
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
Userspace has made use of /proc/self/fd very liberally to allow for
descriptors to be re-opened. There are a wide variety of uses for this
feature, but it has always required constructing a pathname and could
not be done without procfs mounted. The obvious solution for this is to
extend openat(2) to have an AT_EMPTY_PATH-equivalent -- O_EMPTYPATH.
Now that descriptor re-opening has been made safe through the new
magic-link resolution restrictions, we can replicate these restrictions
for O_EMPTYPATH. In particular, we only allow "upgrading" the file
descriptor if the corresponding FMODE_PATH_* bit is set (or the
FMODE_{READ,WRITE} cases for non-O_PATH file descriptors).
When doing openat(O_EMPTYPATH|O_PATH), O_PATH takes precedence and
O_EMPTYPATH is ignored. Very few users ever have a need to O_PATH
re-open an existing file descriptor, and so accommodating them at the
expense of further complicating O_PATH makes little sense. Ultimately,
if users ask for this we can always add RESOLVE_EMPTY_PATH to
resolveat(2) in the future.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fcntl.h | 39 ++++++++++++++--------------
arch/sparc/include/uapi/asm/fcntl.h | 1 +
fs/fcntl.c | 2 +-
fs/namei.c | 20 ++++++++++++++
fs/open.c | 7 ++++-
include/linux/fcntl.h | 2 +-
include/uapi/asm-generic/fcntl.h | 4 +++
8 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/arch/alpha/include/uapi/asm/fcntl.h b/arch/alpha/include/uapi/asm/fcntl.h
index 50bdc8e8a271..1f879bade68b 100644
--- a/arch/alpha/include/uapi/asm/fcntl.h
+++ b/arch/alpha/include/uapi/asm/fcntl.h
@@ -34,6 +34,7 @@
#define O_PATH 040000000
#define __O_TMPFILE 0100000000
+#define O_EMPTYPATH 0200000000
#define F_GETLK 7
#define F_SETLK 8
diff --git a/arch/parisc/include/uapi/asm/fcntl.h b/arch/parisc/include/uapi/asm/fcntl.h
index 03ce20e5ad7d..5d709058a76f 100644
--- a/arch/parisc/include/uapi/asm/fcntl.h
+++ b/arch/parisc/include/uapi/asm/fcntl.h
@@ -2,26 +2,27 @@
#ifndef _PARISC_FCNTL_H
#define _PARISC_FCNTL_H
-#define O_APPEND 000000010
-#define O_BLKSEEK 000000100 /* HPUX only */
-#define O_CREAT 000000400 /* not fcntl */
-#define O_EXCL 000002000 /* not fcntl */
-#define O_LARGEFILE 000004000
-#define __O_SYNC 000100000
+#define O_APPEND 0000000010
+#define O_BLKSEEK 0000000100 /* HPUX only */
+#define O_CREAT 0000000400 /* not fcntl */
+#define O_EXCL 0000002000 /* not fcntl */
+#define O_LARGEFILE 0000004000
+#define __O_SYNC 0000100000
#define O_SYNC (__O_SYNC|O_DSYNC)
-#define O_NONBLOCK 000200004 /* HPUX has separate NDELAY & NONBLOCK */
-#define O_NOCTTY 000400000 /* not fcntl */
-#define O_DSYNC 001000000 /* HPUX only */
-#define O_RSYNC 002000000 /* HPUX only */
-#define O_NOATIME 004000000
-#define O_CLOEXEC 010000000 /* set close_on_exec */
-
-#define O_DIRECTORY 000010000 /* must be a directory */
-#define O_NOFOLLOW 000000200 /* don't follow links */
-#define O_INVISIBLE 004000000 /* invisible I/O, for DMAPI/XDSM */
-
-#define O_PATH 020000000
-#define __O_TMPFILE 040000000
+#define O_NONBLOCK 0000200004 /* HPUX has separate NDELAY & NONBLOCK */
+#define O_NOCTTY 0000400000 /* not fcntl */
+#define O_DSYNC 0001000000 /* HPUX only */
+#define O_RSYNC 0002000000 /* HPUX only */
+#define O_NOATIME 0004000000
+#define O_CLOEXEC 0010000000 /* set close_on_exec */
+
+#define O_DIRECTORY 0000010000 /* must be a directory */
+#define O_NOFOLLOW 0000000200 /* don't follow links */
+#define O_INVISIBLE 0004000000 /* invisible I/O, for DMAPI/XDSM */
+
+#define O_PATH 0020000000
+#define __O_TMPFILE 0040000000
+#define O_EMPTYPATH 0100000000
#define F_GETLK64 8
#define F_SETLK64 9
diff --git a/arch/sparc/include/uapi/asm/fcntl.h b/arch/sparc/include/uapi/asm/fcntl.h
index 67dae75e5274..dc86c9eaf950 100644
--- a/arch/sparc/include/uapi/asm/fcntl.h
+++ b/arch/sparc/include/uapi/asm/fcntl.h
@@ -37,6 +37,7 @@
#define O_PATH 0x1000000
#define __O_TMPFILE 0x2000000
+#define O_EMPTYPATH 0x4000000
#define F_GETOWN 5 /* for sockets. */
#define F_SETOWN 6 /* for sockets. */
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 3d40771e8e7c..4cf05a2fd162 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -1031,7 +1031,7 @@ static int __init fcntl_init(void)
* Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
* is defined as O_NONBLOCK on some platforms and not on others.
*/
- BUILD_BUG_ON(21 - 1 /* for O_RDONLY being 0 */ !=
+ BUILD_BUG_ON(22 - 1 /* for O_RDONLY being 0 */ !=
HWEIGHT32(
(VALID_OPEN_FLAGS & ~(O_NONBLOCK | O_NDELAY)) |
__FMODE_EXEC | __FMODE_NONOTIFY));
diff --git a/fs/namei.c b/fs/namei.c
index 54d57dad0f91..e39b573fcc4d 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3571,6 +3571,24 @@ static int trailing_magiclink(struct nameidata *nd, int acc_mode,
return may_open_magiclink(upgrade_mask, acc_mode);
}
+static int do_emptypath(struct nameidata *nd, const struct open_flags *op,
+ struct file *file)
+{
+ int error;
+ /* We don't support AT_FDCWD (since O_PATH is disallowed here). */
+ struct fd f = fdget_raw(nd->dfd);
+
+ if (!f.file)
+ return -EBADF;
+
+ /* Apply trailing_magiclink()-like restrictions. */
+ error = may_open_magiclink(f.file->f_mode, op->acc_mode);
+ if (!error)
+ error = vfs_open(&f.file->f_path, file);
+ fdput(f);
+ return error;
+}
+
static struct file *path_openat(struct nameidata *nd,
const struct open_flags *op, unsigned flags)
{
@@ -3583,6 +3601,8 @@ static struct file *path_openat(struct nameidata *nd,
if (unlikely(file->f_flags & __O_TMPFILE)) {
error = do_tmpfile(nd, flags, op, file);
+ } else if (unlikely(file->f_flags & O_EMPTYPATH)) {
+ error = do_emptypath(nd, op, file);
} else if (unlikely(file->f_flags & O_PATH)) {
/* Inlined path_lookupat() with a trailing_magiclink() check. */
fmode_t opath_mask = op->opath_mask;
diff --git a/fs/open.c b/fs/open.c
index 806a75d685e1..310b896eecf0 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1015,6 +1015,8 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o
lookup_flags |= LOOKUP_DIRECTORY;
if (!(flags & O_NOFOLLOW))
lookup_flags |= LOOKUP_FOLLOW;
+ if (flags & O_EMPTYPATH)
+ lookup_flags |= LOOKUP_EMPTY;
op->lookup_flags = lookup_flags;
return 0;
}
@@ -1076,14 +1078,17 @@ long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
{
struct open_flags op;
int fd = build_open_flags(flags, mode, &op);
+ int empty = 0;
struct filename *tmp;
if (fd)
return fd;
- tmp = getname(filename);
+ tmp = getname_flags(filename, op.lookup_flags, &empty);
if (IS_ERR(tmp))
return PTR_ERR(tmp);
+ if (!empty)
+ op.open_flag &= ~O_EMPTYPATH;
fd = get_unused_fd_flags(flags);
if (fd >= 0) {
diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
index d019df946cb2..2868ae6c8fc1 100644
--- a/include/linux/fcntl.h
+++ b/include/linux/fcntl.h
@@ -9,7 +9,7 @@
(O_RDONLY | O_WRONLY | O_RDWR | O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC | \
O_APPEND | O_NDELAY | O_NONBLOCK | O_NDELAY | __O_SYNC | O_DSYNC | \
FASYNC | O_DIRECT | O_LARGEFILE | O_DIRECTORY | O_NOFOLLOW | \
- O_NOATIME | O_CLOEXEC | O_PATH | __O_TMPFILE)
+ O_NOATIME | O_CLOEXEC | O_PATH | __O_TMPFILE | O_EMPTYPATH)
#ifndef force_o_largefile
#define force_o_largefile() (!IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T))
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 9dc0bf0c5a6e..ae6862f69cc2 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -89,6 +89,10 @@
#define __O_TMPFILE 020000000
#endif
+#ifndef O_EMPTYPATH
+#define O_EMPTYPATH 040000000
+#endif
+
/* a horrid kludge trying to make sure that this will fail on old kernels */
#define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
#define O_TMPFILE_MASK (__O_TMPFILE | O_DIRECTORY | O_CREAT)
--
2.23.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