On Sat 2014-01-18 12:26:20, Borislav Petkov wrote:
> On Sat, Jan 18, 2014 at 12:08:29PM +0100, Pavel Machek wrote:
> > ?? By the time userspace is booted, you have overwritten the MSR, and
> > information, if the BIOS is buggy, was lost.
>
> Bullshit - if you don't apply the workaround, the bit in
On Sat, Jan 18, 2014 at 12:08:29PM +0100, Pavel Machek wrote:
> ?? By the time userspace is booted, you have overwritten the MSR, and
> information, if the BIOS is buggy, was lost.
Bullshit - if you don't apply the workaround, the bit in the MSR remains
unset.
Drop this senseless conversation and
On Sat 2014-01-18 11:42:31, Borislav Petkov wrote:
> On Sat, Jan 18, 2014 at 03:01:55AM +0100, Pavel Machek wrote:
> > I'd say that proposed "your bios has a bug"
>
> You can always unconditionally print "your bios has a bug". Just like
> that. Without even looking.
Yeah, and we have linux-firmwa
On Sat, Jan 18, 2014 at 03:01:55AM +0100, Pavel Machek wrote:
> I'd say that proposed "your bios has a bug"
You can always unconditionally print "your bios has a bug". Just like
that. Without even looking.
So no, I don't think adding a warning for this one case makes sense.
If you want to add a
On Fri 2014-01-17 17:21:00, H. Peter Anvin wrote:
> On 01/17/2014 04:29 PM, Pavel Machek wrote:
> >
> > Have you checked your dmesg recently? Normal people don't read
> > it... it is just too much of it.
> >
> >> Printing a warning is appropriate if we can't actually fix the problem
> >> in the O
On 01/17/2014 04:29 PM, Pavel Machek wrote:
>
> Have you checked your dmesg recently? Normal people don't read
> it... it is just too much of it.
>
>> Printing a warning is appropriate if we can't actually fix the problem
>> in the OS. If we actually make the problem go away then we have just
>>
On Fri 2014-01-17 14:51:52, H. Peter Anvin wrote:
> On 01/17/2014 02:50 PM, Borislav Petkov wrote:
> > On Fri, Jan 17, 2014 at 11:28:06PM +0100, Pavel Machek wrote:
> >> Would it make sense to printk() a warning?
> >
> > No because people come and start bitching about their dmesg containing
> > a
On Fri, Jan 17, 2014 at 02:51:52PM -0800, H. Peter Anvin wrote:
> Printing a warning is appropriate if we can't actually fix the problem
> in the OS. If we actually make the problem go away then we have just
> done our job and we can be done with it.
And we do make it go away so no warning and a g
On 01/17/2014 02:50 PM, Borislav Petkov wrote:
> On Fri, Jan 17, 2014 at 11:28:06PM +0100, Pavel Machek wrote:
>> Would it make sense to printk() a warning?
>
> No because people come and start bitching about their dmesg containing
> a warning and whether their hardware is b0rked without even read
On Fri, Jan 17, 2014 at 11:28:06PM +0100, Pavel Machek wrote:
> Would it make sense to printk() a warning?
No because people come and start bitching about their dmesg containing
a warning and whether their hardware is b0rked without even reading the
actual words.
> BIOS is clearly buggy in this c
On Tue 2014-01-14 17:27:23, Borislav Petkov wrote:
> From: Borislav Petkov
>
> This adds the workaround for erratum 793 as a precaution in case not
> every BIOS implements it. This addresses CVE-2013-6885.
>
> Signed-off-by: Borislav Petkov
> ---
> arch/x86/kernel/cpu/amd.c | 11 +++
>
On Fri, Jan 17, 2014 at 12:05:37PM -0600, Aravind Gopalakrishnan wrote:
> On 1/17/2014 11:42 AM, H. Peter Anvin wrote:
> >
> >Hence the question: did an unfixed BIOS ever make it into a shipping
> >production system? Because if it did, we do have a coverage hole.
> >
> Right, and the answer to you
On 1/17/2014 11:42 AM, H. Peter Anvin wrote:
Hence the question: did an unfixed BIOS ever make it into a shipping
production system? Because if it did, we do have a coverage hole.
-hpa
Right, and the answer to your question is: there is a *chance* it did..
From internal discussions
On 01/17/2014 09:02 AM, Borislav Petkov wrote:
>
> No, you don't. :-)
>
> You would much prefer to have the workaround done in the BIOS and only
> if there's a coverage hole, only then to do it in the kernel.
>
Hence the question: did an unfixed BIOS ever make it into a shipping
production syst
On 1/17/2014 11:02 AM, Borislav Petkov wrote:
On Fri, Jan 17, 2014 at 08:23:24AM -0800, H. Peter Anvin wrote:
Actually I by and large disagree with that. There is a limit, of
course, but when it comes to flipping an MSR in init code, the bar is
pretty darn low. We have quirks for all kind of har
On Fri, Jan 17, 2014 at 08:23:24AM -0800, H. Peter Anvin wrote:
> Actually I by and large disagree with that. There is a limit, of
> course, but when it comes to flipping an MSR in init code, the bar is
> pretty darn low. We have quirks for all kind of hardware, and this is
> just another example.
On 01/17/2014 02:18 AM, Borislav Petkov wrote:
>
> We also cannot carry *every* erratum workaround in the kernel just
> because people don't update firmware. Firmware is becoming ubiquitous,
> sadly, and because of that, admins should provision for firmware
> upgrades too.
>
> Besides, *even* if
On Thu, Jan 16, 2014 at 10:21:24PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 16 Jan 2014, Aravind Gopalakrishnan wrote:
> > We might want to still have a software fix for this just in case
> > someone uses older BIOSes..
>
> There is no "just in case" when it comes to someone using outda
On 01/16/2014 04:21 PM, Henrique de Moraes Holschuh wrote:
> On Thu, 16 Jan 2014, Aravind Gopalakrishnan wrote:
>> We might want to still have a software fix for this just in case
>> someone uses older BIOSes..
>
> There is no "just in case" when it comes to someone using outdated firmware.
> It i
On Thu, 16 Jan 2014, Aravind Gopalakrishnan wrote:
> We might want to still have a software fix for this just in case
> someone uses older BIOSes..
There is no "just in case" when it comes to someone using outdated firmware.
It is a *given*, except for hardware that is only used in HPC and multipl
On Thu, Jan 16, 2014 at 11:58:13AM -0600, Aravind Gopalakrishnan wrote:
> We might want to still have a software fix for this just in case
> someone uses older BIOSes..
Are you saying there are F16h BIOSes out there which might not have the
fix?
Also, for PCI config space fixes, take a look at
ar
On 1/14/2014 2:38 PM, Borislav Petkov wrote:
Before you go and do that, just ask internally whether those
workarounds are being delivered with AGESA instead. We don't want to
have a fix in the kernel for *every* erratum if it can be helped.
We're making an exception for this one because it can
On Tue, Jan 14, 2014 at 02:15:08PM -0600, Aravind Gopalakrishnan wrote:
> Scrubbing the RevGuide for Fam16, I found couple more Errata that need
> workarounds:
Before you go and do that, just ask internally whether those workarounds
are being delivered with AGESA instead. We don't want to have a f
On 01/14/2014 08:42 AM, Borislav Petkov wrote:
> On Tue, Jan 14, 2014 at 08:30:31AM -0800, H. Peter Anvin wrote:
>> Please put MSR_AMD_LS_CFG in msr-index.h or at least at the top of the
>> file,
>
> Yeah, can we agree on some kind of a rule for msr-index.h? Something
> like the rule for pci.h, fo
On Tue, Jan 14, 2014 at 08:30:31AM -0800, H. Peter Anvin wrote:
> Please put MSR_AMD_LS_CFG in msr-index.h or at least at the top of the
> file,
Yeah, can we agree on some kind of a rule for msr-index.h? Something
like the rule for pci.h, for example?
My only wish is to have all the MSRs at one p
On 01/14/2014 08:27 AM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> This adds the workaround for erratum 793 as a precaution in case not
> every BIOS implements it. This addresses CVE-2013-6885.
>
> Signed-off-by: Borislav Petkov
> +
> +#define MSR_AMD_LS_CFG 0xc0011020
> + /*
From: Borislav Petkov
This adds the workaround for erratum 793 as a precaution in case not
every BIOS implements it. This addresses CVE-2013-6885.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/amd.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/cpu/a
27 matches
Mail list logo
