Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working

2018-11-11 Thread James Bottomley
On Sun, 2018-11-11 at 21:09 +0100, Michael Niewöhner wrote: > On Sun, 2018-11-11 at 10:57 -0800, James Bottomley wrote: [...] > > Well, I still think the ACPI setup is incorrect. What's in > > /sys/class/platform (should be directories of ACPI devices)? The > > TPM i

Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working

2018-11-11 Thread James Bottomley
On Sun, 2018-11-11 at 19:50 +0100, Michael Niewöhner wrote: [...] > > However, this makes me wonder about yours: > > > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO > > > TC- > > > S06 1300 AMI ) > > > > I thought the Lenovo "upgrade to 2.0" in fact disabled

Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working

2018-11-11 Thread James Bottomley
On Sun, 2018-11-11 at 18:55 +0100, Michael Niewöhner wrote: > Hi all, > > Nuvoton NCPT650 does not work in TPM 2.0 mode with tpm_tis / > tpm_i2c_nuvoton while it works in TPM 1.2 mode (I can reflash it via > UEFI setup). Kernel version is 4.19.1 Not that this helps you, but mine definitely

Re: [RFC PATCH 6/6] shiftfs: support nested shiftfs mounts

2018-11-02 Thread James Bottomley
On Fri, 2018-11-02 at 15:16 +0200, Amir Goldstein wrote: > On Fri, Nov 2, 2018 at 2:44 PM Seth Forshee om> wrote: > > > > On Fri, Nov 02, 2018 at 12:02:45PM +0200, Amir Goldstein wrote: > > > On Thu, Nov 1, 2018 at 11:49 PM Seth Forshee > > cal.com> wrote: > > > > > > > > shiftfs mounts cannot

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

2018-11-02 Thread James Bottomley
On Fri, 2018-11-02 at 08:50 +1100, NeilBrown wrote: > Firstly, you gave an analytical response to what was, in my view, an > emotional observation. While I agree with your analysis, it is > largely irrelevant. It is not how people *feel* about kernel > development. > > You say that the code

Re: [PATCH v6 0/1] ns: introduce binfmt_misc namespace

2018-11-01 Thread James Bottomley
On Thu, 2018-11-01 at 04:51 +0100, Jann Horn wrote: > On Thu, Nov 1, 2018 at 3:59 AM James Bottomley > wrote: > > > > On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote: > > > Hi, > > > > > > Any comment on this last version? > > >

Re: [PATCH v6 0/1] ns: introduce binfmt_misc namespace

2018-10-31 Thread James Bottomley
On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote: > Hi, > > Any comment on this last version? > > Any chance to be merged? I've got a use case for this: I went to one of the Graphene talks in Edinburgh and it struck me that we seem to keep reinventing the type of sandboxing that

Re: [PATCH] scsi: aic7xxx: Fix unintended sign extension issue

2018-10-25 Thread James Bottomley
On Thu, 2018-10-25 at 16:13 +0100, Colin King wrote: > From: Colin Ian King > > In the expression "ahc_inb(ahc, port+3) << 24", the initial value is > a u8, but is promoted to a signed int, then sign-extended to > uint64_t. Why is this, that's highly non intuitive? The compiler is supposed to

Re: [Ksummit-discuss] [GIT PULL] code of conduct fixes for 4.19-rc8

2018-10-23 Thread James Bottomley
On Mon, 2018-10-22 at 22:10 +0100, Greg Kroah-Hartman wrote: > On Sat, Oct 20, 2018 at 01:15:14PM -0700, James Bottomley wrote: > > This is the series of patches which has been discussed on both > > ksummit-discuss and linux-kernel for the past few weeks. As Shuah > >

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

2018-10-22 Thread James Bottomley
On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote: > On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > > > Hi all, > > > > As everyone knows by now, we added a new Code of Conduct to the > > kernel tree a few weeks ago. > > I wanted to stay detached from all this, but as remaining (publicly) >

[GIT PULL] code of conduct fixes for 4.19-rc8

2018-10-20 Thread James Bottomley
This is the series of patches which has been discussed on both ksummit- discuss and linux-kernel for the past few weeks. As Shuah said when kicking off the process, it's designed as a starting point for the next phase of the discussion, not as the end point, so it's only really a set of minor

Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address

2018-10-20 Thread James Bottomley
On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote: > > +to the circumstances. The Code of Conduct Committee is obligated > > to > > +maintain confidentiality with regard to the reporter of an > > incident. > > +Further details of specific enforcement policies may be posted > > +separately. > >

Re: linux-next: build warning after merge of the scsi tree

2018-10-18 Thread James Bottomley
On Fri, 2018-10-19 at 15:50 +1100, Stephen Rothwell wrote: > Hi James, > > After merging the scsi tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > drivers/scsi/lpfc/lpfc_debugfs.c: In function > 'lpfc_debugfs_nodelist_open': >

Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-18 Thread James Bottomley
On Thu, 2018-10-18 at 19:49 +, tim.b...@sony.com wrote: > > -Original Message- > > From: Frank Rowand > > > > On 10/18/18 07:56, James Bottomley wrote: > > > On Wed, 2018-10-17 at 12:53 -0700, Frank Rowand wrote: > > >

Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-18 Thread James Bottomley
On Wed, 2018-10-17 at 12:53 -0700, Frank Rowand wrote: > On 10/17/18 12:08, James Bottomley wrote: [...] > > > Trying to understand how you are understanding my comment vs what > > > I intended to communicate, it seems to me that you are focused on > > > the &q

Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-17 Thread James Bottomley
On Wed, 2018-10-17 at 11:49 -0700, Frank Rowand wrote: > On 10/16/18 19:41, James Bottomley wrote: > > On Tue, 2018-10-16 at 19:10 -0700, Frank Rowand wrote: [...] > > > Repeating my comment on version 1: > > > > > > My understanding of the concern behind

Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors

2018-10-17 Thread James Bottomley
On Wed, 2018-10-17 at 08:21 -0700, Josh Triplett wrote: > People in underrepresented and commonly marginalized groups, > especially those more commonly overlooked, don't always know if a > given group has taken their particular group into account or given > any thought to it. Explicit inclusion

Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-16 Thread James Bottomley
On Tue, 2018-10-16 at 19:10 -0700, Frank Rowand wrote: > On 10/16/18 07:58, James Bottomley wrote: > > The current code of conduct has an ambiguity in the it considers > > publishing > > private information such as email addresses unacceptable > > behaviour. Since &g

[PATCH v3 3/3] code-of-conduct: Add back the TAB as the central reporting point

2018-10-16 Thread James Bottomley
Acked-by: Geert Uytterhoeven Signed-off-by: James Bottomley --- v2: Added this patch to allay concerns we were stripping the reporting mechanism entirely. v3: Add (where required by law) as a qualifier to the confidentiality requirement --- Documentation/process/code-of-conduct.rst | 11

[PATCH v3 2/3] code-of-conduct: Strip the enforcement paragraph pending community discussion

2018-10-16 Thread James Bottomley
: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.") Acked-by: Shuah Khan Acked-by: Guenter Roeck Acked-by: Geert Uytterhoeven Reviewed-by: Alan Cox Signed-off-by: James Bottomley --- v2: Added additional commit paragraph clarifying we do expect eventually to have an enforceme

[PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-16 Thread James Bottomley
Acked-by: Kees Cook Signed-off-by: James Bottomley --- Documentation/process/code-of-conduct.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index ab7c24b5478c..aa40e34e7785 100644 --- a/D

[PATCH v3 0/3] code of conduct fixes

2018-10-16 Thread James Bottomley
since that's where most of the current discussion is. I can add other lists as people suggest them. James --- James Bottomley (3): code-of-conduct: Fix the ambiguity about collecting email addresses code-of-conduct: Strip the enforcement paragraph pending community discussion code

Re: [PATCH] KEYS: trusted: fix -Wvarags warning

2018-10-12 Thread James Bottomley
On Fri, 2018-10-12 at 10:53 -0500, Denis Kenzior wrote: > Hi James, > > > > From the links provided in the patch it seems that one cannot > > > pass char/float/short to va_start(). Fair enough. So if we make > > > h3 an unsigned int, the issue goes away, no? > > > > For the current version

Re: [PATCH] KEYS: trusted: fix -Wvarags warning

2018-10-12 Thread James Bottomley
On Fri, 2018-10-12 at 10:44 -0500, Denis Kenzior wrote: > Hi James, > > > > So instead of having unsigned char h3, can't we simply have bool > > > h3 or unsigned int h3? > > > > Given the ambiguity in the standards, the safe thing that will work > > for all time and all potential compilers is a

Re: [PATCH] KEYS: trusted: fix -Wvarags warning

2018-10-12 Thread James Bottomley
On Fri, 2018-10-12 at 10:13 -0500, Denis Kenzior wrote: > Hi James, > > > > So can't we simply use 'bool' or uint32 as the type for h3 > > > instead > > > of re-ordering everything > > > > The problem is the standard is ambiguious. The only thing that's > > guaranteed to work for all time is a

Re: [PATCH] KEYS: trusted: fix -Wvarags warning

2018-10-12 Thread James Bottomley
On Fri, 2018-10-12 at 10:13 -0500, Denis Kenzior wrote: > Hi James, > > > > So can't we simply use 'bool' or uint32 as the type for h3 > > > instead of re-ordering everything > > > > The problem is the standard is ambiguious. The only thing that's > > guaranteed to work for all time is a char

Re: [PATCH] KEYS: trusted: fix -Wvarags warning

2018-10-12 Thread James Bottomley
On Fri, 2018-10-12 at 07:29 -0500, Denis Kenzior wrote: > Hi Nick, > > > @@ -123,7 +123,7 @@ static int TSS_rawhmac(unsigned char *digest, > > const unsigned char *key, > >*/ > > static int TSS_authhmac(unsigned char *digest, const unsigned > > char *key, > > unsigned

Re: undefined behavior (-Wvarargs) in security/keys/trusted.c#TSS_authhmac()

2018-10-11 Thread James Bottomley
On Thu, 2018-10-11 at 18:02 +0200, Arnd Bergmann wrote: > On 10/10/18, Nick Desaulniers wrote: > > Hello, > > I noticed that compiling with > > CONFIG_TCG_TPM=y > > CONFIG_HW_RANDOM_TPM=y > > and Clang produced the warning: > > > > CC security/keys/trusted.o > >

Re: [Ksummit-discuss] [PATCH v2 0/3] code of conduct fixes

2018-10-10 Thread James Bottomley
On Wed, 2018-10-10 at 18:23 -0500, Eric W. Biederman wrote: > James Bottomley writes: > > > Resend to show accumulated tags and also to add a third patch > > listing the TAB as the reporting point as a few people seem to > > want. If it gets the same lev

Re: [Ksummit-discuss] [PATCH v2 2/3] code-of-conduct: Strip the enforcement paragraph pending community discussion

2018-10-10 Thread James Bottomley
On Wed, 2018-10-10 at 21:04 +, Luck, Tony wrote: > > the enforcement clause of the new code of conduct. Since there is > > concern that this becomes binding on the release of the 4.19 kernel > > Is there some logic behind that concern? Well, yes, Linux as a project goes through numbered

[PATCH v2 3/3] code-of-conduct: Add back the TAB as the central reporting point

2018-10-10 Thread James Bottomley
Add a Reporting section where the Enforcement section used to be. The intention is still to debate what should go here, but in the meantime, this gives us back the central reporting point we had in the old code of conflict. Signed-off-by: James Bottomley --- v2: Added this patch to allay

[PATCH v2 2/3] code-of-conduct: Strip the enforcement paragraph pending community discussion

2018-10-10 Thread James Bottomley
: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.") Acked-by: Shuah Khan Acked-by: Guenter Roeck Acked-by: Geert Uytterhoeven Reviewed-by: Alan Cox Signed-off-by: James Bottomley --- v2: Added additional commit paragraph clarifying we do expect eventually to have an enforceme

[PATCH v2 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-10 Thread James Bottomley
collected by the project to correct this ambiguity. Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.") Acked-by: Geert Uytterhoeven Acked-by: Shuah Khan Acked-by: Guenter Roeck Reviewed-by: Alan Cox Reviewed-by: Mauro Carvalho Chehab Signed-off-by: James Bottomley --- Doc

[PATCH v2 0/3] code of conduct fixes

2018-10-10 Thread James Bottomley
is looked on with less favour than the other. It was also a bit unclear which list to send this to, but I finally settled on linux-kernel as the catch all and ksummit-discuss since that's where most of the current discussion is. I can add other lists as people suggest them. James --- James

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-09 Thread James Bottomley
> > > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley > > > > wrote: > > > > > The current code of conduct has an ambiguity in the it > > > > > considers publishing private information such as email > > > > > addresses un

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

2018-10-08 Thread James Bottomley
On Mon, 2018-10-08 at 17:58 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley > > > > On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > > > -Original Message- > > > > From: James Bot

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-08 Thread James Bottomley
On Mon, 2018-10-08 at 08:20 -0700, Josh Triplett wrote: > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote: > > The current code of conduct has an ambiguity in the it considers > > publishing private information such as email addresses unacceptable > > behavi

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

2018-10-08 Thread James Bottomley
On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley  > > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > > > -Original Message- > > > > From: James Bottomley >

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-08 Thread James Bottomley
On Mon, 2018-10-08 at 08:25 +1000, Dave Airlie wrote: > On Sun, 7 Oct 2018 at 07:36, James Bottomley > wrote: > > > > From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 > > 2001 > > From: James Bottomley > > Date: Sat, 6 Oct 2018 14:21:56

Re: [Ksummit-discuss] [PATCH 0/2] code of conduct fixes

2018-10-07 Thread James Bottomley
On Sun, 2018-10-07 at 19:11 +0200, Daniel Vetter wrote: > Hi James, > > On Sat, Oct 6, 2018 at 11:36 PM James Bottomley > wrote: > > We've had several threads discussing potential changes to the code > > of > > conduct but Mauro is the only person to hav

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-07 Thread James Bottomley
On Sun, 2018-10-07 at 11:04 +0200, Daniel Vetter wrote: > On Sat, Oct 6, 2018 at 11:36 PM James Bottomley > wrote: > > > > From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 > > 2001 > > From: James Bottomley > > Date: Sat, 6 Oct 2018 14:21:56

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

2018-10-06 Thread James Bottomley
On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote: > > -Original Message- > > From: James Bottomley > > > > Significant concern has been expressed about the responsibilities > > outlined in the enforcement clause of the new code of > &

[PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

2018-10-06 Thread James Bottomley
this should be handled. Signed-off-by: James Bottomley --- Documentation/process/code-of-conduct.rst | 15 --- 1 file changed, 15 deletions(-) diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index aa40e34e7785..4dd90987305b 100644

[PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-06 Thread James Bottomley
>From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Sat, 6 Oct 2018 14:21:56 -0700 Subject: [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses The current code of conduct has an ambiguity in the it considers publish

[PATCH 0/2] code of conduct fixes

2018-10-06 Thread James Bottomley
other lists as people suggest them. James --- James Bottomley (2):   code-of-conduct: Fix the ambiguity about collecting email addresses   code-of-conduct: Strip the enforcement paragraph pending community discussion  Documentation/process/code-of-conduct.rst | 17 +  1 file

Re: [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled

2018-10-03 Thread James Bottomley
On Wed, 2018-10-03 at 21:31 -0300, Leonardo Bras wrote: > On Fri, Sep 28, 2018 at 4:15 AM James Bottomley > wrote: > > > > On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote: > > > Avoids building driver if 'make drivers/parisc/' is called and >

Re: [RFC v2 v2 0/1] ns: introduce binfmt_misc namespace

2018-10-03 Thread James Bottomley
On Tue, 2018-10-02 at 18:47 +0200, Laurent Vivier wrote: > Le 02/10/2018 à 18:13, James Bottomley a écrit : > > On Tue, 2018-10-02 at 12:20 +0200, Laurent Vivier wrote: > > > v2: no new namespace, binfmt_misc data are now part of > > > the mount namespace &g

Re: [RFC v2 v2 0/1] ns: introduce binfmt_misc namespace

2018-10-02 Thread James Bottomley
On Tue, 2018-10-02 at 12:20 +0200, Laurent Vivier wrote: > v2: no new namespace, binfmt_misc data are now part of > the mount namespace > I put this in mount namespace instead of user namespace > because the mount namespace is already needed and > I don't want to force to have the

Re: [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled

2018-09-28 Thread James Bottomley
On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote: > Avoids building driver if 'make drivers/parisc/' is called and > CONFIG_PARISC is disabled. Is that really a problem? The drivers/Makefile has this: obj-$(CONFIG_PARISC)+= parisc/  And you just overrode that by forcing the

Re: [PATCH RFC] MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com

2018-09-19 Thread James Bottomley
McKenney > Cc: Douglas Miller > Cc: Eddie James > Cc: Frank Haverkamp > Cc: Frederic Barrat > Cc: James Bottomley Acked-by: James Bottomley James

Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops

2018-09-18 Thread James Bottomley
On Tue, 2018-09-18 at 08:00 +0100, David Woodhouse wrote: > > On Sat, 2018-09-08 at 16:26 +0100, David Howells wrote: > > Marcel Holtmann wrote: > > > > > > > > so I have reviewed and tested this code. In addition, we have > > > test cases for it in ELL (embedded linux library). > > > > I

Re: [PATCH] MAINTAINERS: Add me as a keys/trusted maintainer

2018-09-16 Thread James Bottomley
On Sun, 2018-09-16 at 22:19 +0300, Jarkko Sakkinen wrote: > On Thu, Sep 13, 2018 at 05:45:54PM +0100, David Howells wrote: > > Jarkko Sakkinen wrote: > > > > > David, what do you think? > > > > Which David? > > > > I think you need to ask James and Mimi since they're the current > >

Re: [regression/bisected] 4.19 cycle boot time IO stalls

2018-09-05 Thread James Bottomley
On Wed, 2018-09-05 at 12:25 -0400, Martin K. Petersen wrote: > Jens, > > > I bet it's the host busy change from Ming, which I already > > reported as being the culprit for another test failure I had. For > > some reason it's not merged yet, nudge nudge Martin. > > I reverted the two offending

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

2018-08-31 Thread James Bottomley
On Mon, 2018-08-20 at 21:52 +, Woodhouse, David wrote: > On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote: > > > > Of course, after the long (and entirely unrelated) discussion about > > the TLB flushing bug we had, I'm starting to worry about my own > > competence, and maybe I'm

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-17 Thread James Bottomley
On Fri, 2018-08-17 at 10:42 -0500, Justin Forbes wrote: > On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley > wrote: > > On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote: [...] > > > We also don't necessarily want to encourage ordinary users to > > > fiddle

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-17 Thread James Bottomley
On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote: > James Bottomley wrote: > > > > > As a step by step process, I agree.  However, I think we can > > > > automate it to the point where you install a package and it > > > > says "insert

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-16 Thread James Bottomley
On Thu, 2018-08-16 at 21:31 +0100, David Howells wrote: > James Bottomley wrote: > > > As a step by step process, I agree.  However, I think we can > > automate it to the point where you install a package and it says > > "insert your yubikey" every time you upg

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-16 Thread James Bottomley
On Thu, 2018-08-16 at 16:56 +, David Laight wrote: > From: James Bottomley > > Sent: 16 August 2018 16:57 > > On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote: > > > James Bottomley wrote: > > > > > > > > The problem with that is th

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-16 Thread James Bottomley
On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote: > James Bottomley wrote: > > > > The problem with that is that it means you can't load third party > > > modules - such as the NVidia driver.  That's fine if you > > > absolutely reject the right

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-16 Thread James Bottomley
On Thu, 2018-08-16 at 08:16 -0700, James Bottomley wrote: > So your lawyers tell you if you sign a third party module for your > kernel then you could get blamed for the damage it causes?  So this > whole escapade is about Red Hat trying to evade legal responsibility > for allowi

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-16 Thread James Bottomley
On Thu, 2018-08-16 at 14:51 +0100, David Howells wrote: > Linus Torvalds wrote: > > > > I see that module signing code trusts only builtin keys and > > > not the keys in secondary_trusted_keys keyring. > > > > This, I think, makes sense. > > > > It basically says: we don't allow modules that

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-16 Thread James Bottomley
On Thu, 2018-08-16 at 15:43 +0100, David Howells wrote: > James Bottomley wrote: > > > I've told you several times you can't use the secure boot keys for > > any form > > of trust beyond boot, > > Yes - and you've been told several times that you're wrong. >

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-16 Thread James Bottomley
On Thu, 2018-08-16 at 13:13 +0100, David Howells wrote: > Vivek Goyal wrote: > > > Now this patch changed it to trusting builtin_trusted_keys by > > default, and all the other keys go to secondary_trusted_keys > > kerying. And that probably explains why it broke. > > > > So checking for keys in

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread James Bottomley
On Wed, 2018-08-15 at 17:52 -0400, Vivek Goyal wrote: > On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote: > > On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote: > > > On 15.08.2018 22:47, Linus Torvalds wrote: > > > > It basically says: we do

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread James Bottomley
On Wed, 2018-08-15 at 23:31 +0200, Yannik Sembritzki wrote: > On 15.08.2018 23:13, James Bottomley wrote: > > Consider a UEFI system for which a user has taken ownership, but > > which > > has some signed ROMs which are UEFI secure boot verified.  Simply > > to &

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread James Bottomley
On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote: > On 15.08.2018 22:47, Linus Torvalds wrote: > > It basically says: we don't allow modules that weren't built with > > the kernel. Adding a new key later and signing a module with it > > violates that premise. > > Considering the

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread James Bottomley
On Wed, 2018-08-15 at 13:47 -0700, Linus Torvalds wrote: > On Wed, Aug 15, 2018 at 12:49 PM Vivek Goyal > wrote: > > > > I see that module signing code trusts only builtin keys and > > not the keys in secondary_trusted_keys keyring. > > This, I think, makes sense. > > It basically says: we

[GIT PULL] first round of SCSI updates for the 4.18+ merge window

2018-08-15 Thread James Bottomley
4710cac0ef4 51372570ac3c Author: James Bottomley Date: Wed Aug 15 10:29:51 2018 -0700 Merge branch 'misc' into for-next diff --cc MAINTAINERS index 544cac829cf4,f3de5d37179a..eeb54037b62d --- a/MAINTAINERS +++ b/MAINTAINERS @@@ -9751,17 -9750,6 +9751,11 @@@ F:drivers/scsi/mac_scsi. F:

Re: [PATCH v4 2/2] tpm: add support for nonblocking operation

2018-08-10 Thread James Bottomley
On Fri, 2018-08-10 at 11:56 -0700, Tadeusz Struk wrote: > On 08/10/2018 11:48 AM, James Bottomley wrote: > > On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote: > > > and the feedback I got from Jason was: > > > > > > "I wonder if it is worth creating

Re: [PATCH v4 2/2] tpm: add support for nonblocking operation

2018-08-10 Thread James Bottomley
On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote: > and the feedback I got from Jason was: > > "I wonder if it is worth creating this when the first file is > opened.. Lots of systems have TPMs but few use the userspace.." > > so I changed this to allocate the WQ on first open. I think it

Re: [PATCH v4 0/4] seccomp trap to userspace

2018-08-07 Thread James Bottomley
On Mon, 2018-08-06 at 20:44 -0600, Tycho Andersen wrote: > Hi all, > > Dinesh Subhraveti has claimed that some part of this series might be > patented. While he has not furnished me with anything to confirm this > claim, I'll put this series on hold. Just on a general policy for handling things

Re: [PATCH v3 RESEND 2/2] tpm: add support for nonblocking operation

2018-08-06 Thread James Bottomley
On Mon, 2018-08-06 at 17:09 -0700, Tadeusz Struk wrote: > On 08/06/2018 04:05 PM, James Bottomley wrote: > > For an async interface, shouldn't I be able to queue an > > arbitrary number of commands without blocking? > > That was the approach in the v1 version of this patch,

Re: [PATCH v3 RESEND 2/2] tpm: add support for nonblocking operation

2018-08-06 Thread James Bottomley
On Mon, 2018-08-06 at 14:14 -0700, Tadeusz Struk wrote: [...] > +static void tpm_async_work(struct work_struct *work) > +{ > + struct file_priv *priv = > + container_of(work, struct file_priv, > async_work); > + ssize_t ret; > + > + ret = tpm_transmit(priv->chip,

Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.

2018-08-03 Thread James Bottomley
On Fri, 2018-08-03 at 10:45 -0400, Mimi Zohar wrote: > On Fri, 2018-08-03 at 07:23 -0700, James Bottomley wrote: > > On Fri, 2018-08-03 at 07:58 -0400, Mimi Zohar wrote: > > > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote: > >

Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.

2018-08-03 Thread James Bottomley
On Fri, 2018-08-03 at 07:58 -0400, Mimi Zohar wrote: > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote: > > Udit Agarwal wrote: > > > > > +== > > > +Secure Key > > > +== > > > + > > > +Secure key is the new type added to kernel key ring service. > > > +Secure key is a

Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.

2018-08-02 Thread James Bottomley
On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote: > Udit Agarwal wrote: > > > +== > > +Secure Key > > +== > > + > > +Secure key is the new type added to kernel key ring service. > > +Secure key is a symmetric type key of minimum length 32 bytes > > +and with maximum

Re: [PATCH] tpm: add support for partial reads

2018-07-23 Thread James Bottomley
On Mon, 2018-07-23 at 13:53 -0700, Tadeusz Struk wrote: > On 07/23/2018 01:19 PM, Jarkko Sakkinen wrote: > > In this case I do not have any major evidence of any major benefit > > *and* the change breaks the ABI. > > As I said before - this does not break the ABI. The current patch does, you

Re: [PATCH] tpm: add support for partial reads

2018-07-19 Thread James Bottomley
On Thu, 2018-07-19 at 13:12 -0700, Tadeusz Struk wrote: > On 07/19/2018 12:52 PM, James Bottomley wrote: > > The ABI break is the error case as I outlined above.  We can't > > assume everyone uses the current interface without getting an error > > and one error and your hos

Re: [PATCH] tpm: add support for partial reads

2018-07-19 Thread James Bottomley
On Thu, 2018-07-19 at 12:05 -0700, Tadeusz Struk wrote: > On 07/19/2018 11:47 AM, James Bottomley wrote: > > On Thu, 2018-07-19 at 10:54 -0700, Tadeusz Struk wrote: > > > On 07/19/2018 10:19 AM, James Bottomley wrote: > > > > That's just an implementatio

Re: [PATCH] tpm: add support for partial reads

2018-07-19 Thread James Bottomley
On Thu, 2018-07-19 at 10:54 -0700, Tadeusz Struk wrote: > On 07/19/2018 10:19 AM, James Bottomley wrote: > > That's just an implementation, though, what's the use case? > > Hi James, > The use case is described in the TCTI spec [1] in the > "3.2.5.2 receive" section

Re: [PATCH] tpm: add support for partial reads

2018-07-19 Thread James Bottomley
On Thu, 2018-07-19 at 08:52 -0700, Tadeusz Struk wrote: > Currently to read a response from the TPM device an application needs > provide "big enough" buffer for the whole response and read it in one > go. The application doesn't know how big the response it beforehand > so it always needs to

Re: linux-next: build warning after merge of the scsi tree

2018-07-10 Thread James Bottomley
On Tue, 2018-07-10 at 08:22 -0600, Jens Axboe wrote: > On 7/10/18 8:14 AM, James Bottomley wrote: > > On Tue, 2018-07-10 at 08:09 -0600, Jens Axboe wrote: > > > On 7/10/18 1:31 AM, Stephen Rothwell wrote: > > > > [...] > > > > I am still seeing these

Re: linux-next: build warning after merge of the scsi tree

2018-07-10 Thread James Bottomley
On Tue, 2018-07-10 at 08:09 -0600, Jens Axboe wrote: > On 7/10/18 1:31 AM, Stephen Rothwell wrote: [...] > > I am still seeing these warnings ... > > Martin queued up the forward declaration patch for this one, not sure > why it isn't showing up in the scsi tree yet. All the trees are fully up

[GIT PULL] SCSI fixes for 4.18-rc3

2018-07-06 Thread James Bottomley
This is two minor bug fixes (aacraid, target) and a fix for a potential exploit in the way sg handles teardown. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog is: David Disseldorp (1): scsi: target: Fix truncated

Re: [PATCH 2/2] KEYS: trusted: Find tpm_chip and use it until module shutdown

2018-07-03 Thread James Bottomley
On Wed, 2018-07-04 at 04:51 +1000, James Morris wrote: > On Tue, 3 Jul 2018, Jarkko Sakkinen wrote: > > > On Tue, Jul 03, 2018 at 08:26:55AM -0700, James Bottomley wrote: > > > > OK, I was not sure how that discussion went. I could add myself as > > co-maintainer t

Re: [PATCH 2/2] KEYS: trusted: Find tpm_chip and use it until module shutdown

2018-07-03 Thread James Bottomley
On Tue, 2018-07-03 at 18:24 +0300, Jarkko Sakkinen wrote: [...] > > Reviewed-by: Jarkko Sakkinen > > Is James maintaining this now? Have not seen his feedback yet... Hey, I thought we both were ... However, it looks fine to me Reviewed-by: James E.J. Bottomley James

Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries

2018-07-02 Thread James Bottomley
On Mon, 2018-07-02 at 14:18 -0700, Andrew Morton wrote: > On Mon, 2 Jul 2018 12:34:00 -0700 Linus Torvalds dation.org> wrote: > > > On Sun, Jul 1, 2018 at 10:52 PM Waiman Long > > wrote: > > > > > > A rogue application can potentially create a large number of > > > negative > > > dentries in

Re: [PATCH v3 0/2] tpm: add support for nonblocking operation

2018-06-20 Thread James Bottomley
On Wed, 2018-06-20 at 18:24 -0700, Tadeusz Struk wrote: > On 06/20/2018 04:59 PM, James Bottomley wrote: > > I'm slightly surprised by this statement.  I thought IoT Node.js > > runtimes (of which there are far too many, so I haven't looked at > > all of them) use libu

Re: [PATCH v3 0/2] tpm: add support for nonblocking operation

2018-06-20 Thread James Bottomley
On Tue, 2018-06-19 at 17:45 -0700, Tadeusz Struk wrote: > On 06/19/2018 06:10 AM, Jarkko Sakkinen wrote: > > On Tue, Jun 12, 2018 at 10:58:26AM -0700, Tadeusz Struk wrote: > > > The TCG SAPI specification [1] defines a set of functions, which > > > allows applications to use the TPM device in

[PATCH v3 1/1] shiftfs: uid/gid shifting bind mount

2018-06-15 Thread James Bottomley
subtrees (using the -o mark option as root). Once mounted, the subtree is mapped via the super block user namespace so that the interior ids of the mounting user namespace are the ids written to the filesystem. Signed-off-by: James Bottomley --- v3 - update to 4.14 (d_real changes) v1 - based

[PATCH v3 0/1] shiftfs: uid/gid shifting filesystem

2018-06-15 Thread James Bottomley
ost to use this, but it's not impossible to come up with a scheme for marking trees that can safely be shift mounted by unprivileged user namespaces. James --- James Bottomley (1): shiftfs: uid/gid shifting bind mount fs/Kconfig | 8 + fs/Makefile| 1 +

[GIT PULL] SCSI fixes for 4.17-rc6

2018-05-21 Thread James Bottomley
Two driver fixes (zfcp and target core), one information leak in sg and one build clean up. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog is: Alexander Potapenko (1): scsi: sg: allocate with __GFP_ZERO in

[GIT PULL] SCSI fixes for 4.17-rc5

2018-05-15 Thread James Bottomley
Two small driver fixes: aacraid to fix an unknown IU type on task management functions which causes a firmware fault and vmw_pvscsi to change a return code to retry the operation instead of causing an immediate error The patch is available here:

Re: [Ksummit-discuss] bug-introducing patches

2018-05-08 Thread James Bottomley
On Tue, 2018-05-08 at 21:43 +, Sasha Levin via Ksummit-discuss wrote: > On Tue, May 08, 2018 at 01:59:18PM -0700, David Lang wrote: > > On Tue, 8 May 2018, Sasha Levin wrote: > > > > > There's no one, for example, who picked up vanilla v4.16 and > > > plans to keep using it for a year. > > >

Re: [Ksummit-discuss] bug-introducing patches

2018-05-04 Thread James Bottomley
On Fri, 2018-05-04 at 17:13 -0400, Theodore Y. Ts'o wrote: > If it's not necessary, fine.  But we should still delete what is > currently documented in stable_kernel_rules and was introduced in > 8e9b9362266d, because it doesn't describe current practice. It definitely doesn't seem to describe

Re: [Ksummit-discuss] bug-introducing patches

2018-05-03 Thread James Bottomley
On Thu, 2018-05-03 at 15:43 +, Sasha Levin via Ksummit-discuss wrote: > On Thu, May 03, 2018 at 08:27:48AM -0700, James Bottomley wrote: [...] > > It's also a sad fact that a lot of things which look like obvious > > fixes actually turn out not to be so with later testing.  

Re: [Ksummit-discuss] bug-introducing patches

2018-05-03 Thread James Bottomley
On Thu, 2018-05-03 at 15:06 +, Sasha Levin via Ksummit-discuss wrote: > On Thu, May 03, 2018 at 04:48:50PM +0200, Willy Tarreau wrote: > > On Thu, May 03, 2018 at 07:33:04AM -0700, James Bottomley wrote: > > > They're definitely for bug fixes, but there's a spectrum: obvio

Re: [Ksummit-discuss] bug-introducing patches

2018-05-03 Thread James Bottomley
On Thu, 2018-05-03 at 14:08 +0300, Jani Nikula wrote: > On Tue, 01 May 2018, "Theodore Y. Ts'o" wrote: > > Post -rc3 or -rc4, in my opinion bug fixes should wait until the > > next > > merge window before they get merged at all. > > What are -rc5 and later for then if not bug

[GIT PULL] SCSI fixes for 4.17-rc3

2018-05-02 Thread James Bottomley
Three small bug fixes: an illegally overlapping memcmp in target code, a potential infinite loop in isci under certain rare phy conditions and an ATA queue depth (performance) correction for storvsc. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

2018-04-26 Thread James Bottomley
On Thu, 2018-04-26 at 11:05 -0400, Mikulas Patocka wrote: > > On Thu, 26 Apr 2018, James Bottomley wrote: [...] > > Perhaps find out beforehand instead of insisting on an approach > without > > knowing.  On openSUSE the grub config is built from the files in > > /etc

  1   2   3   4   5   6   7   8   9   10   >