On 03/03, jef...@chromium.org wrote:
>
> @@ -1683,7 +1683,8 @@ static int xol_add_vma(struct mm_struct *mm, struct
> xol_area *area)
> }
>
> vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE,
> - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO,
> +
On Mon, Mar 3, 2025 at 1:16 AM Kuninori Morimoto
wrote:
>
>
> Hi Kees
>
> Thank you for your feedback
>
> > > I would like to use string_choices helper to cleanup the code, but it
> > > missing
> > > some of well used string pair in kernel. This patch-set adds it.
> >
> > Do you have some Coccine
From: Jeff Xu
Add sysmap_is_sealed.c to test system mappings are sealed.
Note: CONFIG_MSEAL_SYSTEM_MAPPINGS must be set, as indicated in
config file.
Signed-off-by: Jeff Xu
---
.../mseal_system_mappings/.gitignore | 2 +
.../selftests/mseal_system_mappings/Makefile | 6 +
.../se
From: Jeff Xu
Update memory sealing documentation to include details about system
mappings.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
---
Documentation/userspace-api/mseal.rst | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/userspace-api/mseal.rst
From: Jeff Xu
Provide support to mseal the uprobe mapping.
Unlike other system mappings, the uprobe mapping is not
established during program startup. However, its lifetime is the same
as the process's lifetime. It could be sealed from creation.
Test was done with perf tool, and observe the upr
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
the vdso, vvar, and compat-mode vectors and sigpage mappings.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/vdso.c | 12
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
covering the vdso, vvar, vvar_vclock.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/x86/Kconfig | 1 +
arch/x86/entry/vdso/vma.c | 7 ---
2 files changed, 5 ins
From: Jeff Xu
Add code to detect if the vdso is memory sealed, skip the test
if it is.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
Reviewed-by: Lorenzo Stoakes
---
.../testing/selftests/x86/test_mremap_vdso.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tools/t
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP
macro for future patches.
Signed-off-by: Jeff Xu
---
include/linux/mm.h | 10 ++
init/Kconfig | 22
From: Jeff Xu
This is V8 version, addressing comments from V7, without code logic
change.
---
As discussed during mseal() upstream process [1], mseal() protects
the VMAs of a given virtual memory range against modifications, such
as
On Wed, Feb 26, 2025 at 01:10:03PM +0100, Thorsten Blum wrote:
> Since strncpy() is deprecated for NUL-terminated destination buffers,
> use strscpy() instead.
>
> Compile-tested only.
>
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-hardening@vger.kernel.org
> Signed-off-by: Thorste
Hi Kees
Thank you for your feedback
> > I would like to use string_choices helper to cleanup the code, but it
> > missing
> > some of well used string pair in kernel. This patch-set adds it.
>
> Do you have some Coccinelle scripts or other patches that show the use
> of these helpers? We tend
Convert mux_control_ops to a flexible array member at the end of the
mux_chip struct and add the __counted_by() compiler attribute to
improve access bounds-checking via CONFIG_UBSAN_BOUNDS and
CONFIG_FORTIFY_SOURCE.
Use struct_size() to calculate the number of bytes to allocate for a new
mux chip
strncpy() is deprecated for NUL-terminated destination buffers; use
strscpy() instead. The destination buffer db_root is only used with "%s"
format strings and must therefore be NUL-terminated, but not NUL-padded.
Use scnprintf() because snprintf() could return a value >= DB_ROOT_LEN
and lead to a
On 02/03/2025 7:16 pm, Rudolf Marek wrote:
> Dne 01. 03. 25 v 23:48 Rudolf Marek napsal(a):
>> I don't know how slow is to do the jump back via far jump.
>
> I did some micro benchmark on Raptorlake platform using other
> operating system I'm very familiar with.
>
> I added following sequence to th
Dne 01. 03. 25 v 23:48 Rudolf Marek napsal(a):
I don't know how slow is to do the jump back via far jump.
I did some micro benchmark on Raptorlake platform using other operating system
I'm very familiar with.
I added following sequence to the SYSCALL64 entrypoint:
.balign 16
syscallentry64:
On Thu, Feb 27, 2025 at 06:39:33PM +0100, Thorsten Blum wrote:
> strncpy() is deprecated for NUL-terminated destination buffers; use
> strscpy() instead.
>
> Compile-tested only.
>
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-hardening@vger.kernel.org
> Signed-off-by: Thorsten Blum
On 28. Feb 2025, at 21:10, Kees Cook wrote:
> On Wed, Feb 26, 2025 at 01:10:03PM +0100, Thorsten Blum wrote:
>> Since strncpy() is deprecated for NUL-terminated destination buffers,
>> use strscpy() instead.
>>
>> Compile-tested only.
>>
>> Link: https://github.com/KSPP/linux/issues/90
>> Cc: lin
18 matches
Mail list logo
