Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski 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
Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
On Thu, 1 Aug 2019 at 11:51, Janne Karhunen wrote:
>
> On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg 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
Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
On Thu, 1 Aug 2019 at 13:00, Janne Karhunen wrote: > > On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski > 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
Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg 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
Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg 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
Re: [PATCH] doc:it_IT: translations for documents in process/
On Wednesday, July 31, 2019 8:51:24 PM CEST Jonathan Corbet wrote: > On Sun, 28 Jul 2019 11:20:54 +0200 > > Federico Vaga wrote: > > From: Alessia Mantegazza > > > > Translations for the following documents in process/: > > - email-clients > > - management-style > > > > Signed-off-by: Alessia Mantegazza > > Signed-off-by: Federico Vaga > > 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/
Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
On Tue, Jul 30, 2019 at 10:44:51AM -0700, Suren Baghdasaryan wrote: > On Tue, Jul 30, 2019 at 1:11 AM Peter Zijlstra 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 > > > Signed-off-by: Suren Baghdasaryan > > > --- > > > 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.
Re: [PATCH] doc:it_IT: translations for documents in process/
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 wrote: > > > From: Alessia Mantegazza > > > > > > Translations for the following documents in process/: > > > - email-clients > > > - management-style > > > > > > Signed-off-by: Alessia Mantegazza > > > Signed-off-by: Federico Vaga > > > > 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
Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
On Thu, 1 Aug 2019 at 13:30, Janne Karhunen wrote: > > On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg 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
Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
On Thu, 1 Aug 2019 at 14:00, Janne Karhunen wrote: > > On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg 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
Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
On Thu, Aug 1, 2019 at 1:00 PM Sumit Garg 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
Re: [PATCH] doc:it_IT: translations for documents in process/
On Thu, 1 Aug 2019 11:53:06 +0200 Federico Vaga 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
Re: [PATCH v8 0/2] fTPM: firmware TPM running in TEE
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
Re: [PATCH v4] tpm: Document UEFI event log quirks
On Wed, Jul 31, 2019 at 01:39:48PM -0600, Jonathan Corbet wrote: > On Fri, 12 Jul 2019 18:44:32 +0300 > Jarkko Sakkinen 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 > > --- > > 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
Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
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 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 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 > > > > Signed-off-by: Suren Baghdasaryan > > > > --- > > > > 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+unsubscr...@android.com. >
Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
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
>
Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
On Thu, Aug 01, 2019 at 11:28:30AM -0700, Suren Baghdasaryan wrote: > > 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". Quite; PSI does have its uses. RT just isn't one of them.
Re: [PATCH v2 2/2] idr: Document that ida_simple_{get,remove}() are deprecated
On Tue, Jul 30, 2019 at 2:20 PM Stephen Boyd wrote: > > These two functions are deprecated. Users should call ida_alloc() or > ida_free() respectively instead. Add documentation to this effect until > the macro can be removed. > > Cc: Greg KH > Cc: Tri Vo > Cc: Jonathan Corbet > Cc: linux-doc@vger.kernel.org > Signed-off-by: Stephen Boyd Reviewed-by: Tri Vo
Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
On Thu, Aug 1, 2019 at 2:59 PM Peter Zijlstra wrote: > > On Thu, Aug 01, 2019 at 11:28:30AM -0700, Suren Baghdasaryan wrote: > > > 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". > > Quite; PSI does have its uses. RT just isn't one of them. Sorry about messing it up in the first place. If you don't see any issues with my patch replacing sched_setscheduler() with sched_setscheduler_nocheck(), would you mind taking it too? I applied it over your patch onto Linus' ToT with no merge conflicts. Thanks, Suren. > -- > To unsubscribe from this group and stop receiving emails from it, send an > email to kernel-team+unsubscr...@android.com. >
[PATCH] mailmap: add entry for Jaegeuk Kim
Add entry to connect all Jaegeuk's email addresses. Acked-by: Jaegeuk Kim Signed-off-by: Chao Yu --- .mailmap | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.mailmap b/.mailmap index 477debe3d960..70d41c86e644 100644 --- a/.mailmap +++ b/.mailmap @@ -89,6 +89,9 @@ Henrik Kretzschmar Henrik Rydberg Herbert Xu Jacob Shin +Jaegeuk Kim +Jaegeuk Kim +Jaegeuk Kim James Bottomley James Bottomley James E Wilson -- 2.18.0.rc1
Re: [PATCH] Documentation/admin-guide: Embargoed hardware security issues
Hi Greg, Thomas, On Thu, Jul 25, 2019 at 03:01:13PM +0200, Greg Kroah-Hartman wrote: > +The list is encrypted and email to the list can be sent by either PGP or > +S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME > +certificate. The list's PGP key and S/MIME certificate are available from > +https://www.kernel.org/ Just thinking, wouldn't it be useful to strongly encourage that the document should be in plain text format ? Otherwise the door remains open for sending you a self-extractable EXE file which contains an encrypted Word doc, which is not the most useful to handle especially to copy-paste mitigation code nor to comment on. Even some occasional PDFs we've seen on the sec@k.o list were sometimes quite detailed but less convenient than the vast majority of plain text ones, particularly when it comes to quoting some parts. Just my two cents, Willy
[PATCH] Documentation/checkpatch: Prefer str_has_prefix over strncmp
Add strncmp() to Documentation/process/deprecated.rst since using strncmp() to check whether a string starts with a prefix is error-prone. The safe replacement is str_has_prefix(). Also add check to the newly introduced deprecated_string_apis in checkpatch.pl. This patch depends on patch: "Documentation/checkpatch: Prefer stracpy/strscpy over strcpy/strlcpy/strncpy." Signed-off-by: Chuhong Yuan --- Documentation/process/deprecated.rst | 8 scripts/checkpatch.pl| 1 + 2 files changed, 9 insertions(+) diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index 56280e108d5a..22d3f0dbcf61 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -109,6 +109,14 @@ the given limit of bytes to copy. This is inefficient and can lead to linear read overflows if a source string is not NUL-terminated. The safe replacement is stracpy() or strscpy(). +strncmp() +- +:c:func:`strncmp` is often used to test if a string starts with a prefix +by strncmp(str, prefix, length of prefix). This is error-prone because +length of prefix can have counting error if using a constant length, or use +sizeof(prefix) without - 1. Also, if the prefix is a pointer, sizeof(prefix) +leads to a wrong size. The safe replacement is str_has_prefix(). + Variable Length Arrays (VLAs) - Using stack VLAs produces much worse machine code than statically diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 0ae9ae01d855..38e82d2ac286 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -609,6 +609,7 @@ our %deprecated_string_apis = ( "strcpy"=> "stracpy or strscpy", "strlcpy" => "stracpy or strscpy", "strncpy" => "stracpy or strscpy - for non-NUL-terminated uses, strncpy dest should be __nonstring", + "strncmp" => "str_has_prefix", ); #Create a search pattern for all these strings apis to speed up a loop below -- 2.20.1
Re: [PATCH] Documentation/admin-guide: Embargoed hardware security issues
On Fri, Aug 02, 2019 at 06:49:08AM +0200, Willy Tarreau wrote: > Hi Greg, Thomas, > > On Thu, Jul 25, 2019 at 03:01:13PM +0200, Greg Kroah-Hartman wrote: > > +The list is encrypted and email to the list can be sent by either PGP or > > +S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME > > +certificate. The list's PGP key and S/MIME certificate are available from > > +https://www.kernel.org/ > > Just thinking, wouldn't it be useful to strongly encourage that the > document should be in plain text format ? Otherwise the door remains open > for sending you a self-extractable EXE file which contains an encrypted > Word doc, which is not the most useful to handle especially to copy-paste > mitigation code nor to comment on. Even some occasional PDFs we've seen > on the sec@k.o list were sometimes quite detailed but less convenient > than the vast majority of plain text ones, particularly when it comes > to quoting some parts. What document are you referring to here? This just describes how the encrypted mailing list is going to work, not anything else. But yes, we have had some "encrypted pdfs" be sent to us recently that no one can decrypt unless they run Windows or do some really crazy hacks with the gstreamer pipeline. But that's separate from this specific mailing list, we can always just tell people to not do foolish things if that happens again (like we did in this case.) thanks, greg k-h
