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: <Y4qqmcM8iijFaemO@a4bf019067fa.jf.intel.com>
Date:   Fri, 2 Dec 2022 17:47:05 -0800
From:   Ashok Raj <ashok.raj@...el.com>
To:     Sohil Mehta <sohil.mehta@...el.com>
CC:     Borislav Petkov <bp@...en8.de>, X86-kernel <x86@...nel.org>,
        "LKML Mailing List" <linux-kernel@...r.kernel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Tony Luck <tony.luck@...el.com>, <alison.schofield@...el.com>,
        <reinette.chatre@...el.com>, Ashok Raj <ashok.raj@...el.com>
Subject: Re: [Patch V1 2/7] x86/microcode/intel: Remove retries on early
 microcode load

On Fri, Dec 02, 2022 at 03:53:52PM -0800, Mehta, Sohil wrote:
> On 11/29/2022 1:08 PM, Ashok Raj wrote:
> > -
> > -	if (apply_microcode_early(&uci, true)) {
> > -		/* Mixed-silicon system? Try to refetch the proper patch: */
> > -		*iup = NULL;
> > -
> > -		goto reget;
> > -	}
> > +	apply_microcode_early(&uci, true);
> 
> After this change, none of the callers of apply_microcode_early() check the
> return code.
> 
> In future, do we expect callers to care about the return code? The rest
> patches in this series don't seem to suggest so. Also, the expected error
> printing happens in the function itself.
> 
> Should the return type for apply_microcode_early() be changed to void (in a
> follow-up patch)?

Good idea.. But I think its early, the return code could be used for
something useful. I have some additional cleanup patches that I need to
fixup and we could use this for real.

For e.g. early loading failures are now reported by each vendor, if we can
consolidate this, we could do it more at a core level, but I'm worried it
might be too much change right now, and this can wait its turn. 

Cheers,
Ashok

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ