On Sat, 2 Dec 2023 at 09:49, Justin Chen wrote:
>
>
>
> On 12/1/23 10:53 PM, Ard Biesheuvel wrote:
> > On Fri, 1 Dec 2023 at 23:59, Justin Chen wrote:
> >>
> >>
> >>
> >> On 12/1/23 10:07 AM, Steven Rostedt wrote:
> >&
On Fri, 1 Dec 2023 at 23:59, Justin Chen wrote:
>
>
>
> On 12/1/23 10:07 AM, Steven Rostedt wrote:
> > On Fri, 1 Dec 2023 09:25:59 -0800
> > Justin Chen wrote:
> >
> >>> It appears the sub instruction at 0x6dd0 correctly accounts for the
> >>> extra 8 bytes, so the frame pointer is valid. So it
On Fri, 1 Dec 2023 at 00:48, Justin Chen wrote:
>
> Hello,
>
> Ran into an odd bug that I am unsure what the solution is. Tested a few
> kernels versions and they all fail the same.
>
> FUNCTION_GRAPH_FP_TEST was enabled with 953f534a7ed6 ("ARM: ftrace:
> enable HAVE_FUNCTION_GRAPH_FP_TEST").
On Tue, 20 Apr 2021 at 17:54, Rob Herring wrote:
>
> On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
> wrote:
> >
> >
> >
> > On 4/20/21 4:45 PM, Rob Herring wrote:
> > > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
> > > wrote:
> > >>
> > >> Hi,
> > >
> > > Greg or Sasha won't know what
ents with space in calls to clock_gettime_return to make it
> compatible with IAS.
>
> Link:
> https://sourceware.org/binutils/docs/as/Macro.html#Macro
> https://github.com/ClangBuiltLinux/linux/issues/1349
>
> Suggested-by: Ard Biesheuvel
Please remove this tag - the onl
On Fri, 16 Apr 2021 at 20:16, Jian Cai wrote:
>
> LLVM's integrated assembler does not support using commas separating
> the name and arguments in .macro. However, only spaces are used in the
> manual page. This replaces commas between macro names and the subsequent
> arguments with space in
On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote:
>
> On 07.04.21 19:26, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
> > reserved
On Tue, 13 Apr 2021 at 07:43, Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
>
> arch/arm64/include/asm/assembler.h
>
> between commits:
>
> 27248fe1abb2 ("arm64: assembler: remove conditional NEON yield macros")
> 13150149aa6d
On Mon, 12 Apr 2021 at 21:51, Chris von Recklinghausen
wrote:
>
> On 4/12/21 3:27 PM, Ard Biesheuvel wrote:
> > On Mon, 12 Apr 2021 at 21:20, Eric Biggers wrote:
> >> On Mon, Apr 12, 2021 at 03:04:58PM -0400, Chris von Recklinghausen wrote:
> >>> On 4/
On Mon, 12 Apr 2021 at 21:20, Eric Biggers wrote:
>
> On Mon, Apr 12, 2021 at 03:04:58PM -0400, Chris von Recklinghausen wrote:
> > On 4/12/21 1:45 PM, Eric Biggers wrote:
> > > On Mon, Apr 12, 2021 at 10:09:32AM -0400, Chris von Recklinghausen wrote:
> > > > Suspend fails on a system in fips
On Sun, 4 Apr 2021 at 20:12, Andy Shevchenko wrote:
>
> Switch to use for_each_acpi_dev_match() instead of home grown analogue.
> No functional change intended.
>
> Signed-off-by: Andy Shevchenko
> ---
> v2: fixed refcounting
> (example from which I took the v1 approach has been broken, fix
On Thu, 8 Apr 2021 at 18:53, Peter Zijlstra wrote:
>
> Hi!
>
> Given code like:
>
> DEFINE_STATIC_KEY_FALSE(sched_schedstats);
>
> #define schedstat_enabled()
> static_branch_unlikely(_schedstats)
> #define schedstat_set(var, val) do { if (schedstat_enabled()) { var =
>
On Tue, 6 Apr 2021 at 13:54, Mark Rutland wrote:
>
> [adding Ard for EFI runtime services bits]
>
> On Thu, Apr 01, 2021 at 04:32:12PM -0700, Sami Tolvanen wrote:
> > Disable CFI checking for functions that switch to linear mapping and
> > make an indirect call to a physical address, since the
On Thu, 1 Apr 2021 at 15:54, Chris von Recklinghausen
wrote:
>
> On 4/1/21 9:38 AM, Rafael J. Wysocki wrote:
> > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> >> On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> >>> On Tue, 2021-03-30 at
On Thu, 1 Apr 2021 at 15:38, Rafael J. Wysocki wrote:
>
> On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> >
> > On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> > >
> > > On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> > > >
On Thu, 1 Apr 2021 at 15:34, Rafael J. Wysocki wrote:
>
> On Thu, Apr 1, 2021 at 2:25 PM Chris von Recklinghausen
> wrote:
> >
> > Suspend fails on a system in fips mode because md5 is used for the e820
> > integrity check and is not available. Use crc32 instead.
> >
> > Fixes: 62a03defeabd ("PM
On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
>
> On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> > On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > > On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > > > On Tue, Mar 30, 2
(+ Arvind)
On Tue, 30 Mar 2021 at 19:57, Daniel Walker wrote:
>
> This adds code to handle the generic command line changes.
> The efi code appears that it doesn't benefit as much from this design
> as it could.
>
> For example, if you had a prepend command line with "nokaslr" then
> you might
On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
>
> On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > Hi,
> > > MD5 was marked incompliant with FIPS in 2009:
> > > a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged
(+ Pavel)
On Mon, 29 Mar 2021 at 15:42, Greg Kroah-Hartman
wrote:
>
> On Mon, Mar 29, 2021 at 03:08:52PM +0200, Ard Biesheuvel wrote:
> > On Mon, 29 Mar 2021 at 12:12, Greg Kroah-Hartman
> > wrote:
> > >
> > > On Mon, Mar 29, 2021 at 03:05:25PM +0530, Nare
d...@arm.com
> > > Signed-off-by: Anshuman Khandual
> > > Reviewed-by: David Hildenbrand
> > > Reviewed-by: Catalin Marinas
> > > Cc: Will Deacon
> > > Cc: Ard Biesheuvel
> > > Cc: Mark Rutland
> > > Cc: Heiko Carstens
> >
On Wed, 24 Mar 2021 at 15:54, Changbin Du wrote:
>
> setup_arch() would invoke efi_init()->efi_get_fdt_params(). If no
> valid fdt found then initial_boot_params will be null. So we
> should stop further fdt processing here. I encountered this
> issue on risc-v.
>
> Signed-off-by: Changbin Du
On Fri, 26 Mar 2021 at 03:22, Tianjia Zhang
wrote:
>
> In the process of calculating the hash, use the more accurate type
> 'u32' instead of the original 'unsigned int' to avoid ambiguity.
>
> Signed-off-by: Tianjia Zhang
I don't see the point of this patch. u32 and unsigned int are always
the
gt;
> John Millikin (1):
> x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)
>
> Nathan Chancellor (2):
> x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS
> efi/libstub: Add $(CLANG_FLAGS) to x86 flags
>
Acked-by: Ard Biesheuvel
> arch/x86/Makefile
On Thu, 25 Mar 2021 at 07:22, chenjun (AM) wrote:
>
> 在 2021/3/24 16:29, Ard Biesheuvel 写道:
> > On Wed, 24 Mar 2021 at 08:27, chenjun (AM) wrote:
> >>
> >> Hi
> >>
> >> I make a Image for arm64 (without CONFIG_RANDOMIZE_BASE). And a ko (13M)
>
On Thu, 25 Mar 2021 at 08:43, Peter Zijlstra wrote:
>
> On Thu, Mar 25, 2021 at 01:42:41AM +0100, Rasmus Villemoes wrote:
> > > Actually, it looks like I can't select PREEMPT_DYNAMIC> and tweaking
> > > Kconfig
> >
> > Ah, there's no prompt on the "bool" line, so it doesn't show up. That
> >
On Wed, 24 Mar 2021 at 08:27, chenjun (AM) wrote:
>
> Hi
>
> I make a Image for arm64 (without CONFIG_RANDOMIZE_BASE). And a ko (13M)
> can not be inserted.
>
How many large modules have you loaded already? The module region is
only 128 MB, so if your modules are huge, you may run out of space.
On Tue, 23 Mar 2021 at 09:36, Tianjia Zhang
wrote:
>
> The kernel module signature supports the option to use the SM3
> secure hash (OSCCA GM/T 0004-2012 SM3).
>
> Signed-off-by: Tianjia Zhang
A secure hash is not the same as a signature. Looking at the patch,
the asymmetric algorithm that is
305_simd_init() takes only the key but not the nonce, so it
should only be passed 16 bytes.
> Fixes: 1c08a104360f ("crypto: poly1305 - add new 32 and 64-bit generic
> versions")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Ard Biesheuvel
> ---
> arch/arm/crypto/pol
On Mon, 22 Mar 2021 at 16:57, Ard Biesheuvel wrote:
>
> On Mon, 22 Mar 2021 at 14:26, Will Deacon wrote:
> >
> > On Fri, 19 Mar 2021 18:41:06 +, Mark Rutland wrote:
> > > We recently converted arm64 to use arch_stack_walk() in commit:
> > >
> > >
On Mon, 22 Mar 2021 at 14:26, Will Deacon wrote:
>
> On Fri, 19 Mar 2021 18:41:06 +, Mark Rutland wrote:
> > We recently converted arm64 to use arch_stack_walk() in commit:
> >
> > 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK")
> >
> > The core stacktrace code expects that
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: fb98cc0b3af2ba4d87301dff2b381b12eee35d7d
Gitweb:
https://git.kernel.org/tip/fb98cc0b3af2ba4d87301dff2b381b12eee35d7d
Author:Ard Biesheuvel
AuthorDate:Wed, 10 Mar 2021 08:33:19 +01:00
On Wed, 10 Mar 2021 at 09:37, Lv Yunlong wrote:
>
> In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next
> use the unmapped rsv. Use the unmapped pages will cause segment
> fault.
>
> Fixes: 18df7577adae6 ("efi/memreserve: deal with memreserve entries in
> unmapped memory")
>
take it as a fix.
>
> I don't see any issue with this patch, more so given that the IBFT
> legacy discovery method was decoupled from the ACPI table method,
> so it looks sound on ARM64.
>
> However, I would like to get Al and Ard opinions on this to make sure
> there is not something I am missing (in particular wrt the rationale
> behind the "Not Supported" in the docs).
>
Both the original change and this documentation change look fine to me.
Acked-by: Ard Biesheuvel
On Thu, 18 Mar 2021 at 08:29, Ran Wang wrote:
>
> Hi Ard,
>
>
> On Wednesday, March 17, 2021 4:29 PM, Ard Biesheuvel wrote:
> >
> > On Wed, 17 Mar 2021 at 09:04, Jens Wiklander
> > wrote:
> > >
> > > On Fri, Mar 12, 2021 at 04:36:53PM +0800,
On Wed, 17 Mar 2021 at 09:04, Jens Wiklander wrote:
>
> On Fri, Mar 12, 2021 at 04:36:53PM +0800, Ran Wang wrote:
> > This patch add ACPI support for optee driver.
> >
> > Signed-off-by: Ran Wang
> > ---
> > drivers/tee/optee/core.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> >
On Tue, 16 Mar 2021 at 11:04, Arnd Bergmann wrote:
>
> On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov wrote:
> >
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:1e28eed1 Linux 5.12-rc3
> > > git
On Wed, 6 Jan 2021 at 11:35, Andre Przywara wrote:
>
> From: Ard Biesheuvel
>
> Implement arch_get_random_seed_*() for ARM based on the firmware
> or hypervisor provided entropy source described in ARM DEN0098.
>
> This will make the kernel's random number generator consu
(+ James)
On Wed, 10 Mar 2021 at 13:41, Ard Biesheuvel wrote:
>
> On Wed, 10 Mar 2021 at 12:18, Will Deacon wrote:
> >
> > On Tue, Mar 09, 2021 at 07:32:16PM -0500, Mark Salter wrote:
> > > I ran into an early boot soft lockup on a Qualcomm Amberwing using a v5.11
>
On Wed, 10 Mar 2021 at 12:18, Will Deacon wrote:
>
> On Tue, Mar 09, 2021 at 07:32:16PM -0500, Mark Salter wrote:
> > I ran into an early boot soft lockup on a Qualcomm Amberwing using a v5.11
> > kernel configured for 52-bit VA. This turned into a panic with a v5.12-rc2
> > kernel.
> >
> > The
On Tue, 9 Mar 2021 at 13:37, Michal Suchanek wrote:
>
> When using dummy-tools STACKPROTECTOR_PER_TASK is unconditionally
> selected. This defeats the purpose of the all-enabled tool.
>
What is dummy-tools and why should we care about it?
> Description copied from arm
>
> Cc: Masahiro Yamada
>
On Tue, 9 Mar 2021 at 01:03, Daniel Walker wrote:
>
> This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
> option.
>
> Cc: xe-linux-exter...@cisco.com
> Signed-off-by: Ruslan Ruslichenko
> Signed-off-by: Ruslan Bilovol
> Signed-off-by: Daniel Walker
> ---
> arch/x86/Kconfig
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 9e9888a0fe97b9501a40f717225d2bef7100a2c1
Gitweb:
https://git.kernel.org/tip/9e9888a0fe97b9501a40f717225d2bef7100a2c1
Author:Ard Biesheuvel
AuthorDate:Fri, 05 Mar 2021 10:21:05 +01:00
; | ^
>
> ---8<---
> This patch fixes missing prototype warnings in crypto/aegis128-neon.c.
>
> Fixes: a4397635afea ("crypto: aegis128 - provide a SIMD...")
> Reported-by: kernel test robot
> Signed-off-by: Herbert Xu
Acked-by:
On Wed, 24 Feb 2021 at 19:43, Kairui Song wrote:
>
> Currently when efi_memmap_insert is called, only the
> physical memory addresses are re-calculated. The virt
> addresses of the split entries are untouched.
>
> If any later operation depends on the virt_addaress info, things
> will go wrong.
On Thu, 4 Mar 2021 at 10:46, Lukas Wunner wrote:
>
> On Thu, Mar 04, 2021 at 11:28:37AM +0300, Heikki Krogerus wrote:
> > The old device property API is going to be removed.
> > Replacing the device_add_properties() call with the software
> > node API equivalent,
On Wed, 3 Mar 2021 at 18:10, Julien Thierry wrote:
>
> From: Raphael Gault
>
> Add build option to run stack validation at compile time.
>
> When requiring stack validation, jump tables are disabled as it
> simplifies objtool analysis (without having to introduce unreliable
> artifacs). In local
On Fri, 5 Mar 2021 at 12:38, Marc Zyngier wrote:
>
> On Fri, 05 Mar 2021 02:38:17 +,
> Sami Tolvanen wrote:
> >
> > On Thu, Mar 4, 2021 at 2:34 PM Sami Tolvanen
> > wrote:
> > >
> > > On Thu, Mar 4, 2021 at 2:17 PM Marc Zyngier wrote:
> > > >
> > > > On Thu, 04 Mar 2021 21:25:41 +,
>
(+ Lukas)
On Thu, 4 Mar 2021 at 09:28, Heikki Krogerus
wrote:
>
> The old device property API is going to be removed.
> Replacing the device_add_properties() call with the software
> node API equivalent, device_create_managed_software_node().
>
> Signed-off-by: Heikki Krogerus
> ---
>
On Sat, 27 Feb 2021 at 04:29, Julian Braha wrote:
>
> When EFI_EMBEDDED_FIRMWARE is enabled, and CRYPTO is not enabled,
> Kbuild gives the following warning:
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_SHA256
> Depends on [n]: CRYPTO [=n]
> Selected by [y]:
> -
;
I gave this series a spin with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y,
and all the tests still pass.
Tested-by: Ard Biesheuvel
Acked-by: Ard Biesheuvel
> arch/x86/crypto/Makefile | 2 -
> arch/x86/crypto/aesni-intel_avx-x86_64.S | 28 +
> arch/x86/cr
(cc Peter)
On Thu, 18 Feb 2021 at 21:18, Heinrich Schuchardt wrote:
>
> UEFI variables ConInDev, ConOutDev, ConErrDev are volatile variables that
> are set by the firmware on every reset. It does not make sense to set these
> variables via the efivarfs filesystem.
>
> Signed-off-by: Heinrich
On Wed, 17 Feb 2021 at 10:42, Will Deacon wrote:
>
> [Please include arm64 and kvm folks for threads involving the stage-2 MMU]
>
> On Tue, Feb 16, 2021 at 03:47:52PM +0530, Preeti Nagar wrote:
> > The changes introduce a new security feature, RunTime Integrity Check
> > (RTIC), designed to
On Tue, 16 Feb 2021 at 11:10, Peter Zijlstra wrote:
>
> On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote:
> > [ TL;DR for the non-ARM folks on CC: disabling softirq processing when using
> > SIMD in kernel mode could reduce complexity and improve perfor
On Tue, 16 Feb 2021 at 04:12, Anshuman Khandual
wrote:
>
>
>
> On 2/16/21 1:21 AM, Pavel Tatashin wrote:
> > On Mon, Feb 15, 2021 at 2:34 PM Ard Biesheuvel wrote:
> >>
> >> On Mon, 15 Feb 2021 at 20:30, Pavel Tatashin
> >> wrote:
> >&
On Mon, 15 Feb 2021 at 20:30, Pavel Tatashin wrote:
>
> > Can't we simply use signed arithmetic here? This expression works fine
> > if the quantities are all interpreted as s64 instead of u64
>
> I was thinking about that, but I do not like the idea of using sign
> arithmetics for physical
On Mon, 15 Feb 2021 at 20:22, Pavel Tatashin wrote:
>
> Memory hotplug may fail on systems with CONFIG_RANDOMIZE_BASE because the
> linear map range is not checked correctly.
>
> The start physical address that linear map covers can be actually at the
> end of the range because of randomization.
(+ Linus)
On Wed, 3 Feb 2021 at 19:24, Florian Fainelli wrote:
>
> On 1/27/21 3:09 AM, Alexander A Sverdlin wrote:
> > From: Alexander Sverdlin
> >
> > FTRACE's function tracer currently doesn't always work on ARM with
> > MODULE_PLT option enabled. If the module is loaded too far, FTRACE's
> >
On Wed, 20 Jan 2021 at 16:44, Dave Martin wrote:
>
> On Tue, Jan 19, 2021 at 05:29:05PM +0100, Ard Biesheuvel wrote:
> > On Tue, 19 Jan 2021 at 17:01, Dave Martin wrote:
> > >
> > > On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote:
> > >
On Fri, 29 Jan 2021 at 00:30, Ard Biesheuvel wrote:
>
> On Thu, 28 Jan 2021 at 23:28, Arnd Bergmann wrote:
> >
> > On Thu, Jan 28, 2021 at 10:03 PM Ard Biesheuvel wrote:
> > > On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers
> > > wrote
On Thu, 11 Feb 2021 at 13:57, Vincenzo Frascino
wrote:
>
> The simplification of mte_get_random_tag() caused the introduction of the
> warning below:
>
> In file included from arch/arm64/include/asm/kasan.h:9,
> from include/linux/kasan.h:16,
> from
e+0x1c/0x24)
> (SyS_clone) from (__sys_trace_return+0x0/0x10)
> Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)
>
> Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support")
> Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM")
> Sign
t thread happening concurrently with an EFI runtime service call
> would be misinterpreted as an EFI page fault. Fix that.
>
> This isn't quite exact. We could do better by using a special CS for
> calls into EFI.
>
> Cc: Dave Hansen
> Cc: Peter Zijlstra
> Cc: Ard Biesheuvel
&g
dui0473/c/writing-arm-assembly-language/assembly-language-changes-after-rvctv2-1
> Link: https://github.com/ClangBuiltLinux/linux/issues/1271
> Reported-by: Arnd Bergmann
> Signed-off-by: Nick Desaulniers
Acked-by: Ard Biesheuvel
> ---
> arch/arm/probes/kprobes/test-arm.c | 290
Renato Golin
> Suggested-by: David Spickett
> Signed-off-by: Nick Desaulniers
Acked-by: Ard Biesheuvel
But can we add a bit more context to the commit log, please? It is not
obvious to the casual reader why it is OK to emit UNPREDICTABLE
opcodes, i.e., that these are selftests that
On Mon, 8 Feb 2021 at 20:30, Kaneda, Erik wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel
> > Sent: Monday, February 8, 2021 11:14 AM
> > To: Kaneda, Erik
> > Cc: Rafael J. Wysocki ; Shawn Guo
> > ; Linux ARM > ker
On Mon, 8 Feb 2021 at 20:07, Kaneda, Erik wrote:
>
>
>
> > -Original Message-
> > From: Rafael J. Wysocki
> > Sent: Monday, February 8, 2021 5:01 AM
> > To: Shawn Guo ; Ard Biesheuvel
> > ; Kaneda, Erik
> > Cc: Linux ARM ; ACPI Devel Malin
On Mon, 8 Feb 2021 at 15:32, Will Deacon wrote:
>
> Hi Marc,
>
> On Mon, Feb 08, 2021 at 09:57:09AM +, Marc Zyngier wrote:
> > It recently came to light that there is a need to be able to override
> > some CPU features very early on, before the kernel is fully up and
> > running. The reasons
On Mon, 8 Feb 2021 at 07:37, Vitaly Chikunov wrote:
>
> Herbert,
>
> On Fri, Jan 29, 2021 at 02:00:04PM +1100, Herbert Xu wrote:
> > On Thu, Jan 28, 2021 at 09:49:41PM -0500, Stefan Berger wrote:
> > >
> > > In my patch series I initially had registered the akciphers under the
> > > names
> > >
On Sun, 7 Feb 2021 at 03:47, liulongfang wrote:
>
> On 2021/2/5 19:44, Herbert Xu write:
> > On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote:
> >> If this configuration item is not turned on,
> >> the allocation of crypto_tfm will fail when
> >> the shash algorithm calculates the
On Sat, 6 Feb 2021 at 14:10, Guillaume Tucker
wrote:
>
> On 05/02/2021 12:05, Ard Biesheuvel wrote:
> > On Fri, 5 Feb 2021 at 09:21, Ard Biesheuvel wrote:
> >>
> >> On Thu, 4 Feb 2021 at 22:31, Guillaume Tucker
> >> wrote:
> >>>
> >>
: Robert Moore
Cc: Erik Kaneda
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Reported-by: Shawn Guo
Signed-off-by: Ard Biesheuvel
---
drivers/acpi/acpica/nsrepair2.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/nsrepair2.c b/dr
On Fri, 5 Feb 2021 at 09:21, Ard Biesheuvel wrote:
>
> On Thu, 4 Feb 2021 at 22:31, Guillaume Tucker
> wrote:
> >
> > On 04/02/2021 18:23, Nick Desaulniers wrote:
> > > On Thu, Feb 4, 2021 at 10:12 AM Nathan Chancellor
> > > wrote:
> > >>
>
t.
>
> See https://github.com/ClangBuiltLinux/linux/issues/256 for more info.
>
> Reported-by: Arnd Bergmann
> Link: http://lkml.kernel.org/r/20210107223424.4135538-1-a...@kernel.org
> Signed-off-by: Borislav Petkov
Acked-by: Ard Biesheuvel
> ---
> arch/x86/platform/efi/efi_
Linux wrote:
> >>> On Thu, Feb 4, 2021 at 8:02 AM Ard Biesheuvel wrote:
> >>>>
> >>>> On Thu, 4 Feb 2021 at 16:53, Guillaume Tucker
> >>>> wrote:
> >>>>>
> >>>>> On 04/02/2021 15:42, Ard Biesheuvel wrote:
On Thu, 4 Feb 2021 at 16:53, Guillaume Tucker
wrote:
>
> On 04/02/2021 15:42, Ard Biesheuvel wrote:
> > On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker
> > wrote:
> >>
> >> On 04/02/2021 10:33, Guillaume Tucker wrote:
> >>> On 04/02/2021 10:27, Ard B
On Thu, 4 Feb 2021 at 15:36, Russell King - ARM Linux admin
wrote:
>
> On Thu, Feb 04, 2021 at 03:25:20PM +0100, Ard Biesheuvel wrote:
> > Pushing contents of the cache hierarchy to main memory is *not* a
> > valid use of set/way ops, and so there is no point in pretending th
On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker
wrote:
>
> On 04/02/2021 10:33, Guillaume Tucker wrote:
> > On 04/02/2021 10:27, Ard Biesheuvel wrote:
> >> On Thu, 4 Feb 2021 at 11:06, Russell King - ARM Linux admin
> >> wrote:
> >>>
> >>> On
On Thu, 4 Feb 2021 at 15:09, Russell King - ARM Linux admin
wrote:
>
> On Thu, Feb 04, 2021 at 12:26:44PM +, Marc Zyngier wrote:
> > I agree. With set/way CMOs, there is no way to reach the PoC if
> > it beyond the system cache, leading to an unbootable kernel.
> > This is actually pretty
On Thu, 4 Feb 2021 at 12:45, Russell King - ARM Linux admin
wrote:
>
> On Thu, Feb 04, 2021 at 11:32:05AM +, Guillaume Tucker wrote:
> > Yes it does fix the issue:
> >
> > https://lava.collabora.co.uk/scheduler/job/3173819
> >
> > with Ard's fix applied to this test branch:
> >
> >
> >
On Thu, 4 Feb 2021 at 11:52, 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'
(cc Marc)
On Thu, 4 Feb 2021 at 11:48, Russell King - ARM Linux admin
wrote:
>
> On Thu, Feb 04, 2021 at 11:27:16AM +0100, Ard Biesheuvel wrote:
> > Hi Russell,
> >
> > If Guillaume is willing to do the experiment, and it fixes the issue,
> > it proves that rk3288
On Thu, 4 Feb 2021 at 11:06, Russell King - ARM Linux admin
wrote:
>
> On Thu, Feb 04, 2021 at 10:07:58AM +0100, Ard Biesheuvel wrote:
> > On Thu, 4 Feb 2021 at 09:43, Guillaume Tucker
> > wrote:
> > >
> > > Hi Ard,
> > >
> > > Plea
t; > URL:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > Branch: master
> > Target: rk3288-rock2-square
> > CPU arch: arm
> > Lab:lab-collabora
> > Compiler: clang-11
> > Config:
On Wed, 3 Feb 2021 at 19:51, Nathan Chancellor wrote:
>
> On Wed, Jan 20, 2021 at 10:33:43AM +0100, Ard Biesheuvel wrote:
> > On Mon, 18 Jan 2021 at 22:42, Arvind Sankar wrote:
> > >
> > > On Mon, Jan 18, 2021 at 09:24:09PM +0100, Borislav Petkov wrote:
>
On Sat, 9 Jan 2021 at 11:33, Lecopzer Chen wrote:
>
> Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Like how the MODULES_VADDR does now, just not to early populate
> the VMALLOC_START between VMALLOC_END.
>
MALLOC
>
I failed to realize that VMAP_STACK and KASAN are currently mutually
exclusive on arm64, and that this series actually fixes that, which is
a big improvement, so it would make sense to call that out.
This builds and runs fine for me on a VM running under KVM.
Tested-by: Ard Biesheuvel
On Sun, 31 Jan 2021 at 19:55, Catalin Marinas wrote:
>
> On Fri, Jan 29, 2021 at 02:09:05PM -0800, Linus Torvalds wrote:
> > On Fri, Jan 29, 2021 at 11:03 AM Catalin Marinas
> > wrote:
> > >
> > > arm64 fixes:
> > >
> > > - Fix the virt_addr_valid() returning true for < PAGE_OFFSET addresses.
>
On Thu, 28 Jan 2021 at 23:28, Arnd Bergmann wrote:
>
> On Thu, Jan 28, 2021 at 10:03 PM Ard Biesheuvel wrote:
> > On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers
> > wrote:
> > > @@ -468,15 +468,15 @@ void kprobe_thumb32_test_cases(void)
> > >
> > &g
On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers wrote:
>
> Clang's integrated assembler only accepts UAL syntax, rewrite the
> instructions that were changed by RVCTv2.1.
>
> The document "Assembly language changes after RVCTv2.1" was very
> helpful.
>
> This exposed a bug in Clang's integrated
On Thu, 28 Jan 2021 at 06:04, Herbert Xu wrote:
>
> On Fri, Jan 22, 2021 at 03:09:52PM +0800, Meng Yu wrote:
> > 1. Add ecc curves(P224, P384, P521) for ECDH;
>
> OK I think this is getting unwieldy.
>
> In light of the fact that we already have hardware that supports
> a specific subset of
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 3e1e00c00e2b9b5c9a2f47f1c67720a5d430e4d0
Gitweb:
https://git.kernel.org/tip/3e1e00c00e2b9b5c9a2f47f1c67720a5d430e4d0
Author:Ard Biesheuvel
AuthorDate:Tue, 19 Jan 2021 15:16:27 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: cdec91c034a2c99331b62a5f417bf7527fa6d490
Gitweb:
https://git.kernel.org/tip/cdec91c034a2c99331b62a5f417bf7527fa6d490
Author:Ard Biesheuvel
AuthorDate:Mon, 02 Nov 2020 10:04:39 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 3820749ddcee694abfd5ae6cabc18aaab11eab34
Gitweb:
https://git.kernel.org/tip/3820749ddcee694abfd5ae6cabc18aaab11eab34
Author:Ard Biesheuvel
AuthorDate:Mon, 02 Nov 2020 11:51:10 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 8ff059b8531f3b98e14f0461859fc7cdd95823e4
Gitweb:
https://git.kernel.org/tip/8ff059b8531f3b98e14f0461859fc7cdd95823e4
Author:Ard Biesheuvel
AuthorDate:Mon, 18 Jan 2021 13:38:42 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 2f196059864fb0fe8f60c14a2cb214055b283e08
Gitweb:
https://git.kernel.org/tip/2f196059864fb0fe8f60c14a2cb214055b283e08
Author:Ard Biesheuvel
AuthorDate:Mon, 02 Nov 2020 17:11:49 +01:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 514b1a8477d25a157f65bf52a443f8ffcc2eb54e
Gitweb:
https://git.kernel.org/tip/514b1a8477d25a157f65bf52a443f8ffcc2eb54e
Author:Ard Biesheuvel
AuthorDate:Tue, 19 Jan 2021 15:05:40 +01:00
On Mon, 25 Jan 2021 at 14:54, Marc Zyngier wrote:
>
> On 2021-01-25 12:54, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 11:53, Marc Zyngier wrote:
> >>
> >> Given that the early cpufeature infrastructure has borrowed quite
> >> a lot of code from the
On Mon, 25 Jan 2021 at 11:53, Marc Zyngier wrote:
>
> Given that the early cpufeature infrastructure has borrowed quite
> a lot of code from the kaslr implementation, let's reimplement
> the matching of the "nokaslr" option with it.
>
> Signed-off-by: Marc Zyngier
> Acked-by: Catalin Marinas
>
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
1 - 100 of 5027 matches
Mail list logo
