A few stray notes on Windows patching and hot patching


Miscellaneous notes, largely unorganized.

  • A lot of people questioned the specific choice of MOV EDI, EDI as the two-byte NOP, with many people suggesting alternatives. The decision to use MOV EDI, EDI as the two-byte NOP instruction came after consulting with CPU manufacturers for their recommendations for the best two-byte NOP. So if you think something better should have been used, go take it up with the CPU manufacturers. They're the ones who came up with the recommendation. (Though I suspect they know more about the best way to optimize code for their CPUs than you do.)
  • You can enable hotpatching on your own binaries by passing the /hotpatch flag to the compiler.
  • The primary audience for hotpatching is server administrators who want to install a security update without having to reboot the computer.
  • There were some people who interpreted the presence of hotpatch points as a security hole, since it makes it easier for malware to redirect OS code. Well, yes, but it didn't enable anything that they didn't already know how to do. If malware can patch your process, then it has already made it to the other side of the airtight hatchway. And besides, malware authors aren't going to bother carefully patching code to avoid obscure race conditions. They're just going to patch the first five bytes of the function without regard for safety, because that'll work 99% of the time. (It's not like the other 1% are going to call the virus authors when the patch fails.)
Comments (58)
  1. anyfoo says:

    This makes me curious what the arguments against MOV EDI, EDI are (no matter how correct they turn out to be)?

  2. Joshua says:

    @anyfoo: Mostly idiocy. I'd have used MOV EAX, EAX which is basically the same thing.

    Filler text to avoid the spam filter.

  3. Jon says:

    Intel's documentation recommends  0x66 0x90   as a 2 byte NOP,   not mov edi edi.

  4. Matt says:

    @Jon: Apart from on some architectures that's an invalid instruction, so you'll get an enormous fault up to the kernel and lose 10000 cycles every time you hit one of those on an old CPU.

  5. a random passerby says:

    Bother, my previous comment must've been filtered for being too long. But Matt makes a better point than I did, anyways.

  6. @Matt:

    Live pathing is only supported on the OS versions that don't run on ancient CPUs.

    [You're looking at the problem at the wrong level. What happens if somebody sets the /hotpatch flag for a non-OS app that intends to run downlevel? -Raymond]
  7. Joshua says:

    alegrl: Live pathing is only supported on the OS versions that don't run on ancient CPUs.

    A curious statement. I can find no evidence that /hotpatch is supported for x64. A Google search only turns up somebody complaining on the forums that it doesn't work (compiler complains). If there is no /hotpatch for x64 than we will soon be saying /hotpatch is only supported for ancient CPUs.

  8. [You're looking at the problem at the wrong level. What happens if somebody sets the /hotpatch flag for a non-OS app that intends to run downlevel? -Raymond]

    OK, 66 90 actually should not cause an exception on any 32+ bit architecture because it's XCHG AX,AX or XCHG RAX,RAX.

  9. a random passerby says:

    [66 90 actually should not cause an exception on any 32+ bit architecture because it's XCHG AX,AX or XCHG RAX,RAX.]

    @alegr1: Really. From the documentation I found 0x66 is an SSE2 extension introduced by the Pentium 4. XCHG is 0x86. And all 2-byte opcodes prefixed with 0x66 were introduced in P4 or later (and many were only introduced in Core 2). I'm not sure how 0x66 0x90 would ever be a valid byte patter prior to SSE2, and there are a lot of 32 bit processors that predate it.

  10. Csaboka says:

    @a random passerby:

    You should really search more thoroughly next time. 0x66 is the operand size prefix – it makes instructions 32-bit wide in 16-bit mode and 16-bit wide in 32-bit mode. See details here: wiki.osdev.org/X86-64_Instruction_Encoding

    Intel may have given it special meaning for more modern instructions, but for the basic instructions that are present in up to and including the 386, it affects the operand size.

  11. Josh says:

    0x66 is the operand size prefix and was present on the 386 –  ie.  on processors older than those that Windows NT runs on.

  12. Tom says:

    I've found a neat little code to insert hooks into hot patched compatible binaries (x86)

    http://www.secnews.pl/…/hot-patching

  13. Matt says:

    @alegr1:

    From the Intel processor manual:

    The one-byte NOP instruction is an alias mnemonic for the XCHG (E)AX, (E)AX instruction.

    The multi-byte NOP instruction performs no operation on supported processors and generates undefined opcode exception on processors that do not support the multibyte NOP instruction.

  14. @Tom says:

    Stop posting link-spam to your own website. There are plenty of free and better solutions for hooking APIs (see Detours, EasyHook etc).

  15. 640k says:

    Do these administrators know if all different versions of patches is backwards and forward compatible? No, because most patches can't be trusted to be compatible with hot-patching. How did this feature gain even -100 points?

  16. @Matt:

    How about actually reading what's written there in the said Intel manual, and paying attention to the opcodes of the multi-byte NOP commands there?

  17. Richard Russell says:

    Having written my own x86 assembler, I can confirm that 66 90 is indeed the opcode for 'xchg ax,ax' (in 32-bit mode).

  18. Joshua says:

    @640k: Because the Linux guys can indeed patch almost everything without rebooting. Really only kernel & X need to reboot, and sometimes not even X. For i386 if you're lucky someone will have a ksplice module for you so you don't have to reboot. MS just had to implement the same thing for security patches.

    [I like how it's "except the kernel, the window manager, and IPC." That's all the interesting parts! That's like saying "no part of the car is affected except the engine and the electronics." -Raymond]
  19. Maurits says:

    I find the soft hyphen to be more useful when many of the following are true:

    * Horizontal width of the column is low

    * Text is justified (both right- and left-aligned)

    * Words are broken far from their beginning or ending

    * (That is to say, only long words are broken, and then only in the middle)

  20. Matt says:

    @alegr, richard: I work at Intel. You are both wrong (and in richard's case, your x86 assembler is also wrong).

    There is no mneumonic for XCHG EAX, EAX, or XCHG AX, AX. This instruction does not exist.

    Opcode 90 is (and has always been) implemented in silicon as a NOP (pipeline ignore) not an XCHG. This is important because otherwise a NOP could cause pipeline stalls waiting for EAX (or AX)es value to be resolved by older processors who would then need EAX to be fully resolved (i.e. leave the register renaming unit for XCHG resolution) before EAX could be used.

    That is why 66 90 can cause an invalid opcode instruction on some older models. A memory-size prefix followed by a pipeline ignore is invalid; it is not, and never was an MEMPREFIX:XCHG a,a

    Later models (up to about PI) would ignore the error and continue, but it would still take longer to complete than a MOV.

    That is why our advice was not to use a 66 90, but to use a 2 byte mov. The reason we chose EDI was because EDI is the least likely register to still be in the pipeline at the start of a function (based on running about half a million programs through our simulator). Consequently using MOV EDI, EDI is less likely to cause a pipeline stall waiting for the register's result to be finalized from a previous "in-flow" instruction.

    I don't see why this is so hard. Raymond told you guys that the reason MOV EDI, EDI was chosen was because it was faster according to the processor team at Intel (and presumably AMD). Don't argue with them. If you disagree with the Intel processor team about what the fastest 2-byte NOP is, it's probably because you're wrong.

  21. Matt says:

    Spoke too soon. There is a mnemonic for XCHG EAX, EAX in long mode, (just not in legacy mode): 87 C0.

  22. anyfoo says:

    Matt, thanks for the insight, makes perfect sense.

  23. Danny Moules says:

    "Don't argue with them. If you disagree with the Intel processor team about what the fastest 2-byte NOP is, it's probably because you're wrong."

    yourlogicalfallacyis.com/appeal-to-authority

    Ah, the amount of times I've heard that argument from teams, vehemently certain they can't be at fault because they surely know their own application better than anyone, who then have major egg on their face when their application is shown to have a major security fault. The funny thing is they even have all the evidence up front but, because of their hubris, don't bother checking before they outright reject the assertion. They fail to realise that other people can choose, as their area of research, a third-party product – unladen with the bias of it being their own. The best authorities on Adobe security, for example, exist well outside Adobe.

    Note that I don't argue that they're not often more likely to be correct. Rather, I vehemently disagree with the assertion that nobody should bother trying to correct it. People who think that their authority means they should reasonably be beyond scrutiny are the sort of people who don't get their work properly reviewed – and are therefore rather more likely to have it shot down.

  24. Matt says:

    @Danny Moules: You, as an armchair critic with no actual understanding of processors, with no benchmarks and with no relevant experience do not understand Intel's processors better than the Intel processor team. You might know more than some people at Intel (e.g. people in finance) and some people outside Intel might know more than everyone at Intel (e.g. an ex-employee of Intel's or an expert at a competitor company). But Raymond didn't ask a random person at Intel, he asked the IAX processor team. And you are almost certainly not one of the tiny number of people qualified to assess, never mind the even smaller number of people qualified to contradict Intel's assertion about what the fastest effective nop on their processors is.

    In summary: If you disagree with the Intel processor team about what the fastest 2-byte NOP is, it's probably because you're wrong.

  25. Danny Moules says:

    You're still falling foul of the fallacy. My hobby (security research) is entirely based upon the premise that intelligent people can, and do, regularly disprove engineer's assumptions about their own products. Their 'authority' is irrelevant. Sony assert that nobody could possibly break their keys and then somebody does because they got sick of hearing it said. Social networks say they know their systems don't have holes and then it's shown they do (http://www.theregister.co.uk/…/menshn_password_reset_vuln).

    The fallacy is not assuming that people with authority are liable to be correct. It's assuming that because the team understand their product that everybody else is ill-suited to refute those assumptions. In fact, they are the most likely people to be blinkered because they will invariably look at things through 'Intel-coloured glasses', to paraphrase Raymond. In research peer review is not only desirable, it's considered necessary. The people who build a system are assumed to be the worst at assessing it (this assumption is patently not true but it's ultimately so useful as to be a mantra).

    Incidentally I assume you meant 'you' in the global term. Unless you think I'm trying to represent myself as somebody who could prove the the team's assertion wrong. That's certainly not the case, I'm talking about a principle. e.g. Bruce Schneier does not build his own crypto systems in a vacuum. He openly asks everyone to challenge his assertions. Although the leading expert on his algorithms or his lectures, he gets plenty of valid criticism which ultimately makes his work even better. This is true of the entire cryptographic profession. Nobody with any sense 'rolls their own', even if they are the best in the world. It's just too damn complicated for a crack team of the best to do by themselves with any reliability. I know from my own experience with writing kernels and poking around GPUs that this level of complexity is shared in processor-land.

    Being the best does not make you infallible. Therefore it's unreasonable to suggest (as you did initially) "Don't argue with them". People can, and do, argue with leading authorities all the time and win. That's pretty much what research is about. I have no problem with your summary, that people who challenge them are likely to get their asses handed to them (because they are) but that's no justification for nobody to try. That assertion is fundamentally based on a logical fallacy.

  26. Jon says:

    @Danny Moules

    The "probably" is in his statement because there is a slight chance there is a better solution. Yes, the argument is an appeal to authority, but it certainly is a good one. Microsoft decided to put a 2-byte NOP in every function call, so they definitely wanted to be certain that it was as efficient as possible. They went out to the appropriate experts in the field (such as the IAS processer team), which also certainly understood the importance of giving the best possible answer. After all this research they used the NOP given in the article, because a team of experts agreed that it is the best solution. There is a chance that someone can find a better NOP, but there is no reason for anyone here to assume that the ideas they throw out off the top of their heads are going to work better than what Intel, Microsoft and presumably other manufacturers determined – I suspect that pretty much any idea given in this thread or the previous one was already considered and ultimately rejected. If someone would bother to explain why they think their NOP is better with a well-reasoned argument (it could be safely assumed that Intel had a well-reasoned argument even before Matt's post), then I'm sure you could get some civil discussion about the solution.

  27. Another Jon says:

    My argument isn't about which NOP is the best,  it's about the documentation.

    If Intel think mov edi,edi  is the best 2-byte NOP,  then why does the documentation say to use 66 90 ?

    [66 90 is probably the best 2-byte nop if you know that your CPU supports it. But Windows needs to run on processors which may not support 66 90. -Raymond]
  28. Random User 68973290 says:

    @Another Jon

    Probably because, while "mov edi,edi" is usually in effect a NOP at the start of most functions, is is not in fact a true NOP. As Matt points out, the MOV can cause a pipeline stall waiting on registers.

  29. ErikF says:

    @Another Jon: Which documentation are you looking at? Features and best practices have changed throughout the IAx86 series of processors, so it's quite possible that what you have is correct for a certain class of processor but not necessarily all classes.

  30. Random User 68973290 says:

    "if you know that your CPU supports it"

    Oh, right. Probably more that than what I said.

  31. [66 90 is probably the best 2-byte nop if you know that your CPU supports it. But Windows needs to run on processors which may not support 66 90. -Raymond]

    Um, 66 90 is even supported by 80386. The only issue was that old Pentiums might not optimize this opcode as NOP.

    [According to this web page, it raises #UD on CPUs prior to family 6 (Pentium Pro). Note also that there are CPU manufacturers other than Intel. Do you know for sure that the Cyrix 6×86 can handle 66 90? -Raymond]
  32. Matt says:

    @Danny: "Being the best does not make you infallible"

    No, but it means that in a random crowd of people, several of whom know nothing about your product, but off the top of their head claim that "X" to be true about a thing you spend 9-5 researching and benchmarking for thirty years, it is so infintessimally small that they are right entirely by accident that it's almost not worth the argument.

    If you've studied it, be my guest and announce your findings. But don't claim that an expert panel are wrong off the top of your head without actually having the first bit of knowledge about the subject area at all or performing any real tests to check.

    Suggesting that an Intel processors team with their combined years of expertise and massive benchmarks will have mistakenly said "mov edi, edi" to the question "what is the fastest 2-byte nop – I need to know because that OS that runs on your processor that most of your customers use and will use to benchmark you against your main competitor is about to have this two byte sequence liberally sprinkled all over it, and if you give me the wrong answer it will be bad for your business", but would have entirely forgotten to check the performance versus the "2-byte nop" opcode says more about your understanding than about the experts'.

    Regards the security stuff, I think you have a very strange view of "expert". Here is a hint: Intel knows a LOT about benchmarking their processors. Louise Mench – famed for being an MP who writes adult books and who quit in the middle of her job after admitting to taking class-A drugs, knows very, very little about securing websites.

  33. OK, Dr. Matt,

    The Big Disagreement here has been whether 66 90 could be used at all. You claimed 66 90 will cause #UD on some processors that can run Windows NT. Because shaking hands with Intel experts makes you also an expert.

    The reality is that 66 90 is not a multy-byte NOP (which may not be supported on older processors). It's a single byte NOP (equivalent to XCHG EAX, EAX) which may or may not be optimized into NOP by a particular pipeline design, with an operand size prefix, and is supported since 80386.

    This is the end of story.

  34. JDP says:

    It's like Composition 101 all up in here. A fallacious appeal to authority is relying on an expert in field A for information or advice in field B. Ex: "I trust Danny Moules to explain argumentation because he knows his stuff when it comes to computer security."

    In the kind of example Danny gave above, there's a strong inductive argument in listening to an expert in his field. Yes, that expert may be proven wrong, but it's not per-se example of a fallacy to believe him or take his advice in his field of expertise.

  35. Matt says:

    @alegr1: What the hell are you talking about? 66 90 isn't a single byte, it isn't an XCHG EAX, EAX (nor is it equivilent to one – try it in long mode if you don't believe me) and on a substantial number of machines at the time when the question was asked 66 90 would either #UD or run orders of magnitude slower than MOV EDI, EDI.

    THAT is the end of the story.

    In fact, it was obviously the end of the story because Raymond said "We asked Intel and they told us the answer".

    Much as you and Danny might like to believe otherwise, magically summoning the answer out of your gut feelings and trying to claim that you now know better than the world's biggest collection of processor experts who were asked a business-critical question about a field they collectively have hundreds of years studying and who actually did the tests which clearly prove you wrong is more an indication of your egomania than an indication of your massive intellect.

  36. Matt,

    On which CPU 66 90 would #UD and in which mode? Have you actually ever tried it (or had an architecture expert confirm that)?

  37. Maurits says:

    We seem to be moving from "appeal to authority" to "ad hominem"…

    The point Danny raises is valid (or not valid) regardless of Danny's personal expertise.

    "Because the processor vendors said so" is an excellent business answer to "why do we use this particular NOP?" but an unsatisfying engineering answer, because it just raises the follow-up question "OK, but why did the processor vendors favor that NOP?"

  38. Paul Parks says:

    @Maurits: I believe Matt answered the question about why MOV EDI,EDI was used in the comment at 2013/1/3 4:40 AM.

  39. Adrian says:

    @alegr: Matt also answered that one

    "From the Intel processor manual:

    The one-byte NOP instruction is an alias mnemonic for the XCHG (E)AX, (E)AX instruction.

    The multi-byte NOP instruction performs no operation on supported processors and generates undefined opcode exception on processors that do not support the multibyte NOP instruction."

    The fact that Intel say that multibyte NOPs (of which they explicitly mention 66 90 as a multibyte nop) can generate undefined opcode operations proves his point. They didn't say "one and two byte nops won't generate a #UD". They just said that one byte ones won't.

    Stop being a d*. You're clearly wrong.

  40. Dave says:

    "On which CPU 66 90 would #UD and in which mode?"

    The documentation is clear.  Raymond quoted it earlier

    The multi-byte form of NOP is available on processors with model encoding:

    • CPUID.01H.EAX[Bytes 11:8] = 0110B or 1111B

    This means multi-byte NOP is supported on families 6 and 15.   Which is Pentium Pro and newer.  Check the AMD documentation for the other half of the market.

  41. @Adrian, Dave:

    Multi-byte NOP has two-byte opcode 0F 1F. One can have longer NOP command by using different addressing modes of these opcodes. and adding prefixes to them. In the Intel Architecture document, only 0F 1F is ever called multi-byte NOP. Only this opcode support is indicated by the said CPUID bit.

    0x90 is a single-byte NOP, equivalent to XCHG EAX. A 0x66 prefix (operand size) doesn't magically make it an invalid opcode, because it's still a valid instruction on all IA32 CPUs.

  42. A 0x66 prefix (operand size) doesn't magically make it an invalid opcode, because it's still a valid instruction on all IA32 CPUs.

    More on that. Opcodes from 0x90 to 0x97 are single-byte XCHG to a register, it's been this way since 8086, and it still means the same in the extended mode. Starting with 80386, an operand length prefix (0x66) could be applied to this command. There was no special case for 0x90 to make it an invalid to use with 0x66. 80486, Pentiums, etc kept it the same, because a) why bother, b) it would break existing software.

  43. Matt says:

    66 90 is a multibyte nop. You can tell this not only by the fact that it has multiple bytes and is a nop, but because it appears in "Table 4-9.  Recommended Multi-Byte Sequence of NOP Instruction" of the Intel IA32 manual as entry "2 bytes: 66 90".

    90 is not an XCHG EAX, EAX in IA32 (90 was a XCHG AX, AX before the 8086, but since the 8086 it's been a NOP).

    This discussion is getting boring. Proof that NOP isn't an XCHG:

     MOV RBX, 1122334455667788h

     XCHG EBX, EBX

    result: RBX = 0000000055667788h

     MOV RAX, 1122334455667788

     db 90 ; // what you think is an XCHG EAX, EAX

    result: RAX = 1122334455667788h.

    This discussion is getting boring alegr. The reason why Mov EDI, EDI is the best 2 byte nop at the point where Microsoft asked is because that is the 2 byte sequence that Intel told them.

  44. Matt:

    So what you're saying 66 90 has suddenly become an invalid opcode on some processor architecture? You're mistaken.

  45. Gabe says:

    Matt: When you say "90 was a XCHG AX, AX before the 8086", what came before the 8086? The 8008 and 8080 preceded it, but 90 was a subtraction opcode on those chips.

    alegr1: Matt isn't saying that the opcode has "suddenly" become invalid; he said it was invalid on some older architectures. The 90 opcode has to be implemented as a NOP to prevent pipeline stalls. Since 66 is not a valid prefix for a NOP, 66 90 is not a valid opcode. While that combination may be ignored by current architectures, it does not mean that it always was.

    Regardless, if 90 is implemented as XCHG AX, AX then it will be slow because it will cause a pipeline stall, making it ineligible for use in hot patching.

  46. From Raymond's link, support is only conditional for the 3+ byte form – the 0x0f1f variants; the 1 and 2 bytes are documented there as NOT raising #UD. It seems quite likely it's Matt and Raymond who are right about 0x6690 failing on earlier CPUs, and the documentation Raymond linked to could well be mistaken, but Raymond does seem to have missed the ">= 3 bytes" stipulation from his own link.

    Dave: the documentation Raymond cited stipulates 'multi-byte NOP' applies to the THREE (and more) byte forms only.

    I get the impression – and would certainly expect – that Microsoft consulted more than just Intel. As Matt notes, 'MOV EAX,EAX' sounds like an obvious candidate but actually has a nasty drawback (it will wait for the value of EAX to be current, even though it doesn't really matter); on the previous thread someone suggested 'lea esi, [esi]', which would have a worse version of that flaw on some cores (address generation interlock).

    On ARM the recommended NOP after a CPU mode transition used to be 'MOVNV R0,R0' (the NV – Never – conditional prefix negating the instruction's entire meaning anyway); irritatingly, ARM later deprecated the NV condition code then redefined it as "special purpose", recommending a plain "MOV R0,R0" as NOP instead.

  47. @jas88 says:

    "From Raymond's link, support is only conditional for the 3+ byte form – the 0x0f1f variants"

    download.intel.com/…/253667.pdf

    "The multi-byte NOP instruction performs no operation on supported processors and generates undefined opcode exception on processors that do not support the multibyte NOP instruction." suggests that the two byte form might raise a #UD. 66 90 is clearly included in the "multibyte nops" group as shown from the table that immediately follows it.

  48. [According to this web page, it raises #UD on CPUs prior to family 6 (Pentium Pro). Note also that there are CPU manufacturers other than Intel. Do you know for sure that the Cyrix 6×86 can handle 66 90? -Raymond]

    This page says that UD is only thrown for 0f 1f opcode.

    [You're right, I misread the table. But I wouldn't be surprised if it was suboptimal on older processors. -Raymond]
  49. JDP says:

    I like that the conversation's gone from "Well, what about THIS OPCODE?" to "Let's look at what intel's documentation says." Eventually people will check with AMD and get tenuously close to "after consulting with CPU manufacturers for their recommendations" as Raymond first wrote.

  50. Cheong says:

    [According to this web page, it raises #UD on CPUs prior to family 6 (Pentium Pro). Note also that there are CPU manufacturers other than Intel. Do you know for sure that the Cyrix 6×86 can handle 66 90? -Raymond]

    Indeed. According to this [ en.wikipedia.org/…/Cyrix_coma_bug ] Wiki page, XCHG instruction can leave Cyrix 6×86 processors in uninterruptable state forever. The fix is to insert NOP if you need to use XCHG at all.

    Therefore if you know your code will run on Cyrix processors, you'll want to avoid using it as NOP.

  51. 640k says:

    66 90 is the best instruction *Intel* can recommend *currently*. It has nothing to do with any hardware or any truth.

    1. Intel is not the only x86 cpu manufacturer in town.

    2. What Intel recommends today is not the same as they recommended yesterday and tomorrow.

    3. With Intel's compiler tricks in recent memory, actually the ONLY important metric Intel should optimize every answer for are stockholder value. Let's say the recommended instruction performs lousy on competitors hardware and mediocre on current Intel hardware, recommending that instruction gives the best value for Intel's stockholder, even if it performs worse than any other instruction.

  52. @cheong00:

    The cyrix problem is related to XCHG with memory operand (and possibly unaligned). It goes through absolutely different uops than a register XCHG, and also involves an implicit LOCK.

  53. MS should make it more prominent which KBs support hotpatching. It is an under-used feature.

  54. ShakeASpear says:

    Much Ado About Nopping

    *funny, no?  punny?  yes*

  55. Jon says:

    "It goes through absolutely different uops than a register XCHG"

    Like 66 90 then.

  56. Dave Oldcorn says:

    One interesting aspect is that you could potentially split nop into two different things: "some code that does nothing" and "an instruction to the processor to do nothing". The former implies using as few resources as possible, and the latter implies using a fixed amount of resource.

    Microsoft's desire in this case is explicitly for the former, and it's certain that NOP itself has (at least at some points in the past, and maybe on some architectures now) had the semantics of the latter.

    MOV EDI,EDI makes sense for this in that on a renaming CPU it uses only decode resources and rename resources (the rename potentially inducing a stall to wait for a previous EDI computation to complete). It's probable that no execution resources will be required at all.

  57. asklar says:

    re:"MS should make it more prominent which KBs support hotpatching. It is an under-used feature."

    It's not under-used, we don't use it (well, haven't really). Not all fixes are hot-patchable, and it takes only one hotfix/GDR to force a reboot for the whole batch in a patch Tuesday. The likelihood of being able to avoid a reboot due to hot-patching is close to zero.

    [Due disclosure] I work in the team that issues hotfixes/security updates/service packs, etc.

  58. Jeroen Mostert says:

    Well, I'm glad I checked back on this discussion, even though the popcorn is stale by now. What a performance.

    @Dave: if you want to get technical, there isn't really any difference between those two. Since the processor doesn't stop, a NOP does *something*, regardless of how its implemented — at the bare minimum, it increments the instruction pointer. Selecting a "good" NOP is harder than expected because 1. it must do nothing observable to a program, 2. it must work on all processor models we want to support, 3. if it slows down the program, it should do so to the least extent possible. As the discussion here shows, doing nothing well can be surprisingly hard. Perhaps the Tao Te Ching should be consulted, in addition to any processor manuals.

Comments are closed.