Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Jun 2018 11:10:52 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] mlock2 and memfd_create

* Andrei Vagin <avagin@...il.com> [2018-06-21 17:16:03 -0700]:
> On Tue, Jun 19, 2018 at 10:43:14PM +0200, Szabolcs Nagy wrote:
> > +
> > +int mlock2(const void *addr, size_t len, unsigned flags)
> > +{
> > +	if (flags == 0)
> > +		return mlock(addr, len);
> > +	return syscall(SYS_mlock2, addr, len, flags);
> 
> I would prefer another way to support old kernels:
> 
> 	int ret;
> 
> 	ret = syscall(SYS_mlock2, addr, len, flags);
> 	if (ret == -1 && errno == ENOSYS && flags == 0)
> 		return mlock(addr, len);
> 	return ret;
> 
> This way works a bit slower on old kernels, but it doesn't have side
> effects if mlock2 is supported.
> 
> For example, the user can set seccomp rules, and he will not expect that
> the mlock syscall will be executed, when he calls mlock2() in a code.
> 

mlock2 is documented to be equivalent to mlock if flags==0,
the glibc logic is the same and seccomp (or whatever else
operating on the syscall layer) has to deal with mlock
anyway (unless we change the mlock implementation too).
so i would not be too worried about this.

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.