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]

Date:	Wed, 27 Nov 2013 15:15:21 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Andi Kleen <andi@...stfloor.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] Add a text_poke syscall v2

On Wed, Nov 27, 2013 at 2:53 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> If we are going to go down that route, I would like to see a list of
> patch sites, not just one with a "timeout" that won't get used.

Oh, I agree. The interface of the original patch was just inane/insane.

The timeout and the callback is pointless. The only thing the system
call should get as an argument is the address and the replacement
instruction.  So

  int text_poke(void *addr, const void *opcode, size_t len)

sounds fine to me. And it would do:
 - take some (possibly per-mm) mutex
 - write the one-byte int3
 - do the IPI
 - write the other bytes
 - do the IPI
 - do the first byte
 - release the (possibly per-mm) mutex

and then in the BP handler we'd just take the mutex, see if the first
byte of the exception is still int3, if it's not, just return silently
(because that means that we hit the race).

And I would seriously suggest just open-coding the above simple
sequence instead of trying to force-reuse the text_poke_bp() function
we already have. Because I think doing this on kernel code is
*very*different* (for irq reasons _and_ for IPI mask reasons).

Hmm? It doesn't sound too bad. And I really don't see the point of
some timeout handling or anything like that.

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