RE: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On 2013-05-10, Matthew Garrett wrote: > On Fri, 2013-05-10 at 07:05 +, Ren, Qiaowei wrote: >> On 2013-05-08, Matthew Garrett wrote: >>> On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote: >>> +What: /sys/devices/platform/intel_txt/parameter/acm_max_size +Date: May 2013 +KernelVersion:3.9 +Contact: "Qiaowei Ren" +Description: The "acm_max_size" property will show max size of + authenticated code execution area. >>> >>> What would userspace use this for? >> >> These sysfs files are just export SMX & TXT related information to userspace. > So that other developers (or OSV & ISV) can be able to develop txt > related applications or tools based on these information. > > If they're only using it for debugging purposes then sysfs probably > isn't the right place. Is there any reason tools would need to know this > during normal usage? Unlike tboot log, these properties are not used for debugging purposes. They are used to report attributes, options and limitations of SMX operation. Software may use them to identify operations limits or additional options. Thanks, Qiaowei
Re: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On Fri, 2013-05-10 at 07:05 +, Ren, Qiaowei wrote: > On 2013-05-08, Matthew Garrett wrote: > > On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote: > > > > > +What:/sys/devices/platform/intel_txt/parameter/acm_max_size > > > +Date:May 2013 > > > +KernelVersion: 3.9 > > > +Contact: "Qiaowei Ren" > > > +Description: The "acm_max_size" property will show max size of > > > + authenticated code execution area. > > > > What would userspace use this for? > > These sysfs files are just export SMX & TXT related information to userspace. > So that other developers (or OSV & ISV) can be able to develop txt related > applications or tools based on these information. If they're only using it for debugging purposes then sysfs probably isn't the right place. Is there any reason tools would need to know this during normal usage? -- Matthew Garrett | mj...@srcf.ucam.org
RE: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On 2013-05-08, Matthew Garrett wrote:
> On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote:
>
> > +What: /sys/devices/platform/intel_txt/parameter/acm_max_size
> > +Date: May 2013
> > +KernelVersion: 3.9
> > +Contact: "Qiaowei Ren"
> > +Description: The "acm_max_size" property will show max size of
> > + authenticated code execution area.
>
> What would userspace use this for?
These sysfs files are just export SMX & TXT related information to userspace.
So that other developers (or OSV & ISV) can be able to develop txt related
applications or tools based on these information.
> > +What: /sys/devices/platform/intel_txt/parameter/acm_mem_types
> > +Date: May 2013
> > +KernelVersion: 3.9
> > +Contact: "Qiaowei Ren"
> > +Description: The "acm_max_types" property will show external memory
> > + types supported during AC mode.
>
> Or this? And what's AC mode?
It means that the property will show supportable memory types for memory mapped
outside of the authenticated code execution area.
> > + __asm__ __volatile__ (IA32_GETSEC_OPCODE "\n"
> > + : "=a"(eax), "=b"(ebx), "=c"(ecx)
> > + : "a"(IA32_GETSEC_PARAMETERS), "b"(index));
> > +
> > + *param_type = eax & 0x1f;
> > + *peax = eax;
> > + *pebx = ebx;
> > + *pecx = ecx;
>
> Should there be a check for failure here? Is it possible for this operation
> to fail?
You mean GETSEC instruction? I don't notice related description in manual. Next
function get_parameters() will process return eax/ebx/ecx returned by this
instruction.
> > + write_cr4(read_cr4() | CR4_SMXE);
>
> Whoo. This needs at least a giant comment and probably some locking, but if
> this is supposed to be set during runtime then it should be done in core
> architecture code rather than just in this driver.
Oh. This code should be removed, because tboot code have set SMXE bit.
Thanks,
Qiaowei
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On 2013-05-08, Matthew Garrett wrote:
On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote:
+What: /sys/devices/platform/intel_txt/parameter/acm_max_size
+Date: May 2013
+KernelVersion: 3.9
+Contact: Qiaowei Ren qiaowei@intel.com
+Description: The acm_max_size property will show max size of
+ authenticated code execution area.
What would userspace use this for?
These sysfs files are just export SMX TXT related information to userspace.
So that other developers (or OSV ISV) can be able to develop txt related
applications or tools based on these information.
+What: /sys/devices/platform/intel_txt/parameter/acm_mem_types
+Date: May 2013
+KernelVersion: 3.9
+Contact: Qiaowei Ren qiaowei@intel.com
+Description: The acm_max_types property will show external memory
+ types supported during AC mode.
Or this? And what's AC mode?
It means that the property will show supportable memory types for memory mapped
outside of the authenticated code execution area.
+ __asm__ __volatile__ (IA32_GETSEC_OPCODE \n
+ : =a(eax), =b(ebx), =c(ecx)
+ : a(IA32_GETSEC_PARAMETERS), b(index));
+
+ *param_type = eax 0x1f;
+ *peax = eax;
+ *pebx = ebx;
+ *pecx = ecx;
Should there be a check for failure here? Is it possible for this operation
to fail?
You mean GETSEC instruction? I don't notice related description in manual. Next
function get_parameters() will process return eax/ebx/ecx returned by this
instruction.
+ write_cr4(read_cr4() | CR4_SMXE);
Whoo. This needs at least a giant comment and probably some locking, but if
this is supposed to be set during runtime then it should be done in core
architecture code rather than just in this driver.
Oh. This code should be removed, because tboot code have set SMXE bit.
Thanks,
Qiaowei
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On Fri, 2013-05-10 at 07:05 +, Ren, Qiaowei wrote: On 2013-05-08, Matthew Garrett wrote: On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote: +What:/sys/devices/platform/intel_txt/parameter/acm_max_size +Date:May 2013 +KernelVersion: 3.9 +Contact: Qiaowei Ren qiaowei@intel.com +Description: The acm_max_size property will show max size of + authenticated code execution area. What would userspace use this for? These sysfs files are just export SMX TXT related information to userspace. So that other developers (or OSV ISV) can be able to develop txt related applications or tools based on these information. If they're only using it for debugging purposes then sysfs probably isn't the right place. Is there any reason tools would need to know this during normal usage? -- Matthew Garrett | mj...@srcf.ucam.org
RE: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On 2013-05-10, Matthew Garrett wrote: On Fri, 2013-05-10 at 07:05 +, Ren, Qiaowei wrote: On 2013-05-08, Matthew Garrett wrote: On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote: +What: /sys/devices/platform/intel_txt/parameter/acm_max_size +Date: May 2013 +KernelVersion:3.9 +Contact: Qiaowei Ren qiaowei@intel.com +Description: The acm_max_size property will show max size of + authenticated code execution area. What would userspace use this for? These sysfs files are just export SMX TXT related information to userspace. So that other developers (or OSV ISV) can be able to develop txt related applications or tools based on these information. If they're only using it for debugging purposes then sysfs probably isn't the right place. Is there any reason tools would need to know this during normal usage? Unlike tboot log, these properties are not used for debugging purposes. They are used to report attributes, options and limitations of SMX operation. Software may use them to identify operations limits or additional options. Thanks, Qiaowei
Re: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote:
> These interfaces are located in /sys/devices/platform/intel_txt/parameter/,
> showing specific parameter information for SMX features supported by
> the processor.
Explain what SMX is here.
> +Contact: "Qiaowei Ren"
> +Description: The parameter/ directory exposes specific parameter
> + information for SMX features supported by the processor.
Also here.
> +What:/sys/devices/platform/intel_txt/parameter/acm_max_size
> +Date:May 2013
> +KernelVersion: 3.9
> +Contact: "Qiaowei Ren"
> +Description: The "acm_max_size" property will show max size of
> + authenticated code execution area.
What would userspace use this for?
> +What:/sys/devices/platform/intel_txt/parameter/acm_mem_types
> +Date:May 2013
> +KernelVersion: 3.9
> +Contact: "Qiaowei Ren"
> +Description: The "acm_max_types" property will show external memory
> + types supported during AC mode.
Or this? And what's AC mode?
> +static void __getsec_parameters(uint32_t index, int *param_type,
> + uint32_t *peax, uint32_t *pebx,
> + uint32_t *pecx)
> +{
> + uint32_t eax = 0, ebx = 0, ecx = 0;
These are all going to be overwritten by the getsec operation? Do they
really need to be initialised?
> + __asm__ __volatile__ (IA32_GETSEC_OPCODE "\n"
> + : "=a"(eax), "=b"(ebx), "=c"(ecx)
> + : "a"(IA32_GETSEC_PARAMETERS), "b"(index));
> +
> + *param_type = eax & 0x1f;
> + *peax = eax;
> + *pebx = ebx;
> + *pecx = ecx;
Should there be a check for failure here? Is it possible for this
operation to fail?
> + write_cr4(read_cr4() | CR4_SMXE);
Whoo. This needs at least a giant comment and probably some locking, but
if this is supposed to be set during runtime then it should be done in
core architecture code rather than just in this driver.
> + sscanf(buf, "%d", );
What if this fails?
> +EXPORT_SYMBOL_GPL(sysfs_create_parameter);
> +
> +MODULE_LICENSE("GPL");
Not needed.
> +#define IA32_GETSEC_OPCODE ".byte 0x0f,0x37"
Nnf. Does the assembler really not know about this instruction?
--
Matthew Garrett | mj...@srcf.ucam.org
Re: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote:
These interfaces are located in /sys/devices/platform/intel_txt/parameter/,
showing specific parameter information for SMX features supported by
the processor.
Explain what SMX is here.
+Contact: Qiaowei Ren qiaowei@intel.com
+Description: The parameter/ directory exposes specific parameter
+ information for SMX features supported by the processor.
Also here.
+What:/sys/devices/platform/intel_txt/parameter/acm_max_size
+Date:May 2013
+KernelVersion: 3.9
+Contact: Qiaowei Ren qiaowei@intel.com
+Description: The acm_max_size property will show max size of
+ authenticated code execution area.
What would userspace use this for?
+What:/sys/devices/platform/intel_txt/parameter/acm_mem_types
+Date:May 2013
+KernelVersion: 3.9
+Contact: Qiaowei Ren qiaowei@intel.com
+Description: The acm_max_types property will show external memory
+ types supported during AC mode.
Or this? And what's AC mode?
+static void __getsec_parameters(uint32_t index, int *param_type,
+ uint32_t *peax, uint32_t *pebx,
+ uint32_t *pecx)
+{
+ uint32_t eax = 0, ebx = 0, ecx = 0;
These are all going to be overwritten by the getsec operation? Do they
really need to be initialised?
+ __asm__ __volatile__ (IA32_GETSEC_OPCODE \n
+ : =a(eax), =b(ebx), =c(ecx)
+ : a(IA32_GETSEC_PARAMETERS), b(index));
+
+ *param_type = eax 0x1f;
+ *peax = eax;
+ *pebx = ebx;
+ *pecx = ecx;
Should there be a check for failure here? Is it possible for this
operation to fail?
+ write_cr4(read_cr4() | CR4_SMXE);
Whoo. This needs at least a giant comment and probably some locking, but
if this is supposed to be set during runtime then it should be done in
core architecture code rather than just in this driver.
+ sscanf(buf, %d, index);
What if this fails?
+EXPORT_SYMBOL_GPL(sysfs_create_parameter);
+
+MODULE_LICENSE(GPL);
Not needed.
+#define IA32_GETSEC_OPCODE .byte 0x0f,0x37
Nnf. Does the assembler really not know about this instruction?
--
Matthew Garrett | mj...@srcf.ucam.org
