On Mon, 25 Jan 2021 at 15:28, Marc Zyngier wrote:
>
> On 2021-01-25 14:19, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 14:54, Marc Zyngier wrote:
> >>
> >> On 2021-01-25 12:54, Ard Biesheuvel wrote:
>
> [...]
>
> >> > This struct
On Sun, 24 Jan 2021 at 15:23, Ard Biesheuvel wrote:
>
> On Sun, 24 Jan 2021 at 15:10, Stephan Müller wrote:
> >
> > Hi,
> >
> > The key derviation functions are considered to be a cryptographic
> > operation. As cryptographic operations are provided via the k
On Sun, 24 Jan 2021 at 15:28, Helge Deller wrote:
>
> On some of my parisc machines, this patch c055e3eae0f1 ("crypto: xor -
> use ktime for template benchmarking") triggers a dividy-by-zero
> exception because "min" becomes zero, which then leads to a kernel
> crash.
>
> It's not clear yet, why
On Sun, 24 Jan 2021 at 15:10, Stephan Müller wrote:
>
> Hi,
>
> The key derviation functions are considered to be a cryptographic
> operation. As cryptographic operations are provided via the kernel
> crypto API, this patch set consolidates the KDF implementations into the
> crypto API.
>
> The
On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman
wrote:
>
>
>
> On 1/22/21 11:43 AM, Mark Brown wrote:
> > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote:
> >
> >> 2) The shadow stack idea sounds promising -- how hard would it be to
> >>make a prototype reliable
On Fri, 22 Jan 2021 at 18:44, Mark Brown wrote:
>
> On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote:
>
> > 2) The shadow stack idea sounds promising -- how hard would it be to
> >make a prototype reliable unwinder?
>
> In theory it doesn't look too hard and I can't see a
On Fri, 22 Jan 2021 at 17:53, Peter Zijlstra wrote:
>
> On Mon, Jan 18, 2021 at 03:12:21PM +0100, Frederic Weisbecker wrote:
> > +#ifdef CONFIG_PREEMPT_DYNAMIC
> > +DEFINE_STATIC_CALL(preempt_schedule, __preempt_schedule_func());
> > +EXPORT_STATIC_CALL(preempt_schedule);
> > +#endif
>
> >
On Thu, 21 Jan 2021 at 05:13, Arvind Sankar wrote:
>
> 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
On Thu, 21 Jan 2021 at 12:23, Peter Zijlstra wrote:
>
> On Thu, Jan 21, 2021 at 12:08:23PM +0100, Ard Biesheuvel wrote:
> > On Thu, 21 Jan 2021 at 11:26, Julien Thierry wrote:
>
> > > I'm not familiar with toolcahin code models, but would this approach be
> > &g
On Thu, 21 Jan 2021 at 11:26, Julien Thierry wrote:
>
> Hi Ard,
>
> On 1/21/21 10:03 AM, Ard Biesheuvel wrote:
> > Hello Julien,
> >
> > On Wed, 20 Jan 2021 at 18:38, Julien Thierry wrote:
> >>
> >> Hi,
> >>
> >> This series en
On Thu, 21 Jan 2021 at 10:54, Christophe Leroy
wrote:
>
>
>
> Le 21/01/2021 à 08:31, Ard Biesheuvel a écrit :
> > On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
> > wrote:
> >>
> >>
> >>
> >> Le 20/01/2021 à 23:23, Ard Biesheuvel a
Hello Julien,
On Wed, 20 Jan 2021 at 18:38, Julien Thierry wrote:
>
> Hi,
>
> This series enables objtool to start doing stack validation on arm64
> kernel builds.
Could we elaborate on this point, please? 'Stack validation' means
getting an accurate picture of all kernel code that will be
On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
wrote:
>
>
>
> Le 20/01/2021 à 23:23, Ard Biesheuvel a écrit :
> > On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
> > wrote:
> >>
> >> Talitos Security Engine AESU considers any input
> >> data siz
On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
wrote:
>
> Talitos Security Engine AESU considers any input
> data size that is not a multiple of 16 bytes to be an error.
> This is not a problem in general, except for Counter mode
> that is a stream cipher and can have an input of any size.
>
>
On Wed, 20 Jan 2021 at 14:01, Will Deacon wrote:
>
> On Wed, 6 Jan 2021 10:34:48 +, Andre Przywara wrote:
> > a fix to v5, now *really* fixing the wrong priority of SMCCC vs. RNDR
> > in arch_get_random_seed_long_early(). Apologies for messing this up
> > in v5 and thanks to broonie for being
On Mon, 18 Jan 2021 at 22:42, Arvind Sankar wrote:
>
> 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) !=
On Tue, 19 Jan 2021 at 17:01, Dave Martin wrote:
>
> On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote:
> > Kernel mode NEON can be used in task or softirq context, but only in
> > a non-nesting manner, i.e., softirq context is only permitted if the
> >
On Mon, 28 Dec 2020 at 20:11, Dey, Megha wrote:
>
> Hi Eric,
>
> On 12/21/2020 3:20 PM, Eric Biggers wrote:
> > On Fri, Dec 18, 2020 at 01:10:57PM -0800, Megha Dey wrote:
> >> Optimize crypto algorithms using VPCLMULQDQ and VAES AVX512 instructions
> >> (first implemented on Intel's Icelake
On Fri, 18 Dec 2020 at 22:07, Megha Dey wrote:
>
> This is a preparatory patch to introduce the optimized crypto algorithms
> using AVX512 instructions which would require VAES and VPLCMULQDQ support.
>
> Check for VAES and VPCLMULQDQ assembler support using AVX512 registers.
>
> Cc:
On Sat, 16 Jan 2021 at 06:13, Dave Hansen wrote:
>
> On 1/15/21 6:04 PM, Eric Biggers wrote:
> > On Fri, Jan 15, 2021 at 04:20:44PM -0800, Dave Hansen wrote:
> >> On 1/15/21 4:14 PM, Dey, Megha wrote:
> >>> Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
> >> That's
On Fri, 18 Dec 2020 at 22:08, Megha Dey wrote:
>
> Introduce the AVX512 implementation that optimizes the AESNI-GCM encode
> and decode routines using VPCLMULQDQ.
>
> The glue code in AESNI module overrides the existing AVX2 GCM mode
> encryption/decryption routines with the AX512 AES GCM mode
On Fri, 18 Dec 2020 at 22:08, Megha Dey wrote:
>
> Introduce the "by16" implementation of the AES CTR mode using AVX512
> optimizations. "by16" means that 16 independent blocks (each block
> being 128 bits) can be ciphered simultaneously as opposed to the
> current 8 blocks.
>
> The glue code in
On Fri, 18 Dec 2020 at 22:07, Megha Dey wrote:
>
> From: Kyung Min Park
>
> Update the crc_pcl function that calculates T10 Data Integrity Field
> CRC16 (CRC T10 DIF) using VPCLMULQDQ instruction. VPCLMULQDQ instruction
> with AVX-512F adds EVEX encoded 512 bit version of PCLMULQDQ instruction.
On Fri, 15 Jan 2021 at 21:27, Arvind Sankar wrote:
>
> 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():
>
On Sat, 19 Dec 2020 at 03:05, Herbert Xu wrote:
>
> On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote:
> >
> > Questions:
> > - what did I miss or break horribly?
> > - does any of this matter for RT? AIUI, RT runs softirqs from a dedicated
> >
On Wed, 13 Jan 2021 at 23:09, Linus Torvalds
wrote:
>
> On Wed, Jan 13, 2021 at 1:44 PM Russell King - ARM Linux admin
> wrote:
> >
> > So, maybe the Sparc issue was just a similar but different bug in gcc
> > 4.9.x.
>
> Good catch. And I know this bug has happened independently on
> different
angBuiltLinux/linux/issues/256
> Signed-off-by: Arnd Bergmann
Acked-by: Ard Biesheuvel
This can go via the x86 tree directly, IMO
> ---
> arch/x86/platform/efi/efi_64.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/platform/efi/efi_64
Horn
> Cc: Theodore Ts'o
> Reviewed-by: Andy Lutomirski
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
>
> Andrew, please consider taking this patch since the maintainer has been
> ignoring it for 4 months
> (https://lkml.kernel.org/lkml/20200916043652.96
ymore. Fix it to always use the standard constants.
>
> Cc: linux-cry...@vger.kernel.org
> Cc: Andy Lutomirski
> Cc: Jann Horn
> Cc: Theodore Ts'o
> Acked-by: Herbert Xu
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
>
> Andrew, please co
RNDRESEEDCRNG")
> Cc: sta...@vger.kernel.org
> Cc: linux-cry...@vger.kernel.org
> Cc: Andy Lutomirski
> Cc: Jann Horn
> Cc: Theodore Ts'o
> Reviewed-by: Jann Horn
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
>
> Andrew, please consider taking this p
On Tue, 12 Jan 2021 at 23:49, Bjorn Helgaas wrote:
>
> On Sat, Jan 09, 2021 at 10:53:53AM +0100, Ard Biesheuvel wrote:
> > The _DSM #5 method in the ACPI host bridge object tells us whether the
> > OS is permitted to deviate from the resource assignment configured b
On Tue, 12 Jan 2021 at 07:19, Andrew Morton wrote:
>
> On Sun, 10 Jan 2021 13:03:49 +0100 Linus Walleij
> wrote:
>
> > On Sun, Jan 10, 2021 at 11:21 AM hailong wrote:
> >
> > > >> +#ifndef PTE_HWTABLE_PTRS
> > > >> +#define PTE_HWTABLE_PTRS 0
> > > >> +#endif
> > > >
> > > >Can this even
On Mon, 11 Jan 2021 at 04:40, Jeremy Linton wrote:
>
> Hi,
>
> On 1/9/21 5:07 AM, Stefan Wahren wrote:
> > Hi Jeremy,
> >
> > +add Nicolas
> >
> > Am 08.01.21 um 22:13 schrieb Jeremy Linton:
> >> The rpi4 has a Arasan controller it carries over
...
> >> @@ -299,6 +311,8 @@ MODULE_DEVICE_TABLE(of,
On Mon, 4 Jan 2021 at 20:09, Ard Biesheuvel wrote:
>
> On Tue, 17 Nov 2020 at 14:33, Ard Biesheuvel wrote:
> >
> > On Wed, 11 Nov 2020 at 09:19, Ard Biesheuvel wrote:
> > >
> > > (+ Eric)
> > >
> > > On Thu, 5 Nov 2020 at 16:29, Ard Bies
: # v5.4+
Signed-off-by: Ard Biesheuvel
---
drivers/pci/setup-res.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 43eda101fcf4..3b38be081e93 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -410,10 +410,16
(+ Linus)
On Sat, 9 Jan 2021 at 05:50, Hailong liu wrote:
>
> From: Hailong Liu
>
> The size of kasan_early_shadow_pte[] now is PTRS_PER_PTE which defined to
> 512 for arm architecture. This means that it only covers the prev Linux pte
> entries, but not the HWTABLE pte entries for arm.
>
> The
On Fri, 8 Jan 2021 at 19:31, Andrey Konovalov wrote:
>
> On Sun, Jan 3, 2021 at 6:12 PM Lecopzer Chen wrote:
> >
> > Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> > ("kasan: support backing vmalloc space with real shadow memory")
> >
> > Acroding to how x86 ported it [1], they
struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
> >
> > Not even crypto drivers are allowed to assume that desc+1 is where
> > the CRC is stored.
>
> It violates how the shash API is meant to be used in general, but there is a
> test that enforces that the shash_desc
u128_xor() takes pointers to quantities that are assumed to be at least
64-bit aligned, which is not guaranteed to be the case in the smp_c1()
routine. So switch to crypto_xor() instead.
Signed-off-by: Ard Biesheuvel
---
net/bluetooth/smp.c | 5 ++---
1 file changed, 2 insertions(+), 3
(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/firmware/efi/runtime-map. Then compressed boot os
> can not get suitable
On Tue, 17 Nov 2020 at 14:33, Ard Biesheuvel wrote:
>
> On Wed, 11 Nov 2020 at 09:19, Ard Biesheuvel wrote:
> >
> > (+ Eric)
> >
> > On Thu, 5 Nov 2020 at 16:29, Ard Biesheuvel wrote:
> > >
> > > When reseeding the CRNG periodically, arch_get_rand
On Thu, 31 Dec 2020 at 21:09, Pavel Machek wrote:
>
> Hi!
>
> > ecdh_set_secret() casts a void* pointer to a const u64* in order to
> > feed it into ecc_is_key_valid(). This is not generally permitted by
> > the C standard, and leads to actual misalignment faults on ARMv6
> > cores. In some
3a/0x60
> kernel_init_freeable+0x1dd/0x238
> ? rest_init+0xc6/0xc6
> kernel_init+0x8/0x10a
> ret_from_fork+0x1f/0x30
> ---[ end trace 5bd3c1d0b2da ]---
>
> Signed-off-by: Kirill Tkhai
Hello Kirill,
This needs
Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchm
On Sat, 26 Dec 2020 at 11:16, Heinrich Schuchardt wrote:
>
> On 11/27/20 8:20 PM, Heinrich Schuchardt wrote:
> > Since the UEFI 2.8A specification the UEFI enabled firmware provides a
> > configuration table EFI_RT_PROPERTIES_TABLE which indicates which runtime
> > services are enabled. The EFI
On Fri, 25 Dec 2020 at 20:14, Eric Biggers wrote:
>
> On Tue, Dec 22, 2020 at 05:06:27PM +0100, Ard Biesheuvel wrote:
> > The AES-NI implementation of XTS was impacted significantly by the retpoline
> > changes, which is due to the fact that both its asm helper and the chai
On Thu, 24 Dec 2020 at 09:55, Borislav Petkov wrote:
>
> Hi Ard,
>
> On Wed, Dec 23, 2020 at 11:43:45PM +0100, Ard Biesheuvel wrote:
> > I hope this report is not holding up the PR for efi/core?
>
> I was just looking at that yesterday...
>
> But nah, lemme send it.
>
Cheers,
Hello Boris,
On Wed, 23 Dec 2020 at 22:04, Borislav Petkov wrote:
>
> On Wed, Dec 23, 2020 at 12:02:33PM -0800, Nick Desaulniers wrote:
> > On Wed, Dec 23, 2020 at 10:36 AM Borislav Petkov wrote:
> > >
> > > On Fri, Dec 18, 2020 at 09:03:14AM +0800, kernel test robot wrote:
> > > > tree:
helpers. Instead, let's adopt the arm64 strategy, i.e.,
provide a helper which can consume inputs of any size, provided that the
penultimate, full block is passed via the last call if ciphertext stealing
needs to be applied.
This also allows us to enable the XTS mode for i386.
Signed-off-by: Ard
t;x86/retpoline/crypto: Convert crypto assembler indirect
jumps")
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/aesni-intel_asm.S | 115
arch/x86/crypto/aesni-intel_glue.c | 25 +++--
2 files changed, 84 insertions(+), 56 deletions(-)
diff --git a/arch/x86/crypto/aesni-i
Biggers
Cc: Herbert Xu
Ard Biesheuvel (2):
crypto: x86/aes-ni-xts - use direct calls to and 4-way stride
crypto: x86/aes-ni-xts - rewrite and drop indirections via glue helper
arch/x86/crypto/aesni-intel_asm.S | 353
arch/x86/crypto/aesni-intel_glue.c | 230
On Fri, 18 Dec 2020 at 22:07, Megha Dey wrote:
>
> From: Kyung Min Park
>
> Optimize GHASH computations with the 512 bit wide VPCLMULQDQ instructions.
> The new instruction allows to work on 4 x 16 byte blocks at the time.
> For best parallelism and deeper out of order execution, the main loop
On Fri, 18 Dec 2020 at 20:12, Ard Biesheuvel wrote:
>
> On Fri, 18 Dec 2020 at 15:01, Ard Biesheuvel wrote:
> >
> > On Fri, 18 Dec 2020 at 15:00, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Fri, Dec 18, 2020 at 01:48:09PM +,
On Fri, 18 Dec 2020 at 15:01, Ard Biesheuvel wrote:
>
> On Fri, 18 Dec 2020 at 15:00, Russell King - ARM Linux admin
> wrote:
> >
> > On Fri, Dec 18, 2020 at 01:48:09PM +, Guillaume Tucker wrote:
> > > Please see the bisection report below about a boot failu
/end is no longer
expensive?
Cc: Dave Martin
Cc: Mark Brown
Cc: Herbert Xu
Cc: Eric Biggers
Cc: Will Deacon
Cc: Catalin Marinas
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Sebastian Andrzej Siewior
Cc: Ingo Molnar
Ard Biesheuvel (5):
crypto: aead - disallow en/decrypt for non-task
Now that kernel mode SIMD is guaranteed to be available when executing
in task or softirq context, we no longer need scalar fallbacks to use
when the NEON is unavailable. So get rid of them.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/ghash-ce-glue.c | 209 +---
1 file
is cheap, we can relax this
restriction, by increasing the granularity of kernel mode NEON code, and
always disabling softirq processing while the NEON is being used in task
context.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 19 +--
arch/arm64/kernel/asm
that GCM executes at 1-2 cycles per bytes and operates on 64 byte
chunks, doing a yield check every iteration should limit the scheduling
(or softirq) latency to < 200 cycles, which is a very conservative upper
bound.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/ghash-ce-core.S |
In order to ensure that kernel mode SIMD routines will not need a scalar
fallback if they run with softirqs disabled, disallow any use of the
AEAD encrypt and decrypt routines from outside of task or softirq context.
Signed-off-by: Ard Biesheuvel
---
crypto/aead.c | 10 ++
1 file
In order to ensure that kernel mode SIMD routines will not need a scalar
fallback if they run with softirqs disabled, disallow any use of the
skcipher encrypt and decrypt routines from outside of task or softirq
context.
Signed-off-by: Ard Biesheuvel
---
crypto/skcipher.c | 10 ++
1
On Fri, 18 Dec 2020 at 15:00, Russell King - ARM Linux admin
wrote:
>
> On Fri, Dec 18, 2020 at 01:48:09PM +, Guillaume Tucker wrote:
> > Please see the bisection report below about a boot failure on
> > ox820-cloudengines-pogoplug-series-3. There was also a bisection
> > yesterday with
to
> -maarch64linux based on the toolchain configuration.
>
> LLD will always create RELRO relocation types regardless of target
> emulation.
>
RELRO program header
> To avoid the above warning when linking with BFD, pass -z norelro only
> when linking with LLD or with -maarch64linux
Hello Chang,
On Wed, 16 Dec 2020 at 18:47, Chang S. Bae wrote:
>
> Key Locker (KL) is Intel's new security feature that protects the AES key
> at the time of data transformation. New AES SIMD instructions -- as a
> successor of Intel's AES-NI -- are provided to encode an AES key and
> reference
a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -16766,6 +16766,18 @@ M: Ion Badulescu
> > S: Odd Fixes
> > F: drivers/net/ethernet/adaptec/starfire*
> >
> > +STATIC BRANCH/CALL
> > +M: Peter Zijlstra
> > +M: Josh Poimboeuf
> > +M: Jason Ba
The following commit has been merged into the efi/core branch of tip:
Commit-ID: d72c8b0e1cacc39495cd413433d260e8ae59374a
Gitweb:
https://git.kernel.org/tip/d72c8b0e1cacc39495cd413433d260e8ae59374a
Author:Ard Biesheuvel
AuthorDate:Sun, 13 Dec 2020 16:07:03 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: e0a6aa30504cb8179d07609fb6386705e8f00663
Gitweb:
https://git.kernel.org/tip/e0a6aa30504cb8179d07609fb6386705e8f00663
Author:Ard Biesheuvel
AuthorDate:Sun, 13 Dec 2020 09:39:40 +01:00
On Mon, 14 Dec 2020 at 06:48, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from include/linux/kernel.h:14,
> from include/linux/list.h:9,
> from
On Sat, 12 Dec 2020 at 10:36, Ard Biesheuvel wrote:
>
> On Fri, 11 Dec 2020 at 20:07, Eric Biggers wrote:
> >
> > On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> > > The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> >
On Fri, 11 Dec 2020 at 20:07, Eric Biggers wrote:
>
> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> > The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> > On platforms with Zhaoxin CPUs supporting this X86 feature, When
> > crc32c-intel and crc32c-generic are
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 91c1c092f27da4164d55ca81e0a483108f8a3235
Gitweb:
https://git.kernel.org/tip/91c1c092f27da4164d55ca81e0a483108f8a3235
Author:Ard Biesheuvel
AuthorDate:Mon, 07 Dec 2020 17:33:33 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 54649911f31b6e7c2a79a1426ca98259139e4c35
Gitweb:
https://git.kernel.org/tip/54649911f31b6e7c2a79a1426ca98259139e4c35
Author:Ard Biesheuvel
AuthorDate:Thu, 29 Oct 2020 14:49:01 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 4dbe44fb538c59a4adae5abfa9ded2f310250315
Gitweb:
https://git.kernel.org/tip/4dbe44fb538c59a4adae5abfa9ded2f310250315
Author:Ard Biesheuvel
AuthorDate:Mon, 07 Dec 2020 18:40:53 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: c0249238feefbbb99d517d06ace4338393901b67
Gitweb:
https://git.kernel.org/tip/c0249238feefbbb99d517d06ace4338393901b67
Author:Ard Biesheuvel
AuthorDate:Thu, 12 Nov 2020 15:42:27 +01:00
On Tue, 8 Dec 2020 at 17:49, Paul Cercueil wrote:
>
> Introduce a new header , that brings two new macros:
> IF_ENABLED_OR_ELSE() and IF_ENABLED().
>
> IF_ENABLED_OR_ELSE(CONFIG_FOO, a, b) evaluates to (a) if CONFIG_FOO is set
> to 'y' or 'm', (b) otherwise. It is used internally to define the
>
On Fri, 4 Dec 2020 at 22:30, Brijesh Singh wrote:
>
> The SEV FW version >= 0.23 added a new command that can be used to query
> the attestation report containing the SHA-256 digest of the guest memory
> encrypted through the KVM_SEV_LAUNCH_UPDATE_{DATA, VMSA} commands and
> sign the report with
On Tue, 8 Dec 2020 at 14:25, David Howells wrote:
>
> I wonder - would it make sense to reserve two arrays of scatterlist structs
> and a mutex per CPU sufficient to map up to 1MiB of pages with each array
> while the krb5 service is in use?
>
> That way sunrpc could, say, grab the mutex, map the
On Tue, 8 Dec 2020 at 13:04, Russell King - ARM Linux admin
wrote:
>
> On Tue, Dec 08, 2020 at 01:02:05PM +0100, Ard Biesheuvel wrote:
> > On Tue, 8 Dec 2020 at 12:39, Stephen Rothwell wrote:
> > >
> > > Hi all,
> > >
> > > In commit
> > &g
On Tue, 8 Dec 2020 at 12:39, Stephen Rothwell wrote:
>
> Hi all,
>
> In commit
>
> 4812d516af55 ("ARM: 9027/1: head.S: explicitly map DT even if it lives in
> the first physical section")
>
> Fixes tag
>
> Fixes: 149a3ffe62b9dbc3 ("9012/1: move device tree mapping out of linear
> region")
>
On Mon, 7 Dec 2020 at 15:15, David Howells wrote:
>
> Ard Biesheuvel wrote:
>
> > > I wonder if it would help if the input buffer and output buffer didn't
> > > have to correspond exactly in usage - ie. the output buffer could be used
> > > at a slower rate t
On Mon, 7 Dec 2020 at 14:50, Horia Geantă wrote:
>
> On 11/26/2020 9:09 AM, Ard Biesheuvel wrote:
> > On Wed, 25 Nov 2020 at 22:39, Iuliana Prodan wrote:
> >>
> >> On 11/25/2020 11:16 PM, Ard Biesheuvel wrote:
> >>> On Wed, 25 Nov 2020 a
On Mon, 7 Dec 2020 at 15:28, Jason A. Donenfeld wrote:
>
> Hi Ard,
>
> On Tue, Dec 1, 2020 at 1:24 PM Ard Biesheuvel wrote:
> > > > > is implemented. In most cases, these are special instructions, but in
> > > > > some cases, such as on AR
On Mon, 7 Dec 2020 at 13:02, David Howells wrote:
>
> Ard Biesheuvel wrote:
>
> > > Yeah - the problem with that is that for sunrpc, we might be dealing with
> > > 1MB
> > > plus bits of non-contiguous pages, requiring >8K of scatterlist elements
> >
On Mon, 7 Dec 2020 at 10:42, Mike Rapoport wrote:
>
> On Mon, Dec 07, 2020 at 09:35:06AM +, Marc Zyngier wrote:
> > On 2020-12-07 09:09, Ard Biesheuvel wrote:
> > > (+ Marc)
> > >
> > > On Fri, 4 Dec 2020 at 12:14, Will Deacon wrote:
> > > &g
(+ Marc)
On Fri, 4 Dec 2020 at 12:14, Will Deacon wrote:
>
> On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote:
> > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP
> > do not free the reserved memory for the page map, decrease the section
> > size can reduce the waste
On Sun, 6 Dec 2020 at 03:49, Masahiro Yamada wrote:
>
> On Fri, Dec 4, 2020 at 8:10 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > genksyms does not know or care about the _Static_assert() built-in,
> > and sometimes falls back to ignoring the later symbols, which causes
> >
On Tue, 1 Dec 2020 at 13:23, Ard Biesheuvel wrote:
>
> (+ Jason)
>
> On Fri, 20 Nov 2020 at 05:11, Eric Biggers wrote:
> >
> > On Wed, Nov 11, 2020 at 09:19:37AM +0100, Ard Biesheuvel wrote:
> > > (+ Eric)
> > >
> > > On Thu, 5 Nov 2020 at
On Sat, 5 Dec 2020 at 22:15, James Bottomley
wrote:
>
> [Rostedt added because this is all his fault]
> On Sat, 2020-12-05 at 21:57 +0100, Ard Biesheuvel wrote:
> > On Sat, 5 Dec 2020 at 21:24, James Bottomley
> > wrote:
> [...]
> > > > So I don't object t
On Sat, 5 Dec 2020 at 21:24, James Bottomley
wrote:
>
> On Sat, 2020-12-05 at 20:36 +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 F
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 indicates if a string begins w
On Fri, 4 Dec 2020 at 18:19, David Howells wrote:
>
> Ard Biesheuvel wrote:
>
> > The tricky thing with CTS is that you have to ensure that the final
> > full and partial blocks are presented to the crypto driver as one
> > chunk, or it won't be able to perf
On Fri, 4 Dec 2020 at 18:06, wrote:
>
> From: Francis Laniel
>
> The two functions indicates if a string begins with a given prefix.
> The only difference is that strstarts() returns a bool while str_has_prefix()
> returns the length of the prefix if the string begins with it or 0 otherwise.
>
On Fri, 4 Dec 2020 at 17:52, David Howells wrote:
>
> Bruce Fields wrote:
>
> > OK, I guess I don't understand the question. I haven't thought about
> > this code in at least a decade. What's an auxilary cipher? Is this a
> > question about why we're implementing something, or how we're
> >
On Thu, 3 Dec 2020 at 23:26, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> When the SIMD portion of the driver is disabled, the compiler cannot
> figure out in advance if it will be called:
>
> ERROR: modpost: "crypto_aegis128_update_simd" [crypto/aegis128.ko] undefined!
>
> Add a conditional
0C00 (CS3 space),
> i.e. not at a multiple of 128 MiB.
>
> Suggested-by: Nicolas Pitre
> Suggested-by: Ard Biesheuvel
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ard Biesheuvel
Unfortunately, this may still blindly overwrite memory that is marked
as reserved in the device tree,
gned-off-by: Geert Uytterhoeven
Reviewed-by: Ard Biesheuvel
> ---
> v10:
> - New.
> ---
> arch/arm/boot/compressed/head.S | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/
to little endian */
> + eor \tmp, \val, \val, ror #16
> + bic \tmp, \tmp, #0x00ff
> + mov \val, \val, ror #8
> + eor \val, \val, \tmp, lsr #8
> +#endif
> + .endm
> +
Thanks for cleaning thi
On Thu, 3 Dec 2020 at 02:35, Iuliana Prodan (OSS)
wrote:
>
> From: Iuliana Prodan
>
> This series removes CRYPTO_ALG_ALLOCATES_MEMORY flag and
> allocates the memory needed by the driver, to fulfil a
> request, within the crypto request object.
> The extra size needed for base extended
On Tue, 1 Dec 2020 at 20:53, Randy Dunlap wrote:
>
> On 12/1/20 2:03 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20201130:
> >
>
> on i386 or x86_64:
>
> CONFIG_CRYPTO_AEGIS128=m
> CONFIG_CRYPTO_AEGIS128_AESNI_SSE2=y
>
>
> ERROR: modpost: "crypto_aegis128_update_simd"
On Tue, 1 Dec 2020 at 16:17, Rongwei Wang
wrote:
>
>
>
> > 2020年12月1日 下午10:54，Borislav Petkov 写道：
> >
> > On Tue, Dec 01, 2020 at 10:33:42PM +0800, wangrongwei wrote:
> >> Yes, and x86 also provides two instructions with the same name in the
> >> instruction set, but not in ARM.
> >
> > Sorry, I
(+ Jason)
On Fri, 20 Nov 2020 at 05:11, Eric Biggers wrote:
>
> On Wed, Nov 11, 2020 at 09:19:37AM +0100, Ard Biesheuvel wrote:
> > (+ Eric)
> >
> > On Thu, 5 Nov 2020 at 16:29, Ard Biesheuvel wrote:
> > >
> > > When reseeding the CRNG periodically, a
On Mon, 30 Nov 2020 at 07:58, Tianjia Zhang
wrote:
>
>
>
> On 11/30/20 10:24 AM, Herbert Xu wrote:
> > On Mon, Nov 30, 2020 at 10:21:56AM +0800, Tianjia Zhang wrote:
> >>
> >>> That is true only if there are non-generic implementations of
> >>> the algorithms, which is not the case here. Please
101 - 200 of 5028 matches
Mail list logo
