[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHa2GOE7T+NQ=pgo_zXjtnCRHQ1i6OJnC2vY_SbUx_EYKCQ8wQ@mail.gmail.com>
Date: Thu, 3 May 2012 12:05:15 +0800
From: Eugene Teo <eugeneteo@...il.com>
To: Solar Designer <solar@...nwall.com>
Cc: owl-dev@...ts.openwall.com, Petr Matousek <pmatouse@...hat.com>
Subject: Re: [GSoC] featues to port
Late reply, lots of holidays here recently.
> > Global steps could be:
> > * moving Owl to RHEL6/OpenVZ-based kernel from RHEL5/OpenVZ-based.
> > This includes bug fixing, patching userspace, etc.
> > * pushing some enhancements to upstream kernel.
> > * pushing more simple and not disputable enhancements to RHEL6.
> > * backporting accepted enhancements from upstream kernel to RHEL6/OpenVZ.
> > * forwardport old but not accepted by upstream enhancements from PaX/Owl
> kernels.
> >
> > Only 3 or 4 of enhancements are ready for RHEL6 inclusion - HARDEN_PROC,
> > HARDEN_RLIMIT_NPROC, HARDEN_SHM, and probably HARDEN_LINK. If we want
> > to push anything more, it probably should be discussed in the near time.
> > I'd want to push at least PAX_USERCOPY feature to the upstream and then
> > to RHEL6.
>
> I'd like to hear from the Red Hat folks on this. I think at least the
> BINFMT_ELF_AOUT cleanup may be acceptable for RHEL6 as well and without
> requiring a discussion on LKML first.
>
Vasiliy, Al Viro is usually very very busy. Who else would be good at
looking at this patch? It has to be committed in the upstream kernel before
we can accept patches for them. I understand that the policy may be
different from other competitors, but we believe in making sure that the
community gets it first before we do. Any experimental changes has to be
committed upstream first.
> > I see 2 rough ways to go:
> >
> > 1) - discuss and try to push already accepted features to RHEL6.
> > - move Owl to RHEL6 kernel.
> > - backport/forwardport features to Owl kernel.
> >
> > 2) the same, but +discuss features marked above as DISCUSS on LKML.
> >
> > As last summer showed, the most of time was taken by discussions and
> > disputes on LKML, a bit less was taken by porting GrSecurity/PaX
> > features with stuctural changes. Actual _backporting_ is much faster.
> > So, I think (1) will be fully implemented in less than a summer. LKML
> > discussions could be an "idle" task.
> >
> > The cons are that moving the LKML discussion to the idle state might
> > move actual RHEL6 porting to the Jul/Aug and not finishing it during the
> > summer.
>
> I think that LKML discussions are naturally an idle task, and I don't
> see how treating them as such makes anything slower. You do need to
> stay on top of issues brought to LKML, but you also have plenty of time
> to proceed with getting stuff into our actual kernels in parallel.
> Indeed, it is possible that you'd end up revising some of the patches
> for upstream acceptance, but if so you'll be able to get those newer
> revisions into Owl as well. If upstream acceptance is required for
> getting the patches into RHEL6, then those changes will have to wait for
> such acceptance anyway. You can't have stuff accepted upstream
> instantly even if you make this your highest priority.
>
Do you have the source rpm for the most recent kernel? I think we should be
able to get hold of the srpm for you but not the git tree unfortunately. If
necessary, feel free to ping Petr, and he should be able to get you some
information. I think that you can start filing bugs in bugzilla.redhat.com,
and backport the ones that are OK.
Eugene
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
