* Re: [PATCH 10/22] docs: amd-memory-encryption.rst get rid of warnings
From: Paolo Bonzini @ 2019-05-30 8:30 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Radim Krčmář, kvm
In-Reply-To: <76b7a2990edd771aa1708862d0c6644a6b2d795d.1559171394.git.mchehab+samsung@kernel.org>
On 30/05/19 01:23, Mauro Carvalho Chehab wrote:
> Get rid of those warnings:
>
> Documentation/virtual/kvm/amd-memory-encryption.rst:244: WARNING: Citation [white-paper] is not referenced.
> Documentation/virtual/kvm/amd-memory-encryption.rst:246: WARNING: Citation [amd-apm] is not referenced.
> Documentation/virtual/kvm/amd-memory-encryption.rst:247: WARNING: Citation [kvm-forum] is not referenced.
>
> For references that aren't mentioned at the text by adding an
> explicit reference to them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/virtual/kvm/amd-memory-encryption.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/amd-memory-encryption.rst b/Documentation/virtual/kvm/amd-memory-encryption.rst
> index 33d697ab8a58..6c37ff9a0a3c 100644
> --- a/Documentation/virtual/kvm/amd-memory-encryption.rst
> +++ b/Documentation/virtual/kvm/amd-memory-encryption.rst
> @@ -243,6 +243,9 @@ Returns: 0 on success, -negative on error
> References
> ==========
>
> +
> +See [white-paper]_, [api-spec]_, [amd-apm]_ and [kvm-forum]_ for more info.
> +
> .. [white-paper] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
> .. [api-spec] http://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
> .. [amd-apm] http://support.amd.com/TechDocs/24593.pdf (section 15.34)
>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
^ permalink raw reply
* Великденски бонуси
From: Radoslav Dobrev @ 2019-05-30 10:07 UTC (permalink / raw)
To: linux-doc
Здравейте!
Ваучерите за храна се нареждат сред любимите социални придобивки на работещите хора и сред най-предпочитаните начини за стимулиране от работодателите. Те подобряват ефективността и производителността на Вашите служители.
Благодарение на ваучерите за храна реализирате спестявания – стойността на ваучерите не се облага с данъци и осигуровки до 60лв месечно за всеки работник, а в същото време мотивацията и покупателната способност на служителите нараства.
Ако проявявате интерес към възможностите за въвеждане на ваучери за храна във Вашата фирма и желаете по-подробна информация, изпратете ми съобщение.
Радослав Добрев
Head of HR Benefit Team
www.originalcard.eu
^ permalink raw reply
* Re: [PATCH v2 1/3] evm: check hash algorithm passed to init_desc()
From: Mimi Zohar @ 2019-05-30 11:53 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <20190529133035.28724-2-roberto.sassu@huawei.com>
On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> This patch prevents memory access beyond the evm_tfm array by checking the
> validity of the index (hash algorithm) passed to init_desc(). The hash
> algorithm can be arbitrarily set if the security.ima xattr type is not
> EVM_XATTR_HMAC.
>
> Fixes: 5feeb61183dde ("evm: Allow non-SHA1 digital signatures")
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: stable@vger.kernel.org
Thanks, queued.
> ---
> security/integrity/evm/evm_crypto.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index e11564eb645b..82a38e801ee4 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -89,6 +89,9 @@ static struct shash_desc *init_desc(char type, uint8_t hash_algo)
> tfm = &hmac_tfm;
> algo = evm_hmac;
> } else {
> + if (hash_algo >= HASH_ALGO__LAST)
> + return ERR_PTR(-EINVAL);
> +
> tfm = &evm_tfm[hash_algo];
> algo = hash_algo_name[hash_algo];
> }
^ permalink raw reply
* Re: [PATCH v2 3/3] ima: show rules with IMA_INMASK correctly
From: Mimi Zohar @ 2019-05-30 11:53 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <20190529133035.28724-4-roberto.sassu@huawei.com>
On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> Show the '^' character when a policy rule has flag IMA_INMASK.
>
> Fixes: 80eae209d63ac ("IMA: allow reading back the current IMA policy")
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: stable@vger.kernel.org
Thanks, queued.
> ---
> security/integrity/ima/ima_policy.c | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index e0cc323f948f..ae4034f041c4 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -1146,10 +1146,10 @@ enum {
> };
>
> static const char *const mask_tokens[] = {
> - "MAY_EXEC",
> - "MAY_WRITE",
> - "MAY_READ",
> - "MAY_APPEND"
> + "^MAY_EXEC",
> + "^MAY_WRITE",
> + "^MAY_READ",
> + "^MAY_APPEND"
> };
>
> #define __ima_hook_stringify(str) (#str),
> @@ -1209,6 +1209,7 @@ int ima_policy_show(struct seq_file *m, void *v)
> struct ima_rule_entry *entry = v;
> int i;
> char tbuf[64] = {0,};
> + int offset = 0;
>
> rcu_read_lock();
>
> @@ -1232,15 +1233,17 @@ int ima_policy_show(struct seq_file *m, void *v)
> if (entry->flags & IMA_FUNC)
> policy_func_show(m, entry->func);
>
> - if (entry->flags & IMA_MASK) {
> + if ((entry->flags & IMA_MASK) || (entry->flags & IMA_INMASK)) {
> + if (entry->flags & IMA_MASK)
> + offset = 1;
> if (entry->mask & MAY_EXEC)
> - seq_printf(m, pt(Opt_mask), mt(mask_exec));
> + seq_printf(m, pt(Opt_mask), mt(mask_exec) + offset);
> if (entry->mask & MAY_WRITE)
> - seq_printf(m, pt(Opt_mask), mt(mask_write));
> + seq_printf(m, pt(Opt_mask), mt(mask_write) + offset);
> if (entry->mask & MAY_READ)
> - seq_printf(m, pt(Opt_mask), mt(mask_read));
> + seq_printf(m, pt(Opt_mask), mt(mask_read) + offset);
> if (entry->mask & MAY_APPEND)
> - seq_printf(m, pt(Opt_mask), mt(mask_append));
> + seq_printf(m, pt(Opt_mask), mt(mask_append) + offset);
> seq_puts(m, " ");
> }
>
^ permalink raw reply
* Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Mimi Zohar @ 2019-05-30 12:00 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <20190529133035.28724-3-roberto.sassu@huawei.com>
On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> Currently, ima_appraise_measurement() ignores the EVM status when
> evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a valid
> security.ima xattr with type IMA_XATTR_DIGEST or IMA_XATTR_DIGEST_NG,
> ima_appraise_measurement() returns INTEGRITY_PASS regardless of the EVM
> status. The problem is that the EVM status is overwritten with the
> > appraisal statu
Roberto, your framing of this problem is harsh and misleading. IMA
and EVM are intentionally independent of each other and can be
configured independently of each other. The intersection of the two
is the call to evm_verifyxattr(). INTEGRITY_UNKNOWN is returned for a
number of reasons - when EVM is not configured, the EVM hmac key has
not yet been loaded, the protected security attribute is unknown, or
the file is not in policy.
This patch does not differentiate between any of the above cases,
requiring mutable files to always be protected by EVM, when specified
as an "ima_appraise=" option on the boot command line.
IMA could be extended to require EVM on a per IMA policy rule basis.
Instead of framing allowing IMA file hashes without EVM as a bug that
has existed from the very beginning, now that IMA/EVM have matured and
is being used, you could frame it as extending IMA or hardening.
>
> This patch mitigates the issue by selecting signature verification as the
> only method allowed for appraisal when EVM is not initialized. Since the
> new behavior might break user space, it must be turned on by adding the
> '-evm' suffix to the value of the ima_appraise= kernel option.
>
> Fixes: 2fe5d6def1672 ("ima: integrity appraisal extension")
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: stable@vger.kernel.org
> ---
> Documentation/admin-guide/kernel-parameters.txt | 3 ++-
> security/integrity/ima/ima_appraise.c | 8 ++++++++
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 138f6664b2e2..d84a2e612b93 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1585,7 +1585,8 @@
> Set number of hash buckets for inode cache.
>
> ima_appraise= [IMA] appraise integrity measurements
> - Format: { "off" | "enforce" | "fix" | "log" }
> + Format: { "off" | "enforce" | "fix" | "log" |
> + "enforce-evm" | "log-evm" }
Is it necessary to define both "enforce-evm" and "log-evm"? Perhaps
defining "require-evm" is sufficient.
Mimi
> default: "enforce"
>
> ima_appraise_tcb [IMA] Deprecated. Use ima_policy= instead.
> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> index 5fb7127bbe68..afef06e10fb9 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -18,6 +18,7 @@
>
> #include "ima.h"
>
> +static bool ima_appraise_req_evm __ro_after_init;
> static int __init default_appraise_setup(char *str)
> {
> #ifdef CONFIG_IMA_APPRAISE_BOOTPARAM
> @@ -28,6 +29,9 @@ static int __init default_appraise_setup(char *str)
> else if (strncmp(str, "fix", 3) == 0)
> ima_appraise = IMA_APPRAISE_FIX;
> #endif
> + if (strcmp(str, "enforce-evm") == 0 ||
> + strcmp(str, "log-evm") == 0)
> + ima_appraise_req_evm = true;
> return 1;
> }
>
> @@ -245,7 +249,11 @@ int ima_appraise_measurement(enum ima_hooks func,
> switch (status) {
> case INTEGRITY_PASS:
> case INTEGRITY_PASS_IMMUTABLE:
> + break;
> case INTEGRITY_UNKNOWN:
> + if (ima_appraise_req_evm &&
> + xattr_value->type != EVM_IMA_XATTR_DIGSIG)
> + goto out;
> break;
> case INTEGRITY_NOXATTRS: /* No EVM protected xattrs. */
> case INTEGRITY_NOLABEL: /* No security.evm xattr. */
^ permalink raw reply
* Re: [PATCH v8 1/7] iommu: enhance IOMMU default DMA mode build options
From: John Garry @ 2019-05-30 12:20 UTC (permalink / raw)
To: Zhen Lei, Jean-Philippe Brucker, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Hanjun Guo, Linuxarm
In-Reply-To: <20190530034831.4184-2-thunder.leizhen@huawei.com>
On 30/05/2019 04:48, Zhen Lei wrote:
> First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
> opportunity to set {lazy|strict} mode as default at build time. Then put
> the three config options in an choice, make people can only choose one of
> the three at a time.
>
Since this was not picked up, but modulo (somtimes same) comments below:
Reviewed-by: John Garry <john.garry@huawei.com>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> drivers/iommu/Kconfig | 42 +++++++++++++++++++++++++++++++++++-------
> drivers/iommu/iommu.c | 3 ++-
> 2 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 83664db5221df02..d6a1a45f80ffbf5 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -75,17 +75,45 @@ config IOMMU_DEBUGFS
> debug/iommu directory, and then populate a subdirectory with
> entries as required.
>
> -config IOMMU_DEFAULT_PASSTHROUGH
> - bool "IOMMU passthrough by default"
> +choice
> + prompt "IOMMU default DMA mode"
> depends on IOMMU_API
> - help
> - Enable passthrough by default, removing the need to pass in
> - iommu.passthrough=on or iommu=pt through command line. If this
> - is enabled, you can still disable with iommu.passthrough=off
> - or iommu=nopt depending on the architecture.
> + default IOMMU_DEFAULT_STRICT
> + help
> + This option allows IOMMU DMA mode to be chose at build time, to
As before:
/s/chose/chosen/, /s/allows IOMMU/allows an IOMMU/
> + override the default DMA mode of each ARCHs, removing the need to
Again, as before:
ARCHs should be singular
> + pass in kernel parameters through command line. You can still use
> + ARCHs specific boot options to override this option again.
> +
> +config IOMMU_DEFAULT_PASSTHROUGH
> + bool "passthrough"
> + help
> + In this mode, the DMA access through IOMMU without any addresses
> + translation. That means, the wrong or illegal DMA access can not
> + be caught, no error information will be reported.
>
> If unsure, say N here.
>
> +config IOMMU_DEFAULT_LAZY
> + bool "lazy"
> + help
> + Support lazy mode, where for every IOMMU DMA unmap operation, the
> + flush operation of IOTLB and the free operation of IOVA are deferred.
> + They are only guaranteed to be done before the related IOVA will be
> + reused.
why no advisory on how to set if unsure?
> +
> +config IOMMU_DEFAULT_STRICT
> + bool "strict"
> + help
> + For every IOMMU DMA unmap operation, the flush operation of IOTLB and
> + the free operation of IOVA are guaranteed to be done in the unmap
> + function.
> +
> + This mode is safer than the two above, but it maybe slower in some
> + high performace scenarios.
and here?
> +
> +endchoice
> +
> config OF_IOMMU
> def_bool y
> depends on OF && IOMMU_API
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 67ee6623f9b2a4d..56bce221285b15f 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -43,7 +43,8 @@
> #else
> static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
> #endif
> -static bool iommu_dma_strict __read_mostly = true;
> +static bool iommu_dma_strict __read_mostly =
> + IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
>
> struct iommu_group {
> struct kobject kobj;
>
^ permalink raw reply
* Re: [PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Michael Ellerman @ 2019-05-30 12:55 UTC (permalink / raw)
To: Bhupesh Sharma, linuxppc-dev
Cc: arnd, bhsharma, bhupesh.linux, benh, paulus, linux-kernel, corbet,
linux-doc
In-Reply-To: <1559212177-7072-1-git-send-email-bhsharma@redhat.com>
Bhupesh Sharma <bhsharma@redhat.com> writes:
> powerpc architecture (both 64-bit and 32-bit) supports stack protector
> mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
> add stack protector support")].
>
> Update stackprotector arch support documentation to reflect the same.
>
> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> ---
> Documentation/features/debug/stackprotector/arch-support.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt
> index 9999ea521f3e..32bbdfc64c32 100644
> --- a/Documentation/features/debug/stackprotector/arch-support.txt
> +++ b/Documentation/features/debug/stackprotector/arch-support.txt
> @@ -22,7 +22,7 @@
> | nios2: | TODO |
> | openrisc: | TODO |
> | parisc: | TODO |
> - | powerpc: | TODO |
> + | powerpc: | ok |
> | riscv: | TODO |
> | s390: | TODO |
> | sh: | ok |
> --
> 2.7.4
Thanks.
This should probably go via the documentation tree?
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
* Re: [PATCH v6 00/12] Include linux PCI docs into Sphinx TOC tree
From: Bjorn Helgaas @ 2019-05-30 13:04 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Changbin Du, linux-pci, linux-doc, linux-kernel, mchehab+samsung
In-Reply-To: <20190530030139.GI28250@google.com>
On Wed, May 29, 2019 at 10:01:39PM -0500, Bjorn Helgaas wrote:
> On Wed, May 29, 2019 at 04:35:10PM -0600, Jonathan Corbet wrote:
> > On Mon, 20 May 2019 06:10:15 +0000
> > Changbin Du <changbin.du@gmail.com> wrote:
> >
> > > Bjorn and Jonathan,
> > > Could we consider to merge this serias now? Thanks.
> >
> > Somewhat belatedly, but I think we could. Bjorn, do you have a preference
> > for which tree this goes through? I don't remember if we'd come to an
> > agreement on that or not, sorry...
>
> Actually, let me at least take a look at these. I noticed that
> renames caused some of the ACPI docs to end up with lines >80 columns,
> and I'd prefer to avoid that. So maybe I'll take these after all if
> that's OK.
I applied these to pci/docs for v5.3, thanks!
^ permalink raw reply
* Re: [PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Bhupesh Sharma @ 2019-05-30 13:07 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Arnd Bergmann, Bhupesh SHARMA,
Benjamin Herrenschmidt, Paul Mackerras, Linux Kernel Mailing List,
corbet, linux-doc
In-Reply-To: <87v9xsnlu9.fsf@concordia.ellerman.id.au>
On Thu, May 30, 2019 at 6:25 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Bhupesh Sharma <bhsharma@redhat.com> writes:
> > powerpc architecture (both 64-bit and 32-bit) supports stack protector
> > mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
> > add stack protector support")].
> >
> > Update stackprotector arch support documentation to reflect the same.
> >
> > Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> > ---
> > Documentation/features/debug/stackprotector/arch-support.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt
> > index 9999ea521f3e..32bbdfc64c32 100644
> > --- a/Documentation/features/debug/stackprotector/arch-support.txt
> > +++ b/Documentation/features/debug/stackprotector/arch-support.txt
> > @@ -22,7 +22,7 @@
> > | nios2: | TODO |
> > | openrisc: | TODO |
> > | parisc: | TODO |
> > - | powerpc: | TODO |
> > + | powerpc: | ok |
> > | riscv: | TODO |
> > | s390: | TODO |
> > | sh: | ok |
> > --
> > 2.7.4
>
> Thanks.
>
> This should probably go via the documentation tree?
>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Thanks for the review Michael.
I am ok with this going through the documentation tree as well.
Regards,
Bhupesh
^ permalink raw reply
* Re: [PATCH 22/22] docs: fix broken documentation links
From: Sven Van Asbroeck @ 2019-05-30 13:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Greg KH, Linux Kernel Mailing List, Linux Doc Mailing List
In-Reply-To: <f9fecacbe4ce0b2b3aed38d71ae3753f2daf3ce3.1559171394.git.mchehab+samsung@kernel.org>
On Wed, May 29, 2019 at 7:24 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
For drivers/staging/fieldbus/Documentation/fieldbus_dev.txt:
Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com>
^ permalink raw reply
* Re: [PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Jonathan Corbet @ 2019-05-30 14:13 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Michael Ellerman, linuxppc-dev, Arnd Bergmann, Bhupesh SHARMA,
Benjamin Herrenschmidt, Paul Mackerras, Linux Kernel Mailing List,
linux-doc
In-Reply-To: <CACi5LpM9v1YC_6HhA-uKghawzkEu=TTPVkomMmv2i-LGi8X7+g@mail.gmail.com>
On Thu, 30 May 2019 18:37:46 +0530
Bhupesh Sharma <bhsharma@redhat.com> wrote:
> > This should probably go via the documentation tree?
> >
> > Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>
> Thanks for the review Michael.
> I am ok with this going through the documentation tree as well.
Works for me too, but I don't seem to find the actual patch anywhere I
look. Can you send me a copy?
Thanks,
jon
^ permalink raw reply
* Re: [lwn:docs-next 19/19] htmldocs: include/linux/generic-radix-tree.h:1: warning: 'Generic radix trees/sparse arrays' not found
From: Jonathan Corbet @ 2019-05-30 14:40 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, linux-doc
In-Reply-To: <201905301152.nK61DkP1%lkp@intel.com>
On Thu, 30 May 2019 11:14:54 +0800
kbuild test robot <lkp@intel.com> wrote:
> tree: git://git.lwn.net/linux-2.6 docs-next
> head: b0d60bfbb60cef1efd699a65e29a94487f8c7b1f
> commit: b0d60bfbb60cef1efd699a65e29a94487f8c7b1f [19/19] kernel-doc: always name missing kerneldoc sections
> reproduce: make htmldocs
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
So, for anybody watching at home, the issue is stuff like this:
> >> include/linux/generic-radix-tree.h:1: warning: 'Generic radix trees/sparse arrays' not found
[...]
> >> drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found
> >> drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found
> >> drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found
> >> drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found
These warnings are not new, but the text has changed. They all used to
just read "no structured comments found"; now we know exactly what
kernel-doc was told to look for and didn't find.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 4/5] docs: by default, build docs a lot faster with Sphinx >= 1.7
From: Jonathan Corbet @ 2019-05-30 14:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190529225305.213d8c36@coco.lan>
On Wed, 29 May 2019 22:53:05 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > Yup. The point is that I see the sphinx-build output *in the docs-build
> > output", not when I run it standalone (where it does the expected thing).
>
> Weird... could some versions of Sphinx be redirecting the output of
> --version to stderr instead of stdout?
>
> If so, something like:
>
> perl -e 'open IN,"sphinx-build --version 2>&1 |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto\n" if ($1 >= "1.7") } ;} close IN'
>
> would make it print "-jauto" with those other versions you're trying.
That does improve the behavior from the command line; it seems that
sphinx-build is indeed writing to stderr. BUT that still doesn't fix the
docs build! To get the option to take effect, I also have to explicitly
export SPHINXOPTS. So the winning combination is:
export SPHINXOPTS = $(shell perl -e 'open IN,"sphinx-build --version
2>&1 |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto" if ($$1 >= "1.7") } ;} close IN')
I don't have any weird version of make, so I'm not sure why you see
different results than I do here.
I can apply those tweaks to your patch if it's OK with you.
> I didn't try the python2 versions, though.
Interestingly, I would appear to have both versions installed, with
python2 winning in $PATH.
jon
^ permalink raw reply
* Re: [PATCH 4/5] docs: by default, build docs a lot faster with Sphinx >= 1.7
From: Mauro Carvalho Chehab @ 2019-05-30 15:08 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190530085404.54973d02@lwn.net>
Em Thu, 30 May 2019 08:54:04 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 29 May 2019 22:53:05 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > > Yup. The point is that I see the sphinx-build output *in the docs-build
> > > output", not when I run it standalone (where it does the expected thing).
> >
> > Weird... could some versions of Sphinx be redirecting the output of
> > --version to stderr instead of stdout?
> >
> > If so, something like:
> >
> > perl -e 'open IN,"sphinx-build --version 2>&1 |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto\n" if ($1 >= "1.7") } ;} close IN'
> >
> > would make it print "-jauto" with those other versions you're trying.
>
> That does improve the behavior from the command line; it seems that
> sphinx-build is indeed writing to stderr. BUT that still doesn't fix the
> docs build! To get the option to take effect, I also have to explicitly
> export SPHINXOPTS. So the winning combination is:
>
> export SPHINXOPTS = $(shell perl -e 'open IN,"sphinx-build --version
> 2>&1 |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto" if ($$1 >= "1.7") } ;} close IN')
>
> I don't have any weird version of make, so I'm not sure why you see
> different results than I do here.
>
> I can apply those tweaks to your patch if it's OK with you.
Yeah, sure! With those changes it work fine here too.
So, feel free to apply the changes.
>
> > I didn't try the python2 versions, though.
>
> Interestingly, I would appear to have both versions installed, with
> python2 winning in $PATH.
It sounds that Fedora 30 is conservative with regards to python :-)
The Sphinx version detection script takes it into account,
suggesting pip3 instead of pip - or when called like:
$ ./scripts/sphinx-pre-install --no-virtualenv
Detected OS: Fedora release 30 (Thirty).
ERROR: please install "python-sphinx", otherwise, build won't work.
Warning: better to also install "sphinx_rtd_theme".
You should run:
sudo dnf install -y python3-sphinx python3-sphinx_rtd_theme
It seeks for the python3 packages on Fedora.
Regards,
Mauro
^ permalink raw reply
* [PATCH v4 0/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-05-30 15:27 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, Sasha Levin
Changes since v3:
- Address comments by Jarkko Sakkinen
- Address comments by Igor Opaniuk
Sasha Levin (2):
fTPM: firmware TPM running in TEE
fTPM: add documentation for ftpm driver
Documentation/security/tpm/index.rst | 1 +
Documentation/security/tpm/tpm_ftpm_tee.rst | 31 ++
drivers/char/tpm/Kconfig | 5 +
drivers/char/tpm/Makefile | 1 +
drivers/char/tpm/tpm_ftpm_tee.c | 380 ++++++++++++++++++++
drivers/char/tpm/tpm_ftpm_tee.h | 40 +++
6 files changed, 458 insertions(+)
create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
--
2.20.1
^ permalink raw reply
* [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-05-30 15:27 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, Sasha Levin
In-Reply-To: <20190530152758.16628-1-sashal@kernel.org>
This patch adds support for a software-only implementation of a TPM
running in TEE.
There is extensive documentation of the design here:
https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/ .
As well as reference code for the firmware available here:
https://github.com/Microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM
Signed-off-by: Thirupathaiah Annapureddy <thiruan@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/char/tpm/Kconfig | 5 +
drivers/char/tpm/Makefile | 1 +
drivers/char/tpm/tpm_ftpm_tee.c | 380 ++++++++++++++++++++++++++++++++
drivers/char/tpm/tpm_ftpm_tee.h | 40 ++++
4 files changed, 426 insertions(+)
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index f3e4bc490cf05..8bc9a56cade14 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -163,6 +163,11 @@ config TCG_VTPM_PROXY
/dev/vtpmX and a server-side file descriptor on which the vTPM
can receive commands.
+config TCG_FTPM_TEE
+ tristate "TEE based fTPM Interface"
+ depends on TEE && OPTEE
+ ---help---
+ This driver proxies for fTPM running in TEE
source "drivers/char/tpm/st33zp24/Kconfig"
endif # TCG_TPM
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a01c4cab902a6..c354cdff9c625 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
obj-$(CONFIG_TCG_CRB) += tpm_crb.o
obj-$(CONFIG_TCG_VTPM_PROXY) += tpm_vtpm_proxy.o
+obj-$(CONFIG_TCG_FTPM_TEE) += tpm_ftpm_tee.o
diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
new file mode 100644
index 0000000000000..f926b1287988b
--- /dev/null
+++ b/drivers/char/tpm/tpm_ftpm_tee.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Microsoft Corporation
+ *
+ * Implements a firmware TPM as described here:
+ * https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/
+ *
+ * A reference implementation is available here:
+ * https://github.com/microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM/optee_ta/fTPM
+ */
+
+#include <linux/acpi.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/tee_drv.h>
+#include <linux/tpm.h>
+#include <linux/uuid.h>
+
+#include "tpm.h"
+#include "tpm_ftpm_tee.h"
+
+#define DRIVER_NAME "ftpm-tee"
+
+/*
+ * TA_FTPM_UUID: BC50D971-D4C9-42C4-82CB-343FB7F37896
+ *
+ * Randomly generated, and must correspond to the GUID on the TA side.
+ * Defined here in the reference implementation:
+ * https://github.com/microsoft/ms-tpm-20-ref/blob/master/Samples/ARM32-FirmwareTPM/optee_ta/fTPM/include/fTPM.h#L42
+ */
+
+static const uuid_t ftpm_ta_uuid =
+ UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
+ 0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x96);
+
+/**
+ * ftpm_tee_tpm_op_recv - retrieve fTPM response.
+ *
+ * @chip: the tpm_chip description as specified in driver/char/tpm/tpm.h.
+ * @buf: the buffer to store data.
+ * @count: the number of bytes to read.
+ *
+ * Return:
+ * In case of success the number of bytes received.
+ * On failure, -errno.
+ */
+static int ftpm_tee_tpm_op_recv(struct tpm_chip *chip, u8 *buf, size_t count)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
+ size_t len;
+
+ len = pvt_data->resp_len;
+ if (count < len) {
+ dev_err(&chip->dev,
+ "%s:Invalid size in recv: count=%zd, resp_len=%zd\n",
+ __func__, count, len);
+ return -EIO;
+ }
+
+ memcpy(buf, pvt_data->resp_buf, len);
+ pvt_data->resp_len = 0;
+
+ return len;
+}
+
+/**
+ * ftpm_tee_tpm_op_send - send TPM commands through the TEE shared memory.
+ *
+ * @chip: the tpm_chip description as specified in driver/char/tpm/tpm.h
+ * @buf: the buffer to send.
+ * @len: the number of bytes to send.
+ *
+ * Return:
+ * In case of success, returns 0.
+ * On failure, -errno
+ */
+static int ftpm_tee_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t len)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
+ size_t resp_len;
+ int rc;
+ u8 *temp_buf;
+ struct tpm_header *resp_header;
+ struct tee_ioctl_invoke_arg transceive_args;
+ struct tee_param command_params[4];
+ struct tee_shm *shm = pvt_data->shm;
+
+ if (len > MAX_COMMAND_SIZE) {
+ dev_err(&chip->dev,
+ "%s:len=%zd exceeds MAX_COMMAND_SIZE supported by fTPM TA\n",
+ __func__, len);
+ return -EIO;
+ }
+
+ memset(&transceive_args, 0, sizeof(transceive_args));
+ memset(command_params, 0, sizeof(command_params));
+ pvt_data->resp_len = 0;
+
+ /* Invoke FTPM_OPTEE_TA_SUBMIT_COMMAND function of fTPM TA */
+ transceive_args = (struct tee_ioctl_invoke_arg) {
+ .func = FTPM_OPTEE_TA_SUBMIT_COMMAND,
+ .session = pvt_data->session,
+ .num_params = 4,
+ };
+
+ /* Fill FTPM_OPTEE_TA_SUBMIT_COMMAND parameters */
+ command_params[0] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
+ .u.memref = {
+ .shm = shm,
+ .size = len,
+ .shm_offs = 0,
+ },
+ };
+
+ temp_buf = tee_shm_get_va(shm, 0);
+ if (IS_ERR(temp_buf)) {
+ dev_err(&chip->dev, "%s:tee_shm_get_va failed for transmit\n",
+ __func__);
+ return PTR_ERR(temp_buf);
+ }
+ memset(temp_buf, 0, (MAX_COMMAND_SIZE + MAX_RESPONSE_SIZE));
+
+ memcpy(temp_buf, buf, len);
+
+ command_params[1] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
+ .u.memref = {
+ .shm = shm,
+ .size = MAX_RESPONSE_SIZE,
+ .shm_offs = MAX_COMMAND_SIZE,
+ },
+ };
+
+ rc = tee_client_invoke_func(pvt_data->ctx, &transceive_args,
+ command_params);
+ if ((rc < 0) || (transceive_args.ret != 0)) {
+ dev_err(&chip->dev, "%s:SUBMIT_COMMAND invoke error: 0x%x\n",
+ __func__, transceive_args.ret);
+ return (rc < 0) ? rc : transceive_args.ret;
+ }
+
+ temp_buf = tee_shm_get_va(shm, command_params[1].u.memref.shm_offs);
+ if (IS_ERR(temp_buf)) {
+ dev_err(&chip->dev, "%s:tee_shm_get_va failed for receive\n",
+ __func__);
+ return PTR_ERR(temp_buf);
+ }
+
+ resp_header = (struct tpm_header *)temp_buf;
+ resp_len = be32_to_cpu(resp_header->length);
+
+ /* sanity check resp_len */
+ if (resp_len < TPM_HEADER_SIZE) {
+ dev_err(&chip->dev, "%s:tpm response header too small\n",
+ __func__);
+ return -EIO;
+ }
+ if (resp_len > MAX_RESPONSE_SIZE) {
+ dev_err(&chip->dev,
+ "%s:resp_len=%zd exceeds MAX_RESPONSE_SIZE\n",
+ __func__, resp_len);
+ return -EIO;
+ }
+
+ /* sanity checks look good, cache the response */
+ memcpy(pvt_data->resp_buf, temp_buf, resp_len);
+ pvt_data->resp_len = resp_len;
+
+ return 0;
+}
+
+static void ftpm_tee_tpm_op_cancel(struct tpm_chip *chip)
+{
+ /* not supported */
+}
+
+static u8 ftpm_tee_tpm_op_status(struct tpm_chip *chip)
+{
+ return 0;
+}
+
+static bool ftpm_tee_tpm_req_canceled(struct tpm_chip *chip, u8 status)
+{
+ return 0;
+}
+
+static const struct tpm_class_ops ftpm_tee_tpm_ops = {
+ .flags = TPM_OPS_AUTO_STARTUP,
+ .recv = ftpm_tee_tpm_op_recv,
+ .send = ftpm_tee_tpm_op_send,
+ .cancel = ftpm_tee_tpm_op_cancel,
+ .status = ftpm_tee_tpm_op_status,
+ .req_complete_mask = 0,
+ .req_complete_val = 0,
+ .req_canceled = ftpm_tee_tpm_req_canceled,
+};
+
+/*
+ * Check whether this driver supports the fTPM TA in the TEE instance
+ * represented by the params (ver/data) to this function.
+ */
+static int ftpm_tee_match(struct tee_ioctl_version_data *ver, const void *data)
+{
+ /*
+ * Currently this driver only support GP Complaint OPTEE based fTPM TA
+ */
+ if ((ver->impl_id == TEE_IMPL_ID_OPTEE) &&
+ (ver->gen_caps & TEE_GEN_CAP_GP))
+ return 1;
+ else
+ return 0;
+}
+
+/*
+ * Undo what has been done in ftpm_tee_probe
+ */
+static void ftpm_tee_deinit(struct ftpm_tee_private *pvt_data)
+{
+ /* Release the chip */
+ tpm_chip_unregister(pvt_data->chip);
+
+ /* frees chip */
+ if (pvt_data->chip)
+ put_device(&pvt_data->chip->dev);
+
+ if (pvt_data->ctx) {
+ /* Free the shared memory pool */
+ tee_shm_free(pvt_data->shm);
+
+ /* close the existing session with fTPM TA*/
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+
+ /* close the context with TEE driver */
+ tee_client_close_context(pvt_data->ctx);
+ }
+
+ /* memory allocated with devm_kzalloc() is freed automatically */
+}
+
+/**
+ * ftpm_tee_probe - initialize the fTPM
+ * @pdev: the platform_device description.
+ *
+ * Return:
+ * On success, 0. On failure, -errno.
+ */
+static int ftpm_tee_probe(struct platform_device *pdev)
+{
+ int rc;
+ struct tpm_chip *chip;
+ struct device *dev = &pdev->dev;
+ struct ftpm_tee_private *pvt_data = NULL;
+ struct tee_ioctl_open_session_arg sess_arg;
+
+ pvt_data = devm_kzalloc(dev, sizeof(struct ftpm_tee_private),
+ GFP_KERNEL);
+ if (!pvt_data)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, pvt_data);
+
+ /* Open context with TEE driver */
+ pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
+ NULL);
+ if (IS_ERR(pvt_data->ctx)) {
+ dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
+ return -EPROBE_DEFER;
+ }
+
+ /* Open a session with fTPM TA */
+ memset(&sess_arg, 0, sizeof(sess_arg));
+ memcpy(sess_arg.uuid, ftpm_ta_uuid.b, TEE_IOCTL_UUID_LEN);
+ sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
+ sess_arg.num_params = 0;
+
+ rc = tee_client_open_session(pvt_data->ctx, &sess_arg, NULL);
+ if ((rc < 0) || (sess_arg.ret != 0)) {
+ dev_err(dev, "%s:tee_client_open_session failed, err=%x\n",
+ __func__, sess_arg.ret);
+ rc = -EINVAL;
+ goto out_tee_session;
+ }
+ pvt_data->session = sess_arg.session;
+
+ /* Allocate dynamic shared memory with fTPM TA */
+ pvt_data->shm = tee_shm_alloc(pvt_data->ctx,
+ (MAX_COMMAND_SIZE + MAX_RESPONSE_SIZE),
+ TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
+ if (IS_ERR(pvt_data->shm)) {
+ dev_err(dev, "%s:tee_shm_alloc failed\n", __func__);
+ rc = -ENOMEM;
+ goto out_shm_alloc;
+ }
+
+ /* Allocate new struct tpm_chip instance */
+ chip = tpm_chip_alloc(dev, &ftpm_tee_tpm_ops);
+ if (IS_ERR(chip)) {
+ dev_err(dev, "%s:tpm_chip_alloc failed\n", __func__);
+ rc = PTR_ERR(chip);
+ goto out_chip_alloc;
+ }
+
+ pvt_data->chip = chip;
+ pvt_data->chip->flags |= TPM_CHIP_FLAG_TPM2;
+
+ /* Create a character device for the fTPM */
+ rc = tpm_chip_register(pvt_data->chip);
+ if (rc) {
+ dev_err(dev, "%s:tpm_chip_register failed with rc=%d\n",
+ __func__, rc);
+ goto out_chip;
+ }
+
+ return 0;
+
+out_chip:
+ put_device(&pvt_data->chip->dev);
+out_chip_alloc:
+ tee_shm_free(pvt_data->shm);
+out_shm_alloc:
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+out_tee_session:
+ tee_client_close_context(pvt_data->ctx);
+
+ return rc;
+}
+
+/**
+ * ftpm_tee_remove - remove the TPM device
+ * @pdev: the platform_device description.
+ *
+ * Return:
+ * 0 in case of success.
+ */
+static int ftpm_tee_remove(struct platform_device *pdev)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(&pdev->dev);
+
+ /* Release the chip */
+ tpm_chip_unregister(pvt_data->chip);
+
+ /* frees chip */
+ put_device(&pvt_data->chip->dev);
+
+ /* Free the shared memory pool */
+ tee_shm_free(pvt_data->shm);
+
+ /* close the existing session with fTPM TA*/
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+
+ /* close the context with TEE driver */
+ tee_client_close_context(pvt_data->ctx);
+
+ /* memory allocated with devm_kzalloc() is freed automatically */
+
+ return 0;
+}
+
+static const struct of_device_id of_ftpm_tee_ids[] = {
+ { .compatible = "microsoft,ftpm" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids);
+
+static struct platform_driver ftpm_tee_driver = {
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(of_ftpm_tee_ids),
+ },
+ .probe = ftpm_tee_probe,
+ .remove = ftpm_tee_remove,
+};
+
+module_platform_driver(ftpm_tee_driver);
+
+MODULE_AUTHOR("Thirupathaiah Annapureddy <thiruan@microsoft.com>");
+MODULE_DESCRIPTION("TPM Driver for fTPM TA in TEE");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/char/tpm/tpm_ftpm_tee.h b/drivers/char/tpm/tpm_ftpm_tee.h
new file mode 100644
index 0000000000000..b09ee7be45459
--- /dev/null
+++ b/drivers/char/tpm/tpm_ftpm_tee.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) Microsoft Corporation
+ */
+
+#ifndef __TPM_FTPM_TEE_H__
+#define __TPM_FTPM_TEE_H__
+
+#include <linux/tee_drv.h>
+#include <linux/tpm.h>
+#include <linux/uuid.h>
+
+/* The TAFs ID implemented in this TA */
+#define FTPM_OPTEE_TA_SUBMIT_COMMAND (0)
+#define FTPM_OPTEE_TA_EMULATE_PPI (1)
+
+/* max. buffer size supported by fTPM */
+#define MAX_COMMAND_SIZE 4096
+#define MAX_RESPONSE_SIZE 4096
+
+/**
+ * struct ftpm_tee_private - fTPM's private data
+ * @chip: struct tpm_chip instance registered with tpm framework.
+ * @state: internal state
+ * @session: fTPM TA session identifier.
+ * @resp_len: cached response buffer length.
+ * @resp_buf: cached response buffer.
+ * @ctx: TEE context handler.
+ * @shm: Memory pool shared with fTPM TA in TEE.
+ */
+struct ftpm_tee_private {
+ struct tpm_chip *chip;
+ u32 session;
+ size_t resp_len;
+ u8 resp_buf[MAX_RESPONSE_SIZE];
+ struct tee_context *ctx;
+ struct tee_shm *shm;
+};
+
+#endif /* __TPM_FTPM_TEE_H__ */
--
2.20.1
^ permalink raw reply related
* [PATCH v4 2/2] fTPM: add documentation for ftpm driver
From: Sasha Levin @ 2019-05-30 15:27 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, Sasha Levin
In-Reply-To: <20190530152758.16628-1-sashal@kernel.org>
This patch adds basic documentation to describe the new fTPM driver.
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>
---
Documentation/security/tpm/index.rst | 1 +
Documentation/security/tpm/tpm_ftpm_tee.rst | 31 +++++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
diff --git a/Documentation/security/tpm/index.rst b/Documentation/security/tpm/index.rst
index af77a7bbb0700..15783668644f2 100644
--- a/Documentation/security/tpm/index.rst
+++ b/Documentation/security/tpm/index.rst
@@ -4,4 +4,5 @@ Trusted Platform Module documentation
.. toctree::
+ tpm_ftpm_tee
tpm_vtpm_proxy
diff --git a/Documentation/security/tpm/tpm_ftpm_tee.rst b/Documentation/security/tpm/tpm_ftpm_tee.rst
new file mode 100644
index 0000000000000..29c2f8b5ed100
--- /dev/null
+++ b/Documentation/security/tpm/tpm_ftpm_tee.rst
@@ -0,0 +1,31 @@
+=============================================
+Firmware TPM Driver
+=============================================
+
+| Authors:
+| Thirupathaiah Annapureddy <thiruan@microsoft.com>
+| Sasha Levin <sashal@kernel.org>
+
+This document describes the firmware Trusted Platform Module (fTPM)
+device driver.
+
+Introduction
+============
+
+This driver is a shim for a firmware implemented in ARM's TrustZone
+environment. The driver allows programs to interact with the TPM in the same
+way the would interact with a hardware TPM.
+
+Design
+======
+
+The driver acts as a thin layer that passes commands to and from a TPM
+implemented in firmware. The driver itself doesn't contain much logic and is
+used more like a dumb pipe between firmware and kernel/userspace.
+
+The firmware itself is based on the following paper:
+https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf
+
+When the driver is loaded it will expose ``/dev/tpmX`` character devices to
+userspace which will enable userspace to communicate with the firmware tpm
+through this device.
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 00/10] Improvements to the documentation build system
From: Jonathan Corbet @ 2019-05-30 16:43 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Matthew Wilcox, Federico Vaga, Joel Nider, Mike Rapoport
In-Reply-To: <cover.1559170790.git.mchehab+samsung@kernel.org>
On Wed, 29 May 2019 20:09:22 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> This series contain some improvements for the building system.
>
> I sent already several of the patches here. They're rebased on the
> top of your docs-next tree:
The set is now applied...
> patch 1: gets rid of a warning since version 1.8 (I guess it starts
> appearing with 1.8.6);
This one I'd already picked up before.
> patches 2 to 4: improve the pre-install script;
>
> patches 5 to 8: improve the script with checks broken doc references;
>
> patch 9: by default, use "-jauto" with Sphinx 1.7 or upper, in order
> to speed up the build.
I put in the tweak we discussed here.
> patch 10 changes the recommended Sphinx version to 1.7.9. It keeps
> the minimal supported version to 1.3.
>
> Patch 4 contains a good description of the improvements made at
> the build system.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 01/22] ABI: sysfs-devices-system-cpu: point to the right docs
From: Rafael J. Wysocki @ 2019-05-30 16:57 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Thomas Gleixner, Jon Masters, Greg Kroah-Hartman,
Borislav Petkov, Josh Poimboeuf, Rafael J. Wysocki, Jiri Kosina
In-Reply-To: <557b33a4ed53fb1cd5da927c533e7fe283629869.1559171394.git.mchehab+samsung@kernel.org>
On Thursday, May 30, 2019 1:23:32 AM CEST Mauro Carvalho Chehab wrote:
> The cpuidle doc was split on two, one at the admin guide
> and another one at the driver API guide. Instead of pointing
> to a non-existent file, point to both (admin guide being
> the first one).
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> Documentation/ABI/testing/sysfs-devices-system-cpu | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index 1528239f69b2..87478ac6c2af 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -137,7 +137,8 @@ Description: Discover cpuidle policy and mechanism
> current_governor: (RW) displays current idle policy. Users can
> switch the governor at runtime by writing to this file.
>
> - See files in Documentation/cpuidle/ for more information.
> + See Documentation/admin-guide/pm/cpuidle.rst and
> + Documentation/driver-api/pm/cpuidle.rst for more information.
>
>
> What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/name
>
^ permalink raw reply
* Re: [PATCH v3 1/1] sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
From: Dave Chiluk @ 2019-05-30 17:53 UTC (permalink / raw)
To: bsegall
Cc: Phil Auld, Peter Oskolkov, Peter Zijlstra, Ingo Molnar, cgroups,
linux-kernel, Brendan Gregg, Kyle Anderson, Gabriel Munos,
John Hammond, Cong Wang, Jonathan Corbet, linux-doc, pjt
In-Reply-To: <xm264l5dynrg.fsf@bsegall-linux.svl.corp.google.com>
On Wed, May 29, 2019 at 02:05:55PM -0700, bsegall@google.com wrote:
> Dave Chiluk <chiluk+linux@indeed.com> writes:
>
> Yeah, having run the test, stranding only 1 ms per cpu rather than 5
> doesn't help if you only have 10 ms of quota and even 10 threads/cpus.
> The slack timer isn't important in this test, though I think it probably
> should be changed.
My min_cfs_rq_runtime was already set to 1ms.
Additionally raising the amount of quota from 10ms to 50ms or even
100ms, still results in throttling without full quota usage.
> Decreasing min_cfs_rq_runtime helps, but would mean that we have to pull
> quota more often / always. The worst case here I think is where you
> run/sleep for ~1ns, so you wind up taking the lock twice every
> min_cfs_rq_runtime: once for assign and once to return all but min,
> which you then use up doing short run/sleep. I suppose that determines
> how much we care about this overhead at all.
I'm not so concerned about how inefficiently the user-space application
runs, as that's up to the invidual developer. The fibtest testcase, is
purely my approximation of what a java application with lots of worker
threads might do, as I didn't have a great deterministic java
reproducer, and I feared posting java to LKML. I'm more concerned with
the fact that the user requested 10ms/period or 100ms/period and they
hit throttling while simultaneously not seeing that amount of cpu usage.
i.e. on an 8 core machine if I
$ ./runfibtest 1
Iterations Completed(M): 1886
Throttled for: 51
CPU Usage (msecs) = 507
$ ./runfibtest 8
Iterations Completed(M): 1274
Throttled for: 52
CPU Usage (msecs) = 380
You see that in the 8 core case where we have 7 do nothing threads on
cpu's 1-7, we see only 380 ms of usage, and 52 periods of throttling
when we should have received ~500ms of cpu usage.
Looking more closely at the __return_cfs_rq_runtime logic I noticed
if (cfs_b->quota != RUNTIME_INF &&
cfs_rq->runtime_expires == cfs_b->runtime_expires) {
Which is awfully similar to the logic that was fixed by 512ac999. Is it
possible that we are just not ever returning runtime back to the cfs_b
because of the runtime_expires comparison here?
Early on in my testing I created a patch that would report via sysfs the
amount of quota that was expired at the end of a period in
expire_cfs_rq_runtime, and it roughly equalled the difference in quota
between the actual cpu usage and the alloted quota. That leads me to
believe that something is not going quite correct in the slack return
logic __return_cfs_rq_runtime. I'll attach that patch at the bottom of
this e-mail in case you'd like to reproduce my tests.
> Removing expiration means that in the worst case period and quota can be
> effectively twice what the user specified, but only on very particular
> workloads.
I'm only removing expiration of slices that have already been assigned
to individual cfs_rq. My understanding is that there is at most one
cfs_rq per cpu, and each of those can have at most one slice of
available runtime. So the worst case burst is slice_ms * cpus. Please
help me understand how you get to twice user specified quota and period
as it's not obvious to me *(I've only been looking at this for a few
months).
> I think we should at least think about instead lowering
> min_cfs_rq_runtime to some smaller value
Do you mean lower than 1ms?
Thanks
Dave.
From: Dave Chiluk <chiluk+linux@indeed.com>
Date: Thu, 30 May 2019 12:47:12 -0500
Subject: [PATCH] Add expired_time sysfs entry
Signed-off-by: Dave Chiluk <chiluk+linux@indeed.com>
---
kernel/sched/core.c | 41 +++++++++++++++++++++++++++++++++++++++++
kernel/sched/fair.c | 4 ++++
kernel/sched/sched.h | 1 +
3 files changed, 46 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 874c427..3c06df9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6655,6 +6655,30 @@ static long tg_get_cfs_period(struct task_group *tg)
return cfs_period_us;
}
+static int tg_set_cfs_expired_runtime(struct task_group *tg, long
slice_expiration)
+{
+ struct cfs_bandwidth *cfs_b = &tg->cfs_bandwidth;
+
+ if (slice_expiration == 0)
+ {
+ raw_spin_lock_irq(&cfs_b->lock);
+ cfs_b->expired_runtime= 0;
+ raw_spin_unlock_irq(&cfs_b->lock);
+ return 0;
+ }
+ return 1;
+}
+
+static u64 tg_get_cfs_expired_runtime(struct task_group *tg)
+{
+ u64 expired_runtime;
+
+ expired_runtime = tg->cfs_bandwidth.expired_runtime;
+ do_div(expired_runtime, NSEC_PER_USEC);
+
+ return expired_runtime;
+}
+
static s64 cpu_cfs_quota_read_s64(struct cgroup_subsys_state *css,
struct cftype *cft)
{
@@ -6679,6 +6703,18 @@ static int cpu_cfs_period_write_u64(struct
cgroup_subsys_state *css,
return tg_set_cfs_period(css_tg(css), cfs_period_us);
}
+static u64 cpu_cfs_expired_runtime_read_u64(struct cgroup_subsys_state *css,
+ struct cftype *cft)
+{
+ return tg_get_cfs_expired_runtime(css_tg(css));
+}
+
+static int cpu_cfs_expired_runtime_write_s64(struct cgroup_subsys_state *css,
+ struct cftype *cftype, s64
cfs_slice_expiration_us)
+{
+ return tg_set_cfs_expired_runtime(css_tg(css), cfs_slice_expiration_us);
+}
+
struct cfs_schedulable_data {
struct task_group *tg;
u64 period, quota;
@@ -6832,6 +6868,11 @@ static u64 cpu_rt_period_read_uint(struct
cgroup_subsys_state *css,
.write_u64 = cpu_cfs_period_write_u64,
},
{
+ .name = "cfs_expired_runtime",
+ .read_u64 = cpu_cfs_expired_runtime_read_u64,
+ .write_s64 = cpu_cfs_expired_runtime_write_s64,
+ },
+ {
.name = "stat",
.seq_show = cpu_cfs_stat_show,
},
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f35930f..bcbd4ef 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4382,6 +4382,9 @@ static void expire_cfs_rq_runtime(struct cfs_rq *cfs_rq)
cfs_rq->runtime_expires += TICK_NSEC;
} else {
/* global deadline is ahead, expiration has passed */
+ raw_spin_lock_irq(&cfs_b->lock);
+ cfs_b->expired_runtime += cfs_rq->runtime_remaining;
+ raw_spin_unlock_irq(&cfs_b->lock);
cfs_rq->runtime_remaining = 0;
}
}
@@ -4943,6 +4946,7 @@ void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
cfs_b->runtime = 0;
cfs_b->quota = RUNTIME_INF;
cfs_b->period = ns_to_ktime(default_cfs_period());
+ cfs_b->expired_runtime = 0;
INIT_LIST_HEAD(&cfs_b->throttled_cfs_rq);
hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC,
HRTIMER_MODE_ABS_PINNED);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b52ed1a..499d2e2 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -343,6 +343,7 @@ struct cfs_bandwidth {
s64 hierarchical_quota;
u64 runtime_expires;
int expires_seq;
+ u64 expired_runtime;
short idle;
short period_active;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 08/22] docs: bpf: get rid of two warnings
From: Song Liu @ 2019-05-30 18:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, open list,
Jonathan Corbet, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Networking, bpf
In-Reply-To: <f2f40f306acbd3d834746fe9acb607052e82a1ee.1559171394.git.mchehab+samsung@kernel.org>
On Wed, May 29, 2019 at 4:25 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> Documentation/bpf/btf.rst:154: WARNING: Unexpected indentation.
> Documentation/bpf/btf.rst:163: WARNING: Unexpected indentation.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> Documentation/bpf/btf.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
> index 8820360d00da..4ae022d274ab 100644
> --- a/Documentation/bpf/btf.rst
> +++ b/Documentation/bpf/btf.rst
> @@ -151,6 +151,7 @@ for the type. The maximum value of ``BTF_INT_BITS()`` is 128.
>
> The ``BTF_INT_OFFSET()`` specifies the starting bit offset to calculate values
> for this int. For example, a bitfield struct member has:
> +
> * btf member bit offset 100 from the start of the structure,
> * btf member pointing to an int type,
> * the int type has ``BTF_INT_OFFSET() = 2`` and ``BTF_INT_BITS() = 4``
> @@ -160,6 +161,7 @@ from bits ``100 + 2 = 102``.
>
> Alternatively, the bitfield struct member can be the following to access the
> same bits as the above:
> +
> * btf member bit offset 102,
> * btf member pointing to an int type,
> * the int type has ``BTF_INT_OFFSET() = 0`` and ``BTF_INT_BITS() = 4``
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH 2/2] Docs: hwmon: pmbus: Add PXE1610 driver
From: Vijay Khemka @ 2019-05-30 18:51 UTC (permalink / raw)
To: Guenter Roeck, Jean Delvare, Jonathan Corbet,
linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: joel@jms.id.au, linux-aspeed@lists.ozlabs.org, Sai Dasari,
Greg Kroah-Hartman
In-Reply-To: <0a94e784-41a0-4f2d-f9f8-6b365a1e755e@roeck-us.net>
On 5/29/19, 6:05 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
On 5/29/19 3:35 PM, Vijay Khemka wrote:
> Added support for Infenion PXE1610 driver
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> ---
> Documentation/hwmon/pxe1610 | 84 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 84 insertions(+)
> create mode 100644 Documentation/hwmon/pxe1610
>
> diff --git a/Documentation/hwmon/pxe1610 b/Documentation/hwmon/pxe1610
> new file mode 100644
> index 000000000000..b5c83edf027a
> --- /dev/null
> +++ b/Documentation/hwmon/pxe1610
> @@ -0,0 +1,84 @@
> +Kernel driver pxe1610
> +=====================
> +
> +Supported chips:
> + * Infinion PXE1610
> + Prefix: 'pxe1610'
> + Addresses scanned: -
> + Datasheet: Datasheet is not publicly available.
> +
> + * Infinion PXE1110
> + Prefix: 'pxe1110'
> + Addresses scanned: -
> + Datasheet: Datasheet is not publicly available.
> +
> + * Infinion PXM1310
> + Prefix: 'pxm1310'
> + Addresses scanned: -
> + Datasheet: Datasheet is not publicly available.
> +
> +Author: Vijay Khemka <vijaykhemka@fb.com>
> +
> +
> +Description
> +-----------
> +
> +PXE1610 is a Multi-rail/Multiphase Digital Controllers and
> +it is compliant to Intel VR13 DC-DC converter specifications.
> +
And the others ?
This supports VR12 as well and I don't see this controller supports any other VR versions.
> +
> +Usage Notes
> +-----------
> +
> +This driver can be enabled with kernel config CONFIG_SENSORS_PXE1610
> +set to 'y' or 'm'(for module).
> +
The above does not really add value.
Ok, I will remove it.
> +This driver does not probe for PMBus devices. You will have
> +to instantiate devices explicitly.
> +
> +Example: the following commands will load the driver for an PXE1610
> +at address 0x70 on I2C bus #4:
> +
> +# modprobe pxe1610
> +# echo pxe1610 0x70 > /sys/bus/i2c/devices/i2c-4/new_device
> +
> +It can also be instantiated by declaring in device tree if it is
> +built as a kernel not as a module.
> +
I assume you mean "built into the kernel".
Why would devicetree based instantiation not work if the driver is built
as module ?
Will correct statement here.
> +
> +Sysfs attributes
> +----------------
> +
> +curr1_label "iin"
> +curr1_input Measured input current
> +curr1_alarm Current high alarm
> +
> +curr[2-4]_label "iout[1-3]"
> +curr[2-4]_input Measured output current
> +curr[2-4]_crit Critical maximum current
> +curr[2-4]_crit_alarm Current critical high alarm
> +
> +in1_label "vin"
> +in1_input Measured input voltage
> +in1_crit Critical maximum input voltage
> +in1_crit_alarm Input voltage critical high alarm
> +
> +in[2-4]_label "vout[1-3]"
> +in[2-4]_input Measured output voltage
> +in[2-4]_lcrit Critical minimum output voltage
> +in[2-4]_lcrit_alarm Output voltage critical low alarm
> +in[2-4]_crit Critical maximum output voltage
> +in[2-4]_crit_alarm Output voltage critical high alarm
> +
> +power1_label "pin"
> +power1_input Measured input power
> +power1_alarm Input power high alarm
> +
> +power[2-4]_label "pout[1-3]"
> +power[2-4]_input Measured output power
> +
> +temp[1-3]_input Measured temperature
> +temp[1-3]_crit Critical high temperature
> +temp[1-3]_crit_alarm Chip temperature critical high alarm
> +temp[1-3]_max Maximum temperature
> +temp[1-3]_max_alarm Chip temperature high alarm
>
^ permalink raw reply
* Re: [PATCH 1/2] hwmon: pmbus: Add Infineon PXE1610 VR driver
From: Vijay Khemka @ 2019-05-30 18:55 UTC (permalink / raw)
To: Guenter Roeck, Jean Delvare, Jonathan Corbet,
linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: joel@jms.id.au, linux-aspeed@lists.ozlabs.org, Sai Dasari,
Greg Kroah-Hartman
In-Reply-To: <e72ae680-e8b7-455a-fdde-af79d429dd8c@roeck-us.net>
On 5/29/19, 6:01 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
On 5/29/19 3:35 PM, Vijay Khemka wrote:
> Added pmbus driver for the new device Infineon pxe1610
> voltage regulator. It also supports similar family device
> PXE1110 and PXM1310.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> ---
> drivers/hwmon/pmbus/Kconfig | 9 +++
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/pxe1610.c | 119 ++++++++++++++++++++++++++++++++++
> 3 files changed, 129 insertions(+)
> create mode 100644 drivers/hwmon/pmbus/pxe1610.c
>
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 30751eb9550a..338ef9b5a395 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -154,6 +154,15 @@ config SENSORS_MAX8688
> This driver can also be built as a module. If so, the module will
> be called max8688.
>
> +config SENSORS_PXE1610
> + tristate "Infineon PXE1610"
> + help
> + If you say yes here you get hardware monitoring support for Infineon
> + PXE1610.
> +
> + This driver can also be built as a module. If so, the module will
> + be called pxe1610.
> +
> config SENSORS_TPS40422
> tristate "TI TPS40422"
> help
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 2219b9300316..b0fbd017a91a 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
> obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
> obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
> obj-$(CONFIG_SENSORS_MAX8688) += max8688.o
> +obj-$(CONFIG_SENSORS_PXE1610) += pxe1610.o
> obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
> obj-$(CONFIG_SENSORS_TPS53679) += tps53679.o
> obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
> diff --git a/drivers/hwmon/pmbus/pxe1610.c b/drivers/hwmon/pmbus/pxe1610.c
> new file mode 100644
> index 000000000000..01e267944df5
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/pxe1610.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Hardware monitoring driver for Infineon PXE1610
> + *
> + * Copyright (c) 2019 Facebook Inc
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include "pmbus.h"
> +
> +/*
> + * Identify chip parameters.
> + */
> +static int pxe1610_identify(struct i2c_client *client,
> + struct pmbus_driver_info *info)
Please align continuation lines with '('.
Ack.
> +{
> + if (pmbus_check_byte_register(client, 0, PMBUS_VOUT_MODE)) {
> + int vout_mode;
> +
> + vout_mode = pmbus_read_byte_data(client, 0, PMBUS_VOUT_MODE);
pmbus_read_byte_data() can return an error. Calling pmbus_check_byte_register()
doesn't really add any value here, since the second call can still fail,
which needs to be checked.
Ack.
> + switch (vout_mode & 0x1f) {
> + case 1:
> + info->vrm_version = vr12;
> + break;
Alignment is off.
Ack.
> + case 2:
> + info->vrm_version = vr13;
> + break;
Same here.
> + default:
> + return -ENODEV;
> + }
> + }
> + return 0;
> +}
> +
> +static int pxe1610_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct pmbus_driver_info *info;
> + u8 buf[I2C_SMBUS_BLOCK_MAX];
> + int ret;
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_READ_BYTE_DATA
> + | I2C_FUNC_SMBUS_READ_WORD_DATA
> + | I2C_FUNC_SMBUS_READ_BLOCK_DATA))
> + return -ENODEV;
> +
> + /* By default this device doesn't boot to page 0, so set page 0
> + * to access all pmbus registers.
> + */
Please use standard multi-line comments.
Ack.
> + i2c_smbus_write_byte_data(client, 0, 0);
> +
Please use the PMBUS_PAGE command definition.
Will use.
I wonder if it would make sense to initialize currpage in the core to an unreasonable
number for multi-page chips, but I guess that is a different question.
> + /* Read Manufacturer id */
> + ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to read PMBUS_MFR_ID\n");
> + return ret;
> + }
> + if (ret != 2 || strncmp(buf, "XP", strlen("XP"))) {
The strlen() is really unnecessary here. Just use 2 (and a define
for it if you like).
Ack
> + dev_err(&client->dev, "MFR_ID unrecognised\n");
unrecognized. Oh well, turns out unrecognised is the British spelling and
just as valid, so feel free to keep it if you like.
> + return -ENODEV;
> + }
> +
> + info = devm_kzalloc(&client->dev, sizeof(struct pmbus_driver_info),
> + GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + info->format[PSC_VOLTAGE_IN] = linear;
> + info->format[PSC_VOLTAGE_OUT] = vid;
> + info->format[PSC_CURRENT_IN] = linear;
> + info->format[PSC_CURRENT_OUT] = linear;
> + info->format[PSC_POWER] = linear;
> + info->format[PSC_TEMPERATURE] = linear;
> +
> + info->func[0] = PMBUS_HAVE_VIN
> + | PMBUS_HAVE_VOUT | PMBUS_HAVE_IIN
> + | PMBUS_HAVE_IOUT | PMBUS_HAVE_PIN
> + | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
> + | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT
> + | PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP;
> + info->func[1] = info->func[0];
> + info->func[2] = info->func[0];
> +
> + info->pages = id->driver_data;
> + info->identify = pxe1610_identify;
> +
It doesn't really add value to initialize all these parameters manually.
I would suggest to use the approach from tps53679.c, ie have a static
structure and use devm_kmemdup() to pass a copy to pmbus_do_probe().
Will look into this.
> + return pmbus_do_probe(client, id, info);
> +}
> +
> +static const struct i2c_device_id pxe1610_id[] = {
> + {"pxe1610", 3},
> + {"pxe1110", 3},
> + {"pxm1310", 3},
Unless there are chips with different page counts in the queue, using
driver_data to pass the number of pages does not add any value. Just
set num_pages to 3.
If you like, feel free to use a define instead of a constant.
Ack.
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, pxe1610_id);
> +
> +/* This is the driver that will be inserted */
This comment does not add any value.
> +static struct i2c_driver pxe1610_driver = {
> + .driver = {
> + .name = "pxe1610",
> + },
> + .probe = pxe1610_probe,
> + .remove = pmbus_do_remove,
> + .id_table = pxe1610_id,
> +};
> +
> +module_i2c_driver(pxe1610_driver);
> +
> +MODULE_AUTHOR("Vijay Khemka <vijaykhemka@fb.com>");
> +MODULE_DESCRIPTION("PMBus driver for Infineon PXE1610, PXE1110 and PXM1310");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* [PATCH v2] Allow to exclude specific file types in LoadPin
From: Ke Wu @ 2019-05-30 19:22 UTC (permalink / raw)
To: Kees Cook, Jonathan Corbet, James Morris, Serge E. Hallyn
Cc: linux-doc, linux-kernel, linux-security-module, Ke Wu
In-Reply-To: <20190529224350.6460-1-mikewu@google.com>
Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
make sure loaded kernel module and kernel image are trusted. This
patch adds a kernel command line option "loadpin.exclude" which
allows to exclude specific file types from LoadPin. This is useful
when people want to use different mechanisms to verify module and
kernel image while still use LoadPin to protect the integrity of
other files kernel loads.
Signed-off-by: Ke Wu <mikewu@google.com>
---
Changelog since v1:
- Mark ignore_read_file_id with __ro_after_init.
- Mark parse_exclude() with __init.
- Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
Documentation/admin-guide/LSM/LoadPin.rst | 10 ++++++
security/loadpin/loadpin.c | 38 +++++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
index 32070762d24c..716ad9b23c9a 100644
--- a/Documentation/admin-guide/LSM/LoadPin.rst
+++ b/Documentation/admin-guide/LSM/LoadPin.rst
@@ -19,3 +19,13 @@ block device backing the filesystem is not read-only, a sysctl is
created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
a mutable filesystem means pinning is mutable too, but having the
sysctl allows for easy testing on systems with a mutable filesystem.)
+
+It's also possible to exclude specific file types from LoadPin using kernel
+command line option "``loadpin.exclude``". By default, all files are
+included, but they can be excluded using kernel command line option such
+as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
+different mechanisms such as ``CONFIG_MODULE_SIG`` and
+``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
+still use LoadPin to protect the integrity of other files kernel loads. The
+full list of valid file types can be found in ``kernel_read_file_str``
+defined in ``include/linux/fs.h``.
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 055fb0a64169..d5f064644c54 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -45,6 +45,8 @@ static void report_load(const char *origin, struct file *file, char *operation)
}
static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
+static char *exclude_read_files[READING_MAX_ID];
+static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
static struct super_block *pinned_root;
static DEFINE_SPINLOCK(pinned_root_spinlock);
@@ -129,6 +131,13 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
struct super_block *load_root;
const char *origin = kernel_read_file_id_str(id);
+ /* If the file id is excluded, ignore the pinning. */
+ if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
+ ignore_read_file_id[id]) {
+ report_load(origin, file, "pinning-excluded");
+ return 0;
+ }
+
/* This handles the older init_module API that has a NULL file. */
if (!file) {
if (!enforce) {
@@ -187,10 +196,37 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
};
+static void __init parse_exclude(void)
+{
+ int i, j;
+ char *cur;
+
+ for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
+ cur = exclude_read_files[i];
+ if (!cur)
+ break;
+ if (*cur == '\0')
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(kernel_read_file_str); j++) {
+ if (strcmp(cur, kernel_read_file_str[j]) == 0) {
+ pr_info("excluding: %s\n",
+ kernel_read_file_str[j]);
+ ignore_read_file_id[j] = 1;
+ /*
+ * Can not break, because one read_file_str
+ * may map to more than on read_file_id.
+ */
+ }
+ }
+ }
+}
+
static int __init loadpin_init(void)
{
pr_info("ready to pin (currently %senforcing)\n",
enforce ? "" : "not ");
+ parse_exclude();
security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
return 0;
}
@@ -203,3 +239,5 @@ DEFINE_LSM(loadpin) = {
/* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
module_param(enforce, int, 0);
MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
+module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
+MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* Re: [PATCH 18/22] docs: security: trusted-encrypted.rst: fix code-block tag
From: James Morris @ 2019-05-30 19:43 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mimi Zohar, James Bottomley, Jarkko Sakkinen,
linux-integrity, keyrings
In-Reply-To: <9c8e63bba3c3735573ab107ffd65131db10e1d2e.1559171394.git.mchehab+samsung@kernel.org>
On Wed, 29 May 2019, Mauro Carvalho Chehab wrote:
> The code-block tag is at the wrong place, causing those
> warnings:
>
> Documentation/security/keys/trusted-encrypted.rst:112: WARNING: Literal block expected; none found.
> Documentation/security/keys/trusted-encrypted.rst:121: WARNING: Unexpected indentation.
> Documentation/security/keys/trusted-encrypted.rst:122: WARNING: Block quote ends without a blank line; unexpected unindent.
> Documentation/security/keys/trusted-encrypted.rst:123: WARNING: Block quote ends without a blank line; unexpected unindent.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox