|
From: Christian B. <bor...@de...> - 2011-04-20 08:54:50
|
Folks, Currently Divya is doing some more work on missing instructions for s390x (e.g. stck, translate etc.). I will open bugzillas for these when the patches are ready. There are some crypto instructions (hashing, DES, etc.) which we also want to implement. These instruction get a parameter block two memory fields and a length. Since crypto cannot be modeled in an efficient way we first thought that a dirty helper might be the right solution, but there are some problems: - Dirty can only have one memory area - The length field (mSize) cannot be an IRTemp What might be a good approach to tackle these instruction? Can we enhance Dirty helpers to accept multiple memory areas with dynamic length fields (this would require changes in most tools, I guess)? Any better ideas? Christian |
|
From: Julian S. <js...@ac...> - 2011-04-20 09:25:34
|
> Since crypto cannot be modeled in an efficient way we first > thought that a dirty helper might be the right solution, but there are > some problems: > - Dirty can only have one memory area > - The length field (mSize) cannot be an IRTemp > > What might be a good approach to tackle these instruction? Can we enhance > Dirty helpers to accept multiple memory areas with dynamic length fields > (this would require changes in most tools, I guess)? This would be particularly complicated for Memcheck. See do_shadow_Dirty and do_origins_Dirty in mc_translate.c for the current handling. It's not pretty. Can you explain more about the instruction(s)? What exactly are the inputs and the outputs? I am wondering if this can be done somehow using clean helpers. J |
|
From: Christian B. <bor...@de...> - 2011-04-20 11:01:04
|
Am 20.04.2011 11:24, schrieb Julian Seward: > Can you explain more about the instruction(s)? What exactly are the > inputs and the outputs? I am wondering if this can be done somehow > using clean helpers. One example is the KM (Cipher Message) instruction: KM R1,R2 Register 0 contains the function code(e.g. KM-AES-256) Register 1 contains the parameter block (e.g. the key) Register R1 contains the address of the target Register R2 contains the address of the source Register R2+1 contains the length of the source Your comment about clean helper made me rethink and I was rereading that stuff again. The encryption functions seem to be ok. It seems that the length must be a multiple of the basic data block size (e.g. 16 for AES) and for the ones I checked, the output is really calculated blockwise. (the chaining value is updated in the parameter block). These instructions have a startup cost, so just doing 8 or 16 bytes at a time is slower but it probably should work reasonably enough. Then I have to find a good way to let a clean helper return a 128 bit value. The message digest functions (e.g. SHA512) will be a little more tricky, since they have up to 128byte as data block size. Here we might need a dirty helper instead of a clean one. And I still dont know how to pass back 512bits without going over memory. Christian For reference the instructions KM, KMC, KLMD, KMAC etc. are in http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr008.pdf |
|
From: Julian S. <js...@ac...> - 2011-04-20 11:46:20
|
> These instructions have a startup cost, so just doing 8 or > 16 bytes at a time is slower but it probably should work > reasonably enough. Yeah. This is kind of similar to the way CRC32 works on amd64. > Then I have to find a good way to let a clean > helper return a 128 bit value. I don't know of any good way using the existing IR infrastructure. One bad way I have used in the past (try not to die laughing) is to call the helper twice, passing it a bool that indicates whether it should return the lower or upper 64 bits of the result. Yes, it's brain-dead-moron stuff. But yes, it works. See amd64g_calculate_RCR(). In fact it is very annoying not to be able to pass 128 bit values to/from clean helpers -- it has caused a lot of extra complexity in the SSEx implementations. And in future for AVX I suspect I will want to pass 256 bit vectors to/from helpers. It would be good perhaps to contemplate how to extend the clean helper IR stuff just a little bit, so it is possible to pass 128 values in/out by reference. Maybe the cleanest solution is to allow args and/or result type to be Ity_V128, and put the burden on the instruction selectors, so that when they see such an arg type or result type, they generate code to allocate space on the (host) stack, and pass the address of that instead to the helper. Of course this means we'd also have to document that a helper function expecting to deal with such arguments must pass/return them by reference. IOW specify how to write such a function in a way that is compatible with the proposed instruction selector changes. > The message digest functions (e.g. SHA512) will be a little more > tricky, since they have up to 128byte as data block size. Here > we might need a dirty helper instead of a clean one. And I still > dont know how to pass back 512bits without going over memory. I have no suggestions for that. J |