On Thu, Feb 06, 2025 at 10:51:54AM -0500, enh wrote:
> On Thu, Feb 6, 2025 at 10:28 AM Thomas Weißschuh
> wrote:
> >
> > On Thu, Feb 06, 2025 at 09:38:59AM -0500, enh wrote:
> > > On Thu, Feb 6, 2025 at 8:20 AM Thomas Weißschuh
> > > wrote:
> > > >
> > > > On Fri, Jan 17, 2025 at 02:35:18PM -0500
On Thu, Feb 6, 2025 at 10:28 AM Thomas Weißschuh
wrote:
>
> On Thu, Feb 06, 2025 at 09:38:59AM -0500, enh wrote:
> > On Thu, Feb 6, 2025 at 8:20 AM Thomas Weißschuh
> > wrote:
> > >
> > > On Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote:
> > > > On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu wrote:
On Thu, Feb 06, 2025 at 09:38:59AM -0500, enh wrote:
> On Thu, Feb 6, 2025 at 8:20 AM Thomas Weißschuh
> wrote:
> >
> > On Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote:
> > > On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu wrote:
> >
> >
> >
> > > > There are technical difficulties to seal vdso/vvar
On Thu, Feb 6, 2025 at 8:20 AM Thomas Weißschuh
wrote:
>
> On Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote:
> > On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu wrote:
>
>
>
> > > There are technical difficulties to seal vdso/vvar from the glibc
> > > side. The dynamic linker lacks vdso/vvar mapping
On Thu, Jan 23, 2025 at 5:38 PM Matthew Wilcox wrote:
[heh, long time no see! haven't been on an email thread with you in a
while :-) ]
> On Thu, Jan 23, 2025 at 04:50:46PM -0500, enh wrote:
> > yeah, at this point i should (a) drag in +cferris who may have actual
> > experience of this and (b)
On Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote:
> On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu wrote:
> > There are technical difficulties to seal vdso/vvar from the glibc
> > side. The dynamic linker lacks vdso/vvar mapping size information, and
> > architectural variations for vdso/vvar also
On Fri, 2025-01-03 at 15:48 -0500, Liam R. Howlett wrote:
>
> So we have at least two userspace uses that this will breaks: checkpoint
> restore and now gVisor, but who knows what else?
I believe we previously pointed out it might also break running the
ARCH=um kernel:
https://lore.kernel.org/al
On Thu, Jan 23, 2025 at 04:50:46PM -0500, enh wrote:
> yeah, at this point i should (a) drag in +cferris who may have actual
> experience of this and (b) admit that iirc i've never personally seen
> _evidence_ of this, just claims. most famously in the chrome source...
> if you `grep -r /proc/.*/ma
On Thu, Jan 23, 2025 at 3:40 AM Vlastimil Babka wrote:
>
> On 1/22/25 23:29, enh wrote:
> > On Wed, Jan 22, 2025 at 12:24 PM Liam R. Howlett
> > wrote:
> >>
> >>
> >> We are making changes in this area. Can you elaborate on the 'awkward'
> >> part? The locking or the tearing of data?
> >>
> >>
On 1/22/25 23:29, enh wrote:
> On Wed, Jan 22, 2025 at 12:24 PM Liam R. Howlett
> wrote:
>>
>>
>> We are making changes in this area. Can you elaborate on the 'awkward'
>> part? The locking or the tearing of data?
>>
>> The way you state the page, it makes me think it's the tearing that is
>> th
On Wed, Jan 22, 2025 at 12:24 PM Liam R. Howlett
wrote:
>
> * enh [250121 10:38]:
> > On Fri, Jan 17, 2025 at 5:08 PM Liam R. Howlett
> > wrote:
> > >
> > > * enh [250117 14:35]:
> > > ...
> > >
> > > >
> > > > as a maintainer of a different linux libc, i've long wanted a "tell me
> > > > ever
* enh [250121 10:38]:
> On Fri, Jan 17, 2025 at 5:08 PM Liam R. Howlett
> wrote:
> >
> > * enh [250117 14:35]:
> > ...
> >
> > >
> > > as a maintainer of a different linux libc, i've long wanted a "tell me
> > > everything there is to know about this vma" syscall rather than having
> > > to par
On Fri, Jan 17, 2025 at 5:08 PM Liam R. Howlett wrote:
>
> * enh [250117 14:35]:
> ...
>
> >
> > as a maintainer of a different linux libc, i've long wanted a "tell me
> > everything there is to know about this vma" syscall rather than having
> > to parse /proc/maps...
> >
>
> You mean an ioctl()
* enh [250117 14:35]:
...
>
> as a maintainer of a different linux libc, i've long wanted a "tell me
> everything there is to know about this vma" syscall rather than having
> to parse /proc/maps...
>
You mean an ioctl()-based API to query VMAs from /proc//maps?
Andrii had something like that
On Fri, Jan 17, 2025 at 11:35 AM enh wrote:
>
> On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu wrote:
> >
> > On Thu, Jan 16, 2025 at 9:18 AM Pedro Falcato
> > wrote:
> > >
> > > On Thu, Jan 16, 2025 at 5:02 PM Benjamin Berg
> > > wrote:
> > > >
> > > > Hi Lorenzo,
> > > >
> > > > On Thu, 2025-01-16
On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu wrote:
>
> On Thu, Jan 16, 2025 at 9:18 AM Pedro Falcato wrote:
> >
> > On Thu, Jan 16, 2025 at 5:02 PM Benjamin Berg
> > wrote:
> > >
> > > Hi Lorenzo,
> > >
> > > On Thu, 2025-01-16 at 15:48 +, Lorenzo Stoakes wrote:
> > > > On Wed, Jan 15, 2025 at
On Thu, Jan 16, 2025 at 9:18 AM Pedro Falcato wrote:
>
> On Thu, Jan 16, 2025 at 5:02 PM Benjamin Berg
> wrote:
> >
> > Hi Lorenzo,
> >
> > On Thu, 2025-01-16 at 15:48 +, Lorenzo Stoakes wrote:
> > > On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote:
> > > > On Wed, Jan 15, 2025 at 11:
On Thu, Jan 16, 2025 at 7:49 AM Lorenzo Stoakes
wrote:
>
> On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote:
> > Hi Lorenzo
> >
> > On Wed, Jan 15, 2025 at 11:46 AM Lorenzo Stoakes
> > wrote:
> > >
> > > Jeff,
> > >
> > > My name is Lorenzo, not Lorenze.
> > >
> > I apologize.
>
> No worri
Hi Kees,
On Thu, Jan 16, 2025 at 11:40:37AM -0800, Kees Cook wrote:
> On Thu, Jan 16, 2025 at 06:26:55AM +0100, Christoph Hellwig wrote:
> > On Wed, Jan 15, 2025 at 03:52:23PM -0800, Kees Cook wrote:
> > > > You seem to be saying you're pushing an internal feature on upstream and
> > > > only care
On Thu, Jan 16, 2025 at 03:34:40PM +, Lorenzo Stoakes wrote:
> This was originally addressed with config flags, but then boot options were
> provided which completely overrode this.
> [...]
> Again, I have no objection to a version of this series which explicitly
> disallows known-broken scenar
On Thu, Jan 16, 2025 at 06:26:55AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 15, 2025 at 03:52:23PM -0800, Kees Cook wrote:
> > > You seem to be saying you're pushing an internal feature on upstream and
> > > only care about internal use cases, this is not how upstream works, as
> > > Matthew a
On Thu, Jan 16, 2025 at 5:02 PM Benjamin Berg wrote:
>
> Hi Lorenzo,
>
> On Thu, 2025-01-16 at 15:48 +, Lorenzo Stoakes wrote:
> > On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote:
> > > On Wed, Jan 15, 2025 at 11:46 AM Lorenzo Stoakes
> > > wrote:
> >
> > [SNIP]
> > >
> > > > I've mad
On Thu, Jan 16, 2025 at 06:01:47PM +0100, Benjamin Berg wrote:
> Hi Lorenzo,
>
> On Thu, 2025-01-16 at 15:48 +, Lorenzo Stoakes wrote:
> > On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote:
> > > On Wed, Jan 15, 2025 at 11:46 AM Lorenzo Stoakes
> > > wrote:
> >
> > [SNIP]
> > >
> > > > I
Hi Lorenzo,
On Thu, 2025-01-16 at 15:48 +, Lorenzo Stoakes wrote:
> On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote:
> > On Wed, Jan 15, 2025 at 11:46 AM Lorenzo Stoakes
> > wrote:
>
> [SNIP]
> >
> > > I've made it abundantly clear that this (NACKed) series cannot allow the
> > > ke
On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote:
> Hi Lorenzo
>
> On Wed, Jan 15, 2025 at 11:46 AM Lorenzo Stoakes
> wrote:
> >
> > Jeff,
> >
> > My name is Lorenzo, not Lorenze.
> >
> I apologize.
No worries, sorry I realise it was probably a typo! But just in case you
didn't realise :P
Kees,
I reply inline below but the TL;DR is - I'm fine with an incremental
approach, my requirements for arch support are sensible and doable and I'll
_give a R-b tag_ if such a version is submitted. :)
This isn't a discreet means of me trying to reject the whole idea, if I
felt that way I'd just
On Wed, Jan 15, 2025 at 03:52:23PM -0800, Kees Cook wrote:
> > You seem to be saying you're pushing an internal feature on upstream and
> > only care about internal use cases, this is not how upstream works, as
> > Matthew alludes to.
>
> Internal? No. Chrome OS and Android. Linux runs more Androi
On Wed, Jan 15, 2025 at 07:46:00PM +, Lorenzo Stoakes wrote:
> You are now suggesting disabling the !CRIU requirement. Which violates my
> _requirements_ (not optional features).
Why not make this simply incremental? The feature isn't intended to work
with CRIU. Why don't we get the feature in
Hi Lorenzo
On Wed, Jan 15, 2025 at 11:46 AM Lorenzo Stoakes
wrote:
>
> Jeff,
>
> My name is Lorenzo, not Lorenze.
>
I apologize.
> I've made it abundantly clear that this (NACKed) series cannot allow the
> kernel to be in a broken state even if a user sets flags to do so.
>
> This is because use
Jeff,
My name is Lorenzo, not Lorenze.
I've made it abundantly clear that this (NACKed) series cannot allow the
kernel to be in a broken state even if a user sets flags to do so.
This is because users might lack context to make this decision and
incorrectly do so, and now we ship a known-broken
On Mon, Jan 13, 2025 at 1:26 PM Jeff Xu wrote:
>
> On Mon, Jan 6, 2025 at 5:12 PM Kees Cook wrote:
> >
> > On Fri, Jan 03, 2025 at 09:38:10PM +, Lorenzo Stoakes wrote:
> > > On Tue, Dec 17, 2024 at 02:18:53PM -0800, Kees Cook wrote:
> > > > On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chr
On Mon, Jan 13, 2025 at 01:26:59PM -0800, Jeff Xu wrote:
> This patch is intended for ChromeOS and Android and is
> feature-complete from their perspective.
"I have everything I need from the Google point of view, so I will push
this feature into upstream".
No, thanks.
On Mon, Jan 6, 2025 at 5:12 PM Kees Cook wrote:
>
> On Fri, Jan 03, 2025 at 09:38:10PM +, Lorenzo Stoakes wrote:
> > On Tue, Dec 17, 2024 at 02:18:53PM -0800, Kees Cook wrote:
> > > On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > > > Seal vdso, vvar, sigpage, uprobes a
On Fri, Jan 03, 2025 at 03:48:23PM -0500, Liam R. Howlett wrote:
> So we have at least two userspace uses that this will breaks: checkpoint
> restore and now gVisor, but who knows what else? How many config
> options before we decide this can't be just on by default?
See my reply to Lorenzo, but
On Fri, Jan 03, 2025 at 09:38:10PM +, Lorenzo Stoakes wrote:
> On Tue, Dec 17, 2024 at 02:18:53PM -0800, Kees Cook wrote:
> > On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> > >
> > > Those mappings are readonly or exe
On Tue, Dec 17, 2024 at 02:18:53PM -0800, Kees Cook wrote:
> On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> >
> > Those mappings are readonly or executable only, sealing can protect
> > them from ever changing or unmapped d
* Kees Cook [241217 17:19]:
> On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> >
> > Those mappings are readonly or executable only, sealing can protect
> > them from ever changing or unmapped during the life time of the pr
On Tue, Dec 17, 2024 at 2:18 PM Kees Cook wrote:
>
> Also from discussions it sounds like there may need to be even finer-gain
> control, likely via prctl, for dealing with the CRIU case. The proposal
> is to provide an opt-out prctl with CAP_CHECKPOINT_RESTORE? I think this
> is reasonable a
On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped during the life time of the process.
> For complete descriptions of m
Hi Liam
On Mon, Dec 16, 2024 at 10:56 AM Liam R. Howlett
wrote:
>
> * Jeff Xu [241216 13:35]:
>
> ...
>
> > >
> > > I like the idea and I think the opt-out solution should work for CRIU.
> > > CRIU will be able to call this prctl and re-execute itself.
> > >
> > Great! Let's iterate on the opt-o
Hi Andrei
On Thu, Dec 12, 2024 at 10:33 PM Andrei Vagin wrote:
>
> On Wed, Dec 11, 2024 at 2:47 PM Jeff Xu wrote:
> >
> > Hi Andrei
> >
> > Thanks for your email.
> > I was hoping to get some feedback from CRIU devs, and happy to see you
> > reaching out..
> >
> ...
> > I have been thinking of o
* Jeff Xu [241216 13:35]:
...
> >
> > I like the idea and I think the opt-out solution should work for CRIU.
> > CRIU will be able to call this prctl and re-execute itself.
> >
> Great! Let's iterate on the opt-out solution then.
>
This patch set has been NACK'ed.
Please rework your solution
On Wed, Dec 11, 2024 at 2:47 PM Jeff Xu wrote:
>
> Hi Andrei
>
> Thanks for your email.
> I was hoping to get some feedback from CRIU devs, and happy to see you
> reaching out..
>
...
> I have been thinking of other alternatives, but those would require
> more understanding on CRIU use cases.
> On
Hi Andrei
Thanks for your email.
I was hoping to get some feedback from CRIU devs, and happy to see you
reaching out..
On Mon, Dec 9, 2024 at 8:12 PM Andrei Vagin wrote:
>
> On Mon, Nov 25, 2024 at 12:49 PM wrote:
> >
> > From: Jeff Xu
> >
> > Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
On Mon, Nov 25, 2024 at 12:49 PM wrote:
>
> From: Jeff Xu
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped during the life time of the process.
> For complete descriptions of memory se
On Wed, Dec 4, 2024 at 6:04 AM Benjamin Berg wrote:
>
> Hi,
>
> On Mon, 2024-11-25 at 20:20 +, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> >
> > Those mappings are readonly or executable only, sealing can protect
> > them from ever ch
Hi,
On Wed, 2024-12-04 at 09:43 -0800, Jeff Xu wrote:
> On Wed, Dec 4, 2024 at 6:04 AM Benjamin Berg
> wrote:
> > On Mon, 2024-11-25 at 20:20 +, jef...@chromium.org wrote:
> > > From: Jeff Xu
> > >
> > > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> > >
> > > Those mappings are readon
Hi,
On Mon, 2024-11-25 at 20:20 +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped during the life time of the process.
> For complete
NACK.
Unfortunately past experience indicates that engaging in a back-and-forth
is not productive.
Please re-read what I've said and properly address the very serious
concerns raised.
This series is unacceptable in its current form as it allows untested
architectures and known broken configurati
On Mon, Dec 2, 2024 at 11:35 PM Lorenzo Stoakes
wrote:
>
> On Mon, Dec 02, 2024 at 12:38:27PM -0800, Jeff Xu wrote:
> > On Mon, Dec 2, 2024 at 10:29 AM Lorenzo Stoakes
> > wrote:
> > >
> > > On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > > > From: Jeff Xu
> > > >
> > >
On Mon, Dec 02, 2024 at 12:38:27PM -0800, Jeff Xu wrote:
> On Mon, Dec 2, 2024 at 10:29 AM Lorenzo Stoakes
> wrote:
> >
> > On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > > From: Jeff Xu
> > >
> > > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> > >
> > > Those mappin
On Mon, Nov 25, 2024 at 12:40 PM Matthew Wilcox wrote:
>
> On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > +/*
> > + * Kernel cmdline override for CONFIG_SEAL_SYSTEM_MAPPINGS
> > + */
> > +enum seal_system_mappings_type {
> > + SEAL_SYSTEM_MAPPINGS_DISABLED,
> > +
On Mon, Dec 2, 2024 at 10:29 AM Lorenzo Stoakes
wrote:
>
> On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> >
> > Those mappings are readonly or executable only, sealing can protect
> > them from ever
On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped during the life time of the process.
> For complete
On Mon, Dec 2, 2024 at 9:57 AM Lorenzo Stoakes
wrote:
>
> On Mon, Dec 02, 2024 at 09:22:33AM -0800, Jeff Xu wrote:
> > On Mon, Nov 25, 2024 at 12:40 PM Matthew Wilcox wrote:
> > >
> > > On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > > > +/*
> > > > + * Kernel cmdline ove
On Mon, Dec 2, 2024 at 9:22 AM Jeff Xu wrote:
>
> On Mon, Nov 25, 2024 at 12:40 PM Matthew Wilcox wrote:
> >
> > On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > > +/*
> > > + * Kernel cmdline override for CONFIG_SEAL_SYSTEM_MAPPINGS
> > > + */
> > > +enum seal_system_mapp
On Mon, Dec 02, 2024 at 09:22:33AM -0800, Jeff Xu wrote:
> On Mon, Nov 25, 2024 at 12:40 PM Matthew Wilcox wrote:
> >
> > On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > > +/*
> > > + * Kernel cmdline override for CONFIG_SEAL_SYSTEM_MAPPINGS
> > > + */
> > > +enum seal_sys
On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> +/*
> + * Kernel cmdline override for CONFIG_SEAL_SYSTEM_MAPPINGS
> + */
> +enum seal_system_mappings_type {
> + SEAL_SYSTEM_MAPPINGS_DISABLED,
> + SEAL_SYSTEM_MAPPINGS_ENABLED
> +};
> +
> +static enum seal_system_mappin
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing or unmapped during the life time of the process.
For complete descriptions of memory sealing, please see mseal.rst [1].
System mappings such
59 matches
Mail list logo
