* [PATCH v10 8/8] tpm: TPM 2.0 FIFO Interface
From: Jarkko Sakkinen @ 2014-12-12 19:46 UTC (permalink / raw)
To: Peter Huewe, Ashley Lai, Marcel Selhorst
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Jarkko Sakkinen,
Will Arthur
In-Reply-To: <1418413600-5400-1-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Detect TPM 2.0 by sending idempotent TPM 2.x command. Ordinals for
TPM 2.0 are higher than TPM 1.x commands so this should be fail-safe.
Using STS3 is unreliable because some chips just report 0xff and not
what the spec says.
Before TPM family is detected, timeouts are set to the maximum values
for both TPM 1.x and TPM 2.x. In addition to this, suspend/resume
functionality is implemented for TPM 2.x.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Will Arthur <will.c.arthur-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Reviewed-by: Jasob Gunthorpe <jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Stephan Berger <stephan.berger-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
drivers/char/tpm/tpm_tis.c | 112 +++++++++++++++++++++++++++++++++++----------
1 file changed, 89 insertions(+), 23 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 89e1abb..c8884be 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2005, 2006 IBM Corporation
+ * Copyright (C) 2014 Intel Corporation
*
* Authors:
* Leendert van Doorn <leendert-aZOuKsOsJu3MbYB6QlFGEg@public.gmane.org>
@@ -64,12 +65,22 @@ enum tis_defaults {
TIS_LONG_TIMEOUT = 2000, /* 2 sec */
};
+
+/* Some timeout values are needed before it is known whether the chip is
+ * TPM 1.0 or TPM 2.0.
+ */
+#define TIS_TIMEOUT_A_MAX max(TIS_SHORT_TIMEOUT, TPM2_TIMEOUT_A)
+#define TIS_TIMEOUT_B_MAX max(TIS_LONG_TIMEOUT, TPM2_TIMEOUT_B)
+#define TIS_TIMEOUT_C_MAX max(TIS_SHORT_TIMEOUT, TPM2_TIMEOUT_C)
+#define TIS_TIMEOUT_D_MAX max(TIS_SHORT_TIMEOUT, TPM2_TIMEOUT_D)
+
#define TPM_ACCESS(l) (0x0000 | ((l) << 12))
#define TPM_INT_ENABLE(l) (0x0008 | ((l) << 12))
#define TPM_INT_VECTOR(l) (0x000C | ((l) << 12))
#define TPM_INT_STATUS(l) (0x0010 | ((l) << 12))
#define TPM_INTF_CAPS(l) (0x0014 | ((l) << 12))
#define TPM_STS(l) (0x0018 | ((l) << 12))
+#define TPM_STS3(l) (0x001b | ((l) << 12))
#define TPM_DATA_FIFO(l) (0x0024 | ((l) << 12))
#define TPM_DID_VID(l) (0x0F00 | ((l) << 12))
@@ -363,6 +374,7 @@ static int tpm_tis_send_main(struct tpm_chip *chip, u8 *buf, size_t len)
{
int rc;
u32 ordinal;
+ unsigned long dur;
rc = tpm_tis_send_data(chip, buf, len);
if (rc < 0)
@@ -374,9 +386,14 @@ static int tpm_tis_send_main(struct tpm_chip *chip, u8 *buf, size_t len)
if (chip->vendor.irq) {
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
+
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ dur = tpm2_calc_ordinal_duration(chip, ordinal);
+ else
+ dur = tpm_calc_ordinal_duration(chip, ordinal);
+
if (wait_for_tpm_stat
- (chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
- tpm_calc_ordinal_duration(chip, ordinal),
+ (chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID, dur,
&chip->vendor.read_queue, false) < 0) {
rc = -ETIME;
goto out_err;
@@ -598,17 +615,19 @@ static int tpm_tis_init(struct device *dev, acpi_handle acpi_dev_handle,
return PTR_ERR(chip);
chip->vendor.priv = priv;
+#ifdef CONFIG_ACPI
chip->acpi_dev_handle = acpi_dev_handle;
+#endif
chip->vendor.iobase = devm_ioremap(dev, start, len);
if (!chip->vendor.iobase)
return -EIO;
- /* Default timeouts */
- chip->vendor.timeout_a = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
- chip->vendor.timeout_b = msecs_to_jiffies(TIS_LONG_TIMEOUT);
- chip->vendor.timeout_c = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
- chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
+ /* Maximum timeouts */
+ chip->vendor.timeout_a = TIS_TIMEOUT_A_MAX;
+ chip->vendor.timeout_b = TIS_TIMEOUT_B_MAX;
+ chip->vendor.timeout_c = TIS_TIMEOUT_C_MAX;
+ chip->vendor.timeout_d = TIS_TIMEOUT_D_MAX;
if (wait_startup(chip, 0) != 0) {
rc = -ENODEV;
@@ -620,11 +639,18 @@ static int tpm_tis_init(struct device *dev, acpi_handle acpi_dev_handle,
goto out_err;
}
+ /* Every TPM 2.x command has a higher ordinal than TPM 1.x commands.
+ * Therefore, we can use an idempotent TPM 2.x command to probe TPM 2.x.
+ */
+ rc = tpm2_gen_interrupt(chip, true);
+ if (rc == 0 || rc == TPM2_RC_INITIALIZE)
+ chip->flags |= TPM_CHIP_FLAG_TPM2;
+
vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
chip->vendor.manufacturer_id = vendor;
- dev_info(dev,
- "1.2 TPM (device-id 0x%X, rev-id %d)\n",
+ dev_info(dev, "%s TPM (device-id 0x%X, rev-id %d)\n",
+ (chip->flags & TPM_CHIP_FLAG_TPM2) ? "2.0" : "1.2",
vendor >> 16, ioread8(chip->vendor.iobase + TPM_RID(0)));
if (!itpm) {
@@ -720,7 +746,10 @@ static int tpm_tis_init(struct device *dev, acpi_handle acpi_dev_handle,
chip->vendor.probed_irq = 0;
/* Generate Interrupts */
- tpm_gen_interrupt(chip);
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ tpm2_gen_interrupt(chip, false);
+ else
+ tpm_gen_interrupt(chip);
chip->vendor.irq = chip->vendor.probed_irq;
@@ -765,16 +794,44 @@ static int tpm_tis_init(struct device *dev, acpi_handle acpi_dev_handle,
}
}
- if (tpm_get_timeouts(chip)) {
- dev_err(dev, "Could not get TPM timeouts and durations\n");
- rc = -ENODEV;
- goto out_err;
- }
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ chip->vendor.timeout_a = msecs_to_jiffies(TPM2_TIMEOUT_A);
+ chip->vendor.timeout_b = msecs_to_jiffies(TPM2_TIMEOUT_B);
+ chip->vendor.timeout_c = msecs_to_jiffies(TPM2_TIMEOUT_C);
+ chip->vendor.timeout_d = msecs_to_jiffies(TPM2_TIMEOUT_D);
+ chip->vendor.duration[TPM_SHORT] =
+ msecs_to_jiffies(TPM2_DURATION_SHORT);
+ chip->vendor.duration[TPM_MEDIUM] =
+ msecs_to_jiffies(TPM2_DURATION_MEDIUM);
+ chip->vendor.duration[TPM_LONG] =
+ msecs_to_jiffies(TPM2_DURATION_LONG);
+
+ rc = tpm2_do_selftest(chip);
+ if (rc == TPM2_RC_INITIALIZE) {
+ dev_warn(dev, "Firmware has not started TPM\n");
+ rc = tpm2_startup(chip, TPM2_SU_CLEAR);
+ if (!rc)
+ rc = tpm2_do_selftest(chip);
+ }
- if (tpm_do_selftest(chip)) {
- dev_err(dev, "TPM self test failed\n");
- rc = -ENODEV;
- goto out_err;
+ if (rc) {
+ dev_err(dev, "TPM self test failed\n");
+ if (rc > 0)
+ rc = -ENODEV;
+ goto out_err;
+ }
+ } else {
+ if (tpm_get_timeouts(chip)) {
+ dev_err(dev, "Could not get TPM timeouts and durations\n");
+ rc = -ENODEV;
+ goto out_err;
+ }
+
+ if (tpm_do_selftest(chip)) {
+ dev_err(dev, "TPM self test failed\n");
+ rc = -ENODEV;
+ goto out_err;
+ }
}
return tpm_chip_register(chip);
@@ -808,14 +865,23 @@ static void tpm_tis_reenable_interrupts(struct tpm_chip *chip)
static int tpm_tis_resume(struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
- int ret;
+ int ret = 0;
if (chip->vendor.irq)
tpm_tis_reenable_interrupts(chip);
- ret = tpm_pm_resume(dev);
- if (!ret)
- tpm_do_selftest(chip);
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ /* NOP if firmware properly does this. */
+ tpm2_startup(chip, TPM2_SU_STATE);
+
+ ret = tpm2_shutdown(chip, TPM2_SU_STATE);
+ if (!ret)
+ ret = tpm2_do_selftest(chip);
+ } else {
+ ret = tpm_pm_resume(dev);
+ if (!ret)
+ tpm_do_selftest(chip);
+ }
return ret;
}
--
2.1.0
^ permalink raw reply related
* [PATCH 0/2] Documenting user namespace changes
From: Eric W. Biederman @ 2014-12-12 21:52 UTC (permalink / raw)
To: Michael Kerrisk-manpages
Cc: linux-man, Kees Cook, Linux API, Linux Containers, Josh Triplett,
stable, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kenton Varda, LSM, Richard Weinberger, Casey Schaufler,
Andrew Morton, Andy Lutomirski
In-Reply-To: <8761dh3b7k.fsf_-_-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
Michael the following two patches are my attempt to update the manpages
for my pending user namespace changes.
Eric W. Biederman (2):
proc.5: Document /proc/[pid]/setgroups
user_namespaces.7: Update the documention to reflect the fixes for negative groups
man5/proc.5 | 15 +++++++++++++++
man7/user_namespaces.7 | 52 +++++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 64 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 1/2] proc.5: Document /proc/[pid]/setgroups
From: Eric W. Biederman @ 2014-12-12 21:54 UTC (permalink / raw)
To: Michael Kerrisk-manpages
Cc: linux-man, Kees Cook, Linux API, Linux Containers, Josh Triplett,
stable, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kenton Varda, LSM, Richard Weinberger, Casey Schaufler,
Andrew Morton, Andy Lutomirski
In-Reply-To: <878uicy1r9.fsf_-_@x220.int.ebiederm.org>
Signed-off-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
---
man5/proc.5 | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/man5/proc.5 b/man5/proc.5
index 96077d0dd195..d661e8cfeac9 100644
--- a/man5/proc.5
+++ b/man5/proc.5
@@ -1097,6 +1097,21 @@ are not available if the main thread has already terminated
.\" Added in 2.6.9
.\" CONFIG_SCHEDSTATS
.TP
+.IR /proc/[pid]/setgroups " (since Linux 3.19-rc1)"
+This file reports
+.BR allow
+if the setgroups system call is allowed in the current user namespace.
+This file reports
+.BR deny
+if the setgroups system call is not allowed in the current user namespace.
+This file may be written to with values of
+.BR allow
+and
+.BR deny
+before
+.IR /proc/[pid]/gid_map
+is written to (enabling setgroups) in a user namespace.
+.TP
.IR /proc/[pid]/smaps " (since Linux 2.6.14)"
This file shows memory consumption for each of the process's mappings.
(The
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] user_namespaces.7: Update the documention to reflect the fixes for negative groups
From: Eric W. Biederman @ 2014-12-12 21:54 UTC (permalink / raw)
To: Michael Kerrisk-manpages
Cc: linux-man, Kees Cook, Linux API, Linux Containers, Josh Triplett,
stable, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kenton Varda, LSM, Richard Weinberger, Casey Schaufler,
Andrew Morton, Andy Lutomirski
In-Reply-To: <878uicy1r9.fsf_-_-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
Files with access permissions such as ---rwx---rwx give fewer
permissions to their group then they do to everyone else. Which means
dropping groups with setgroups(0, NULL) actually grants a process
privileges.
The uprivileged setting of gid_map turned out not to be safe after
this change. Privilege setting of gid_map can be interpreted as
meaning yes it is ok to drop groups.
To prevent this problem and future problems user namespaces were
changed in such a way as to guarantee a user can not obtain
credentials without privilege they could not obtain without the
help of user namespaces.
This meant testing the effective user ID and not the filesystem user
ID as setresuid and setregid allow setting any process uid or gid
(except the supplemental groups) to the effective ID.
Furthermore to preserve in some form the useful applications that have
been setting gid_map without privilege the file /proc/[pid]/setgroups
was added to allow disabling setgroups. With the setgroups system
call permanently disabled in a user namespace it again becomes safe to
allow writes to gid_map without privilege.
Here is my meager attempt to update user_namespaces.7 to reflect these
issues.
Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
---
man7/user_namespaces.7 | 52 +++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 49 insertions(+), 3 deletions(-)
diff --git a/man7/user_namespaces.7 b/man7/user_namespaces.7
index d76721d9a0a1..f8333a762308 100644
--- a/man7/user_namespaces.7
+++ b/man7/user_namespaces.7
@@ -533,11 +533,16 @@ One of the following is true:
The data written to
.I uid_map
.RI ( gid_map )
-consists of a single line that maps the writing process's filesystem user ID
+consists of a single line that maps the writing process's effective user ID
(group ID) in the parent user namespace to a user ID (group ID)
in the user namespace.
-The usual case here is that this single line provides a mapping for user ID
-of the process that created the namespace.
+The writing process must have the same effective user ID as the process
+that created the user namespace.
+In the case of
+.I gid_map
+the
+.I setgroups
+file must have been written to earlier and disabled the setgroups system call.
.IP * 3
The opening process has the
.BR CAP_SETUID
@@ -552,6 +557,47 @@ Writes that violate the above rules fail with the error
.\"
.\" ============================================================
.\"
+.SS Interaction with system calls that change the uid or gid values
+When in a user namespace where the
+.I uid_map
+or
+.I gid_map
+file has not been written the system calls that change user IDs
+or group IDs respectively will fail. After the
+.I uid_map
+and
+.I gid_map
+file have been written only the mapped values may be used in
+system calls that change user IDs and group IDs.
+
+For user IDs these system calls include
+.BR setuid ,
+.BR setfsuid ,
+.BR setreuid ,
+and
+.BR setresuid .
+
+For group IDs these system calls include
+.BR setgid ,
+.BR setfsgid ,
+.BR setregid ,
+.BR setresgid ,
+and
+.BR setgroups.
+
+Writing
+.BR deny
+to the
+.I /proc/[pid]/setgroups
+file before writing to
+.I /proc/[pid]/gid_map
+will permanently disable the setgroups system call in a user namespace
+and allow writing to
+.I /proc/[pid]/gid_map
+without
+.BR CAP_SETGID
+in the parent user namespace.
+
.SS Unmapped user and group IDs
.PP
There are various places where an unmapped user ID (group ID)
--
1.9.1
^ permalink raw reply related
* Re: [GIT PULL] kselftest-3.19-rc1
From: Linus Torvalds @ 2014-12-13 21:32 UTC (permalink / raw)
To: Shuah Khan
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Shuah Khan
In-Reply-To: <548750AD.6090201-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, Dec 9, 2014 at 11:42 AM, Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>
> Please pull the following kselftest updates for 3.19-rc1. Details
> in the singed tag:
Gaah. Why do you do this to me?
> git-OoYKEaZ2EDaWaY/ihj7yzEB+6BGkLq7r@public.gmane.org:/pub/scm/linux/kernel/git/shuah/linux-kselftest
> fixes
That's the wrong format, but it's also the wrong branch name.
What it *should* have said is
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/kselftest-3.19-rc1
which is actually publicly accessible, and has the right tag name.
EXCEPT THAT'S WRONG TOO! The actual kselftest-3.19-rc1 tag doesn't
point to the commits in fixes at all! It points to commit
0df1f2487d2f, which is my 3.18-rc3 commit.
Please fix your script/workflow. I'm not pulling this mess.
Linus
^ permalink raw reply
* Re: [CFT] Can I get some Tested-By's on this series?
From: serge @ 2014-12-13 22:31 UTC (permalink / raw)
To: Eric W. Biederman, Serge Hallyn
Cc: Andy Lutomirski, Richard Weinberger, linux-man, Kees Cook,
Linux API, Linux Containers, Josh Triplett, stable,
linux-kernel@vger.kernel.org, Kenton Varda, LSM,
Michael Kerrisk-manpages, Casey Schaufler, Andrew Morton
In-Reply-To: <20141210224822.GG20012@ubuntumail>
sorry, I've only been back from the road the days... Two tries at compiling have failed (infrastructure problems, not your set), hoping to fire of another build tonight.On 12/10/14 16:48 Serge Hallyn wrote:
Quoting Eric W. Biederman (ebiederm@xmission.com):
>
> Will people please test these patches with their container project?
>
> These changes break container userspace (hopefully in a minimal way) if
> I could have that confirmed by testing I would really appreciate it. I
> really don't want to send out a bug fix that accidentally breaks
> userspace again.
>
> The only issue sort of under discussion is if there is a better name for
> /proc/<pid>/setgroups, and the name of the file will not affect the
> functionality of the patchset.
>
> With the code reviewed and written in simple obviously correct, easily
> reviewable ways I am hoping/planning to send this to Linus ASAP.
>
> Eric
Is there a git tree we can clone?
^ permalink raw reply
* Re: [PATCH v10 1/8] tpm: merge duplicate transmit_cmd() functions
From: Stefan Berger @ 2014-12-14 14:03 UTC (permalink / raw)
To: Jarkko Sakkinen, Peter Huewe, Ashley Lai, Marcel Selhorst
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1418413600-5400-2-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 12/12/2014 02:46 PM, Jarkko Sakkinen wrote:
> Merged transmit_cmd() functions in tpm-interface.c and tpm-sysfs.c.
> Added "tpm_" prefix for consistency sake. Changed cmd parameter as
> opaque. This enables to use separate command structures for TPM1
> and TPM2 commands in future. Loose coupling works fine here.
>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Reviewed-by: Jasob Gunthorpe <jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> Reviewed-by: Stephan Berger <stephan.berger-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Not quite ... Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Stefan
^ permalink raw reply
* Re: [PATCH v10 8/8] tpm: TPM 2.0 FIFO Interface
From: Stefan Berger @ 2014-12-14 14:48 UTC (permalink / raw)
To: Jarkko Sakkinen, Peter Huewe, Ashley Lai, Marcel Selhorst
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Will Arthur
In-Reply-To: <1418413600-5400-9-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 12/12/2014 02:46 PM, Jarkko Sakkinen wrote:
> Detect TPM 2.0 by sending idempotent TPM 2.x command. Ordinals for
> TPM 2.0 are higher than TPM 1.x commands so this should be fail-safe.
> Using STS3 is unreliable because some chips just report 0xff and not
> what the spec says.
TPM TIS 1.2 can report either 0xff or 0x00 for sts3 since that part of
register was not defined for this version but only for a later version.
So, unless the TIS 1.3 for TPM 2.0 is broken, it should report a bit
_pattern_ (not plain 0x00 or 0xff) that you could apply the suggested
mask to and check then.
Stefan
^ permalink raw reply
* Re: [PATCH v10 1/8] tpm: merge duplicate transmit_cmd() functions
From: Jarkko Sakkinen @ 2014-12-14 14:57 UTC (permalink / raw)
To: Stefan Berger
Cc: Peter Huewe, Ashley Lai, Marcel Selhorst,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <548D98B8.3010003-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Sun, 2014-12-14 at 09:03 -0500, Stefan Berger wrote:
> On 12/12/2014 02:46 PM, Jarkko Sakkinen wrote:
> > Merged transmit_cmd() functions in tpm-interface.c and tpm-sysfs.c.
> > Added "tpm_" prefix for consistency sake. Changed cmd parameter as
> > opaque. This enables to use separate command structures for TPM1
> > and TPM2 commands in future. Loose coupling works fine here.
> >
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > Reviewed-by: Jasob Gunthorpe <jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> > Reviewed-by: Stephan Berger <stephan.berger-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> Not quite ... Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Oops. Peter, I guess you could fix those or? My apologies.
> Stefan
/Jarkko
^ permalink raw reply
* Re: [PATCH v10 1/8] tpm: merge duplicate transmit_cmd() functions
From: peterhuewe-Mmb7MZpHnFY @ 2014-12-14 15:31 UTC (permalink / raw)
To: Jarkko Sakkinen, Stefan Berger
Cc: Ashley Lai, Marcel Selhorst,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1418569030.9230.7.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 14. Dezember 2014 15:57:10 MEZ, Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>On Sun, 2014-12-14 at 09:03 -0500, Stefan Berger wrote:
>> On 12/12/2014 02:46 PM, Jarkko Sakkinen wrote:
>> > Merged transmit_cmd() functions in tpm-interface.c and tpm-sysfs.c.
>> > Added "tpm_" prefix for consistency sake. Changed cmd parameter as
>> > opaque. This enables to use separate command structures for TPM1
>> > and TPM2 commands in future. Loose coupling works fine here.
>> >
>> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> > Reviewed-by: Jasob Gunthorpe <jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
>> > Reviewed-by: Stephan Berger <stephan.berger-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>
>> Not quite ... Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
>Oops. Peter, I guess you could fix those or? My apologies.
>
>> Stefan
>
>/Jarkko
I'll fix this,
No problem.
Peter
--
Sent from my mobile.
^ permalink raw reply
* Re: [PATCH v10 8/8] tpm: TPM 2.0 FIFO Interface
From: Jarkko Sakkinen @ 2014-12-14 15:40 UTC (permalink / raw)
To: Stefan Berger
Cc: Peter Huewe, Ashley Lai, Marcel Selhorst,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Will Arthur
In-Reply-To: <548DA33A.4010300-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Sun, Dec 14, 2014 at 09:48:26AM -0500, Stefan Berger wrote:
> On 12/12/2014 02:46 PM, Jarkko Sakkinen wrote:
> >Detect TPM 2.0 by sending idempotent TPM 2.x command. Ordinals for
> >TPM 2.0 are higher than TPM 1.x commands so this should be fail-safe.
> >Using STS3 is unreliable because some chips just report 0xff and not
> >what the spec says.
>
> TPM TIS 1.2 can report either 0xff or 0x00 for sts3 since that part of
> register was not defined for this version but only for a later version. So,
> unless the TIS 1.3 for TPM 2.0 is broken, it should report a bit _pattern_
> (not plain 0x00 or 0xff) that you could apply the suggested mask to and
> check then.
I propose this: lets keep the bit ugly but approach for now and when
there are TPM2 FIFOs available in the market move to your workaround.
I think that would be the most reasonable middle road here.
> Stefan
/Jarkko
^ permalink raw reply
* Re: [PATCH v10 1/8] tpm: merge duplicate transmit_cmd() functions
From: Jarkko Sakkinen @ 2014-12-14 15:42 UTC (permalink / raw)
To: peterhuewe-Mmb7MZpHnFY
Cc: Stefan Berger, Ashley Lai, Marcel Selhorst,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <889c95a4-ae60-44db-be8a-fd56a9497c78-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
On Sun, Dec 14, 2014 at 04:31:10PM +0100, peterhuewe-Mmb7MZpHnFY@public.gmane.org wrote:
>
>
> On 14. Dezember 2014 15:57:10 MEZ, Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> >On Sun, 2014-12-14 at 09:03 -0500, Stefan Berger wrote:
> >> On 12/12/2014 02:46 PM, Jarkko Sakkinen wrote:
> >> > Merged transmit_cmd() functions in tpm-interface.c and tpm-sysfs.c.
> >> > Added "tpm_" prefix for consistency sake. Changed cmd parameter as
> >> > opaque. This enables to use separate command structures for TPM1
> >> > and TPM2 commands in future. Loose coupling works fine here.
> >> >
> >> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >> > Reviewed-by: Jasob Gunthorpe <jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> >> > Reviewed-by: Stephan Berger <stephan.berger-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> >>
> >> Not quite ... Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> >
> >Oops. Peter, I guess you could fix those or? My apologies.
> >
> >> Stefan
> >
> >/Jarkko
> I'll fix this,
> No problem.
Thank you.
> Peter
/Jarkko
^ permalink raw reply
* Re: [PATCH v10 8/8] tpm: TPM 2.0 FIFO Interface
From: Stefan Berger @ 2014-12-14 16:09 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Peter Huewe, Ashley Lai, Marcel Selhorst,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Will Arthur
In-Reply-To: <20141214154003.GA13338-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On 12/14/2014 10:40 AM, Jarkko Sakkinen wrote:
> On Sun, Dec 14, 2014 at 09:48:26AM -0500, Stefan Berger wrote:
>> On 12/12/2014 02:46 PM, Jarkko Sakkinen wrote:
>>> Detect TPM 2.0 by sending idempotent TPM 2.x command. Ordinals for
>>> TPM 2.0 are higher than TPM 1.x commands so this should be fail-safe.
>>> Using STS3 is unreliable because some chips just report 0xff and not
>>> what the spec says.
>> TPM TIS 1.2 can report either 0xff or 0x00 for sts3 since that part of
>> register was not defined for this version but only for a later version. So,
>> unless the TIS 1.3 for TPM 2.0 is broken, it should report a bit _pattern_
>> (not plain 0x00 or 0xff) that you could apply the suggested mask to and
>> check then.
> I propose this: lets keep the bit ugly but approach for now and when
> there are TPM2 FIFOs available in the market move to your workaround.
> I think that would be the most reasonable middle road here.
You are now calling tpm2_gen_interrupt and are looking at the rc, which
is the rc from tpm_transmit_cmd, which seems to make sure that the
sending of the command went alright and the reception of the response.
Is this good enough to distinguish between a TPM 2 and a TPM 1.2? If you
send a valid TPM 2 command to a TPM 1.2 this will at least transmit the
data ok, but the TPM will respond with a TPM 1.2 tag in the response.
The way I understand the code, the rc does not include whether the
response packet is a valid TPM 2 response packet and lets you conclude
to a TPM2. I do something similar in upcoming QEMU patches where I send
a valid TPM2 command for probing and if the tag(!) in the response is a
TPM2 tag (0x8001 = TPM_ST_NO_SESSIONS), then it's a TPM 2, otherwise a
TPM 1.2.
Did you test this with a TPM 1.2 ?
Stefan
>
>> Stefan
> /Jarkko
>
^ permalink raw reply
* Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
From: Richard Weinberger @ 2014-12-14 23:05 UTC (permalink / raw)
To: Aditya Kali, tj-DgEjT+Ai2ygdnm+yROfE0A,
lizefan-hv44wF8Li93QT0dZR+AlfA,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA, luto-kltTT9wpgjJwATOyAt5JVQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, mingo-H+wXaHxf7aLQT0dZR+AlfA
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <1417744550-6461-9-git-send-email-adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Aditya,
I gave your patch set a try but it does not work for me.
Maybe you can bring some light into the issues I'm facing.
Sadly I still had no time to dig into your code.
Am 05.12.2014 um 02:55 schrieb Aditya Kali:
> Signed-off-by: Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/cgroups/namespace.txt | 147 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 147 insertions(+)
> create mode 100644 Documentation/cgroups/namespace.txt
>
> diff --git a/Documentation/cgroups/namespace.txt b/Documentation/cgroups/namespace.txt
> new file mode 100644
> index 0000000..6480379
> --- /dev/null
> +++ b/Documentation/cgroups/namespace.txt
> @@ -0,0 +1,147 @@
> + CGroup Namespaces
> +
> +CGroup Namespace provides a mechanism to virtualize the view of the
> +/proc/<pid>/cgroup file. The CLONE_NEWCGROUP clone-flag can be used with
> +clone() and unshare() syscalls to create a new cgroup namespace.
> +The process running inside the cgroup namespace will have its /proc/<pid>/cgroup
> +output restricted to cgroupns-root. cgroupns-root is the cgroup of the process
> +at the time of creation of the cgroup namespace.
> +
> +Prior to CGroup Namespace, the /proc/<pid>/cgroup file used to show complete
> +path of the cgroup of a process. In a container setup (where a set of cgroups
> +and namespaces are intended to isolate processes), the /proc/<pid>/cgroup file
> +may leak potential system level information to the isolated processes.
> +
> +For Example:
> + $ cat /proc/self/cgroup
> + 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/container_id1
> +
> +The path '/batchjobs/container_id1' can generally be considered as system-data
> +and its desirable to not expose it to the isolated process.
> +
> +CGroup Namespaces can be used to restrict visibility of this path.
> +For Example:
> + # Before creating cgroup namespace
> + $ ls -l /proc/self/ns/cgroup
> + lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup -> cgroup:[4026531835]
> + $ cat /proc/self/cgroup
> + 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/container_id1
> +
> + # unshare(CLONE_NEWCGROUP) and exec /bin/bash
> + $ ~/unshare -c
> + [ns]$ ls -l /proc/self/ns/cgroup
> + lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup -> cgroup:[4026532183]
> + # From within new cgroupns, process sees that its in the root cgroup
> + [ns]$ cat /proc/self/cgroup
> + 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/
> +
> + # From global cgroupns:
> + $ cat /proc/<pid>/cgroup
> + 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/container_id1
> +
> + # Unshare cgroupns along with userns and mountns
> + # Following calls unshare(CLONE_NEWCGROUP|CLONE_NEWUSER|CLONE_NEWNS), then
> + # sets up uid/gid map and execs /bin/bash
> + $ ~/unshare -c -u -m
This command does not issue CLONE_NEWUSER, -U does.
> + # Originally, we were in /batchjobs/container_id1 cgroup. Mount our own cgroup
> + # hierarchy.
> + [ns]$ mount -t cgroup cgroup /tmp/cgroup
> + [ns]$ ls -l /tmp/cgroup
> + total 0
> + -r--r--r-- 1 root root 0 2014-10-13 09:32 cgroup.controllers
> + -r--r--r-- 1 root root 0 2014-10-13 09:32 cgroup.populated
> + -rw-r--r-- 1 root root 0 2014-10-13 09:25 cgroup.procs
> + -rw-r--r-- 1 root root 0 2014-10-13 09:32 cgroup.subtree_control
I've patched libvirt-lxc to issue CLONE_NEWCGROUP and not bind mount cgroupfs into a container.
But I'm unable to mount cgroupfs within the container, mount(2) is failing with EINVAL.
And /proc/self/cgroup still shows the cgroup from outside.
---cut---
container:/ # ls /sys/fs/cgroup/
container:/ # mount -t cgroup none /sys/fs/cgroup/
mount: wrong fs type, bad option, bad superblock on none,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
container:/ # cat /proc/self/cgroup
8:memory:/machine/test00.libvirt-lxc
7:devices:/machine/test00.libvirt-lxc
6:hugetlb:/
5:cpuset:/machine/test00.libvirt-lxc
4:blkio:/machine/test00.libvirt-lxc
3:cpu,cpuacct:/machine/test00.libvirt-lxc
2:freezer:/machine/test00.libvirt-lxc
1:name=systemd:/user.slice/user-0.slice/session-c2.scope
container:/ # ls -la /proc/self/ns
total 0
dr-x--x--x 2 root root 0 Dec 14 23:02 .
dr-xr-xr-x 8 root root 0 Dec 14 23:02 ..
lrwxrwxrwx 1 root root 0 Dec 14 23:02 cgroup -> cgroup:[4026532240]
lrwxrwxrwx 1 root root 0 Dec 14 23:02 ipc -> ipc:[4026532238]
lrwxrwxrwx 1 root root 0 Dec 14 23:02 mnt -> mnt:[4026532235]
lrwxrwxrwx 1 root root 0 Dec 14 23:02 net -> net:[4026532242]
lrwxrwxrwx 1 root root 0 Dec 14 23:02 pid -> pid:[4026532239]
lrwxrwxrwx 1 root root 0 Dec 14 23:02 user -> user:[4026532234]
lrwxrwxrwx 1 root root 0 Dec 14 23:02 uts -> uts:[4026532236]
container:/ #
#host side
lxc-os132:~ # ls -la /proc/self/ns
total 0
dr-x--x--x 2 root root 0 Dec 14 23:56 .
dr-xr-xr-x 8 root root 0 Dec 14 23:56 ..
lrwxrwxrwx 1 root root 0 Dec 14 23:56 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Dec 14 23:56 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 root root 0 Dec 14 23:56 mnt -> mnt:[4026531840]
lrwxrwxrwx 1 root root 0 Dec 14 23:56 net -> net:[4026531957]
lrwxrwxrwx 1 root root 0 Dec 14 23:56 pid -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 Dec 14 23:56 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Dec 14 23:56 uts -> uts:[4026531838]
---cut---
Any ideas?
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH v4 0/5] Add Spreadtrum Sharkl64 Platform support
From: Mark Rutland @ 2014-12-15 13:38 UTC (permalink / raw)
To: Lyra Zhang
Cc: Chunyan Zhang, gregkh@linuxfoundation.org, arnd@arndb.de,
gnomes@lxorguk.ukuu.org.uk, broonie@kernel.org,
robh+dt@kernel.org, Pawel Moll, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, Will Deacon, Catalin Marinas,
jslaby@suse.cz, jason@lakedaemon.net, heiko@sntech.de,
florian.vaussard@epfl.ch, andrew@lunn.ch, rrichter@cavium.com,
hytszk@gmail.com, grant.likely@linaro.org
In-Reply-To: <CAAfSe-uz534FiZufojKa8MdBi=VFqhuoFLwof7K+FqXG--AGaw@mail.gmail.com>
On Fri, Dec 05, 2014 at 12:27:23PM +0000, Lyra Zhang wrote:
> On Fri, Dec 5, 2014 at 6:40 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > Hi,
> >
> > On Thu, Dec 04, 2014 at 11:34:15AM +0000, Chunyan Zhang wrote:
> >> Spreadtrum is a rapid growing chip vendor providing smart phone total solutions.
> >>
> >> Sharkl64 Platform is nominated as a SoC infrastructure that supports 4G/3G/2G
> >> standards based on ARMv8 multiple core architecture.Now we have only one
> >> SoC(SC9836) based on this Platform in developing.
> >>
> >> This patchset adds Sharkl64 support in arm64 device tree and the serial driver
> >> of SC9836-UART.
> >>
> >> This patchset also has patches which address "sprd" prefix and DT compatible
> >> strings for nodes which appear un-documented.
> >>
> >> This version code was tesed both on Fast Mode and sc9836-fpga board.
> >> We use the latest boot-wrapper-aarch64 as the bootloader.
> >>
> >> Changes from v3:
> >> * Addressed review comments:
> >> - Added the description of clock property for sc9836-uart
> >> - Revised the size of GICC to be 8KiB
> >> - Added another compatible string for psci-0.1
> >
> > I had open questions on v3 regarding your PSCI imlpementation. You
> > mentioned that you are using the aarch64 bootwrapper, but your DT
> > describes PSCI 0.2, and the (upstream) bootwrapper does not implement
> > PSCI 0.2. Adding the old PSCI compatible string is _not_ sufficient if
> > you do not have a full PSCI 0.2 implementation.
> >
> > Given that PSCI 0.2 requires more functionality to be implemented, I'd
> > like to know that your implementation is spec-compliant (implementing
> > the mandatory functions, nters the kernel in the correct state, etc),
> > and that it has been tested.
> >
> > Would you be able to look at my comments from the last posting please?
> >
> > Thanks,
> > Mark.
> > --
>
> Hi, Mark
>
> Ok, I'll check it again with our related engineers.
>
> Actually, I had read all of your comments carefully before sending
> each version of patches, and I replied you a few days early, I guess
> you may miss it :)
>
> If we just implemented psci-0.1 until now, can we submit this path
> without "compatible = "arm,psci-0.2"", but only with " compatible =
> "arm,psci" ".
Elsewhere I've recommended such things are placed in the DTB by the
bootloader (at least for those cases where the bootlaoder is tied to the
firmware), as it can fill in the appropriate enable-method (and add any
other nodes as required).
Having compatible = "arm,psci", and a couple of other properties for now
is certainly preferable to describing a not-yet-implemented PSCI 0.2.
Thanks,
Mark.
^ permalink raw reply
* Re: [GIT PULL] kselftest-3.19-rc1
From: Shuah Khan @ 2014-12-15 14:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Shuah Khan
In-Reply-To: <CA+55aFx2DSXuikfd-RyEN3V+OaLSYhWub92=NJsNXGUhVnKKFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/13/2014 02:32 PM, Linus Torvalds wrote:
> On Tue, Dec 9, 2014 at 11:42 AM, Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>
>> Please pull the following kselftest updates for 3.19-rc1. Details
>> in the singed tag:
>
> Gaah. Why do you do this to me?
>
>> git-OoYKEaZ2EDaWaY/ihj7yzEB+6BGkLq7r@public.gmane.org:/pub/scm/linux/kernel/git/shuah/linux-kselftest
>> fixes
>
> That's the wrong format, but it's also the wrong branch name.
>
> What it *should* have said is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
> tags/kselftest-3.19-rc1
>
> which is actually publicly accessible, and has the right tag name.
>
> EXCEPT THAT'S WRONG TOO! The actual kselftest-3.19-rc1 tag doesn't
> point to the commits in fixes at all! It points to commit
> 0df1f2487d2f, which is my 3.18-rc3 commit.
>
> Please fix your script/workflow. I'm not pulling this mess.
>
Sorry. I thought I have the workflow right. Doesn't look like I do.
I will fix it and send you another.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Open Source Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* selftests: standardized results output?
From: Young, David @ 2014-12-15 16:42 UTC (permalink / raw)
To: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Shuah Khan (shuahkhan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org),
grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hi, I'm looking into what sorts of tools can consume the selftest output, and
found this on the wikipage:
https://kselftest.wiki.kernel.org/standardize_the_test_output
The current suggestion (as of the last-modified date on that wiki page for
October) is to use the Test Anything Protocol [TAP] for standard output. I
notice that there is at least one test that conforms to TAP output, but
the majority of the tests are not using it.
There's also the kselftest.h file that suggests exit codes for the individual
test applications.
I'm interested in knowing what is the intention of this standardization, so
that I can put some work into a "glue" layer for a tool like buildbot,
autotest, or Jenkins for executing and consuming the results of these
selftests.
1) Is this output standard a "nice to have" that won't be much enforced?
2) Will the exit codes be utilized outside of the current makefile-based
approach for executing the tests? The current make target just runs all the
tests without really concerning itself with the exit values of the
individual tests. It's simple, which isn't a bad thing, but it lacks a
summarized result. Is the intention to use a different harness to consume
and report results?
3) Are the TAP results intended to be the exclusive (std)output of the tests,
or will the tests report in a hybrid fashion?
Such an example would be a test that produces some verbose stdout to the
console, while simultaneously creating a TAP-compliant results.tap file as
well... or vice versa with the stdout being TAP and a more verbose but
free-form log.txt
Thanks,
- David Young
^ permalink raw reply
* Re: [CFT] Can I get some Tested-By's on this series?
From: Serge Hallyn @ 2014-12-15 19:38 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-man, Kees Cook, Richard Weinberger, Linux Containers,
Serge Hallyn, Josh Triplett, stable, Andy Lutomirski,
Kenton Varda, LSM, Michael Kerrisk-manpages, Linux API,
Casey Schaufler, Andrew Morton,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8761dgze56.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> Stéphane Graber <stgraber-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
>
> > On Fri, Dec 12, 2014 at 03:38:18PM -0600, Eric W. Biederman wrote:
> >> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
> >>
> >> > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> >> >>
> >> >> Will people please test these patches with their container project?
> >> >>
> >> >> These changes break container userspace (hopefully in a minimal way) if
> >> >> I could have that confirmed by testing I would really appreciate it. I
> >> >> really don't want to send out a bug fix that accidentally breaks
> >> >> userspace again.
> >> >>
> >> >> The only issue sort of under discussion is if there is a better name for
> >> >> /proc/<pid>/setgroups, and the name of the file will not affect the
> >> >> functionality of the patchset.
> >> >>
> >> >> With the code reviewed and written in simple obviously correct, easily
> >> >> reviewable ways I am hoping/planning to send this to Linus ASAP.
> >> >>
> >> >> Eric
> >> >
> >> > Is there a git tree we can clone?
> >>
> >> Have either of you been able to check to see if any of my changes
> >> affects lxc?
> >>
> >> I am trying to gauge how hard and how fast I should push to Linus. lxc
> >> being the largest adopter of unprivileged user namespaces for general
> >> purpose containers.
> >>
> >> I expect you just call newuidmap and newgidmap and don't actually care
> >> about not being able to set gid_map without privilege. But I really
> >> want to avoid pushing a security fix and then being surprised that
> >> things like lxc break.
> >>
> >> Eric
> >
> > Hi Eric,
> >
> > I've unfortunately been pretty busy this week as I was (well, still am)
> > travelling to South Africa for a meeting. I don't have a full kernel
> > tree around here and a full git clone isn't really doable over the kind
> > of Internet I've got here :)
> >
> > Hopefully Serge can give it a quick try, otherwise I should be able to
> > do some tests on Tuesday when I'm back home.
>
> I thought Serge was going to but I haven't heard yet so I am prodding ;-)
Ok, thanks - yes, unprivileged lxc is working fine with your kernels.
Just to be sure I was testing the right thing I also tested using
my unprivileged nsexec testcases, and they failed on setgroup/setgid
as now expected, and succeeded there without your patches.
thanks,
-serge
^ permalink raw reply
* Re: [CFT] Can I get some Tested-By's on this series?
From: Eric W. Biederman @ 2014-12-15 20:11 UTC (permalink / raw)
To: Serge Hallyn
Cc: linux-man, Kees Cook, Richard Weinberger, Linux Containers,
Josh Triplett, stable, Andy Lutomirski, Kenton Varda, LSM,
Michael Kerrisk-manpages, Linux API, Casey Schaufler,
Andrew Morton,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20141215193838.GB28375@ubuntumail>
Serge Hallyn <serge.hallyn@ubuntu.com> writes:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> Stéphane Graber <stgraber@ubuntu.com> writes:
>>
>> > On Fri, Dec 12, 2014 at 03:38:18PM -0600, Eric W. Biederman wrote:
>> >> Serge Hallyn <serge.hallyn@ubuntu.com> writes:
>> >>
>> >> > Quoting Eric W. Biederman (ebiederm@xmission.com):
>> >> >>
>> >> >> Will people please test these patches with their container project?
>> >> >>
>> >> >> These changes break container userspace (hopefully in a minimal way) if
>> >> >> I could have that confirmed by testing I would really appreciate it. I
>> >> >> really don't want to send out a bug fix that accidentally breaks
>> >> >> userspace again.
>> >> >>
>> >> >> The only issue sort of under discussion is if there is a better name for
>> >> >> /proc/<pid>/setgroups, and the name of the file will not affect the
>> >> >> functionality of the patchset.
>> >> >>
>> >> >> With the code reviewed and written in simple obviously correct, easily
>> >> >> reviewable ways I am hoping/planning to send this to Linus ASAP.
>> >> >>
>> >> >> Eric
>> >> >
>> >> > Is there a git tree we can clone?
>> >>
>> >> Have either of you been able to check to see if any of my changes
>> >> affects lxc?
>> >>
>> >> I am trying to gauge how hard and how fast I should push to Linus. lxc
>> >> being the largest adopter of unprivileged user namespaces for general
>> >> purpose containers.
>> >>
>> >> I expect you just call newuidmap and newgidmap and don't actually care
>> >> about not being able to set gid_map without privilege. But I really
>> >> want to avoid pushing a security fix and then being surprised that
>> >> things like lxc break.
>> >>
>> >> Eric
>> >
>> > Hi Eric,
>> >
>> > I've unfortunately been pretty busy this week as I was (well, still am)
>> > travelling to South Africa for a meeting. I don't have a full kernel
>> > tree around here and a full git clone isn't really doable over the kind
>> > of Internet I've got here :)
>> >
>> > Hopefully Serge can give it a quick try, otherwise I should be able to
>> > do some tests on Tuesday when I'm back home.
>>
>> I thought Serge was going to but I haven't heard yet so I am prodding ;-)
>
> Ok, thanks - yes, unprivileged lxc is working fine with your kernels.
> Just to be sure I was testing the right thing I also tested using
> my unprivileged nsexec testcases, and they failed on setgroup/setgid
> as now expected, and succeeded there without your patches.
Thanks.
Serge unless you object will add your Tested-By to my pull message to Linus.
Minor question do you runprivileged nsexec test cases test to see if the
write to gid_map succeeds? I would have expected the gid_map write to
fail before the setgroups setgid system calls came into play.
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH v10 0/8] TPM 2.0 support
From: Jarkko Sakkinen @ 2014-12-15 20:17 UTC (permalink / raw)
To: Peter Huewe, Ashley Lai, Marcel Selhorst
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
linux-api-u79uwXL29TY76Z2rM5mHXA,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1418413600-5400-1-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
So, what do you think? Are we now settled with this?
/Jarkko
On Fri, Dec 12, 2014 at 11:46:32AM -0800, Jarkko Sakkinen wrote:
> This patch set enables TPM2 protocol and provides drivers for FIFO and
> CRB interfaces. This patch set does not export any sysfs attributes for
> TPM 2.0 because existing sysfs attributes have three non-trivial issues:
>
> - They are associated with the platform device instead of character
> device.
> - They are are not trivial key-value pairs but contain text that is
> not easily parsed by a computer.
> - Raciness as described in
> http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
>
> v2:
> - Improved struct tpm_chip life-cycle by taking advantage of devres
> API.
> - Refined sysfs attributes as simple key-values thereby not repeating
> mistakes in TPM1 sysfs attributes.
> - Documented functions in tpm-chip.c and tpm2-cmd.c.
> - Documented sysfs attributes.
>
> v3:
> - Lots of fixes in calling order in device drivers (thanks to Jason
> Gunthorpe for pointing these out!).
> - Attach sysfs attributes to the misc device because it represents
> TPM device to the user space.
>
> v4:
> - Disable sysfs attibutes for TPM 2.0 for until we can sort out the
> best approach for them.
> - Fixed all the style issues found with checkpatch.pl.
>
> v5:
> - missing EXPORT_SYMBOL_GPL()
> - own class for TPM devices used for TPM 2.0 devices and onwards.
>
> v6:
> - Non-racy initialization for sysfs attributes using struct device's
> groups field.
> - The class 'tpm' is used now for all TPM devices. For the first device
> node major MISC_MAJOR and minor TPM_MINOR is used in order to retain
> backwards compatability.
>
> v7:
> - Release device number and free struct tpm_chip memory inside
> tpm_dev_release callback.
> - Moved code from tpm-interface.c and tpm_dev.c to tpm-chip.c.
>
> v8:
> - Cleaned up unneeded cast from tpm_transmit_cmd().
> - Cleaned up redundant PPI_VERSION_LEN constant from tpm_ppi.c.
> - Fixed tpm_tis to use tpm2_calc_ordinal_duration() for TPM2 devices.
> - tpm_crb: in crb_recv, check that count can hold the TPM header at
> minimum.
> - tpm_crb: add enumerations for bit flags in start and cancel fields
> of the control area.
> - tpm_crb: use ioremap() for command and response buffer because
> they might be anywhere.
> - tpm_crb: use IO access functions for reading ioremapped buffers
> because using direct pointers is not portable.
> - tpm_crb: only apply ACPI start if start method reported by the
> TPM2 ACPI table allows it.
> - In tpm2_pcr_read() just calculate index and bit and get rid of
> hacky loop.
> - Do not add sysfs attributes for TPM 2.0 devices.
>
> v9:
> - Fixed compilation issues in v8 (sorry for not using the correct
> tree).
> - Just do "return tpm_chip_register();" instead of copying return
> value to a variable.
> - Removed unused tpm2_startup().
> - In the CRB driver ACPI TPM2 table could contain platform specific
> and therefore inequality test does not work. Fixed in this patch
> set.
>
> v10:
> - Fixed coccicheck and sparse errors and other reported style errors.
> - Fixed build errors without CONFIG_ACPI.
> - Fixed build error with CONFIG_OF.
> - Added TPM_CHIP_FLAG_REGISTERED to mark successful tpm_chip_register().
> It is checked in the beginning of tpm_chip_unregister(), which is
> called even when "attach" callback for a device fails because "detach"
> callback is always called.
> - Added TPM_CHIP_FLAG_PPI to mark successful PPI interface lookup because
> in older TPM chips version string might be non-existent.
> - Check TPM version from the 4th byte of STS register after requesting
> the locality because otherwise the read will return bogus data.
> - Some TPM chips just give 0xff as the 4th byte so using that for detecting
> TPM family is unstable. Instead I chose the approach of using idempotent
> TPM 2.x command to detect such case.
>
> Jarkko Sakkinen (8):
> tpm: merge duplicate transmit_cmd() functions
> tpm: two-phase chip management functions
> tpm: fix raciness of PPI interface lookup
> tpm: rename chip->dev to chip->pdev
> tpm: device class for tpm
> tpm: TPM 2.0 baseline support
> tpm: TPM 2.0 CRB Interface
> tpm: TPM 2.0 FIFO Interface
>
> Documentation/ABI/stable/sysfs-class-tpm | 22 +-
> drivers/char/tpm/Kconfig | 9 +
> drivers/char/tpm/Makefile | 3 +-
> drivers/char/tpm/tpm-chip.c | 256 +++++++++++++
> drivers/char/tpm/tpm-dev.c | 42 +--
> drivers/char/tpm/tpm-interface.c | 263 +++++--------
> drivers/char/tpm/tpm-sysfs.c | 29 +-
> drivers/char/tpm/tpm.h | 118 +++++-
> drivers/char/tpm/tpm2-cmd.c | 617 +++++++++++++++++++++++++++++++
> drivers/char/tpm/tpm_atmel.c | 25 +-
> drivers/char/tpm/tpm_crb.c | 354 ++++++++++++++++++
> drivers/char/tpm/tpm_i2c_atmel.c | 55 +--
> drivers/char/tpm/tpm_i2c_infineon.c | 43 +--
> drivers/char/tpm/tpm_i2c_nuvoton.c | 71 ++--
> drivers/char/tpm/tpm_i2c_stm_st33.c | 32 +-
> drivers/char/tpm/tpm_ibmvtpm.c | 17 +-
> drivers/char/tpm/tpm_infineon.c | 51 +--
> drivers/char/tpm/tpm_nsc.c | 34 +-
> drivers/char/tpm/tpm_ppi.c | 141 ++++---
> drivers/char/tpm/tpm_tis.c | 224 ++++++-----
> drivers/char/tpm/xen-tpmfront.c | 14 +-
> 21 files changed, 1820 insertions(+), 600 deletions(-)
> create mode 100644 drivers/char/tpm/tpm-chip.c
> create mode 100644 drivers/char/tpm/tpm2-cmd.c
> create mode 100644 drivers/char/tpm/tpm_crb.c
>
> --
> 2.1.0
>
^ permalink raw reply
* Re: [CFT] Can I get some Tested-By's on this series?
From: Serge Hallyn @ 2014-12-15 20:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-man, Kees Cook, Richard Weinberger, Linux Containers,
Josh Triplett, stable, Andy Lutomirski, Kenton Varda, LSM,
Michael Kerrisk-manpages, Linux API, Casey Schaufler,
Andrew Morton,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8761dcwu40.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
>
> > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> >> Stéphane Graber <stgraber-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
> >>
> >> > On Fri, Dec 12, 2014 at 03:38:18PM -0600, Eric W. Biederman wrote:
> >> >> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
> >> >>
> >> >> > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> >> >> >>
> >> >> >> Will people please test these patches with their container project?
> >> >> >>
> >> >> >> These changes break container userspace (hopefully in a minimal way) if
> >> >> >> I could have that confirmed by testing I would really appreciate it. I
> >> >> >> really don't want to send out a bug fix that accidentally breaks
> >> >> >> userspace again.
> >> >> >>
> >> >> >> The only issue sort of under discussion is if there is a better name for
> >> >> >> /proc/<pid>/setgroups, and the name of the file will not affect the
> >> >> >> functionality of the patchset.
> >> >> >>
> >> >> >> With the code reviewed and written in simple obviously correct, easily
> >> >> >> reviewable ways I am hoping/planning to send this to Linus ASAP.
> >> >> >>
> >> >> >> Eric
> >> >> >
> >> >> > Is there a git tree we can clone?
> >> >>
> >> >> Have either of you been able to check to see if any of my changes
> >> >> affects lxc?
> >> >>
> >> >> I am trying to gauge how hard and how fast I should push to Linus. lxc
> >> >> being the largest adopter of unprivileged user namespaces for general
> >> >> purpose containers.
> >> >>
> >> >> I expect you just call newuidmap and newgidmap and don't actually care
> >> >> about not being able to set gid_map without privilege. But I really
> >> >> want to avoid pushing a security fix and then being surprised that
> >> >> things like lxc break.
> >> >>
> >> >> Eric
> >> >
> >> > Hi Eric,
> >> >
> >> > I've unfortunately been pretty busy this week as I was (well, still am)
> >> > travelling to South Africa for a meeting. I don't have a full kernel
> >> > tree around here and a full git clone isn't really doable over the kind
> >> > of Internet I've got here :)
> >> >
> >> > Hopefully Serge can give it a quick try, otherwise I should be able to
> >> > do some tests on Tuesday when I'm back home.
> >>
> >> I thought Serge was going to but I haven't heard yet so I am prodding ;-)
> >
> > Ok, thanks - yes, unprivileged lxc is working fine with your kernels.
> > Just to be sure I was testing the right thing I also tested using
> > my unprivileged nsexec testcases, and they failed on setgroup/setgid
> > as now expected, and succeeded there without your patches.
>
> Thanks.
>
> Serge unless you object will add your Tested-By to my pull message to Linus.
Sounds good.
> Minor question do you runprivileged nsexec test cases test to see if the
> write to gid_map succeeds? I would have expected the gid_map write to
> fail before the setgroups setgid system calls came into play.
Yes, I did that by hand, and it failed (with your kernel).
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 5/6] virtio_pci: add VIRTIO_PCI_NO_LEGACY
From: Michael S. Tsirkin @ 2014-12-15 21:23 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rusty Russell,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1418678575-31755-1-git-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Add macro to disable all legacy register defines.
Helpful to make sure legacy macros don't leak
through into modern code.
Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
include/uapi/linux/virtio_pci.h | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
index e5ec1ca..35b552c 100644
--- a/include/uapi/linux/virtio_pci.h
+++ b/include/uapi/linux/virtio_pci.h
@@ -41,6 +41,8 @@
#include <linux/virtio_config.h>
+#ifndef VIRTIO_PCI_NO_LEGACY
+
/* A 32-bit r/o bitmask of the features supported by the host */
#define VIRTIO_PCI_HOST_FEATURES 0
@@ -67,16 +69,11 @@
* a read-and-acknowledge. */
#define VIRTIO_PCI_ISR 19
-/* The bit of the ISR which indicates a device configuration change. */
-#define VIRTIO_PCI_ISR_CONFIG 0x2
-
/* MSI-X registers: only enabled if MSI-X is enabled. */
/* A 16-bit vector for configuration changes. */
#define VIRTIO_MSI_CONFIG_VECTOR 20
/* A 16-bit vector for selected queue notifications. */
#define VIRTIO_MSI_QUEUE_VECTOR 22
-/* Vector value used to disable MSI for queue */
-#define VIRTIO_MSI_NO_VECTOR 0xffff
/* The remaining space is defined by each driver as the per-driver
* configuration space */
@@ -94,4 +91,12 @@
/* The alignment to use between consumer and producer parts of vring.
* x86 pagesize again. */
#define VIRTIO_PCI_VRING_ALIGN 4096
+
+#endif /* VIRTIO_PCI_NO_LEGACY */
+
+/* The bit of the ISR which indicates a device configuration change. */
+#define VIRTIO_PCI_ISR_CONFIG 0x2
+/* Vector value used to disable MSI for queue */
+#define VIRTIO_MSI_NO_VECTOR 0xffff
+
#endif
--
MST
^ permalink raw reply related
* [PATCH RFC 3/5] virtio-pci: define layout for virtio 1.0
From: Michael S. Tsirkin @ 2014-12-15 21:33 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-sh, linux-api, virtualization
In-Reply-To: <1418679168-1011-1-git-send-email-mst@redhat.com>
From: Rusty Russell <rusty@rustcorp.com.au>
Based on patches by Michael S. Tsirkin <mst@redhat.com>, but I found it
hard to follow so changed to use structures which are more
self-documenting.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/uapi/linux/virtio_pci.h | 62 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
index 35b552c..28c2ce0 100644
--- a/include/uapi/linux/virtio_pci.h
+++ b/include/uapi/linux/virtio_pci.h
@@ -99,4 +99,66 @@
/* Vector value used to disable MSI for queue */
#define VIRTIO_MSI_NO_VECTOR 0xffff
+#ifndef VIRTIO_PCI_NO_MODERN
+
+/* IDs for different capabilities. Must all exist. */
+
+/* Common configuration */
+#define VIRTIO_PCI_CAP_COMMON_CFG 1
+/* Notifications */
+#define VIRTIO_PCI_CAP_NOTIFY_CFG 2
+/* ISR access */
+#define VIRTIO_PCI_CAP_ISR_CFG 3
+/* Device specific confiuration */
+#define VIRTIO_PCI_CAP_DEVICE_CFG 4
+
+/* This is the PCI capability header: */
+struct virtio_pci_cap {
+ __u8 cap_vndr; /* Generic PCI field: PCI_CAP_ID_VNDR */
+ __u8 cap_next; /* Generic PCI field: next ptr. */
+ __u8 cap_len; /* Generic PCI field: capability length */
+ __u8 type_and_bar; /* Upper 3 bits: bar.
+ * Lower 3 is VIRTIO_PCI_CAP_*_CFG. */
+ __le32 offset; /* Offset within bar. */
+ __le32 length; /* Length. */
+};
+
+#define VIRTIO_PCI_CAP_BAR_SHIFT 5
+#define VIRTIO_PCI_CAP_BAR_MASK 0x7
+#define VIRTIO_PCI_CAP_TYPE_SHIFT 0
+#define VIRTIO_PCI_CAP_TYPE_MASK 0x7
+
+struct virtio_pci_notify_cap {
+ struct virtio_pci_cap cap;
+ __le32 notify_off_multiplier; /* Multiplier for queue_notify_off. */
+};
+
+/* Fields in VIRTIO_PCI_CAP_COMMON_CFG: */
+struct virtio_pci_common_cfg {
+ /* About the whole device. */
+ __le32 device_feature_select; /* read-write */
+ __le32 device_feature; /* read-only */
+ __le32 guest_feature_select; /* read-write */
+ __le32 guest_feature; /* read-write */
+ __le16 msix_config; /* read-write */
+ __le16 num_queues; /* read-only */
+ __u8 device_status; /* read-write */
+ __u8 config_generation; /* read-only */
+
+ /* About a specific virtqueue. */
+ __le16 queue_select; /* read-write */
+ __le16 queue_size; /* read-write, power of 2. */
+ __le16 queue_msix_vector; /* read-write */
+ __le16 queue_enable; /* read-write */
+ __le16 queue_notify_off; /* read-only */
+ __le32 queue_desc_lo; /* read-write */
+ __le32 queue_desc_hi; /* read-write */
+ __le32 queue_avail_lo; /* read-write */
+ __le32 queue_avail_hi; /* read-write */
+ __le32 queue_used_lo; /* read-write */
+ __le32 queue_used_hi; /* read-write */
+};
+
+#endif /* VIRTIO_PCI_NO_MODERN */
+
#endif
--
MST
^ permalink raw reply related
* [PATCH RFC 5/5] virtio_pci: macros for PCI layout offsets.
From: Michael S. Tsirkin @ 2014-12-15 21:33 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, virtualization, linux-sh, cornelia.huck, linux-api
In-Reply-To: <1418679168-1011-1-git-send-email-mst@redhat.com>
QEMU wants it, so why not? Trust, but verify.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
include/uapi/linux/virtio_pci.h | 30 ++++++++++++++++++
drivers/virtio/virtio_pci_modern.c | 63 ++++++++++++++++++++++++++++++++++++++
2 files changed, 93 insertions(+)
diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
index 28c2ce0..5d546c6 100644
--- a/include/uapi/linux/virtio_pci.h
+++ b/include/uapi/linux/virtio_pci.h
@@ -159,6 +159,36 @@ struct virtio_pci_common_cfg {
__le32 queue_used_hi; /* read-write */
};
+/* Macro versions of offsets for the Old Timers! */
+#define VIRTIO_PCI_CAP_VNDR 0
+#define VIRTIO_PCI_CAP_NEXT 1
+#define VIRTIO_PCI_CAP_LEN 2
+#define VIRTIO_PCI_CAP_TYPE_AND_BAR 3
+#define VIRTIO_PCI_CAP_OFFSET 4
+#define VIRTIO_PCI_CAP_LENGTH 8
+
+#define VIRTIO_PCI_NOTIFY_CAP_MULT 12
+
+#define VIRTIO_PCI_COMMON_DFSELECT 0
+#define VIRTIO_PCI_COMMON_DF 4
+#define VIRTIO_PCI_COMMON_GFSELECT 8
+#define VIRTIO_PCI_COMMON_GF 12
+#define VIRTIO_PCI_COMMON_MSIX 16
+#define VIRTIO_PCI_COMMON_NUMQ 18
+#define VIRTIO_PCI_COMMON_STATUS 20
+#define VIRTIO_PCI_COMMON_CFGGENERATION 21
+#define VIRTIO_PCI_COMMON_Q_SELECT 22
+#define VIRTIO_PCI_COMMON_Q_SIZE 24
+#define VIRTIO_PCI_COMMON_Q_MSIX 26
+#define VIRTIO_PCI_COMMON_Q_ENABLE 28
+#define VIRTIO_PCI_COMMON_Q_NOFF 30
+#define VIRTIO_PCI_COMMON_Q_DESCLO 32
+#define VIRTIO_PCI_COMMON_Q_DESCHI 36
+#define VIRTIO_PCI_COMMON_Q_AVAILLO 40
+#define VIRTIO_PCI_COMMON_Q_AVAILHI 44
+#define VIRTIO_PCI_COMMON_Q_USEDLO 48
+#define VIRTIO_PCI_COMMON_Q_USEDHI 52
+
#endif /* VIRTIO_PCI_NO_MODERN */
#endif
diff --git a/drivers/virtio/virtio_pci_modern.c b/drivers/virtio/virtio_pci_modern.c
index 636666c..5b0c012 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -446,6 +446,67 @@ static inline int virtio_pci_find_capability(struct pci_dev *dev, u8 cfg_type,
return 0;
}
+/* This is part of the ABI. Don't screw with it. */
+static inline void check_offsets(void)
+{
+ /* Note: disk space was harmed in compilation of this function. */
+ BUILD_BUG_ON(VIRTIO_PCI_CAP_VNDR !=
+ offsetof(struct virtio_pci_cap, cap_vndr));
+ BUILD_BUG_ON(VIRTIO_PCI_CAP_NEXT !=
+ offsetof(struct virtio_pci_cap, cap_next));
+ BUILD_BUG_ON(VIRTIO_PCI_CAP_LEN !=
+ offsetof(struct virtio_pci_cap, cap_len));
+ BUILD_BUG_ON(VIRTIO_PCI_CAP_TYPE_AND_BAR !=
+ offsetof(struct virtio_pci_cap, type_and_bar));
+ BUILD_BUG_ON(VIRTIO_PCI_CAP_OFFSET !=
+ offsetof(struct virtio_pci_cap, offset));
+ BUILD_BUG_ON(VIRTIO_PCI_CAP_LENGTH !=
+ offsetof(struct virtio_pci_cap, length));
+ BUILD_BUG_ON(VIRTIO_PCI_NOTIFY_CAP_MULT !=
+ offsetof(struct virtio_pci_notify_cap,
+ notify_off_multiplier));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_DFSELECT !=
+ offsetof(struct virtio_pci_common_cfg,
+ device_feature_select));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_DF !=
+ offsetof(struct virtio_pci_common_cfg, device_feature));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_GFSELECT !=
+ offsetof(struct virtio_pci_common_cfg,
+ guest_feature_select));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_GF !=
+ offsetof(struct virtio_pci_common_cfg, guest_feature));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_MSIX !=
+ offsetof(struct virtio_pci_common_cfg, msix_config));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_NUMQ !=
+ offsetof(struct virtio_pci_common_cfg, num_queues));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_STATUS !=
+ offsetof(struct virtio_pci_common_cfg, device_status));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_CFGGENERATION !=
+ offsetof(struct virtio_pci_common_cfg, config_generation));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_SELECT !=
+ offsetof(struct virtio_pci_common_cfg, queue_select));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_SIZE !=
+ offsetof(struct virtio_pci_common_cfg, queue_size));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_MSIX !=
+ offsetof(struct virtio_pci_common_cfg, queue_msix_vector));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_ENABLE !=
+ offsetof(struct virtio_pci_common_cfg, queue_enable));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_NOFF !=
+ offsetof(struct virtio_pci_common_cfg, queue_notify_off));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_DESCLO !=
+ offsetof(struct virtio_pci_common_cfg, queue_desc_lo));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_DESCHI !=
+ offsetof(struct virtio_pci_common_cfg, queue_desc_hi));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_AVAILLO !=
+ offsetof(struct virtio_pci_common_cfg, queue_avail_lo));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_AVAILHI !=
+ offsetof(struct virtio_pci_common_cfg, queue_avail_hi));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_USEDLO !=
+ offsetof(struct virtio_pci_common_cfg, queue_used_lo));
+ BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_USEDHI !=
+ offsetof(struct virtio_pci_common_cfg, queue_used_hi));
+}
+
/* the PCI probing function */
int virtio_pci_modern_probe(struct pci_dev *pci_dev,
const struct pci_device_id *id)
@@ -455,6 +516,8 @@ int virtio_pci_modern_probe(struct pci_dev *pci_dev,
struct virtio_device_id virtio_id;
u32 notify_length;
+ check_offsets();
+
/* We only own devices >= 0x1000 and <= 0x107f: leave the rest. */
if (pci_dev->device < 0x1000 || pci_dev->device > 0x107f)
return -ENODEV;
--
MST
^ permalink raw reply related
* [GIT PULL RESEND] kselftest-3.19-rc1
From: Shuah Khan @ 2014-12-15 21:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Shuah Khan, Shuah Khan
In-Reply-To: <548EEA88.2060206-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Hi Linus,
Please pull the following Kselftest updates for 3.19-rc1. Hope
I have this right this time. Sorry again for the messed up
first request.
thanks,
-- Shuah
The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4:
Linux 3.18-rc3 (2014-11-02 15:01:51 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-3.19-rc1
for you to fetch changes up to 3ce51050fadd63737c03627293ca2dc4be238891:
selftest: size: Add size test for Linux kernel (2014-12-03 19:27:47 -0700)
----------------------------------------------------------------
kselftest updates for 3.19-rc1
----------------------------------------------------------------
Michael Ellerman (3):
kcmp: Move kcmp.h into uapi
selftests/kcmp: Don't include kernel headers
selftests/kcmp: Always try to build the test
Shuah Khan (7):
selftests/net: move test out of Makefile into a shell script
selftests/user: move test out of Makefile into a shell script
selftests: add kselftest framework for uniform test reporting
selftests/breakpoints: change test to use ksft framework
selftests/ipc: change test to use ksft framework
selftests/kcmp: change test to use ksft framework
selftests/timers: change test to use ksft framework
Tim Bird (1):
selftest: size: Add size test for Linux kernel
include/uapi/linux/Kbuild | 1 +
include/{ => uapi}/linux/kcmp.h | 6 +-
tools/testing/selftests/Makefile | 1 +
.../selftests/breakpoints/breakpoint_test.c | 10 ++-
tools/testing/selftests/ipc/msgque.c | 26 +++---
tools/testing/selftests/kcmp/Makefile | 22 +----
tools/testing/selftests/kcmp/kcmp_test.c | 27 ++++--
tools/testing/selftests/kselftest.h | 62 +++++++++++++
tools/testing/selftests/net/Makefile | 8 +-
tools/testing/selftests/net/test_bpf.sh | 10 +++
tools/testing/selftests/size/.gitignore | 1 +
tools/testing/selftests/size/Makefile | 12 +++
tools/testing/selftests/size/get_size.c | 100
+++++++++++++++++++++
tools/testing/selftests/timers/posix_timers.c | 14 +--
tools/testing/selftests/user/Makefile | 8 +-
tools/testing/selftests/user/test_user_copy.sh | 10 +++
16 files changed, 252 insertions(+), 66 deletions(-)
rename include/{ => uapi}/linux/kcmp.h (62%)
create mode 100644 tools/testing/selftests/kselftest.h
tools/testing/selftests/net/Makefile | 8 +-
tools/testing/selftests/net/test_bpf.sh | 10 +++
tools/testing/selftests/size/.gitignore | 1 +
tools/testing/selftests/size/Makefile | 12 +++
tools/testing/selftests/size/get_size.c | 100
+++++++++++++++++++++
tools/testing/selftests/timers/posix_timers.c | 14 +--
tools/testing/selftests/user/Makefile | 8 +-
tools/testing/selftests/user/test_user_copy.sh | 10 +++
16 files changed, 252 insertions(+), 66 deletions(-)
rename include/{ => uapi}/linux/kcmp.h (62%)
create mode 100644 tools/testing/selftests/kselftest.h
create mode 100755 tools/testing/selftests/net/test_bpf.sh
create mode 100644 tools/testing/selftests/size/.gitignore
create mode 100644 tools/testing/selftests/size/Makefile
create mode 100644 tools/testing/selftests/size/get_size.c
create mode 100755 tools/testing/selftests/user/test_user_copy.sh
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Open Source Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ 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