linux-kernel - Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

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:	Fri, 10 Aug 2007 01:03:22 +0000
From:	"Dan Merillat" <dan.merillat@...il.com>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	"Andrea Arcangeli" <andrea@...e.de>,
	"Eric Sandeen" <sandeen@...deen.net>,
	"Satyam Sharma" <satyam.sharma@...il.com>,
	"Matt Mackall" <mpm@...enic.com>,
	"Rene Herman" <rene.herman@...il.com>,
	"Ray Lee" <ray-lk@...rabbit.org>, "Bodo Eggert" <7eggert@....de>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Jesper Juhl" <jesper.juhl@...il.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"William Lee Irwin III" <wli@...omorphy.com>,
	"David Chinner" <dgc@....com>,
	"Arjan van de Ven" <arjan@...radead.org>,
	"Denis Vlasenko" <vda.linux@...glemail.com>
Subject: Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

On 8/1/07, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> On Wed, 1 Aug 2007 15:33:58 +0200
> Andrea Arcangeli <andrea@...e.de> wrote:
> > Tweaking kernel ptes is prohibitive during clone() because that's
> > kernel memory and it would require a flush tlb all with IPIs that
> > won't scale (IPIs are really the blocker)
>
> Agreed - except when doing debug work then its an acceptable cost. You
> still have to sort the debug side out because you are going to fault the
> kernel stack which will probably then cause a triple fault and reboot on
> the spot.

I was assuming debugging work, yes.  I was also thinking it wouldn't
be done at clone() time, but mapped (on a single CPU) at the time of a
context switch.  It would eliminate IPI, but would probably make the
rest of the TLB handling much too ugly to contemplate.    As an
alternative, could the TLB flush and associated IPI be deferred until
the process migrates?   First migration would trigger flush/IPI,
further migration would be as now, no?   I'd happily run it with
various dm/md layers underneath

On 8/1/07, Denis Vlasenko <vda.linux@...glemail.com> wrote:
> Hmm, neat. Why do you need to _allocate second page_ at all?
> Just mark it "not present"...

Because the kernel mapping covers all physical memory contiguously, so
if the page isn't allocated, it could be used by a kernel data
structure you need to access.  Same reason the kernel stack has to be
contiguous pages.   Well, for non-highmem at least.  Either way, you
don't want to mark an in-use page as inaccessable, you never know
what's under there.
-
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/