linux-kernel - Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task

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:	Sun, 22 Feb 2015 09:52:38 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Ingo Molnar <mingo@...nel.org>
cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Vojtech Pavlik <vojtech@...e.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add
 sched_task_call())

On Sat, 21 Feb 2015, Ingo Molnar wrote:

> > Plus a lot of processes would see EINTR, causing more havoc.
> 
> Parking threads safely in user mode does not require the propagation of 
> syscall interruption to user-space.

BTW how exactly do you envision this will work? Do I understand your 
proposal correctly that EINTR will be "handled" somewhere in the "live 
patching special signal handler" and then have the interrupted syscall 
restarted?

Even without EINTR propagation to userspace, this would make a lot of new 
syscall restarts that were not there before, and I am still to be 
convinced that this is something we are not going to cause a lot of new 
user-visible breakage with.

Yes, the breakage would be caused kernel bugs (I mostly envision drivers 
to be problematic in this area) that would be nice to have fixed, but the 
user experience that will come out of it will be just completely horrible.

Or did I misunderstand what you are really proposing?

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/