Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please restore our registers when you’re done with them

randomascii.wordpress.com

Post reply on HN
Print view View original

131–140 of 142 posts

Re: Please restore our registers when you’re done with them

#131

Post by skissane »

brucedawson wrote: post #127
skissane wrote: post #97

Earlier quoted context omitted.

> In this case I don't understand how the state leaked from the file-system filter driver to our process, as it seems to have done. I assume you made some Windows API call somewhere, which ended up in the filesystem filter driver, which then clobbered the register. And I'm guessing the NT kernel code and Windows DLLs never save/restore the register, because it isn't supposed to be clobbered. Couldn't one approach be…

Those tactics could work. They would be a bit expensive however, and it would be a shame to have all users paying the performance penalty because of a few bad pieces of software. And, this would not have caught the two errors in the assembly language code within Chrome - that would require testing at every function call, not just Windows API calls. It would be more practical (I think) to do this checking on a special…

> They would be a bit expensive however

It would be interesting to see measurements of how big the expense is.

Also, I don't think one necessarily has to do it for every Windows API call – some Windows API calls are more likely to invoke third-party code than others; some API calls are far more performance-critical than others. Maybe one could find a subset of calls to focus on which maximise the likelihood of invoking third-party code but also minimise the performance impact.

> And, this would not have caught the two errors in the assembly language code within Chrome - that would require testing at every function call, not just Windows API calls

For code you control, I think some kind of static analysis would be a better approach – parse inline assembly code and check that every register it touches is marked as clobbered to the compiler. I saw some other comments you were replying to already on that topic. I think this kind of "dynamic" approach should be reserved for third-party code with low trustworthiness.

> It would be more practical (I think) to do this checking on a special build of Chrome that is shipped to a small percentage of users, so that not everybody pays the price.

I was thinking, you could also do it using API hooking. Have some hidden setting to control it, by default off. If it is off, no impact, same as now. If the flag is on, hook (some subset of) Windows APIs with the "unexpected-register-clobber-detector". That way you don't have to produce two completely different builds.

And maybe even, automatically turn that flag on if an install starts to experience crashes–especially if the presence of certain kinds of third-party software is detected.

> But, this is an ecosystem problem and I'm not sure Chrome wants to shoulder the entire burden of finding bad software :-)

Agree. Ideally, Microsoft would take the lead there, since it is their platform. But a world in which the Chrome team does it would be better than a world in which nobody does.

Re: Please restore our registers when you’re done with them

#132

Post by Iwan-Zotow »

astrange wrote: post #111
matthews2 wrote: post #29

Earlier quoted context omitted.

Maybe we need some kind of higher level language that gets boiled down into assembly.

C does have official intrinsics for SIMD on Intel platforms, but the people who are good at writing video codecs don't like to use them because Wintel culture has such bad taste at naming functions (thanks to Hungarian notation) that using them is near-unreadable and it's easier to write everything in asm.

You're wrong. Intrinsics for SIMD are not named by Windows people. They were named by Intel engineers and supported now by all other compilers. Naming is actually in the C/C++ style - __simd_do_something_here() and such

Re: Please restore our registers when you’re done with them

#133

Post by Iwan-Zotow »

bombcar wrote: post #6
gumby wrote: post #4

Earlier quoted context omitted.

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 a…

common (and actually recommended) idiom on intel/amd is to do 'xor reg,reg'

Re: Please restore our registers when you’re done with them

#134

Post by brucedawson »

gumby wrote: post #13
bombcar wrote: post #12

Earlier quoted context omitted.

It seems to me something that could be found by some kind of valgrind-like tool - it'd be much slower than normal code but "ABI exception detected" or something.

Not worth checking for. The few people who write assembly code these days know what they are doing, and, bugs aside, the compiler knows what to do.

Interesting conclusion given that I found two functions and a (presumed) third-party driver/what-not that were violating the ABI. One of these was causing crashes, and the other one was going to. The crashes went on for over a year and a half, so, ...

Re: Please restore our registers when you’re done with them

#135

Post by astrange »

Iwan-Zotow wrote: post #132
astrange wrote: post #111

Earlier quoted context omitted.

C does have official intrinsics for SIMD on Intel platforms, but the people who are good at writing video codecs don't like to use them because Wintel culture has such bad taste at naming functions (thanks to Hungarian notation) that using them is near-unreadable and it's easier to write everything in asm.

You're wrong. Intrinsics for SIMD are not named by Windows people. They were named by Intel engineers and supported now by all other compilers. Naming is actually in the C/C++ style - __simd_do_something_here() and such

I am not wrong and I'm not talking about those.

The Intel platform intrinsics have names like `_mm512_4dpwssd_epi32()`. The standardized SIMD intrinsics with `simd` in the name are much newer than any of the code I'm talking about in ffmpeg/x264/dav1d. These are okay, but not being platform-specific of course means you don't get platform-specific features, which you might want when you're doing this level of optimization.

The other problem is compilers (esp. gcc) were traditionally very bad at code generation for them, although these days they're okay at it.

Re: Please restore our registers when you’re done with them

#136

Post by dblohm7 »

srcreigh wrote: post #90
dblohm7 wrote: post #35

I used to take point for Mozilla's efforts dealing with third-party interference in our binaries. Browsers are ripe targets for this kind of shit. The stories we could tell...

Please write some stuff about this

I did write a little bit! Here's an oldie but a goodie:

https://dblohm7.ca/blog/2016/01/11/bugs-from-hell-injected-t...

Re: Please restore our registers when you’re done with them

#137

Post by dblohm7 »

harry8 wrote: post #71
dblohm7 wrote: post #35

I used to take point for Mozilla's efforts dealing with third-party interference in our binaries. Browsers are ripe targets for this kind of shit. The stories we could tell...

And from our perspective you should! Would be interesting.

I did write a little bit! Here's an oldie but a goodie:

https://dblohm7.ca/blog/2016/01/11/bugs-from-hell-injected-t...

Re: Please restore our registers when you’re done with them

#139

Post by Wowfunhappy »

JoshTriplett wrote: post #79
cpeterso wrote: post #51

Earlier quoted context omitted.

Yes. That's pretty common, unfortunately.

I'd love to see Chrome and Firefox and IE working together to detect this kind of thing and put up a malware warning explaining how to uninstall it, and see how quickly it can be eliminated. Seriously, there is zero valid reason to ever inject code into another program, other than as a debugging tool on a system being debugged.

> Seriously, there is zero valid reason to ever inject code into another program

Sometimes, I use software which does not work the way I would like it to work. When this software is closed source, and the problem sufficiently annoying, I inject code to make it do what I want.

(And no, once I do this I don't open bug reports, unless I can reproduce the problem without code injection.)

Because that's the great thing about owning a computer, and knowing how to really use it. It's a tool for you to command.

Now, will most people ever do this? No. I wish everyone could, but unfortunately, injecting code in a useful way requires a reasonable amount of coding knowledge.

But, this is Hacker News. I would hope most users here can come up with lots of valid reasons to inject code into other programs.

Re: Please restore our registers when you’re done with them

#140

Post by JoshTriplett »

Wowfunhappy wrote: post #139
JoshTriplett wrote: post #79

Earlier quoted context omitted.

I'd love to see Chrome and Firefox and IE working together to detect this kind of thing and put up a malware warning explaining how to uninstall it, and see how quickly it can be eliminated. Seriously, there is zero valid reason to ever inject code into another program, other than as a debugging tool on a system being debugged.

> Seriously, there is zero valid reason to ever inject code into another program Sometimes, I use software which does not work the way I would like it to work. When this software is closed source, and the problem sufficiently annoying, I inject code to make it do what I want. (And no, once I do this I don't open bug reports, unless I can reproduce the problem without code injection.) Because that's the great thing ab…

There's a huge difference between "I, the user of this system, am intentionally injecting code into a process to debug/extend it in a way I want, and if it breaks I'll have a pretty good idea that it might be my injected code's fault and know where to start looking" and "software that I may not even have intentionally installed on this system or understand the function of has broken other software on this system".
Post reply on HN