"FIXME: add error handling" in
kexec_enter_virtual_mode().
Signed-off-by: Sai Praneeth Prakhya
Cc: Borislav Petkov
Cc: Ingo Molnar
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/efi.h | 6 +++---
arch/x86/platform/efi/efi.c| 21 +-
arch/x86/platform/efi/efi_32.c |
onality intended.
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar
[ardb: move changes to upstream libfdt into local header]
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/libstub/Makefile | 4 +-
drivers/firmware/efi/libstub/efistub.h | 11 +
Replace all GPL license blurbs with an equivalent SPDX header (most
files are GPLv2, some are GPLv2+). While at it, drop some outdated
header changelogs as well.
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/apple-properties.c | 13 +
drivers/firmware/efi/arm-init.c
earlycon=efifb, is likely to be useful
to diagnose boot issues on such systems if they have no accessible serial
port)
Cc: Alexander Graf
Cc: Heinrich Schuchardt
Cc: AKASHI Takahiro
Cc: Leif Lindholm
Tested-by: Jeffrey Hugo
Tested-by: Bjorn Andersson
Tested-by: Lee Jones
Signed-off-by: Ard Bi
- Implement earlycon=efifb based on existing earlyprintk code
- Move BGRT table handling to earlier in the boot so we don't overwrite it
- Various minor fixes and code cleanups from Sai, Ingo and Ard
----
Ard Biesheuvel (7):
nt generic support for the Memory ...")
Acked-by: Sai Praneeth Prakhya
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/memattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index 8986757eafaf..aac9
stake, given that no code seems to exist that actually enforces that
or relies on it.
Reported-by: Heinrich Schuchardt
Reviewed-by: Leif Lindholm
Signed-off-by: Ard Biesheuvel
---
include/linux/efi.h | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/linux/ef
From: Sai Praneeth Prakhya
can_free_region() is called only once during _boot_ by
efi_reserve_boot_services(). Hence, mark it as __init function.
Signed-off-by: Sai Praneeth Prakhya
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/efi/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1
the boot.
Also note that we cannot take the 'acpi_disabled' global variable
into account, since it may not have assumed the correct value yet
(on arm64, the default value is '1' which is overridden to '0' if
no DT description has been made available by the firmwar
fined, even for i386 (and changing that results in a slew of build errors)
So instead, build those routines only if CONFIG_AMD_MEM_ENCRYPT is
defined.
Signed-off-by: Ard Biesheuvel
---
arch/Kconfig | 3 +++
arch/x86/Kconfig | 5 +
arch/x86/mm/ioremap.c | 4 ++--
3 files changed,
not populate its struct screen_info early
enough for earlycon=efifb to work, so it is disabled there.
Reviewed-by: Alexander Graf
Signed-off-by: Ard Biesheuvel
---
.../admin-guide/kernel-parameters.txt | 8 +-
arch/x86/Kconfig.debug| 10 --
arch/x86/include/asm
; https://lore.kernel.org/lkml/20190122144114.9816-3-gre...@linuxfoundation.org/
>
> Signed-off-by: Nathan Chancellor
Acked-by: Ard Biesheuvel
Catalin, Will,
Could you please apply this directly?
> ---
> drivers/firmware/efi/arm-runtime.c | 6 +++---
> 1 file changed, 3 insertio
On Tue, 29 Jan 2019 at 18:36, Qian Cai wrote:
>
> Read efi_page_tables debugfs triggering an out-of-bounds access here,
>
> arch/arm64/mm/dump.c: 282
> if (addr >= st->marker[1].start_address) {
>
> from,
>
> arch/arm64/mm/dump.c: 331
> note_page(st, addr, 2, pud_val(pud));
>
> because st->marker+
(+ Bjorn)
On Mon, 28 Jan 2019 at 12:27, Vivek Gautam wrote:
>
> Hi Ard,
>
> On Thu, Jan 24, 2019 at 1:25 PM Ard Biesheuvel
> wrote:
> >
> > On Thu, 24 Jan 2019 at 07:58, Vivek Gautam
> > wrote:
> > >
> > > On Mon, Jan 21, 2019 at 7:55 PM Ard
hange anything on that front.
Fixes: b48ac83d6bbc2 ("irqchip: GICv3: ITS: MSI support")
Cc: # v4.4 - v4.9
Reported-by: Ard Biesheuvel
Tested-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
[ardb: rebased onto v4.9.153, should apply cleanly onto v4.4.y as well]
Signed-off-by: Ard Biesheuve
On Wed, 9 Jan 2019 at 11:46, Hedi Berriche wrote:
>
> Calls into UV firmware must be protected against concurrency, use the
> now visible efi_runtime_sem lock to serialise them.
>
> Signed-off-by: Hedi Berriche
> Reviewed-by: Russ Anderson
> Reviewed-by: Mike Travis
> Reviewed-by: Dimitri Sivan
Wahl
Please drop these reviewed-bys
Acked-by: Ard Biesheuvel
> ---
> arch/x86/include/asm/uv/bios.h | 1 -
> arch/x86/platform/uv/bios_uv.c | 12
> 2 files changed, 13 deletions(-)
>
> diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h
Hello Hedi,
On Wed, 9 Jan 2019 at 11:46, Hedi Berriche wrote:
>
> Make efi_runtime_lock semaphore global so that it can be used by EFI
> runtime callers that may be defined outside efi/runtime-wrappers.c.
>
> The immediate motivation is to piggy-back it to serialise UV platform BIOS
> calls.
>
>
(+ masahiro)
On Fri, 25 Jan 2019 at 14:28, Ard Biesheuvel wrote:
>
> On Thu, 17 Jan 2019 at 23:46, wrote:
> >
> > From: Eugene Loh
> >
> > When checking for symbols with excessively long names,
> > account for null terminating character.
> >
>
On Thu, 17 Jan 2019 at 23:46, wrote:
>
> From: Eugene Loh
>
> When checking for symbols with excessively long names,
> account for null terminating character.
>
> Fixes: f3462aa952cf ("Kbuild: Handle longer symbols in kallsyms.c")
> Signed-off-by: Eug
On Fri, 25 Jan 2019 at 12:30, Christian König
wrote:
>
> Am 25.01.19 um 09:43 schrieb Ard Biesheuvel:
> > On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote:
> >> On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel
> >> wrote:
> >>> On Thu, 24 Jan 201
__pure makes sense and is a good idea
> for documentation purposes and possible future optimizations,
> which also silences the warning.
>
> Signed-off-by: Miguel Ojeda
Acked-by: Ard Biesheuvel
> ---
> I am picking this up through the compiler-attributes tree
> and putt
On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote:
>
> On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel
> wrote:
> >
> > On Thu, 24 Jan 2019 at 13:31, Koenig, Christian
> > wrote:
> > >
> > > Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> > >
On Thu, 24 Jan 2019 at 14:14, Corentin Labbe wrote:
>
> On Thu, Jan 24, 2019 at 01:36:23PM +0100, Ard Biesheuvel wrote:
> > On Wed, 23 Jan 2019 at 23:53, Eric Biggers wrote:
> > >
> > > From: Eric Biggers
> > >
> > > Convert alg_test_skciphe
On Thu, 24 Jan 2019 at 14:54, Alex Deucher wrote:
>
> On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel
> wrote:
> >
> > On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> > wrote:
> > >
> > > Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> >
On Wed, 23 Jan 2019 at 23:53, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Convert alg_test_skcipher() to use the new test framework, adding a list
> of testvec_configs to test by default. When the extra self-tests are
> enabled, randomly generated testvec_configs are tested as well.
>
> This
On Thu, 24 Jan 2019 at 13:31, Koenig, Christian
wrote:
>
> Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> > The DRM driver stack is designed to work with cache coherent devices
> > only, but permits an optimization to be enabled in some cases, where
> > for some buffers,
code to return the final keystream block when needed.
>
> Fixes: 88a3f582bea9 ("crypto: arm64/aes - don't use IV buffer to return final
> keystream block")
> Cc: # v4.11+
> Cc: Ard Biesheuvel
> Signed-off-by: Eric Biggers
Reviewed-by: Ard Biesheuvel
> ---
Reported-by: Carsten Haitzler
Signed-off-by: Ard Biesheuvel
---
include/drm/drm_cache.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index bfe1639df02d..97fc498dc767 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm
On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
wrote:
>
> Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > wrote:
> >> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> >>> [SNIP]
> >>> This is
On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> > [SNIP]
> > This is *exactly* my point the whole time.
> >
> > The current code has
> >
> > static inline bool drm_arch_can_wc_memory(void)
>
On Thu, 24 Jan 2019 at 10:24, Herbert Xu wrote:
>
> On Thu, Jan 24, 2019 at 09:50:35AM +0100, Ard Biesheuvel wrote:
> >
> > Thanks for yet another round of cleanup
> >
> > I'll look into these, but I'd like to clarify one thing first.
> >
> >
On Thu, 24 Jan 2019 at 10:45, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:28 schrieb Ard Biesheuvel:
> > On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
> > wrote:
> >> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> >>> On Wed, Jan 23, 2019 at
On Thu, 24 Jan 2019 at 10:31, Michel Dänzer wrote:
>
> On 2019-01-23 5:52 p.m., Ard Biesheuvel wrote:
> > On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
> >>
> >> I think we just want a driver-local check for those combinations
> >> where we know
On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> > On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
> >> But my concern is that it seems likely that non-cache coherent
> >> implementations ar
On Thu, 24 Jan 2019 at 09:48, Eric Biggers wrote:
>
> On Wed, Jan 23, 2019 at 02:49:11PM -0800, Eric Biggers wrote:
> > Hello,
> >
> > Crypto algorithms must produce the same output for the same input
> > regardless of data layout, i.e. how the src and dst scatterlists are
> > divided into chunks
On Thu, 24 Jan 2019 at 07:58, Vivek Gautam wrote:
>
> On Mon, Jan 21, 2019 at 7:55 PM Ard Biesheuvel
> wrote:
> >
> > On Mon, 21 Jan 2019 at 14:56, Robin Murphy wrote:
> > >
> > > On 21/01/2019 13:36, Ard Biesheuvel wrote:
> > > >
On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
>
> I think we just want a driver-local check for those combinations
> where we know this hack actually works, which really just seems
> to be x86-64 with PAT. Something like the patch below, but maybe with
> even more strong warnings to not d
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote:
>
> On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > > Variables declared in a switch statement before any case statements
> > > cannot be initialized, so move all instances out of the
On Wed, 23 Jan 2019 at 09:56, Julien Thierry wrote:
>
>
>
> On 22/01/2019 20:18, Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 16:36, Julien Thierry wrote:
> >>
> >> CPU does not received signals for interrupts with a priority masked by
> >> ICC_PM
On Wed, 23 Jan 2019 at 08:15, Christoph Hellwig wrote:
>
> On Tue, Jan 22, 2019 at 10:07:07PM +0100, Ard Biesheuvel wrote:
> > Yes, so much was clear. And the reason this breaks on some arm64
> > systems is because
> > a) non-snooped PCIe TLP attributes may be ignored, an
On Tue, 22 Jan 2019 at 21:56, Alex Deucher wrote:
>
> On Tue, Jan 22, 2019 at 4:19 AM Ard Biesheuvel
> wrote:
> >
> > On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
> > >
> > > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > > >
On Mon, 21 Jan 2019 at 16:36, Julien Thierry wrote:
>
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
> Since the logic of
On Tue, 22 Jan 2019 at 14:28, Torsten Duwe wrote:
>
> On Tue, Jan 22, 2019 at 10:18:17AM +, Julien Thierry wrote:
> > Hi Torsten,
> >
> > A few suggestions below.
> >
> > > +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> > > +#define ARCH_SUPPORTS_FTRACE_OPS 1
> > > +#define REC_IP_BRANCH_OFFSET AAR
On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
>
> On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
> >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wro
On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
>
> On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
> >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wro
On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
>
> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
> >>
> >> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 18:55, Mich
On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
>
> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
> >>
> >> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019
On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>
> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
> >
> >> Until that happens we should just change the driver ifdefs to default
> >> the hacks t
On Mon, 21 Jan 2019 at 17:35, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 05:30:00PM +0100, Ard Biesheuvel wrote:
> > > Until that happens we should just change the driver ifdefs to default
> > > the hacks to off and only enable them on setups where we 100%
&g
On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 05:14:37PM +0100, Ard Biesheuvel wrote:
> > > I'll add big fat comments. But the fact that nothing is exported
> > > there should be a fairly big hint.
> > >
> >
&
On Mon, 21 Jan 2019 at 16:59, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote:
> > >
> > > > +#include
> > >
> > > This header is not fo
PSR.[DAIF] for the irqflags.
>
> Signed-off-by: Julien Thierry
> Suggested-by: Daniel Thompson
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Ard Biesheuvel
> Cc: Oleg Nesterov
> ---
> arch/arm64/include/asm/efi.h | 6 +
urn from a runtime service.
> This allows to check for flags that are not necesarly related to
> irqflags.
>
> Signed-off-by: Julien Thierry
> Acked-by: Catalin Marinas
> Cc: Ard Biesheuvel
> Cc: linux-...@vger.kernel.org
> ---
> drivers/firmware/efi/runtime-wrappers.c
On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote:
>
> > +#include
>
> This header is not for usage in device drivers, but purely for
> dma-mapping implementations!
>
Is that documented anywhere?
> > +static inline bool drm_device_can_wc_memory(struct drm_device *ddev)
> > {
> > + if (
On Mon, 21 Jan 2019 at 14:56, Robin Murphy wrote:
>
> On 21/01/2019 13:36, Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 14:25, Robin Murphy wrote:
> >>
> >> On 21/01/2019 10:50, Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 11:17, Vi
On Mon, 21 Jan 2019 at 14:25, Robin Murphy wrote:
>
> On 21/01/2019 10:50, Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 11:17, Vivek Gautam
> > wrote:
> >>
> >> Hi,
> >>
> >>
> >> On Mon, Jan 21, 2019 at 12:56 PM Ard Biesheuv
On Mon, 21 Jan 2019 at 13:59, Sumit Garg wrote:
>
> On Mon, 21 Jan 2019 at 15:33, Ard Biesheuvel
> wrote:
> >
> > On Mon, 21 Jan 2019 at 10:30, Sumit Garg wrote:
> > >
> > > On ARM SoC's with TrustZone enabled, peripherals like entropy sources
&
On Mon, 21 Jan 2019 at 11:17, Vivek Gautam wrote:
>
> Hi,
>
>
> On Mon, Jan 21, 2019 at 12:56 PM Ard Biesheuvel
> wrote:
> >
> > On Mon, 21 Jan 2019 at 06:54, Vivek Gautam
> > wrote:
> > >
> > > Qualcomm SoCs have an additional level of cac
On Mon, 21 Jan 2019 at 11:30, Greg KH wrote:
>
> On Mon, Jan 21, 2019 at 02:59:19PM +0530, Sumit Garg wrote:
> > --- /dev/null
> > +++ b/drivers/char/hw_random/optee-rng.c
> > @@ -0,0 +1,272 @@
> > +// SPDX-License-Identifier: GPL-2.0
>
> Nice, but:
>
>
>
> > +MODULE_LICENSE("GPL");
>
> This stri
stian Koenig
Cc: Alex Deucher
Cc: David Zhou
Cc: Huang Rui
Cc: Junwei Zhang
Cc: Michel Daenzer
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Will Deacon
Reported-by: Carsten Haitzler
Signed-off-by
On Mon, 21 Jan 2019 at 10:30, Sumit Garg wrote:
>
> On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> might not be accessible to normal world (linux in this case) and rather
> accessible to secure world (OP-TEE in this case) only. So this driver
> aims to provides a generic i
On Mon, 21 Jan 2019 at 06:54, Vivek Gautam wrote:
>
> Qualcomm SoCs have an additional level of cache called as
> System cache, aka. Last level cache (LLC). This cache sits right
> before the DDR, and is tightly coupled with the memory controller.
> The clients using this cache request their slice
On Sun, 20 Jan 2019 at 02:51, Kees Cook wrote:
>
> On Fri, Jan 18, 2019 at 2:58 AM Ard Biesheuvel
> wrote:
> >
> > A couple of fixes to permit newer versions of GCC to use the stack
> > protector plugin for ARM.
> >
> > Ard Biesheuvel (2):
> > gcc-
The ARM per-task stack protector GCC plugin hits an assert in
the compiler in some case, due to the fact the the SP mask
expression is not sign-extended as it should be. So fix that.
Suggested-by: Kugan Vivekanandarajah
Signed-off-by: Ard Biesheuvel
---
scripts/gcc-plugins
GCC9+.
Signed-off-by: Ard Biesheuvel
---
scripts/gcc-plugins/arm_ssp_per_task_plugin.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/scripts/gcc-plugins/arm_ssp_per_task_plugin.c
b/scripts/gcc-plugins/arm_ssp_per_task_plugin.c
index a65fbefb8501..89c47f57d1ce 100644
A couple of fixes to permit newer versions of GCC to use the stack
protector plugin for ARM.
Ard Biesheuvel (2):
gcc-plugins: arm_ssp_per_task_plugin: sign extend the SP mask
gcc-plugins: arm_ssp_per_task_plugin: fix for GCC 9+
scripts/gcc-plugins/arm_ssp_per_task_plugin.c | 23
On Thu, 17 Jan 2019 at 07:07, Benjamin Herrenschmidt
wrote:
>
> On Wed, 2019-01-16 at 08:47 +0100, Ard Biesheuvel wrote:
> > > As far as I know on x86 it doesn't, so when you have an un-cached page
> > > you can still access it with a snooping DMA read/write op
On Wed, 16 Jan 2019 at 04:37, Yueyi Li wrote:
>
> OK, thanks. But seems this mail be ignored, do i need re-sent the patch?
>
> On 2018/12/26 21:49, Ard Biesheuvel wrote:
> > On Tue, 25 Dec 2018 at 03:30, Yueyi Li wrote:
> >> Hi Ard,
> >>
> >>
&
On Wed, 16 Jan 2019 at 08:36, Koenig, Christian
wrote:
>
> Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt:
> > On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote:
> As far as I know Power doesn't really supports un-cached memory at all,
> except for a very very old and odd co
fix single target build for external module")
> Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support")
> Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
> Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries")
&g
On Mon, 14 Jan 2019 at 12:38, Koenig, Christian
wrote:
>
> Am 14.01.19 um 11:53 schrieb Ard Biesheuvel:
> > On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote:
> >> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
> >>> ARM systems do not permit the use of anything
On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote:
>
> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
> > ARM systems do not permit the use of anything other than cached
> > mappings for system memory, since that memory may be mapped in the
> > linear region as well, and t
On Fri, 11 Jan 2019 at 08:46, Ingo Molnar wrote:
>
> Linus,
>
> Please pull the latest efi-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> efi-urgent-for-linus
>
># HEAD: b12f5440d8ca02e8f9ab4f1461f9214295cc4f66 Merge branch 'linus' into
> e
Cc: Junwei Zhang
Cc: David Airlie
Reported-by: Carsten Haitzler
Signed-off-by: Ard Biesheuvel
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 046a6dda690a..0c1eef5f7ae3
On Fri, 28 Dec 2018 at 04:04, Andrew Morton wrote:
>
> On Wed, 26 Dec 2018 16:31:59 +0100 Ard Biesheuvel
> wrote:
>
> > Please stop sending EFI patches if you can't be bothered to
> > test/reproduce against the EFI tree.
>
> um, sorry, but that's a bit s
vices,
e.g., Sumit's RNG implementation on SynQuacer which we would like to
bind a Linux driver to.
Cc: Jens Wiklander
Cc: Sumit Garg
Cc: Graeme Gregory
Cc: Jerome Forissier
Ard Biesheuvel (2):
optee: model OP-TEE as a platform device/driver
optee: add ACPI support
drivers/tee/op
automatically on systems that advertise the presence of OP-TEE via
the device tree.
Signed-off-by: Ard Biesheuvel
---
drivers/tee/optee/core.c | 86
1 file changed, 32 insertions(+), 54 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index
Add support for devices that expose the presence of OPTEE via device
object in the ACPI namespace.
Signed-off-by: Ard Biesheuvel
---
drivers/tee/optee/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 61ea65cfaedd
On Wed, 26 Dec 2018 at 16:13, Qian Cai wrote:
>
> On 12/26/18 7:02 AM, Ard Biesheuvel wrote:
> > On Wed, 26 Dec 2018 at 03:35, Qian Cai wrote:
> >>
> >> a0fc5578f1d (efi: Let kmemleak ignore false positives) is no longer
> >> needed due to efi_mem_re
On Tue, 25 Dec 2018 at 03:30, Yueyi Li wrote:
>
> Hi Ard,
>
>
> On 2018/12/24 17:45, Ard Biesheuvel wrote:
> > Does the following change fix your issue as well?
> >
> > index 9b432d9fcada..9dcf0ff75a11 100644
> > --- a/arch/arm64/mm/init.c
> > ++
On Wed, 26 Dec 2018 at 03:35, Qian Cai wrote:
>
> a0fc5578f1d (efi: Let kmemleak ignore false positives) is no longer
> needed due to efi_mem_reserve_persistent() uses __get_free_page()
> instead where kmemelak is not able to track regardless. Otherwise,
> kernel reported "kmemleak: Trying to colo
On Mon, 24 Dec 2018 at 08:40, Yueyi Li wrote:
>
> When KASLR enaled(CONFIG_RANDOMIZE_BASE=y), the top 4K virtual
> address have chance to be mapped to physical address, but which
> is expected to leave room for ERR_PTR.
>
> Also, it might cause some other warparound issue when somewhere
> use the
On Sat, 22 Dec 2018 at 12:04, Ard Biesheuvel wrote:
>
> On Sat, 22 Dec 2018 at 11:54, Ingo Molnar wrote:
> >
> >
> > * Sai Praneeth Prakhya wrote:
> >
> > > Commit d5052a7130a6 ("x86/efi: Unmap EFI boot services code/data regions
> > &
On Fri, 21 Dec 2018 at 20:57, Edgecombe, Rick P
wrote:
>
> On Fri, 2018-12-21 at 18:25 +0100, Ard Biesheuvel wrote:
> > On Fri, 21 Dec 2018 at 18:12, Andy Lutomirski
> > wrote:
> > > > On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel <
> > > > ard.biesh
ate EFI runtime calls access it's arguments in 1:1 mode. Hence,
> > don't unmap EFI boot services code/data regions when booted in mixed mode.
> >
> > Signed-off-by: Sai Praneeth Prakhya
> > Cc: Borislav Petkov
> > Cc: Ingo Molnar
> > Cc: Andy Lutom
On Fri, 21 Dec 2018 at 20:29, Borislav Petkov wrote:
>
> On Fri, Dec 21, 2018 at 06:26:23PM +0100, Ard Biesheuvel wrote:
> > On Fri, 21 Dec 2018 at 18:13, Borislav Petkov wrote:
> > >
> > > On Fri, Dec 21, 2018 at 06:02:29PM +0100, Ard Biesheuvel wrote:
> > &
On Fri, 21 Dec 2018 at 18:13, Borislav Petkov wrote:
>
> On Fri, Dec 21, 2018 at 06:02:29PM +0100, Ard Biesheuvel wrote:
> > As far as I can tell, the SGI x86 UV platforms still rely on this, so
> > we're stuck with it for the foreseeable future.
>
> What happened wit
On Fri, 21 Dec 2018 at 18:12, Andy Lutomirski wrote:
>
> > On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel
> > wrote:
> >
> >> On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote:
> >>
> >> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
On Mon, 17 Dec 2018 at 20:48, Prakhya, Sai Praneeth
wrote:
>
> > > > > Hi Thomas and Ingo,
> > > > >
> > > > > I recently noticed that the below commits [1] and [2] are broken
> > > > > when kernel command line argument "efi=old_map" is passed. Sorry!
> > > > > I missed to test this condition prio
On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote:
>
> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> wrote:
> >
> > This adds two new flags VM_IMMEDIATE_UNMAP and VM_HAS_SPECIAL_PERMS, for
> > enabling vfree operations to immediately clear executable TLB entries to
> > freed
> > pages, and
On Fri, 21 Dec 2018 at 17:21, Guenter Roeck wrote:
>
...
> ---
> [8]:
>
> This problem results in a stall on reboot. Reverting the offending patch
> fixes the problem.
>
> # bad: [340ae71f9dd421227a58c14a909b63033745dca4] Add linux-next specific
> files for 20181221
> # good: [7566ec393f4161572b
On Tue, 4 Dec 2018 at 19:06, Sebastian Andrzej Siewior
wrote:
>
> On 2018-12-04 09:23:13 [-0800], Kees Cook wrote:
> > Okay, so, if kmsg_dump() uses rcu_read_lock(), that means efi-pstore
> > can _never_ sleep, and it's nothing to do with pstore internals. :( I
> > guess we just hard-code it, then
On Wed, 19 Dec 2018 at 23:50, Ard Biesheuvel wrote:
>
> On Tue, 18 Dec 2018 at 00:20, Heinrich Schuchardt wrote:
> >
> > On 12/17/18 11:42 PM, Ard Biesheuvel wrote:
> > > On Mon, 17 Dec 2018 at 23:33, Heinrich Schuchardt
> > > wrote:
> > >>
On Wed, 19 Dec 2018 at 18:01, Julien Thierry wrote:
>
> Hi Ard,
>
> On 14/12/2018 16:40, Julien Thierry wrote:
> >
> >
> > On 14/12/2018 15:49, Ard Biesheuvel wrote:
> >> On Fri, 14 Dec 2018 at 16:23, Julien Thierry
> >> wrote:
> >>&g
On Tue, 18 Dec 2018 at 00:20, Heinrich Schuchardt wrote:
>
> On 12/17/18 11:42 PM, Ard Biesheuvel wrote:
> > On Mon, 17 Dec 2018 at 23:33, Heinrich Schuchardt
> > wrote:
> >>
> >> On 12/17/18 7:16 PM, tip-bot for Heinri
this could potentially trigger alignment faults during
> > EFI runtime services calls on 32-bit ARM, given that it does not
> > permit load/store double or load/store multiple instructions to
> > operate on memory addresses that are not 32-bit aligned.
> >
> > Sign
On Mon, 17 Dec 2018 at 19:42, Prakhya, Sai Praneeth
wrote:
>
> > > Hi Thomas and Ingo,
> > >
> > > I recently noticed that the below commits [1] and [2] are broken when
> > > kernel command line argument "efi=old_map" is passed. Sorry! I missed
> > > to test this condition prior to sending these p
On Mon, 17 Dec 2018 at 19:06, Prakhya, Sai Praneeth
wrote:
>
> > Commit-ID: 08cfb38f3ef49cfd1bba11a00401451606477d80
> > Gitweb:
> > https://git.kernel.org/tip/08cfb38f3ef49cfd1bba11a00401451606477d80
> > Author: Sai Praneeth Prakhya
> > AuthorDate: Thu, 29 Nov 2018 18:12:24 +0100
> > Commit
The following changes since commit 7566ec393f4161572ba6f11ad5171fd5d59b0fbd:
Linux 4.20-rc7 (2018-12-16 15:46:55 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
for you to fetch changes up to 7b671e6a4917594a4e9ffd6411
901 - 1000 of 2067 matches
Mail list logo
