linux-kernel - Re: [PATCH 3/4] driver: provide sysfs interfaces to access TXT log

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: <1367990202.2425.26.camel@x230>
Date:	Wed, 8 May 2013 05:16:43 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	Qiaowei Ren <qiaowei.ren@...el.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	Xiaoyan Zhang <xiaoyan.zhang@...el.com>,
	Gang Wei <gang.wei@...el.com>
Subject: Re: [PATCH 3/4] driver: provide sysfs interfaces to access TXT log

On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote:

> +What:		/sys/devices/platform/intel_txt/log/log_header
> +Date:		May 2013
> +KernelVersion:	3.9

How different are these logs to the TPM measurements exported via
securityfs?

> +What:		/sys/devices/platform/intel_txt/log/block_index
> +Date:		May 2013
> +KernelVersion:	3.9
> +Contact:	"Qiaowei Ren" <qiaowei.ren@...el.com>
> +Description:	The "block_index" property allows you to set the block
> +		index for output.

So I write a value here and then I see different chunks of log? This
doesn't seem like an optimal interface. What do these logs actually
contain? How do I know which block I should be reading?

> +static int are_uuids_equal(const struct uuid *uuid1,
> +			   const struct uuid *uuid2)
> +{
> +	return (memcmp(uuid1, uuid2, sizeof(*uuid1)) == 0) ? 1 : 0;
> +}

Use one of the uuidcmp functions from uuid.h?

> +EXPORT_SYMBOL_GPL(sysfs_create_log);
> +
> +MODULE_LICENSE("GPL");

Same as for the previous patch - you don't need these.

> +struct uuid {
> +	uint32_t data1;
> +	uint16_t data2;
> +	uint16_t data3;
> +	uint16_t data4;
> +	uint8_t  data5[6];
> +} __packed;

There's already UUID structures in uuid.h

> +#define TBOOT_LOG_UUID		{0xc0192526, 0x6b30, 0x4db4, 0x844c, \
> +				{0xa3, 0xe9, 0x53, 0xb8, 0x81, 0x74} }

uuid.h again.

-- 
Matthew Garrett | mjg59@...f.ucam.org