This patch addresses CVE-2006-1056 (information leak from fxsave/fxrstor on AMD CPUs) and also adjusts 64-bit handling so that full 64-bit RIP/RDP values get saved/restored. More fine-grained handling may be needed if 32-bit processes are expected to properly see their selectors (native Linux doesn''t currently do that either, but there is a patch to adjust it there). Signed-off-by: Jan Beulich <jbeulich@novell.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 24 Apr 2006, at 16:31, Jan Beulich wrote:> This patch addresses CVE-2006-1056 (information leak from > fxsave/fxrstor on AMD CPUs) and also adjusts 64-bit handling > so that full 64-bit RIP/RDP values get saved/restored. More > fine-grained handling may be needed if 32-bit processes are > expected to properly see their selectors (native Linux doesn''t > currently do that either, but there is a patch to adjust > it there).Why does this patch (and the one in Linux 2.6.16.9) use ''emms'' in the fxsave path rather than ''ffree st(7)'' which is what AMD recommends in their published advisory? Is the former faster? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:> On 24 Apr 2006, at 16:31, Jan Beulich wrote: > > > This patch addresses CVE-2006-1056 (information leak from > > fxsave/fxrstor on AMD CPUs) and also adjusts 64-bit handling > > so that full 64-bit RIP/RDP values get saved/restored. More > > fine-grained handling may be needed if 32-bit processes are > > expected to properly see their selectors (native Linux doesn''t > > currently do that either, but there is a patch to adjust > > it there). > > Why does this patch (and the one in Linux 2.6.16.9) use ''emms'' in the > fxsave path rather than ''ffree st(7)'' which is what AMD recommends in > their published advisory? Is the former faster?On K7/K8 emms and ffree st(7) are the same performance. On P4 ffree is much faster. The Linux 2.6 patch uses emms because it patches the code in only on K7/K8. For the Xen patch that''s ok too although it checks, not patches. In Linux 2.4 where the code is executed unconditionally ffree is used. An earlier version of the AMD workaround used emms always until the P4 emms performance issue was discovered. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 24.04.06 18:14 >>> > >On 24 Apr 2006, at 16:31, Jan Beulich wrote: > >> This patch addresses CVE-2006-1056 (information leak from >> fxsave/fxrstor on AMD CPUs) and also adjusts 64-bit handling >> so that full 64-bit RIP/RDP values get saved/restored. More >> fine-grained handling may be needed if 32-bit processes are >> expected to properly see their selectors (native Linux doesn''t >> currently do that either, but there is a patch to adjust >> it there). > >Why does this patch (and the one in Linux 2.6.16.9) use ''emms'' in the >fxsave path rather than ''ffree st(7)'' which is what AMD recommends in >their published advisory? Is the former faster?I just cloned what Andi did for 32- and 64-bit Linux. Andi? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25 Apr 2006, at 01:56, Andi Kleen wrote:> On K7/K8 emms and ffree st(7) are the same performance. On P4 ffree is > much faster. The Linux 2.6 patch uses emms because it patches the code > in only on K7/K8. For the Xen patch that''s ok too although it checks, > not patches. In Linux 2.4 where the code is executed unconditionally > ffree is used. > > An earlier version of the AMD workaround used emms always until > the P4 emms performance issue was discovered.Thanks Andi. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel