linux-kernel - Re: kvm vmload/vmsave vs tss.ist

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, 25 Dec 2008 16:17:57 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Joerg Roedel <joerg.roedel@....com>,
	Benjamin Serebrin <benjamin.serebrin@....com>,
	linux-kernel <linux-kernel@...r.kernel.org>, kvm@...r.kernel.org,
	Alexander Graf <agraf@...e.de>
Subject: Re: kvm vmload/vmsave vs tss.ist

* Avi Kivity <avi@...hat.com> wrote:

> I would like to remove this limitation.  I see several ways to go about 
> it:
>
> 1. Drop the use of IST
>
> This would reduce the (perceived) reliability of the kernel and would 
> probably not be welcomed.

> hpa/Ingo, any opinions?

i think we should actually do #1 unconditionally.

ISTs are bad for the native kernel too. They have various nasty 
complications in the stack walker (and hence they _reduce_ reliability in 
practice), and they are non-preemptible as well. Plus we have the 
maximum-stack-footprint ftrace plugin now, which can remove any perception 
about how bad the worst-case stack footprint is in practice.

If it ever becomes an issue we could also soft-switch to a larger (per 
CPU) exception stack from the exception handlers themselves. The 
architectural stack footprint of the various critical exceptions are 
calculatable and low - so we could switch away and get almost the kind of 
separation that ISTs give. There's no deep reason to actually make use of 
hw switched ISTs.

So feel free to send a patch that just standardizes the critical 
exceptions to use the regular kernel stack. (I havent actually tried this 
but it should be relatively simple to implement. Roadblocks are possible.)

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