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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 25 Jul 2014 18:46:14 +0200 From: Borislav Petkov <bp@...en8.de> To: Henrique de Moraes Holschuh <hmh@....eng.br> Cc: linux-kernel@...r.kernel.org, H Peter Anvin <hpa@...or.com> Subject: Re: [PATCH 6/8] x86, microcode, intel: total_size is valid only when data_size != 0 On Wed, Jul 23, 2014 at 05:10:49PM -0300, Henrique de Moraes Holschuh wrote: > According to the Intel SDM vol 3A (order code 253668-051US, June 2014), > on section 9.11.1, page 9-28: > > "For microcode updates with a data size field equal to 00000000H, the > size of the microcode update is 2048 bytes. The first 48 bytes contain > the microcode update header. The remaining 2000 bytes contain encrypted > data." > > "For microcode updates with a data size not equal to 00000000H, the total > size field specifies the size of the microcode update" > > We were incorrectly assuming that total_size is valid when it is > non-zero, instead of checking data_size to be non-zero. IOW, we were > trusting a reserved field to be zero in a situation where it was, in > fact, undefined. I'm perfectly fine with the patch except this statement above. I can't parse it. What reserved field? I'd guess the packages they distribute always have total_size initialized properly, i.e. in the case where data_size is 0, total_size is 2048 anyway. This is maybe the reason why nobody hit this bug as get_totalsize() returning always the correct number. Right? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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