Remove the hidden assumption that options are allocated at the end of
the struct, and teach the compiler about them using a flexible array.
First patch is converting hard-coded 'info + 1' to use ip_tunnel_info()
helper.
Second patch adds the 'options' flexible array and changes the helper to
use i
Remove the hidden assumption that options are allocated at the end of
the struct, and teach the compiler about them using a flexible array.
With this, we can revert the unsafe_memcpy() call we have in
tun_dst_unclone() [1], and resolve the false field-spanning write
warning caused by the memcpy()
Tunnel options should not be accessed directly, use the ip_tunnel_info()
accessor instead.
Signed-off-by: Gal Pressman
---
include/net/ip_tunnels.h | 2 +-
net/sched/act_tunnel_key.c | 8 +---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/net/ip_tunnels.h b/include
On Mon, Feb 17, 2025 at 06:38:27PM +, David Laight wrote:
> I may not have retpolines enabled, a typical call site is (from vmlinux.o):
Make sure CONFIG_FINEIBT=y, otherwise there is no point in talking about
this. This requires KERNEL_IBT=y RETPOLINE=y CALL_PADDING=y CFI_CLANG=y.
Then look
On Mon, 17 Feb 2025 14:13:21 +0100
Peter Zijlstra wrote:
> On Mon, Feb 17, 2025 at 01:06:29PM +, David Laight wrote:
> > On Sat, 15 Feb 2025 22:07:29 +0100
> > Peter Zijlstra wrote:
> >
> > > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > > > On Thu, Feb 13, 2025 at
On 2/17/25 13:19, Johannes Berg wrote:
> On Mon, 2025-02-17 at 12:44 +0200, Eugen Hristev wrote:
>>
>> At this moment going through devcoredump is not something that impacts
>> the idea of the implementation.
>
> Yeah. I don't think it _should_ go through it at all.
>
>> The whole reason of go
Hi Thorsten,
On 2/13/25 3:10 PM, Thorsten Blum wrote:
strncpy() is deprecated for NUL-terminated destination buffers. Use
strscpy() instead and remove the manual NUL-termination.
Compile-tested only.
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-b
On Sat, 15 Feb 2025 22:07:29 +0100
Peter Zijlstra wrote:
> On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> >
> > > Right, the "if they can control a function pointer" is the part I'm
> > > focusing on. This attack
On Mon, Feb 17, 2025 at 01:06:29PM +, David Laight wrote:
> On Sat, 15 Feb 2025 22:07:29 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> > >
> > > > Right, the "if they ca
On Mon, 2025-02-17 at 13:39 +0200, Eugen Hristev wrote:
>
> On 2/17/25 13:19, Johannes Berg wrote:
> > On Mon, 2025-02-17 at 12:44 +0200, Eugen Hristev wrote:
> > >
> > > At this moment going through devcoredump is not something that impacts
> > > the idea of the implementation.
> >
> > Yeah. I
On Mon, 2025-02-17 at 12:44 +0200, Eugen Hristev wrote:
>
> At this moment going through devcoredump is not something that impacts
> the idea of the implementation.
Yeah. I don't think it _should_ go through it at all.
> The whole reason of going through it (because things work without it as
> w
On 2/17/25 12:23, Johannes Berg wrote:
> On Mon, 2025-02-17 at 12:16 +0200, Eugen Hristev wrote:
>
>> This series comes as an RFC proposed solution to enhance pstore and
>> devcoredump with the following functionality:
>
> ...
>
>> This patch series attempts to solve this by reusing existing
On Sun, Feb 16, 2025 at 03:51:27PM -0800, Kees Cook wrote:
> On Sat, Feb 15, 2025 at 10:07:29PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> > >
> > > > Right, the "if they can co
On Mon, 2025-02-17 at 12:16 +0200, Eugen Hristev wrote:
> This series comes as an RFC proposed solution to enhance pstore and
> devcoredump with the following functionality:
...
> This patch series attempts to solve this by reusing existing
> infrastructure in pstore and devcoredump, and provide
Directly mapped zones have a different semantic from usual pstore zones.
Such zones use a pointer to data in their buffer struct, instead of
keeping the buffer locally.
The data pointer and size is then passed to the backend for further use.
Having a different semantics, backends supporting only th
Proof of concept on how devcd register core area works.
Signed-off-by: Eugen Hristev
---
drivers/crypto/qcom-rng.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c
index 0685ba122e8a..a1509609f50c 100644
--- a/drivers/crypto/q
log_buf_addr_get() and log_buf_len_get() can be reused in another module,
export the symbols.
Signed-off-by: Eugen Hristev
---
kernel/printk/printk.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 07668433644b..022947f9b61d 100644
---
Add support for pstore smem backend in the qcom smem driver.
This backend resorts to minidump regions behind the scenes.
Co-developed-by: Mukesh Ojha
Signed-off-by: Eugen Hristev
---
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 6 +-
drivers/soc/qcom/smem_md.c
If dmapped zones are available, register the log buffer into one zone.
Signed-off-by: Eugen Hristev
---
fs/pstore/platform.c | 16
1 file changed, 16 insertions(+)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 32448d9dd316..9a5c1d6d5031 100644
--- a/fs/pstore/p
Add API for registering device core area for saving into pstore.
Signed-off-by: Eugen Hristev
---
drivers/base/devcoredump.c | 13 +
include/linux/devcoredump.h | 3 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c
index 2a
Add shared memory type of pstore.
Signed-off-by: Eugen Hristev
---
fs/pstore/Kconfig | 13
fs/pstore/Makefile | 3 +
fs/pstore/smem.c| 115
include/linux/pstore_smem.h | 9 +++
4 files changed, 140 insertions(+)
creat
Struct pstore_device_info is used in pstore/zone, and it's
not really connected to anything related to pstore/blk.
To further improve on the pstore zone and allow other types of
drivers to connect, it is logical to have this struct into
pstore_zone.h file.
Signed-off-by: Eugen Hristev
---
includ
Implement core area registration mechanism.
Implement directly mapped zone corespoding to core areas.
Signed-off-by: Eugen Hristev
---
fs/pstore/platform.c | 67
fs/pstore/zone.c | 77 ++
include/linux/pstore.h
Enable smem pstore backend that registers regions into the minidump
table.
Signed-off-by: Eugen Hristev
---
drivers/soc/qcom/smem.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 592819701809..f4d2646fcc0b 100644
--- a/driv
Hello,
This series comes as an RFC proposed solution to enhance pstore and
devcoredump with the following functionality:
It is interesting to mark specific memory regions in the kernel
as core areas, such that in the even of a cataclysmic event like
panic, deadlock, hardware fault, those areas can
On 2/13/25 23:13, Thorsten Blum wrote:
> Add the __counted_by compiler attribute to the flexible array member
> attrs to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and
> CONFIG_FORTIFY_SOURCE.
>
> Increment num before adding a new param_attribute to the attrs array and
> adjust the arr
From: Lukas Bulwahn
Commit db6fe4d61ece ("lib: Move KUnit tests into tests/ subdirectory") adds
a file entry to the non-existing file scripts/test_fortify.sh. Probably,
this entry intends to refer to ./lib/test_fortify/test_fortify.sh, though.
As that file is already covered by the entry lib/test
27 matches
Mail list logo