On Thu, Oct 29, 2020 at 11:02:22AM +, Catalin Marinas via Libc-alpha wrote:
> On Tue, Oct 27, 2020 at 02:15:22PM +, Dave P Martin wrote:
> > I also wonder whether we actually care whether the pages are marked
> > executable or not here; probably the flags can just be independent. This
> >
On Tue, Oct 27, 2020 at 02:15:22PM +, Dave P Martin wrote:
> I also wonder whether we actually care whether the pages are marked
> executable or not here; probably the flags can just be independent. This
> rather depends on whether the how the architecture treats the BTI (a.k.a
> GP)
On Mon, Oct 26, 2020 at 05:39:42PM -0500, Jeremy Linton via Libc-alpha wrote:
> Hi,
>
> On 10/26/20 12:52 PM, Dave Martin wrote:
> >On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
> >>The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
> >>>Unrolling this
* Dave Martin via Libc-alpha:
> On Mon, Oct 26, 2020 at 05:45:42PM +0100, Florian Weimer via Libc-alpha wrote:
>> * Dave Martin via Libc-alpha:
>>
>> > Would it now help to add something like:
>> >
>> > int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
>> > {
>> >int ret
On Mon, Oct 26, 2020 at 05:45:42PM +0100, Florian Weimer via Libc-alpha wrote:
> * Dave Martin via Libc-alpha:
>
> > Would it now help to add something like:
> >
> > int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
> > {
> > int ret = -EINVAL;
> >
Hi,
On 10/26/20 12:52 PM, Dave Martin wrote:
On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
Unrolling this discussion a bit, this problem comes from a few sources:
1) systemd is trying to implement a
On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
> The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
> > Unrolling this discussion a bit, this problem comes from a few sources:
> >
> > 1) systemd is trying to implement a policy that doesn't fit SECCOMP
> >
The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
> Unrolling this discussion a bit, this problem comes from a few sources:
>
> 1) systemd is trying to implement a policy that doesn't fit SECCOMP
> syscall filtering very well.
>
> 2) The program is trying to do something not expressible
On Mon, Oct 26, 2020 at 03:56:35PM +, Dave Martin wrote:
> On Mon, Oct 26, 2020 at 02:52:46PM +, Catalin Marinas via Libc-alpha
> wrote:
> > Now, if the dynamic loader silently ignores the mprotect() failure on
> > the main executable, is there much value in exposing a flag in the aux
>
* Dave Martin via Libc-alpha:
> Would it now help to add something like:
>
> int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
> {
> int ret = -EINVAL;
> mmap_write_lock(current->mm);
> if (all vmas in [addr .. addr + len) have
> their
On 26.10.2020 18.24, Dave Martin wrote:
On Wed, Oct 21, 2020 at 10:44:46PM -0500, Jeremy Linton via Libc-alpha wrote:
Hi,
There is a problem with glibc+systemd on BTI enabled systems. Systemd
has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
PROT_EXEC changes. Glibc
On 26.10.2020 16.52, Catalin Marinas wrote:
On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote:
On 23.10.2020 12.02, Catalin Marinas wrote:
On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
Regardless, it makes sense to me to have the kernel load the executable
itself
On Wed, Oct 21, 2020 at 10:44:46PM -0500, Jeremy Linton via Libc-alpha wrote:
> Hi,
>
> There is a problem with glibc+systemd on BTI enabled systems. Systemd
> has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
> PROT_EXEC changes. Glibc enables BTI only on segments which are
On Mon, Oct 26, 2020 at 02:52:46PM +, Catalin Marinas via Libc-alpha wrote:
> On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote:
> > On 23.10.2020 12.02, Catalin Marinas wrote:
> > > On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
> > > > Regardless, it makes sense to
On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote:
> On 23.10.2020 12.02, Catalin Marinas wrote:
> > On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
> > > Regardless, it makes sense to me to have the kernel load the executable
> > > itself with BTI enabled by default. I
On Saturday, October 24, 2020 2:12 PM, Salvatore Mesoraca
wrote:
> On Sat, 24 Oct 2020 at 12:34, Topi Miettinen toiwo...@gmail.com wrote:
>
> > On 23.10.2020 20.52, Salvatore Mesoraca wrote:
> >
> > > Hi,
> > > On Thu, 22 Oct 2020 at 23:24, Topi Miettinen toiwo...@gmail.com wrote:
> > >
> > > >
On Sat, 24 Oct 2020 at 12:34, Topi Miettinen wrote:
>
> On 23.10.2020 20.52, Salvatore Mesoraca wrote:
> > Hi,
> >
> > On Thu, 22 Oct 2020 at 23:24, Topi Miettinen wrote:
> >> SARA looks interesting. What is missing is a prctl() to enable all W^X
> >> protections irrevocably for the current
On 23.10.2020 20.52, Salvatore Mesoraca wrote:
Hi,
On Thu, 22 Oct 2020 at 23:24, Topi Miettinen wrote:
SARA looks interesting. What is missing is a prctl() to enable all W^X
protections irrevocably for the current process, then systemd could
enable it for services with
On 23.10.2020 12.02, Catalin Marinas wrote:
On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
Regardless, it makes sense to me to have the kernel load the executable
itself with BTI enabled by default. I prefer gaining Catalin's suggested
patch[2]. :)
[...]
[2]
Hi,
On Thu, 22 Oct 2020 at 23:24, Topi Miettinen wrote:
> SARA looks interesting. What is missing is a prctl() to enable all W^X
> protections irrevocably for the current process, then systemd could
> enable it for services with MemoryDenyWriteExecute=yes.
SARA actually has a procattr[0]
On Fri, Oct 23, 2020 at 07:13:17AM +0100, Szabolcs Nagy wrote:
> The 10/22/2020 10:31, Catalin Marinas wrote:
> > IIUC, the problem is with the main executable which is mapped by the
> > kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but
> > does not have the original file
On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
> Regardless, it makes sense to me to have the kernel load the executable
> itself with BTI enabled by default. I prefer gaining Catalin's suggested
> patch[2]. :)
[...]
> [2]
The 10/22/2020 10:31, Catalin Marinas wrote:
> IIUC, the problem is with the main executable which is mapped by the
> kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but
> does not have the original file descriptor to be able to remap. Its only
> choice is mprotect() and this
On 22.10.2020 23.02, Kees Cook wrote:
On Thu, Oct 22, 2020 at 01:39:07PM +0300, Topi Miettinen wrote:
But I think SELinux has a more complete solution (execmem) which can track
the pages better than is possible with seccomp solution which has a very
narrow field of view. Maybe this facility
On Thu, Oct 22, 2020 at 01:39:07PM +0300, Topi Miettinen wrote:
> But I think SELinux has a more complete solution (execmem) which can track
> the pages better than is possible with seccomp solution which has a very
> narrow field of view. Maybe this facility could be made available to
>
On 22.10.2020 10.54, Szabolcs Nagy wrote:
The 10/21/2020 22:44, Jeremy Linton wrote:
There is a problem with glibc+systemd on BTI enabled systems. Systemd
has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
PROT_EXEC changes. Glibc enables BTI only on segments which are
* Topi Miettinen:
> Allowing mprotect(PROT_EXEC|PROT_BTI) would mean that all you need to
> circumvent MDWX is to add PROT_BTI flag. I'd suggest getting the flags
> right at mmap() time or failing that, reverting the PROT_BTI for
> legacy programs later.
>
> Could the kernel tell the loader of
On 22.10.2020 12.31, Catalin Marinas wrote:
On Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote:
On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.n...@arm.com) wrote:
The dynamic loader has to process the LOAD segments to get to the ELF
note that says to enable BTI. Maybe we
On 22.10.2020 11.29, Szabolcs Nagy wrote:
The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote:
On 22.10.2020 10.54, Florian Weimer wrote:
* Lennart Poettering:
Did you see Topi's comments on the systemd issue?
https://github.com/systemd/systemd/issues/17368#issuecomment-710485532
I
On Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote:
> On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.n...@arm.com) wrote:
> > > > The dynamic loader has to process the LOAD segments to get to the ELF
> > > > note that says to enable BTI. Maybe we could do a first pass and load
> >
On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.n...@arm.com) wrote:
> > > The dynamic loader has to process the LOAD segments to get to the ELF
> > > note that says to enable BTI. Maybe we could do a first pass and load
> > > only the segments that cover notes. But that requires lots of changes
On Do, 22.10.20 09:05, Szabolcs Nagy (szabolcs.n...@arm.com) wrote:
> > > Various changes have been suggested, replacing the mprotect with mmap
> > > calls
> > > having PROT_BTI set on the original mapping, re-mmapping the segments,
> > > implying PROT_EXEC on mprotect PROT_BTI calls when
The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote:
> On 22.10.2020 10.54, Florian Weimer wrote:
> > * Lennart Poettering:
> > > Did you see Topi's comments on the systemd issue?
> > >
> > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532
> > >
> > > I think I agree
* Topi Miettinen:
>> The dynamic loader has to process the LOAD segments to get to the ELF
>> note that says to enable BTI. Maybe we could do a first pass and
>> load only the segments that cover notes. But that requires lots of
>> changes to generic code in the loader.
>
> What if the loader
On 22.10.2020 10.54, Florian Weimer wrote:
* Lennart Poettering:
On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote:
Hi,
There is a problem with glibc+systemd on BTI enabled systems. Systemd
has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
PROT_EXEC
The 10/22/2020 09:18, Lennart Poettering wrote:
> On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote:
>
> > Hi,
> >
> > There is a problem with glibc+systemd on BTI enabled systems. Systemd
> > has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
> > PROT_EXEC
* Lennart Poettering:
> On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote:
>
>> Hi,
>>
>> There is a problem with glibc+systemd on BTI enabled systems. Systemd
>> has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
>> PROT_EXEC changes. Glibc enables BTI only
On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote:
> Hi,
>
> There is a problem with glibc+systemd on BTI enabled systems. Systemd
> has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
> PROT_EXEC changes. Glibc enables BTI only on segments which are marked as
38 matches
Mail list logo
