* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Stephen Boyd @ 2019-08-01 21:14 UTC (permalink / raw)
To: Brendan Higgins
Cc: Petr Mladek, Jeff Dike, Kevin Hilman, Logan Gunthorpe,
Michael Ellerman, Daniel Vetter, Amir Goldstein, Frank Rowand,
Steven Rostedt, Kees Cook, David Rientjes, kunit-dev,
Kieran Bingham, Peter Zijlstra, Randy Dunlap, Joel Stanley,
Luis Chamberlain, Rob Herring, shuah, wfg, Greg KH, Julia Lawall,
linux-nvdimm, dri-devel, linux-um, Sasha Levin, Theodore Ts'o,
Richard Weinberger, Dan Carpenter, Knut Omang, Josh Poimboeuf,
Masahiro Yamada, Timothy Bird, John Ogness, devicetree,
open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAFd5g473iFfvBnJs2pcwuJYgY+DpgD6RLzyDFL1otUuScgKUag@mail.gmail.com>
Quoting Brendan Higgins (2019-08-01 11:59:57)
> On Thu, Aug 1, 2019 at 11:55 AM Brendan Higgins
> <brendanhiggins@google.com> wrote:
> >
> > On Fri, Jul 26, 2019 at 1:31 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > > To be honest I do not fully understand KUnit design. I am not
> > > completely sure how the tested code is isolated from the running
> > > system. Namely, I do not know if the tested code shares
> > > the same locks with the system running the test.
> >
> > No worries, I don't expect printk to be the hang up in those cases. It
> > sounds like KUnit has a long way to evolve before printk is going to
> > be a limitation.
>
> So Stephen, what do you think?
>
> Do you want me to go forward with the new kunit_assert API wrapping
> the string_stream as I have it now? Would you prefer to punt this to a
> later patch? Or would you prefer something else?
>
I like the struct based approach. If anything, it can be adjusted to
make the code throw some records into a spinlock later on and delay the
formatting of the assertion if need be. Can you resend with that
approach? I don't think I'll have any more comments after that.
^ permalink raw reply
* Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
From: Bjorn Andersson @ 2019-08-01 19:14 UTC (permalink / raw)
To: Fabien Dessenne
Cc: Ohad Ben-Cohen, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Jonathan Corbet, linux-remoteproc, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel, linux-doc,
Benjamin Gaignard
In-Reply-To: <1552492237-28810-1-git-send-email-fabien.dessenne@st.com>
On Wed 13 Mar 08:50 PDT 2019, Fabien Dessenne wrote:
> The current implementation does not allow two different devices to use
> a common hwspinlock. This patch set proposes to have, as an option, some
> hwspinlocks shared between several users.
>
> Below is an example that explain the need for this:
> exti: interrupt-controller@5000d000 {
> compatible = "st,stm32mp1-exti", "syscon";
> interrupt-controller;
> #interrupt-cells = <2>;
> reg = <0x5000d000 0x400>;
> hwlocks = <&hsem 1>;
> };
> The two drivers (stm32mp1-exti and syscon) refer to the same hwlock.
> With the current hwspinlock implementation, only the first driver succeeds
> in requesting (hwspin_lock_request_specific) the hwlock. The second request
> fails.
>
>
> The proposed approach does not modify the API, but extends the DT 'hwlocks'
> property with a second optional parameter (the first one identifies an
> hwlock) that specifies whether an hwlock is requested for exclusive usage
> (current behavior) or can be shared between several users.
> Examples:
> hwlocks = <&hsem 8>; Ref to hwlock #8 for exclusive usage
> hwlocks = <&hsem 8 0>; Ref to hwlock #8 for exclusive (0) usage
> hwlocks = <&hsem 8 1>; Ref to hwlock #8 for shared (1) usage
>
> As a constraint, the #hwlock-cells value must be 1 or 2.
> In the current implementation, this can have theorically any value but:
> - all of the exisiting drivers use the same value : 1.
> - the framework supports only one value : 1 (see implementation of
> of_hwspin_lock_simple_xlate())
> Hence, it shall not be a problem to restrict this value to 1 or 2 since
> it won't break any driver.
>
Hi Fabien,
Your series looks good, but it makes me wonder why the hardware locks
should be an exclusive resource.
How about just making all (specific) locks shared?
Regards,
Bjorn
> Fabien Dessenne (6):
> dt-bindings: hwlock: add support of shared locks
> hwspinlock: allow sharing of hwspinlocks
> dt-bindings: hwlock: update STM32 #hwlock-cells value
> ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
> ARM: dts: stm32: Add hwlock for irqchip on stm32mp157
> ARM: dts: stm32: hwlocks for GPIO for stm32mp157
>
> .../devicetree/bindings/hwlock/hwlock.txt | 27 +++++--
> .../bindings/hwlock/st,stm32-hwspinlock.txt | 6 +-
> Documentation/hwspinlock.txt | 10 ++-
> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 2 +
> arch/arm/boot/dts/stm32mp157c.dtsi | 10 +++
> drivers/hwspinlock/hwspinlock_core.c | 82 +++++++++++++++++-----
> drivers/hwspinlock/hwspinlock_internal.h | 2 +
> 7 files changed, 108 insertions(+), 31 deletions(-)
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-08-01 18:59 UTC (permalink / raw)
To: Stephen Boyd
Cc: Petr Mladek, Jeff Dike, Kevin Hilman, Logan Gunthorpe,
Michael Ellerman, Daniel Vetter, Amir Goldstein, Frank Rowand,
Steven Rostedt, Kees Cook, David Rientjes, kunit-dev,
Kieran Bingham, Peter Zijlstra, Randy Dunlap, Joel Stanley,
Luis Chamberlain, Rob Herring, shuah, wfg, Greg KH, Julia Lawall,
linux-nvdimm, dri-devel, linux-um, Sasha Levin, Theodore Ts'o,
Richard Weinberger, Dan Carpenter, Knut Omang, Josh Poimboeuf,
Masahiro Yamada, Timothy Bird, John Ogness, devicetree,
open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAFd5g46iAhDZ5C_chi7oYLVOkwcoj6+0nw+kPWuXhqWwWKd9jA@mail.gmail.com>
On Thu, Aug 1, 2019 at 11:55 AM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> On Fri, Jul 26, 2019 at 1:31 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > On Thu 2019-07-25 13:21:12, Brendan Higgins wrote:
> > > On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek <pmladek@suse.com> wrote:
> > > >
> > > > On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> > > > > Quoting Brendan Higgins (2019-07-22 15:30:49)
> > > > > > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > > > > >
> > > > > > >
> > > > > > > What's the calling context of the assertions and expectations? I still
> > > > > > > don't like the fact that string stream needs to allocate buffers and
> > > > > > > throw them into a list somewhere because the calling context matters
> > > > > > > there.
> > > > > >
> > > > > > The calling context is the same as before, which is anywhere.
> > > > >
> > > > > Ok. That's concerning then.
> > > > >
> > > > > >
> > > > > > > I'd prefer we just wrote directly to the console/log via printk
> > > > > > > instead. That way things are simple because we use the existing
> > > > > > > buffering path of printk, but maybe there's some benefit to the string
> > > > > > > stream that I don't see? Right now it looks like it builds a string and
> > > > > > > then dumps it to printk so I'm sort of lost what the benefit is over
> > > > > > > just writing directly with printk.
> > > > > >
> > > > > > It's just buffering it so the whole string gets printed uninterrupted.
> > > > > > If we were to print out piecemeal to printk, couldn't we have another
> > > > > > call to printk come in causing it to garble the KUnit message we are
> > > > > > in the middle of printing?
> > > > >
> > > > > Yes, printing piecemeal by calling printk many times could lead to
> > > > > interleaving of messages if something else comes in such as an interrupt
> > > > > printing something. Printk has some support to hold "records" but I'm
> > > > > not sure how that would work here because KERN_CONT talks about only
> > > > > being used early on in boot code. I haven't looked at printk in detail
> > > > > though so maybe I'm all wrong and KERN_CONT just works?
> > > >
> > > > KERN_CONT does not guarantee that the message will get printed
> > > > together. The pieces get interleaved with messages printed in
> > > > parallel.
> > > >
> > > > Note that KERN_CONT was originally really meant to be used only during
> > > > boot. It was later used more widely and ended in the best effort category.
> > > >
> > > > There were several attempts to make it more reliable. But it was
> > > > always either too complicated or error prone or both.
> > > >
> > > > You need to use your own buffering if you rely want perfect output.
> > > > The question is if it is really worth the complexity. Also note that
> > > > any buffering reduces the chance that the messages will reach
> > > > the console.
> > >
> > > Seems like that settles it then. Thanks!
> > >
> > > > BTW: There is a work in progress on a lockless printk ring buffer.
> > > > It will make printk() more secure regarding deadlocks. But it might
> > > > make transparent handling of continuous lines even more tricky.
> > > >
> > > > I guess that local buffering, before calling printk(), will be
> > > > even more important then. Well, it might really force us to create
> > > > an API for it.
> > >
> > > Cool! Can you CC me on that discussion?
> >
> > Adding John Oggness into CC.
> >
> > John, please CC Brendan Higgins on the patchsets eventually switching
> > printk() into the lockless buffer. The test framework is going to
> > do its own buffering to keep the related messages together.
> >
> > The lockless ringbuffer might make handling of related (partial)
> > lines worse or better. It might justify KUnit's extra buffering
> > or it might allow to get rid of it.
>
> Thanks for CC'ing me on the printk ringbuffer thread. It looks like it
> actually probably won't affect my needs for KUnit logging. The biggest
> reason I need some sort of buffering system is to be able to compose
> messages piece meal into a single message that will be printed out to
> the user as a single message with no messages from other printk
> callers printed out in the middle of mine.
>
> The prb does look interesting; however, it appears that to get the
> semantics that I need, I would have to put my entire message in a
> single data block and would consequently need to know the size of my
> message a priori, which is problematic. Consequently, it seems as
> though I will probably need to compose my entire message using my own
> buffering system.
>
> > > > Note that stroring the messages into the printk log is basically safe in any
> > > > context. It uses temporary per-CPU buffers for recursive messages and
> > > > in NMI. The only problem is panic() when some CPU gets stuck with the
> > > > lock taken. This will get solved by the lockless ringbuffer. Also
> > > > the temporary buffers will not be necessary any longer.
> > >
> > > Sure, I think Stephen's concern is all the supporting code that is
> > > involved. Not printk specifically. It just means a lot more of KUnit
> > > has to be IRQ safe.
> >
> > I see.
> >
> > BTW: I wonder if KUnit could reuse the existing seq_buf implementation
> > for buffering messages.
> >
> > I am sorry if it has already been proposed and rejected for some
> > reason. I might have missed it. Feel free to just point me to
> > same older mail.
>
> Yeah, we discussed it briefly here:
>
> https://lkml.org/lkml/2019/5/17/497
>
> Looks like I forgot to include my reasoning in the commit text, sorry
> about that.
>
> > > > Much bigger problems are with consoles. There are many of them. It
> > > > means a lot of code and more locks involved, including scheduler
> > > > locks. Note that console lock is a semaphore.
> > >
> > > That shouldn't affect us though, right? As long as we continue to use
> > > the printk interface?
> >
> > I guess that it should not affect KUnit.
> >
> > The only problem might be if the testing framework calls printk()
> > inside scheduler or console code. And only when the tested code
> > uses the same locks that will be used by the called printk().
>
> Yeah, well printk will not be our only problem in those instances.
>
> > To be honest I do not fully understand KUnit design. I am not
> > completely sure how the tested code is isolated from the running
> > system. Namely, I do not know if the tested code shares
> > the same locks with the system running the test.
>
> No worries, I don't expect printk to be the hang up in those cases. It
> sounds like KUnit has a long way to evolve before printk is going to
> be a limitation.
So Stephen, what do you think?
Do you want me to go forward with the new kunit_assert API wrapping
the string_stream as I have it now? Would you prefer to punt this to a
later patch? Or would you prefer something else?
Cheers
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-08-01 18:55 UTC (permalink / raw)
To: Petr Mladek
Cc: Jeff Dike, Kevin Hilman, Logan Gunthorpe, Michael Ellerman,
Daniel Vetter, Amir Goldstein, Frank Rowand, Steven Rostedt,
Kees Cook, David Rientjes, kunit-dev, Kieran Bingham,
Peter Zijlstra, Randy Dunlap, Joel Stanley, Luis Chamberlain,
Rob Herring, Stephen Boyd, shuah, wfg, Greg KH, Julia Lawall,
linux-nvdimm, dri-devel, linux-um, Sasha Levin, Theodore Ts'o,
Richard Weinberger, Dan Carpenter, Knut Omang, Josh Poimboeuf,
Masahiro Yamada, Timothy Bird, John Ogness, devicetree,
open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <20190726083148.d4gf57w2nt5k7t6n@pathway.suse.cz>
On Fri, Jul 26, 2019 at 1:31 AM Petr Mladek <pmladek@suse.com> wrote:
>
> On Thu 2019-07-25 13:21:12, Brendan Higgins wrote:
> > On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek <pmladek@suse.com> wrote:
> > >
> > > On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> > > > Quoting Brendan Higgins (2019-07-22 15:30:49)
> > > > > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > > > >
> > > > > >
> > > > > > What's the calling context of the assertions and expectations? I still
> > > > > > don't like the fact that string stream needs to allocate buffers and
> > > > > > throw them into a list somewhere because the calling context matters
> > > > > > there.
> > > > >
> > > > > The calling context is the same as before, which is anywhere.
> > > >
> > > > Ok. That's concerning then.
> > > >
> > > > >
> > > > > > I'd prefer we just wrote directly to the console/log via printk
> > > > > > instead. That way things are simple because we use the existing
> > > > > > buffering path of printk, but maybe there's some benefit to the string
> > > > > > stream that I don't see? Right now it looks like it builds a string and
> > > > > > then dumps it to printk so I'm sort of lost what the benefit is over
> > > > > > just writing directly with printk.
> > > > >
> > > > > It's just buffering it so the whole string gets printed uninterrupted.
> > > > > If we were to print out piecemeal to printk, couldn't we have another
> > > > > call to printk come in causing it to garble the KUnit message we are
> > > > > in the middle of printing?
> > > >
> > > > Yes, printing piecemeal by calling printk many times could lead to
> > > > interleaving of messages if something else comes in such as an interrupt
> > > > printing something. Printk has some support to hold "records" but I'm
> > > > not sure how that would work here because KERN_CONT talks about only
> > > > being used early on in boot code. I haven't looked at printk in detail
> > > > though so maybe I'm all wrong and KERN_CONT just works?
> > >
> > > KERN_CONT does not guarantee that the message will get printed
> > > together. The pieces get interleaved with messages printed in
> > > parallel.
> > >
> > > Note that KERN_CONT was originally really meant to be used only during
> > > boot. It was later used more widely and ended in the best effort category.
> > >
> > > There were several attempts to make it more reliable. But it was
> > > always either too complicated or error prone or both.
> > >
> > > You need to use your own buffering if you rely want perfect output.
> > > The question is if it is really worth the complexity. Also note that
> > > any buffering reduces the chance that the messages will reach
> > > the console.
> >
> > Seems like that settles it then. Thanks!
> >
> > > BTW: There is a work in progress on a lockless printk ring buffer.
> > > It will make printk() more secure regarding deadlocks. But it might
> > > make transparent handling of continuous lines even more tricky.
> > >
> > > I guess that local buffering, before calling printk(), will be
> > > even more important then. Well, it might really force us to create
> > > an API for it.
> >
> > Cool! Can you CC me on that discussion?
>
> Adding John Oggness into CC.
>
> John, please CC Brendan Higgins on the patchsets eventually switching
> printk() into the lockless buffer. The test framework is going to
> do its own buffering to keep the related messages together.
>
> The lockless ringbuffer might make handling of related (partial)
> lines worse or better. It might justify KUnit's extra buffering
> or it might allow to get rid of it.
Thanks for CC'ing me on the printk ringbuffer thread. It looks like it
actually probably won't affect my needs for KUnit logging. The biggest
reason I need some sort of buffering system is to be able to compose
messages piece meal into a single message that will be printed out to
the user as a single message with no messages from other printk
callers printed out in the middle of mine.
The prb does look interesting; however, it appears that to get the
semantics that I need, I would have to put my entire message in a
single data block and would consequently need to know the size of my
message a priori, which is problematic. Consequently, it seems as
though I will probably need to compose my entire message using my own
buffering system.
> > > Note that stroring the messages into the printk log is basically safe in any
> > > context. It uses temporary per-CPU buffers for recursive messages and
> > > in NMI. The only problem is panic() when some CPU gets stuck with the
> > > lock taken. This will get solved by the lockless ringbuffer. Also
> > > the temporary buffers will not be necessary any longer.
> >
> > Sure, I think Stephen's concern is all the supporting code that is
> > involved. Not printk specifically. It just means a lot more of KUnit
> > has to be IRQ safe.
>
> I see.
>
> BTW: I wonder if KUnit could reuse the existing seq_buf implementation
> for buffering messages.
>
> I am sorry if it has already been proposed and rejected for some
> reason. I might have missed it. Feel free to just point me to
> same older mail.
Yeah, we discussed it briefly here:
https://lkml.org/lkml/2019/5/17/497
Looks like I forgot to include my reasoning in the commit text, sorry
about that.
> > > Much bigger problems are with consoles. There are many of them. It
> > > means a lot of code and more locks involved, including scheduler
> > > locks. Note that console lock is a semaphore.
> >
> > That shouldn't affect us though, right? As long as we continue to use
> > the printk interface?
>
> I guess that it should not affect KUnit.
>
> The only problem might be if the testing framework calls printk()
> inside scheduler or console code. And only when the tested code
> uses the same locks that will be used by the called printk().
Yeah, well printk will not be our only problem in those instances.
> To be honest I do not fully understand KUnit design. I am not
> completely sure how the tested code is isolated from the running
> system. Namely, I do not know if the tested code shares
> the same locks with the system running the test.
No worries, I don't expect printk to be the hang up in those cases. It
sounds like KUnit has a long way to evolve before printk is going to
be a limitation.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Suren Baghdasaryan @ 2019-08-01 18:28 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, lizefan, Johannes Weiner, axboe, Dennis Zhou,
Dennis Zhou, Andrew Morton, linux-mm, linux-doc, LKML,
kernel-team, Nick Kralevich, Thomas Gleixner
In-Reply-To: <20190801095112.GA31381@hirez.programming.kicks-ass.net>
Hi Peter,
Thanks for sharing your thoughts. I understand your point and I tend
to agree with it. I originally designed this using watchdog as the
example of a critical system health signal and in the context of
mobile device memory pressure is critical but I agree that there are
more important things in life. I checked and your proposal to change
it to FIFO-1 should still work for our purposes. Will test to make
sure and reply to your patch. Couple clarifications in-line.
On Thu, Aug 1, 2019 at 2:51 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Jul 30, 2019 at 10:44:51AM -0700, Suren Baghdasaryan wrote:
> > On Tue, Jul 30, 2019 at 1:11 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Mon, Jul 29, 2019 at 06:33:10PM -0700, Suren Baghdasaryan wrote:
> > > > When a process creates a new trigger by writing into /proc/pressure/*
> > > > files, permissions to write such a file should be used to determine whether
> > > > the process is allowed to do so or not. Current implementation would also
> > > > require such a process to have setsched capability. Setting of psi trigger
> > > > thread's scheduling policy is an implementation detail and should not be
> > > > exposed to the user level. Remove the permission check by using _nocheck
> > > > version of the function.
> > > >
> > > > Suggested-by: Nick Kralevich <nnk@google.com>
> > > > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > > > ---
> > > > kernel/sched/psi.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
> > > > index 7acc632c3b82..ed9a1d573cb1 100644
> > > > --- a/kernel/sched/psi.c
> > > > +++ b/kernel/sched/psi.c
> > > > @@ -1061,7 +1061,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group *group,
> > > > mutex_unlock(&group->trigger_lock);
> > > > return ERR_CAST(kworker);
> > > > }
> > > > - sched_setscheduler(kworker->task, SCHED_FIFO, ¶m);
> > > > + sched_setscheduler_nocheck(kworker->task, SCHED_FIFO, ¶m);
> > >
> > > ARGGH, wtf is there a FIFO-99!! thread here at all !?
> >
> > We need psi poll_kworker to be an rt-priority thread so that psi
>
> There is a giant difference between 'needs to be higher than OTHER' and
> FIFO-99.
>
> > notifications are delivered to the userspace without delay even when
> > the CPUs are very congested. Otherwise it's easy to delay psi
> > notifications by running a simple CPU hogger executing "chrt -f 50 dd
> > if=/dev/zero of=/dev/null". Because these notifications are
>
> So what; at that point that's exactly what you're asking for. Using RT
> is for those who know what they're doing.
>
> > time-critical for reacting to memory shortages we can't allow for such
> > delays.
>
> Furthermore, actual RT programs will have pre-allocated and locked any
> memory they rely on. They don't give a crap about your pressure
> nonsense.
>
This signal is used not to protect other RT tasks but to monitor
overall system memory health for the sake of system responsiveness.
> > Notice that this kworker is created only if userspace creates a psi
> > trigger. So unless you are using psi triggers you will never see this
> > kthread created.
>
> By marking it FIFO-99 you're in effect saying that your stupid
> statistics gathering is more important than your life. It will preempt
> the task that's in control of the band-saw emergency break, it will
> preempt the task that's adjusting the electromagnetic field containing
> this plasma flow.
>
> That's insane.
IMHO an opt-in feature stops being "stupid" as soon as the user opted
in to use it, therefore explicitly indicating interest in it. However
I assume you are using "stupid" here to indicate that it's "less
important" rather than it's "useless".
> I'm going to queue a patch to reduce this to FIFO-1, that will preempt
> regular OTHER tasks but will not perturb (much) actual RT bits.
>
Thanks for posting the fix.
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>
^ permalink raw reply
* Re: [PATCH v4] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-08-01 17:43 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-kernel, linux-integrity, linux-doc, tweek, matthewgarrett,
jorhand, rdunlap, Sasha Levin
In-Reply-To: <20190731133948.1a527db8@lwn.net>
On Wed, Jul 31, 2019 at 01:39:48PM -0600, Jonathan Corbet wrote:
> On Fri, 12 Jul 2019 18:44:32 +0300
> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
>
> > There are some weird quirks when it comes to UEFI event log. Provide a
> > brief introduction to TPM event log mechanism and describe the quirks
> > and how they can be sorted out.
> >
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> > v4: - Unfortanely -> Unfortunately
> > v3: - Add a section for refs and use a bullet list to enumerate them.
> > - Remove an invalid author info.
> > v2: - Fix one typo.
> > - Refine the last paragraph to better explain how the two halves
> > of the event log are concatenated.
> > Documentation/security/tpm/index.rst | 1 +
> > Documentation/security/tpm/tpm_event_log.rst | 55 ++++++++++++++++++++
> > 2 files changed, 56 insertions(+)
> > create mode 100644 Documentation/security/tpm/tpm_event_log.rst
>
> I've applied this, thanks. Before I could do so, though, I had to edit
> the headers, which read:
>
> > Content-Type: text/plain; charset=y
>
> "git am" *really* doesn't like "charset=y". I think this is something
> that git send-email likes to do occasionally, don't know why...
Thank you!
/Jarkko
^ permalink raw reply
* Re: [PATCH v8 0/2] fTPM: firmware TPM running in TEE
From: Jarkko Sakkinen @ 2019-08-01 16:35 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Sasha Levin, peterhuewe, jgg, corbet, linux-kernel, linux-doc,
linux-integrity, linux-kernel, thiruan, bryankel, tee-dev,
sumit.garg, rdunlap
In-Reply-To: <20190715090525.GA28477@apalos>
On Mon, Jul 15, 2019 at 12:05:25PM +0300, Ilias Apalodimas wrote:
> On Fri, Jul 12, 2019 at 06:37:58AM +0300, Jarkko Sakkinen wrote:
> > On Thu, Jul 11, 2019 at 11:10:59PM +0300, Ilias Apalodimas wrote:
> > > Will report back any issues when we start using it on real hardware
> > > rather than QEMU
> > >
> > > Thanks
> > > /Ilias
> >
> > That would awesome. PR is far away so there is time to add more
> > tested-by's. Thanks.
> >
>
> I tested the basic fucntionality on QEMU and with the code only built as a
> module. You can add my tested-by on this if you want
Thank you. Added.
/Jarkko
^ permalink raw reply
* Re: [PATCH] doc:it_IT: translations for documents in process/
From: Jonathan Corbet @ 2019-08-01 14:00 UTC (permalink / raw)
To: Federico Vaga; +Cc: linux-doc, linux-kernel, Alessia Mantegazza
In-Reply-To: <1695846.t893fQQLz3@pcbe13614>
On Thu, 1 Aug 2019 11:53:06 +0200
Federico Vaga <federico.vaga@cern.ch> wrote:
> Of course, I checked on the version available on my distribution. I did not
> look for translation changes on different version of the same email client @_@
Hmm...normally we expect you to check all versions back to the 1991
release of the 0.01 kernel...:) I think that your diligence is more than
sufficiently due, thanks.
jon
^ permalink raw reply
* Re: [RFC v2 0/8] arm64: MMU enabled kexec relocation
From: Pavel Tatashin @ 2019-08-01 13:24 UTC (permalink / raw)
To: Pavel Tatashin, James Morris, Sasha Levin, Eric W. Biederman,
kexec mailing list, LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM, Marc Zyngier, James Morse,
Vladimir Murzin, Matthias Brugger, Bhupesh Sharma
In-Reply-To: <20190731153857.4045-1-pasha.tatashin@soleen.com>
I will send a new version soon, so please do not spend time reviewing
this work. In the new version I will fix MMU at EL2 issue by doing
what we are doing in hibernation: reduce to EL1 to do the copying, and
escalate back to to EL2 to branch to new kernel. Also, this will
simplify copying function by actually doing the linear copy as ttbr1
and ttbr0 are always available this way.
Thank you,
Pasha
On Wed, Jul 31, 2019 at 11:38 AM Pavel Tatashin
<pasha.tatashin@soleen.com> wrote:
>
> Changelog from previous RFC:
> - Added trans_table support for both hibernate and kexec.
> - Fixed performance issue, where enabling MMU did not yield the
> actual performance improvement.
>
> Bug:
> With the current state, this patch series works on kernels booted with EL1
> mode, but for some reason, when elevated to EL2 mode reboot freezes in
> both QEMU and on real hardware.
>
> The freeze happens in:
>
> arch/arm64/kernel/relocate_kernel.S
> turn_on_mmu()
>
> Right after sctlr_el2 is written (MMU on EL2 is enabled)
>
> msr sctlr_el2, \tmp1
>
> I've been studying all the relevant control registers for EL2, but do not
> see what might be causing this hang:
>
> MAIR_EL2 is set to be exactly the same as MAIR_EL1 0xbbff440c0400
>
> TCR_EL2 0x80843510
> Enabled bits:
> PS Physical Address Size. (0b100 44 bits, 16TB.)
> SH0 Shareability 11 Inner Shareable
> ORGN0 Normal memory, Outer Write-Back Read-Allocate Write-Allocate Cach.
> IRGN0 Normal memory, Inner Write-Back Read-Allocate Write-Allocate Cach.
> T0SZ 01 0000
>
> SCTLR_EL2 0x30e5183f
> RES1 : Reserve ones
> M : MMU enabled
> A : Align check
> C : Cacheability control
> SA : SP Alignment check enable
> IESB : Implicit Error Synchronization event
> I : Instruction access Cacheability
>
> TTBR0_EL2 0x1b3069000 (address of trans_table)
>
> Any suggestion of what else might be missing that causes this freeze when
> MMU is enabled in EL2?
>
> =====
> Here is the current data from the real hardware:
> (because of bug, I forced EL1 mode by setting el2_switch always to zero in
> cpu_soft_restart()):
>
> For this experiment, the size of kernel plus initramfs is 25M. If initramfs
> was larger, than the improvements would be even greater, as time spent in
> relocation is proportional to the size of relocation.
>
> Previously:
> kernel shutdown 0.022131328s
> relocation 0.440510736s
> kernel startup 0.294706768s
>
> Relocation was taking: 58.2% of reboot time
>
> Now:
> kernel shutdown 0.032066576s
> relocation 0.022158152s
> kernel startup 0.296055880s
>
> Now: Relocation takes 6.3% of reboot time
>
> Total reboot is x2.16 times faster.
>
> Previous approaches and discussions
> -----------------------------------
> https://lore.kernel.org/lkml/20190709182014.16052-1-pasha.tatashin@soleen.com
> reserve space for kexec to avoid relocation, involves changes to generic code
> to optimize a problem that exists on arm64 only:
>
> https://lore.kernel.org/lkml/20190716165641.6990-1-pasha.tatashin@soleen.com
> The first attempt to enable MMU, some bugs that prevented performance
> improvement. The page tables unnecessary configured idmap for the whole
> physical space.
>
> Pavel Tatashin (8):
> kexec: quiet down kexec reboot
> arm64, mm: transitional tables
> arm64: hibernate: switch to transtional page tables.
> kexec: add machine_kexec_post_load()
> arm64, kexec: move relocation function setup and clean up
> arm64, kexec: add expandable argument to relocation function
> arm64, kexec: configure transitional page table for kexec
> arm64, kexec: enable MMU during kexec relocation
>
> arch/arm64/Kconfig | 4 +
> arch/arm64/include/asm/kexec.h | 24 ++-
> arch/arm64/include/asm/pgtable-hwdef.h | 1 +
> arch/arm64/include/asm/trans_table.h | 66 ++++++
> arch/arm64/kernel/asm-offsets.c | 10 +
> arch/arm64/kernel/cpu-reset.S | 4 +-
> arch/arm64/kernel/cpu-reset.h | 8 +-
> arch/arm64/kernel/hibernate.c | 261 ++++++------------------
> arch/arm64/kernel/machine_kexec.c | 168 ++++++++++++---
> arch/arm64/kernel/relocate_kernel.S | 238 +++++++++++++++-------
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/trans_table.c | 272 +++++++++++++++++++++++++
> kernel/kexec.c | 4 +
> kernel/kexec_core.c | 8 +-
> kernel/kexec_file.c | 4 +
> kernel/kexec_internal.h | 2 +
> 16 files changed, 756 insertions(+), 319 deletions(-)
> create mode 100644 arch/arm64/include/asm/trans_table.h
> create mode 100644 arch/arm64/mm/trans_table.c
>
> --
> 2.22.0
>
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 10:40 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYOwcO5-cyaJf3tMMAdyVHJo=BzmCWtsjA3S8aj5g-GZxQ@mail.gmail.com>
On Thu, Aug 1, 2019 at 1:00 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > Here TEE isn't similar to a user-space crypto library. In our case TEE
> > > is based on ARM TrustZone which only allows TEE communications to be
> > > initiated from privileged mode. So why would you like to route
> > > communications via user-mode (which is less secure) when we have
> > > standardised TEE interface available in kernel?
> >
> > The physical access guards for reading/writing the involved critical
> > memory are identical as far as I know? Layered security is generally a
> > good thing, and the userspace pass actually adds a layer, so not sure
> > which is really safer?
>
> AFAIK, layered security is better in case we move from lower privilege
> level to higher privilege level rather than in reverse order.
You can look at this in many ways. Another way to look at it is that
the services should be provided with the least amount of permissions
required for the task. Further you can containerize something, the
better.
As for your PLATFORMS support: it is all nice, but there is no way to
convince op-tee or any other tee to be adopted by many real users.
Every serious user can and will do their own thing, or at very best,
buy it from someone who did their own thing and is trusted. There is
zero chance that samsung, huawei, apple, nsa, google, rambus, payment
system vendors, .. would actually share the tee (or probably even the
interfaces). It is just too vital and people do not trust each other
anymore :(
Anyway, enough about the topic from my side. I guess people will tell
what they want, I'm fine with any, and it is all progress from the
current state :)
--
Janne
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 10:27 UTC (permalink / raw)
To: Janne Karhunen
Cc: Rouven Czerwinski, tee-dev @ lists . linaro . org,
Daniel Thompson, Jonathan Corbet, jejb, Ard Biesheuvel,
Linux Doc Mailing List, Jarkko Sakkinen,
Linux Kernel Mailing List, dhowells, linux-security-module,
keyrings, Mimi Zohar, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <CAE=NcrbujsM8wYJXq+s=o5Vy1xY1b0uKYBGvp6UP5ex70HrB2Q@mail.gmail.com>
On Thu, 1 Aug 2019 at 14:00, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > Anyway, just my .02c. I guess having any new support in the kernel for
> > > new trust sources is good and improvement from the current state. I
> > > can certainly make my stuff work with your setup as well, what ever
> > > people think is the best.
> >
> > Yes your implementation can very well fit under trusted keys
> > abstraction framework without creating a new keytype: "ext-trusted".
>
> The fundamental problem with the 'standardized kernel tee' still
> exists - it will never be generic in real life. Getting all this in
> the kernel will solve your problem and sell this particular product,
> but it is quite unlikely to help that many users. If the security is
> truly important to you, would you really trust any of this code to
> someone else? In this day and age, I really doubt many do.
There are already multiple platforms supported by OP-TEE [1] which
could benefit from this trusted keys interface.
> Everyone
> does their own thing, so this is why I really see all that as a
> userspace problem.
>
IMO, we should try to use standardized interfaces which are well
thought off rather than implementing your own.
[1] https://optee.readthedocs.io/general/platforms.html
-Sumit
>
> --
> Janne
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 10:00 UTC (permalink / raw)
To: Janne Karhunen
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAE=Ncrae6pM+WBDu9eJ7Fw2Fkvf3_YqH5tj9Tt938D4RtWcdSQ@mail.gmail.com>
On Thu, 1 Aug 2019 at 13:30, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > I chose the userspace plugin due to this, you can use userspace aids
> > > to provide any type of service. Use the crypto library you desire to
> > > do the magic you want.
> >
> > Here TEE isn't similar to a user-space crypto library. In our case TEE
> > is based on ARM TrustZone which only allows TEE communications to be
> > initiated from privileged mode. So why would you like to route
> > communications via user-mode (which is less secure) when we have
> > standardised TEE interface available in kernel?
>
> The physical access guards for reading/writing the involved critical
> memory are identical as far as I know? Layered security is generally a
> good thing, and the userspace pass actually adds a layer, so not sure
> which is really safer?
>
AFAIK, layered security is better in case we move from lower privilege
level to higher privilege level rather than in reverse order.
-Sumit
> In my case the rerouting was to done generalize it. Any type of trust
> source, anywhere.
>
>
> > > > Isn't actual purpose to have trusted keys is to protect user-space
> > > > from access to kernel keys in plain format? Doesn't user mode helper
> > > > defeat that purpose in one way or another?
> > >
> > > Not really. CPU is in the user mode while running the code, but the
> > > code or the secure keydata being is not available to the 'normal'
> > > userspace. It's like microkernel service/driver this way. The usermode
> > > driver is part of the kernel image and it runs on top of a invisible
> > > rootfs.
> >
> > Can you elaborate here with an example regarding how this user-mode
> > helper will securely communicate with a hardware based trust source
> > with other user-space processes denied access to that trust source?
>
> The other user mode processes will never see the device node to open.
> There is none in existence for them; it only exists in the ramfs based
> root for the user mode helper.
>
>
> --
> Janne
^ permalink raw reply
* Re: [PATCH] doc:it_IT: translations for documents in process/
From: Federico Vaga @ 2019-08-01 9:53 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-kernel, Alessia Mantegazza
In-Reply-To: <20864529.Q1CKeA7GMu@pcbe13614>
On Thursday, August 1, 2019 11:37:58 AM CEST Federico Vaga wrote:
> On Wednesday, July 31, 2019 8:51:24 PM CEST Jonathan Corbet wrote:
> > On Sun, 28 Jul 2019 11:20:54 +0200
> >
> > Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > > From: Alessia Mantegazza <amantegazza@vaga.pv.it>
> > >
> > > Translations for the following documents in process/:
> > > - email-clients
> > > - management-style
> > >
> > > Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it>
> > > Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
> >
> > This looks generally good, but I have to ask...
> >
> > > +Se la patch che avete inserito dev'essere modificata usato la finestra
> > > di
> > > +scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia
> > > +disabilitata
> > >
> > > :menuselection:`Configurazione-->Preferenze-->Composizione-->Interruzion
> > > :e
> > >
> > > riga`.
> >
> > Have you actually verified that the translations used in these mail
> > clients matches what you have here?
>
> Yep, I've installed all of them and gone through all menus.
P.S.
Of course, I checked on the version available on my distribution. I did not
look for translation changes on different version of the same email client @_@
But even if I do it, there is no "nice" solution to the problem
> But I just noticed a typo in the quoted statement, I will send a new patch:
>
> "modificata usato" -> "modificata usando"
>
> > Thanks,
> >
> > jon
^ permalink raw reply
* Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Peter Zijlstra @ 2019-08-01 9:51 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Ingo Molnar, lizefan, Johannes Weiner, axboe, Dennis Zhou,
Dennis Zhou, Andrew Morton, linux-mm, linux-doc, LKML,
kernel-team, Nick Kralevich, Thomas Gleixner
In-Reply-To: <CAJuCfpH7NpuYKv-B9-27SpQSKhkzraw0LZzpik7_cyNMYcqB2Q@mail.gmail.com>
On Tue, Jul 30, 2019 at 10:44:51AM -0700, Suren Baghdasaryan wrote:
> On Tue, Jul 30, 2019 at 1:11 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, Jul 29, 2019 at 06:33:10PM -0700, Suren Baghdasaryan wrote:
> > > When a process creates a new trigger by writing into /proc/pressure/*
> > > files, permissions to write such a file should be used to determine whether
> > > the process is allowed to do so or not. Current implementation would also
> > > require such a process to have setsched capability. Setting of psi trigger
> > > thread's scheduling policy is an implementation detail and should not be
> > > exposed to the user level. Remove the permission check by using _nocheck
> > > version of the function.
> > >
> > > Suggested-by: Nick Kralevich <nnk@google.com>
> > > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > > ---
> > > kernel/sched/psi.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
> > > index 7acc632c3b82..ed9a1d573cb1 100644
> > > --- a/kernel/sched/psi.c
> > > +++ b/kernel/sched/psi.c
> > > @@ -1061,7 +1061,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group *group,
> > > mutex_unlock(&group->trigger_lock);
> > > return ERR_CAST(kworker);
> > > }
> > > - sched_setscheduler(kworker->task, SCHED_FIFO, ¶m);
> > > + sched_setscheduler_nocheck(kworker->task, SCHED_FIFO, ¶m);
> >
> > ARGGH, wtf is there a FIFO-99!! thread here at all !?
>
> We need psi poll_kworker to be an rt-priority thread so that psi
There is a giant difference between 'needs to be higher than OTHER' and
FIFO-99.
> notifications are delivered to the userspace without delay even when
> the CPUs are very congested. Otherwise it's easy to delay psi
> notifications by running a simple CPU hogger executing "chrt -f 50 dd
> if=/dev/zero of=/dev/null". Because these notifications are
So what; at that point that's exactly what you're asking for. Using RT
is for those who know what they're doing.
> time-critical for reacting to memory shortages we can't allow for such
> delays.
Furthermore, actual RT programs will have pre-allocated and locked any
memory they rely on. They don't give a crap about your pressure
nonsense.
> Notice that this kworker is created only if userspace creates a psi
> trigger. So unless you are using psi triggers you will never see this
> kthread created.
By marking it FIFO-99 you're in effect saying that your stupid
statistics gathering is more important than your life. It will preempt
the task that's in control of the band-saw emergency break, it will
preempt the task that's adjusting the electromagnetic field containing
this plasma flow.
That's insane.
I'm going to queue a patch to reduce this to FIFO-1, that will preempt
regular OTHER tasks but will not perturb (much) actual RT bits.
^ permalink raw reply
* Re: [PATCH] doc:it_IT: translations for documents in process/
From: Federico Vaga @ 2019-08-01 9:37 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-kernel, Alessia Mantegazza
In-Reply-To: <20190731125124.46e06ab6@lwn.net>
On Wednesday, July 31, 2019 8:51:24 PM CEST Jonathan Corbet wrote:
> On Sun, 28 Jul 2019 11:20:54 +0200
>
> Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > From: Alessia Mantegazza <amantegazza@vaga.pv.it>
> >
> > Translations for the following documents in process/:
> > - email-clients
> > - management-style
> >
> > Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it>
> > Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
>
> This looks generally good, but I have to ask...
>
> > +Se la patch che avete inserito dev'essere modificata usato la finestra di
> > +scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia
> > +disabilitata
> > :menuselection:`Configurazione-->Preferenze-->Composizione-->Interruzione
> > riga`.
> Have you actually verified that the translations used in these mail
> clients matches what you have here?
Yep, I've installed all of them and gone through all menus.
But I just noticed a typo in the quoted statement, I will send a new patch:
"modificata usato" -> "modificata usando"
>
> Thanks,
>
> jon
--
Federico Vaga
http://www.federicovaga.it/
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 8:30 UTC (permalink / raw)
To: Sumit Garg
Cc: Rouven Czerwinski, tee-dev @ lists . linaro . org,
Daniel Thompson, Jonathan Corbet, jejb, Ard Biesheuvel,
Linux Doc Mailing List, Jarkko Sakkinen,
Linux Kernel Mailing List, dhowells, linux-security-module,
keyrings, Mimi Zohar, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <CAFA6WYPt4q+jaJbaoauXKr2qKgBHvtQ663s4t=W3nuPJPe2xpw@mail.gmail.com>
On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > Anyway, just my .02c. I guess having any new support in the kernel for
> > new trust sources is good and improvement from the current state. I
> > can certainly make my stuff work with your setup as well, what ever
> > people think is the best.
>
> Yes your implementation can very well fit under trusted keys
> abstraction framework without creating a new keytype: "ext-trusted".
The fundamental problem with the 'standardized kernel tee' still
exists - it will never be generic in real life. Getting all this in
the kernel will solve your problem and sell this particular product,
but it is quite unlikely to help that many users. If the security is
truly important to you, would you really trust any of this code to
someone else? In this day and age, I really doubt many do. Everyone
does their own thing, so this is why I really see all that as a
userspace problem.
--
Janne
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 7:59 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYMOXQbL5OeheFUFpTr8gte8XHHr-71-h8+qX0+R_sekDQ@mail.gmail.com>
On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > I chose the userspace plugin due to this, you can use userspace aids
> > to provide any type of service. Use the crypto library you desire to
> > do the magic you want.
>
> Here TEE isn't similar to a user-space crypto library. In our case TEE
> is based on ARM TrustZone which only allows TEE communications to be
> initiated from privileged mode. So why would you like to route
> communications via user-mode (which is less secure) when we have
> standardised TEE interface available in kernel?
The physical access guards for reading/writing the involved critical
memory are identical as far as I know? Layered security is generally a
good thing, and the userspace pass actually adds a layer, so not sure
which is really safer?
In my case the rerouting was to done generalize it. Any type of trust
source, anywhere.
> > > Isn't actual purpose to have trusted keys is to protect user-space
> > > from access to kernel keys in plain format? Doesn't user mode helper
> > > defeat that purpose in one way or another?
> >
> > Not really. CPU is in the user mode while running the code, but the
> > code or the secure keydata being is not available to the 'normal'
> > userspace. It's like microkernel service/driver this way. The usermode
> > driver is part of the kernel image and it runs on top of a invisible
> > rootfs.
>
> Can you elaborate here with an example regarding how this user-mode
> helper will securely communicate with a hardware based trust source
> with other user-space processes denied access to that trust source?
The other user mode processes will never see the device node to open.
There is none in existence for them; it only exists in the ramfs based
root for the user mode helper.
--
Janne
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 7:58 UTC (permalink / raw)
To: Janne Karhunen
Cc: Rouven Czerwinski, tee-dev @ lists . linaro . org,
Daniel Thompson, Jonathan Corbet, jejb, Ard Biesheuvel,
Linux Doc Mailing List, Jarkko Sakkinen,
Linux Kernel Mailing List, dhowells, linux-security-module,
keyrings, Mimi Zohar, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <CAE=NcraqD9FNM0Gk9UGhPGi3heVzZrAKGc1gNZxoe1OnDaQ=pA@mail.gmail.com>
On Thu, 1 Aug 2019 at 13:00, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski
> <r.czerwinski@pengutronix.de> wrote:
>
> > > I'm aware of it - I have implemented a large part of the GP TEE APIs
> > > earlier (primarily the crypto functions). Does the TEE you work with
> > > actually support GP properly? Can I take a look at the code?
> >
> > AFAIK Sumit is working with the OP-TEE implementation, which can be
> > found on github: https://github.com/op-tee/optee_os
>
> Thanks, I will take a look.
For documentation, refer to: https://optee.readthedocs.io/
> The fundamental problem with these things
> is that there are infinite amount of ways how TEEs and ROTs can be
> done in terms of the hardware and software. I really doubt there are 2
> implementations in existence that are even remotely compatible in real
> life.
I agree with you regarding implementation specific nature of TEE but
having a standardized client interface does solves the problem.
> As such, all things TEE/ROT would logically really belong in the
> userland and thanks to the bpfilter folks now the umh logic really
> makes that possible ... I think. The key implementation I did was just
> an RFC on the concept, what if we start to move the stuff that really
> belongs in the userspace to this pseudo-userland. It's not kernel, but
> it's not commonly accessible userland either. The shared memory would
> also work without any modifications between the umh based TEE/ROT
> driver and the userland if needed.
>
> Anyway, just my .02c. I guess having any new support in the kernel for
> new trust sources is good and improvement from the current state. I
> can certainly make my stuff work with your setup as well, what ever
> people think is the best.
Yes your implementation can very well fit under trusted keys
abstraction framework without creating a new keytype: "ext-trusted".
-Sumit
>
>
> --
> Janne
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 7:40 UTC (permalink / raw)
To: Janne Karhunen
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAE=NcraDkm5cxE=ceq_9XkQz=NZ6KdVXkNUsdD4G2LrWz-bpDw@mail.gmail.com>
On Thu, 1 Aug 2019 at 11:51, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > To clarify a bit further - my thought was to support any type of trust
> > > source.
> >
> > That could be very well accomplished via Trusted Keys abstraction
> > framework [1]. A trust source just need to implement following APIs:
> >
> > struct trusted_key_ops ts_trusted_key_ops = {
> > .migratable = 0, /* non-migratable */
> > .init = init_ts_trusted,
> > .seal = ts_key_seal,
> > .unseal = ts_key_unseal,
> > .get_random = ts_get_random,
> > .cleanup = cleanup_ts_trusted,
> > };
>
> Which is basically the same as implementing a new keytype in the
> kernel; abstraction is not raised in any considerable manner this way?
>
It doesn't create a new keytype. There is only single keytype:
"trusted" which could be implemented via one of the trust source
available in the system like TPM, TEE etc.
> I chose the userspace plugin due to this, you can use userspace aids
> to provide any type of service. Use the crypto library you desire to
> do the magic you want.
Here TEE isn't similar to a user-space crypto library. In our case TEE
is based on ARM TrustZone which only allows TEE communications to be
initiated from privileged mode. So why would you like to route
communications via user-mode (which is less secure) when we have
standardised TEE interface available in kernel?
>
>
> > > With the
> > > user mode helper in between anyone can easily add their own thing in
> > > there.
> >
> > Isn't actual purpose to have trusted keys is to protect user-space
> > from access to kernel keys in plain format? Doesn't user mode helper
> > defeat that purpose in one way or another?
>
> Not really. CPU is in the user mode while running the code, but the
> code or the secure keydata being is not available to the 'normal'
> userspace. It's like microkernel service/driver this way. The usermode
> driver is part of the kernel image and it runs on top of a invisible
> rootfs.
>
Can you elaborate here with an example regarding how this user-mode
helper will securely communicate with a hardware based trust source
with other user-space processes denied access to that trust source?
-Sumit
>
> --
> Janne
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 7:30 UTC (permalink / raw)
To: Rouven Czerwinski
Cc: Sumit Garg, tee-dev @ lists . linaro . org, Daniel Thompson,
Jonathan Corbet, jejb, Ard Biesheuvel, Linux Doc Mailing List,
Jarkko Sakkinen, Linux Kernel Mailing List, dhowells,
linux-security-module, keyrings, Mimi Zohar, Casey Schaufler,
linux-integrity, linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <19d9be198619e951750dedeb4d0a7f372083b42c.camel@pengutronix.de>
On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski
<r.czerwinski@pengutronix.de> wrote:
> > I'm aware of it - I have implemented a large part of the GP TEE APIs
> > earlier (primarily the crypto functions). Does the TEE you work with
> > actually support GP properly? Can I take a look at the code?
>
> AFAIK Sumit is working with the OP-TEE implementation, which can be
> found on github: https://github.com/op-tee/optee_os
Thanks, I will take a look. The fundamental problem with these things
is that there are infinite amount of ways how TEEs and ROTs can be
done in terms of the hardware and software. I really doubt there are 2
implementations in existence that are even remotely compatible in real
life. As such, all things TEE/ROT would logically really belong in the
userland and thanks to the bpfilter folks now the umh logic really
makes that possible ... I think. The key implementation I did was just
an RFC on the concept, what if we start to move the stuff that really
belongs in the userspace to this pseudo-userland. It's not kernel, but
it's not commonly accessible userland either. The shared memory would
also work without any modifications between the umh based TEE/ROT
driver and the userland if needed.
Anyway, just my .02c. I guess having any new support in the kernel for
new trust sources is good and improvement from the current state. I
can certainly make my stuff work with your setup as well, what ever
people think is the best.
--
Janne
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Rouven Czerwinski @ 2019-08-01 6:50 UTC (permalink / raw)
To: Janne Karhunen, Sumit Garg
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
jejb, Ard Biesheuvel, Linux Doc Mailing List, Jarkko Sakkinen,
Linux Kernel Mailing List, dhowells, linux-security-module,
keyrings, Mimi Zohar, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <CAE=NcrYz8bT9zDhS_ZcvY84fpeTDxZ-KhJKeQGGyf=o4pG2J-Q@mail.gmail.com>
On Thu, 2019-08-01 at 09:36 +0300, Janne Karhunen wrote:
> On Wed, Jul 31, 2019 at 5:23 PM Sumit Garg <sumit.garg@linaro.org>
> wrote:
>
> > > I guess my wording was wrong, tried to say that physical TEEs in
> > > the
> > > wild vary massively hardware wise. Generalizing these things is
> > > rough.
> > >
> >
> > There are already well defined GlobalPlatform Standards to
> > generalize
> > the TEE interface. One of them is GlobalPlatform TEE Client API [1]
> > which provides the basis for this TEE interface.
>
> I'm aware of it - I have implemented a large part of the GP TEE APIs
> earlier (primarily the crypto functions). Does the TEE you work with
> actually support GP properly? Can I take a look at the code?
AFAIK Sumit is working with the OP-TEE implementation, which can be
found on github: https://github.com/op-tee/optee_os
Regards,
Rouven
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 6:36 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYOKcOzSwakHhgshZcebD8ZBMSi7xQdjWYFS79=Xc+odOg@mail.gmail.com>
On Wed, Jul 31, 2019 at 5:23 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > I guess my wording was wrong, tried to say that physical TEEs in the
> > wild vary massively hardware wise. Generalizing these things is rough.
> >
>
> There are already well defined GlobalPlatform Standards to generalize
> the TEE interface. One of them is GlobalPlatform TEE Client API [1]
> which provides the basis for this TEE interface.
I'm aware of it - I have implemented a large part of the GP TEE APIs
earlier (primarily the crypto functions). Does the TEE you work with
actually support GP properly? Can I take a look at the code?
Normally the TEE implementations are well-guarded secrets and the
state of the implementation is quite random. In many cases keeping
things secret is fine from my point of view, given that it is a RoT
after all. The secrecy is the core business here. So, this is why I
opted the userspace 'secret' route - no secrets in the kernel, but
it's fine for the userspace. Umh was a logical fit to implement it.
--
Janne
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 6:21 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYOEqe1a1DCyVYKA+oZaZ0n5hnjxdubstUnrwdUW1-4xHw@mail.gmail.com>
On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > To clarify a bit further - my thought was to support any type of trust
> > source.
>
> That could be very well accomplished via Trusted Keys abstraction
> framework [1]. A trust source just need to implement following APIs:
>
> struct trusted_key_ops ts_trusted_key_ops = {
> .migratable = 0, /* non-migratable */
> .init = init_ts_trusted,
> .seal = ts_key_seal,
> .unseal = ts_key_unseal,
> .get_random = ts_get_random,
> .cleanup = cleanup_ts_trusted,
> };
Which is basically the same as implementing a new keytype in the
kernel; abstraction is not raised in any considerable manner this way?
I chose the userspace plugin due to this, you can use userspace aids
to provide any type of service. Use the crypto library you desire to
do the magic you want.
> > With the
> > user mode helper in between anyone can easily add their own thing in
> > there.
>
> Isn't actual purpose to have trusted keys is to protect user-space
> from access to kernel keys in plain format? Doesn't user mode helper
> defeat that purpose in one way or another?
Not really. CPU is in the user mode while running the code, but the
code or the secure keydata being is not available to the 'normal'
userspace. It's like microkernel service/driver this way. The usermode
driver is part of the kernel image and it runs on top of a invisible
rootfs.
--
Janne
^ permalink raw reply
* Re: [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Jaegeuk Kim @ 2019-08-01 4:05 UTC (permalink / raw)
To: Chao Yu
Cc: Nathan Chancellor, Daniel Rosenberg, Jonathan Corbet,
linux-f2fs-devel, linux-kernel, linux-doc, linux-fsdevel,
linux-api, kernel-team
In-Reply-To: <5d6c5da8-ad1e-26e2-0a3d-84949cd4e9aa@huawei.com>
On 08/01, Chao Yu wrote:
> Hi Nathan,
>
> Thanks for the report! :)
>
> On 2019/8/1 1:57, Nathan Chancellor wrote:
> > Hi all,
> >
> > <snip>
> >
> >> diff --git a/fs/f2fs/hash.c b/fs/f2fs/hash.c
> >> index cc82f142f811f..99e79934f5088 100644
> >> --- a/fs/f2fs/hash.c
> >> +++ b/fs/f2fs/hash.c
> >> @@ -14,6 +14,7 @@
> >> #include <linux/f2fs_fs.h>
> >> #include <linux/cryptohash.h>
> >> #include <linux/pagemap.h>
> >> +#include <linux/unicode.h>
> >>
> >> #include "f2fs.h"
> >>
> >> @@ -67,7 +68,7 @@ static void str2hashbuf(const unsigned char *msg, size_t len,
> >> *buf++ = pad;
> >> }
> >>
> >> -f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
> >> +static f2fs_hash_t __f2fs_dentry_hash(const struct qstr *name_info,
> >> struct fscrypt_name *fname)
> >> {
> >> __u32 hash;
> >> @@ -103,3 +104,35 @@ f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
> >> f2fs_hash = cpu_to_le32(hash & ~F2FS_HASH_COL_BIT);
> >> return f2fs_hash;
> >> }
> >> +
> >> +f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
> >> + const struct qstr *name_info, struct fscrypt_name *fname)
> >> +{
> >> +#ifdef CONFIG_UNICODE
> >> + struct f2fs_sb_info *sbi = F2FS_SB(dir->i_sb);
> >> + const struct unicode_map *um = sbi->s_encoding;
> >> + int r, dlen;
> >> + unsigned char *buff;
> >> + struct qstr *folded;
> >> +
> >> + if (name_info->len && IS_CASEFOLDED(dir)) {
> >> + buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
> >> + if (!buff)
> >> + return -ENOMEM;
> >> +
> >> + dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
> >> + if (dlen < 0) {
> >> + kvfree(buff);
> >> + goto opaque_seq;
> >> + }
> >> + folded->name = buff;
> >> + folded->len = dlen;
> >> + r = __f2fs_dentry_hash(folded, fname);
> >> +
> >> + kvfree(buff);
> >> + return r;
> >> + }
> >> +opaque_seq:
> >> +#endif
> >> + return __f2fs_dentry_hash(name_info, fname);
> >> +}
> >
> > Clang now warns:
> >
> > fs/f2fs/hash.c:128:3: warning: variable 'folded' is uninitialized when used here [-Wuninitialized]
> > folded->name = buff;
> > ^~~~~~
> > fs/f2fs/hash.c:116:21: note: initialize the variable 'folded' to silence this warning
> > struct qstr *folded;
> > ^
> > = NULL
> > 1 warning generated.
> >
> > I assume that it wants to be initialized with f2fs_kzalloc as well but
> > I am not familiar with this code and what it expects to do.
> >
> > Please look into this when you get a chance!
>
> That should be a bug, it needs to define a struct qstr type variable rather than
> a pointer there.
>
> Jaegeuk, could you fix this in you branch?
Yeah, let me apply this.
--- a/fs/f2fs/hash.c
+++ b/fs/f2fs/hash.c
@@ -113,25 +113,27 @@ f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
const struct unicode_map *um = sbi->s_encoding;
int r, dlen;
unsigned char *buff;
- struct qstr *folded;
+ struct qstr folded;
- if (name_info->len && IS_CASEFOLDED(dir)) {
- buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
- if (!buff)
- return -ENOMEM;
+ if (!name_info->len || !IS_CASEFOLDED(dir))
+ goto opaque_seq;
- dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
- if (dlen < 0) {
- kvfree(buff);
- goto opaque_seq;
- }
- folded->name = buff;
- folded->len = dlen;
- r = __f2fs_dentry_hash(folded, fname);
+ buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
+ if (!buff)
+ return -ENOMEM;
+ dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
+ if (dlen < 0) {
kvfree(buff);
- return r;
+ goto opaque_seq;
}
+ folded.name = buff;
+ folded.len = dlen;
+ r = __f2fs_dentry_hash(&folded, fname);
+
+ kvfree(buff);
+ return r;
+
opaque_seq:
#endif
return __f2fs_dentry_hash(name_info, fname);
^ permalink raw reply
* Re: [PATCH] mailmap: add entry for Gao Xiang
From: Gao Xiang @ 2019-08-01 3:31 UTC (permalink / raw)
To: Chao Yu, corbet; +Cc: linux-doc, chao, Miao Xie
In-Reply-To: <20190801031750.17094-1-yuchao0@huawei.com>
On 2019/8/1 11:17, Chao Yu wrote:
> Add entry to connect all Gao Xiang's email addresses.
>
> Signed-off-by: Chao Yu <yuchao0@huawei.com>
Acked-by: Gao Xiang <gaoxiang25@huawei.com>
Thanks,
Gao Xiang
^ 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