Wednesday, December 21, 2005
Friday, December 16, 2005
- 904706 MS05-050: Security Update for DirectX: Vulnerability in DirectShow Could Allow Remote Code Execution (re-release)
- 905915 MS05-054: Cumulative Security Update for Internet Explorer
Another update will be blogged when the component versions of these updates are live on the OEM Secure Site.
Thursday, December 08, 2005
Wednesday, November 16, 2005
Move over Mars Rover - here comes the Interplanetary Embedded Expeditionary Force!
Evidence Details - Global Evidence Management System
Thursday, November 10, 2005
Anyway, back on November 2, I noted that we were working on getting the October updates re-released as EXE and RTF files, rather than CD ISO format. Well, the web development team has the correct bits now and is working to rebuild the pages - I expect the job to be completed by early next week. Look for an update here once the job is done.
There was also a single update released earlier this week that applies to XPE - MS05-053 is a critical security update for XP Pro. We're releasing it as a desktop update and I expect it to be available early next week as well for Embedded customers. The componentized version will be in our next scheduled release in December.
That's about it for now.
Thursday, November 03, 2005
Add to that the fact they're using XP Pro rather than XP Embedded... Come on, guys! XPE was made for this application!
Ford squeezes an office into a truck | CNET News.com
Wednesday, November 02, 2005
When the bits were released, they were released on CD - this means a few things. First, you can order an October XPE Update CD (that's probably not the name, but that's the spirit of the name) from your AR (whoever you got your toolkit from). Second, we can use existing release processes and teams to do the release, rather than me doing 90% of the release work. Third, because this is a new process, there are teething pains we're working out. The IMG file is one of them.
The IMG format is just an ISO copy of the CD we released. If you have a CD burner and software that can recognize the IMG format, you can burn your own CD - pop that CD into your development machine and you can run the update packages from it, scan the documentation, and archive it for posterity. If you don't have a CD burner and software to support it...
We've recognized this as a mistake, and are working to correct it now. However, rather than pull the release down and put it back up once we get the downloads fixed, we're leaving the IMG file available for download until we get the standard EXE/RTF downloads available.
Like I said, these are teething pains - big ugly teething pains. There are changes to our entire release process, from how I hand the bits off to how the web team handles them to exactly who the people doing the work are. We are making sure this won't happen again next time, but I can empathize with those of you affected by the problems we're having this time.
Wednesday, October 26, 2005
Windows Registry Editor Version 5.00
Note that you can cut and paste the above snippet into a .REG file and apply it using RegEdit, if it's on your runtime. If not, you can add the keys offline, or using a script.
Also note that you may see this problem with the componentized version - the registry keys are owned by the COM Base component, but I'll do some more investigation and see if I can't resolve this in the components for December.
Tuesday, October 25, 2005
Well, it's how you can run two XPE databases on the same server, like maybe an SP1 DB along with an SP2 DB, all on one machine. No more second servers to handle the SP2 upgrade.
Why did we come up with this? Simple - automation. I've been talking a bit in this blog, and to MVP's and other customers at events, that moving security work into WinSE meant we had to automate a lot of stuff. One of the first things we automated was the creation of update packages, and the WinSE Build lab is integrating that automation into their normal build processes.
The problem came when they realized they needed to XPE DB's to do the XPE update builds, one for SP1 and SP2. They were really agitated when I told them that, if there's an SP3, they'd need a third server for it as well. They needed a way to use only one server if possible.
SQL Server supports multiple instances - basically, other DB servers running as separate processes on the machine. But CMI was never written to handle multiple instances - it just connects to the default instance on a given machine. The server to connect to is just a single string - no extra setting for which instance to use. But SQL already provides a syntax for selecting a server and specific instance - it's
A few things to note about the steps Lynda provides:
- We developed these steps for the WinSE Build Lab, which has a SQL Server installation being used for other purposes. Therefore, we added two new instances, one for SP1 and one for SP2, so their default instance wouldn't be affected by XPE. In your setup, you may not need to be so diligent and be able to use just a single additional instance.
- In our build environment, it's important we keep our repository files separated, so step 6 is necessary. You may not need to do this - repository separation is provided in the DB's themselves, and all the update files go into separate repositories, so this may not be necessary. It does duplicate a few Gb of data, so if you're tight on space on your server, you should be able to skip this without affecting your builds.
- Step 5 has you copying databases from one instance to another - we did not test, and do not yet know, if you can install the DB directly to a given instance. If anyone tries this, let us know how it worked.
That's it - questions on this procedure should be sent on a comments to either this post or the original.
Thursday, October 20, 2005
A few notes about these persistent delays - in the past, the delays have been due to engineering delays. We wait until the second Tuesday (when the Pro updates are public) to start our componentization process. Now, however, we're actually done with the componentization and testing a week before everything is ready for release - that week gives us time to actually do the release of the componentized updates. The release process has changed as well - we're releasing via CD direct to the Authorized Resellers, so you can actually order the update CD from the company from which you get your XPE tools and device licenses. Everything up to the burning of the CD I have some control over - after the CD is burned, it's a black box to me.
So, while from my POV we're simultaneously releasing Embedded updates with the Pro updates, the process of getting them onto the OEM Secure Site is still a time consuming process, and means that you still see a week delay. I'm doing everything I can to decrease that time to be as small as possible.
One other note - October included an update for DirectX 9 for both SP1 and SP2(MS05-050, KB904706). XPE SP1 did not ship with DX9, so there won't be a componentized version of the DX9 update for XPE SP1 in the package that gets released. We did ship a DX9 component for XPE SP1 as a separate feature update - I plan to have an update for that feature in December. It will be setup so it won't install on your XPE SP1 DB unless you have the DX9 feature added - let me know if this is important to you by commenting here.
And one final note - you'll want to keep visiting both this blog and the Embedded Team blog in the coming weeks. We're working on something pretty cool that we should have figured out years ago, and I think you'll want to see it.
Tuesday, October 18, 2005
It's a hassle for you, but to be honest, I really don't need real estate advice from someone who thinks my blog is "really cool", "has tons of great info", and "will definitely bookmark your blog!"
Seems like Sean Liming's kept himself busy - head up to his Tools page, and towards the bottom, you'll see a link to a new tool called SLDDiff. For those of you who have his latest XPE book, the Windows XP Embedded Supplemental Toolkit, this will look familiar - it's a lot like SLXDiff, but it compares SLD's.
I'll confess that I was the impetus here - I was looking for a way to find differences in 30+Mb SLD's (like our monthly rollup SLD's) and had nothing. I hacked together an XSLT that would pull the pertinent data out of the SLD, sort it, and dump it to a text file. Do that on two different SLD's, then run the text file output through WinDiff (or suitable differencing engine), and you've got a really terrible way to figure out what changed. Sean took that idea, wrapped it in a neat interface, and came up with a tool I use when necessary.
As for the latest set updates, they're on their way - the desktop versions should be on the OEM Secure Site RSN (Real Soon Now), and the component updates are on their way as well. The only thing that you won't find in the component updates is the DX9 update for XPE SP1. XPE SP1 shipped with DX 8 - we do have a DX9 component for XPE SP1, but since I didn't have that installed when I ran the updates, I didn't pick it up. It will be out in November.
One other piece of good news is that we're now using an automated tool for generating updates for XPE - it does everything we used to do over 1-2 days in about 15 minutes, integrates into the existing build process for XP Pro updates, and cuts down on our test time. We're not pushing so hard anymore to get fixes developed and tested, and can take some time to implement more test automation as well. Our hope is to code ourselves out of jobs, but not until we speed up the release process... :-)
Friday, July 08, 2005
Tuesday, July 05, 2005
If you’re using SUS on an older XPE deployment, take note here – SUS 1.0 (which shipped with XPE SP1) is no longer available for download from Microsoft. The Windows Update Services component in XPE SP2 supersedes it, and support for the old version ends in one year. Remember, folks, I didn’t make this decision, I’m just reporting the news here…
Oh, and expect the June security update rollups for the XPE DB to be out soon – they just got through test, and need to go through codesigning and release. With Monday being a holiday in the States, I can’t guarantee Friday, but I will push it as hard as I can.
Thursday, June 23, 2005
Yesterday, the following Desktop Security Updates for Windows XP Embedded were published to the OEM Secure Site at https://microsoft.embeddedoem.com:
- Windows XP Embedded with Service Pack 2
- MS05-019: Vulnerabilities in TCP/IP Could Allow Denial of Service (893066)
- MS05-025: Cumulative Security Update for Internet Explorer (883939)
- MS05-026: Vulnerabilities in HTML Help Could Allow Remote Code Execution (896538)
- MS05-027: Vulnerability in SMB Could Allow Remote Code Execution (896422)
- Windows XP Embedded with Service Pack 1
- MS05-019: Vulnerabilities in TCP/IP Could Allow Denial of Service (893066)
- MS05-025: Cumulative Security Update for Internet Explorer (883939)
- MS05-026: Vulnerabilities in HTML Help Could Allow Remote Code Execution (896538)
- MS05-027: Vulnerability in SMB Could Allow Remote Code Execution (896422)
- MS05-028: Vulnerability in Web Client Service May Allow Remote Code Execution and Elevation of Privilege (896426)
- MS05-030: Vulnerability in Outlook Express Could Allow Remote Code Execution (897715)
These updates can be installed on Windows XP Embedded runtimes that already have the Desktop QFE Installer tool installed.
Thursday, June 16, 2005
I sent off the requests for the recent round of security updates on Tuesday – they’re working their way through the release process and should be available soon. I’ll update the blog once they’re posted to the OEM Secure Site.
For the record, here is the list of updates that apply to XPE that we are releasing – remember, we only pick up Critical and Important fixes by default.
|XPE SP1||XPE SP2|
|MS05-004, 887998 (reissue)||Y||Y|
|MS05-019, 893066 (reissue)||Y||Y|
One thing to note is that the MS05–004 reissue desktop update will be late getting to the site – I’m having problems identifying the correct updates for SP1 and SP2 (there are about 12 different packages to choose from). Once I get them ID’d, I’ll get them out – expect them next week.
As for the component updates, there’s one final issue that needs to be investigated, but once that’s done, they should be ready for codesigning and release as well. I’ll be expediting them once they’re OK’d by test.
Friday, June 10, 2005
Great news from Tech-Ed – the MSRC (Microsoft Security Response Center) team made a presentation about how security vulnerabilities are patched on Microsoft platforms and applications. This is great background material and shows how much work goes into the updated binaries themselves. All this work happens well before XPE ever gets to work the Embedded voodoo to bring you the componentized versions – good info.
Oh, and one extra point – there’s a sentence in this article that reads:
On every product team within Microsoft, a staff member is on call to coordinate with the MSRC and join the investigation.
When I was on the Embedded team, that person for XPE was me. I don’t know who the person is now.
Thursday, June 09, 2005
Not sure if this is common knowledge, but Microsoft publishes the Microsoft Security Bulletin Advance Notification the week before security bulletins are supposed to come out. While it identifies neither specific issues nor bulletins, it does give you a count of issues for Windows. As a rule of thumb, any Critical or Important bulletin applicable to Windows is packaged to XPE, so the Windows count will be the maximum number of issues we push out in our roll ups.
Also, at this point, we are only handle Critical and Imporant security bulletins by default, so the non-security High Priority updates at the bottom of the page don’t get packaged automagically. If you find you need one of these (because you saw it come down Windows Update or saw in on MSDN or TechNet), contact PSS to request it’s inclusion for XPE.
Friday, June 03, 2005
Not sure if I plugged this before, but the latest episode of the Code Room focussed on embedded tech, and stars XPE superstar and eMVP Sean Liming – give it a look. Not much on XPE, but it’s good to kill your lunch hour anyway.
OK, it’s not strictly Embedded, but it may open the way for a new class of Embedded devices. Office is opening their formats to be XML based, which in and of itself is very cool (side note: this will make publishing extra info about Embedded security updates much easier). But what if someone were to come up with a way, outside of Office, to consume these new formats and put it on an Embedded device. I’m thinking of a service-based business with a document kiosk available to walk-in customers, with documents stored on the device. XML attributes could provide user-viewable info before they print the doc, and a network connection allows it to be updated live.
Or maybe an XPE-based projector with slide decks stored right on the projector. Give it to your sales force on tours to present standard slide decks to prospective customers, or load it with lessons for a substitute teacher to present to a class in your absence.
Maybe a SAN/NAS or printer device with some XML processing that can report on the documents that pass through it with some intelligence on the the documents.
There are possibilities in the embedded space foe this, all made possible by three things – the richness of the Windows API in XPE, XML processing power, and new, open Office document formats.
Wednesday, May 25, 2005
File this as a follow-up to my talk at MEDC about XP SP2, XPE SP2, and securing your XPE devices – an internal analysis of XP SP2 found machines running it were 15 times less likely to have one of the top twenty malware apps on it than RTM or SP1 desktops.
It was announced last night – Windows Embedded for Point of Service (WEPOS) is a reality. Based on XPE SP2, WEPOS is a retail-optimised platform (not my term)… you know, I should talk in my own voice…
WEPOS is an installable OS, like XP, but it’s based on XPE SP2, and it’s designed for POS terminals and other devices used in retail. It’s not just our POS macro component with a lot of HW support wrapped in an installer – it’s got some extras that the WEPOS team put together to make devices live better in a retail world. These guys worked hard to get this thing ready and out the door, and I for one am glad to see it come out.
The MS Press article is kinda dry, but the links take you to cool places.
Monday, May 23, 2005
This makes a lot of sense to me – I use variations of the same password on multiple websites, depending on the strength allowed or enforced, but would like to have different passwords in different places. My solution? My Pocket PC – I have a password saving app on my Dell Axim that I use to store these passwords (along with other sensitive info). Protecting the info is the key, and by storing the passwords behind an encryption layer, all I need to do is remember one password to get into it. My software? MyCodes Lite, as I can store other info there as well (like CC numbers and other sensitive data), and it’s freeware as well.
Wednesday, May 18, 2005
Interesting - this is the first I’ve heard of this, and it’s a good follow-up to my talk on securing XPE devices from MEDC last week. While nothing in this article is specific to XPE, it will bear fruit for XPE device makers as a welcome side-effect of it’s goals of protecting XP desktops. A variation of a honey pot, the “honeymonkey” concept doesn’t wait for hackers to come feast on the honey, but brings the honey to the hacker looking for exploits. The use of virtual XP machines is a good approach as well. Strider is a tool developed by MS to find root-kit viruses, viruses that mask themselves from normal scans by hooking and/or shimming XP binaries.
Tuesday, May 17, 2005
Well, MEDC is over – sorry I didn’t post more last week. For some reason, when I got back to Seattle Friday afternoon I was very tired – might have been the fact that I averaged 4 hours of sleep per night while in Vegas (go figure).
The last day was pretty cool – I volunteered to referee the SumoBot competition, which was won by the lone RC entry from ASU. We had some cool prizes, including more bots from Parallax, and the final event was very exciting and even attended by Elvis. Mike Hall has some cool pod cast videos on his site – I’m looking forward to him posting the one of me and Elvis at the SumoBot competition.
This year’s Devcon was probably my last – if you were there, or have read the blog, you know that I’m no longer on the Embedded team, so my chances of going to future Devcon’s will be low. Sean Liming will be presenting my material on securing XPE devices at the MEDC roadshow in Europe and Asia – the info will be the same, so if you have a chance to go, I urge you to.
One very cool thing we did was during the keynote, which I reported on earlier – a working HORM demo during Bill’s speech. I have to give thanks to Brad Combs’ XPEFiles – during the development of that device, we discovered that the video driver was not part of XPE as shipped. We searched XPEFiles and found the driver componentized there – 10 minutes later, we were rebuilding the runtime with the updated driver and within 30 minutes were seeing an 800x600 32–bit color rather than 640x480 in 16 color mode. Very cool, and my thanks to Brad for running his site.
In other news, there was a recent report on eWeek about a faulty security update, namely MS05–019 (thanks to Andy Allred for bringing this to my attention). I haven’t heard anything about XPE customers being affected by any aspect of the faults, but we will be handling the re-release in our next regularly scheduled security update package for XPE.
Wednesday, May 11, 2005
You know, I wish I had something to report from this morning, but since I had no commitments until this afternoon, I spend the morning in a small poker tourney (placed 7th out of 30, top five paid).
However, I do have some info from last night’s Ask the Experts session, where I had a chance to talk to more than a few customers. One thing that came up was using RDP to access a Minlogon XPE box – this cannot be done. RDP requires a user with a password to authenticate – since Minlogon has no concept of a “user”, you can’t login to an XPE box based on Minlogon using RDP. Also, the default RDP behaviour of only having one active session on XP Pro carries to XPE – you can’t have someone logged into the XPE machine directly and someone logged in remotely, and have them both working at the same time. You’ll need to go with NetMeeting or some other alternative to provide for two people to access the machine simultaneously.
Look for more later…
Tuesday, May 10, 2005
Mike Hall just got through with a demo of the new Windows Mobile 5.0 – part of the demo included an XPE SP2 device with HORM. On stage, Mike pulled the plug on the device, then plugged it back in, and watched the device POST and reboot into the custom shell with about a 7 second delay. Sweet!
If you missed the streaming keynote, you should be able to get it on demand from the webcasts site.
Monday, May 09, 2005
Well, the first post that was supposed to go out this morning took a while – seems my blog posting software, BlogJet, was configured to use the internal MS proxy server rather than auto-detecting (which explains a lot).
Now it’s around 5pm – I’m running through my hands-on lab (HOL) to make sure it will work as advertised and get the kinks out of it. After this is done (probably another 30 minutes or so – it’s going through FBA now), and I’m back up in the room to get ready for the MVP dinner. We’ve invited 50–60 MVP’s and are going to put them in a room with a few MS folks, some food, and sharp knives – should be fun.
Today’s been a dead day other than prep work – tomorrow should be much more interesting, as that’s when the sessions and HOL’s start in earnest.
Oh, and one quick update – a few customers have reported to us that a feature update we put out last year to add Remote Desktop Protocol 5.2 to XPE SP1 was lost in XPE SP2. I think I’ve reported on this in the past – indeed, SP2 didn’t include RDP 5.2, so we wound up updating XPE SP2 with RDP 5.1. In any case, the RDP 5.2 component feature update for XPE SP2 is currently in test – reports are good so far, no major issues. In fact, the biggest problem is that I forgot to give them the additional info document. We should have this through component testing this week.
Well, I’m here in sunny Lost Wages. I always have problems sleeping when I travel, so I was out walking the casino floor around midnight and ordering dinner at 1am. The thing I love about Las Vegas is that, if you don’t have a watch, you really have no idea what time it is – the casino is open and running 24/7, and the only way to tell time is either by the restaurant closings or the kids walking outside the casino floor.
Anyway, it’s early on Day One (9am to be precise), and I’ve registered, gotten into the speaker lounge and been checking e-mail. Bumped in to Mike Hall, who will be podcasting the whole time – minor setback when the podcast hardware room was burglarized, but we had the CSI crew in and should have the culprit in 40–50 minutes, depending on whether we’re the main or the sub plot.
Signed in and got my speaker gift – a USB key and a USB set of speakers (think they’re sending a message? Next year, will it be Bluetooth stuff?). Had some coffee in my new coffee mug, which was in the backpack they handed out, and some breakfast which was in the speaker room. You know, I think I’ve figured out why these things are so bloody expensive…
Monday, May 02, 2005
Well, the April updates were posted to the OEM Secure Site last week – the date is April 29, which is right on for when they asked me to verify the bits downloads. This time gap between desktop updates and component updates will be consistent through the early summer, but expect it to decrease as summer languishes into fall – that’s when we’ll have things in place to start to turn up the heat on getting updates through a more aggressive process.
BTW, you can learn more about the existing process, the new process, and our goals next week at MEDC in Las Vegas. I’ve got one scheduled session and a hands-on lab about securing XPE devices, and part of those appearances includes some discussion about security updates and the processes around them. The organisers of MEDC have done something cool this year – in previous conferences, there’s usually a crowd of people surrounding the speaker and the podium, asking questions and engaging in discussions. Problem is, with a dozen of more people crowding the speaker on the podium, it’s tough to get the next speaker and his audience into the room. Therefore, the organisers have come up with the idea of a Speaker Cabana – basically, it’s a place somewhere away from the podium and presentation room where we can all get comfortable and have our conversations, which allows the setup for the next guy to take place. Since it’s a cabana (and it is Vegas), I’m expecting comfy chairs, a drink cart, and some finger food, but I’m ready to accept just a comfy chair and a plug to charge my laptop. I’ll bring my own potables… :-)
Q & A
Now, some Q&A – a loyal (I hope) reader has fired some questions to me directly regarding BootPrep and the vagaries of a dual boot with XP Pro and XPE. I’ll group the questions together to answer them.
Can you please tell me that what it bootprep utility and why it's used?
BootPrep is a utility we shipped with XPE to allow you to create an XP boot sector on a drive that normally wouldn’t have one, such as a FAT/FAT32 partition. You only need to run it if the partition you will be booting from is FAT or FAT32 and does not currently have an XP boot sector on it. To put it another way, if you’re booting from an NTFS partition, or if you’re dual-booting a system that already has XP booting on it, you do not need to run BootPrep – all NTFS volumes have the proper XP boot sector code in them, and a system already booting XP has already been properly setup to boot XPE no matter which volume it’s on. BootPrep is only useful for making a single drive/single partition FAT/FAT32 system bootable to XPE.
Is it necessary to run FBA on target device hard drive which is formatted by FAT/FAT 32?
It's necessary to run FBA on every system, no matter the underlying file system.
What are ARC paths?
That's best handled by giving you some links to info on the base OS. Knowledge Base article 102873 has some good basic information on ARC paths.
And What is GenDisk?
GenDisk stands for Generic Disk, and is a fallback PnP ID for an IDE or SCSI disk. Basically, any disk that can be used in a PC supports some basic functionality – GenDisk encapsulates that functionality, so that if XP/XPE can’t find a specific driver for your drive, it can still boot from it and read and write data to it. Some of the links returned by a search on MSDN can give you more info on GenDisk, why it appears, and why it’s useful.
When I do dual boot, I do it on drive D of target device, which is formatted by NTFS system. My root drive is C with XP pro, does this thing giving me problem for RAM boot?
It might - a Remote Boot into a RAM disk presumes that the RAM disk will be C:. If you are preparing the system on D: so it runs properly, it probably won’t run properly in a RAM disk called C:. You may want to swap how you dual boot the system – repartition and install XP Pro on D:, then put your XPE image on C:.
Tuesday, April 19, 2005
OK, I just approved the DL’s for the April security bulletins - expect to see them live later today or tomorrow. I apologize for the long delay on this – my web release guys were swamped last week, due to two factors: first, it was Security Bulletin time around here; and second, last week was spring break for the local school systems and lots of people had vacation planned with their families. I realize this looks like a step backward as far as the time lag goes, but for the desktop updates, nothing really has changed process-wise – we did this release just as we have over the past year. However, as we move the process forward and get it better settled into WinSE, I expect to be able to get the releases moving sooner, which means they’ll appear on the OEM Secure Site sooner. That’s the next thing on my list, right behind getting Test lined up and right in front of getting Dev lined up.
The component versions are finishing up in test right now – just a few minor issues to polish, and they should be ready for codesigning and release. If all goes well, they should be on their way to the web release team by the end of this week, which means early next week for a real release, which will actually be a week quicker than the last set. Once Test is lined up in WinSE to do this testing along side the other updates, we should be able to get the sign-off, code-signing, and release done at the same time as the desktop versions. So while this month seems to be a step backward, things are looking good to have releases done and to you quicker each cycle. As I mentioned before, the goal is to have Embedded updates available the same day as the desktop updates - we hope to have approached that goal by the end of this year, and be making steady progress towards it each cycle.
Now, in Other News:
I’ve had two comments from people on my Linux story from a few weeks back, trying to explain the vagaries of releasing GPL source code. I’ve read the GPL, and to my understanding (section 3a and 3b), you either have to make the source available or tell people how they can get it, and not charge more than copying and media fees for it (i.e. you can’t give away the EXE but charge beau-coup bucks for the source). Compare that with proprietary software (such as Microsoft makes), where the source code itself is IP (intellectual property), owned by the company or individual and protected by copyright, patent, and license law. If you write proprietary software, you can charge whatever you want – if you write GPL software, you can’t really charge for the binaries nor the source other than some recovery costs, although it does open the market for add-on support and services (look at Redhat for an example, who make their money as a service-based business, since they can’t charge for the software directly [GPL Section 1]). However, Microsoft and other proprietary software vendors do both – charge for the software, and charge for extended support. It seems to me that proprietary software makes better economic sense.
I know I’ve cleared up nothing, and have probably opened myself up to more comments and religious arguments, but at least people are reading the blog.
Tuesday, April 12, 2005
There are scheduled security bulletins today for XP Pro – we’re already working on the Embedded versions, and the desktop version should be on the OEM Secure Site by the end of the week, next Monday at the latest.
To keep up to date, you can add the Microsoft Security Bulletin RSS feed to your favorite RSS reader (I use Serence KlipFolio) to get updates on what’s current, and keep a handy list of what was released in the past.
All this at no extra charge, like more ice water at a restaurant or watered down drinks at a Las Vegas blackjack table…
Monday, April 11, 2005
You know, I thought I had blogged this back in November, but I can’t find it. In any case, here’s the story, trying to find the original AvantGarde report. There’s scary news (Windows XP SP1 machines on the Internet were owned – not hacked, probed, tested, but owned – on average in four minutes) and good news (Windows XP SP2 with the Windows Firewall on by default kept the machine from being compromised at all) and some duh news (no firewall in the world can save you from a weak or non-existant password). The main points here:
- If you’re not running the Windows Firewall on SP2, you should be.
- If you’re not running any firewall, you should be.
- Set strong passwords on all your accounts (combination of lower-case alphas, UPPER-CASE ALPHAS, numbers, and symbols, at least six characters long)
Well, I guess I better start updating this a bit more – there are actually people reading it that I didn’t approach with the request, “PLEASE READ MY BLOG!” Not that I’m that desparate for a readership, but who knows? Should I decide to turn the corner from Helpful Embedded Guy to Evil Genius, a solid readership makes for a ready source of Evil Henchmen recruits… :-)
Anyway, on to the letter – Sana in Pakistan found my e-mail on the blog and is asking about Remote Boot. His problem description (minorly editted):
I deployed (the base image) to target pc's hard-drive and ran it until I got Machine-resealed message. Further, I prepared a .sdi file from it. Using windows 2003 server, I configured dhcp & remote boot dervice. I gave Client's MAC address, boot program and boot image name in remote boot manager.
.sdi file size is 180 MB.
The ramdisk image started loading and it completed. Next, the light blue screen, that showed that it's an XPE image of evaluation copy and it will expire in 120 days, was displayed.
Further, it moved to the page that we get when xp starts, like welcome page. Then it got stucked there though i waited for 30 mins. but it did'nt log on.
OK, so my take on this is that 320Mb is nowhere near anough memory to host a 180Mb RAM boot image plus have memory enough to run. For any remote boot application, the bare minimum I think acceptable is twice the size of the SDI, plus a little extra (note that this is my opinion, not a statement of supported configurations). In this case, the 180Mb RAM image leaves only 140Mb to load the system plus everything else. Remember, when you boot the machine on HD, you’ve got 320Mb of memory to load stuff into (like FBA, services, drivers, etc). Now you’ve cut down the memory by more than half – I’d expect some teething pains.
However, I realize that the runtime should have done something within 30 minutes, albeit slowly (assuming you have a shell defined properly – I’m skipping over some of the more obvious troubleshooting here, assuming the runtime boots on the PC properly). My first step would be to shut the machine down, reboot into a safe build, and check the event logs on the embedded system – something may be failing that’s necessary. Second step would be to try to boot with a kernel debugger hooked up.
Of course, I’d also try stripping as much unnecessary HW/SW from the machine as possible – check out my MSDN article on small footprint to find out how. Basically, start with as small a system as possible as a sanity test on remote boot, then add things to the runtime until you’ve got your whole device up and running. By starting small, you can eliminate a bunch of things that might be causing a problem, and if things stop working after you add something, you can isolate your troubleshooting to what was just added. The problem is that you can’t just strip down a 180Mb runtime – you’ll have to start over with a small runtime and add things to make it functionally complete.
Any comments from the rest of the readership (both of you) are welcome.
Thursday, March 31, 2005
Well, this is my first blog post from my new position on the Sustained Engineering team. While my office move was done a few weeks ago, and I’ve been doing the job since then as well, it was just made official today (at least, that’s when it finally filtered up through the many various DB layers to show up in our address book). So today, officially, I am no longer on the Embedded team.
I’ll wait until you can compose yourself. :-)
What I’ve been doing for the past week or two is trying to get our new automation tool simplified for the non-Embedded folks over here in WinSE. My colleague in crime and Part-Time Bottle Washer Jay Kremer did a great job with the tool, but even after it was completed and being used, it was a hands-on process that he babysitted through the process. It is a vast improvement over the old process, but it requires you know the XPE QFE process, XPE architecture, and have the time to do it. In short, it’s not going to fit into the fully automated hands-off processes WinSE currently uses to put security bulletins together.
So what I’ve been doing to writing some wrapper apps to go around the automation tool that enable:
- One button push operation – basically, call the wrapper and point it at a folder full of updates.
- Batch processing – the tool works on one update package at a time. The wrapper lets us work on all the updates at once.
- Automatically select the right SP level.
- Accumulate all the updated components into one rollup SLD – this required some fancy footwork to replace the previously used rollup with the one we just got through creating.
Now, it’s still not ready for the WinSE build lab to take over – some updates can’t be handled this way, there are some other oddities in the automation tool itself that need to be tweaked, and no one here is going to want use code written by a PM (go figure, since the last shipping code I wrote was pre-MS, early 1995 in Clipper) – but it’s better than the previous manual process. Next steps are to spec out the changes we need for V2 of the tool, get a dev assigned to do the work (tougher than it sounds), and push this baby out the door.
Friday, March 25, 2005
Have you checked out the new XP/LH Embedded Team blog yet? You haven’t? Why not? Oh, I see, you’ve been busy. Out of town, you say? Off visiting the in-laws for a week? Well, most libraries, even in that little town your spouse’s parents live in, have internet access – why not break away for a while and read some cool stuff? You can’t tell me that your father-in-law account of the fish that got away is that compelling… :-)
If you haven’t checked out the newest blog on Embedded Avenue, you should. Andy and Lynda from the test team have setup the blog as a clearinghouse for all the tribal knowledge collected over the past four years of XPE. These tow guys know their stuff, and they know how to pass it on to other folks. They also update it much more frequently than I update my blog :-(.
BTW, check out Andy’s post about Rawdeps and cooking. There’s a bit of a contest at the bottom – i.e. you could win something.
For those of you way out of the loop, there’s a group formed last year called the Windows Embedded Developer’s Interest Group (WE-DIG for short). It’s comprised of a bunch of embedded developer’s from our the Puget Sound who work with Microsoft Embedde technologies – XPE (of course – the only MS embedded OS that actually has embedded in it’s name), WinCE, PocketPC, and others like Media Center and Tablet. We meet monthly on MS campus – you can register at our website for access to member only content, notifications of new meetings, and other interesting stuff.
Of course, if you don’t live within commuting distance from Redmond (heck, on bad days, people who live in Bellevue aren’t within commuting distance), then making the meetings is going to be tough. That’s where registering on the website comes in – Mike Hall, our esteemed A/V nerd, videotapes every meeting, then dumps them to the website for the world to see. Well, not the world – the WE-DIG registered users world.
And, if you’re planning on coming to MEDC in May down in Vegas (Vegas baby!), we’ll have our May meeting there. I’m pushing to have it around the $5 blackjack tables, but am being overruled in favor of a quieter, more professional venue (to which I say: who is more professional than a Vegas blackjack dealer?) You’ll get a chance to meet the board (including yours truly, the aforementioned Mike Hall, and a host of others – logon to find out who else is on the board), see what we do at meetings, and enter our monthly raffle to win some cool stuff. What kind of cool stuff? Well, in our first meeting, we gave away a Motorola MP200 phone – we haven’t hit that high again, but we do get books, dev kits, some HW, and general swag.
Thursday, March 17, 2005
ZDNet is reporting a German visitor to CeBit trying to notify about a dozen companies that their products which use Linux are in violation of the GPL by not returning the modified source to the community. The protagonist in our story, one Harald Welte, is the author of netfilter/iptables and a one man wrecking crew when it comes to tracking down GPL violators as part of the GPL Violations Project.
This story, I think, is very illustrative of the problem open source has when it comes to defining a profitable business model for your open source solution. There are a lot of companies thinking GPL source is public domain, grabbing it, adding their own valuable IP, then retaining those changes. Any lawyer can tell you GPL’d source is not PD, and while there are some enforcement issues with GPL’d source (for example, there’s no legal way to sell a license for no money, and while that’s a technicality of the law, it’s still an issue to deal with), Welte and the rest of the open source community are well within their rights to demand these vendors turn over current source to their projects.
Now I’ll ask you – let’s say you’ve just used Linux to develop a home router/firewall solution, adding significant IP to make the firewall as bullet-proof and state of the art as possible, maybe incorporating some new inventions you’ve developed. Are you going to be willing to turn that source over to the greater GPL community? Remember, anyone can get the publickly available source, from developer’s to researchers to gifted 15–year old script kiddies who live to wreak havoc and ruin. Can you patent your inventions since they’re based on GPL? What if someone takes your source contributions, tweaks them a little, and starts selling a competing product? How do you enforce your IP rights over that? How do you keep from going out of business?
I like Linux, but then again, I’m a computer hobbyist and have been since junior high school. As an alternate OS, it’s kinda neat to play around with, and there are a few things it has the XP doesn’t yet (for example, a full OS install including office software and development system in about 4 Gb of disk space), but there is no way I’m basing any derivative works from it. As a profitable embedded business model, Linux makes absolutely no sense whatsoever.
Tuesday, March 15, 2005
A quick update on some changes happening here at Microsoft.
First, the bad news – I am no longer a part of the Embedded team.
Now, the good news – I am moving to the Sustained Engineering team to handle servicing of XPE. What this means is that XPE servicing will now be part of the servicing infrastructure for all of Windows. This includes not only security and other updates, but also future service packs for XPE. My friend and teammate Jay has done a great job with servicing since he joined the team 18 months ago, but if the team is ever to concentrate solely on Longhorn Embedded, they need to have the resources that were previously dedicated to servicing XPE. So, we give servicing to the servicing experts (along with some resources, like me) and the Embedded team can work on bigger and better things.
Ramifications? Well, by bringing XPE into the larger Windows servicing structure, we hope to get security bulletins out quicker. We’re also hoping to get other non-security updates out in a timelier manner, and without so much internal hoo-haw over testing and verification. Also, because we’ll be treating Embedded like any other Windows product, we hope to avoid problems like we saw with the .Net update last week. Plus, the Embedded team can dedicate 100% of their attention on Longhorn Embedded, which is a very good thing.
Now, before you start getting your hopes up and inundating me with questions and comments – this won’t happen tomorrow. It will take a while. Embedded has been on its own path with regard to servicing for so long that I expect a lot of churn just trying to integrate into the main servicing processes. As you can imagine, there is a lot to hand over, and we’re still hammering out the details and getting past the he-said/she-said stage of the relationship. I won’t make any predictions on when things will happen – most of my predictions have been BS in the past.
So there you have it – change can be a good thing, and I’m hoping this will be a very good thing.
As a bit of an aside, this has been in the works for months – I’ve known about it since before XMas last year. This past January, the entire Embedded team wasin a big office move. Since I knew I’d be moving once more when I got into the WinSE team, I only unpacked two of my boxes (books, some HW, and stuff for my desk) – the other boxes have been sitting here, unopened, for two months. My WinSE office move is tonight, so I’ve been looking forward to getting everything out of the boxes again. However, I’ve heard a rumour that another office move is planned in the near future, so I may never get my stuff unboxed. Such is life at Microsoft – when you’re trying to carry 1000 canaries in a truck that can only carry 500, the trick is to keep 500 flying at all times…
One last thing – I added a new link to the Mobile and Embedded Device Convention (MEDC, or what used to be just Embedded Devcon) on the upper left. I plan to be there in Las Vegas in May with my wife, and my money plans to stay. Hope you can make it – it should be a fun time.
Thursday, March 03, 2005
OK, we’ve had one of our best people (namely Aaron Stebner) working on getting this working. He’s got a set of steps that workaround the previously mentioned problems with applying the .Net security updates to XPE runtimes. Look for the updates to be back on the OEM Secure Site within a week – in the meantime, you can DL the bits from the Download Center to test these steps out (Aaron shold repeat them on his blog as well).
- Figure out the exact version of the .Net Framework you have (major and minor version plus service pack).
- If you are using the .Net 1.0 component we shipped in XPE SP1, it will be 1.0 SP2.
- If you are using the .Net 1.1 component we shipped in XPE SP2 or as a QFE to XPE SP1, it will be 1.1.
- If you are using the .Net 1.1 component in the value-add folder of XPE SP2, it will be 1.1 SP1.
- If you are using .Net 1.0, get the test package from http://www.microsoft.com/downloads/details.aspx?FamilyID=33d4d33e-473f-4842-a3a8-c8266aee8fab&DisplayLang=en.
- If you are using .Net 1.1, get the test package from http://www.microsoft.com/downloads/details.aspx?FamilyID=e54be8be-22af-4390-86e1-25d76794d5c7&DisplayLang=en.
- If you are using .Net 1.1 SP1, get the test package from http://www.microsoft.com/downloads/details.aspx?FamilyID=9bbd5617-49ae-40bf-b0fa-f9049349c6f5&DisplayLang=en
You will need to choose the version that is specifically marked for "Tablet PC / Media Center" (for 1.0 hotfixes) or "Windows Server 2003" (for 1.1 hotfixes). Note that you can’t use the regular Windows XP Pro update – we use a different install method for .Net on XPE that confuses the update installer.
<name of exe> /x:<folder>.
Note that this key name should be changed as needed to 1.0 or to a different service pack level if there is a higher .Net Framework SP installed. This key is unnecessary for .Net 1.1 installs.
update*.inffiles in the update folder. There is a
[Version]section at the top that you will need to update the following values for:
The values of Min, Max and This for service pack should match the CSDVersion value in your registry at HKLM\System\CurrentControlSet\Control\Windows. For example, for XP Embedded SP2 this value should be 512, for XPE SP1 this value is 256.
update.exefrom the update folder on your embedded device (assuming your embedded device has the Desktop QFE Installer support component, or includes the dependencies
update.exeneeds to run correctly).
We have verified these steps via PSS and Test, and they work as advertised.
Pain in the butt? You’re right – we’re working on a quicker, simpler way of doing this with DUA. If you’re not using DUA, you’ll have to either do these steps manually or script them yourself – the easiest way I can see would be to prep the install in steps 1–4 and step 6 once, then write a script that makes the registry changes and runs the installer for steps 5 and 7.
Wednesday, March 02, 2005
The article itself isn’t what’s interesting here (well, it’s interesting, but on a different level) – it’s the last three paragraphs that summarize the relevant portions of the book “They Made America”:
Describing the development of CP/M, [Harold] Evans wrote that "[Gary] Kildall created the bedrock and subsoil out of which the PC software industry would grow."
"Entirely out of his own head, without the backing of a research lab or anyone, he wrote the first language for a microcomputer operating system ... before there was even a microcomputer," Evans wrote.
Huh? Obviously, the author never read “Fire in the Valley”, or just chose to ignore Steve Wozniak, Steve Jobs, and the entire Apple computer company, who had a working microcomputer (which I cut my programming teeth on back in the day) well before IBM ever decided to make the PC.
I remember when a personal computer – a normal desktop machine – had less memory in it than the smallest flash cards you can buy. My first computer, and Apple //c, had 128Kb (yes, that’s kilobytes) or memory, which was double the RAM of the other Apple ][ models. Nowadays we’re building embedded systems that run on 1Gb CF cards with half a gig or RAM, and my 64Mb Pocket PC can use 512Mb SD cards no bigger than my thumbnail. I’m not sure what to be more depressed over – that I can carry more computing power in my pocket than I had twenty years ago, or that I’m not even 40 yet and already talking nostalgic about “the good ole days”…
Yes, we all know that, as a U.S. citizen, he can’t carry a title of nobility, but there is is anyway. He can’t go by Sir William, but he can sign his name Bill Gates, K.B.E. (Knight of the British Empire). And no, I don’t know if he’s taking jousting or swordsmanship training… :-)
Friday, February 25, 2005
Sean's covered most of XPE SP2, and relied heavily on the Embedded community to give him pointers, tips, and info. The updated Tips and Tricks from Embedded's own Lynda Allen are worth the read in and of themselves (ignore the MS ID numbers - they're just SQL ID fields and mean absolutely nothing to anyone). And the tools are worth the price - heck, Component Tracker alone is worth the price (it gives you all sorts of cool info about a component, like a list of dependencies and what depends on the component). Highly recommended - check out Sean's website for more details.
I don't know how good a reviewer I can be, but as I read it, I'll dump my thoughts here.
Tuesday, February 22, 2005
We've had some recent issues with the .Net security update for XPE desktop installs (MS05-004, KB 887219, ASP.NET Path Validation Vulnerability). The way we do .Net installs on XPE isn't the way the update package thinks it should be, so the update won't install on XPE runtimes. We're going to pull the update from the OEM Secure Site, and are working on a way to make this work for XPE runtimes. Sorry for the problems.