Tuesday, June 16, 2015
"AW67. Enabling PECI via the PECI_CTL MSR Does Not Enable PECI and May Corrupt the CPUID Feature Flags
Problem: Writing PECI_CTL MSR (Platform Environment Control Interface Control Register) will not update the PECI_CTL MSR (5A0H), instead it will write to the VMM Feature Flag Mask MSR (CPUID_FEATURE_MASK1, 478H).
Implication: Due to this erratum, PECI (Platform Environment Control Interface) will not be enabled as expected by the software. In addition, due to this erratum, processor features reported in ECX following execution of leaf 1 of CPUID (EAX=1) may be masked. Software utilizing CPUID leaf 1 to verify processor capabilities may not work as intended.
Workaround: It is possible for the BIOS to contain a workaround for this erratum. Do not initialize PECI before processor update is loaded. Also, load processor update as soon as possible after RESET as documented in the RS – Wolfdale Processor Family Bios Writers Guide, Section 14.8.3 Bootstrap Processor Initialization Requirements. "
The CMPXCHG16B feature flag is one of the flags that is reported in ECX.
This erratum only affects E0/R0 steppings of 45nm Core 2, as you can see in the Summary Table of Changes.
Generally a BIOS update will contain the needed microcode update mentioned above.
For those who have Intel motherboards, from https://communities.vmware.com/message/1765787 :
"I got fed up and went to Intel on this one. One of their second level people finally gave me the suggestion that I should again flash the BIOS update, but use the method for full bios refresh, rather than the windows-based update process. I suspect that the microcode fix referred to in AV69 is in a part of the bios core that is not updated unless you do the full refresh."
Thursday, October 30, 2014
Visual C++ 1.0 for NT shipped around the time of NT 3.1 release, and it used MSVCRT10.DLL. This was followed by MSVCRT20.DLL (for 2.x) and MSVCRT40.DLL (for 4.0).
Visual C++ 4.2 introduced the now famous MSVCRT.DLL, which was also used by 5.0 and 6.0. The 6.0 MSVCRT had a new heap allocator that exposed bugs in existing apps, forcing MS to issue the Microsoft Libraries Update.
As a result, starting with Win2000 the MSVCRT.DLL was now part of Windows. Future versions of Visual C++ used MSVCR70.DLL etc. For 7.x the DLLs was supposed to go into the application directory. 8.0 and 9.0 used SxS (with the exception of Win2000 and older where it was supposed to be placed in System32, if I remembered correctly). 10.0 abandoned SxS and always used System32, This is also true for 11.0 and 12.0.
14.0 will split the CRT into two parts, one is the version specific vcruntime140.dll etc, and the other is the non version specific backward compatible appcrt.dll and desktopcrt.dll. See MS's blog article for more details.
Tuesday, August 19, 2014
"I agree, but I do have several items on my wishlist for Satya, including ending the Yahoo-Bing and the MS-Novell deal, ending the Android patent attacks, putting an end to the SCO lawsuit,"
"For example, the MS-Novell deal is so bad that FSF put a provision in GPLv3 against it. I don’t know how much power MS has right now to end the SCO lawsuit, but it was quite famous. So is the FAT/exFAT patents and how it has been used to attack Android and other things that uses them (I am thinking that existing patents should go to the public domain and any remaining exFAT patent applications withdrawn from USPTO if possible)."
If you don't remember, the patent part of the Microsoft-Novell deal was discriminatory, which means that it was limited to specific customers. The point of free software, including licenses like the GPL, is that it allows free distribution of software without any royalty based patent licensing requirements. This is why the GPLv3 had a provision against it. Another problem is the $100 million worth of vouchers, to get customers to buy SUSE. Why should MS help a competitor like this? This deal was renewed in 2011 for four years, and it still have the same problems. Since then Novell has abandoned Mono, making the deal less valuable for MS than it was before.
Also, the FAT patents are not the only patents MS used to attack Android, and ChromeOS is also attacked using similar patents. Most of these patent attacks are based on FUD.
"And I forgot to mention OOXML. I just realized that Office for Windows don’t use the “Open XML” term that much inside the software. I am thinking of a proposal where the standard would be withdrawn from ISO, the “Office Open XML” term would be depreciated, and the “Strict Open XML” option would be removed (I doubt it is catching on). Note this don’t change the file format itself in anyway, the contents of the ISO standard would be merged with MS-DOCX/XLSX/PPTX."
Friday, December 20, 2013
I have reverse engineered this patch and its effects on keyboard layouts a bit. The patch works by shipping a new version of win32k for XP and Server 2003 that pay attention to a registry key. When this registry key is added, it restricts loading of keyboard layouts to the System32 folder (already done in Vista and later). This prevents further exploits on the keyboard layout loading code. This is the first part shipped in KB2676562.
The second part is a patch (KB2686509) that adds this registry key. Before this registry key is added, a DLL called kblchecker.dll is loaded that is shipped inside the patch. This DLL is supposed to enumerate all the keyboard layouts on the system and make sure they are all in the system32 folder because any other keyboard layout DLL is going to be disabled by this update. What I found out by black box testing this patch is that any registry key value (not subkeys or any value inside a subkey) in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Keyboard Layout key regardless of name is going to make this check fail with no FaultyKeyboards.log being created, which looks like a bug. The reason MS is not fixing this bug is probably because all it does is makes the installation of this patch fail.
Tuesday, August 27, 2013
We ask MS to:
- Ship these DLLs separately from PowerPoint 2003 along with a utility to call them, to provide users with a way to read these old formats.
- Consider opening the source to the translators. This will save MS the work of documenting these old formats.
Sunday, July 14, 2013
"Now, when such a .ipsum construct gains "layout" by a subset of layout properties (position: absolute; / float: any value; / display: inline-block; / zoom: 1;), what will happen? Right. Some will have to cancel the frozen process, others will have to reboot, data gets lost. Don't do it. (No, I don't link to a testcase here. IE7b3 is still crashing after scrolling/resizing. Depending on the memory already burned, you might have difficulties to stop the process...)"
I created this test manually (save http://www.satzansatz.de/cssd/pseudocss/pseudocss_t004.html and add zoom: 1 to .ipsum) and not only this bug is still in final IE7, I also noticed that there is also a potentially exploitable crash bug by opening the about box after opening this page. When this happens, it crashes with EIP at an invalid address.
After this, by adding onclick="window.showModalDialog('target.htm')" to <p class="ipsum">, creating the target.htm, then opening the page and clicking inside the box, I triggered various crashes including attempts at executing data (note that IE7 do not enable DEP by default) and heap termination on corruption.
I turned full pageheap on and after I did so it crashes reliably at:
(360.51c): Access violation - code c0000005 (first/second chance not available) eax=00000004 ebx=08042e78 ecx=0000000a edx=065acfa0 esi=08042e78 edi=065289c0 eip=3ceff096 esp=04d04ba8 ebp=04d04bf8 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 mshtml!CLineCore::AssignLine+0x37: 3ceff096 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
MS fixed this bug in the May 2013 Cumulative Update for IE6 and IE7.
Here is http://www.satzansatz.de/cssd/pseudocss/pseudocss_t004.html rendered in IE6 and IE7 before the patch:
After the patch (notice it is the same rendering as IE8+ in IE7 compat mode):
Monday, December 31, 2012
But one of my favorite is PX00307, about the decision that turned 32-bit OS/2 into a fiasco in the first place. One of the red signs is that the problems of the "32-bit Windows extenders" was not even mentioned, such as no preemptive multitasking and no memory protection! Win9x fixed some but not all of the problems. For example, the Win16Mutex was used as a global mutex to simulate the Win16 cooperative multitasking system. This mutex was taken every time a 16-bit thunk was entered and was global to the system, and even most Win32 apps sometimes thunk to 16-bit (for example when calling USER32) or took the mutex for other reasons. And notice neither Gordon Letwin (the architect of OS/2) or Dave Cutler (the architect of NT) was in the To list, another red sign. Now, OS/2 had a sync input queue that made the preemptive multitasking much less useful, but that was much easier to fix and IBM hacked in a workaround in a FixPak for Warp 3.
But that is not my favorite problem with Win9x. My favorite is how Caldera used it's dependence on DOS to continue DR's lawsuit against MS, even having projects like "WinBolt" to prove it. And of course even before then, there was Windows 3.1's infamous AARD code. And guess what, OS/2 never depended on DOS. It was designed from the beginning as a full OS!