On Tue, 27 Oct 2020 at 23:03, Nick Desaulniers wrote:
>
> On Tue, Oct 27, 2020 at 2:50 PM Ard Biesheuvel wrote:
> >
> > On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers
> > wrote:
> > >
> > > On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:
On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers wrote:
>
> On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:
> >
> > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to
Nick Desaulniers
Cc: Arvind Sankar
Cc: Randy Dunlap
Cc: Josh Poimboeuf
Cc: Thomas Gleixner
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Peter Zijlstra (Intel)
Cc: Geert Uytterhoeven
Cc: Kees Cook
Fixes: 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
___bpf_prog_r
on, Oct 26, 2020 at 10:44 AM Geert Uytterhoeven
> > > wrote:
> > > > On Mon, Oct 26, 2020 at 6:39 PM Ard Biesheuvel wrote:
> > > > > On Mon, 26 Oct 2020 at 17:01, Geert Uytterhoeven
> > > > > wrote:
> > > > > > On Mon,
On Tue, 27 Oct 2020 at 20:25, Geert Uytterhoeven wrote:
>
> Hi Nick,
>
> CC Josh
>
> On Mon, Oct 26, 2020 at 6:49 PM Nick Desaulniers
> wrote:
> > On Mon, Oct 26, 2020 at 10:44 AM Geert Uytterhoeven
> > wrote:
> > > On Mon, Oct 26, 2020 at 6:39 PM Ard
On Tue, 27 Oct 2020 at 12:29, Ard Biesheuvel wrote:
>
> On Tue, 27 Oct 2020 at 11:20, Geert Uytterhoeven wrote:
> >
> > Hi Jean-Philippe,
> >
> > On Tue, Oct 27, 2020 at 11:09 AM Jean-Philippe Brucker
> > wrote:
> > > On Mon, Oct 26, 2
erence
via R_AARCH64_CALL26 can simply remain unsatisfied.
Cc: Jessica Yu
Cc: Kees Cook
Cc: Geert Uytterhoeven
Cc: Nick Desaulniers
Signed-off-by: Ard Biesheuvel
---
include/linux/module.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/module.h b/include/linux/modu
On Tue, 27 Oct 2020 at 11:20, Geert Uytterhoeven wrote:
>
> Hi Jean-Philippe,
>
> On Tue, Oct 27, 2020 at 11:09 AM Jean-Philippe Brucker
> wrote:
> > On Mon, Oct 26, 2020 at 06:38:46PM +0100, Ard Biesheuvel wrote:
> > > > > > Note tha
> In preparation for warning on orphan sections, discard
> > > > unwanted non-zero-sized generated sections, and enforce other
> > > > expected-to-be-zero-sized sections (since discarding them might hide
> > > > problems with them suddenly gaining unexpected entri
On Thu, 22 Oct 2020 at 19:59, Ard Biesheuvel wrote:
>
> On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > > On Thu, 22 Oct 2020 at 18:23, Russell King
On Sun, 25 Oct 2020 at 15:31, Arvind Sankar wrote:
>
> Unrolling the LOAD and BLEND loops improves performance by ~8% on x86_64
> (tested on Broadwell Xeon) while not increasing code size too much.
>
> Signed-off-by: Arvind Sankar
> Reviewed-by: Eric Biggers
Acked-
Broadwell Xeon).
>
> Signed-off-by: Arvind Sankar
> Reviewed-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
> lib/crypto/sha256.c | 174 ++--
> 1 file changed, 38 insertions(+), 136 deletions(-)
>
> diff --git a/lib/crypto
save about 2-3% of the total time taken to compute the digest, with a
> reasonable memset() implementation, and considerably more (~20%) with a
> bad one (eg the x86 purgatory currently uses a memset() coded in C).
>
> Signed-off-by: Arvind Sankar
> Reviewed-by: Eric Biggers
Acked-by: Ard Bi
igned to registers, and even if stack spilling was
> required, there may be compiler-generated temporaries that are
> impossible to clear in any case.
>
> So drop the clearing of a through h and t1/t2.
>
> Signed-off-by: Arvind Sankar
> Reviewed-by: Eric Biggers
Acked-b
can get inlined into sha256(), in which case the memset is
> optimized away.
>
> Signed-off-by: Arvind Sankar
> Reviewed-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
> lib/crypto/sha256.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a
On Sun, 25 Oct 2020 at 15:31, Arvind Sankar wrote:
>
> Without the barrier_data() inside memzero_explicit(), the compiler may
> optimize away the state-clearing if it can tell that the state is not
> used afterwards.
>
> Signed-off-by: Arvind Sankar
Acked-by: Ard Biesheuvel
On Sat, 24 Oct 2020 at 20:40, Icenowy Zheng wrote:
>
>
>
> 于 2020年10月25日 GMT+08:00 上午2:30:35, "Jernej Škrabec"
> 写到:
> >Dne sobota, 24. oktober 2020 ob 19:51:06 CEST je Icenowy Zheng
> >napisal(a):
> >> 在 2020-10-25星期日的 00:25 +0800，Chen-Yu Tsai写道：
> >>
> >> > From: Chen-Yu Tsai
> >> >
> >> >
On Fri, 23 Oct 2020 at 13:54, Vamshi K Sthambamkadi
wrote:
>
> kmemleak report:
> unreferenced object 0x9b8915fcb000 (size 4096):
> comm "efivarfs.sh", pid 2360, jiffies 4294920096 (age 48.264s)
> hex dump (first 32 bytes):
> 2d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
On Sun, 25 Oct 2020 at 17:19, Arvind Sankar wrote:
>
> On Sun, Oct 11, 2020 at 10:20:12AM -0400, Arvind Sankar wrote:
> > The image_size argument to efi_relocate_kernel() is currently specified
> > as init_size, but this is unnecessarily large. The compressed kernel is
> > much smaller, in fact,
On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 06
On Thu, 22 Oct 2020 at 19:50, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 07:47:57PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 07:
On Thu, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> > 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
>
On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 06
On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko wrote:
> > >
> > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > &g
On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko wrote:
>
> 22.10.2020 10:06, Ard Biesheuvel пишет:
> > On Thu, 22 Oct 2020 at 05:30, Kees Cook wrote:
> >>
> >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> >>> 22.10.2020 02:40, Ke
On Wed, 21 Oct 2020 at 14:35, Nicolas Saenz Julienne
wrote:
>
> Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
> physical address addressable by all DMA masters in the system. It's
> specially useful for setting memory zones sizes at early boot time.
>
> Signed-off-by:
On Thu, 22 Oct 2020 at 05:30, Kees Cook wrote:
>
> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > 22.10.2020 02:40, Kees Cook пишет:
> > > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > >> The vfp_kmode_exception() function now is unreachable using
return NULL;
> }
>
> + if ((u64)virt_to_phys(smibuf->start) >> 32) {
> + printk(KERN_ERR "gsmi: allocation not within 32-bit physical
> address space\n");
> + kfree(smibuf->start);
> +
On Wed, 21 Oct 2020 at 21:07, Joe Perches wrote:
>
> On Wed, 2020-10-21 at 21:02 +0200, Ard Biesheuvel wrote:
> > On Wed, 21 Oct 2020 at 20:58, Joe Perches wrote:
> > > Like the __section macro, the __alias macro uses
> > > macro # stringification to create quotes
On Wed, 21 Oct 2020 at 20:58, Joe Perches wrote:
>
> Like the __section macro, the __alias macro uses
> macro # stringification to create quotes around
> the section name used in the __attribute__.
>
> Remove the stringification and add quotes or a
> stringification to the uses instead.
>
Why?
On Wed, 21 Oct 2020 at 10:51, Greg Kroah-Hartman
wrote:
>
> On Wed, Oct 21, 2020 at 12:37:52AM -0700, Furquan Shaikh wrote:
> > On Tue, Oct 20, 2020 at 11:37 PM Ard Biesheuvel wrote:
> > >
> > > On Wed, 21 Oct 2020 at 07:18, Greg Kroah-Hartman
> > > wrot
On Tue, 20 Oct 2020 at 22:16, Nick Desaulniers wrote:
>
> On Tue, Oct 20, 2020 at 10:57 AM Will Deacon wrote:
> >
> > On Fri, 16 Oct 2020 10:53:39 -0700, Nick Desaulniers wrote:
> > > With CONFIG_EXPERT=y, CONFIG_KASAN=y, CONFIG_RANDOMIZE_BASE=n,
> > > CONFIG_RELOCATABLE=n, we observe the
On Wed, 21 Oct 2020 at 07:18, Greg Kroah-Hartman
wrote:
>
> On Tue, Oct 20, 2020 at 10:01:41PM -0700, Furquan Shaikh wrote:
> > GSMI driver uses dma_pool_* API functions for buffer allocation
> > because it requires that the SMI buffers are allocated within 32-bit
> > physical address space.
INIT_DATA_SECTION(16)
> >> +
> >> + #ifdef CONFIG_EFI
> >> + . = ALIGN(PECOFF_SECTION_ALIGNMENT);
> >> + __pecoff_text_end = .;
> >> + #endif
> >> +
> >> /* Start of data section */
> >>
On Thu, 15 Oct 2020 at 12:31, Lorenzo Pieralisi
wrote:
>
> On Wed, Oct 14, 2020 at 09:12:09PM +0200, Nicolas Saenz Julienne wrote:
>
> [...]
>
> > +unsigned int __init acpi_iort_get_zone_dma_size(void)
> > +{
> > + struct acpi_table_iort *iort;
> > + struct acpi_iort_node *node, *end;
> >
On Fri, 16 Oct 2020 at 08:51, Hanjun Guo wrote:
>
> On 2020/10/16 2:03, Catalin Marinas wrote:
> > On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote:
> >> On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
> >>> From: Ard Biesheuvel
> >>&
On Thu, 15 Oct 2020 at 11:16, Nicolas Saenz Julienne
wrote:
>
> On Thu, 2020-10-15 at 08:56 +0200, Ard Biesheuvel wrote:
> > On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote:
> > > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
> > > wrote:
> > >
On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote:
>
> On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
> wrote:
> >
> > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
> > physical address addressable by all DMA masters in the system. It's
> > specially useful for
On Mon, 12 Oct 2020 at 13:38, Robin Murphy wrote:
>
> On 2020-10-09 08:55, Jisheng Zhang wrote:
> > Currently, dw_pcie_msi_init() allocates and maps page for msi, then
> > program the PCIE_MSI_ADDR_LO and PCIE_MSI_ADDR_HI. The Root Complex
> > may lose power during suspend-to-RAM, so when we
Hello Chester,
Thanks for looking into this.
Some comments below.
On Wed, 14 Oct 2020 at 12:41, Chester Lin wrote:
>
> Separate the get_sb_mode() from arch/x86 and treat it as a common function
> [rename to efi_get_secureboot_mode] so all EFI-based architectures can
> reuse the same logic.
>
>
On Wed, 14 Oct 2020 at 07:07, Anshuman Khandual
wrote:
>
>
>
> On 10/12/2020 12:59 PM, Ard Biesheuvel wrote:
> > On Tue, 6 Oct 2020 at 08:36, Anshuman Khandual
> > wrote:
> >>
> >>
> >>
> >> On 09/30/2020 01:32 PM, Anshuman K
On Mon, 12 Oct 2020 at 13:37, Catalin Marinas wrote:
>
> On Sat, Oct 10, 2020 at 05:12:31PM +0200, Nicolas Saenz Julienne wrote:
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index f6902a2b4ea6..0eca5865dcb1 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
>
On Mon, 5 Oct 2020 at 04:20, Chester Lin wrote:
>
> On Mon, Sep 14, 2020 at 04:05:22PM +0800, Chester Lin wrote:
> > Hi Ard,
> >
> > On Fri, Sep 11, 2020 at 06:01:09PM +0300, Ard Biesheuvel wrote:
> > > On Fri, 4 Sep 2020 at 10:29, Chester Lin wrote:
> &g
On Tue, 6 Oct 2020 at 08:36, Anshuman Khandual
wrote:
>
>
>
> On 09/30/2020 01:32 PM, Anshuman Khandual wrote:
> > But if __is_lm_address() checks against the effective linear range instead
> > i.e [_PAGE_OFFSET(vabits_actual)..(PAGE_END - 1)], it can be used for hot
> > plug physical range check
On Wed, 7 Oct 2020 at 16:44, André Przywara wrote:
>
> On 07/10/2020 15:16, James Morse wrote:
>
> Hi,
>
> > On 06/10/2020 21:18, Andre Przywara wrote:
> >> The ARM architected TRNG firmware interface, described in ARM spec
> >> DEN0098[1], defines an ARM SMCCC based interface to a true random
Hi Nicolas,
$SUBJECT is out of sync with the patch below. Also, for legibility, it
helps if the commit log is intelligible by itself, rather than relying
on $SUBJECT being the first line of the first paragraph.
On Sat, 10 Oct 2020 at 17:12, Nicolas Saenz Julienne
wrote:
>
> The function
The following commit has been merged into the efi/core branch of tip:
Commit-ID: cc383a9e245c527d3175e2cf4cced9dbbedbbac6
Gitweb:
https://git.kernel.org/tip/cc383a9e245c527d3175e2cf4cced9dbbedbbac6
Author:Ard Biesheuvel
AuthorDate:Fri, 02 Oct 2020 10:01:23 +02:00
On Fri, 9 Oct 2020 at 19:10, Catalin Marinas wrote:
>
> On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote:
> > On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi
> > wrote:
> > > We can move this check to IORT code and call it from arm64 if it
> > >
On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi
wrote:
>
> On Fri, Oct 09, 2020 at 11:13:59AM +0200, Ard Biesheuvel wrote:
> > On Fri, 9 Oct 2020 at 10:36, Nicolas Saenz Julienne
> > wrote:
> > >
> > > On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
On Fri, 9 Oct 2020 at 10:36, Nicolas Saenz Julienne
wrote:
>
> On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
> > On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
> > > On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> >
On Fri, 9 Oct 2020 at 10:51, Xiaoming Ni wrote:
>
> drivers/firmware/efi/mokvar-table.c:139:5: error: implicit declaration of
> function 'early_memunmap'; did you mean 'devm_memunmap'?
> [-Werror=implicit-function-declaration]
> drivers/firmware/efi/mokvar-table.c:148:9: error: implicit
On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
>
> On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> > Sadly I just realised that the series is incomplete, we have RPi4 users that
> > want to boot unsing ACPI, and this series would break things for them. I'll
> >
(+ Lorenzo)
On Thu, 8 Oct 2020 at 12:14, Catalin Marinas wrote:
>
> On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> > On Fri, 2020-10-02 at 12:55 +0100, Catalin Marinas wrote:
> > > On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote:
> > > > On Thu,
remove the variable to get rid of the
> warning.
>
> Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1171
> Signed-off-by: Nathan Chancellor
Acked-by: Ard Biesheuvel
> ---
> crypto/
pher_encrypt+0x50/0x84
> test_skcipher_vec_cfg+0x224/0x5f0
> test_skcipher+0xbc/0x120
> alg_test_skcipher+0xa0/0x1b0
> alg_test+0x3dc/0x47c
> cryptomgr_test+0x38/0x60
>
> Fixes: 0e89640b640d ("crypto: arm64 - Use modern annotations for assembly
> functions&qu
On Tue, 6 Oct 2020 at 14:33, Catalin Marinas wrote:
>
> On Tue, Oct 06, 2020 at 11:43:14AM +0100, Dave P Martin wrote:
> > On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
> > > On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> > > > On Tue, Oct 06, 2020 at
On Tue, 6 Oct 2020 at 11:38, Dave Martin wrote:
>
> On Mon, Oct 05, 2020 at 02:24:47PM -0500, Jeremy Linton wrote:
> > Hi,
> >
> > On 10/5/20 1:54 PM, Ard Biesheuvel wrote:
> > >On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
> > >>
> >
On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
>
> The AES code uses a 'br x7' as part of a function called by
> a macro, that ends up needing a BTI_J as a target.
Could we instead just drop the tail call, i.e, replace it with a ret
and do a 'bl' after it returns? The indirect call does not
On Mon, 5 Oct 2020 at 08:40, Stephan Mueller wrote:
>
> Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel:
>
> Hi Ard,
>
> > If jitterentropy is a special case, we could put a alternate
> > non-'static inline' version of random_get_entropy() in the core
On Mon, 5 Oct 2020 at 08:19, Christoph Hellwig wrote:
>
> On Sun, Oct 04, 2020 at 11:16:10PM +0200, Ard Biesheuvel wrote:
> > On Sun, 4 Oct 2020 at 20:48, Stephan M??ller wrote:
> > >
> > > The RISC-V architecture is about to implement the callback
> >
On Sun, 4 Oct 2020 at 20:48, Stephan Müller wrote:
>
> The RISC-V architecture is about to implement the callback
> random_get_entropy with a function that is not exported to modules.
Why is that? Wouldn't it be better to export the symbol instead?
> Thus, the Jitter RNG is changed to be only
t; > Brian Gerst
>
> 32-bit doesn't use this implementation: it's #define'd to true in
> drivers/firmware/efi/libstub/efistub.h.
>
Yes, and the reason this [now redundant] test exists is because this
did not use to be the case before
de8c55208c386 efi/libstub: Fix mixed mode boot issue after macro refactor
So for this patch
Acked-by: Ard Biesheuvel
I'll queue this up
On Fri, 2 Oct 2020 at 21:14, Heinrich Schuchardt wrote:
>
> On 10/2/20 7:21 PM, Ard Biesheuvel wrote:
> > Hi Heinrich,
> >
> > Thanks for documenting this.
> >
> >
> > On Fri, 2 Oct 2020 at 19:11, Heinrich Schuchardt wrote:
> >>
> >
Hi Heinrich,
Thanks for documenting this.
On Fri, 2 Oct 2020 at 19:11, Heinrich Schuchardt wrote:
>
> Describe how a device tree and an initial RAM disk can be passed to the EFI
> Boot Stub.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> Documentation/admin-guide/efi-stub.rst | 35
On Thu, 1 Oct 2020 at 19:44, Nathan Chancellor wrote:
>
> On Fri, Sep 04, 2020 at 09:31:05PM -0400, Lenny Szubowicz wrote:
> > Because of system-specific EFI firmware limitations, EFI volatile
> > variables may not be capable of holding the required contents of
> > the Machine Owner Key (MOK)
On Wed, 30 Sep 2020 at 16:36, Ondrej Mosnáček wrote:
>
> st 30. 9. 2020 o 15:04 Colin King napísal(a):
> >
> > From: Colin Ian King
> >
> > There is an off-by-one range check on the upper limit of
> > index "no". Fix this by changing the > comparison to >=
>
> Note that this doesn't completely
for PAGE_OFFSET,
> >>>> bits [51..48] are ignored by the MMU and remain unchanged, even though
> >>>> the
> >>>> effective start address of linear map is now slightly different. Hence,
> >>>> to
> >>>> reliably check the p
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 6277e374b0b07c1a93c829f0a27e38739b3b7a1b
Gitweb:
https://git.kernel.org/tip/6277e374b0b07c1a93c829f0a27e38739b3b7a1b
Author:Ard Biesheuvel
AuthorDate:Thu, 24 Sep 2020 13:52:24 +02:00
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: d32de9130f6c79533508e2c7879f18997bfbe2a0
Gitweb:
https://git.kernel.org/tip/d32de9130f6c79533508e2c7879f18997bfbe2a0
Author:Ard Biesheuvel
AuthorDate:Sat, 26 Sep 2020 10:52:42 +02:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 232f4eb6393f42f7f9418560ae9228e747fc6faf
Gitweb:
https://git.kernel.org/tip/232f4eb6393f42f7f9418560ae9228e747fc6faf
Author:Ard Biesheuvel
AuthorDate:Wed, 23 Sep 2020 09:56:14 +02:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 9846d86031eeca2fb2867fe4ac9d92803a97e8e4
Gitweb:
https://git.kernel.org/tip/9846d86031eeca2fb2867fe4ac9d92803a97e8e4
Author:Ard Biesheuvel
AuthorDate:Wed, 23 Sep 2020 10:18:31 +02:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 963fabf37f6a94214a823df0a785e653cb8ad6ea
Gitweb:
https://git.kernel.org/tip/963fabf37f6a94214a823df0a785e653cb8ad6ea
Author:Ard Biesheuvel
AuthorDate:Wed, 23 Sep 2020 10:20:10 +02:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: c9b51a2dbfe7f47643e133bf48e1bf28f1b85d2a
Gitweb:
https://git.kernel.org/tip/c9b51a2dbfe7f47643e133bf48e1bf28f1b85d2a
Author:Ard Biesheuvel
AuthorDate:Wed, 23 Sep 2020 10:07:49 +02:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: b89114cd018cffa5deb7def1844ce1891efd4f96
Gitweb:
https://git.kernel.org/tip/b89114cd018cffa5deb7def1844ce1891efd4f96
Author:Ard Biesheuvel
AuthorDate:Thu, 24 Sep 2020 17:58:22 +02:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 5d3c8617ccee6387ba73a5dba77fb9dc21cb85f4
Gitweb:
https://git.kernel.org/tip/5d3c8617ccee6387ba73a5dba77fb9dc21cb85f4
Author:Ard Biesheuvel
AuthorDate:Wed, 23 Sep 2020 10:13:07 +02:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 5ee70cd60652e85e4e8ced99f58f2fcbab405110
Gitweb:
https://git.kernel.org/tip/5ee70cd60652e85e4e8ced99f58f2fcbab405110
Author:Ard Biesheuvel
AuthorDate:Wed, 23 Sep 2020 10:27:36 +02:00
On Tue, 29 Sep 2020 at 19:50, Will Deacon wrote:
>
> On Thu, Sep 24, 2020 at 07:55:19PM +0800, Hou Tao wrote:
> > The following is the newest performance data:
> >
> > aarch64 host (4 sockets, 24 cores per sockets)
> >
> > * v4.19.111
> >
> > no writer, reader cn|
On Sun, 27 Sep 2020 at 21:56, Julia Lawall wrote:
>
> These patches replace commas by semicolons.
Why?
> This was done using the
> Coccinelle semantic patch (http://coccinelle.lip6.fr/) shown below.
>
> This semantic patch ensures that commas inside for loop headers will not be
> transformed.
On Mon, 28 Sep 2020 at 18:15, Ard Biesheuvel wrote:
>
> On Mon, 28 Sep 2020 at 17:52, Jarkko Sakkinen
> wrote:
> >
> > On Mon, Sep 28, 2020 at 10:16:07PM +0800, Kai-Heng Feng wrote:
> > > Hi Jarkko,
> > >
> > > > On Sep 28, 2020, at 22:06, Jark
On Mon, 28 Sep 2020 at 17:52, Jarkko Sakkinen
wrote:
>
> On Mon, Sep 28, 2020 at 10:16:07PM +0800, Kai-Heng Feng wrote:
> > Hi Jarkko,
> >
> > > On Sep 28, 2020, at 22:06, Jarkko Sakkinen
> > > wrote:
> > >
> > > On Mon, Sep 28, 2020 at 08:31:04PM +0800, Kai-Heng Feng wrote:
> > >> Commit
On Mon, 28 Sep 2020 at 13:57, Leizhen (ThunderTown)
wrote:
>
>
>
> On 2020/9/28 18:14, Ard Biesheuvel wrote:
> > On Mon, 28 Sep 2020 at 11:27, Zhen Lei wrote:
> >>
> >> mov r4, pc
> >> and r4, r4, #0xf800 //truncated to 128MiB bound
On Mon, 28 Sep 2020 at 11:27, Zhen Lei wrote:
>
> mov r4, pc
> and r4, r4, #0xf800 //truncated to 128MiB boundary
> add r4, r4, #TEXT_OFFSET//PA(_start)
>
> Currently, the decompressed kernel must be placed at the position: 128MiB
> boundary + TEXT_OFFSET. This limitation
n Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> >>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> >>>> wrote:
> >>>>>
> >>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> >>>&
On Fri, 25 Sep 2020 at 22:47, Kees Cook wrote:
>
> On Fri, Sep 25, 2020 at 10:37:01PM +0200, Ard Biesheuvel wrote:
> > On Fri, 25 Sep 2020 at 22:28, Kees Cook wrote:
> > >
> > > On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote:
> > > > T
On Fri, 25 Sep 2020 at 22:28, Kees Cook wrote:
>
> On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote:
> > This is regarding the KASLR feature support on ARM for the kernel
> > version 4.9 and 4.14.
> >
> > Is KASLR supported on ARM-32 Linux 4.9 and above ?
>
> Sorry, this feature did
On Fri, 25 Sep 2020 at 09:54, Michael Schaller wrote:
>
> On Fri, Sep 25, 2020 at 9:49 AM Ard Biesheuvel wrote:
> >
> > On Fri, 25 Sep 2020 at 09:45, Michael Schaller wrote:
> > >
> > > Without this patch efivarfs_alloc_dentry creates dentries with slashes i
On Fri, 25 Sep 2020 at 09:45, Michael Schaller wrote:
>
> Without this patch efivarfs_alloc_dentry creates dentries with slashes in
> their name if the respective EFI variable has slashes in its name. This in
> turn causes EIO on getdents64, which prevents a complete directory listing
> of
On Fri, 18 Sep 2020 at 13:25, Michael Schaller wrote:
>
> Without this patch efivarfs_alloc_dentry creates dentries with slashes in
> their name if the respective EFI variable has slashes in its name. This in
> turn causes EIO on getdents64, which prevents a complete directory listing
> of
On Fri, 25 Sep 2020 at 02:51, joeyli wrote:
>
> Hi Ard,
>
> On Thu, Sep 24, 2020 at 12:47:46PM +0200, Ard Biesheuvel wrote:
> > On Thu, 24 Sep 2020 at 10:28, Lee, Chun-Yi wrote:
> > >
> > > This patch moved the logic of creating efivars mount point
On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
wrote:
>
> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> > The TPM event log is provided to the OS by the firmware, by loading
> > it into an area in memory and passing the physical address via a node
>
On Thu, 24 Sep 2020 at 15:45, Ard Biesheuvel wrote:
>
> On Thu, 24 Sep 2020 at 15:28, Rob Herring wrote:
> >
> > On Thu, Sep 24, 2020 at 5:00 AM Ard Biesheuvel wrote:
> > >
> > > On Wed, 23 Sep 2020 at 08:28, Jisheng Zhang
> > > wrote:
> >
On Thu, 24 Sep 2020 at 15:28, Rob Herring wrote:
>
> On Thu, Sep 24, 2020 at 5:00 AM Ard Biesheuvel wrote:
> >
> > On Wed, 23 Sep 2020 at 08:28, Jisheng Zhang
> > wrote:
> > >
> > > Currently, dw_pcie_msi_init() allocates and maps page for ms
On Wed, 23 Sep 2020 at 08:28, Jisheng Zhang wrote:
>
> Currently, dw_pcie_msi_init() allocates and maps page for msi, then
> program the PCIE_MSI_ADDR_LO and PCIE_MSI_ADDR_HI. The Root Complex
> may lose power during suspend-to-RAM, so when we resume, we want to
> redo the latter but not the
of mount point.
>
> The 'efivars' platform device be created on generic EFI runtime services
> platform, so it can be used to determine the availability of efivarfs.
> But this approach is not available for google gsmi efivars abstraction.
>
> This patch be tested on Here on qemu-OVMF and qemu-ub
On Thu, 24 Sep 2020 at 11:45, Ard Biesheuvel wrote:
>
> On Wed, 23 Sep 2020 at 23:02, Kees Cook wrote:
> >
> > On Wed, Sep 23, 2020 at 08:43:21PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 23 Sep 2020 at 20:41, Kees Cook wrote:
> > > >
> > >
On Wed, 23 Sep 2020 at 23:02, Kees Cook wrote:
>
> On Wed, Sep 23, 2020 at 08:43:21PM +0200, Ard Biesheuvel wrote:
> > On Wed, 23 Sep 2020 at 20:41, Kees Cook wrote:
> > >
> > > On Wed, Sep 23, 2020 at 06:13:58PM +0200, Ard Biesheuvel wrote:
> > >
On Wed, 23 Sep 2020 at 20:41, Kees Cook wrote:
>
> On Wed, Sep 23, 2020 at 06:13:58PM +0200, Ard Biesheuvel wrote:
> > The EFI pstore implementation relies on the 'efivars' abstraction,
> > which encapsulates the EFI variable store in a way that can be
> > overridden by ot
On Wed, 23 Sep 2020 at 17:39, Borislav Petkov wrote:
>
> On Wed, Sep 23, 2020 at 04:52:18PM +0200, Ard Biesheuvel wrote:
> > I think the question is why we are retaining this Reported-by header
> > to begin with. Even though the early feedback is appreciated,
> > credit
Remove some false dependencies on CONFIG_EFI_VARS, which only controls
the creation of the sysfs entries, whereas the underlying functionality
that these modules rely on is enabled unconditionally when CONFIG_EFI
is set.
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/Kconfig | 3 +--
1
future.
Signed-off-by: Ard Biesheuvel
---
Documentation/arm/uefi.rst | 2 +-
drivers/firmware/efi/Kconfig | 13 -
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/Documentation/arm/uefi.rst b/Documentation/arm/uefi.rst
index f868330df6be..f732f957421f 100644
301 - 400 of 5028 matches
Mail list logo
