On Fri, Sep 06, 2019 at 02:51:01PM +0200, Miroslav Benes wrote:
>
> > > Now, I don't think that replacing .ko on disk is a good idea. We've
> > > already discussed it. It would lead to a maintenance/packaging problem,
> > > because you never know which version of the module is loaded in the
> >
On 9/6/19 1:51 PM, Miroslav Benes wrote:
Now, I don't think that replacing .ko on disk is a good idea. We've
already discussed it. It would lead to a maintenance/packaging problem,
because you never know which version of the module is loaded in the
system. The state space grows rather rapidly t
> > Now, I don't think that replacing .ko on disk is a good idea. We've
> > already discussed it. It would lead to a maintenance/packaging problem,
> > because you never know which version of the module is loaded in the
> > system. The state space grows rather rapidly there.
>
> What exactly
On Thu, Sep 05, 2019 at 03:52:59PM +0200, Petr Mladek wrote:
> On Thu 2019-09-05 08:15:02, Josh Poimboeuf wrote:
> > On Thu, Sep 05, 2019 at 08:08:32AM -0500, Josh Poimboeuf wrote:
> > > On Thu, Sep 05, 2019 at 01:09:55PM +0200, Petr Mladek wrote:
> > > > > I don't have a number, but it's very comm
On Thu 2019-09-05 08:15:02, Josh Poimboeuf wrote:
> On Thu, Sep 05, 2019 at 08:08:32AM -0500, Josh Poimboeuf wrote:
> > On Thu, Sep 05, 2019 at 01:09:55PM +0200, Petr Mladek wrote:
> > > > I don't have a number, but it's very common to patch a function which
> > > > uses jump labels or alternatives
On Thu, Sep 05, 2019 at 03:31:56PM +0200, Jiri Kosina wrote:
> On Thu, 5 Sep 2019, Josh Poimboeuf wrote:
>
> > > All the indirect jumps are turned into alternatives when retpolines
> > > are in place.
> >
> > Actually in C code those are done by the compiler as calls/jumps to
> > __x86_indirect_
On Thu, 5 Sep 2019, Josh Poimboeuf wrote:
> > All the indirect jumps are turned into alternatives when retpolines
> > are in place.
>
> Actually in C code those are done by the compiler as calls/jumps to
> __x86_indirect_thunk_*.
Sure, and the thunks do the redirection via JMP_NOSPEC / CALL_NOS
On Thu, Sep 05, 2019 at 01:19:06PM +0200, Jiri Kosina wrote:
> On Thu, 5 Sep 2019, Petr Mladek wrote:
>
> > > I don't have a number, but it's very common to patch a function which
> > > uses jump labels or alternatives.
> >
> > Really? My impression is that both alternatives and jump_labels
> >
On Thu, Sep 05, 2019 at 08:08:32AM -0500, Josh Poimboeuf wrote:
> On Thu, Sep 05, 2019 at 01:09:55PM +0200, Petr Mladek wrote:
> > > I don't have a number, but it's very common to patch a function which
> > > uses jump labels or alternatives.
> >
> > Really? My impression is that both alternatives
On Thu, Sep 05, 2019 at 01:09:55PM +0200, Petr Mladek wrote:
> > I don't have a number, but it's very common to patch a function which
> > uses jump labels or alternatives.
>
> Really? My impression is that both alternatives and jump_labels
> are used in hot paths. I would expect them mostly in co
On Thu, Sep 05, 2019 at 02:16:51PM +0200, Miroslav Benes wrote:
> > > > A full demo would require packaging up replacement .ko's with a
> > > > livepatch, as
> > > > well as "blacklisting" those deprecated .kos, etc. But that's all I
> > > > had time
> > > > to cook up last week before our holid
On Thu, 5 Sep 2019, Josh Poimboeuf wrote:
> On Thu, Sep 05, 2019 at 02:03:34PM +0200, Miroslav Benes wrote:
> > > > + I would like to better understand the scope of the current
> > > > problems. It is about modifying code in the livepatch that
> > > > depends on position of the related c
On Thu, Sep 05, 2019 at 02:03:34PM +0200, Miroslav Benes wrote:
> > > + I would like to better understand the scope of the current
> > > problems. It is about modifying code in the livepatch that
> > > depends on position of the related code:
> > >
> > > + relocations are rather cl
On Wed, 4 Sep 2019, Josh Poimboeuf wrote:
> On Tue, Sep 03, 2019 at 03:02:34PM +0200, Miroslav Benes wrote:
> > On Mon, 2 Sep 2019, Joe Lawrence wrote:
> >
> > > On 9/2/19 12:13 PM, Miroslav Benes wrote:
> > > >> I can easily foresee more problems like those in the future. Going
> > > >> forward
On Wed, 4 Sep 2019, Josh Poimboeuf wrote:
> On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote:
> > On Tue 2019-09-03 15:02:34, Miroslav Benes wrote:
> > > On Mon, 2 Sep 2019, Joe Lawrence wrote:
> > >
> > > > On 9/2/19 12:13 PM, Miroslav Benes wrote:
> > > > >> I can easily foresee more
[...]
> I wonder what is necessary for a productive discussion on Plumbers:
[...]
> + It might be useful to prepare overview of the existing proposals
> and agree on the positives and negatives. I am afraid that some
> of them might depend on the customer base and
> use cas
On 9/5/19 7:09 AM, Petr Mladek wrote:
On Wed 2019-09-04 21:50:55, Josh Poimboeuf wrote:
On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote:
I wonder what is necessary for a productive discussion on Plumbers:
+ Josh would like to see what code can get removed when late
handling
On Thu, 5 Sep 2019, Petr Mladek wrote:
> > I don't have a number, but it's very common to patch a function which
> > uses jump labels or alternatives.
>
> Really? My impression is that both alternatives and jump_labels
> are used in hot paths. I would expect them mostly in core code
> that is al
On Wed 2019-09-04 21:50:55, Josh Poimboeuf wrote:
> On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote:
> > I wonder what is necessary for a productive discussion on Plumbers:
> >
> > + Josh would like to see what code can get removed when late
> > handling of modules gets removed.
On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote:
> On Tue 2019-09-03 15:02:34, Miroslav Benes wrote:
> > On Mon, 2 Sep 2019, Joe Lawrence wrote:
> >
> > > On 9/2/19 12:13 PM, Miroslav Benes wrote:
> > > >> I can easily foresee more problems like those in the future. Going
> > > >> for
On Tue, Sep 03, 2019 at 03:02:34PM +0200, Miroslav Benes wrote:
> On Mon, 2 Sep 2019, Joe Lawrence wrote:
>
> > On 9/2/19 12:13 PM, Miroslav Benes wrote:
> > >> I can easily foresee more problems like those in the future. Going
> > >> forward we have to always keep track of which special sections
On 9/4/19 4:49 AM, Petr Mladek wrote:
On Tue 2019-09-03 15:02:34, Miroslav Benes wrote:
On Mon, 2 Sep 2019, Joe Lawrence wrote:
On 9/2/19 12:13 PM, Miroslav Benes wrote:
I can easily foresee more problems like those in the future. Going
forward we have to always keep track of which special s
On Tue 2019-09-03 15:02:34, Miroslav Benes wrote:
> On Mon, 2 Sep 2019, Joe Lawrence wrote:
>
> > On 9/2/19 12:13 PM, Miroslav Benes wrote:
> > >> I can easily foresee more problems like those in the future. Going
> > >> forward we have to always keep track of which special sections are
> > >> ne
On Mon, 2 Sep 2019, Joe Lawrence wrote:
> On 9/2/19 12:13 PM, Miroslav Benes wrote:
> >> I can easily foresee more problems like those in the future. Going
> >> forward we have to always keep track of which special sections are
> >> needed for which architectures. Those special sections can chan
On 9/2/19 12:13 PM, Miroslav Benes wrote:
I can easily foresee more problems like those in the future. Going
forward we have to always keep track of which special sections are
needed for which architectures. Those special sections can change over
time, or can simply be overlooked for a given ar
> I can easily foresee more problems like those in the future. Going
> forward we have to always keep track of which special sections are
> needed for which architectures. Those special sections can change over
> time, or can simply be overlooked for a given architecture. It's
> fragile.
Indeed
On Tue, Aug 27, 2019 at 11:05:51AM -0400, Joe Lawrence wrote:
> > Sure, it introduces risk. But we have to compare that risk (which only
> > affects rare edge cases) with the ones introduced by the late module
> > patching code. I get the feeling that "late module patching" introduces
> > risk to
On 8/26/19 10:54 AM, Josh Poimboeuf wrote:
On Fri, Aug 23, 2019 at 10:13:06AM +0200, Petr Mladek wrote:
On Thu 2019-08-22 17:36:49, Josh Poimboeuf wrote:
On Fri, Aug 16, 2019 at 11:46:08AM +0200, Petr Mladek wrote:
On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote:
On Wed, Aug 14, 2019 at 01:0
On Mon, Aug 26, 2019 at 03:44:21PM +0200, Nicolai Stange wrote:
> Josh Poimboeuf writes:
>
> > On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
> >> > Really, we should be going in the opposite direction, by creating module
> >> > dependencies, like all other kernel modules do, ens
On Fri, Aug 23, 2019 at 10:13:06AM +0200, Petr Mladek wrote:
> On Thu 2019-08-22 17:36:49, Josh Poimboeuf wrote:
> > On Fri, Aug 16, 2019 at 11:46:08AM +0200, Petr Mladek wrote:
> > > On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote:
> > > > On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes
Josh Poimboeuf writes:
> On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
>> > Really, we should be going in the opposite direction, by creating module
>> > dependencies, like all other kernel modules do, ensuring that a module
>> > is loaded *before* we patch it. That would also
On Thu 2019-08-22 17:36:49, Josh Poimboeuf wrote:
> On Fri, Aug 16, 2019 at 11:46:08AM +0200, Petr Mladek wrote:
> > On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote:
> > > On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
> > > > > Really, we should be going in the opposite direction
On Fri, Aug 16, 2019 at 11:46:08AM +0200, Petr Mladek wrote:
> On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote:
> > On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
> > > > Really, we should be going in the opposite direction, by creating module
> > > > dependencies, like all other
On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote:
> On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
> > > Really, we should be going in the opposite direction, by creating module
> > > dependencies, like all other kernel modules do, ensuring that a module
> > > is loaded *before* we
On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
> > Really, we should be going in the opposite direction, by creating module
> > dependencies, like all other kernel modules do, ensuring that a module
> > is loaded *before* we patch it. That would also eliminate this bug.
>
> Yes,
On Mon, 22 Jul 2019, Petr Mladek wrote:
> On Fri 2019-07-19 14:28:40, Miroslav Benes wrote:
> > Josh reported a bug:
> >
> > When the object to be patched is a module, and that module is
> > rmmod'ed and reloaded, it fails to load with:
> >
> > module: x86/modules: Skipping invalid relocat
On Sun, 28 Jul 2019, Josh Poimboeuf wrote:
> On Fri, Jul 19, 2019 at 02:28:40PM +0200, Miroslav Benes wrote:
> > Josh reported a bug:
> >
> > When the object to be patched is a module, and that module is
> > rmmod'ed and reloaded, it fails to load with:
> >
> > module: x86/modules: Skippin
On Fri, Jul 19, 2019 at 02:28:40PM +0200, Miroslav Benes wrote:
> Josh reported a bug:
>
> When the object to be patched is a module, and that module is
> rmmod'ed and reloaded, it fails to load with:
>
> module: x86/modules: Skipping invalid relocation target, existing value is
> nonzero
On Fri 2019-07-19 14:28:40, Miroslav Benes wrote:
> Josh reported a bug:
>
> When the object to be patched is a module, and that module is
> rmmod'ed and reloaded, it fails to load with:
>
> module: x86/modules: Skipping invalid relocation target, existing value is
> nonzero for type 2, lo
Josh reported a bug:
When the object to be patched is a module, and that module is
rmmod'ed and reloaded, it fails to load with:
module: x86/modules: Skipping invalid relocation target, existing value is
nonzero for type 2, loc ba0302e9, val a03e293c
livepatch: failed to
40 matches
Mail list logo
