On Fri, Feb 2, 2024 at 8:46 PM Liam R. Howlett wrote:
>
> * Linus Torvalds [240202 18:36]:
> > On Fri, 2 Feb 2024 at 13:18, Liam R. Howlett
> > wrote:
> > >
> > > There will be a larger performance cost to checking up front without
> > > allowing the partial completion.
> >
> > I suspect that f
...
> IMO, UNIX API design has historically mostly been "play stupid games,
> win stupid prizes", which is e.g: why things like close(STDOUT_FILENO)
> work. If you close stdout (and don't dup/reopen something to stdout)
> and printf(), things will break, and you get to keep both pieces.
That is pr
* Linus Torvalds [240202 18:36]:
> On Fri, 2 Feb 2024 at 13:18, Liam R. Howlett wrote:
> >
> > There will be a larger performance cost to checking up front without
> > allowing the partial completion.
>
> I suspect that for mseal(), the only half-way common case will be
> sealing an area that is
On Fri, 2 Feb 2024 at 13:18, Liam R. Howlett wrote:
>
> There will be a larger performance cost to checking up front without
> allowing the partial completion.
I suspect that for mseal(), the only half-way common case will be
sealing an area that is entirely contained within one vma.
So the cost
On Fri, Feb 2, 2024 at 10:52 AM Pedro Falcato wrote:
>
> On Fri, Feb 2, 2024 at 5:59 PM Jeff Xu wrote:
> >
> > On Thu, Feb 1, 2024 at 9:00 PM Theo de Raadt wrote:
> > >
> > > Jeff Xu wrote:
> > >
> > > > Even without free.
> > > > I personally do not like the heap getting sealed like that.
> >
* Linus Torvalds [240202 15:37]:
> On Fri, 2 Feb 2024 at 11:32, Theo de Raadt wrote:
> >
> > Unix system calls must be atomic.
> >
> > They either return an error, and that is a promise they made no changes.
>
> That's actually not true, and never has been.
...
>
> In the specific case of mse
On Fri, Feb 2, 2024 at 9:05 AM Theo de Raadt wrote:
>
> Another interaction to consider is sigaltstack().
>
> In OpenBSD, sigaltstack() forces MAP_STACK onto the specified
> (pre-allocated) region, because on kernel-entry we require the "sp"
> register to point to a MAP_STACK region (this severely
On Fri, Feb 2, 2024 at 12:37 PM Linus Torvalds
wrote:
>
> On Fri, 2 Feb 2024 at 11:32, Theo de Raadt wrote:
> >
> > Unix system calls must be atomic.
> >
> > They either return an error, and that is a promise they made no changes.
>
> That's actually not true, and never has been.
>
> It's a good
On Fri, 2 Feb 2024 at 11:32, Theo de Raadt wrote:
>
> Unix system calls must be atomic.
>
> They either return an error, and that is a promise they made no changes.
That's actually not true, and never has been.
It's a good thing to aim for, but several errors means "some or all
may have been don
On Fri, Feb 2, 2024 at 11:21 AM Liam R. Howlett wrote:
>
> * Jeff Xu [240202 12:24]:
>
> ...
>
> > > Provide code that uses this feature.
>
> Please do this too :)
>
Yes. Will do.
> > >
> > > Provide benchmark results where you apply mseal to 1, 2, 4, 8, 16, and
> > > 32 VMAs.
> > >
> > I will
> What I'm more concerned about is what happens if you call mseal() on a
> range and it can mseal a portion. Like, what happens to the first vma
> in your test_seal_unmapped_middle case? I see it returns an error, but
> is the first VMA mseal()'ed? (no it's not, but test that)
That is correct, L
* Jeff Xu [240202 12:24]:
...
> > Provide code that uses this feature.
Please do this too :)
> >
> > Provide benchmark results where you apply mseal to 1, 2, 4, 8, 16, and
> > 32 VMAs.
> >
> I will prepare for the benchmark tests.
Thank you, please also include runs of calls that you are modi
On Fri, Feb 2, 2024 at 5:59 PM Jeff Xu wrote:
>
> On Thu, Feb 1, 2024 at 9:00 PM Theo de Raadt wrote:
> >
> > Jeff Xu wrote:
> >
> > > Even without free.
> > > I personally do not like the heap getting sealed like that.
> > >
> > > Component A.
> > > p=malloc(4096);
> > > writing something to p.
On Thu, Feb 1, 2024 at 9:00 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > Even without free.
> > I personally do not like the heap getting sealed like that.
> >
> > Component A.
> > p=malloc(4096);
> > writing something to p.
> >
> > Component B:
> > mprotect(p,4096, RO)
> > mseal(p,4096)
> >
On Fri, Feb 2, 2024 at 7:13 AM Liam R. Howlett wrote:
>
> * Jeff Xu [240201 22:15]:
> > On Thu, Feb 1, 2024 at 12:45 PM Liam R. Howlett
> > wrote:
> > >
> > > * Jeff Xu [240131 20:27]:
> > > > On Wed, Jan 31, 2024 at 11:34 AM Liam R. Howlett
> > > > wrote:
> > > > >
> > >
> > > Having to opt-
Another interaction to consider is sigaltstack().
In OpenBSD, sigaltstack() forces MAP_STACK onto the specified
(pre-allocated) region, because on kernel-entry we require the "sp"
register to point to a MAP_STACK region (this severely damages ROP pivot
methods). Linux does not have MAP_STACK enfo
On Thu, Feb 01, 2024 at 07:24:02PM -0800, Jeff Xu wrote:
> On Thu, Feb 1, 2024 at 5:06 PM Greg KH wrote:
> >
> > On Thu, Feb 01, 2024 at 03:24:40PM -0700, Theo de Raadt wrote:
> > > As an outsider, Linux development is really strange:
> > >
> > > Two sub-features are being pushed very hard, and th
* Jeff Xu [240201 22:15]:
> On Thu, Feb 1, 2024 at 12:45 PM Liam R. Howlett
> wrote:
> >
> > * Jeff Xu [240131 20:27]:
> > > On Wed, Jan 31, 2024 at 11:34 AM Liam R. Howlett
> > > wrote:
> > > >
> >
> > Having to opt-in to allowing mseal will probably not work well.
> I'm leaving the opt-in di
Jeff Xu wrote:
> Even without free.
> I personally do not like the heap getting sealed like that.
>
> Component A.
> p=malloc(4096);
> writing something to p.
>
> Component B:
> mprotect(p,4096, RO)
> mseal(p,4096)
>
> This will split the heap VMA, and prevent the heap from shrinking, if
> thi
On Thu, Feb 1, 2024 at 8:05 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > To me, the most important thing is to deliver a feature that's easy to
> > use and works well. I don't want users to mess things up, so if I'm
> > the one giving them the tools, I'm going to make sure they have all
> > t
Jeff Xu wrote:
> To me, the most important thing is to deliver a feature that's easy to
> use and works well. I don't want users to mess things up, so if I'm
> the one giving them the tools, I'm going to make sure they have all
> the information they need and that there are safeguards in place.
>
On Thu, Feb 1, 2024 at 7:29 PM Linus Torvalds
wrote:
>
> On Thu, 1 Feb 2024 at 19:24, Jeff Xu wrote:
> >
> > The patch Stephan developed was based on V1 of the patch, IIRC, which
> > is really ancient, and it is not based on MAP_SEALABLE, which is a
> > more recent development entirely from me.
>
On Thu, 1 Feb 2024 at 19:24, Jeff Xu wrote:
>
> The patch Stephan developed was based on V1 of the patch, IIRC, which
> is really ancient, and it is not based on MAP_SEALABLE, which is a
> more recent development entirely from me.
So the problem with this whole patch series from the very beginnin
On Thu, Feb 1, 2024 at 5:06 PM Greg KH wrote:
>
> On Thu, Feb 01, 2024 at 03:24:40PM -0700, Theo de Raadt wrote:
> > As an outsider, Linux development is really strange:
> >
> > Two sub-features are being pushed very hard, and the primary developer
> > doesn't have code which uses either of them.
On Thu, Feb 1, 2024 at 3:15 PM Linus Torvalds
wrote:
>
> On Thu, 1 Feb 2024 at 14:54, Theo de Raadt wrote:
> >
> > Linus, you are in for a shock when the proposal doesn't work for glibc
> > and all the applications!
>
> Heh. I've enjoyed seeing your argumentative style that made you so
> famous b
On Thu, Feb 1, 2024 at 12:45 PM Liam R. Howlett wrote:
>
> * Jeff Xu [240131 20:27]:
> > On Wed, Jan 31, 2024 at 11:34 AM Liam R. Howlett
> > wrote:
> > >
>
> Having to opt-in to allowing mseal will probably not work well.
I'm leaving the opt-in discussion in Linus's thread.
> Initial library m
On Thu, Feb 01, 2024 at 03:24:40PM -0700, Theo de Raadt wrote:
> As an outsider, Linux development is really strange:
>
> Two sub-features are being pushed very hard, and the primary developer
> doesn't have code which uses either of them. And once it goes in, it
> cannot be changed.
>
> It's ve
Linus Torvalds wrote:
> and using PROT_SEAL at mmap() time is similarly the same obvious
> notion of "map this, and then seal that mapping".
The usual way is:
ptr = mmap(NULL, len PROT_READ|PROT_WRITE, ...)
initialize region between ptr, ptr+len
mprotect(ptr, len, PROT_READ)
m
Linus Torvalds wrote:
> So yes, to my mind
>
> mprotect(addr, len, PROT_READ);
> mseal(addr, len, 0);
>
> should basically give identical results to
>
> mprotect(addr, len, PROT_READ | PROT_SEAL);
>
> and using PROT_SEAL at mmap() time is similarly the same obvious
> notion of "ma
On Thu, 1 Feb 2024 at 14:54, Theo de Raadt wrote:
>
> Linus, you are in for a shock when the proposal doesn't work for glibc
> and all the applications!
Heh. I've enjoyed seeing your argumentative style that made you so
famous back in the days. Maybe it's always been there, but I haven't
seen the
> To me, this means Linus is OK with the general signatures of the APIs.
Linus, you are in for a shock when the proposal doesn't work for glibc
and all the applications!
On Thu, Feb 1, 2024 at 12:45 PM Liam R. Howlett wrote:
> >
> > I would love to hear more from Linux developers on this.
>
> Linus said it was really important to get the semantics correct, but you
> took his (unfinished) list and kept going. I think there are some
> unanswered questions and that'
There is another problem with adding PROT_SEAL to the mprotect()
call.
What are the precise semantics?
If one reviews how mprotect() behaves, it is quickly clear that
it is very sloppy specification. We spent quite a bit of effort
making our manual page as clear as possible to the most it gauran
* Jeff Xu [240131 20:27]:
> On Wed, Jan 31, 2024 at 11:34 AM Liam R. Howlett
> wrote:
> >
> > Please add me to the Cc list of these patches.
> Ok.
> >
> > * jef...@chromium.org [240131 12:50]:
> > > From: Jeff Xu
> > >
> > > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> -Original Message-
> From: Theo de Raadt
> > I would love to hear more from Linux developers on this.
>
> I'm not sure you are capable of listening.
>
Theo,
It is possible to make your technical points, and even to express frustration
that it has
been difficult to get them across,
I'd like to propose a new flag to the Linux open() system call.
It is
O_DUPABLE
You mix it with other O_* flags to the open call, everyone is familiar
with this, it is very easy to use.
If the O_DUPABLE flag is set, the file descriptor may be cloned with
dup(), dup2() or similar call. If no
Jeff Xu wrote:
> I considered Theo's inputs from OpenBSD's perspective regarding the
> difference, and I wasn't convinced that Linux should remove these. In
> my view, those are two different kernels code, and the difference in
> Linux is not added without reasons (for MAP_SEALABLE, there is a no
On Wed, Jan 31, 2024 at 11:34 AM Liam R. Howlett
wrote:
>
> Please add me to the Cc list of these patches.
Ok.
>
> * jef...@chromium.org [240131 12:50]:
> > From: Jeff Xu
> >
> > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> > In a nutshell, mseal() protects the VMAs o
Please add me to the Cc list of these patches.
* jef...@chromium.org [240131 12:50]:
> From: Jeff Xu
>
> This patchset proposes a new mseal() syscall for the Linux kernel.
>
> In a nutshell, mseal() protects the VMAs of a given virtual memory
> range against modifications, such as changes to t
From: Jeff Xu
This patchset proposes a new mseal() syscall for the Linux kernel.
In a nutshell, mseal() protects the VMAs of a given virtual memory
range against modifications, such as changes to their permission bits.
Modern CPUs support memory permissions, such as the read/write (RW)
and no-e
40 matches
Mail list logo
