It has been possible in the past to assume that, if you’re running at DISPATCH_LEVEL on a given physical processor, you can get away with less locking if you do per-processor data structures. It makes sense: you are guaranteed to be the only thread in your code on that CPU until you’re done, since you can only be preempted by threads > DISPATCH_LEVEL, and your DPC will pick up where it left off once the system returns to DISPATCH_LEVEL. With a per-processor queue or other data structure, accesses from DISPATCH_LEVEL are guaranteed to be atomic.

Well, for reasons that will become clear over the next few months, that strategy is no longer possible. There may be cases in future versions of Windows that allow different physical processors to be assigned the same processor ID. That means that two different threads running at the same time on different processors might wind up colliding on the same queue.

Of course, this also implies that data structures that were once assumed to be per-processor exclusive (i.e. singletons) will no longer necessarily be so. If you’re using processor number as a key that you assume is globally unique, e.g. managing some initialize-once data or something, you will need to re-think your architecture.

If you don’t generally deal with processor numbers, none of this matters to you. For those that do, however, if you do anything "smart" with processor numbers, you may have some re-thinking to do.

-Steve

http://www.youtube.com/phonefactor

Thanks to Dan Leafblad for doing all the hard work to pull this together. And Shame on Evan Conway for making me wear a conehead hat. It looks… well… just watch the video…

Traut runs a team of about 200 software engineers at Microsoft that is responsible for the core kernel scheduling, memory management, boot sequence, and virtualization technology such as Virtual PC and Virtual Server. The latter technologies are becoming more and more important as servers get more powerful and gain more and more CPU cores, and it was clear from the demonstration that Microsoft is placing significant effort into integrating virtual machine technology into everything that they do.

As I’ve written before, I think a focus on (high-scale) multi-core will be a key to the OS’s success going forward. Anyway, check out the video linked from the article.

UPDATE: Ken covered this a while ago regarding a similar decision by AMD.

Once you get over the character-mode interface, it actually has a ton of neat features, including a nice disassembler, and basically everyone I’ve asked in the hex-editing community (?) concurs that it’s the only thing they’d ever use to modify a binary.

So, I loaded up my pcap file and searched around for the bytes to modify. I found the (long) block of hex that I wanted in another capture file and went to copy the bytes. Then I tried to open another file and past them in. Hmm, nope, not supported!

Then I tried re-arranging bytes within the same file. Nope! Not (obviously?) supported, at least without overwriting things.

So, in a bit of a huff, I fired up Visual Studio 2005 and instantly copied and pasted the bytes I needed and achieved a state of happiness in mere seconds.

I’m sure there are a lot of people that will be able to tell me how to get hiew to do this, and I’m sure I could have written a script or something, but… life is to short to learn Yet Another Non-Obvious Editor.

So, I’m sure hiew is great, and if I ever need to hex edit a PE image, I’ll certainly keep it in mind. But for network packets - back to VS!

UPDATE: I am a dumbass. I cannot believe I left the title "your hex editing" instead of "you’re" - the shame!

I think I forgot to mention the release of the 8th volume of Uninformed a couple of weeks ago as well. Lots of good stuff there. Some of the same (bright) people are involved in both Metasploit and Uninformed.

For those that haven’t used it before, the current err.exe indexes 22,851 error codes from 171 sources. Pass it a magic number from somewhere and it’ll make sense out of it!

Enjoy!