linux-kernel - Re: [PATCH v4 00/10] x86/microcode/AMD: Check microcode file sanity before loading it

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]

Message-ID: <20180315232306.GA31610@pd.tnic>
Date:   Fri, 16 Mar 2018 00:23:06 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 00/10] x86/microcode/AMD: Check microcode file sanity
 before loading it

On Fri, Mar 16, 2018 at 12:07:34AM +0100, Maciej S. Szmigiero wrote:
> Currently, it is very easy to make the AMD microcode update driver crash
> or spin on a malformed microcode container file since it does very little
> consistency checking on data loaded from such file.

Ok, a couple of tips for the next time:

* please send your reworked patchset for review after review of your
current patchset has been completed. We normally send patchsets once a
week. You've sent yours two days after and that's kinda too fast. I'm
sure you can imagine reviewers have other work to do too.

So please be patient before resending next time.

If in doubt, the whole process is documented in Documentation/process/ -
might wanna skim through it.

* when sending your patchset, make sure all mails are sent as a reply to
the 0/N message.

Your 0/N has:

Message-ID: <9964a6cf-00be-78ea-cc1e-7f7062716fce@...iej.szmigiero.name>

but your 1/N has

References: <cover.1521150415.git.mail@...iej.szmigiero.name>

so something went wrong there. Normally git send-email does this
correctly.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.