linux-kernel - Re: [PATCH] Add a text

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: <20131119184959.GE29695@two.firstfloor.org>
Date:	Tue, 19 Nov 2013 19:49:59 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] Add a text_poke syscall

> I think I would prefer an interface which took a list of patch points,
> or implemented only the aspects which are impossible to do in user space.

We already have all the code. Why not just use it?

Note I'm not adding any new mechanism, just exporting the existing one.
So the usual "do things in user space" arguments do not really
apply here.

Also this is subtle enough that there is definitely benefit from
having only a single canonical code that does it.

If we ever need any new errata workarounds for this they could be also
all done in a single central place.

> 
> All we really need in the kernel is the IPI broadcasts - the rest can be
> done in user space, including intercepting SIGTRAP.  For userspace it is
> probably the best to just put a thread to sleep until the patching is
> done, which can be done with a futex.

I'm not sure that's worth it. IPIs are reasonably fast (a few 1000s cycles).
Sleeping likely only becomes beneficial with much longer delays, like
ms. But if the IPIs start taking ms we have much more problems.

> One advantage with doing this in userspace is that the kernel doesn't
> have to be responsible avoiding holding a thread due to a slightly
> different SIGTRAP -- it will all come out after the signal handler is
> restored, anyway.

It's just some spinning, not a new task state. I don't think any
task states make sense here.

-Andi
--
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/