* [PATCH] arm64: dts: freescale: sl28: disable unused network port
From: Michael Walle @ 2020-02-20 18:09 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel; +Cc: Shawn Guo, Michael Walle
By default (and on variant 3) the second network port is not available.
Disable it. Now that its disabled, we have to explicitly enable it again
for board variant 4.
Signed-off-by: Michael Walle <michael@walle.cc>
---
.../boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
index f659e89face8..df212ed5bb94 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
@@ -21,6 +21,7 @@
&enetc_port1 {
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
+ status = "okay";
mdio {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
index d221ed471cde..6b3e710f6a2b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
@@ -35,6 +35,7 @@
&enetc_port0 {
phy-handle = <&phy0>;
phy-connection-type = "sgmii";
+ status = "okay";
mdio {
#address-cells = <1>;
@@ -48,6 +49,10 @@
};
};
+&enetc_port1 {
+ status = "disabled";
+};
+
&esdhc {
sd-uhs-sdr104;
sd-uhs-sdr50;
--
2.20.1
^ permalink raw reply related
* Re: [Nouveau] [PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
From: Frédéric Pierret @ 2020-02-20 18:09 UTC (permalink / raw)
To: Ilia Mirkin
Cc: Ben Skeggs, David Airlie, Daniel Vetter, dri-devel, nouveau, LKML
In-Reply-To: <CAKb7Uvh8Ob592LOizH9FGZz5ag=VJ3R=dh0G5iZSg2-JzWZFMQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2495 bytes --]
Hi Ilia,
Well...if Ben made it's own version you mean using my patch given on comment https://bugzilla.kernel.org/show_bug.cgi?id=206299#c9 and then adding commit message without quoting me as reporter ok...
At least, upstream is patched.
Best,
Frédéric
On 2020-02-20 18:32, Ilia Mirkin wrote:
> Hi Frédéric,
>
> It appears Ben made his own version of this patch (probably based on
> the one you added to the kernel bz), and it's already upstream:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2
>
> Cheers,
>
> -ilia
>
> On Thu, Feb 20, 2020 at 12:19 PM Frédéric Pierret
> <frederic.pierret@qubes-os.org> wrote:
>>
>> Hi,
>> Is anything missing here? How can I get this merged?
>>
>> Best regards,
>> Frédéric Pierret
>>
>> On 2020-02-08 20:43, Frédéric Pierret wrote:
>>> Pointer to structure array is assumed not NULL by default. It has
>>> the consequence to raise a kernel panic when it's not the case.
>>>
>>> Basically, running at least a RTX2080TI on Xen makes a bad mmio error
>>> which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the
>>> code, it's assumed to be not NULL by accessing directly 'mthd->data[0]'
>>> which is the reason of the kernel panic. Simply check if the pointer
>>> is not NULL before continuing.
>>>
>>> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206299
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org>
>>> ---
>>> drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> index bcf32d92ee5a..50e3539f33d2 100644
>>> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> @@ -74,6 +74,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
>>>
>>> if (debug > subdev->debug)
>>> return;
>>> + if (!mthd)
>>> + return;
>>>
>>> for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
>>> u32 base = chan->head * mthd->addr;
>>>
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: freescale: sl28: disable unused network port
From: Michael Walle @ 2020-02-20 18:09 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel; +Cc: Michael Walle, Shawn Guo
By default (and on variant 3) the second network port is not available.
Disable it. Now that its disabled, we have to explicitly enable it again
for board variant 4.
Signed-off-by: Michael Walle <michael@walle.cc>
---
.../boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
index f659e89face8..df212ed5bb94 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
@@ -21,6 +21,7 @@
&enetc_port1 {
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
+ status = "okay";
mdio {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
index d221ed471cde..6b3e710f6a2b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
@@ -35,6 +35,7 @@
&enetc_port0 {
phy-handle = <&phy0>;
phy-connection-type = "sgmii";
+ status = "okay";
mdio {
#address-cells = <1>;
@@ -48,6 +49,10 @@
};
};
+&enetc_port1 {
+ status = "disabled";
+};
+
&esdhc {
sd-uhs-sdr104;
sd-uhs-sdr50;
--
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
* Re: [PATCH net-next v5] net: page_pool: API cleanup and comments
From: David Miller @ 2020-02-20 18:09 UTC (permalink / raw)
To: ilias.apalodimas
Cc: netdev, jonathan.lemon, lorenzo, toke, brouer, thomas.petazzoni,
jaswinder.singh, peppe.cavallaro, alexandre.torgue, joabreu,
mcoquelin.stm32, hawk, kuba, ast, daniel, john.fastabend,
linux-kernel, linux-stm32, linux-arm-kernel, bpf
In-Reply-To: <20200220074155.765234-1-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 20 Feb 2020 09:41:55 +0200
> Functions starting with __ usually indicate those which are exported,
> but should not be called directly. Update some of those declared in the
> API and make it more readable.
>
> page_pool_unmap_page() and page_pool_release_page() were doing
> exactly the same thing calling __page_pool_clean_page(). Let's
> rename __page_pool_clean_page() to page_pool_release_page() and
> export it in order to show up on perf logs and get rid of
> page_pool_unmap_page().
>
> Finally rename __page_pool_put_page() to page_pool_put_page() since we
> can now directly call it from drivers and rename the existing
> page_pool_put_page() to page_pool_put_full_page() since they do the same
> thing but the latter is trying to sync the full DMA area.
>
> This patch also updates netsec, mvneta and stmmac drivers which use
> those functions.
>
> Suggested-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied, thanks Ilias.
^ permalink raw reply
* [Xen-devel] [PATCH] MAINTAINERS: Step back to designated reviewer for mm/
From: George Dunlap @ 2020-02-20 18:09 UTC (permalink / raw)
To: xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Wilk, Andrew Cooper,
George Dunlap, Julien Grall, Jan Beulich, Ian Jackson
With having to take over Lars' role as community manager, I don't have
the necessary time to review the mm/ subsystem. Step back to being only
a designated reviewer, reverting mantainership to the x86 maintianers.
While here, fix my e-mail address in other places.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien.grall@arm.com>
---
MAINTAINERS | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 46424c1833..a2a3e8d7d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -439,7 +439,7 @@ S: Supported
F: xen/common/sched/rt.c
SCHEDULING
-M: George Dunlap <george.dunlap@eu.citrix.com>
+M: George Dunlap <george.dunlap@citrix.com>
M: Dario Faggioli <dfaggioli@suse.com>
S: Supported
F: xen/common/sched/
@@ -544,7 +544,9 @@ F: xen/include/asm-x86/hvm/ioreq.h
F: xen/include/public/hvm/ioreq.h
X86 MEMORY MANAGEMENT
-M: George Dunlap <george.dunlap@eu.citrix.com>
+M: Jan Beulich <jbeulich@suse.com>
+M: Andrew Cooper <andrew.cooper3@citrix.com>
+R: George Dunlap <george.dunlap@citrix.com>
S: Supported
F: xen/arch/x86/mm/
@@ -575,7 +577,7 @@ F: xen/include/asm-x86/guest/hyperv-tlfs.h
F: xen/include/asm-x86/hvm/viridian.h
XENTRACE
-M: George Dunlap <george.dunlap@eu.citrix.com>
+M: George Dunlap <george.dunlap@citrix.com>
S: Supported
F: tools/xentrace/
F: xen/common/trace.c
@@ -591,7 +593,7 @@ F: docs/misc/xsm-flask.txt
THE REST
M: Andrew Cooper <andrew.cooper3@citrix.com>
-M: George Dunlap <George.Dunlap@eu.citrix.com>
+M: George Dunlap <george.dunlap@citrix.com>
M: Ian Jackson <ian.jackson@eu.citrix.com>
M: Jan Beulich <jbeulich@suse.com>
M: Julien Grall <julien@xen.org>
--
2.25.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH net-next v5] net: page_pool: API cleanup and comments
From: David Miller @ 2020-02-20 18:09 UTC (permalink / raw)
To: ilias.apalodimas
Cc: joabreu, kuba, alexandre.torgue, daniel, netdev, toke,
john.fastabend, ast, linux-kernel, jaswinder.singh,
jonathan.lemon, linux-arm-kernel, thomas.petazzoni, brouer,
peppe.cavallaro, bpf, lorenzo, linux-stm32, mcoquelin.stm32, hawk
In-Reply-To: <20200220074155.765234-1-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 20 Feb 2020 09:41:55 +0200
> Functions starting with __ usually indicate those which are exported,
> but should not be called directly. Update some of those declared in the
> API and make it more readable.
>
> page_pool_unmap_page() and page_pool_release_page() were doing
> exactly the same thing calling __page_pool_clean_page(). Let's
> rename __page_pool_clean_page() to page_pool_release_page() and
> export it in order to show up on perf logs and get rid of
> page_pool_unmap_page().
>
> Finally rename __page_pool_put_page() to page_pool_put_page() since we
> can now directly call it from drivers and rename the existing
> page_pool_put_page() to page_pool_put_full_page() since they do the same
> thing but the latter is trying to sync the full DMA area.
>
> This patch also updates netsec, mvneta and stmmac drivers which use
> those functions.
>
> Suggested-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied, thanks Ilias.
_______________________________________________
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 6/8] drm/vram-helper: don't use ttm bo->offset v2
From: Daniel Vetter @ 2020-02-20 18:09 UTC (permalink / raw)
To: Nirmoy Das
Cc: thellstrom, amd-gfx, airlied, kenny.ho, brian.welty, dri-devel,
nirmoy.das, linux-graphics-maintainer, kraxel, alexander.deucher,
sean, christian.koenig, bskeggs
In-Reply-To: <20200219135322.56463-7-nirmoy.das@amd.com>
On Wed, Feb 19, 2020 at 02:53:20PM +0100, Nirmoy Das wrote:
> Calculate GEM VRAM bo's offset within vram-helper without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 92a11bb42365..3edf5f241c15 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -198,6 +198,21 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo)
> }
> EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
>
> +/**
> + * drm_gem_vram_pg_offset() - Returns a GEM VRAM object's page offset
> + * @gbo: the GEM VRAM object
> + *
> + * Returns:
> + * The buffer object's page offset, or
> + * 0 with a warning when memory manager node of the buffer object is NULL
> + * */
We generally don't add full formal kerneldoc for internal functions like
this. It won't get pulled into generated docs and generally just bitrots.
Just informal comment if it's really tricky, but the function name here is
clear enough I think.
So with the comment removed:
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> +static s64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
> +{
> + if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
> + return 0;
> + return gbo->bo.mem.start;
> +}
> +
> /**
> * drm_gem_vram_offset() - \
> Returns a GEM VRAM object's offset in video memory
> @@ -214,7 +229,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
> {
> if (WARN_ON_ONCE(!gbo->pin_count))
> return (s64)-ENODEV;
> - return gbo->bo.offset;
> + return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
> }
> EXPORT_SYMBOL(drm_gem_vram_offset);
>
> --
> 2.25.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v2
From: Daniel Vetter @ 2020-02-20 18:09 UTC (permalink / raw)
To: Nirmoy Das
Cc: David1.Zhou, thellstrom, amd-gfx, airlied, kenny.ho, brian.welty,
maarten.lankhorst, dri-devel, nirmoy.das,
linux-graphics-maintainer, kraxel, daniel, alexander.deucher,
sean, christian.koenig, bskeggs
In-Reply-To: <20200219135322.56463-7-nirmoy.das@amd.com>
On Wed, Feb 19, 2020 at 02:53:20PM +0100, Nirmoy Das wrote:
> Calculate GEM VRAM bo's offset within vram-helper without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 92a11bb42365..3edf5f241c15 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -198,6 +198,21 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo)
> }
> EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
>
> +/**
> + * drm_gem_vram_pg_offset() - Returns a GEM VRAM object's page offset
> + * @gbo: the GEM VRAM object
> + *
> + * Returns:
> + * The buffer object's page offset, or
> + * 0 with a warning when memory manager node of the buffer object is NULL
> + * */
We generally don't add full formal kerneldoc for internal functions like
this. It won't get pulled into generated docs and generally just bitrots.
Just informal comment if it's really tricky, but the function name here is
clear enough I think.
So with the comment removed:
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> +static s64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
> +{
> + if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
> + return 0;
> + return gbo->bo.mem.start;
> +}
> +
> /**
> * drm_gem_vram_offset() - \
> Returns a GEM VRAM object's offset in video memory
> @@ -214,7 +229,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
> {
> if (WARN_ON_ONCE(!gbo->pin_count))
> return (s64)-ENODEV;
> - return gbo->bo.offset;
> + return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
> }
> EXPORT_SYMBOL(drm_gem_vram_offset);
>
> --
> 2.25.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [Xen-devel] [PATCH] MAINTAINERS: Step back to designated reviewer for mm/
From: Andrew Cooper @ 2020-02-20 18:10 UTC (permalink / raw)
To: George Dunlap, xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Wilk, Julien Grall,
Jan Beulich, Ian Jackson
In-Reply-To: <20200220180917.2988821-1-george.dunlap@citrix.com>
On 20/02/2020 18:09, George Dunlap wrote:
> With having to take over Lars' role as community manager, I don't have
> the necessary time to review the mm/ subsystem. Step back to being only
> a designated reviewer, reverting mantainership to the x86 maintianers.
>
> While here, fix my e-mail address in other places.
>
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [RFC PATCH 0/1] selinux: Add support for new key permissions
From: Richard Haines @ 2020-02-20 18:10 UTC (permalink / raw)
To: dhowells; +Cc: selinux, sds, paul, Richard Haines
I've been running this patch on my system for a few weeks now with no
problems, therefore I conclude that the key service only passes one
permission at a time.
Listed below is the output from the kernel logs regarding the permission
translations.
key_perms polcap = 0
entry_perm: 0x0001 exit_perm: 0x0001 view
entry_perm: 0x0002 exit_perm: 0x0002 read
entry_perm: 0x0004 exit_perm: 0x0004 write
entry_perm: 0x0008 exit_perm: 0x0008 search
entry_perm: 0x0010 exit_perm: 0x0010 link
entry_perm: 0x0020 exit_perm: 0x0020 setsec
entry_perm: 0x0040 exit_perm: 0x0008 inval/search
entry_perm: 0x0080 exit_perm: 0x0004 revoke/write
entry_perm: 0x0100 exit_perm: 0x0008 join/search
entry_perm: 0x0200 exit_perm: 0x0004 clear/write
entry_perm: 0x0400 exit_perm: 0x0010 parent_join/link
key_perms polcap = 1
entry_perm: 0x0001 exit_perm: 0x0001 view
entry_perm: 0x0002 exit_perm: 0x0002 read
entry_perm: 0x0004 exit_perm: 0x0004 write
entry_perm: 0x0008 exit_perm: 0x0008 search
entry_perm: 0x0010 exit_perm: 0x0010 link
entry_perm: 0x0020 exit_perm: 0x0020 setsec
entry_perm: 0x0040 exit_perm: 0x0080 inval
entry_perm: 0x0080 exit_perm: 0x0100 revoke
entry_perm: 0x0100 exit_perm: 0x0200 join
entry_perm: 0x0200 exit_perm: 0x0400 clear
entry_perm: 0x0400 exit_perm: 0x0200 parent_join/join
<--- key.h ----> <-- av_permissions.h -->
KEY_NEED_VIEW 0x001 KEY__VIEW 0x00000001U
KEY_NEED_READ 0x002 KEY__READ 0x00000002U
KEY_NEED_WRITE 0x004 KEY__WRITE 0x00000004U
KEY_NEED_SEARCH 0x008 KEY__SEARCH 0x00000008U
KEY_NEED_LINK 0x010 KEY__LINK 0x00000010U
KEY_NEED_SETSEC 0x020 KEY__SETATTR 0x00000020U
KEY_NEED_INVAL 0x040 KEY__INVAL 0x00000080U
KEY_NEED_REVOKE 0x080 KEY__REVOKE 0x00000100U
KEY_NEED_JOIN 0x100 KEY__JOIN 0x00000200U
KEY_NEED_CLEAR 0x200 KEY__CLEAR 0x00000400U
KEY_NEED_PARENT_JOIN 0x400 KEY__JOIN 0x00000200U
Richard Haines (1):
selinux: Add support for new key permissions
security/selinux/hooks.c | 123 ++++++++++++++++------------
security/selinux/include/security.h | 10 +--
security/selinux/ss/services.c | 4 +-
3 files changed, 76 insertions(+), 61 deletions(-)
--
2.24.1
^ permalink raw reply
* [RFC PATCH 1/1] selinux: Add support for new key permissions
From: Richard Haines @ 2020-02-20 18:10 UTC (permalink / raw)
To: dhowells; +Cc: selinux, sds, paul, Richard Haines
In-Reply-To: <20200220181031.156674-1-richard_c_haines@btinternet.com>
Add a new 'key_perms' policy capability and support for the additional
key permissions: inval, revoke, join, clear
Also fixes JOIN -> LINK permission translation when policy
capability 'keys_perms' = 0;
The current "setattr" perm name remains and is used for KEY_NEED_SETSEC.
This gives the following permissions for the 'key' class:
create Create a key or keyring.
view View attributes.
read Read contents.
write Update or modify.
search Search (keyring) or find (key).
link Link a key into the keyring.
setattr kernel < current version: Change permissions on a keyring.
kernel >= current version: Set owner, group, ACL.
inval Invalidate key.
revoke Revoke key.
join Join keyring as session.
clear Clear a keyring.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
security/selinux/hooks.c | 123 ++++++++++++++++------------
security/selinux/include/security.h | 10 +--
security/selinux/ss/services.c | 4 +-
3 files changed, 76 insertions(+), 61 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 46a8f3e7d..af179442c 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -6538,8 +6538,7 @@ static int selinux_key_permission(key_ref_t key_ref,
{
struct key *key;
struct key_security_struct *ksec;
- unsigned int key_perm = 0, switch_perm = 0;
- int bit = 1, count = KEY_NEED_ALL;
+ unsigned int key_perm = 0;
u32 sid;
/* if no specific permissions are requested, we skip the
@@ -6549,60 +6548,73 @@ static int selinux_key_permission(key_ref_t key_ref,
return 0;
if (selinux_policycap_key_perms()) {
- while (count) {
- switch_perm = bit & perm;
- switch (switch_perm) {
- case KEY_NEED_VIEW:
- key_perm |= KEY__VIEW;
- break;
- case KEY_NEED_READ:
- key_perm |= KEY__READ;
- break;
- case KEY_NEED_WRITE:
- key_perm |= KEY__WRITE;
- break;
- case KEY_NEED_SEARCH:
- key_perm |= KEY__SEARCH;
- break;
- case KEY_NEED_LINK:
- key_perm |= KEY__LINK;
- break;
- case KEY_NEED_SETSEC:
- key_perm |= KEY__SETATTR;
- break;
- case KEY_NEED_INVAL:
- key_perm |= KEY__INVAL;
- break;
- case KEY_NEED_REVOKE:
- key_perm |= KEY__REVOKE;
- break;
- case KEY_NEED_JOIN:
- case KEY_NEED_PARENT_JOIN:
- key_perm |= KEY__JOIN;
- break;
- case KEY_NEED_CLEAR:
- key_perm |= KEY__CLEAR;
- break;
- }
- bit <<= 1;
- count >>= 1;
+ switch (perm) {
+ case KEY_NEED_VIEW:
+ key_perm = KEY__VIEW;
+ break;
+ case KEY_NEED_READ:
+ key_perm = KEY__READ;
+ break;
+ case KEY_NEED_WRITE:
+ key_perm = KEY__WRITE;
+ break;
+ case KEY_NEED_SEARCH:
+ key_perm = KEY__SEARCH;
+ break;
+ case KEY_NEED_LINK:
+ key_perm = KEY__LINK;
+ break;
+ case KEY_NEED_SETSEC:
+ key_perm = KEY__SETATTR;
+ break;
+ case KEY_NEED_INVAL:
+ key_perm = KEY__INVAL;
+ break;
+ case KEY_NEED_REVOKE:
+ key_perm = KEY__REVOKE;
+ break;
+ case KEY_NEED_JOIN:
+ case KEY_NEED_PARENT_JOIN:
+ key_perm = KEY__JOIN;
+ break;
+ case KEY_NEED_CLEAR:
+ key_perm = KEY__CLEAR;
+ break;
+ default:
+ pr_err("BUG pcap = 1 entry_perm: 0x%04x\n", perm);
+ BUG();
+ break;
}
} else {
- key_perm = perm & (KEY_NEED_VIEW | KEY_NEED_READ |
- KEY_NEED_WRITE | KEY_NEED_SEARCH |
- KEY_NEED_LINK);
- if (perm & KEY_NEED_PARENT_JOIN)
- key_perm |= KEY_NEED_LINK;
- if (perm & KEY_NEED_SETSEC)
- key_perm |= OLD_KEY_NEED_SETATTR;
- if (perm & KEY_NEED_INVAL)
- key_perm |= KEY_NEED_SEARCH;
- if (perm & KEY_NEED_REVOKE && !(perm & OLD_KEY_NEED_SETATTR))
- key_perm |= KEY_NEED_WRITE;
- if (perm & KEY_NEED_JOIN)
- key_perm |= KEY_NEED_SEARCH;
- if (perm & KEY_NEED_CLEAR)
- key_perm |= KEY_NEED_WRITE;
+ switch (perm) {
+ case KEY_NEED_VIEW:
+ key_perm = KEY_NEED_VIEW;
+ break;
+ case KEY_NEED_READ:
+ key_perm = KEY_NEED_READ;
+ break;
+ case KEY_NEED_WRITE:
+ case KEY_NEED_REVOKE:
+ case KEY_NEED_CLEAR:
+ key_perm = KEY_NEED_WRITE;
+ break;
+ case KEY_NEED_SEARCH:
+ case KEY_NEED_INVAL:
+ case KEY_NEED_JOIN:
+ key_perm = KEY_NEED_SEARCH;
+ break;
+ case KEY_NEED_LINK:
+ case KEY_NEED_PARENT_JOIN:
+ key_perm = KEY_NEED_LINK;
+ break;
+ case KEY_NEED_SETSEC:
+ key_perm = OLD_KEY_NEED_SETATTR;
+ break;
+ default:
+ pr_err("BUG pcap = 0 entry_perm: 0x%04x\n", perm);
+ BUG();
+ break;
+ }
}
sid = cred_sid(cred);
@@ -6610,6 +6622,9 @@ static int selinux_key_permission(key_ref_t key_ref,
key = key_ref_to_ptr(key_ref);
ksec = key->security;
+ pr_info("entry_perm: 0x%04x exit_perm: 0x%04x\n",
+ perm, key_perm);
+
return avc_has_perm(&selinux_state,
sid, ksec->sid, SECCLASS_KEY, key_perm, NULL);
}
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index cba9610b8..c0998e79d 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -79,8 +79,8 @@ enum {
POLICYDB_CAPABILITY_ALWAYSNETWORK,
POLICYDB_CAPABILITY_CGROUPSECLABEL,
POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION,
- POLICYDB_CAPABILITY_KEYPERMS,
POLICYDB_CAPABILITY_GENFS_SECLABEL_SYMLINKS,
+ POLICYDB_CAPABILITY_KEYPERMS,
__POLICYDB_CAPABILITY_MAX
};
#define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
@@ -215,18 +215,18 @@ static inline bool selinux_policycap_nnp_nosuid_transition(void)
return state->policycap[POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION];
}
-static inline bool selinux_policycap_key_perms(void)
+static inline bool selinux_policycap_genfs_seclabel_symlinks(void)
{
struct selinux_state *state = &selinux_state;
- return state->policycap[POLICYDB_CAPABILITY_KEYPERMS];
+ return state->policycap[POLICYDB_CAPABILITY_GENFS_SECLABEL_SYMLINKS];
}
-static inline bool selinux_policycap_genfs_seclabel_symlinks(void)
+static inline bool selinux_policycap_key_perms(void)
{
struct selinux_state *state = &selinux_state;
- return state->policycap[POLICYDB_CAPABILITY_GENFS_SECLABEL_SYMLINKS];
+ return state->policycap[POLICYDB_CAPABILITY_KEYPERMS];
}
int security_mls_enabled(struct selinux_state *state);
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index d4a05f34d..6efc86c47 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -73,8 +73,8 @@ const char *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
"always_check_network",
"cgroup_seclabel",
"nnp_nosuid_transition",
- "key_perms",
- "genfs_seclabel_symlinks"
+ "genfs_seclabel_symlinks",
+ "key_perms"
};
static struct selinux_ss selinux_ss;
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] lib: make a test module with set/clear bit
From: Peter Zijlstra @ 2020-02-20 18:10 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: tglx, mingo, bp, x86, linux-kernel, linux, andriy.shevchenko,
dan.j.williams
In-Reply-To: <20200220173722.2034546-2-jesse.brandeburg@intel.com>
On Thu, Feb 20, 2020 at 09:37:22AM -0800, Jesse Brandeburg wrote:
> Test some bit clears/sets to make sure assembly doesn't change.
> Instruct Kbuild to build this file with extra warning level -Wextra,
> to catch new issues, and also doesn't hurt to build with C=1.
>
> This was used to test changes to arch/x86/include/asm/bitops.h.
>
> Recommended usage:
> make defconfig
> scripts/config -m CONFIG_TEST_BITOPS
> make modules_prepare
> make C=1 W=1 lib/test_bitops.ko
> objdump -S -d lib/test_bitops.ko
I only applied this second patch:
# sparse --version
0.6.0 (Debian: 0.6.0-3+b1)
# grep TEST_BITOPS defconfig-build/.config
CONFIG_TEST_BITOPS=m
# make C=1 W=1 O=defconfig-build/ lib/test_bitops.ko
make[1]: Entering directory '/usr/src/linux-2.6/defconfig-build'
GEN Makefile
HOSTCC scripts/basic/fixdep
HOSTCC arch/x86/tools/relocs_32.o
HOSTCC arch/x86/tools/relocs_64.o
HOSTCC arch/x86/tools/relocs_common.o
HOSTLD arch/x86/tools/relocs
HOSTCC scripts/selinux/genheaders/genheaders
HOSTCC scripts/selinux/mdp/mdp
HOSTCC scripts/kallsyms
HOSTCC scripts/sorttable
HOSTCC scripts/asn1_compiler
HOSTCC scripts/extract-cert
HOSTCC scripts/mod/mk_elfconfig
CHECK ../scripts/mod/empty.c
CC scripts/mod/empty.o
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
CC scripts/mod/devicetable-offsets.s
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
CC kernel/bounds.s
CC arch/x86/kernel/asm-offsets.s
CALL ../scripts/checksyscalls.sh
CALL ../scripts/atomic/check-atomics.sh
DESCEND objtool
HOSTCC /usr/src/linux-2.6/defconfig-build/tools/objtool/fixdep.o
HOSTLD /usr/src/linux-2.6/defconfig-build/tools/objtool/fixdep-in.o
LINK /usr/src/linux-2.6/defconfig-build/tools/objtool/fixdep
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/exec-cmd.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/help.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/pager.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/parse-options.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/run-command.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/sigchain.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/subcmd-config.o
LD /usr/src/linux-2.6/defconfig-build/tools/objtool/libsubcmd-in.o
AR /usr/src/linux-2.6/defconfig-build/tools/objtool/libsubcmd.a
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/arch/x86/decode.o
LD /usr/src/linux-2.6/defconfig-build/tools/objtool/arch/x86/objtool-in.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/builtin-check.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/builtin-orc.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/check.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/orc_gen.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/orc_dump.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/elf.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/special.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/objtool.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/libstring.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/libctype.o
CC /usr/src/linux-2.6/defconfig-build/tools/objtool/str_error_r.o
LD /usr/src/linux-2.6/defconfig-build/tools/objtool/objtool-in.o
LINK /usr/src/linux-2.6/defconfig-build/tools/objtool/objtool
CHECK ../lib/test_bitops.c
CC [M] lib/test_bitops.o
MODPOST 1 modules
CC [M] lib/test_bitops.mod.o
LD [M] lib/test_bitops.ko
make[1]: Leaving directory '/usr/src/linux-2.6/defconfig-build'
No warnings for me!
^ permalink raw reply
* Re: [PATCH net-next] net: use netif_is_bridge_port() to check for IFF_BRIDGE_PORT
From: David Miller @ 2020-02-20 18:10 UTC (permalink / raw)
To: jwi; +Cc: netdev, johannes, roopa, nikolay
In-Reply-To: <20200220080007.51862-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Thu, 20 Feb 2020 09:00:07 +0100
> Trivial cleanup, so that all bridge port-specific code can be found in
> one go.
>
> CC: Johannes Berg <johannes@sipsolutions.net>
> CC: Roopa Prabhu <roopa@cumulusnetworks.com>
> CC: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/4] net: ll_temac: Add more error handling of dma_map_single() calls
From: David Miller @ 2020-02-20 18:11 UTC (permalink / raw)
To: esben; +Cc: netdev, linux-arm-kernel, linux-kernel, andrew, michal.simek,
ynezz
In-Reply-To: <87v9o18xqd.fsf@geanix.com>
From: Esben Haabendal <esben@geanix.com>
Date: Thu, 20 Feb 2020 09:32:58 +0100
> David Miller <davem@davemloft.net> writes:
>
>> From: Esben Haabendal <esben@geanix.com>
>> Date: Wed, 19 Feb 2020 11:54:00 +0100
>>
>>> @@ -863,12 +865,13 @@ temac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>>> skb_dma_addr = dma_map_single(ndev->dev.parent, skb->data,
>>> skb_headlen(skb), DMA_TO_DEVICE);
>>> cur_p->len = cpu_to_be32(skb_headlen(skb));
>>> + if (WARN_ON_ONCE(dma_mapping_error(ndev->dev.parent, skb_dma_addr)))
>>> + return NETDEV_TX_BUSY;
>>
>> The appropriate behavior in this situation is to drop the packet and return
>> NETDEV_TX_OK.
>
> Ok, and I guess the same goes for the error handling of dma_map_single()
> of one of the fragments later in same function.
Yes.
^ permalink raw reply
* Re: [PATCH net 2/4] net: ll_temac: Add more error handling of dma_map_single() calls
From: David Miller @ 2020-02-20 18:11 UTC (permalink / raw)
To: esben; +Cc: andrew, netdev, michal.simek, linux-kernel, ynezz,
linux-arm-kernel
In-Reply-To: <87v9o18xqd.fsf@geanix.com>
From: Esben Haabendal <esben@geanix.com>
Date: Thu, 20 Feb 2020 09:32:58 +0100
> David Miller <davem@davemloft.net> writes:
>
>> From: Esben Haabendal <esben@geanix.com>
>> Date: Wed, 19 Feb 2020 11:54:00 +0100
>>
>>> @@ -863,12 +865,13 @@ temac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>>> skb_dma_addr = dma_map_single(ndev->dev.parent, skb->data,
>>> skb_headlen(skb), DMA_TO_DEVICE);
>>> cur_p->len = cpu_to_be32(skb_headlen(skb));
>>> + if (WARN_ON_ONCE(dma_mapping_error(ndev->dev.parent, skb_dma_addr)))
>>> + return NETDEV_TX_BUSY;
>>
>> The appropriate behavior in this situation is to drop the packet and return
>> NETDEV_TX_OK.
>
> Ok, and I guess the same goes for the error handling of dma_map_single()
> of one of the fragments later in same function.
Yes.
_______________________________________________
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 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset v2
From: Daniel Vetter @ 2020-02-20 18:11 UTC (permalink / raw)
To: Nirmoy Das
Cc: David1.Zhou, thellstrom, amd-gfx, airlied, kenny.ho, brian.welty,
maarten.lankhorst, dri-devel, nirmoy.das,
linux-graphics-maintainer, kraxel, daniel, alexander.deucher,
sean, christian.koenig, bskeggs
In-Reply-To: <20200219135322.56463-8-nirmoy.das@amd.com>
On Wed, Feb 19, 2020 at 02:53:21PM +0100, Nirmoy Das wrote:
> Switch over to GEM VRAM's implementation to retrieve bo->offset
>
> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c
> index 8066d7d370d5..18d2ec34534d 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -29,16 +29,21 @@ static void bochs_plane_update(struct bochs_device *bochs,
> struct drm_plane_state *state)
> {
> struct drm_gem_vram_object *gbo;
> + s64 gpu_addr;
>
> if (!state->fb || !bochs->stride)
> return;
>
> gbo = drm_gem_vram_of_gem(state->fb->obj[0]);
> + gpu_addr = drm_gem_vram_offset(gbo);
> + if (WARN_ON_ONCE(gpu_addr < 0))
> + return; /* Bug: we didn't pin the BO to VRAM in prepare_fb. */
That negative errno in gpu_addr from vram helpers is kinda wild.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> +
> bochs_hw_setbase(bochs,
> state->crtc_x,
> state->crtc_y,
> state->fb->pitches[0],
> - state->fb->offsets[0] + gbo->bo.offset);
> + state->fb->offsets[0] + gpu_addr);
> bochs_hw_setformat(bochs, state->fb->format);
> }
>
> --
> 2.25.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset v2
From: Daniel Vetter @ 2020-02-20 18:11 UTC (permalink / raw)
To: Nirmoy Das
Cc: thellstrom, amd-gfx, airlied, kenny.ho, brian.welty, dri-devel,
nirmoy.das, linux-graphics-maintainer, kraxel, alexander.deucher,
sean, christian.koenig, bskeggs
In-Reply-To: <20200219135322.56463-8-nirmoy.das@amd.com>
On Wed, Feb 19, 2020 at 02:53:21PM +0100, Nirmoy Das wrote:
> Switch over to GEM VRAM's implementation to retrieve bo->offset
>
> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c
> index 8066d7d370d5..18d2ec34534d 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -29,16 +29,21 @@ static void bochs_plane_update(struct bochs_device *bochs,
> struct drm_plane_state *state)
> {
> struct drm_gem_vram_object *gbo;
> + s64 gpu_addr;
>
> if (!state->fb || !bochs->stride)
> return;
>
> gbo = drm_gem_vram_of_gem(state->fb->obj[0]);
> + gpu_addr = drm_gem_vram_offset(gbo);
> + if (WARN_ON_ONCE(gpu_addr < 0))
> + return; /* Bug: we didn't pin the BO to VRAM in prepare_fb. */
That negative errno in gpu_addr from vram helpers is kinda wild.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> +
> bochs_hw_setbase(bochs,
> state->crtc_x,
> state->crtc_y,
> state->fb->pitches[0],
> - state->fb->offsets[0] + gbo->bo.offset);
> + state->fb->offsets[0] + gpu_addr);
> bochs_hw_setformat(bochs, state->fb->format);
> }
>
> --
> 2.25.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC PATCH 1/3] efi/x86: Use symbolic constants in PE header instead of bare numbers
From: Arvind Sankar @ 2020-02-20 18:11 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Arvind Sankar, linux-efi, Laszlo Ersek, Leif Lindholm,
Peter Jones, Matthew Garrett, Alexander Graf, Ilias Apalodimas,
Heinrich Schuchardt, Daniel Kiper, James Bottomley
In-Reply-To: <20200220180454.GA2436919@rani.riverdale.lan>
On Thu, Feb 20, 2020 at 01:04:54PM -0500, Arvind Sankar wrote:
> On Thu, Feb 20, 2020 at 06:32:39PM +0100, Ard Biesheuvel wrote:
> > Another thing I wondered was whether we really need the .reloc
> > section. We don't have one on ARM, and it works fine with the existing
> > EDK2 loader.
> > Peter: any idea whether the issue with .reloc you pointed out to me
> > the other day still exists in EDK2 today?
>
> commit 743628e868c5 ("x86, efi stub: Add .reloc section back into
> image") says that
> Some UEFI firmware will not load a .efi with a .reloc section
> with a size of 0.
>
> Is that the issue you're refering to? It is a bit odd, since we actually
> leave base relocation table at a size of zero with an RVA of zero, so it
> shouldn't even look at the .reloc section according to the spec. At
> least current EKD2 code doesn't seem to -- I think it would even work if
> you specify fewer tables than 6 so that the base relocation table is
> missing altogether.
Another couple of odd things are that the PE header is supposed to be
8-byte aligned which we don't do, and NumberOfSymbols is set to 1 --
should be 0, no?
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 18:11 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20200220175744.GQ37466@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 4112 bytes --]
* Tony Lindgren <tony@atomide.com> [200220 17:58]:
> * Andrew F. Davis <afd@ti.com> [200220 17:39]:
> > On 2/20/20 12:13 PM, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [200220 16:37]:
> > >> * Andrew F. Davis <afd@ti.com> [200220 16:24]:
> > >>> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> > >>>> * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> > >>>>> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> > >>>>>> Andrew,
> > >>>>>>
> > >>>>>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> > >>>>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > >>>>>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> > >>>>>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> > >>>>>>> date: 3 weeks ago
> > >>>>>>> config: arm-randconfig-a001-20200213 (attached as .config)
> > >>>>>>> compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
> > >>>>>>> reproduce:
> > >>>>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >>>>>>> chmod +x ~/bin/make.cross
> > >>>>>>> git checkout c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> > >>>>>>> # save the attached .config to linux build tree
> > >>>>>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> > >>>>>>>
> > >>>>>>> If you fix the issue, kindly add following tag
> > >>>>>>> Reported-by: kbuild test robot <lkp@intel.com>
> > >>>>>>>
> > >>>>>>> All errors (new ones prefixed by >>):
> > >>>>>>>
> > >>>>>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> > >>>>>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> > >>>>>>
> > >>>>>> Have you looked at this one? Looks like there's still an unhandled
> > >>>>>> randconfig build case.
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> I've had a quick look, all the ARM config does:
> > >>>>>
> > >>>>> select HAVE_ARM_SMCCC if CPU_V7
> > >>>>>
> > >>>>> so I don't think this will happen in any real config, but if we want to
> > >>>>> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> > >>>>> on it.
> > >>>>
> > >>>> Seems to happen at least with omap2 only config where we don't have
> > >>>> CPU_V7. Something like below seems to fix it.
> > >>>>
> > >>>> If that looks OK to you, I'll send out a proper fix.
> > >>>>
> > >>>
> > >>>
> > >>> This looks fine to me.
> > >>>
> > >>> A better later fix might be to later stub out the actual __arm_smccc_smc
> > >>> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> > >>> get the fix.
> > >>
> > >> Yeah seems that might be better. Adding Aaro and Marc to Cc.
> > >
> > > But if we can in theory have some arm11 machine with smccc, then this
> > > local ifdef below is probably the way to go.
> > >
> >
> > If the machine has SMCCC then it will also have the
> > CONFIG_HAVE_ARM_SMCCC set and so nothing would change.
>
> Hmm yeah good point.
So the patch below seems like the way to go then. Anybody have issues
with the patch below?
Regards,
Tony
8< -------------------------
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -121,6 +121,7 @@ struct arm_smccc_quirk {
} state;
};
+#ifdef CONFIG_HAVE_ARM_SMCCC
/**
* __arm_smccc_smc() - make SMC calls
* @a0-a7: arguments passed in registers 0 to 7
@@ -137,6 +138,14 @@ asmlinkage void __arm_smccc_smc(unsigned long a0, unsigned long a1,
unsigned long a2, unsigned long a3, unsigned long a4,
unsigned long a5, unsigned long a6, unsigned long a7,
struct arm_smccc_res *res, struct arm_smccc_quirk *quirk);
+#else
+static inline void __arm_smccc_smc(unsigned long a0, unsigned long a1,
+ unsigned long a2, unsigned long a3, unsigned long a4,
+ unsigned long a5, unsigned long a6, unsigned long a7,
+ struct arm_smccc_res *res, struct arm_smccc_quirk *quirk)
+{
+}
+#endif
/**
* __arm_smccc_hvc() - make HVC calls
^ permalink raw reply
* Re: [RFC PATCH] security,anon_inodes,kvm: enable security support for anon inodes
From: Casey Schaufler @ 2020-02-20 18:11 UTC (permalink / raw)
To: Paul Moore, linux-security-module, linux-fsdevel, viro
Cc: selinux, kvm, dancol, nnk, Stephen Smalley
In-Reply-To: <CAHC9VhSsjrgu2Jn+yiV5Bz_wt2x5bgEXdhjqLA+duWYNo4gOtw@mail.gmail.com>
On 2/17/2020 4:14 PM, Paul Moore wrote:
> On Thu, Feb 13, 2020 at 2:41 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> Add support for labeling and controlling access to files attached to anon
>> inodes. Introduce extended interfaces for creating such files to permit
>> passing a related file as an input to decide how to label the anon
>> inode. Define a security hook for initializing the anon inode security
>> attributes. Security attributes are either inherited from a related file
>> or determined based on some combination of the creating task and policy
>> (in the case of SELinux, using type_transition rules). As an
>> example user of the inheritance support, convert kvm to use the new
>> interface for passing the related file so that the anon inode can inherit
>> the security attributes of /dev/kvm and provide consistent access control
>> for subsequent ioctl operations. Other users of anon inodes, including
>> userfaultfd, will default to the transition-based mechanism instead.
>>
>> Compared to the series in
>> https://lore.kernel.org/selinux/20200211225547.235083-1-dancol@google.com/,
>> this approach differs in that it does not require creation of a separate
>> anonymous inode for each file (instead storing the per-instance security
>> information in the file security blob), it applies labeling and control
>> to all users of anonymous inodes rather than requiring opt-in via a new
>> flag, it supports labeling based on a related inode if provided,
>> it relies on type transitions to compute the label of the anon inode
>> when there is no related inode, and it does not require introducing a new
>> security class for each user of anonymous inodes.
>>
>> On the other hand, the approach in this patch does expose the name passed
>> by the creator of the anon inode to the policy (an indirect mapping could
>> be provided within SELinux if these names aren't considered to be stable),
>> requires the definition of type_transition rules to distinguish userfaultfd
>> inodes from proc inodes based on type since they share the same class,
>> doesn't support denying the creation of anonymous inodes (making the hook
>> added by this patch return something other than void is problematic due to
>> it being called after the file is already allocated and error handling in
>> the callers can't presently account for this scenario and end up calling
>> release methods multiple times), and may be more expensive
>> (security_transition_sid overhead on each anon inode allocation).
>>
>> We are primarily posting this RFC patch now so that the two different
>> approaches can be concretely compared. We anticipate a hybrid of the
>> two approaches being the likely outcome in the end. In particular
>> if support for allocating a separate inode for each of these files
>> is acceptable, then we would favor storing the security information
>> in the inode security blob and using it instead of the file security
>> blob.
> Bringing this back up in hopes of attracting some attention from the
> fs-devel crowd and Al. As Stephen already mentioned, from a SELinux
> perspective we would prefer to attach the security blob to the inode
> as opposed to the file struct; does anyone have any objections to
> that?
Sorry for the delay - been sick the past few days.
I agree that the inode is a better place than the file for information
about the inode. This is especially true for Smack, which uses
multiple extended attributes in some cases. I don't believe that any
except the access label will be relevant to anonymous inodes, but
I can imagine security modules with policies that would.
I am always an advocate of full xattr support. It goes a long
way in reducing the number and complexity of special case interfaces.
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 18:11 UTC (permalink / raw)
To: Andrew F. Davis
Cc: kbuild-all, linux-kernel, kbuild test robot, linux-omap,
Aaro Koskinen, Marc Zyngier, linux-arm-kernel, Arnd Bergmann,
Rob Herring
In-Reply-To: <20200220175744.GQ37466@atomide.com>
* Tony Lindgren <tony@atomide.com> [200220 17:58]:
> * Andrew F. Davis <afd@ti.com> [200220 17:39]:
> > On 2/20/20 12:13 PM, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [200220 16:37]:
> > >> * Andrew F. Davis <afd@ti.com> [200220 16:24]:
> > >>> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> > >>>> * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> > >>>>> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> > >>>>>> Andrew,
> > >>>>>>
> > >>>>>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> > >>>>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > >>>>>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> > >>>>>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> > >>>>>>> date: 3 weeks ago
> > >>>>>>> config: arm-randconfig-a001-20200213 (attached as .config)
> > >>>>>>> compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
> > >>>>>>> reproduce:
> > >>>>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >>>>>>> chmod +x ~/bin/make.cross
> > >>>>>>> git checkout c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> > >>>>>>> # save the attached .config to linux build tree
> > >>>>>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> > >>>>>>>
> > >>>>>>> If you fix the issue, kindly add following tag
> > >>>>>>> Reported-by: kbuild test robot <lkp@intel.com>
> > >>>>>>>
> > >>>>>>> All errors (new ones prefixed by >>):
> > >>>>>>>
> > >>>>>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> > >>>>>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> > >>>>>>
> > >>>>>> Have you looked at this one? Looks like there's still an unhandled
> > >>>>>> randconfig build case.
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> I've had a quick look, all the ARM config does:
> > >>>>>
> > >>>>> select HAVE_ARM_SMCCC if CPU_V7
> > >>>>>
> > >>>>> so I don't think this will happen in any real config, but if we want to
> > >>>>> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> > >>>>> on it.
> > >>>>
> > >>>> Seems to happen at least with omap2 only config where we don't have
> > >>>> CPU_V7. Something like below seems to fix it.
> > >>>>
> > >>>> If that looks OK to you, I'll send out a proper fix.
> > >>>>
> > >>>
> > >>>
> > >>> This looks fine to me.
> > >>>
> > >>> A better later fix might be to later stub out the actual __arm_smccc_smc
> > >>> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> > >>> get the fix.
> > >>
> > >> Yeah seems that might be better. Adding Aaro and Marc to Cc.
> > >
> > > But if we can in theory have some arm11 machine with smccc, then this
> > > local ifdef below is probably the way to go.
> > >
> >
> > If the machine has SMCCC then it will also have the
> > CONFIG_HAVE_ARM_SMCCC set and so nothing would change.
>
> Hmm yeah good point.
So the patch below seems like the way to go then. Anybody have issues
with the patch below?
Regards,
Tony
8< -------------------------
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -121,6 +121,7 @@ struct arm_smccc_quirk {
} state;
};
+#ifdef CONFIG_HAVE_ARM_SMCCC
/**
* __arm_smccc_smc() - make SMC calls
* @a0-a7: arguments passed in registers 0 to 7
@@ -137,6 +138,14 @@ asmlinkage void __arm_smccc_smc(unsigned long a0, unsigned long a1,
unsigned long a2, unsigned long a3, unsigned long a4,
unsigned long a5, unsigned long a6, unsigned long a7,
struct arm_smccc_res *res, struct arm_smccc_quirk *quirk);
+#else
+static inline void __arm_smccc_smc(unsigned long a0, unsigned long a1,
+ unsigned long a2, unsigned long a3, unsigned long a4,
+ unsigned long a5, unsigned long a6, unsigned long a7,
+ struct arm_smccc_res *res, struct arm_smccc_quirk *quirk)
+{
+}
+#endif
/**
* __arm_smccc_hvc() - make HVC calls
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 18:11 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Rob Herring, kbuild-all, kbuild test robot, Arnd Bergmann,
Aaro Koskinen, Marc Zyngier, linux-kernel, linux-omap,
linux-arm-kernel
In-Reply-To: <20200220175744.GQ37466@atomide.com>
* Tony Lindgren <tony@atomide.com> [200220 17:58]:
> * Andrew F. Davis <afd@ti.com> [200220 17:39]:
> > On 2/20/20 12:13 PM, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [200220 16:37]:
> > >> * Andrew F. Davis <afd@ti.com> [200220 16:24]:
> > >>> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> > >>>> * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> > >>>>> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> > >>>>>> Andrew,
> > >>>>>>
> > >>>>>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> > >>>>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > >>>>>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> > >>>>>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> > >>>>>>> date: 3 weeks ago
> > >>>>>>> config: arm-randconfig-a001-20200213 (attached as .config)
> > >>>>>>> compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
> > >>>>>>> reproduce:
> > >>>>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >>>>>>> chmod +x ~/bin/make.cross
> > >>>>>>> git checkout c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> > >>>>>>> # save the attached .config to linux build tree
> > >>>>>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> > >>>>>>>
> > >>>>>>> If you fix the issue, kindly add following tag
> > >>>>>>> Reported-by: kbuild test robot <lkp@intel.com>
> > >>>>>>>
> > >>>>>>> All errors (new ones prefixed by >>):
> > >>>>>>>
> > >>>>>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> > >>>>>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> > >>>>>>
> > >>>>>> Have you looked at this one? Looks like there's still an unhandled
> > >>>>>> randconfig build case.
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> I've had a quick look, all the ARM config does:
> > >>>>>
> > >>>>> select HAVE_ARM_SMCCC if CPU_V7
> > >>>>>
> > >>>>> so I don't think this will happen in any real config, but if we want to
> > >>>>> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> > >>>>> on it.
> > >>>>
> > >>>> Seems to happen at least with omap2 only config where we don't have
> > >>>> CPU_V7. Something like below seems to fix it.
> > >>>>
> > >>>> If that looks OK to you, I'll send out a proper fix.
> > >>>>
> > >>>
> > >>>
> > >>> This looks fine to me.
> > >>>
> > >>> A better later fix might be to later stub out the actual __arm_smccc_smc
> > >>> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> > >>> get the fix.
> > >>
> > >> Yeah seems that might be better. Adding Aaro and Marc to Cc.
> > >
> > > But if we can in theory have some arm11 machine with smccc, then this
> > > local ifdef below is probably the way to go.
> > >
> >
> > If the machine has SMCCC then it will also have the
> > CONFIG_HAVE_ARM_SMCCC set and so nothing would change.
>
> Hmm yeah good point.
So the patch below seems like the way to go then. Anybody have issues
with the patch below?
Regards,
Tony
8< -------------------------
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -121,6 +121,7 @@ struct arm_smccc_quirk {
} state;
};
+#ifdef CONFIG_HAVE_ARM_SMCCC
/**
* __arm_smccc_smc() - make SMC calls
* @a0-a7: arguments passed in registers 0 to 7
@@ -137,6 +138,14 @@ asmlinkage void __arm_smccc_smc(unsigned long a0, unsigned long a1,
unsigned long a2, unsigned long a3, unsigned long a4,
unsigned long a5, unsigned long a6, unsigned long a7,
struct arm_smccc_res *res, struct arm_smccc_quirk *quirk);
+#else
+static inline void __arm_smccc_smc(unsigned long a0, unsigned long a1,
+ unsigned long a2, unsigned long a3, unsigned long a4,
+ unsigned long a5, unsigned long a6, unsigned long a7,
+ struct arm_smccc_res *res, struct arm_smccc_quirk *quirk)
+{
+}
+#endif
/**
* __arm_smccc_hvc() - make HVC calls
_______________________________________________
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 net-next 2/3] net: dsa: mv88e6xxx: fix duplicate vlan warning
From: Russell King - ARM Linux admin @ 2020-02-20 18:12 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Heiner Kallweit, Vivien Didelot, Ido Schimmel,
David S. Miller, netdev
In-Reply-To: <20200218162750.GR31084@lunn.ch>
On Tue, Feb 18, 2020 at 05:27:50PM +0100, Andrew Lunn wrote:
> On Tue, Feb 18, 2020 at 11:51:57AM +0000, Russell King - ARM Linux admin wrote:
> > On Tue, Feb 18, 2020 at 11:46:14AM +0000, Russell King wrote:
> > > When setting VLANs on DSA switches, the VLAN is added to both the port
> > > concerned as well as the CPU port by dsa_slave_vlan_add(). If multiple
> > > ports are configured with the same VLAN ID, this triggers a warning on
> > > the CPU port.
> > >
> > > Avoid this warning for CPU ports.
> > >
> > > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >
> > Note that there is still something not right. On the ZII dev rev B,
> > setting up a bridge across all the switch ports, I get:
>
> Hi Russell
>
> FYI: You need to be a little careful with VLANs on rev B. The third
> switch does not have the PVT hardware. So VLANs are going to 'leak'
> when they cross the DSA link to that switch.
I'm not sure I fully understand what you're saying or the mechanism
behind it.
From what I can see, the 88E6352 and the 88E6185 both contain a VTU
which is capable of taking an ingressing frame and restricting which
ports it can egress from.
If a frame ingresses on one 88E6352, passed across to the other
88E6352, and finally to the 88E6185, doesn't each switch look up in
its own VTU which ports to egress the packet from, which should
include the DSA ports, so it can then be passed to the other switches?
And doesn't the VTU on each switch define which ports the frame is
allowed to egress out of?
From what I can see, setting up a bridge across all lan ports on the
Zii rev B, then enabling vlan filtering, and then allowing VID V on
lan0 and lan8 (one port on each 88E6352, passed across to the other
88E6352, and finally to the 88E6185 which has the other port on)
results in VID V frames passed correctly across, and are received
appropriately. Untagged traffic continues to be received
appropriately.
Removing VID V from lan8 (the port I'm monitoring) results in VID V
traffic no longer sent out via lan8.
So, it seems to work as one would expect.
What am I missing?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH v2 1/2] x86: fix bitops.h warning with a moved cast
From: Peter Zijlstra @ 2020-02-20 18:12 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: tglx, mingo, bp, x86, linux-kernel, linux, andriy.shevchenko,
dan.j.williams
In-Reply-To: <20200220173722.2034546-1-jesse.brandeburg@intel.com>
On Thu, Feb 20, 2020 at 09:37:21AM -0800, Jesse Brandeburg wrote:
> Fix many sparse warnings when building with C=1.
>
> When the kernel is compiled with C=1, there are lots of messages like:
> arch/x86/include/asm/bitops.h:77:37: warning: cast truncates bits from constant value (ffffff7f becomes 7f)
>
> @@ -72,9 +74,11 @@ static __always_inline void
> arch_clear_bit(long nr, volatile unsigned long *addr)
> {
> if (__builtin_constant_p(nr)) {
> + u8 cmaski = ~CONST_MASK(nr);
> +
> asm volatile(LOCK_PREFIX "andb %1,%0"
> : CONST_MASK_ADDR(nr, addr)
> - : "iq" ((u8)~CONST_MASK(nr)));
> + : "iq" (cmaski));
> } else {
> asm volatile(LOCK_PREFIX __ASM_SIZE(btr) " %1,%0"
> : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
Urgh, that's sad. So why doesn't this still generate a warning, ~ should
promote your u8 to int, and then you down-cast to u8 on assignment
again.
So now you have more lines, more ugly casts and exactly the same
generated code; where the win?
Perhaps you should write it like:
: "iq" (0xFF ^ CONST_MASK(nr))
hmm?
^ permalink raw reply
* Re: [PATCH v26 10/22] x86/sgx: Linux Enclave Driver
From: Sean Christopherson @ 2020-02-20 18:13 UTC (permalink / raw)
To: Jordan Hand
Cc: Jarkko Sakkinen, linux-kernel, x86, linux-sgx, akpm, dave.hansen,
nhorman, npmccallum, haitao.huang, andriy.shevchenko, tglx,
kai.svahn, bp, josh, luto, kai.huang, rientjes, cedric.xing,
puiterwijk, linux-security-module, Suresh Siddha, Haitao Huang
In-Reply-To: <15074c16-4832-456d-dd12-af8548e46d6d@linux.microsoft.com>
On Tue, Feb 18, 2020 at 07:26:31PM -0800, Jordan Hand wrote:
> I ran our validation tests for the Open Enclave SDK against this patch
> set and came across a potential issue.
>
> On 2/9/20 1:25 PM, Jarkko Sakkinen wrote:
> > +/**
> > + * sgx_encl_may_map() - Check if a requested VMA mapping is allowed
> > + * @encl: an enclave
> > + * @start: lower bound of the address range, inclusive
> > + * @end: upper bound of the address range, exclusive
> > + * @vm_prot_bits: requested protections of the address range
> > + *
> > + * Iterate through the enclave pages contained within [@start, @end) to verify
> > + * the permissions requested by @vm_prot_bits do not exceed that of any enclave
> > + * page to be mapped. Page addresses that do not have an associated enclave
> > + * page are interpreted to zero permissions.
> > + *
> > + * Return:
> > + * 0 on success,
> > + * -EACCES if VMA permissions exceed enclave page permissions
> > + */
> > +int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start,
> > + unsigned long end, unsigned long vm_prot_bits)
> > +{
> > + unsigned long idx, idx_start, idx_end;
> > + struct sgx_encl_page *page;
> > +
> > + /* PROT_NONE always succeeds. */
> > + if (!vm_prot_bits)
> > + return 0;
> > +
> > + idx_start = PFN_DOWN(start);
> > + idx_end = PFN_DOWN(end - 1);
> > +
> > + for (idx = idx_start; idx <= idx_end; ++idx) {
> > + mutex_lock(&encl->lock);
> > + page = radix_tree_lookup(&encl->page_tree, idx);
> > + mutex_unlock(&encl->lock);
> > +
> > + if (!page || (~page->vm_max_prot_bits & vm_prot_bits))
> > + return -EACCES;
> > + }
> > +
> > + return 0;
> > +}
> > +static struct sgx_encl_page *sgx_encl_page_alloc(struct sgx_encl *encl,
> > + unsigned long offset,
> > + u64 secinfo_flags)
> > +{
> > + struct sgx_encl_page *encl_page;
> > + unsigned long prot;
> > +
> > + encl_page = kzalloc(sizeof(*encl_page), GFP_KERNEL);
> > + if (!encl_page)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + encl_page->desc = encl->base + offset;
> > + encl_page->encl = encl;
> > +
> > + prot = _calc_vm_trans(secinfo_flags, SGX_SECINFO_R, PROT_READ) |
> > + _calc_vm_trans(secinfo_flags, SGX_SECINFO_W, PROT_WRITE) |
> > + _calc_vm_trans(secinfo_flags, SGX_SECINFO_X, PROT_EXEC);
> > +
> > + /*
> > + * TCS pages must always RW set for CPU access while the SECINFO
> > + * permissions are *always* zero - the CPU ignores the user provided
> > + * values and silently overwrites them with zero permissions.
> > + */
> > + if ((secinfo_flags & SGX_SECINFO_PAGE_TYPE_MASK) == SGX_SECINFO_TCS)
> > + prot |= PROT_READ | PROT_WRITE;
> > +
> > + /* Calculate maximum of the VM flags for the page. */
> > + encl_page->vm_max_prot_bits = calc_vm_prot_bits(prot, 0);
>
> During mprotect (in mm/mprotect.c line 525) the following checks if
> READ_IMPLIES_EXECUTE and a PROT_READ is being requested. If so and
> VM_MAYEXEC is set, it also adds PROT_EXEC to the request.
>
> if (rier && (vma->vm_flags & VM_MAYEXEC))
> prot |= PROT_EXEC;
>
> But if we look at sgx_encl_page_alloc(), we see vm_max_prot_bits is set
> without taking VM_MAYEXEC into account:
>
> encl_page->vm_max_prot_bits = calc_vm_prot_bits(prot, 0);
>
> sgx_encl_may_map() checks that the requested protection can be added with:
>
> if (!page || (~page->vm_max_prot_bits & vm_prot_bits))
> return -EACCESS
>
> This means that for any process where READ_IMPLIES_EXECUTE is set and
> page where (vma->vm_flags & VM_MAYEXEC) == true, mmap/mprotect calls to
> that request PROT_READ on a page that was not added with PROT_EXEC will
> fail.
I could've sworn this was discussed on the SGX list at one point, but
apparently we only discussed it internally. Anyways...
More than likely, the READ_IMPLIES_EXECUTE (RIE) crud rears its head
because part of the enclave loader is written in assembly. Unless
explicitly told otherwise, the linker assumes that any program with
assembly code may need an executable stack, which leads to the RIE
personality being set for the process. Here's a fantastic write up for
more details: https://www.airs.com/blog/archives/518
There are essentially two paths we can take:
1) Exempt EPC pages from RIE during mmap()/mprotect(), i.e. don't add
PROT_EXEC for enclaves.
2) Punt the issue to userspace.
Option (1) is desirable in some ways:
- Enclaves will get an executable stack if and only if the loader/creator
intentionally configures it to have an executable stack.
- Separates enclaves from the personality of the loader.
- Userspace doesn't have to do anything for the common case of not
wanting an executable stack for its enclaves.
The big down side to (1) is that it'd require an ugly hook in architecture
agnostic code. And arguably, it reduces the overall security of the
platform (more below).
For (2), userspace has a few options:
a) Tell the linker the enclave loader doesn't need RIE, either via a .note
in assembly files or via the global "-z noexecstack" flag.
b) Spawn a separate process to run/map the enclave if the enclave loader
needs RIE.
c) Require enclaves to allow PROT_EXEC on all pages. Note, this is an
absolutely terrible idea and only included for completeness.
As shown by the lack of a mmap()/mprotect() hook in this series to squash
RIE, we chose option (2). Given that enclave loaders are not legacy code
and hopefully following decent coding practices, option (2a) should suffice
for all loaders. The security benefit mentioned above is that forcing
enclave loaders to squash RIE eliminates an exectuable stack as an attack
vector on the loader.
If for some reason a loader "needs" an executable stack, requiring such a
beast to jump through a few hoops to run sane enclaves doesn't seem too
onerous.
This obviously needs to be called out in the kernel docs.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.