linux-kernel - RE: [PATCH] intel_txt: add s3 userspace memory integrity verification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <037F493892196B458CD3E193E8EBAD4F01EDB41C7E@pdsmsx502.ccr.corp.intel.com>
Date:	Thu, 15 Oct 2009 15:57:21 +0800
From:	"Wang, Shane" <shane.wang@...el.com>
To:	Pavel Machek <pavel@....cz>, "Rafael J. Wysocki" <rjw@...k.pl>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	"Cihula, Joseph" <joseph.cihula@...el.com>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"chrisw@...s-sol.org" <chrisw@...s-sol.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"jbeulich@...ell.com" <jbeulich@...ell.com>,
	"peterm@...hat.com" <peterm@...hat.com>
Subject: RE: [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--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/