From: Joel Granados <j.granados@samsung.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
<linux-fsdevel@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-s390@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <linux-mm@kvack.org>,
<linux-security-module@vger.kernel.org>, <bpf@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, <linux-xfs@vger.kernel.org>,
<linux-trace-kernel@vger.kernel.org>,
<linux-perf-users@vger.kernel.org>,
<netfilter-devel@vger.kernel.org>, <coreteam@netfilter.org>,
<kexec@lists.infradead.org>, <linux-hardening@vger.kernel.org>,
<bridge@lists.linux.dev>, <lvs-devel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, <rds-devel@oss.oracle.com>,
<linux-sctp@vger.kernel.org>, <linux-nfs@vger.kernel.org>,
<apparmor@lists.ubuntu.com>
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Wed, 8 May 2024 13:40:38 +0200 [thread overview]
Message-ID: <20240508114038.vnx2hchpxeimuqz2@joelS2.panther.com> (raw)
In-Reply-To: <4cda5d2d-dd92-44ef-9e7b-7b780ec795ab@t-8ch.de>
[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]
On Fri, May 03, 2024 at 04:09:40PM +0200, Thomas Weißschuh wrote:
> Hey Joel,
>
...
> > # Motivation
> > As I read it, the motivation for these constification efforts are:
> > 1. It provides increased safety: Having things in .rodata section reduces the
> > attack surface. This is especially relevant for structures that have function
> > pointers (like ctl_table); having these in .rodata means that these pointers
> > always point to the "intended" function and cannot be changed.
> > 2. Compiler optimizations: This was just a comment in the patchsets that I have
> > mentioned ([3,4,5]). Do you know what optimizations specifically? Does it
> > have to do with enhancing locality for the data in .rodata? Do you have other
> > specific optimizations in mind?
>
> I don't know about anything that would make it faster.
> It's more about safety and transmission of intent to API users,
> especially callback implementers.
Noted.
...
> > # Show the move
> > I created [8] because there is no easy way to validate which objects made it
> > into .rodata. I ran [8] for your Dec 2nd patcheset [7] and there are less in
> > .rodata than I expected (the results are in [9]) Why is that? Is it something
> > that has not been posted to the lists yet?
>
> Constifying the APIs only *allows* the actual table to be constified
> themselves.
> Then each table definition will have to be touched and "const" added.
That is what I thought. thx for clarifying.
>
> See patches 17 and 18 in [7] for two examples.
>
> Some tables in net/ are already "const" as the static definitions are
> never registered themselves but only their copies are.
>
...
best
--
Joel Granados
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Joel Granados <j.granados@samsung.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
<linux-fsdevel@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-s390@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <linux-mm@kvack.org>,
<linux-security-module@vger.kernel.org>, <bpf@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, <linux-xfs@vger.kernel.org>,
<linux-trace-kernel@vger.kernel.org>,
<linux-perf-users@vger.kernel.org>,
<netfilter-devel@vger.kernel.org>, <coreteam@netfilter.org>,
<kexec@lists.infradead.org>, <linux-hardening@vger.kernel.org>,
<bridge@lists.linux.dev>, <lvs-devel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, <rds-devel@oss.oracle.com>,
<linux-sctp@vger.kernel.org>, <linux-nfs@vger.kernel.org>,
<apparmor@lists.ubuntu.com>
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Wed, 8 May 2024 13:40:38 +0200 [thread overview]
Message-ID: <20240508114038.vnx2hchpxeimuqz2@joelS2.panther.com> (raw)
In-Reply-To: <4cda5d2d-dd92-44ef-9e7b-7b780ec795ab@t-8ch.de>
[-- Attachment #1.1: Type: text/plain, Size: 1736 bytes --]
On Fri, May 03, 2024 at 04:09:40PM +0200, Thomas Weißschuh wrote:
> Hey Joel,
>
...
> > # Motivation
> > As I read it, the motivation for these constification efforts are:
> > 1. It provides increased safety: Having things in .rodata section reduces the
> > attack surface. This is especially relevant for structures that have function
> > pointers (like ctl_table); having these in .rodata means that these pointers
> > always point to the "intended" function and cannot be changed.
> > 2. Compiler optimizations: This was just a comment in the patchsets that I have
> > mentioned ([3,4,5]). Do you know what optimizations specifically? Does it
> > have to do with enhancing locality for the data in .rodata? Do you have other
> > specific optimizations in mind?
>
> I don't know about anything that would make it faster.
> It's more about safety and transmission of intent to API users,
> especially callback implementers.
Noted.
...
> > # Show the move
> > I created [8] because there is no easy way to validate which objects made it
> > into .rodata. I ran [8] for your Dec 2nd patcheset [7] and there are less in
> > .rodata than I expected (the results are in [9]) Why is that? Is it something
> > that has not been posted to the lists yet?
>
> Constifying the APIs only *allows* the actual table to be constified
> themselves.
> Then each table definition will have to be touched and "const" added.
That is what I thought. thx for clarifying.
>
> See patches 17 and 18 in [7] for two examples.
>
> Some tables in net/ are already "const" as the static definitions are
> never registered themselves but only their copies are.
>
...
best
--
Joel Granados
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Joel Granados <j.granados@samsung.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
<linux-fsdevel@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-s390@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <linux-mm@kvack.org>,
<linux-security-module@vger.kernel.org>, <bpf@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, <linux-xfs@vger.kernel.org>,
<linux-trace-kernel@vger.kernel.org>,
<linux-perf-users@vger.kernel.org>,
<netfilter-devel@vger.kernel.org>, <coreteam@netfilter.org>,
<kexec@lists.infradead.org>, <linux-hardening@vger.kernel.org>,
<bridge@lists.linux.dev>, <lvs-devel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, <rds-devel@oss.oracle.com>,
<linux-sctp@vger.kernel.org>, <linux-nfs@vger.kernel.org>,
<apparmor@lists.ubuntu.com>
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Wed, 8 May 2024 13:40:38 +0200 [thread overview]
Message-ID: <20240508114038.vnx2hchpxeimuqz2@joelS2.panther.com> (raw)
In-Reply-To: <4cda5d2d-dd92-44ef-9e7b-7b780ec795ab@t-8ch.de>
[-- Attachment #1.1: Type: text/plain, Size: 1736 bytes --]
On Fri, May 03, 2024 at 04:09:40PM +0200, Thomas Weißschuh wrote:
> Hey Joel,
>
...
> > # Motivation
> > As I read it, the motivation for these constification efforts are:
> > 1. It provides increased safety: Having things in .rodata section reduces the
> > attack surface. This is especially relevant for structures that have function
> > pointers (like ctl_table); having these in .rodata means that these pointers
> > always point to the "intended" function and cannot be changed.
> > 2. Compiler optimizations: This was just a comment in the patchsets that I have
> > mentioned ([3,4,5]). Do you know what optimizations specifically? Does it
> > have to do with enhancing locality for the data in .rodata? Do you have other
> > specific optimizations in mind?
>
> I don't know about anything that would make it faster.
> It's more about safety and transmission of intent to API users,
> especially callback implementers.
Noted.
...
> > # Show the move
> > I created [8] because there is no easy way to validate which objects made it
> > into .rodata. I ran [8] for your Dec 2nd patcheset [7] and there are less in
> > .rodata than I expected (the results are in [9]) Why is that? Is it something
> > that has not been posted to the lists yet?
>
> Constifying the APIs only *allows* the actual table to be constified
> themselves.
> Then each table definition will have to be touched and "const" added.
That is what I thought. thx for clarifying.
>
> See patches 17 and 18 in [7] for two examples.
>
> Some tables in net/ are already "const" as the static definitions are
> never registered themselves but only their copies are.
>
...
best
--
Joel Granados
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Joel Granados <j.granados@samsung.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
<linux-fsdevel@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-s390@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <linux-mm@kvack.org>,
<linux-security-module@vger.kernel.org>, <bpf@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, <linux-xfs@vger.kernel.org>,
<linux-trace-kernel@vger.kernel.org>,
<linux-perf-users@vger.kernel.org>,
<netfilter-devel@vger.kernel.org>, <coreteam@netfilter.org>,
<kexec@lists.infradead.org>, <linux-hardening@vger.kernel.org>,
<bridge@lists.linux.dev>, <lvs-devel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, <rds-devel@oss.oracle.com>,
<linux-sctp@vger.kernel.org>, <linux-nfs@vger.kernel.org>,
<apparmor@lists.ubuntu.com>
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Wed, 8 May 2024 13:40:38 +0200 [thread overview]
Message-ID: <20240508114038.vnx2hchpxeimuqz2@joelS2.panther.com> (raw)
In-Reply-To: <4cda5d2d-dd92-44ef-9e7b-7b780ec795ab@t-8ch.de>
[-- Attachment #1.1: Type: text/plain, Size: 1736 bytes --]
On Fri, May 03, 2024 at 04:09:40PM +0200, Thomas Weißschuh wrote:
> Hey Joel,
>
...
> > # Motivation
> > As I read it, the motivation for these constification efforts are:
> > 1. It provides increased safety: Having things in .rodata section reduces the
> > attack surface. This is especially relevant for structures that have function
> > pointers (like ctl_table); having these in .rodata means that these pointers
> > always point to the "intended" function and cannot be changed.
> > 2. Compiler optimizations: This was just a comment in the patchsets that I have
> > mentioned ([3,4,5]). Do you know what optimizations specifically? Does it
> > have to do with enhancing locality for the data in .rodata? Do you have other
> > specific optimizations in mind?
>
> I don't know about anything that would make it faster.
> It's more about safety and transmission of intent to API users,
> especially callback implementers.
Noted.
...
> > # Show the move
> > I created [8] because there is no easy way to validate which objects made it
> > into .rodata. I ran [8] for your Dec 2nd patcheset [7] and there are less in
> > .rodata than I expected (the results are in [9]) Why is that? Is it something
> > that has not been posted to the lists yet?
>
> Constifying the APIs only *allows* the actual table to be constified
> themselves.
> Then each table definition will have to be touched and "const" added.
That is what I thought. thx for clarifying.
>
> See patches 17 and 18 in [7] for two examples.
>
> Some tables in net/ are already "const" as the static definitions are
> never registered themselves but only their copies are.
>
...
best
--
Joel Granados
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Joel Granados <j.granados@samsung.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Dave Chinner <david@fromorbit.com>,
linux-mm@kvack.org, Eric Dumazet <edumazet@google.com>,
linux-hardening@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, rds-devel@oss.oracle.com,
linux-rdma@vger.kernel.org, Luis Chamberlain <mcgrof@kernel.org>,
linux-sctp@vger.kernel.org, lvs-devel@vger.kernel.org,
coreteam@netfilter.org, linux-trace-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>,
bridge@lists.linux.dev, apparmor@lists.ubuntu.com,
linux-xfs@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
linux-security-module@vger.kernel.org,
netfilter-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
bpf@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Wed, 8 May 2024 13:40:38 +0200 [thread overview]
Message-ID: <20240508114038.vnx2hchpxeimuqz2@joelS2.panther.com> (raw)
In-Reply-To: <4cda5d2d-dd92-44ef-9e7b-7b780ec795ab@t-8ch.de>
[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]
On Fri, May 03, 2024 at 04:09:40PM +0200, Thomas Weißschuh wrote:
> Hey Joel,
>
...
> > # Motivation
> > As I read it, the motivation for these constification efforts are:
> > 1. It provides increased safety: Having things in .rodata section reduces the
> > attack surface. This is especially relevant for structures that have function
> > pointers (like ctl_table); having these in .rodata means that these pointers
> > always point to the "intended" function and cannot be changed.
> > 2. Compiler optimizations: This was just a comment in the patchsets that I have
> > mentioned ([3,4,5]). Do you know what optimizations specifically? Does it
> > have to do with enhancing locality for the data in .rodata? Do you have other
> > specific optimizations in mind?
>
> I don't know about anything that would make it faster.
> It's more about safety and transmission of intent to API users,
> especially callback implementers.
Noted.
...
> > # Show the move
> > I created [8] because there is no easy way to validate which objects made it
> > into .rodata. I ran [8] for your Dec 2nd patcheset [7] and there are less in
> > .rodata than I expected (the results are in [9]) Why is that? Is it something
> > that has not been posted to the lists yet?
>
> Constifying the APIs only *allows* the actual table to be constified
> themselves.
> Then each table definition will have to be touched and "const" added.
That is what I thought. thx for clarifying.
>
> See patches 17 and 18 in [7] for two examples.
>
> Some tables in net/ are already "const" as the static definitions are
> never registered themselves but only their copies are.
>
...
best
--
Joel Granados
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2024-05-08 11:40 UTC|newest]
Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240423075608eucas1p265e7c90f3efd6995cb240b3d2688b803@eucas1p2.samsung.com>
2024-04-23 7:54 ` [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 01/11] stackleak: don't modify ctl_table argument Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 02/11] cgroup: bpf: constify ctl_table arguments and fields Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 03/11] hugetlb: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 04/11] utsname: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 05/11] neighbour: " Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 06/11] ipv4/sysctl: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 07/11] ipv6/addrconf: " Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 08/11] ipv6/ndisc: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 09/11] ipvs: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 10/11] sysctl: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 11/11] sysctl: treewide: constify the ctl_table argument of handlers Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-29 9:47 ` Heiko Carstens
2024-04-29 9:47 ` Heiko Carstens
2024-04-29 9:47 ` Heiko Carstens
2024-04-29 9:47 ` Heiko Carstens
2024-04-29 9:47 ` Heiko Carstens
2024-04-23 18:31 ` [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers Luis Chamberlain
2024-04-23 18:31 ` Luis Chamberlain
2024-04-23 18:31 ` Luis Chamberlain
2024-04-23 18:31 ` Luis Chamberlain
2024-04-23 18:31 ` Luis Chamberlain
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-25 11:04 ` Joel Granados
2024-04-25 11:04 ` Joel Granados
2024-04-25 11:04 ` Joel Granados
2024-04-25 11:04 ` Joel Granados
2024-04-25 11:04 ` Joel Granados
2024-04-25 20:34 ` Thomas Weißschuh
2024-04-25 20:34 ` Thomas Weißschuh
2024-04-25 20:34 ` Thomas Weißschuh
2024-04-25 20:34 ` Thomas Weißschuh
2024-04-25 20:34 ` Thomas Weißschuh
2024-05-08 11:37 ` Joel Granados
2024-05-08 11:37 ` Joel Granados
2024-05-08 11:37 ` Joel Granados
2024-05-08 11:37 ` Joel Granados
2024-05-08 11:37 ` Joel Granados
2024-05-08 17:11 ` Kees Cook
2024-05-08 17:11 ` Kees Cook
2024-05-08 17:11 ` Kees Cook
2024-05-08 17:11 ` Kees Cook
2024-05-08 17:11 ` Kees Cook
2024-05-09 1:00 ` Jakub Kicinski
2024-05-09 1:00 ` Jakub Kicinski
2024-05-09 1:00 ` Jakub Kicinski
2024-05-09 1:00 ` Jakub Kicinski
2024-05-09 1:00 ` Jakub Kicinski
2024-05-11 9:51 ` Thomas Weißschuh
2024-05-11 9:51 ` Thomas Weißschuh
2024-05-11 9:51 ` Thomas Weißschuh
2024-05-11 9:51 ` Thomas Weißschuh
2024-05-11 9:51 ` Thomas Weißschuh
2024-05-12 19:32 ` Joel Granados
2024-05-12 19:32 ` Joel Granados
2024-05-12 19:32 ` Joel Granados
2024-05-12 19:32 ` Joel Granados
2024-05-12 19:32 ` Joel Granados
2024-05-13 2:57 ` Kees Cook
2024-05-13 2:57 ` Kees Cook
2024-05-13 2:57 ` Kees Cook
2024-05-13 2:57 ` Kees Cook
2024-05-13 2:57 ` Kees Cook
2024-05-12 19:24 ` Joel Granados
2024-05-12 19:24 ` Joel Granados
2024-05-12 19:24 ` Joel Granados
2024-05-12 19:24 ` Joel Granados
2024-05-12 19:24 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-08 11:40 ` Joel Granados [this message]
2024-05-08 11:40 ` Joel Granados
2024-05-08 11:40 ` Joel Granados
2024-05-08 11:40 ` Joel Granados
2024-05-08 11:40 ` Joel Granados
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240508114038.vnx2hchpxeimuqz2@joelS2.panther.com \
--to=j.granados@samsung.com \
--cc=apparmor@lists.ubuntu.com \
--cc=bpf@vger.kernel.org \
--cc=bridge@lists.linux.dev \
--cc=coreteam@netfilter.org \
--cc=david@fromorbit.com \
--cc=edumazet@google.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lvs-devel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=rds-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.