On 02/13, Tycho Andersen wrote:
>
> I think this is a false positive, we have:
Agreed,
> That said, a default case wouldn't hurt, and we should fix the first
> comment anyways, since now we have extensions.
>
> I'm happy to send a patch or maybe it's better for Christian to fix it
> in-tree.
I l
On 02/14, Oleg Nesterov wrote:
>
> On 02/13, Tycho Andersen wrote:
> >
> > I think this is a false positive, we have:
>
> Agreed,
>
> > That said, a default case wouldn't hurt, and we should fix the first
> > comment anyways, since now we have extensions
at 10:06:41AM +0100, Oleg Nesterov wrote:
> >
> > - /* Ensure that only a single signal scope determining flag is set. */
> > - if (hweight32(flags & PIDFD_SEND_SIGNAL_FLAGS) > 1)
> > + switch (flags) {
> > + case 0:
> > + /* but see the
On 02/14, Tycho Andersen wrote:
>
> On Wed, Feb 14, 2024 at 06:55:55PM +0100, Oleg Nesterov wrote:
> >
> > We want to check the "flags" argument at the start, we do not want to
> > delay the "case 0:" check until we have f.file (so that we can check
On 10/04, jef...@chromium.org wrote:
>
> It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may
> alter the mapping of vdso, vvar, and sigpage during restore
> operations. Consequently, this feature cannot be universally enabled
> across all systems.
Can't review.
But as for uprob
Sorry for the noise, forgot to mention...
On 10/04, jef...@chromium.org wrote:
>
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1535,6 +1535,15 @@
> Permit 'security.evm' to be updated regardless of
>
On 10/16, Jeff Xu wrote:
>
> On Wed, Oct 16, 2024 at 6:10 PM Liam R. Howlett
> wrote:
> >
> > > + exec.seal_system_mappings = [KNL]
> > > + Format: { never | always }
> > > + Seal system mappings: vdso, vvar, sigpage, uprobes,
> > > +
On 02/26, Oleg Nesterov wrote:
>
> On 02/24, jef...@chromium.org wrote:
> >
> > 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 f
On 02/26, Lorenzo Stoakes wrote:
>
> On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote:
> > On 02/24, jef...@chromium.org wrote:
> > >
> > > Unlike other system mappings, the uprobe mapping is not
> > > established during program startup. However
On 02/26, Lorenzo Stoakes wrote:
>
> Like I said, Jeff opposes the change. I disagree with him, and agree with you,
> because this is very silly.
>
> But I don't want to hold up this series with that discussion (this is for his
> sake...)
Neither me, so lets go with VM_SEALED_SYSMAP.
My only obje
On 02/24, jef...@chromium.org wrote:
>
> 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.
Agreed, VM_SEALED should be always for the "[uprobes]" vma, regard
AYEXEC|VM_DONTCOPY|VM_IO,
> + VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|
> + VM_SEALED_SYSMAP,
> &xol_mapping);
Reviewed-by: Oleg Nesterov
12 matches
Mail list logo
