lkml.org 
[lkml]   [2009]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH] intel_txt: add s3 userspace memory integrity verification
part of answers.
Pavel Machek wrote:
> On Sun 2009-09-27 17:07:28, Shane Wang wrote:
>> This patch added verification for userspace memory integrity after
>> s3 resume. Integrity verification for other memory (say kernel
>> itself) has been done by tboot.
>>
>
> AFAICT, it verifies userspace _and_ kernel memory, that's why it does
> magic stack switching. Why not verify everything in tboot?
Because tboot only can access <4G mem and the memory is sparse.
Tboot likes to MAC the continuous mem.

>
> Is kernel<->tboot abi described somewhere?
>
>> @@ -168,6 +174,80 @@ static void tboot_create_trampoline(void
>> map_base, map_size); }
>>
>> +static vmac_t mem_mac;
>> +static struct crypto_hash *tfm;
>
> Could these be automatic?
We don't wish the memory is changing when MACing, including the static variables.

>> +void tboot_sx_resume(void)
>> +{
>> + vmac_t mac;
>> +
>> + if (!tboot_enabled())
>> + return;
>> +
>> + if (tboot_gen_mem_integrity(tboot->s3_key, &mac))
>> + panic("tboot: vmac generation failed\n");
>> + else if (mac != mem_mac)
>> + panic("tboot: memory integrity was lost on resume\n"); + else
>> + pr_info("memory integrity OK\n");
>
> So I corrupt memory, but also corrupt tboot_enabled() to return 0....
You corrupt the memory and tboot_enabled(). tboot MACing will find it.


> And... does panic kill the machine quickly enough that no 'bad stuff'
> happens? (Whats bad stuff in this context, anyway?).
Do you have some suggestions on it?

Shane

\
 
 \ /
  Last update: 2009-10-15 10:03    [W:0.195 / U:0.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site