linux-kernel - Re: [RFC kgr on klp 0/9] kGraft on the top of KLP

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]

Message-ID: <alpine.LNX.2.00.1505050036440.17961@pobox.suse.cz>
Date:	Tue, 5 May 2015 00:48:22 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
cc:	Jiri Slaby <jslaby@...e.cz>, live-patching@...r.kernel.org,
	sjenning@...hat.com, vojtech@...e.cz, mingo@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC kgr on klp 0/9] kGraft on the top of KLP

On Mon, 4 May 2015, Josh Poimboeuf wrote:

> Why do we need multiple consistency models?

Well, I am pretty sure we need always at least two:

- the "immediate" one, where the code redirection flip is switched 
  unconditionally and immediately (i.e. exactly what we currently have in 
  Linus' tree); semantically applicable to many patches, but not all of 
  them

- something that fills the "but not all of them" gap above.


Both of the solutions that have been presnted so far have some drawbacks 
that need to be discussed further. To me, the "highlights" (in the 
"drawbacks" space) are:

- any method that is stack-checking-based basically means that we have to
  functionally 100% rely on stack unwinding correctness. We have never 
  done that before, and current stack unwinder is not ready for that 
  (Josh is working on improving that); plus it can cause the patching to 
  fail under certain circumstances

- the kGraft method is not (yet) able to patch kernel threads, and allows 
  for multiple instances of the patched functions to be running in 
  parallel (i.e. patch author needs to be aware of this constaint, and 
  write the code accordingly)

This is exactly why we are submitting the kGraft-on-klp patchset, so that 
we have concurrent implementations (sharing the same goal) to compare, and 
ultimately merge whatever the best possible outcome will be.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/