lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 19 Aug 2019 09:31:43 +0200 (CEST)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
cc:     Joe Lawrence <joe.lawrence@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        live-patching@...r.kernel.org,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch
 modules

On Mon, 19 Aug 2019, Masahiro Yamada wrote:

> On Fri, Aug 16, 2019 at 9:43 PM Joe Lawrence <joe.lawrence@...hat.com> wrote:
> >
> > On 8/16/19 4:19 AM, Miroslav Benes wrote:
> > > Hi,
> > >
> > >> I cleaned up the build system, and pushed it based on my
> > >> kbuild tree.
> > >>
> > >> Please see:
> > >>
> > >> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
> > >> klp-cleanup
> > >
> > > This indeed looks much simpler and cleaner (as far as I can judge with my
> > > limited kbuild knowledge). We just need to remove MODULE_INFO(livepatch,
> > > "Y") from lib/livepatch/test_klp_convert_mod_a.c to make it compile and
> > > work (test_klp_convert_mod_a is not a livepatch module, it is just a dummy
> > > module which is then livepatched by lib/livepatch/test_klp_convert1.c).
> > >
> >
> > Yeah, Masahiro this is great, thanks for reworking this!
> >
> > I did tweak one module like Miroslav mentioned and I think a few of the
> > newly generated files need to be cleaned up as part of "make clean", but
> > all said, this is a nice improvement.
> >
> > Are you targeting the next merge window for your kbuild branch?  (This
> > appears to be what the klp-cleanup branch was based on.)
> 
> 
> I can review this series from the build system point of view,
> but I am not familiar enough with live-patching itself.
> 
> Some possibilities:
> 
> [1] Merge this series thru the live-patch tree after the
>     kbuild base patches land.
>     This requires one extra development cycle (targeting for 5.5-rc1)
>     but I think this is the official way if you do not rush into it.

I'd prefer this option. There is no real rush and I think we can wait one 
extra development cycle.

Joe, could you submit one more revision with all the recent changes (once 
kbuild improvements settle down), please? We should take a look at the 
whole thing one more time? What do you think?
 
> [2] Create an immutable branch in kbuild tree, and the live-patch
>     tree will use it as the basis for queuing this series.
>     We will have to coordinate the pull request order, but
>     we can merge this feature for 5.4-rc1
> 
> [3] Apply this series to my kbuild tree, with proper Acked-by
>     from the livepatch maintainers.
>     I am a little bit uncomfortable with applying patches I
>     do not understand, though...

Thanks
Miroslav

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ