linux-kernel - Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

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] [day] [month] [year] [list]

Message-ID: <20161031225928.iqx332mu7xfyrywg@pd.tnic>
Date:   Mon, 31 Oct 2016 23:59:28 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     sonofagun@...nmailbox.org
Cc:     linux-kernel@...r.kernel.org, Nikos Barkas <levelwol@...il.com>
Subject: Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

On Mon, Oct 31, 2016 at 11:54:44PM +0200, sonofagun@...nmailbox.org wrote:
> No, will simply crash without running something special! If you get no
> issues then that is bad news. I get frequent and repeatable crashes. I
> forgot to mention that all those crashes occur at program launch. If the
> program launches, it does not crash. Unfortunately with Ubuntu it is not
> possible to keep oopses from the error report program.

Can't you enable crash dumps?

$ ulimit -c unlimited

That should reenable core dumping which can then be examined with gdb.
You could put the program executable and the core somewhere on the web
so that I can take a look...

In any case, I'd like to see what those crashes look like. Can you send
dmesg, does it even say something in dmesg related to those crashes?

> On the laptop we have a Debian installation, I will switch to it and
> get crash information there so that we figure out why it behaves that
> way. Besides that, I have some more tests to do but I am running out
> of ideas so I might not be able to help you more on it as my laptop
> appears to be really broken!

Maybe a hw issue? RAM broken, cooling failing...

> Poor performance might be the result here and not the cause of my
> issues. The 688 fix just makes the system respond better. As far as I
> am concerned, I do not wish any module options for turning on the fix.
> I would prefer to use DMI maching for this specific machine and thus
> having the fix automatically.

The problem with DMI strings is that then we have to always go and
update them. And that's always a PITA.

I'm just trying to avoid an unnecessary performance penalty to users
with the erratum workaround where the erratum itself didn't even occur
in the first place. Like in my case, for example. I've never had any
issues with that machine for the time I've been using it.

> All subsystems of the laptop appear to be good(RAM has been tested and
> the HDD has passed our test). There is a sound issue on the HDA but
> such issues are common on most laptops and will be dealt soon.

If by "tested" you mean, you ran memtest on it, memtest is notorious for
not always catching faulty DIMMs.

> > Is it a desktop system or a laptop?
> I got no reply on this question so I suppose you have a desktop.

Oh sorry, I must've missed that question. No, the Ontario I have is a
laptop, something like this one:

https://support.lenovo.com/de/en/documents/pd015763

x121e with an AMD CPU, I *think* it is E-350.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.