[PATCH 4.19 061/114] fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types
From: Ard Biesheuvel
commit f8585539df0a1527c78b5d760665c89fe1c105a9 upstream.
The following commit:
38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping
the FB")
updated the EFI framebuffer code to use memory mappings for the linear
framebuffer that are permitted by the memory attributes described by the
EFI memory map for the particular region, if the framebuffer happens to
be covered by the EFI memory map (which is typically only the case for
framebuffers in shared memory). This is required since non-x86 systems
may require cacheable attributes for memory mappings that are shared
with other masters (such as GPUs), and this information cannot be
described by the Graphics Output Protocol (GOP) EFI protocol itself,
and so we rely on the EFI memory map for this.
As reported by James, this breaks some x86 systems:
[ 1.173368] efifb: probing for efifb
[ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf80
[ 1.173395] Trying to free nonexistent resource
[ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5
The problem turns out to be that the memory map entry that describes the
framebuffer has no memory attributes listed at all, and so we end up with
a mem_flags value of 0x0.
So work around this by ensuring that the memory map entry's attribute field
has a sane value before using it to mask the set of usable attributes.
Reported-by: James Hilliard
Tested-by: James Hilliard
Signed-off-by: Ard Biesheuvel
Cc: # v4.19+
Cc: Borislav Petkov
Cc: James Morse
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Jones
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-efi@vger.kernel.org
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...")
Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
drivers/video/fbdev/efifb.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -476,8 +476,12 @@ static int efifb_probe(struct platform_d
* If the UEFI memory map covers the efifb region, we may only
* remap it using the attributes the memory map prescribes.
*/
- mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
- mem_flags &= md.attribute;
+ md.attribute &= EFI_MEMORY_UC | EFI_MEMORY_WC |
+ EFI_MEMORY_WT | EFI_MEMORY_WB;
+ if (md.attribute) {
+ mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
+ mem_flags &= md.attribute;
+ }
}
if (mem_flags & EFI_MEMORY_WC)
info->screen_base = ioremap_wc(efifb_fix.smem_start,
[PATCH 5.0 076/139] fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types
From: Ard Biesheuvel
commit f8585539df0a1527c78b5d760665c89fe1c105a9 upstream.
The following commit:
38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping
the FB")
updated the EFI framebuffer code to use memory mappings for the linear
framebuffer that are permitted by the memory attributes described by the
EFI memory map for the particular region, if the framebuffer happens to
be covered by the EFI memory map (which is typically only the case for
framebuffers in shared memory). This is required since non-x86 systems
may require cacheable attributes for memory mappings that are shared
with other masters (such as GPUs), and this information cannot be
described by the Graphics Output Protocol (GOP) EFI protocol itself,
and so we rely on the EFI memory map for this.
As reported by James, this breaks some x86 systems:
[ 1.173368] efifb: probing for efifb
[ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf80
[ 1.173395] Trying to free nonexistent resource
[ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5
The problem turns out to be that the memory map entry that describes the
framebuffer has no memory attributes listed at all, and so we end up with
a mem_flags value of 0x0.
So work around this by ensuring that the memory map entry's attribute field
has a sane value before using it to mask the set of usable attributes.
Reported-by: James Hilliard
Tested-by: James Hilliard
Signed-off-by: Ard Biesheuvel
Cc: # v4.19+
Cc: Borislav Petkov
Cc: James Morse
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Jones
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-efi@vger.kernel.org
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...")
Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
drivers/video/fbdev/efifb.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -476,8 +476,12 @@ static int efifb_probe(struct platform_d
* If the UEFI memory map covers the efifb region, we may only
* remap it using the attributes the memory map prescribes.
*/
- mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
- mem_flags &= md.attribute;
+ md.attribute &= EFI_MEMORY_UC | EFI_MEMORY_WC |
+ EFI_MEMORY_WT | EFI_MEMORY_WB;
+ if (md.attribute) {
+ mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
+ mem_flags &= md.attribute;
+ }
}
if (mem_flags & EFI_MEMORY_WC)
info->screen_base = ioremap_wc(efifb_fix.smem_start,
[PATCH 5.1 085/122] fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types
From: Ard Biesheuvel
commit f8585539df0a1527c78b5d760665c89fe1c105a9 upstream.
The following commit:
38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping
the FB")
updated the EFI framebuffer code to use memory mappings for the linear
framebuffer that are permitted by the memory attributes described by the
EFI memory map for the particular region, if the framebuffer happens to
be covered by the EFI memory map (which is typically only the case for
framebuffers in shared memory). This is required since non-x86 systems
may require cacheable attributes for memory mappings that are shared
with other masters (such as GPUs), and this information cannot be
described by the Graphics Output Protocol (GOP) EFI protocol itself,
and so we rely on the EFI memory map for this.
As reported by James, this breaks some x86 systems:
[ 1.173368] efifb: probing for efifb
[ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf80
[ 1.173395] Trying to free nonexistent resource
[ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5
The problem turns out to be that the memory map entry that describes the
framebuffer has no memory attributes listed at all, and so we end up with
a mem_flags value of 0x0.
So work around this by ensuring that the memory map entry's attribute field
has a sane value before using it to mask the set of usable attributes.
Reported-by: James Hilliard
Tested-by: James Hilliard
Signed-off-by: Ard Biesheuvel
Cc: # v4.19+
Cc: Borislav Petkov
Cc: James Morse
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Jones
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-efi@vger.kernel.org
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...")
Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
drivers/video/fbdev/efifb.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -476,8 +476,12 @@ static int efifb_probe(struct platform_d
* If the UEFI memory map covers the efifb region, we may only
* remap it using the attributes the memory map prescribes.
*/
- mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
- mem_flags &= md.attribute;
+ md.attribute &= EFI_MEMORY_UC | EFI_MEMORY_WC |
+ EFI_MEMORY_WT | EFI_MEMORY_WB;
+ if (md.attribute) {
+ mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
+ mem_flags &= md.attribute;
+ }
}
if (mem_flags & EFI_MEMORY_WC)
info->screen_base = ioremap_wc(efifb_fix.smem_start,
Re: [PATCH V7 0/4] Add support for crypto agile logs
On Thu, 23 May 2019, Jarkko Sakkinen wrote: > On Thu, May 23, 2019 at 03:14:49PM +0300, Jarkko Sakkinen wrote: > > On Mon, May 20, 2019 at 01:54:57PM -0700, Matthew Garrett wrote: > > > Identical to previous version except without the KSAN workaround - Ard > > > has a better solution for that. > > > > > > Reviewed-by: Jarkko Sakkinen > > Tested-by: Jarkko Sakkinen > > Only applied to my master at this point becaues the patches from > my earlier PRs are not yet mirrored to security/next-general. Which PRs are these? btw, Linus wants security subsystem maintainers to submit PRs directly to him from now on. I'll only be carrying patches for the core LSM and new security mechanisms before they're merged and have a maintainer assigned. -- James Morris
Re: [PATCH V7 0/4] Add support for crypto agile logs
On Mon, May 20, 2019 at 10:55 PM Matthew Garrett wrote: > > Identical to previous version except without the KSAN workaround - Ard > has a better solution for that. Just tested the patchset on aarch64, all works fine. Reviewed-by: Bartosz Szczepanek Tested-by: Bartosz Szczepanek
Re: [PATCH V7 0/4] Add support for crypto agile logs
On Thu, May 23, 2019 at 03:14:49PM +0300, Jarkko Sakkinen wrote: > On Mon, May 20, 2019 at 01:54:57PM -0700, Matthew Garrett wrote: > > Identical to previous version except without the KSAN workaround - Ard > > has a better solution for that. > > > Reviewed-by: Jarkko Sakkinen > Tested-by: Jarkko Sakkinen Only applied to my master at this point becaues the patches from my earlier PRs are not yet mirrored to security/next-general. /Jarkko
Re: [PATCH V7 0/4] Add support for crypto agile logs
On Mon, May 20, 2019 at 01:54:57PM -0700, Matthew Garrett wrote: > Identical to previous version except without the KSAN workaround - Ard > has a better solution for that. Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen /Jarkko
