On Tue, Aug 27, 2024 at 7:15 PM Jakub Kicinski wrote:
>
> On Sun, 25 Aug 2024 04:15:02 + Mina Almasry wrote:
> > +void net_devmem_free_dmabuf(struct net_iov *niov)
> > +{
> > + struct net_devmem_dmabuf_binding *binding = net_iov_binding(niov);
> > + unsigned long dma_addr = net_devmem_
Adding Mat(s) for awareness, it would be great (but difficult) to have
mptcp too in the long run ;)
On 8/27/24 21:32, Willem de Bruijn wrote:
From: Willem de Bruijn
Lay the groundwork to import into kselftests the over 150 packetdrill
TCP/IP conformance tests on github.com/google/packetdrill.
Hey Roman,
On 21.06.24 22:14, Roman Kagan wrote:
In a series posted a few years ago [1], a proposal was put forward to allow the
kernel to allocate memory local to a mm and thus push it out of reach for
current and future speculation-based cross-process attacks. We still believe
this is a nice
On 2024/8/28 06:49:18, Lin Yikai reply:
[Some people who received this message don't often get email from
andrii.nakry...@gmail.com. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
On Tue, Aug 27, 2024 at 6:40 AM Lin Yikai wrote:
1. Fix cross-compile issue fo
On Tue, Aug 27, 2024 at 10:48:51AM +0530, Dev Jain wrote:
> - ksft_exit_fail_msg("PTRACE_TRACEME", strerror(errno));
> + ksft_exit_fail_perror("PTRACE_TRACEME");
>
> if (raise(SIGSTOP))
> - ksft_exit_fail_msg("raise(SIGSTOP)", strerror(errno));
> +
On Tue, Aug 27, 2024 at 01:33:47PM +0100, Will Deacon wrote:
> On Tue, Aug 27, 2024 at 10:48:51AM +0530, Dev Jain wrote:
> > A "%s" is missing in ksft_exit_fail_msg(); instead, use the newly
> > introduced ksft_exit_fail_perror(). Also, uint64_t corresponds to
> > unsigned 64-bit integer, so use %l
Hello all,
This patch series targets a long-standing BPF usability issue - the lack
of general cross-compilation support - by enabling cross-endian usage of
libbpf and bpftool, as well as supporting cross-endian build targets for
selftests/bpf.
Benefits include improved BPF development and testin
Fix missing newlines and extraneous terminal spaces in messages.
Signed-off-by: Tony Ambardar
---
tools/lib/bpf/btf.c | 6 +++---
tools/lib/bpf/btf_dump.c | 2 +-
tools/lib/bpf/btf_relocate.c | 2 +-
tools/lib/bpf/libbpf.c | 4 ++--
tools/lib/bpf/relo_core.c| 2 +-
5 files
Object linking output data uses the default ELF_T_BYTE type for '.symtab'
section data, which disables any libelf-based translation. Explicitly set
the ELF_T_SYM type for output to restore libelf's byte-order conversion,
noting that input '.symtab' data is already correctly translated.
Fixes: faf6
Mention struct btf_ext_info_sec rather than non-existent btf_sec_func_info
in BTF.ext struct documentation.
Signed-off-by: Tony Ambardar
---
tools/lib/bpf/libbpf_internal.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/lib
Support for handling BTF data of either endianness was added in [1], but
did not include BTF.ext data for lack of use cases. Later, support for
static linking [2] provided a use case, but this feature and later ones
were restricted to native-endian usage.
Add support for BTF.ext handling in either
Allow bpf_object__open() to access files of either endianness, and convert
included BPF programs to native byte-order in-memory for introspection.
Loading BPF objects of non-native byte-order is still disallowed however.
Signed-off-by: Tony Ambardar
---
tools/lib/bpf/libbpf.c | 34 +
Allow static linking object files of either endianness, checking that input
files have consistent byte-order, and setting output endianness from input.
Linking requires in-memory processing of programs, relocations, sections,
etc. in native endianness, and output conversion to target byte-order. T
Track target endianness in 'struct bpf_gen' and process in-memory data in
native byte-order, but on finalization convert the embedded loader BPF
insns to target endianness.
The light skeleton also includes a target-accessed data blob which is
heterogeneous and thus difficult to convert to target b
Update Makefile build rules to compile BPF programs with target endianness
rather than host byte-order. With recent changes, this allows building the
full selftests/bpf suite hosted on x86_64 and targeting s390x or mips64eb
for example.
Signed-off-by: Tony Ambardar
---
tools/testing/selftests/bp
On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> > On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> > > With the current implementation, __cvdso_getrandom_data() calls
> > > memset(), which is un
Since Linux 5.6 tpm_version_major sysfs file is avaialble which gives
the TPM version.
Using this file the test can be skipped on systems with TPM 1.2.
Signed-off-by: Michal Suchanek
---
tools/testing/selftests/tpm2/test_smoke.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testi
tools/testing/selftests/tpm2/ is TPM-specific test
Signed-off-by: Michal Suchanek
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 878dcd23b331..c2ee92c7c16c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23184,6 +23184,7 @@ Q:
https://pat
On Tue, Aug 27, 2024 at 05:29:56PM +0200, Jason A. Donenfeld wrote:
> On Tue, Aug 27, 2024 at 5:29 PM Xi Ruoyao wrote:
> > Or, I can add $(KHDR_INCLUDES) but also keep
> > -isystem $(top_srcdir)/include/uapi, so "make -C tools/testing/selftests
> > TARGETS=vDSO" will still (happens to) work on x86
On Wed, 2024-08-28 at 13:36 +0200, Jason A. Donenfeld wrote:
> On Tue, Aug 27, 2024 at 05:29:56PM +0200, Jason A. Donenfeld wrote:
> > On Tue, Aug 27, 2024 at 5:29 PM Xi Ruoyao wrote:
> > > Or, I can add $(KHDR_INCLUDES) but also keep
> > > -isystem $(top_srcdir)/include/uapi, so "make -C tools/te
These two patch enable the use of "vmtest.sh" for cross-compile arm64 on x86_64
host.
This is essential for utilizing BPF on Android (arm64),
as the compilation server is running on Ubuntu (x86).
Following previous guidance from V1, the two changes are as follow:
V2:
- patch 2:
- [1/2] In Ma
In Makefile, we use $(SRCARCH) to access target arch's uapi include.
This allow us to obtain the definition of 'struct user_pt_regs' for "ptrace.h"
header file.
Thus, it is no longer necessary to execute "make headers_install".
Signed-off-by: Lin Yikai
---
tools/testing/selftests/bpf/Makefile
Regard "LDLIBS += -lzstd" as a separate patch for static compile.
To fix static cross-compile error like this:
$LDLIBS=-static LDFLAGS=--sysroot=/aarch64-linux-gnu/libc ./vmtest.sh -s --
./test_progs
/aarch64-linux-gnu/bin/ld:
aarch64-linux-gnu/libc/usr/lib/libelf.a(elf_compress.o): in func
On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
>> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
>> >
>> > Is there a compiler flag that could be used to disable the generation of
>> > calls
>> > to me
On Wed, Aug 28, 2024 at 2:24 PM Arnd Bergmann wrote:
>
> On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> >> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> >> >
> >> > Is there a compiler flag that
On Wed, Aug 28, 2024 at 01:18:34PM +0200, Jason A. Donenfeld wrote:
> On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> > On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> > > > + for (i = 0; i < ARRAY_SIZE(params->reserved); i++)
> > > > +
On Wed, Aug 28, 2024 at 07:33:13AM -0500, Segher Boessenkool wrote:
> On Wed, Aug 28, 2024 at 01:18:34PM +0200, Jason A. Donenfeld wrote:
> > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> > > On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> > > > > +
On Wed, Aug 28, 2024 at 12:24:12PM +, Arnd Bergmann wrote:
> On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> >> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> >> >
> >> > Is there a compiler fl
On Wed, Aug 28, 2024 at 02:26:08PM +0200, Jason A. Donenfeld wrote:
> On Wed, Aug 28, 2024 at 2:24 PM Arnd Bergmann wrote:
> >
> > On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> > > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> > >> On Tue, Aug 27, 2024 at 11:0
On Wed Aug 28, 2024 at 2:23 PM EEST, Michal Suchanek wrote:
> Since Linux 5.6 tpm_version_major sysfs file is avaialble which gives
> the TPM version.
>
> Using this file the test can be skipped on systems with TPM 1.2.
>
> Signed-off-by: Michal Suchanek
> ---
> tools/testing/selftests/tpm2/test_
Linking to libsodium makes building this test annoying in cross
compilation environments and is just way too much. Since this is just a
basic correctness test, simply open code a simple, unoptimized, dumb
chacha, rather than linking to libsodium.
Signed-off-by: Jason A. Donenfeld
---
tools/testi
Jakub Kicinski wrote:
> Very exciting to see packetdrill tests making their way upstream!
>
> On Tue, 27 Aug 2024 15:32:29 -0400 Willem de Bruijn wrote:
> > RFC points for discussion
> >
> > ksft: the choice for this python framework introduces a dependency on
> > the YNL scripts, and some non-ob
Paolo Abeni wrote:
> Adding Mat(s) for awareness, it would be great (but difficult) to have
> mptcp too in the long run ;)
>
> On 8/27/24 21:32, Willem de Bruijn wrote:
> > From: Willem de Bruijn
> >
> > Lay the groundwork to import into kselftests the over 150 packetdrill
> > TCP/IP conformanc
Hi Jason,
Le 28/08/2024 à 15:55, Jason A. Donenfeld a écrit :
> Linking to libsodium makes building this test annoying in cross
> compilation environments and is just way too much. Since this is just a
> basic correctness test, simply open code a simple, unoptimized, dumb
> chacha, rather than lin
On Tue, 27 Aug 2024 07:52:40 -0700 Breno Leitao wrote:
> +++ b/tools/testing/selftests/net/config
You gotta check all the configs, net is now fine, but bpf still breaks.
There may be more configs we don't use in CI.
BTW I'm not saying anything about the change itself. There's a non-zero
chance th
Hi Christophe,
On Wed, Aug 28, 2024 at 4:38 PM LEROY Christophe
wrote:
> - key[0], key[1], key[2], key[3], key[4], key[5], key[6], key[7]
> + le32toh(key[0]), le32toh(key[1]), le32toh(key[2]),
> le32toh(key[3]),
> + le32toh(key[4]), le32toh(key[5]), le3
On 08/27, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> Lay the groundwork to import into kselftests the over 150 packetdrill
> TCP/IP conformance tests on github.com/google/packetdrill.
>
> Florian recently added support for packetdrill tests in nf_conntrack,
> in commit a8a388c2aae49 ("
Hello Jakub,
On Wed, Aug 28, 2024 at 07:42:40AM -0700, Jakub Kicinski wrote:
> On Tue, 27 Aug 2024 07:52:40 -0700 Breno Leitao wrote:
> > +++ b/tools/testing/selftests/net/config
>
> You gotta check all the configs, net is now fine, but bpf still breaks.
> There may be more configs we don't use i
On Wed, 28 Aug 2024 08:01:02 -0700 Stanislav Fomichev wrote:
> I don't see anything about building the binary itself. Am I missing
> something or should we also have some makefile magic to do it?
> I'm not sure packetdrill is packaged by the distros... Presumably
> we want the existing NIPA runners
On Wed, 28 Aug 2024 at 14:57, Segher Boessenkool
wrote:
>
> On Wed, Aug 28, 2024 at 12:24:12PM +, Arnd Bergmann wrote:
> > On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> > > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> > >> On Tue, Aug 27, 2024 at 11:08:19
Stanislav Fomichev wrote:
> On 08/27, Willem de Bruijn wrote:
> > From: Willem de Bruijn
> >
> > Lay the groundwork to import into kselftests the over 150 packetdrill
> > TCP/IP conformance tests on github.com/google/packetdrill.
> >
> > Florian recently added support for packetdrill tests in nf
On 8/17/2024 1:35 AM, Sean Christopherson wrote:
> On Tue, Jul 09, 2024, Manali Shukla wrote:
>> Expose the Bus Lock Threshold in the guest CPUID and support its
>> functionality in nested guest.
>
> Why? This is a rather messy feature to support in a nested setup, and I'd
> much
> prefer to not
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov :
On Tue, 20 Aug 2024 10:36:22 +0800 you wrote:
> From: Hao Ge
>
> Smatch reported the following warning:
> ./tools/testing/selftests/bpf/testing_helpers.c:455 get_xlated_program()
> warn: variable derefere
On Wed, 28 Aug 2024 10:03:55 -0400 Willem de Bruijn wrote:
> > > A single script is much
> > > simpler, optionally with nested KTAP (not supported yet by ksft). But,
> > > I'm afraid that running time without intermediate output will be very
> > > long when we integrate all packetdrill scripts.
>
Hi Willem, Paolo,
Thank you for this series, that would be great to have the CI validating
these packetdrill tests!
(Having the Netdev CI validating these packetdrill tests was part of my
suggestions for the discussion we will have at NetConf :) )
On 28/08/2024 16:03, Willem de Bruijn wrote:
> P
Hi!
On Wed, Aug 28, 2024 at 05:40:23PM +0200, Ard Biesheuvel wrote:
> On Wed, 28 Aug 2024 at 14:57, Segher Boessenkool
> wrote:
> >
> > On Wed, Aug 28, 2024 at 12:24:12PM +, Arnd Bergmann wrote:
> > > On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> > > > On Tue, Aug 27, 2024 at 05
>
>> /*
>> * Use nested page tables by default. Note, NPT may get forced off by
>> * svm_hardware_setup() if it's unsupported by hardware or the host kernel.
>> @@ -3231,6 +3234,19 @@ static int invpcid_interception(struct kvm_vcpu *vcpu)
>> return kvm_handle_invpcid(vcpu, type, gva);
Le 28/08/2024 à 16:49, Jason A. Donenfeld a écrit :
Hi Christophe,
On Wed, Aug 28, 2024 at 4:38 PM LEROY Christophe
wrote:
- key[0], key[1], key[2], key[3], key[4], key[5], key[6], key[7]
+ le32toh(key[0]), le32toh(key[1]), le32toh(key[2]),
le32toh(key[3]),
+
On Wed, Aug 28, 2024 at 6:54 PM Christophe Leroy
wrote:
> The only thing is that you must describe this behaviour change in your
> commit message, you can't just let people believe it is a one-to-one
> replacement of the previous test implementation that used Sodium.
Good point, will do.
On Wed, 28 Aug 2024 at 18:24, Segher Boessenkool
wrote:
>
> Hi!
>
> On Wed, Aug 28, 2024 at 05:40:23PM +0200, Ard Biesheuvel wrote:
> > On Wed, 28 Aug 2024 at 14:57, Segher Boessenkool
> > wrote:
> > >
> > > On Wed, Aug 28, 2024 at 12:24:12PM +, Arnd Bergmann wrote:
> > > > On Wed, Aug 28, 20
On 6/9/24 22:28, Muhammad Usama Anjum wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 523d84b2d6139..f3a17e5d954a3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -24378,6 +24378,7 @@ T:git
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core
> F: Documentation/a
On 08/28, Willem de Bruijn wrote:
> Stanislav Fomichev wrote:
> > On 08/27, Willem de Bruijn wrote:
> > > From: Willem de Bruijn
> > >
> > > Lay the groundwork to import into kselftests the over 150 packetdrill
> > > TCP/IP conformance tests on github.com/google/packetdrill.
> > >
> > > Florian
On Wed, Aug 28, 2024 at 08:34:49AM +0200, Christophe Leroy wrote:
> Hi Charlie,
>
> Le 28/08/2024 à 07:49, Charlie Jenkins a écrit :
> > Add support for MAP_BELOW_HINT to arch_get_mmap_base() and
> > arch_get_mmap_end().
> >
> > Signed-off-by: Charlie Jenkins
> > ---
> > arch/powerpc/include/a
On Wed, Aug 28, 2024 at 07:12:55PM +0200, Ard Biesheuvel wrote:
> On Wed, 28 Aug 2024 at 18:24, Segher Boessenkool
> wrote:
> > > In my experience, this is likely to do the opposite: it causes the
> > > compiler to 'forget' the semantics of memcpy() and memset(), so that
> > > explicit trivial cal
On Mon, Aug 26, 2024 at 01:00:09PM +0300, Catalin Marinas wrote:
> On Fri, Aug 23, 2024 at 11:01:13PM +0100, Mark Brown wrote:
> > On Fri, Aug 23, 2024 at 04:59:11PM +0100, Catalin Marinas wrote:
> gcs_preserve_current_state() only a context switch thing. Would it work
> if we don't touch the thre
On Tue, Aug 27, 2024 at 10:49:22PM GMT, Charlie Jenkins wrote:
> Add a selftest for MAP_BELOW_HINT that maps until it runs out of space
> below the hint address.
>
> Signed-off-by: Charlie Jenkins
> ---
> tools/testing/selftests/mm/Makefile | 1 +
> tools/testing/selftests/mm/map_below_h
On Wed, Aug 28, 2024 at 06:48:33PM +0100, Lorenzo Stoakes wrote:
> On Tue, Aug 27, 2024 at 10:49:22PM GMT, Charlie Jenkins wrote:
> > Add a selftest for MAP_BELOW_HINT that maps until it runs out of space
> > below the hint address.
> >
> > Signed-off-by: Charlie Jenkins
> > ---
> > tools/testing
On Tue, Aug 27, 2024 at 10:49:06PM GMT, Charlie Jenkins wrote:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the maximum address space,
> unless the hint ad
On Wed, 28 Aug 2024 10:20:47 -0700 Stanislav Fomichev wrote:
> > As Jakub responded.
> >
> > Indeed importing the whole application into the kernel sources is what
> > stopped me from attempting this before. Florian's nf_conntrack charted
> > the path here.
>
> Thanks both. I was expecting to f
On Tue, Aug 27, 2024 at 12:34 PM Willem de Bruijn
wrote:
>
> From: Willem de Bruijn
>
> Lay the groundwork to import into kselftests the over 150 packetdrill
> TCP/IP conformance tests on github.com/google/packetdrill.
>
> Florian recently added support for packetdrill tests in nf_conntrack,
> in
On 8/27/24 22:49, Charlie Jenkins wrote:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the maximum address space,
> unless the hint address is greater than
* Charlie Jenkins [240828 01:49]:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the maximum address space,
> unless the hint address is greater than this v
On 08/28, Jakub Kicinski wrote:
> On Wed, 28 Aug 2024 10:20:47 -0700 Stanislav Fomichev wrote:
> > > As Jakub responded.
> > >
> > > Indeed importing the whole application into the kernel sources is what
> > > stopped me from attempting this before. Florian's nf_conntrack charted
> > > the path he
From: Jon Maloy
Adding SO_PEEK_OFF for TCPv6 and selftest for both TCPv4 and TCPv6
Jon Maloy (2):
tcp: add SO_PEEK_OFF socket option tor TCPv6
selftests: add selftest for tcp SO_PEEK_OFF support
net/ipv6/af_inet6.c | 1 +
tools/testing/selftests/net/Makefile
From: Jon Maloy
When doing further testing of the recently added SO_PEEK_OFF feature
for TCP I realized I had omitted to add it for TCP/IPv6.
I do that here.
Fixes: 05ea491641d3 ("tcp: add support for SO_PEEK_OFF socket option")
Reviewed-by: Eric Dumazet
Reviewed-by: David Gibson
Reviewed-by:
From: Jon Maloy
We add a selftest to check that the new feature added in
commit 05ea491641d3 ("tcp: add support for SO_PEEK_OFF socket option")
works correctly.
Reviewed-by: Jason Xing
Reviewed-by: Stefano Brivio
Tested-by: Stefano Brivio
Signed-off-by: Jon Maloy
---
v2: Made correction bas
On Wed, 28 Aug 2024 11:26:28 -0700 Mina Almasry wrote:
> I did not know about run_kselftest.sh. From a quick look, it seems to
> require selftests to be installed to run them. I think nipa relies on
> something slightly different, it does something like this, AFAIU this
> runs an individual kselfte
On Wed, 28 Aug 2024 08:05:09 -0700 Breno Leitao wrote:
> On Wed, Aug 28, 2024 at 07:42:40AM -0700, Jakub Kicinski wrote:
> > On Tue, 27 Aug 2024 07:52:40 -0700 Breno Leitao wrote:
> > > +++ b/tools/testing/selftests/net/config
> >
> > You gotta check all the configs, net is now fine, but bpf s
On Wed, 28 Aug 2024 00:20:23 -0700 Mina Almasry wrote:
> > On Sun, 25 Aug 2024 04:15:02 + Mina Almasry wrote:
> > > +void net_devmem_free_dmabuf(struct net_iov *niov)
> > > +{
> > > + struct net_devmem_dmabuf_binding *binding = net_iov_binding(niov);
> > > + unsigned long dma_addr = n
Jakub Kicinski wrote:
> On Wed, 28 Aug 2024 10:03:55 -0400 Willem de Bruijn wrote:
> > > > A single script is much
> > > > simpler, optionally with nested KTAP (not supported yet by ksft). But,
> > > > I'm afraid that running time without intermediate output will be very
> > > > long when we integr
On Wed, Aug 28, 2024 at 11:29:56AM -0700, Dave Hansen wrote:
> On 8/27/24 22:49, Charlie Jenkins wrote:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> > address returned by mmap to be less than
On Wed, Aug 28, 2024 at 02:31:42PM -0400, Liam R. Howlett wrote:
> * Charlie Jenkins [240828 01:49]:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> > address returned by mmap to be less than th
On Wed, 28 Aug 2024 15:33:33 -0400 Willem de Bruijn wrote:
> That could work.
>
> Is reporting one KTAP and exitcode per directory vs per packetdrill
> invocation good/bad/neither?
To me "neither", hopefully and unhelpfully I won't tell you anything
that's not common sense :) The balance is betwe
Mingwei Zhang writes:
On Tue, Aug 13, 2024, Colton Lewis wrote:
Without the leading underscore, these variables are referencing a
variable in the calling scope. It only worked before by accident
because all calling scopes had a variable with the right name.
Signed-off-by: Colton Lewis
T
On Wed, Aug 28, 2024 at 01:59:18PM -0700, Charlie Jenkins wrote:
> On Wed, Aug 28, 2024 at 02:31:42PM -0400, Liam R. Howlett wrote:
> > * Charlie Jenkins [240828 01:49]:
> > > Some applications rely on placing data in free bits addresses allocated
> > > by mmap. Various architectures (eg. x86, arm
Hi Mingwei, thanks for reviewing!
Mingwei Zhang writes:
On Tue, Aug 13, 2024, Colton Lewis wrote:
This defined the CPUID calls to determine what extensions and
properties are available. AMD reference manual names listed below.
* PerfCtrExtCore (six core counters instead of four)
* PerfCtrE
Hi Mingwei
Mingwei Zhang writes:
On Tue, Aug 13, 2024, Colton Lewis wrote:
Branch in main() depending on if the CPU is Intel or AMD. They are
subject to vastly different requirements because the AMD PMU lacks
many properties defined by the Intel PMU including the entire CPUID
0xa function whe
From: Jeff Xu
mmap(MAP_FIXED) should return EPERM when memory is sealed.
Fixes: 4205a39e06da ("mm/munmap: replace can_modify_mm with can_modify_vma")
Signed-off-by: Jeff Xu
---
mm/mmap.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 80d70ed
From: Jeff Xu
Add more testcases and increase test coverage, e.g. add
get_vma_size to check VMA size and prot bits.
Signed-off-by: Jeff Xu
---
tools/testing/selftests/mm/mseal_test.c | 826 ++--
1 file changed, 759 insertions(+), 67 deletions(-)
diff --git a/tools/testing/
On Wed, Aug 28, 2024 at 3:39 PM Colton Lewis wrote:
>
> Hi Mingwei
>
> Mingwei Zhang writes:
>
> > On Tue, Aug 13, 2024, Colton Lewis wrote:
> >> Branch in main() depending on if the CPU is Intel or AMD. They are
> >> subject to vastly different requirements because the AMD PMU lacks
> >> many pr
The arm64 Guarded Control Stack (GCS) feature provides support for
hardware protected stacks of return addresses, intended to provide
hardening against return oriented programming (ROP) attacks and to make
it easier to gather call stacks for applications such as profiling.
When GCS is active a sec
Since multiple architectures have support for shadow stacks and we need to
select support for this feature in several places in the generic code
provide a generic config option that the architectures can select.
Suggested-by: David Hildenbrand
Acked-by: David Hildenbrand
Reviewed-by: Deepak Gupt
Currently arch_validate_flags() is written in a very non-extensible
fashion, returning immediately if MTE is not supported and writing the MTE
check as a direct return. Since we will want to add more checks for GCS
refactor the existing code to be more extensible, no functional change
intended.
Re
Three architectures (x86, aarch64, riscv) have announced support for
shadow stacks with fairly similar functionality. While x86 is using
arch_prctl() to control the functionality neither arm64 nor riscv uses
that interface so this patch adds arch-agnostic prctl() support to
get and set status of s
In preparation for adding arm64 GCS support make the map_shadow_stack()
SHADOW_STACK_SET_TOKEN flag generic and add _SET_MARKER. The existing
flag indicates that a token usable for stack switch should be added to
the top of the newly mapped GCS region while the new flag indicates that
a top of stac
FEAT_GCS introduces a number of new system registers, we require that
access to these registers is not trapped when we identify that the feature
is present. There is also a HCRX_EL2 control to make GCS operations
functional.
Since if GCS is enabled any function call instruction will cause a fault
Add some documentation of the userspace ABI for Guarded Control Stacks.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/gcs.rst | 230 +
Documentation/arch/arm64/index.rst | 1 +
2 fi
The architecture defines a format for guarded control stack caps, used
to mark the top of an unused GCS in order to limit the potential for
exploitation via stack switching. Add definitions associated with these.
Reviewed-by: Thiago Jung Bauermann
Acked-by: Catalin Marinas
Signed-off-by: Mark Br
Define C callable functions for GCS instructions used by the kernel. In
order to avoid ambitious toolchain requirements for GCS support these are
manually encoded, this means we have fixed register numbers which will be
a bit limiting for the compiler but none of these should be used in
sufficientl
In order for EL1 to write to an EL0 GCS it must use the GCSSTTR instruction
rather than a normal STTR. Provide a put_user_gcs() which does this.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/uaccess.h | 18 +
There is a control HCRX_EL2.GCSEn which must be set to allow GCS
features to take effect at lower ELs and also fine grained traps for GCS
usage at EL0 and EL1. Configure all these to allow GCS usage by EL0 and
EL1.
We also initialise GCSCR_EL1 and GCSCRE0_EL1 to ensure that we can
execute functio
Add a cpufeature for GCS, allowing other code to conditionally support it
at runtime.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/cpufeature.h | 6 ++
arch/arm64/kernel/cpufeature.c | 9 +
arch/arm64/tool
Pages used for guarded control stacks need to be described to the hardware
using the Permission Indirection Extension, GCS is not supported without
PIE. In order to support copy on write for guarded stacks we allocate two
values, one for active GCSs and one for GCS pages marked as read only prior
t
Use VM_HIGH_ARCH_5 for guarded control stack pages.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
Documentation/filesystems/proc.rst | 2 +-
include/linux/mm.h | 12 +++-
2 files changed, 12 insertions(+), 2 deletions(-)
Map pages flagged as being part of a GCS as such rather than using the
full set of generic VM flags.
This is done using a conditional rather than extending the size of
protection_map since that would make for a very sparse array.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
S
GCS introduces a number of system registers for EL1 and EL0, on systems
with GCS we need to context switch them and expose them to VMMs to allow
guests to use GCS.
In order to allow guests to use GCS we also need to configure
HCRX_EL2.GCSEn, if this is not set GCS instructions will be noops and
CH
Hook up an override for GCS, allowing it to be disabled from the command
line by specifying arm64.nogcs in case there are problems.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Acked-by: Catalin Marinas
Signed-off-by: Mark Brown
---
Documentation/admin-guide/kernel-paramete
Provide a hwcap to enable userspace to detect support for GCS.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/elf_hwcaps.rst | 2 ++
arch/arm64/include/asm/hwcap.h | 1 +
arch/arm64/include/uapi/asm/hwcap.h |
A new exception code is defined for GCS specific faults other than
standard load/store faults, for example GCS token validation failures,
add handling for this. These faults are reported to userspace as
segfaults with code SEGV_CPERR (protection error), mirroring the
reporting for x86 shadow stack
All GCS operations at EL0 must happen on a page which is marked as
having UnprivGCS access, including read operations. If a GCS operation
attempts to access a page without this then it will generate a data
abort with the GCS bit set in ESR_EL1.ISS2.
EL0 may validly generate such faults, for examp
1 - 100 of 141 matches
Mail list logo
