* Herbert Xu | 2008-04-02 14:03:54 [+0800]:
>Sebastian Siewior <linux-crypto@xxxxxxxxxxxxxxxx> wrote:
>>
>> @@ -205,14 +208,22 @@ static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void *key,
>> static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
>> {
>> struct aes_ctx *ctx = aes_ctx(tfm);
>> - padlock_reset_key();
>> +
>> + if (last_key != ctx) {
>> + last_key = ctx;
>> + padlock_reset_key();
>> + }
>
>What if user-space invokes the padlock when xts is preempted?
>From VIA's programming guide:
|- EFLAGS:30 is set to 0 by any x86 instruction, interrupt, exception,
|task switch, etc. operation that causes EFLAGS to be stored (even if
|executed in 16-bit mode). Centaue Technology recommends using the
|instruction sequence PUSHFL; POPFL; prior to any REP XCRYPT instruction
|which uses a different key than the previous REP XCRYPT instruction.
|- EFLAGS:30 cannot be set to 1 by any x86 instruction that causes EFLAGS
|to be loaded. Only REP XCRYPT instructions set this bit to 1.
In that case we are safe aren't we? If we get preempted and user
space is invoked (or any other kernel thread) then the EFLAGS of the
task are restored what sets EFLAGS:30 to zero. Or did I misinterprete
it?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
