On Tue, Jan 14, 2025 at 3:41 PM Jeff Xu wrote:
>
> On Tue, Jan 14, 2025 at 2:42 PM Isaac Manjarres
> wrote:
> >
> > On Tue, Jan 14, 2025 at 01:29:44PM -0800, Kees Cook wrote:
> > > On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote:
>
> > Alternatively, MFD_NOEXEC_SEAL could be exten
On Tue, Jan 14, 2025 at 2:42 PM Isaac Manjarres
wrote:
>
> On Tue, Jan 14, 2025 at 01:29:44PM -0800, Kees Cook wrote:
> > On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote:
> Alternatively, MFD_NOEXEC_SEAL could be extended
> to prevent executable mappings, and MEMFD_NOEXEC_SCOPE_NO
On Tue, Jan 14, 2025 at 01:29:44PM -0800, Kees Cook wrote:
> On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote:
> > I think the main issue in the threat model that I described is that
> > an attacking process can gain control of a more priveleged process.
>
> I understood it to be ab
On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote:
> I think the main issue in the threat model that I described is that
> an attacking process can gain control of a more priveleged process.
I understood it to be about an attacker gaining execution control through
a rewritten functio
On Thu, Jan 09, 2025 at 03:30:36PM -0800, Jeff Xu wrote:
> On Wed, Jan 8, 2025 at 11:06 AM Lorenzo Stoakes
> wrote:
> >
> > On Mon, Jan 06, 2025 at 04:44:33PM -0800, Kees Cook wrote:
> > > On Mon, Jan 06, 2025 at 10:26:27AM -0800, Jeff Xu wrote:
> > > > + Kees because this is related to W^X memfd
On Wed, Jan 8, 2025 at 11:06 AM Lorenzo Stoakes
wrote:
>
> On Mon, Jan 06, 2025 at 04:44:33PM -0800, Kees Cook wrote:
> > On Mon, Jan 06, 2025 at 10:26:27AM -0800, Jeff Xu wrote:
> > > + Kees because this is related to W^X memfd and security.
> > >
> > > On Fri, Jan 3, 2025 at 7:14 AM Jann Horn w
On Wed, Jan 08, 2025 at 07:06:13PM +, Lorenzo Stoakes wrote:
> On Mon, Jan 06, 2025 at 04:44:33PM -0800, Kees Cook wrote:
> > On Mon, Jan 06, 2025 at 10:26:27AM -0800, Jeff Xu wrote:
> > > + Kees because this is related to W^X memfd and security.
> > >
> > > On Fri, Jan 3, 2025 at 7:14 AM Jann
On Mon, Jan 06, 2025 at 04:44:33PM -0800, Kees Cook wrote:
> On Mon, Jan 06, 2025 at 10:26:27AM -0800, Jeff Xu wrote:
> > + Kees because this is related to W^X memfd and security.
> >
> > On Fri, Jan 3, 2025 at 7:14 AM Jann Horn wrote:
> > >
> > > On Fri, Dec 6, 2024 at 7:19 PM Lorenzo Stoakes
> >
On Mon, Jan 06, 2025 at 10:26:27AM -0800, Jeff Xu wrote:
> + Kees because this is related to W^X memfd and security.
>
> On Fri, Jan 3, 2025 at 7:14 AM Jann Horn wrote:
> >
> > On Fri, Dec 6, 2024 at 7:19 PM Lorenzo Stoakes
> > wrote:
> > > On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manj
+ Kees because this is related to W^X memfd and security.
On Fri, Jan 3, 2025 at 7:14 AM Jann Horn wrote:
>
> On Fri, Dec 6, 2024 at 7:19 PM Lorenzo Stoakes
> wrote:
> > On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote:
> > > + if (is_exec_sealed(seals)) {
> >
> > A
On Fri, Dec 6, 2024 at 7:19 PM Lorenzo Stoakes
wrote:
> On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote:
> > + if (is_exec_sealed(seals)) {
>
> Are we intentionally disallowing a MAP_PRIVATE memfd's mapping's execution?
> I've not tested this scenario so don't know i
On Fri, Dec 06, 2024 at 09:14:58PM +, Lorenzo Stoakes wrote:
> On Fri, Dec 06, 2024 at 12:48:09PM -0800, Isaac Manjarres wrote:
> > On Fri, Dec 06, 2024 at 06:19:49PM +, Lorenzo Stoakes wrote:
> > > On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote:
> > > > diff --git a/mm/
On Fri, Dec 06, 2024 at 12:48:09PM -0800, Isaac Manjarres wrote:
> On Fri, Dec 06, 2024 at 06:19:49PM +, Lorenzo Stoakes wrote:
> > On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote:
> > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > index b1b2a24ef82e..c7b96b057fda 100644
> > > --
On Fri, Dec 06, 2024 at 09:49:35AM -0800, Kalesh Singh wrote:
> On Thu, Dec 5, 2024 at 5:09 PM Isaac J. Manjarres
> wrote:
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -375,6 +375,17 @@ unsigned long do_mmap(struct file *file, unsigned long
> > addr,
> > if (!file_mmap_ok(file,
On Fri, Dec 06, 2024 at 06:19:49PM +, Lorenzo Stoakes wrote:
> On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote:
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index b1b2a24ef82e..c7b96b057fda 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -375,6 +375,17 @@ unsigned long do
On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote:
> Android currently uses the ashmem driver [1] for creating shared memory
> regions between processes. Ashmem buffers can initially be mapped with
> PROT_READ, PROT_WRITE, and PROT_EXEC. Processes can then use the
> ASHMEM_SET_PROT
On Thu, Dec 5, 2024 at 5:09 PM Isaac J. Manjarres
wrote:
>
> Android currently uses the ashmem driver [1] for creating shared memory
> regions between processes. Ashmem buffers can initially be mapped with
> PROT_READ, PROT_WRITE, and PROT_EXEC. Processes can then use the
> ASHMEM_SET_PROT_MASK io
Android currently uses the ashmem driver [1] for creating shared memory
regions between processes. Ashmem buffers can initially be mapped with
PROT_READ, PROT_WRITE, and PROT_EXEC. Processes can then use the
ASHMEM_SET_PROT_MASK ioctl command to restrict--never add--the
permissions that the buffer
18 matches
Mail list logo
