Re: [PATCH 2/3] tpm: transition tpm_vtpm_proxy documentation to the Sphinx
On Thu, Nov 03, 2016 at 05:57:51PM -0600, Jarkko Sakkinen wrote:
> Transitioned the tpm_vtpm_proxy documentation to the Sphinx
> infrastructure and removed parts from the documentation that are easier
> to pull from the sources. Restructured vtpm_proxy.h and tpm_vtpm_proxy.c
> to be compatible with this approach and wrote associated documentation
> comments.
>
> Signed-off-by: Jarkko Sakkinen
Stefan?
/Jarkko
> ---
> Documentation/index.rst| 1 +
> Documentation/tpm/index.rst| 7 +++
> .../tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} | 55
> +++---
> 3 files changed, 25 insertions(+), 38 deletions(-)
> create mode 100644 Documentation/tpm/index.rst
> rename Documentation/tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} (53%)
>
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index e0fc729..0058b65 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -19,6 +19,7 @@ Contents:
> media/dvb-drivers/index
> media/v4l-drivers/index
> gpu/index
> + tpm/index
>
> Indices and tables
> ==
> diff --git a/Documentation/tpm/index.rst b/Documentation/tpm/index.rst
> new file mode 100644
> index 000..af77a7b
> --- /dev/null
> +++ b/Documentation/tpm/index.rst
> @@ -0,0 +1,7 @@
> +=
> +Trusted Platform Module documentation
> +=
> +
> +.. toctree::
> +
> + tpm_vtpm_proxy
> diff --git a/Documentation/tpm/tpm_vtpm_proxy.txt
> b/Documentation/tpm/tpm_vtpm_proxy.rst
> similarity index 53%
> rename from Documentation/tpm/tpm_vtpm_proxy.txt
> rename to Documentation/tpm/tpm_vtpm_proxy.rst
> index 30d1902..ea08e76 100644
> --- a/Documentation/tpm/tpm_vtpm_proxy.txt
> +++ b/Documentation/tpm/tpm_vtpm_proxy.rst
> @@ -1,71 +1,50 @@
> +=
> Virtual TPM Proxy Driver for Linux Containers
> +=
>
> -Authors: Stefan Berger (IBM)
> +| Authors:
> +| Stefan Berger
>
> This document describes the virtual Trusted Platform Module (vTPM)
> proxy device driver for Linux containers.
>
> -INTRODUCTION
> -
> +Introduction
> +
>
> The goal of this work is to provide TPM functionality to each Linux
> container. This allows programs to interact with a TPM in a container
> the same way they interact with a TPM on the physical system. Each
> container gets its own unique, emulated, software TPM.
>
> -
> -DESIGN
> ---
> +Design
> +==
>
> To make an emulated software TPM available to each container, the container
> management stack needs to create a device pair consisting of a client TPM
> -character device /dev/tpmX (with X=0,1,2...) and a 'server side' file
> +character device ``/dev/tpmX`` (with X=0,1,2...) and a 'server side' file
> descriptor. The former is moved into the container by creating a character
> device with the appropriate major and minor numbers while the file descriptor
> is passed to the TPM emulator. Software inside the container can then send
> TPM commands using the character device and the emulator will receive the
> commands via the file descriptor and use it for sending back responses.
>
> -To support this, the virtual TPM proxy driver provides a device /dev/vtpmx
> +To support this, the virtual TPM proxy driver provides a device
> ``/dev/vtpmx``
> that is used to create device pairs using an ioctl. The ioctl takes as
> an input flags for configuring the device. The flags for example indicate
> whether TPM 1.2 or TPM 2 functionality is supported by the TPM emulator.
> The result of the ioctl are the file descriptor for the 'server side'
> as well as the major and minor numbers of the character device that was
> created.
> -Besides that the number of the TPM character device is return. If for
> -example /dev/tpm10 was created, the number (dev_num) 10 is returned.
> -
> -The following is the data structure of the TPM_PROXY_IOC_NEW_DEV ioctl:
> -
> -struct vtpm_proxy_new_dev {
> - __u32 flags; /* input */
> - __u32 tpm_num; /* output */
> - __u32 fd;/* output */
> - __u32 major; /* output */
> - __u32 minor; /* output */
> -};
> -
> -Note that if unsupported flags are passed to the device driver, the ioctl
> will
> -fail and errno will be set to EOPNOTSUPP. Similarly, if an unsupported ioctl
> is
> -called on the device driver, the ioctl will fail and errno will be set to
> -ENOTTY.
> -
> -See /usr/include/linux/vtpm_proxy.h for definitions related to the public
> interface
> -of this vTPM device driver.
> +Besides that the number of the TPM character device is returned. If for
> +example ``/dev/tpm10`` was created, the number (``dev_num``) 10 is returned.
>
> Once the device has been created, the driver will immediately try to talk
> to the TPM. All commands from the driver can be rea
Re: [PATCH 3/3] tpm: move documentation under Documentation/security
On Fri, 4 Nov 2016, Jarkko Sakkinen wrote: > On Fri, Nov 04, 2016 at 02:06:00PM +0200, Jani Nikula wrote: > > On Fri, 04 Nov 2016, Jarkko Sakkinen > > wrote: > > > In order too make Documentation root directory cleaner move the tpm > > > directory under Documentation/security. > > > > FWIW I like this. > > Thx. I just realized that I should have CC'd to linux-security-module > to get say from James as this makes path for the whole security tree. > > James, sorry about that. Can you share your opinion? Looks like a good idea to me. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: networking: dsa: Update tagging protocols
On 11/04/2016 05:16 AM, Fabian Mewes wrote: > Add Qualcomm QCA tagging introduced in cafdc45c9 to the > list of supported protocols. > > Signed-off-by: Fabian Mewes Acked-by: Florian Fainelli -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] procfs: Add mem_end to /proc//stat
On Fri, Nov 4, 2016 at 6:14 AM, Christopher Covington wrote: > Applications such as Just-In-Time (JIT) compilers, Checkpoint/Restore In > Userspace (CRIU), and User Mode Linux (UML) need to know the highest > virtual address, TASK_SIZE, to implement pointer tagging or make a first > educated guess at where to find a large, unused region of memory. > Unfortunately the currently available mechanisms for determining TASK_SIZE > are either convoluted and potentially error-prone, such as making repeated > munmap() calls and checking the return code, Oh boy -- if you do this you are just asking to segfault. > or make use of hard-coded > assumptions that limit an application's portability across kernels with > different Kconfig options and multiple architectures. > > Therefore, expose TASK_SIZE to userspace. While PAGE_SIZE is exposed to > userspace via an auxiliary vector, that approach is not used for TASK_SIZE > in case run-time alterations to the usable virtual address range are one > day implemented, such as through an extension to prctl(PR_SET_MM) or a flag > to clone. There is no prctl(PR_GET_MM). Instead such information is > expected to come from /proc//stat[m]. For the same extendability > reason, use a per-pid proc entry rather than a system-wide entry like > /proc/sys/vm/mmap_min_addr. First, this should be in status, not stat, but that's moot because TASK_SIZE is nonsensical as a task property on x86. And, as was nicely covered yesterday at LPC, we already have too much of a mess in /proc where per-mm properties are mixed up with per-task properties. Can we make a point of not adding any new mm-related things to files that are about the task? But also, NAK for x86 if you look at TASK_SIZE: TASK_SIZE is a mess and needs to go away completely -- only TASK_SIZE_MAX makes any sense. If you want to ask "what the largest address that could possibly be mapped in this mm", the answer is 2^47-1-PAGE_SIZE [1] on present CPUs. If you want a prctl to return that, then adding one *might* make sense. OTOH it's a bit unclear what happens if your task is migrated to a hypothetical future CPU with more address bits. If you're a 32-bit process on x86, you have zero high bits free because the address limit is above 2^31-1. If you're an x32 process, then (a) I'm surprised and (b) there might be room for "what is the highest address that an mmap call done without trickery would return". That could be added as well with a suitably scary name in prctl. But this is still rather odd: x32 pointers are exactly 32 bits unless you write weird asm code to use 64-bit pointers, and you wouldn't do that because it defeats the whole point of x32 which is to treat all pointers as exactly 32 bits. So an x32 application should just hard-code 32 as the number of bits. [1] That PAGE_SIZE offset has an interesting backstory involving some overly clever Intel hardware designers and a root hole that, as far as I know, affected every single x86_64 operating system. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] procfs: Add mem_end to /proc//stat
Applications such as Just-In-Time (JIT) compilers, Checkpoint/Restore In Userspace (CRIU), and User Mode Linux (UML) need to know the highest virtual address, TASK_SIZE, to implement pointer tagging or make a first educated guess at where to find a large, unused region of memory. Unfortunately the currently available mechanisms for determining TASK_SIZE are either convoluted and potentially error-prone, such as making repeated munmap() calls and checking the return code, or make use of hard-coded assumptions that limit an application's portability across kernels with different Kconfig options and multiple architectures. Therefore, expose TASK_SIZE to userspace. While PAGE_SIZE is exposed to userspace via an auxiliary vector, that approach is not used for TASK_SIZE in case run-time alterations to the usable virtual address range are one day implemented, such as through an extension to prctl(PR_SET_MM) or a flag to clone. There is no prctl(PR_GET_MM). Instead such information is expected to come from /proc//stat[m]. For the same extendability reason, use a per-pid proc entry rather than a system-wide entry like /proc/sys/vm/mmap_min_addr. Signed-off-by: Christopher Covington --- Documentation/filesystems/proc.txt | 1 + fs/proc/array.c| 5 + 2 files changed, 6 insertions(+) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 74329fd..b9c19cf 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -343,6 +343,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7) env_start address above which program environment is placed env_end address below which program environment is placed exit_code the thread's exit_code in the form reported by the waitpid system call + end_mem address below which all regular program parts are placed (TASK_SIZE) .. The /proc/PID/maps file containing the currently mapped memory regions and diff --git a/fs/proc/array.c b/fs/proc/array.c index 9a3ca9e..32b5002 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -561,6 +561,11 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, else seq_puts(m, " 0"); + if (mm && permitted) + seq_put_decimal_ull(m, " ", mm->task_size); + else + seq_puts(m, " 0"); + seq_putc(m, '\n'); if (mm) mmput(mm); -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] tpm: move documentation under Documentation/security
On Fri, Nov 04, 2016 at 02:06:00PM +0200, Jani Nikula wrote:
> On Fri, 04 Nov 2016, Jarkko Sakkinen wrote:
> > In order too make Documentation root directory cleaner move the tpm
> > directory under Documentation/security.
>
> FWIW I like this.
Thx. I just realized that I should have CC'd to linux-security-module
to get say from James as this makes path for the whole security tree.
James, sorry about that. Can you share your opinion?
> BR,
> Jani.
/Jarkko
>
>
> >
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > Documentation/index.rst | 2 +-
> > Documentation/security/index.rst| 7 +++
> > Documentation/{ => security}/tpm/index.rst | 0
> > Documentation/{ => security}/tpm/tpm_vtpm_proxy.rst | 0
> > Documentation/{ => security}/tpm/xen-tpmfront.txt | 0
> > 5 files changed, 8 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/security/index.rst
> > rename Documentation/{ => security}/tpm/index.rst (100%)
> > rename Documentation/{ => security}/tpm/tpm_vtpm_proxy.rst (100%)
> > rename Documentation/{ => security}/tpm/xen-tpmfront.txt (100%)
> >
> > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > index 0058b65..b4c3034 100644
> > --- a/Documentation/index.rst
> > +++ b/Documentation/index.rst
> > @@ -19,7 +19,7 @@ Contents:
> > media/dvb-drivers/index
> > media/v4l-drivers/index
> > gpu/index
> > - tpm/index
> > + security/index
> >
> > Indices and tables
> > ==
> > diff --git a/Documentation/security/index.rst
> > b/Documentation/security/index.rst
> > new file mode 100644
> > index 000..9bae6bb
> > --- /dev/null
> > +++ b/Documentation/security/index.rst
> > @@ -0,0 +1,7 @@
> > +==
> > +Security documentation
> > +==
> > +
> > +.. toctree::
> > +
> > + tpm/index
> > diff --git a/Documentation/tpm/index.rst
> > b/Documentation/security/tpm/index.rst
> > similarity index 100%
> > rename from Documentation/tpm/index.rst
> > rename to Documentation/security/tpm/index.rst
> > diff --git a/Documentation/tpm/tpm_vtpm_proxy.rst
> > b/Documentation/security/tpm/tpm_vtpm_proxy.rst
> > similarity index 100%
> > rename from Documentation/tpm/tpm_vtpm_proxy.rst
> > rename to Documentation/security/tpm/tpm_vtpm_proxy.rst
> > diff --git a/Documentation/tpm/xen-tpmfront.txt
> > b/Documentation/security/tpm/xen-tpmfront.txt
> > similarity index 100%
> > rename from Documentation/tpm/xen-tpmfront.txt
> > rename to Documentation/security/tpm/xen-tpmfront.txt
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: networking: dsa: Update tagging protocols
On Fri, Nov 04, 2016 at 01:16:14PM +0100, Fabian Mewes wrote: > Add Qualcomm QCA tagging introduced in cafdc45c9 to the > list of supported protocols. > > Signed-off-by: Fabian Mewes Thanks Reviewed-by: Andrew Lunn Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: networking: dsa: Update tagging protocols
Add Qualcomm QCA tagging introduced in cafdc45c9 to the list of supported protocols. Signed-off-by: Fabian Mewes --- Documentation/networking/dsa/dsa.txt |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt index 6d6c07c..63912ef3 100644 --- a/Documentation/networking/dsa/dsa.txt +++ b/Documentation/networking/dsa/dsa.txt @@ -67,13 +67,14 @@ Note that DSA does not currently create network interfaces for the "cpu" and Switch tagging protocols -DSA currently supports 4 different tagging protocols, and a tag-less mode as +DSA currently supports 5 different tagging protocols, and a tag-less mode as well. The different protocols are implemented in: net/dsa/tag_trailer.c: Marvell's 4 trailer tag mode (legacy) net/dsa/tag_dsa.c: Marvell's original DSA tag net/dsa/tag_edsa.c: Marvell's enhanced DSA tag net/dsa/tag_brcm.c: Broadcom's 4 bytes tag +net/dsa/tag_qca.c: Qualcomm's 2 bytes tag The exact format of the tag protocol is vendor specific, but in general, they all contain something which: -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] tpm: move documentation under Documentation/security
On Fri, 04 Nov 2016, Jarkko Sakkinen wrote:
> In order too make Documentation root directory cleaner move the tpm
> directory under Documentation/security.
FWIW I like this.
BR,
Jani.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> Documentation/index.rst | 2 +-
> Documentation/security/index.rst| 7 +++
> Documentation/{ => security}/tpm/index.rst | 0
> Documentation/{ => security}/tpm/tpm_vtpm_proxy.rst | 0
> Documentation/{ => security}/tpm/xen-tpmfront.txt | 0
> 5 files changed, 8 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/security/index.rst
> rename Documentation/{ => security}/tpm/index.rst (100%)
> rename Documentation/{ => security}/tpm/tpm_vtpm_proxy.rst (100%)
> rename Documentation/{ => security}/tpm/xen-tpmfront.txt (100%)
>
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index 0058b65..b4c3034 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -19,7 +19,7 @@ Contents:
> media/dvb-drivers/index
> media/v4l-drivers/index
> gpu/index
> - tpm/index
> + security/index
>
> Indices and tables
> ==
> diff --git a/Documentation/security/index.rst
> b/Documentation/security/index.rst
> new file mode 100644
> index 000..9bae6bb
> --- /dev/null
> +++ b/Documentation/security/index.rst
> @@ -0,0 +1,7 @@
> +==
> +Security documentation
> +==
> +
> +.. toctree::
> +
> + tpm/index
> diff --git a/Documentation/tpm/index.rst
> b/Documentation/security/tpm/index.rst
> similarity index 100%
> rename from Documentation/tpm/index.rst
> rename to Documentation/security/tpm/index.rst
> diff --git a/Documentation/tpm/tpm_vtpm_proxy.rst
> b/Documentation/security/tpm/tpm_vtpm_proxy.rst
> similarity index 100%
> rename from Documentation/tpm/tpm_vtpm_proxy.rst
> rename to Documentation/security/tpm/tpm_vtpm_proxy.rst
> diff --git a/Documentation/tpm/xen-tpmfront.txt
> b/Documentation/security/tpm/xen-tpmfront.txt
> similarity index 100%
> rename from Documentation/tpm/xen-tpmfront.txt
> rename to Documentation/security/tpm/xen-tpmfront.txt
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/8] sched/tune: add detailed documentation
On 27-10-16, 18:41, Patrick Bellasi wrote: > +This last requirement is especially important if we consider that schedutil > can > +potentially replace all currently available CPUFreq policies. Since schedutil > +is event based, as opposed to the sampling driven governors, it is already > more > +responsive at selecting the optimal OPP to run tasks allocated to a CPU. I am not sure if I follow this paragraph. All the governors follow the same basic rules now. They are all event driven (events from scheduler), but they function only after a certain sampling period is finished. Isn't this the case ? > +SchedTune exposes a simple user-space interface with a single > power-performance > +tunable: > + > + /proc/sys/kernel/sched_cfs_boost > + > +This permits expressing a boost value as an integer in the range [0..100]. > + > +A value of 0 (default) for a CFS task means that schedutil will attempt > +to match compute capacity of the CPU where the task is scheduled to > +match its current utilization with a few spare cycles left. A value of > +100 means that schedutil will select the highest available OPP. > + > +The range between 0 and 100 can be set to satisfy other scenarios suitably. > +For example to satisfy interactive response or depending on other system > events > +(battery level, thermal status, etc). Earlier section said that schedutil+schedtune can replace all earlier governors. How will schedutil behave like powersave governor with schedtune? I was expecting the possible values of sched_cfs_boost to be in the range -100 to 100, where -100 will make it powersave, +100 will make it performance and 0 will not make any changes. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
