Re: [PATCH v2 1/1] mseal: update mseal.rst

Randy Dunlap wrote: > On 10/4/24 9:52 AM, Jeff Xu wrote: > >> above is not a sentence but I don't know how to fix it. > >> > > Would below work ? > > > > Certain destructive madvise behaviors, specifically MADV_DONTNEED, > > MADV_FREE, MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, > > MADV_WIP

Re: [PATCH v2 1/1] mseal: update mseal.rst

On 10/4/24 9:52 AM, Jeff Xu wrote: >> above is not a sentence but I don't know how to fix it. >> > Would below work ? > > Certain destructive madvise behaviors, specifically MADV_DONTNEED, > MADV_FREE, MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, > MADV_WIPEONFORK, can pose risks when applie

[PATCH v2][next] wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings

-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. So, in order to avoid ending up with a flexible-array member in the middle of multiple other structs, we use the `__struct_group()` helper to create a new tagged `struct ieee80211_radiotap_hea

Re: [PATCH][next] wifi: iwlwifi: dvm: Avoid -Wflex-array-member-not-at-end warnings

Hi all, Friendly ping: who can take this, please? 🙂 Thanks -Gustavo On 15/08/24 13:00, Gustavo A. R. Silva wrote: -Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. So, in order to avoid ending up with a flexible-array member in the middl

Re: [PATCH][next] wifi: iwlwifi: fw/mvm: Avoid multiple -Wflex-array-member-not-at-end warnings

Hi all, Friendly ping: who can take this, please? 🙂 Thanks -Gustavo On 15/08/24 13:54, Gustavo A. R. Silva wrote: -Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. So, in order to avoid ending up with a flexible-array member in the middl

Re: [PATCH v2 1/1] mseal: update mseal.rst

Jeff Xu wrote: > > > + replacement with a new mapping with new set of attributes, or can > > > + overwrite the existing mapping with another mapping. > > > + > > > + mprotect and pkey_mprotect are blocked because they changes the > > > + protection bits (RWX) of the mapping. > > > + > > >

Re: [PATCH] [next] ARM: Replace snprintf() with the safer scnprintf() variant

On Fri, Oct 04, 2024 at 10:09:50AM +0100, Russell King (Oracle) wrote: > On Fri, Oct 04, 2024 at 03:59:30PM +1300, Paulo Miguel Almeida wrote: > > There is a general misunderstanding amongst engineers that {v}snprintf() > > returns the length of the data *actually* encoded into the destination > >

Re: [REGRESSION][BISECTED] Cannot boot Lichee Pi 4A with FORTIFY_SOURCE enabled

On Fri, Oct 04, 2024 at 01:37:44PM +0200, Alexandre Ghiti wrote: > I have a question though: should we do something about the following > warnings? Is there something wrong somewhere? > > Wanted to write 8 to a 0-sized destination: oldptr at > arch/riscv/errata/thead/errata.c:185 > Wanted to writ

Re: [PATCH v3] slab: Introduce kmalloc_obj() and family

On Fri, Aug 23, 2024 at 06:27:58AM +0200, Przemek Kitszel wrote: > On 8/23/24 01:13, Kees Cook wrote: > > > (...) For cases where the total size of the allocation is needed, > > the kmalloc_obj_sz(), kmalloc_objs_sz(), and kmalloc_flex_sz() family > > of macros can be used. For example: > > > >

Re: [PATCH v1 1/1] mseal: update mseal.rst

On Mon, Sep 30, 2024 at 05:24:39PM -0700, Jeff Xu wrote: > Hi Pedro > > On Sat, Sep 28, 2024 at 6:43 AM Pedro Falcato wrote: > > > > On Fri, Sep 27, 2024 at 06:29:30PM GMT, Jeff Xu wrote: > > > Hi Pedro, > > > > > > On Fri, Sep 27, 2024 at 3:59 PM Pedro Falcato > > > wrote: > > > > > > > + > >

Re: [PATCH v2 1/1] mseal: update mseal.rst

Hi Randy On Thu, Oct 3, 2024 at 3:54 PM Randy Dunlap wrote: > > Hi Jeff, > > Sorry for the delay. > Thanks for your v2 updates. > I appreciate you spending time proofreading the mseal.rst. > > On 9/30/24 5:26 PM, jef...@chromium.org wrote: > > From: Jeff Xu > > > > Update doc after in-loop chan

[RFC PATCH v1 1/1] exec: seal system mappings

From: Jeff Xu Seal vdso, vvar, sigpage, uprobes and vsyscall. Those mappings are readonly or executable only, sealing can protect them from ever changing during the life time of the process. System mappings such as vdso, vvar, and sigpage (for arm) are generated by the kernel during program ini

[RFC PATCH v1 0/1] seal system mappings

From: Jeff Xu Seal vdso, vvar, sigpage, uprobes and vsyscall. Those mappings are readonly or executable only, sealing can protect them from ever changing during the life time of the process. System mappings such as vdso, vvar, and sigpage (for arm) are generated by the kernel during program ini

Re: [REGRESSION][BISECTED] Cannot boot Lichee Pi 4A with FORTIFY_SOURCE enabled

Hi Kees, Jason, On 03/10/2024 23:21, Kees Cook wrote: On Thu, Oct 03, 2024 at 01:12:59PM -0400, Jason Montleon wrote: On Thu, Oct 3, 2024 at 10:41 AM Alexandre Ghiti wrote: So I was able to reproduce the issue on qemu by adding a few tweaks, and indeed we trap in __warn_printk() on a virtual

Re: [PATCH] acl: Annotate struct posix_acl with __counted_by()

On 2. Oct 2024, at 05:42, Nathan Chancellor wrote: > On Thu, Sep 26, 2024 at 02:21:42PM +0200, Thorsten Blum wrote: >> On 26. Sep 2024, at 03:46, kernel test robot wrote: >>> >>> Hello, >>> >>> kernel test robot noticed >>> "WARNING:at_lib/string_helpers.c:#__fortify_report" on: >>> >>> commi

Re: [PATCH] [next] ARM: Replace snprintf() with the safer scnprintf() variant

On Fri, Oct 04, 2024 at 03:59:30PM +1300, Paulo Miguel Almeida wrote: > There is a general misunderstanding amongst engineers that {v}snprintf() > returns the length of the data *actually* encoded into the destination > array. However, as per the C99 standard {v}snprintf() really returns > the len