linux-kernel - Re: [patch 05/10] Linux Kernel Markers

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:	Thu, 10 May 2007 17:28:43 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Andi Kleen <ak@....de>, systemtap@...rces.redhat.com,
	prasanna@...ibm.com, ananth@...ibm.com,
	anil.s.keshavamurthy@...el.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, hch@...radead.org
Subject: Re: [patch 05/10] Linux Kernel Markers - i386 optimized version

> * First issue : Impact on the system. If we try to make this system
>   scale, we will create very long irq disable sections. The expected
>   duration is the worse case IPI latency plus the time it takes to CPU A
>   to change the variable. We therefore directly grow the worse case
>   system's interrupt latency.

Not a huge problem. It doesn't scale in really horrible ways and the IPI
latency on a PIV or later is actually very good. Also the impact is less
than you might think as on huge huge boxes you want multiple copies of
the kernel text pages to reduce NUMA traffic, so you only have to sync
the group of processors involved 

> * Second issue : irq disabling does not protect us from NMI and traps.
>   We cannot use this algorithm to mark these code segments.

If you synchronize all the other processors and disable local interrupts
then the only traps you have to worry about are those you cause, and the
only person taking the trap will be you so you're ok.

NMI is hard but NMI is a special case not worth solving IMHO.

> * Third issue : Scalability. Changing code will stop every CPU on the
>   system for a while. Compared to this, the int3-based approach will run
>   through the breakpoint handler "if" one of the CPU happens to execute
>   this code at the wrong time. The standard case is just an IPI (to

If I read the errata right then patching in an int3 will itself trigger
the errata so anything could happen.

I believe there are other safe sequences for doing code patching - perhaps
one of the Intel folk can advise ?

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