svn commit: r362769 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux

[Shawn Webb]

On Mon, Jun 29, 2020 at 12:42:49PM -0500, Kyle Evans wrote:
> On Mon, Jun 29, 2020 at 10:27 AM Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
> >
> > Hey Kyle,
> >
> > On Mon, Jun 29, 2020 at 03:09:14AM +0000, Kyle Evans wrote:
> > > Author: kevans
> > > Date: Mon Jun 29 03:09:14 2020
> > > New Revision: 362769
> > > URL: https://svnweb.freebsd.org/changeset/base/362769
> > >
> > > Log:
> > >   linuxolator: implement memfd_create syscall
> > >
> > >   This effectively mirrors our libc implementation, but with minor fudging --
> > >   name needs to be copied in from userspace, so we just copy it straight into
> > >   stack-allocated memfd_name into the correct position rather than allocating
> > >   memory that needs to be cleaned up.
> > >
> > >   The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have
> > >   also been implemented now that we support them.
> > >
> > >   Note that this implementation is still not quite at feature parity w.r.t.
> > >   the actual Linux version; some caveats, from my foggy memory:
> > >
> > >   - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress)
> > >   - LTP wants the memfd name exposed to fdescfs
> > >   - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after dup.
> > >     (?)
> > >
> > >   Interested parties can install and run LTP from ports (devel/linux-ltp) to
> > >   confirm any fixes.
> > >
> > >   PR:         240874
> > >   Reviewed by:        kib, trasz
> > >   Differential Revision:      https://reviews.freebsd.org/D21845
> >
> > RELNOTES?
> >
> > >
> > > Modified:
> > >   head/sys/amd64/linux/linux_dummy.c
> > >   head/sys/amd64/linux32/linux32_dummy.c
> > >   head/sys/arm64/linux/linux_dummy.c
> > >   head/sys/compat/linux/linux.c
> > >   head/sys/compat/linux/linux.h
> > >   head/sys/compat/linux/linux_file.c
> > >   head/sys/compat/linux/linux_file.h
> > >   head/sys/i386/linux/linux_dummy.c
> >
> > Should __FreeBSD_version be bumped?
> >
> 
> I'm roping in trasz@, because I'm unsure on either of these points --
> I haven't paid attention and don't know if we typically include linux
> syscalls that we implement in relnotes, and given that this commit
> only really affects pre-compiled Linux binaries I'm not sure if
> there's any utility in bumping __FreeBSD_version; presumably ports
> folks can't do anything differently here, and binaries will work just
> the same.

Hey Kyle,

I assumed as much, but I wasn't entirely sure. I thought I'd just ask
anyways. Thanks for the clarification. :)

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:          0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20200629/207b967d/attachment.sig>