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: <20121115215523.GB6520@tweety>
Date:	Thu, 15 Nov 2012 22:55:23 +0100
From:	Andreas Herrmann <herrmann.der.user@...glemail.com>
To:	Boris Ostrovsky <boris.ostrovsky@....com>
Cc:	Henrique de Moraes Holschuh <hmh@....eng.br>, hpa@...or.com,
	mingo@...e.hu, tglx@...utronix.de, bp@...en8.de,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86, microcode, AMD: Add support for family 16h
 processors

On Thu, Nov 15, 2012 at 04:26:28PM -0500, Boris Ostrovsky wrote:
> 
> 
> On 11/15/2012 03:45 PM, Henrique de Moraes Holschuh wrote:
> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> >>Add valid patch size for family 16h processors
> >>
> >>Signed-off-by: Boris Ostrovsky <boris.ostrovsky@....com>
> >
> >Is this something that needs to go to -stable ?
> >
> >>  #define F1XH_MPB_MAX_SIZE 2048
> >>  #define F14H_MPB_MAX_SIZE 1824
> >>  #define F15H_MPB_MAX_SIZE 4096
> >>+#define F16H_MPB_MAX_SIZE 3458
> >>
> >>  	switch (c->x86) {
> >>  	case 0x14:
> >>@@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
> >>  	case 0x15:
> >>  		max_size = F15H_MPB_MAX_SIZE;
> >>  		break;
> >>+	case 0x16:
> >>+		max_size = F16H_MPB_MAX_SIZE;
> >>+		break;
> >>  	default:
> >>  		max_size = F1XH_MPB_MAX_SIZE;
> >>  		break;
> >
> >Because it looks like without this patch, some valid microcode updates
> >would be rejected by the kernel...
> 
> Right, patch loading will fail.
> 
> I wasn't sure whether stable would be appropriate since this is
> support for new HW. OTOH since this would result in loss of
> functionality one could consider this a bug.

Yes, it seems that a

 Cc: <stable@...r.kernel.org>

(at least for 3.2, 3.4, 3.6)

can't hurt to ensure that most recent kernel releases properly handle
ucode updates for family 16h CPUs (whenever they come out).


Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ