Re: [RFC PATCH v3 3/5] KVM: x86: Add notifications for Heki policy configuration and violation
On Tue, May 14, 2024, Mickaël Salaün wrote:
> On Fri, May 10, 2024 at 10:07:00AM +, Nicolas Saenz Julienne wrote:
> > Development happens
> > https://github.com/vianpl/{linux,qemu,kvm-unit-tests} and the vsm-next
> > branch, but I'd advice against looking into it until we add some order
> > to the rework. Regardless, feel free to get in touch.
>
> Thanks for the update.
>
> Could we schedule a PUCK meeting to synchronize and help each other?
> What about June 12?
June 12th works on my end.
Re: [PATCH 05/12] dmaengine: Add STM32 DMA3 support
On Tue, Apr 23, 2024 at 02:32:55PM +0200, Amelie Delaunay wrote: > STM32 DMA3 driver supports the 3 hardware configurations of the STM32 DMA3 > controller: > - LPDMA (Low Power): 4 channels, no FIFO > - GPDMA (General Purpose): 16 channels, FIFO from 8 to 32 bytes > - HPDMA (High Performance): 16 channels, FIFO from 8 to 256 bytes > Hardware configuration of the channels is retrieved from the hardware > configuration registers. > The client can specify its channel requirements through device tree. > STM32 DMA3 channels can be individually reserved either because they are > secure, or dedicated to another CPU. > Indeed, channels availability depends on Resource Isolation Framework > (RIF) configuration. RIF grants access to buses with Compartiment ID > (CIF) filtering, secure and privilege level. It also assigns DMA channels > to one or several processors. > DMA channels used by Linux should be CID-filtered and statically assigned > to CID1 or shared with other CPUs but using semaphore. In case CID > filtering is not configured, dma-channel-mask property can be used to > specify available DMA channels to the kernel, otherwise such channels > will be marked as reserved and can't be used by Linux. > > Signed-off-by: Amelie Delaunay > --- > drivers/dma/stm32/Kconfig | 10 + > drivers/dma/stm32/Makefile |1 + > drivers/dma/stm32/stm32-dma3.c | 1431 > 3 files changed, 1442 insertions(+) > create mode 100644 drivers/dma/stm32/stm32-dma3.c > > diff --git a/drivers/dma/stm32/Kconfig b/drivers/dma/stm32/Kconfig > index b72ae1a4502f..4d8d8063133b 100644 > --- a/drivers/dma/stm32/Kconfig > +++ b/drivers/dma/stm32/Kconfig > @@ -34,4 +34,14 @@ config STM32_MDMA > If you have a board based on STM32 SoC with such DMA controller > and want to use MDMA say Y here. > > +config STM32_DMA3 > + tristate "STMicroelectronics STM32 DMA3 support" > + select DMA_ENGINE > + select DMA_VIRTUAL_CHANNELS > + help > + Enable support for the on-chip DMA3 controller on STMicroelectronics > + STM32 platforms. > + If you have a board based on STM32 SoC with such DMA3 controller > + and want to use DMA3, say Y here. > + > endif > diff --git a/drivers/dma/stm32/Makefile b/drivers/dma/stm32/Makefile > index 663a3896a881..5082db4b4c1c 100644 > --- a/drivers/dma/stm32/Makefile > +++ b/drivers/dma/stm32/Makefile > @@ -2,3 +2,4 @@ > obj-$(CONFIG_STM32_DMA) += stm32-dma.o > obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o > obj-$(CONFIG_STM32_MDMA) += stm32-mdma.o > +obj-$(CONFIG_STM32_DMA3) += stm32-dma3.o > diff --git a/drivers/dma/stm32/stm32-dma3.c b/drivers/dma/stm32/stm32-dma3.c > new file mode 100644 > index ..b5493f497d06 > --- /dev/null > +++ b/drivers/dma/stm32/stm32-dma3.c > @@ -0,0 +1,1431 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * STM32 DMA3 controller driver > + * > + * Copyright (C) STMicroelectronics 2024 > + * Author(s): Amelie Delaunay > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "../virt-dma.h" > + > +#define STM32_DMA3_SECCFGR 0x00 > +#define STM32_DMA3_PRIVCFGR 0x04 > +#define STM32_DMA3_RCFGLOCKR 0x08 > +#define STM32_DMA3_MISR 0x0C > +#define STM32_DMA3_SMISR 0x10 > + > +#define STM32_DMA3_CLBAR(x) (0x50 + 0x80 * (x)) > +#define STM32_DMA3_CCIDCFGR(x) (0x54 + 0x80 * (x)) > +#define STM32_DMA3_CSEMCR(x) (0x58 + 0x80 * (x)) > +#define STM32_DMA3_CFCR(x) (0x5C + 0x80 * (x)) > +#define STM32_DMA3_CSR(x)(0x60 + 0x80 * (x)) > +#define STM32_DMA3_CCR(x)(0x64 + 0x80 * (x)) > +#define STM32_DMA3_CTR1(x) (0x90 + 0x80 * (x)) > +#define STM32_DMA3_CTR2(x) (0x94 + 0x80 * (x)) > +#define STM32_DMA3_CBR1(x) (0x98 + 0x80 * (x)) > +#define STM32_DMA3_CSAR(x) (0x9C + 0x80 * (x)) > +#define STM32_DMA3_CDAR(x) (0xA0 + 0x80 * (x)) > +#define STM32_DMA3_CLLR(x) (0xCC + 0x80 * (x)) > + > +#define STM32_DMA3_HWCFGR13 0xFC0 /* G_PER_CTRL(X) x=8..15 */ > +#define STM32_DMA3_HWCFGR12 0xFC4 /* G_PER_CTRL(X) x=0..7 */ > +#define STM32_DMA3_HWCFGR4 0xFE4 /* G_FIFO_SIZE(X) x=8..15 */ > +#define STM32_DMA3_HWCFGR3 0xFE8 /* G_FIFO_SIZE(X) x=0..7 */ > +#define STM32_DMA3_HWCFGR2 0xFEC /* G_MAX_REQ_ID */ > +#define STM32_DMA3_HWCFGR1 0xFF0 /* G_MASTER_PORTS, > G_NUM_CHANNELS, G_Mx_DATA_WIDTH */ > +#define STM32_DMA3_VERR 0xFF4 > + > +/* SECCFGR DMA secure configuration register */ > +#define SECCFGR_SEC(x) BIT(x) > + > +/* MISR DMA non-secure/secure masked interrupt status register */ > +#define MISR_MIS(x) BIT(x) > + > +/* CxLBAR DMA channel x linked_list base
Re: [PATCH 05/12] dmaengine: Add STM32 DMA3 support
On Mon, May 13, 2024 at 11:21:18AM +0200, Amelie Delaunay wrote: > Hi Frank, > > On 5/7/24 22:26, Frank Li wrote: > > On Tue, May 07, 2024 at 01:33:31PM +0200, Amelie Delaunay wrote: > > > Hi Vinod, > > > > > > Thanks for the review. > > > > > > On 5/4/24 14:40, Vinod Koul wrote: > > > > On 23-04-24, 14:32, Amelie Delaunay wrote: > > > > > STM32 DMA3 driver supports the 3 hardware configurations of the STM32 > > > > > DMA3 > > > > > controller: > > > > > - LPDMA (Low Power): 4 channels, no FIFO > > > > > - GPDMA (General Purpose): 16 channels, FIFO from 8 to 32 bytes > > > > > - HPDMA (High Performance): 16 channels, FIFO from 8 to 256 bytes > > > > > Hardware configuration of the channels is retrieved from the hardware > > > > > configuration registers. > > > > > The client can specify its channel requirements through device tree. > > > > > STM32 DMA3 channels can be individually reserved either because they > > > > > are > > > > > secure, or dedicated to another CPU. > > > > > Indeed, channels availability depends on Resource Isolation Framework > > > > > (RIF) configuration. RIF grants access to buses with Compartiment ID > > > > > > > > Compartiment? typo...? > > > > > > > > > > Sorry, indeed, Compartment instead. > > > > > > > > (CIF) filtering, secure and privilege level. It also assigns DMA > > > > > channels > > > > > to one or several processors. > > > > > DMA channels used by Linux should be CID-filtered and statically > > > > > assigned > > > > > to CID1 or shared with other CPUs but using semaphore. In case CID > > > > > filtering is not configured, dma-channel-mask property can be used to > > > > > specify available DMA channels to the kernel, otherwise such channels > > > > > will be marked as reserved and can't be used by Linux. > > > > > > > > > > Signed-off-by: Amelie Delaunay > > > > > --- > > > > >drivers/dma/stm32/Kconfig | 10 + > > > > >drivers/dma/stm32/Makefile |1 + > > > > >drivers/dma/stm32/stm32-dma3.c | 1431 > > > > > > > > > >3 files changed, 1442 insertions(+) > > > > >create mode 100644 drivers/dma/stm32/stm32-dma3.c > > > > > > > > > > diff --git a/drivers/dma/stm32/Kconfig b/drivers/dma/stm32/Kconfig > > > > > index b72ae1a4502f..4d8d8063133b 100644 > > > > > --- a/drivers/dma/stm32/Kconfig > > > > > +++ b/drivers/dma/stm32/Kconfig > > > > > @@ -34,4 +34,14 @@ config STM32_MDMA > > > > > If you have a board based on STM32 SoC with such DMA > > > > > controller > > > > > and want to use MDMA say Y here. > > > > > +config STM32_DMA3 > > > > > + tristate "STMicroelectronics STM32 DMA3 support" > > > > > + select DMA_ENGINE > > > > > + select DMA_VIRTUAL_CHANNELS > > > > > + help > > > > > + Enable support for the on-chip DMA3 controller on > > > > > STMicroelectronics > > > > > + STM32 platforms. > > > > > + If you have a board based on STM32 SoC with such DMA3 > > > > > controller > > > > > + and want to use DMA3, say Y here. > > > > > + > > > > >endif > > > > > diff --git a/drivers/dma/stm32/Makefile b/drivers/dma/stm32/Makefile > > > > > index 663a3896a881..5082db4b4c1c 100644 > > > > > --- a/drivers/dma/stm32/Makefile > > > > > +++ b/drivers/dma/stm32/Makefile > > > > > @@ -2,3 +2,4 @@ > > > > >obj-$(CONFIG_STM32_DMA) += stm32-dma.o > > > > >obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o > > > > >obj-$(CONFIG_STM32_MDMA) += stm32-mdma.o > > > > > +obj-$(CONFIG_STM32_DMA3) += stm32-dma3.o > > > > > > > > are there any similarities in mdma/dma and dma3..? > > > > can anything be reused...? > > > > > > > > > > DMA/MDMA were originally intended for STM32 MCUs and have been used in > > > STM32MP1 MPUs. > > > New MPUs (STM32MP2, ...) and STM32 MCUs (STM32H5, STM32N6, ...) use DMA3. > > > Unlike DMA/MDMA, DMA3 can be declined in multiple configurations, LPDMA, > > > GPDMA, HPDMA, and among these global configurations, there are possible > > > sub-configurations (e.g. channel fifo size). stm32-dma3 uses the hardware > > > configuration registers to discover the controller/channels capabilities. > > > Reuse stm32-dma or stm32-mdma would lead to complicating the driver and > > > making future stm32-dma3 evolutions for next STM32 MPUs intricate and very > > > difficult. > > > > I think your reason still not enough to create new driver instead try to > > reuse old one. > > > > Does register layout or dma descriptor is totally difference? > > > > If dma descriptor format is the same, at least you can reuse prepare DMA > > descriptor part. > > > > Choose channel is independt part of DMA channel. You can create sperate > > one for difference DMA engine. > > > > Frank > > > > stm32-dma is not considered for reuse : register layout is completely > different and this DMA controller doesn't rely on descriptors mechanism. > > stm32-mdma is based on descriptors mechanism but even there, there are > significant differences in
Re: [RFC] Mitigating unexpected arithmetic overflow
Hi Peter,
On Wed, May 15, 2024 at 12:36 AM Peter Zijlstra wrote:
>
> On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> > For example, the most common case of overflow we've ever had has very
> > much been array indexing. Now, sometimes that has actually been actual
> > undefined behavior, because it's been overflow in signed variables,
> > and those are "easy" to find in the sense that you just say "no, can't
> > do that". UBSAN finds them, and that's good.
>
> We build with -fno-strict-overflow, which implies -fwrapv, which removes
> the UB from signed overflow by mandating 2s complement.
FWIW,
Clang-19 allows -fwrapv and -fsanitize=signed-integer-overflow to work
together [1]
And the sanitizer was re-introduced with Commit 557f8c582a9ba8ab
("ubsan: Reintroduce signed overflow sanitizer").
>
> With the exception of an UBSAN bug prior to GCC-8, UBSAN will not, and
> should not, warn about signed overflow when using either of these flags.
[1]: https://clang.llvm.org/docs/ReleaseNotes.html#sanitizers
Thanks
Justin
Re: [PATCH v2] fs: remove accidental overflow during wraparound check
On Mon, 13 May 2024 17:50:30 +, Justin Stitt wrote: > Running syzkaller with the newly enabled signed integer overflow > sanitizer produces this report: > > [ 195.401651] [ cut here ] > [ 195.404808] UBSAN: signed-integer-overflow in ../fs/open.c:321:15 > [ 195.408739] 9223372036854775807 + 562984447377399 cannot be represented in > type 'loff_t' (aka 'long long') > [ 195.414683] CPU: 1 PID: 703 Comm: syz-executor.0 Not tainted > 6.8.0-rc2-00039-g14de58dbe653-dirty #11 > [ 195.420138] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.16.3-debian-1.16.3-2 04/01/2014 > [ 195.425804] Call Trace: > [ 195.427360] > [ 195.428791] dump_stack_lvl+0x93/0xd0 > [ 195.431150] handle_overflow+0x171/0x1b0 > [ 195.433640] vfs_fallocate+0x459/0x4f0 > ... > [ 195.490053] [ cut here ] > [ 195.493146] UBSAN: signed-integer-overflow in ../fs/open.c:321:61 > [ 195.497030] 9223372036854775807 + 562984447377399 cannot be represented in > type 'loff_t' (aka 'long long) > [ 195.502940] CPU: 1 PID: 703 Comm: syz-executor.0 Not tainted > 6.8.0-rc2-00039-g14de58dbe653-dirty #11 > [ 195.508395] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.16.3-debian-1.16.3-2 04/01/2014 > [ 195.514075] Call Trace: > [ 195.515636] > [ 195.517000] dump_stack_lvl+0x93/0xd0 > [ 195.519255] handle_overflow+0x171/0x1b0 > [ 195.521677] vfs_fallocate+0x4cb/0x4f0 > [ 195.524033] __x64_sys_fallocate+0xb2/0xf0 > > [...] Applied to the vfs.misc branch of the vfs/vfs.git tree. Patches in the vfs.misc branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.misc [1/1] fs: remove accidental overflow during wraparound check https://git.kernel.org/vfs/vfs/c/c01a23b6fbd1
Re: [linux-next:master] [mm/slab] 7bd230a266: WARNING:at_mm/util.c:#kvmalloc_node_noprof
44 24 60 c7 04 24 > 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 > <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 > All code > >0: 00 48 89add%cl,-0x77(%rax) >3: 44 24 18rex.R and $0x18,%al >6: 31 c0 xor%eax,%eax >8: 48 8d 44 24 60 lea0x60(%rsp),%rax >d: c7 04 24 10 00 00 00movl $0x10,(%rsp) > 14: 48 89 44 24 08 mov%rax,0x8(%rsp) > 19: 48 8d 44 24 20 lea0x20(%rsp),%rax > 1e: 48 89 44 24 10 mov%rax,0x10(%rsp) > 23: b8 10 00 00 00 mov$0x10,%eax > 28: 0f 05 syscall > 2a:* 89 c2 mov%eax,%edx<-- trapping > instruction > 2c: 3d 00 f0 ff ff cmp$0xf000,%eax > 31: 77 1c ja 0x4f > 33: 48 8b 44 24 18 mov0x18(%rsp),%rax > 38: 64 fs > 39: 48 rex.W > 3a: 2b .byte 0x2b > 3b: 04 25 add$0x25,%al > 3d: 28 00 sub%al,(%rax) > ... > > Code starting with the faulting instruction > === >0: 89 c2 mov%eax,%edx >2: 3d 00 f0 ff ff cmp$0xf000,%eax >7: 77 1c ja 0x25 >9: 48 8b 44 24 18 mov0x18(%rsp),%rax >e: 64 fs >f: 48 rex.W > 10: 2b .byte 0x2b > 11: 04 25 add$0x25,%al > 13: 28 00 sub%al,(%rax) > > > The kernel config and materials to reproduce are available at: > https://download.01.org/0day-ci/archive/20240515/202405151008.6ddd1aaf-oliver.s...@intel.com > Looks like the calculation inside eb_copy_relocations() here: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c#L1682 results in (size > INT_MAX) warning being triggered inside kvmalloc_array(). Seems like the relocation count is too high for some reason. I doubt it's our patch causing this but I'll try to reproduce once I'm back from the conference. Thanks, Suren. > > > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki >
Re: [PATCH v2] scsi: sr: fix unintentional arithmetic wraparound
Justin, > Running syzkaller with the newly reintroduced signed integer overflow > sanitizer produces this report: > > [ 65.194362] [ cut here ] > [ 65.197752] UBSAN: signed-integer-overflow in > ../drivers/scsi/sr_ioctl.c:436:9 > [ 65.203607] -2147483648 * 177 cannot be represented in type 'int' > [ 65.207911] CPU: 2 PID: 10416 Comm: syz-executor.1 Not tainted > 6.8.0-rc2-00035-gb3ef86b5a957 #1 > [ 65.213585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.16.3-debian-1.16.3-2 04/01/2014 > [ 65.219923] Call Trace: > [ 65.221556] > [ 65.223029] dump_stack_lvl+0x93/0xd0 > [ 65.225573] handle_overflow+0x171/0x1b0 > [ 65.228219] sr_select_speed+0xeb/0xf0 > [ 65.230786] ? __pm_runtime_resume+0xe6/0x130 > [ 65.233606] sr_block_ioctl+0x15d/0x1d0 > ... > Applied to 6.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [RFC] Mitigating unexpected arithmetic overflow
On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote: > Now, another thing to do might be to treat assignments (and again, > implicit casts) to 'size_t' specially. In most compilers (certainly in > gcc), "size_t" is a special type. > > Now, in the kernel, we don't actually use __builtin_size_t (the kernel > started out with a very standalone type system, and I think it > actually predated gcc's __builtin_size_t or maybe I just wasn't aware > of it). But we certainly _could_ - or we could at least use some > special marked type for our own 'size_t'. So I've been arguing that since unsigned (and signed too when -fwrapv) have well defined wrapping semantics and people rely on them, you cannot go around and assume that wrapping is bad. You're arguing much the same. I've proposed that Kees instead adds a type qualifier to explicitly mark no-overflow / no-wrap types. That way __buildin_size_t is no longer magical, and it along with all the other __builtin_*_overflow() muck can go away. You'd end up with things like: typedef nowrap unsigned int __kernel_size_t; or perhaps: nowrap int idx = j * sizeof(foo); etc. To indeed annotate these baby steps, without making code needlessly ugly with all these __builtin_*_overflow() wrappers.
Re: [RFC] Mitigating unexpected arithmetic overflow
On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote: > For example, the most common case of overflow we've ever had has very > much been array indexing. Now, sometimes that has actually been actual > undefined behavior, because it's been overflow in signed variables, > and those are "easy" to find in the sense that you just say "no, can't > do that". UBSAN finds them, and that's good. We build with -fno-strict-overflow, which implies -fwrapv, which removes the UB from signed overflow by mandating 2s complement. With the exception of an UBSAN bug prior to GCC-8, UBSAN will not, and should not, warn about signed overflow when using either of these flags.
Re: [PATCH] ubsan: Restore dependency on ARCH_HAS_UBSAN
On Wed, 15 May 2024 at 01:38, Kees Cook wrote:
>
> While removing CONFIG_UBSAN_SANITIZE_ALL, ARCH_HAS_UBSAN wasn't correctly
> depended on. Restore this, as we do not want to attempt UBSAN builds
> unless it's actually been tested on a given architecture.
>
> Reported-by: Masahiro Yamada
> Closes:
> https://lore.kernel.org/all/20240514095427.541201-1-masahi...@kernel.org
> Fixes: 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL")
> Signed-off-by: Kees Cook
Reviewed-by: Marco Elver
> ---
> Cc: Marco Elver
> Cc: Andrey Konovalov
> Cc: Andrey Ryabinin
> Cc: kasan-...@googlegroups.com
> Cc: linux-hardening@vger.kernel.org
> ---
> lib/Kconfig.ubsan | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index e81e1ac4a919..bdda600f8dfb 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -4,6 +4,7 @@ config ARCH_HAS_UBSAN
>
> menuconfig UBSAN
> bool "Undefined behaviour sanity checker"
> + depends on ARCH_HAS_UBSAN
> help
> This option enables the Undefined Behaviour sanity checker.
> Compile-time instrumentation is used to detect various undefined
> --
> 2.34.1
>
