Re: AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?
On Tue, Jan 14, 2014 at 07:14:48AM -0800, H. Peter Anvin wrote: > Seriously, though, if this MSR can be set at runtime without problems > (which covers 98% of all workarounds, but not 100%) then it seems > like a no-brainer to just do it as long as the offending CPUs can be > identified by the kernel. Yeah, ok, let me cook it up. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?
On 01/14/2014 03:55 AM, Borislav Petkov wrote: > On Tue, Jan 14, 2014 at 09:41:33AM -0200, Henrique de Moraes Holschuh wrote: >> I just got this assigned to amd64-microcode in Debian, but it is something >> that needs to be worked around by the EFI/BIOS and/or the kernel. >> >> Since we all know just how well it pans out to depend on BIOS/EFI updates >> for *anything*, I'm raising the issue here. IMHO looks like it would be >> worthwhile to either set the relevant MSR in the kernel if the BIOS didn't >> do it, or at least warn the user of the need for a BIOS/EFI update... >> >> It is the usual hangs-core type of CPU errata (therefore, the best type >> since it won't cause silent data corruption). gcc-produced code managed to >> trigger it (in DragonFly BSD). > > I think this is a different issue than the dragonfly issue. In any case, > if AMD delivers all BIOS with this workaround enabled, we don't need to > do anything. And I asked them about it so we'll have an answer soon, I > hope. > > In any case, I'm on it. > Seriously, though, if this MSR can be set at runtime without problems (which covers 98% of all workarounds, but not 100%) then it seems like a no-brainer to just do it as long as the offending CPUs can be identified by the kernel. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?
On Tue, Jan 14, 2014 at 09:41:33AM -0200, Henrique de Moraes Holschuh wrote: > I just got this assigned to amd64-microcode in Debian, but it is something > that needs to be worked around by the EFI/BIOS and/or the kernel. > > Since we all know just how well it pans out to depend on BIOS/EFI updates > for *anything*, I'm raising the issue here. IMHO looks like it would be > worthwhile to either set the relevant MSR in the kernel if the BIOS didn't > do it, or at least warn the user of the need for a BIOS/EFI update... > > It is the usual hangs-core type of CPU errata (therefore, the best type > since it won't cause silent data corruption). gcc-produced code managed to > trigger it (in DragonFly BSD). I think this is a different issue than the dragonfly issue. In any case, if AMD delivers all BIOS with this workaround enabled, we don't need to do anything. And I asked them about it so we'll have an answer soon, I hope. In any case, I'm on it. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?
I just got this assigned to amd64-microcode in Debian, but it is something that needs to be worked around by the EFI/BIOS and/or the kernel. Since we all know just how well it pans out to depend on BIOS/EFI updates for *anything*, I'm raising the issue here. IMHO looks like it would be worthwhile to either set the relevant MSR in the kernel if the BIOS didn't do it, or at least warn the user of the need for a BIOS/EFI update... It is the usual hangs-core type of CPU errata (therefore, the best type since it won't cause silent data corruption). gcc-produced code managed to trigger it (in DragonFly BSD). A quick search under arch/x86 did not locate any existing workaround for this issue. Date: Wed, 27 Nov 2013 21:23:37 -0500 (EST) From: cve-ass...@...re.org To: oss-secur...@...ts.openwall.com Cc: cve-ass...@...re.org Subject: CVE-2013-6885 AMD Publ. 51810 Errata 793 system hang The person who requested CVE-2013-6885 asked that we send the CVE assignment here because various open-source software will probably be adding code to prevent this denial of service attack. http://support.amd.com/TechDocs/51810_16h_00h-0Fh_Rev_Guide.pdf http://lists.dragonflybsd.org/pipermail/kernel/2011-December/046594.html http://www.zdnet.com/blog/hardware/amd-owns-up-to-cpu-bug/18924 793 Specific Combination of Writes to Write Combined Memory Types and Locked Instructions May Cause Core Hang Under a highly specific and detailed set of internal timing conditions, a locked instruction may trigger a timing sequence whereby the write to a write combined memory type is not flushed, causing the locked instruction to stall indefinitely. Potential Effect on System Processor core hang. Suggested Workaround BIOS should set MSRC001_1020[15] = 1b. No fix planned - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?
I just got this assigned to amd64-microcode in Debian, but it is something that needs to be worked around by the EFI/BIOS and/or the kernel. Since we all know just how well it pans out to depend on BIOS/EFI updates for *anything*, I'm raising the issue here. IMHO looks like it would be worthwhile to either set the relevant MSR in the kernel if the BIOS didn't do it, or at least warn the user of the need for a BIOS/EFI update... It is the usual hangs-core type of CPU errata (therefore, the best type since it won't cause silent data corruption). gcc-produced code managed to trigger it (in DragonFly BSD). A quick search under arch/x86 did not locate any existing workaround for this issue. Date: Wed, 27 Nov 2013 21:23:37 -0500 (EST) From: cve-ass...@...re.org To: oss-secur...@...ts.openwall.com Cc: cve-ass...@...re.org Subject: CVE-2013-6885 AMD Publ. 51810 Errata 793 system hang The person who requested CVE-2013-6885 asked that we send the CVE assignment here because various open-source software will probably be adding code to prevent this denial of service attack. http://support.amd.com/TechDocs/51810_16h_00h-0Fh_Rev_Guide.pdf http://lists.dragonflybsd.org/pipermail/kernel/2011-December/046594.html http://www.zdnet.com/blog/hardware/amd-owns-up-to-cpu-bug/18924 793 Specific Combination of Writes to Write Combined Memory Types and Locked Instructions May Cause Core Hang Under a highly specific and detailed set of internal timing conditions, a locked instruction may trigger a timing sequence whereby the write to a write combined memory type is not flushed, causing the locked instruction to stall indefinitely. Potential Effect on System Processor core hang. Suggested Workaround BIOS should set MSRC001_1020[15] = 1b. No fix planned - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?
On Tue, Jan 14, 2014 at 09:41:33AM -0200, Henrique de Moraes Holschuh wrote: I just got this assigned to amd64-microcode in Debian, but it is something that needs to be worked around by the EFI/BIOS and/or the kernel. Since we all know just how well it pans out to depend on BIOS/EFI updates for *anything*, I'm raising the issue here. IMHO looks like it would be worthwhile to either set the relevant MSR in the kernel if the BIOS didn't do it, or at least warn the user of the need for a BIOS/EFI update... It is the usual hangs-core type of CPU errata (therefore, the best type since it won't cause silent data corruption). gcc-produced code managed to trigger it (in DragonFly BSD). I think this is a different issue than the dragonfly issue. In any case, if AMD delivers all BIOS with this workaround enabled, we don't need to do anything. And I asked them about it so we'll have an answer soon, I hope. In any case, I'm on it. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?
On 01/14/2014 03:55 AM, Borislav Petkov wrote: On Tue, Jan 14, 2014 at 09:41:33AM -0200, Henrique de Moraes Holschuh wrote: I just got this assigned to amd64-microcode in Debian, but it is something that needs to be worked around by the EFI/BIOS and/or the kernel. Since we all know just how well it pans out to depend on BIOS/EFI updates for *anything*, I'm raising the issue here. IMHO looks like it would be worthwhile to either set the relevant MSR in the kernel if the BIOS didn't do it, or at least warn the user of the need for a BIOS/EFI update... It is the usual hangs-core type of CPU errata (therefore, the best type since it won't cause silent data corruption). gcc-produced code managed to trigger it (in DragonFly BSD). I think this is a different issue than the dragonfly issue. In any case, if AMD delivers all BIOS with this workaround enabled, we don't need to do anything. And I asked them about it so we'll have an answer soon, I hope. In any case, I'm on it. Seriously, though, if this MSR can be set at runtime without problems (which covers 98% of all workarounds, but not 100%) then it seems like a no-brainer to just do it as long as the offending CPUs can be identified by the kernel. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?
On Tue, Jan 14, 2014 at 07:14:48AM -0800, H. Peter Anvin wrote: Seriously, though, if this MSR can be set at runtime without problems (which covers 98% of all workarounds, but not 100%) then it seems like a no-brainer to just do it as long as the offending CPUs can be identified by the kernel. Yeah, ok, let me cook it up. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
