Please restore our registers when you’re done with them
randomascii.wordpress.com
Please restore our registers when you’re done with them
1–10 of 142 posts
Re: Please restore our registers when you’re done with them
#2No post body was provided.
Re: Please restore our registers when you’re done with them
#3It’s interesting that there is a zero stored in a register and used for hours - is that significantly faster than just using some actual zero each time? Perhaps CPUs need a “always zero” register or some similar menomic to help harden.
Re: Please restore our registers when you’re done with them
#4It’s interesting that there is a zero stored in a register and used for hours - is that significantly faster than just using some actual zero each time? Perhaps CPUs need a “always zero” register or some similar menomic to help harden.
Many architectures do have a 0 register because the value is useful. Others have a zero instruction (or both).
What would an "actual zero" be -- a literal?
Re: Please restore our registers when you’re done with them
#5It seems that the chrome developers should be able to perform the same binary analysis on the suspect Mcafee software. I guess it's a bit harder without source code to reference side-by-side though.
Re: Please restore our registers when you’re done with them
#6It’s interesting that there is a zero stored in a register and used for hours - is that significantly faster than just using some actual zero each time? Perhaps CPUs need a “always zero” register or some similar menomic to help harden.
Many architectures do have a 0 register because the value is useful. Others have a zero instruction (or both). What would an "actual zero" be -- a literal?
Yeah, something like "mov ax, 0h" but I suppose that is way more memory intensive as you have to load a 0 into memory somewhere and then copy it into the register.
It strikes me as somehow the compiler is making assumptions that aren't being enforced by the ... OS? Language? not sure what, but it's assuming functions restore registers used but that isn't enforced by anything. From my (long ago) time there was PUSHA and POPA but I assume those take quite a bit of "oomph" and are avoided if possible.
Re: Please restore our registers when you’re done with them
#7One of the linked pull requests: https://github.com/cisco/openh264/commit/db956674bbdfbaab5ac...
Macros in a macro assembler .. not very nice.
Re: Please restore our registers when you’re done with them
#8One of the linked pull requests: https://github.com/cisco/openh264/commit/db956674bbdfbaab5ac... Macros in a macro assembler .. not very nice.
He even mentions that it's Windows-specific, both in the commit message and in the article... and then seemingly fails to make it Windows-only? That's "not very nice" either.
Re: Please restore our registers when you’re done with them
#9One of the linked pull requests: https://github.com/cisco/openh264/commit/db956674bbdfbaab5ac... Macros in a macro assembler .. not very nice.
He even mentions that it's Windows-specific, both in the commit message and in the article... and then seemingly fails to make it Windows-only? That's "not very nice" either.
[deleted]
Re: Please restore our registers when you’re done with them
#10One of the linked pull requests: https://github.com/cisco/openh264/commit/db956674bbdfbaab5ac... Macros in a macro assembler .. not very nice.
He even mentions that it's Windows-specific, both in the commit message and in the article... and then seemingly fails to make it Windows-only? That's "not very nice" either.
Those PUSH_XMM/POP_XMM macros appear to be Windows-only; I think they expand to nothing on other platforms because they contain their own guard for Windows internally. If that's the case, the call sites don't need to guard for it. I'm guessing that obeying this calling convention is the purpose of those macros.
https://github.com/cisco/openh264/blob/db956674bbdfbaab5acdd...
https://github.com/cisco/openh264/blob/db956674bbdfbaab5acdd...