On Thu, Feb 04, 2021 at 11:13:18PM +0100, Borislav Petkov wrote:
> On Thu, Feb 04, 2021 at 04:43:58PM -0500, Arvind Sankar wrote:
> > This should check EFI_VA_END instead of EFI_VA_START, and maybe throw in
> > a BUG_ON if EFI_VA_END >= EFI_VA_START.
>
> No need:
On Thu, Feb 04, 2021 at 11:51:55AM +0100, Borislav Petkov wrote:
> On Wed, Feb 03, 2021 at 09:29:18PM +0100, Ard Biesheuvel wrote:
> > I think we have agreement on the approach but it is unclear who is
> > going to write the patch.
>
> How's that below?
>
> And frankly, I'd even vote for removing
Desaulniers wrote:
> > > > Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> > > > explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> > > > way that's forward compatible with existing configs, and makes adding
> > &g
On Wed, Jan 20, 2021 at 03:09:53PM -0800, Nick Desaulniers wrote:
> On Tue, Jan 19, 2021 at 1:35 PM Arnd Bergmann wrote:
> >
> > On Tue, Jan 19, 2021 at 10:18 PM 'Nick Desaulniers' via Clang Built
> > Linux wrote:
> > >
> > > On Tue, Jan 19, 2021 at 5:17 AM Adrian Ratiu
> > > wrote:
> > > > dif
On Mon, Jan 18, 2021 at 09:24:09PM +0100, Borislav Petkov wrote:
> > > > As a matter of fact, it seems like the four assertions could be combined
> > > > into:
> > > > BUILD_BUG_ON((EFI_VA_END & P4D_MASK) != (MODULES_END & P4D_MASK));
> > > > BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (E
On Fri, Jan 15, 2021 at 03:12:25PM -0500, Arvind Sankar wrote:
> On Fri, Jan 15, 2021 at 08:54:18PM +0100, Arnd Bergmann wrote:
> > On Fri, Jan 15, 2021 at 8:18 PM Borislav Petkov wrote:
> > >
> > > On Fri, Jan 15, 2021 at 02:11:25PM -0500, Arvind Sankar wrote:
&g
On Fri, Jan 15, 2021 at 02:07:51PM -0500, Arvind Sankar wrote:
> On Thu, Jan 07, 2021 at 11:34:15PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When 5-level page tables are enabled, clang triggers a BUILD_BUG_ON():
> >
> > x86_64-linux-ld: a
On Fri, Jan 15, 2021 at 08:54:18PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 15, 2021 at 8:18 PM Borislav Petkov wrote:
> >
> > On Fri, Jan 15, 2021 at 02:11:25PM -0500, Arvind Sankar wrote:
> > > That's how build-time assertions work: they are _supposed_ to be
&g
On Fri, Jan 15, 2021 at 08:07:29PM +0100, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 11:32:03AM -0700, Nathan Chancellor wrote:
> > I triggered it with CONFIG_UBSAN=y + CONFIG_UBSAN_UNSIGNED_OVERFLOW=y
> > (it can be exposed with an allyesconfig/allmodconfig on mainline
> > currently).
>
> Y
On Thu, Jan 07, 2021 at 11:34:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When 5-level page tables are enabled, clang triggers a BUILD_BUG_ON():
>
> x86_64-linux-ld: arch/x86/platform/efi/efi_64.o: in function
> `efi_sync_low_kernel_mappings':
> efi_64.c:(.text+0x22c): undefined
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 4af0e6e39b7ed77796a41537db91d717fedd0ac3
Gitweb:
https://git.kernel.org/tip/4af0e6e39b7ed77796a41537db91d717fedd0ac3
Author:Arvind Sankar
AuthorDate:Wed, 11 Nov 2020 11:09:46 -05:00
On Wed, Nov 11, 2020 at 11:09:46AM -0500, Arvind Sankar wrote:
> _PAGE_PAT_LARGE is already defined next to _PAGE_PAT. Remove the
> duplicate.
>
> Signed-off-by: Arvind Sankar
> Fixes: 4efb56649132 ("x86/mm: Tabulate the page table encoding definitions")
>
On Tue, Jan 05, 2021 at 09:54:52AM +0100, Ard Biesheuvel wrote:
> (cc Arvind)
>
> On Tue, 5 Jan 2021 at 09:54, Lin Feng wrote:
> >
> > On efi64 x86_64 system, the EFI_CONVENTIONAL_MEMORY regions will not
> > be mapped when making EFI runtime calls. So kexec-tools can not get
> > these from /sys/f
On Tue, Dec 22, 2020 at 07:31:24PM +0800, Pan Zhang wrote:
> When the kernel is loading,
> the load address of the kernel needs to be calculated firstly.
>
> If the kernel address space layout randomization(`kaslr`) is enabled,
> the memory range reserved by the memmap parameter will be excluded
>
On Mon, Dec 21, 2020 at 11:14:39AM -0800, Nick Desaulniers wrote:
> On Wed, Sep 2, 2020 at 7:31 PM Arvind Sankar wrote:
> >
> > When CONFIG_RETPOLINE is disabled, Clang uses a jump table for the
> > switch statement in cmdline_find_option (jump tables are disabled when
&g
On Fri, Dec 11, 2020 at 09:45:15AM +, David Laight wrote:
> From: Arvind Sankar
> > Sent: 10 December 2020 18:14
> ...
> > I wasn't aware of str_has_prefix() at the time. It does seem useful to
> > eliminate the duplication of the string literal, I like the
>
On Thu, Dec 10, 2020 at 03:18:45PM -0800, Nick Desaulniers wrote:
> On Fri, Dec 4, 2020 at 9:06 AM Arvind Sankar wrote:
> >
> > Why? Does this actually cause any problems?
> >
> > It seems like the options for gcc can actually be very straightforward:
> > you just
On Sat, Dec 05, 2020 at 08:36:02PM +0100, Ard Biesheuvel wrote:
> On Fri, 4 Dec 2020 at 19:02, James Bottomley
> wrote:
> >
> > On Fri, 2020-12-04 at 18:07 +0100, Ard Biesheuvel wrote:
> > > On Fri, 4 Dec 2020 at 18:06,
> > > wrote:
> > > > From: Francis Laniel
> > > >
> > > > The two functions
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 29ac40cbed2bc06fa218ca25d7f5e280d3d08a25
Gitweb:
https://git.kernel.org/tip/29ac40cbed2bc06fa218ca25d7f5e280d3d08a25
Author:Arvind Sankar
AuthorDate:Wed, 11 Nov 2020 11:09:45 -05:00
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: 262bd5724afdefd4c48a260d6100e78cc43ee06b
Gitweb:
https://git.kernel.org/tip/262bd5724afdefd4c48a260d6100e78cc43ee06b
Author:Arvind Sankar
AuthorDate:Fri, 27 Nov 2020 12:13:24 -05:00
Committer
On Thu, Dec 03, 2020 at 03:28:14PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 3:22 PM Nick Desaulniers
> wrote:
> >
> > On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar wrote:
> > >
> > > On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers w
On Thu, Dec 03, 2020 at 09:48:57AM +0100, Borislav Petkov wrote:
> On Wed, Dec 02, 2020 at 05:32:32PM -0500, Arvind Sankar wrote:
> > The pfn_range_is_mapped() call just checks whether it is mapped at all
> > in the direct mapping. Is the TSEG range supposed to be marked as
> >
On Wed, Dec 02, 2020 at 11:58:15AM -0600, Tom Lendacky wrote:
> On 11/27/20 11:27 AM, Borislav Petkov wrote:
> > On Fri, Nov 27, 2020 at 12:13:24PM -0500, Arvind Sankar wrote:
> >> Commit
> >>26bfa5f89486 ("x86, amd: Cleanup init_amd")
> >> moved
e cpu support was added two years ago. Remove it from there as
well.
Signed-off-by: Arvind Sankar
---
arch/x86/kernel/cpu/amd.c | 21 -
arch/x86/kernel/cpu/hygon.c | 20
2 files changed, 41 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/ke
On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers wrote:
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support. GNU `as` on
On Mon, Nov 23, 2020 at 06:33:57PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 23, 2020 at 06:22:10PM -0500, Arvind Sankar wrote:
> > Btw, is -gsplit-dwarf at all useful for assembler files?
>
> If you invoke the assembler via the compiler, with that flag it still
> creat
On Tue, Nov 03, 2020 at 04:53:42PM -0800, Nick Desaulniers wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future versions
On Fri, Nov 20, 2020 at 12:46:26PM +0100, Juergen Gross wrote:
> PVOP_VCALL4() is only used for Xen PV, while PVOP_CALL4() isn't used
> at all. Keep PVOP_CALL4() for 64 bits due to symmetry reasons.
>
> This allows to remove the 32-bit definitions of those macros leading
> to a substantial simplif
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 0ac317e89791b76055ef11b952625ef77a1d2eba
Gitweb:
https://git.kernel.org/tip/0ac317e89791b76055ef11b952625ef77a1d2eba
Author:Arvind Sankar
AuthorDate:Mon, 05 Oct 2020 11:12:07 -04:00
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 31d8546033053b98de00846ede8088bdbe38651d
Gitweb:
https://git.kernel.org/tip/31d8546033053b98de00846ede8088bdbe38651d
Author:Arvind Sankar
AuthorDate:Mon, 05 Oct 2020 11:12:08 -04:00
On Sun, Nov 15, 2020 at 08:35:30PM -0800, Nick Desaulniers wrote:
> The kernel uses `-include` to include include/linux/compiler_types.h
> into all translation units (see scripts/Makefile.lib), which #includes
> compiler_attributes.h.
>
> arch/powerpc/boot/ uses different compiler flags from the r
the time-related functions")
> >
> > Hi Randy,
> > Thanks for the patch, it looks good to me. I only had a question on
> > the commit message.
> >
> > Is this also related to:
> > commit 3347acc6fcd4 ("compiler.h: fix barrier_data() on clang&qu
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 688eb28211abdf82a3f51e8997f1c8137947227d
Gitweb:
https://git.kernel.org/tip/688eb28211abdf82a3f51e8997f1c8137947227d
Author:Arvind Sankar
AuthorDate:Sun, 11 Oct 2020 10:20:12 -04:00
Committer
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: c2fe61d8be491ff8188edaf22e838f81146b
Gitweb:
https://git.kernel.org/tip/c2fe61d8be491ff8188edaf22e838f81146b
Author:Arvind Sankar
AuthorDate:Tue, 10 Nov 2020 11:39:19 -05:00
On Fri, Nov 13, 2020 at 04:08:10PM +0100, Vitaly Kuznetsov wrote:
> Since commit 8570978ea030 ("x86/boot/compressed/64: Don't pre-map memory in
> KASLR code") finalize_identity_maps() has no users, drop it.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/boot/compressed/ident_map_64.c | 10
On Wed, Nov 11, 2020 at 04:15:59PM +0200, Adrian Ratiu wrote:
> On Tue, 10 Nov 2020, Nick Desaulniers
> wrote:
> >
> > Yes, though additionally Arvind points out that this code is
> > kind of curious if there was overlap; maybe the parameters
> > should just be restrict-qualified.
> >
>
> Fo
write-protected pages.
Signed-off-by: Arvind Sankar
Fixes: 6ebcb060713f ("x86/mm: Add support to encrypt the kernel in-place")
Tested-by: Tom Lendacky
Cc: sta...@vger.kernel.org
---
arch/x86/include/asm/pgtable_types.h | 1 +
arch/x86/mm/mem_encrypt_identity.c | 4 ++--
2 files
_PAGE_PAT_LARGE is already defined next to _PAGE_PAT. Remove the
duplicate.
Signed-off-by: Arvind Sankar
Fixes: 4efb56649132 ("x86/mm: Tabulate the page table encoding definitions")
---
arch/x86/include/asm/pgtable_types.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x
On Tue, Nov 10, 2020 at 02:39:59PM -0800, Nick Desaulniers wrote:
> On Tue, Nov 10, 2020 at 2:39 PM Nick Desaulniers
> wrote:
> >
> > On Tue, Nov 10, 2020 at 2:36 PM Nick Desaulniers
> > wrote:
> > >
> > > On Tue, Nov 10, 2020 at 2:15 PM Arvind Sankar
On Tue, Nov 10, 2020 at 01:41:17PM -0800, Nick Desaulniers wrote:
> On Mon, Nov 9, 2020 at 11:51 AM Adrian Ratiu
> wrote:
> >
> > On Fri, 06 Nov 2020, Nick Desaulniers
> > wrote:
> > > +#pragma clang loop vectorize(enable)
> > > do {
> > > p1[0] ^= p2[0] ^ p3[0] ^ p4[0] ^
s()")
fixed one instance of this, but missed another.
Move the freeing out-of-line to avoid code duplication and fix this bug.
Signed-off-by: Arvind Sankar
Fixes: d9e9a6418065 ("x86/mm/pti: Allocate a separate user PGD")
---
arch/x86/platform/efi/efi_64.c | 24 +-
On Mon, Nov 09, 2020 at 02:41:48PM -0600, Tom Lendacky wrote:
> On 11/9/20 11:35 AM, Arvind Sankar wrote:
> > The PAT bit is in different locations for 4k and 2M/1G page table
> > entries.
> >
> > Add a definition for _PAGE_LARGE_CACHE_MASK to represent the three
>
write-protected pages.
Remove a duplication definition of _PAGE_PAT_LARGE.
Signed-off-by: Arvind Sankar
---
arch/x86/include/asm/pgtable_types.h | 3 +--
arch/x86/mm/mem_encrypt_identity.c | 4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm
On Sun, Nov 08, 2020 at 12:40:14PM -0500, Arvind Sankar wrote:
> On Fri, Nov 06, 2020 at 07:14:36AM +0200, Adrian Ratiu wrote:
> > Due to a Clang bug [1] neon autoloop vectorization does not happen or
> > happens badly with no gains and considering previous GCC experiences
>
On Fri, Nov 06, 2020 at 07:14:36AM +0200, Adrian Ratiu wrote:
> Due to a Clang bug [1] neon autoloop vectorization does not happen or
> happens badly with no gains and considering previous GCC experiences
> which generated unoptimized code which was worse than the default asm
> implementation, it i
Hi, I have a question about this definition in
arch/x86/mm/mem_encrypt_identity.c:
#define PMD_FLAGS_LARGE (__PAGE_KERNEL_LARGE_EXEC &
~_PAGE_GLOBAL)
#define PMD_FLAGS_DEC PMD_FLAGS_LARGE
#define PMD_FLAGS_DEC_WP((PMD_FLAGS_DEC & ~_PAGE_CACHE_MAS
On Tue, Nov 03, 2020 at 04:05:36PM -0800, Nick Desaulniers wrote:
> On Tue, Nov 3, 2020 at 4:00 PM Arvind Sankar wrote:
> >
> > On Wed, Oct 21, 2020 at 06:21:06PM -0700, Nick Desaulniers wrote:
> > > Further -gdwarf-X where X is an unsupported value doesn't
&
On Wed, Oct 21, 2020 at 06:21:06PM -0700, Nick Desaulniers wrote:
> DWARF5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support. Further -gdwar
On Thu, Oct 29, 2020 at 09:41:13PM +0100, Thomas Gleixner wrote:
> On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> > On 29/10/20 17:56, Arvind Sankar wrote:
> >>> For those two just add:
> >>> struct apic *apic = x86_system_apic;
> >>> before a
The following commit has been merged into the x86/build branch of tip:
Commit-ID: ea3186b9572a1b0299448697cfc44920061872cf
Gitweb:
https://git.kernel.org/tip/ea3186b9572a1b0299448697cfc44920061872cf
Author:Arvind Sankar
AuthorDate:Thu, 29 Oct 2020 12:19:03 -04:00
On Thu, Oct 29, 2020 at 05:59:54PM +0100, Paolo Bonzini wrote:
> On 29/10/20 17:56, Arvind Sankar wrote:
> >> For those two just add:
> >>struct apic *apic = x86_system_apic;
> >> before all the assignments.
> >> Less churn and much better cod
On Thu, Oct 29, 2020 at 03:05:31PM +, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 28 October 2020 21:21
> >
> > From: Arnd Bergmann
> >
> > There are hundreds of warnings in a W=2 build about a local
> > variable shadowing the global 'apic' definition:
> >
> > arch/x86/kvm/lapic.h:1
safe value.
Clean up various comments to clarify that despite the name,
KERNEL_IMAGE_SIZE is not a limit on the size of the kernel image, but a
limit on the maximum virtual address that the image can occupy.
Signed-off-by: Arvind Sankar
---
arch/x86/include/asm/page_32_types.h | 8 +++-
On Thu, Oct 29, 2020 at 03:29:15PM +0100, Uros Bizjak wrote:
> Use TEST %reg,%reg which sets the zero flag in the same way
> as CMP $0,%reg, but the encoding uses one byte less.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Signed-off-by: Uros Bizjak
On Wed, Oct 28, 2020 at 04:20:01PM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 29, 2020 at 12:10:52AM +0100, Ard Biesheuvel wrote:
> > On Wed, 28 Oct 2020 at 23:59, Alexei Starovoitov
> > wrote:
> > >
> > > On Wed, Oct 28, 2020 at 11:15:04PM +0100, Ard Biesheuvel wrote:
> > > > On Wed, 28 Oct 2
On Wed, Oct 28, 2020 at 08:43:55PM +0100, Borislav Petkov wrote:
> On Wed, Oct 28, 2020 at 12:45:51PM -0400, Arvind Sankar wrote:
> > You don't want to try to run the kernel from physical address 0 in any
> > case. The default is set to 16MiB to avoid low memory, historically
On Wed, Oct 28, 2020 at 09:23:52AM +0100, Joerg Roedel wrote:
> On Mon, Oct 26, 2020 at 07:27:06PM +0100, Borislav Petkov wrote:
> > A couple of lines above you call get_sev_encryption_bit() which already
> > reads MSR_AMD64_SEV. Why not set sev_status there too instead of reading
> > that MSR agai
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 1fcd009102ee02e217f2e7635ab65517d785da8e
Gitweb:
https://git.kernel.org/tip/1fcd009102ee02e217f2e7635ab65517d785da8e
Author:Arvind Sankar
AuthorDate:Tue, 27 Oct 2020 19:06:48 -04:00
Committer
On Wed, Oct 28, 2020 at 02:39:09PM +0100, Borislav Petkov wrote:
> On Tue, Oct 27, 2020 at 05:14:22PM -0400, Arvind Sankar wrote:
> > This is indeed just a small correctness fixlet, but I'm not following
> > the rest of your comments.
>
> I'm just trying to make
it runs out of pages while trying to allocate a PMD
pagetable, the error will be currently ignored.
Fix this to propagate errors.
Signed-off-by: Arvind Sankar
Fixes: ea3b5e60ce80 ("x86/mm/ident_map: Add 5-level paging support")
---
arch/x86/mm/ident_map.c | 9 +++--
1 file changed, 7 i
On Tue, Oct 27, 2020 at 01:40:43PM -0700, Nick Desaulniers wrote:
> On Tue, Oct 27, 2020 at 1:30 PM Arvind Sankar wrote:
> >
> > On Tue, Oct 27, 2020 at 01:17:55PM -0700, Nick Desaulniers wrote:
> > > > > (I feel the same about there
> > > > > being a
On Tue, Oct 27, 2020 at 09:08:03PM +0100, Borislav Petkov wrote:
> On Mon, Oct 05, 2020 at 11:15:39AM -0400, Arvind Sankar wrote:
> > Commit b4e0409a36f4 ("x86: check vmlinux limits, 64-bit") added a check
> > that the size of the 64-bit kernel is less than KERNEL_IMAGE
On Tue, Oct 27, 2020 at 01:28:02PM -0700, Nick Desaulniers wrote:
> > commit 3193c0836f203a91bef96d88c64cccf0be090d9c
> > Author: Josh Poimboeuf
> > Date: Wed Jul 17 20:36:45 2019 -0500
> >
> > bpf: Disable GCC -fgcse optimization for ___bpf_prog_run()
> >
> > has
> >
> > Fixes: e55a73251da3
On Tue, Oct 27, 2020 at 01:17:55PM -0700, Nick Desaulniers wrote:
> On Tue, Oct 27, 2020 at 1:15 PM Ard Biesheuvel wrote:
> >
> > On Tue, 27 Oct 2020 at 21:12, Nick Desaulniers
> > wrote:
> > >
> > > On Tue, Oct 27, 2020 at 12:25 PM Geert Uytterhoeven
> > > wrote:
> > > >
> > > > Hi Nick,
> > >
On Tue, Oct 27, 2020 at 08:33:00PM +0100, Ard Biesheuvel wrote:
> On Tue, 27 Oct 2020 at 20:25, Geert Uytterhoeven wrote:
> > >
> > > When I see .eh_frame, I think -fno-asynchronous-unwind-tables is
> > > missing from someone's KBUILD_CFLAGS.
> > > But I don't see anything curious in kernel/bpf/Ma
On Tue, Oct 27, 2020 at 03:40:07PM +0300, Kirill A. Shutemov wrote:
> On Sat, Oct 24, 2020 at 08:41:58PM -0400, Arvind Sankar wrote:
> > Hi, I think the definition of BOOT_PGT_SIZE in
> > arch/x86/include/asm/boot.h is insufficient, especially after
> > ca0e22d4f011 (&q
On Mon, Oct 26, 2020 at 05:10:19PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The way that bpmp_populate_debugfs_inband() uses strncpy()
> and strncat() makes no sense since the size argument for
> the first is insufficient to contain the trailing '/'
> and the second passes the length
On Sun, Oct 25, 2020 at 11:23:52PM +, David Laight wrote:
> From: Arvind Sankar
> > Sent: 25 October 2020 20:18
> >
> > On Sun, Oct 25, 2020 at 06:51:18PM +, David Laight wrote:
> > > From: Arvind Sankar
> > > > Sent: 25 October 2020 14:31
&g
On Sun, Oct 25, 2020 at 06:51:18PM +, David Laight wrote:
> From: Arvind Sankar
> > Sent: 25 October 2020 14:31
> >
> > Unrolling the LOAD and BLEND loops improves performance by ~8% on x86_64
> > (tested on Broadwell Xeon) while not increasing code size too
On Sun, Oct 25, 2020 at 05:28:06PM +0100, Ard Biesheuvel wrote:
> 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
> &g
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, its image only extends up to the start of _bss,
&
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
---
lib/crypto/sha256.c | 24
1 file changed, 20 insertions(+), 4
This reduces code size substantially (on x86_64 with gcc-10 the size of
sha256_update() goes from 7593 bytes to 1952 bytes including the new
SHA256_K array), and on x86 is slightly faster than the full unroll
(tested on Broadwell Xeon).
Signed-off-by: Arvind Sankar
Reviewed-by: Eric Biggers
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
---
lib/crypto/sha256.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/crypto/sha256.c b/lib/crypto/sha256.c
index
.
Signed-off-by: Arvind Sankar
Reviewed-by: Eric Biggers
---
lib/crypto/sha256.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/crypto/sha256.c b/lib/crypto/sha256.c
index 2321f6cb322f..d43bc39ab05e 100644
--- a/lib/crypto/sha256.c
+++ b/lib/crypto/sha256.c
@@ -265,7 +265,7
1
- Reword commit message for patch 2
- Reformat SHA256_K array
- Drop v2 patch combining K and W arrays
v2:
- Add patch to combine K and W arrays, suggested by David
- Reformat SHA256_ROUND() macro a little
Arvind Sankar (6):
crypto: lib/sha256 - Use memzero_explicit() for clearing state
() 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
---
lib/crypto/sha256.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/lib/crypto
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
---
arch/arm64/crypto/ghash-ce-glue.c | 2 +-
arch/arm64/crypto/poly1305-glue.c | 2 +-
arch/arm64/crypto
On Sat, Oct 24, 2020 at 08:41:58PM -0400, Arvind Sankar wrote:
> Hi, I think the definition of BOOT_PGT_SIZE in
> arch/x86/include/asm/boot.h is insufficient, especially after
> ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
>
> Currently, it a
Hi, I think the definition of BOOT_PGT_SIZE in
arch/x86/include/asm/boot.h is insufficient, especially after
ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
Currently, it allocates 6 pages if KASLR is disabled, and either 17 or
19 pages depending on X86_VERBOSE_BOOTUP if
() 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
---
lib/crypto/sha256.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/lib/crypto
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
---
lib/crypto/sha256.c | 24
1 file changed, 20 insertions(+), 4
This reduces code size substantially (on x86_64 with gcc-10 the size of
sha256_update() goes from 7593 bytes to 1952 bytes including the new
SHA256_K array), and on x86 is slightly faster than the full unroll
(tested on Broadwell Xeon).
Signed-off-by: Arvind Sankar
---
lib/crypto/sha256.c | 174
little
Arvind Sankar (5):
crypto: Use memzero_explicit() for clearing state
crypto: lib/sha256 - Don't clear temporary variables
crypto: lib/sha256 - Clear W[] in sha256_update() instead of
sha256_transform()
crypto: lib/sha256 - Unroll SHA256 loop 8 times intead of 64
crypto
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
---
lib/crypto/sha256.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/crypto/sha256.c b/lib/crypto/sha256.c
index d43bc39ab05e..099cd11f83c1
.
Signed-off-by: Arvind Sankar
---
arch/arm64/crypto/ghash-ce-glue.c | 2 +-
arch/arm64/crypto/poly1305-glue.c | 2 +-
arch/arm64/crypto/sha3-ce-glue.c | 2 +-
arch/x86/crypto/poly1305_glue.c | 2 +-
include/crypto/sha1_base.h| 3 ++-
include/crypto/sha256_base.h | 3 ++-
include
On Wed, Oct 21, 2020 at 09:36:33PM -0700, Eric Biggers wrote:
> On Tue, Oct 20, 2020 at 04:39:52PM -0400, 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
>
On Wed, Oct 21, 2020 at 09:58:50PM -0700, Eric Biggers wrote:
> On Tue, Oct 20, 2020 at 04:39:53PM -0400, Arvind Sankar wrote:
> > The assignments to clear a through h and t1/t2 are optimized out by the
> > compiler because they are unused after the assignments.
> >
> >
On Wed, Oct 21, 2020 at 10:02:19PM -0700, Eric Biggers wrote:
> On Tue, Oct 20, 2020 at 04:39:55PM -0400, Arvind Sankar wrote:
> > This reduces code size substantially (on x86_64 with gcc-10 the size of
> > sha256_update() goes from 7593 bytes to 1952 bytes including the new
>
On Wed, Oct 21, 2020 at 05:28:33PM +0200, Daniel Kiper wrote:
> On Mon, Oct 19, 2020 at 01:18:22PM -0400, Arvind Sankar wrote:
> > On Mon, Oct 19, 2020 at 04:51:53PM +0200, Daniel Kiper wrote:
> > > On Fri, Oct 16, 2020 at 04:51:51PM -0400, Arvind Sankar wrote:
> > > &
On Tue, Oct 20, 2020 at 09:36:00PM +, David Laight wrote:
> From: Arvind Sankar
> > Sent: 20 October 2020 21:40
> >
> > Putting the round constants and the message schedule arrays together in
> > one structure saves one register, which can be a significant benefit
.
Signed-off-by: Arvind Sankar
---
include/crypto/sha1_base.h | 3 ++-
include/crypto/sha256_base.h | 3 ++-
include/crypto/sha512_base.h | 3 ++-
include/crypto/sm3_base.h| 3 ++-
lib/crypto/sha256.c | 2 +-
5 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/crypto
This reduces code size substantially (on x86_64 with gcc-10 the size of
sha256_update() goes from 7593 bytes to 1952 bytes including the new
SHA256_K array), and on x86 is slightly faster than the full unroll
(tesed on Broadwell Xeon).
Signed-off-by: Arvind Sankar
---
lib/crypto/sha256.c | 166
equivalent to knowing one 64-byte block's SHA256
hash (with non-standard initial value) which, assuming SHA256 is secure,
doesn't reveal any information about the input.
Signed-off-by: Arvind Sankar
---
lib/crypto/sha256.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/crypto/s
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
---
lib/crypto/sha256.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/lib
Putting the round constants and the message schedule arrays together in
one structure saves one register, which can be a significant benefit on
register-constrained architectures. On x86-32 (tested on Broadwell
Xeon), this gives a 10% performance benefit.
Signed-off-by: Arvind Sankar
Suggested
() 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
---
lib/crypto/sha256.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/lib/crypto/sha256.c b/lib/crypto/sha256
v2:
- Add patch to combine K and W arrays, suggested by David
- Reformat SHA256_ROUND() macro a little
Arvind Sankar (6):
crypto: Use memzero_explicit() for clearing state
crypto: lib/sha256 - Don't clear temporary variables
crypto: lib/sha256 - Clear W[] in sha256_update() instead of
sh
On Tue, Oct 20, 2020 at 02:55:47PM +, David Laight wrote:
> From: Arvind Sankar
> > Sent: 20 October 2020 15:07
> > To: David Laight
> >
> > On Tue, Oct 20, 2020 at 07:41:33AM +, David Laight wrote:
> > > From: Arvind Sankar> Sent: 19 October 2020
On Tue, Oct 20, 2020 at 05:48:12PM +0200, Joerg Roedel wrote:
> On Tue, Oct 20, 2020 at 10:12:59AM -0400, Arvind Sankar wrote:
> > On Tue, Oct 20, 2020 at 02:18:54PM +0200, Joerg Roedel wrote:
> > Why use r10-r12 rather than the caller-save registers? Even for the head
> > c
1 - 100 of 630 matches
Mail list logo
