From: Matthew Garrett <matthew.garrett@nebula.com>
To: Qiaowei Ren <qiaowei.ren@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
Xiaoyan Zhang <xiaoyan.zhang@intel.com>,
Gang Wei <gang.wei@intel.com>
Subject: Re: [PATCH 3/4] driver: provide sysfs interfaces to access TXT log
Date: Wed, 8 May 2013 05:16:43 +0000 [thread overview]
Message-ID: <1367990202.2425.26.camel@x230> (raw)
In-Reply-To: <1367938519-840-4-git-send-email-qiaowei.ren@intel.com>
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@intel.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@srcf.ucam.org
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Garrett <matthew.garrett@nebula.com>
To: Qiaowei Ren <qiaowei.ren@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
Xiaoyan Zhang <xiaoyan.zhang@intel.com>,
Gang Wei <gang.wei@intel.com>
Subject: Re: [PATCH 3/4] driver: provide sysfs interfaces to access TXT log
Date: Wed, 8 May 2013 05:16:43 +0000 [thread overview]
Message-ID: <1367990202.2425.26.camel@x230> (raw)
In-Reply-To: <1367938519-840-4-git-send-email-qiaowei.ren@intel.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1520 bytes --]
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@intel.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@srcf.ucam.org
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2013-05-08 5:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-07 14:55 [PATCH 0/4] Intel TXT driver Qiaowei Ren
2013-05-07 14:55 ` [PATCH 1/4] driver: add TXT driver in kernel Qiaowei Ren
2013-05-08 2:32 ` Matthew Garrett
2013-05-08 2:32 ` Matthew Garrett
2013-05-10 3:38 ` Ren, Qiaowei
2013-05-10 3:38 ` Ren, Qiaowei
2013-05-07 14:55 ` [PATCH 2/4] driver: provide sysfs interfaces to access TXT config space Qiaowei Ren
2013-05-08 2:44 ` Matthew Garrett
2013-05-08 2:44 ` Matthew Garrett
2013-05-07 14:55 ` [PATCH 3/4] driver: provide sysfs interfaces to access TXT log Qiaowei Ren
2013-05-08 5:16 ` Matthew Garrett [this message]
2013-05-08 5:16 ` Matthew Garrett
2013-05-09 8:05 ` Ren, Qiaowei
2013-05-09 8:05 ` Ren, Qiaowei
2013-05-09 12:02 ` Matthew Garrett
2013-05-09 12:02 ` Matthew Garrett
2013-05-10 1:50 ` Ren, Qiaowei
2013-05-10 1:50 ` Ren, Qiaowei
2013-05-07 14:55 ` [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter Qiaowei Ren
2013-05-08 5:24 ` Matthew Garrett
2013-05-08 5:24 ` Matthew Garrett
2013-05-10 7:05 ` Ren, Qiaowei
2013-05-10 7:05 ` Ren, Qiaowei
2013-05-10 13:07 ` Matthew Garrett
2013-05-10 13:07 ` Matthew Garrett
2013-05-11 0:01 ` Ren, Qiaowei
2013-05-11 0:01 ` Ren, Qiaowei
2013-05-08 2:28 ` [PATCH 0/4] Intel TXT driver Matthew Garrett
2013-05-08 2:28 ` Matthew Garrett
2013-05-09 8:19 ` Ren, Qiaowei
2013-05-09 8:19 ` Ren, Qiaowei
2013-05-09 12:02 ` Matthew Garrett
2013-05-09 12:02 ` Matthew Garrett
2013-05-10 2:20 ` Ren, Qiaowei
2013-05-10 2:20 ` Ren, Qiaowei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1367990202.2425.26.camel@x230 \
--to=matthew.garrett@nebula.com \
--cc=gang.wei@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=qiaowei.ren@intel.com \
--cc=xiaoyan.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.