Re: [PATCH AUTOSEL 5.8 18/24] net: usb: rtl8150: set random MAC address when set_ethernet_addr() fails

On 20-10-12 12:11:18, Joe Perches wrote: > On Mon, 2020-10-12 at 15:02 -0400, Sasha Levin wrote: > > From: Anant Thazhemadam > > > > [ Upstream commit f45a4248ea4cc13ed50618ff066849f9587226b2 ] > > > > When get_registers() fails in set_ethernet_addr(),the uninitialized > > value of node_id gets

Re: [PATCH v2] net: usb: rtl8150: don't incorrectly assign random MAC addresses

On 20-10-11 11:33:00, Joe Perches wrote: > On Sun, 2020-10-11 at 10:59 -0700, Jakub Kicinski wrote: > > On Sun, 11 Oct 2020 23:00:30 +0530 Anant Thazhemadam wrote: > > > In set_ethernet_addr(), if get_registers() succeeds, the ethernet address > > > that was read must be copied over. Otherwise, a

Re: [PATCH v2] net: usb: rtl8150: prevent set_ethernet_addr from setting uninit address

On 20-10-02 17:35:25, Anant Thazhemadam wrote: > > Yes, this clears things up for me. I'll see to it that this gets done in a v3. If set_ethernet_addr() fail, don't return error, but use eth_hw_addr_random() instead to set random MAC address and continue with the probing. You can take a look

Re: [Linux-kernel-mentees][PATCH] net: usb: rtl8150: prevent set_ethernet_addr from setting uninit address

ove check to: if (ret == sizeof(node_id)) { and fail in any other case. Apart from this minor detail the rest of the patch looks good to me. Acked-by: Petko Manolov

Re: [PATCH 3/4] net: usb: rtl8150: use usb_control_msg_recv() and usb_control_msg_send()

On 20-09-24 13:09:05, Oliver Neukum wrote: > Am Mittwoch, den 23.09.2020, 17:48 +0300 schrieb Petko Manolov: > > > One possible fix is to add yet another argument to usb_control_msg_recv(), > > which would be the GFP_XYZ flag to pass on to kmemdup(). Up to Greg, of > >

Re: [PATCH 3/4] net: usb: rtl8150: use usb_control_msg_recv() and usb_control_msg_send()

On 20-09-23 12:22:37, Oliver Neukum wrote: > Am Mittwoch, den 23.09.2020, 14:35 +0530 schrieb Himadri Pandya: > > Hi, > > > Many usage of usb_control_msg() do not have proper error check on return > > value leaving scope for bugs on short reads. New usb_control_msg_recv() > > and

Re: [Linux-kernel-mentees][PATCH] rtl8150: set memory to all 0xFFs on failed register reads

On 20-09-16 10:35:40, Anant Thazhemadam wrote: > get_registers() copies whatever memory is written by the > usb_control_msg() call even if the underlying urb call ends up failing. Not true, memcpy() is only called if "ret" is positive. > If get_registers() fails, or ends up reading 0 bytes,

Re: [Linux-kernel-mentees][PATCH] rtl8150: set memory to all 0xFFs on failed register reads

On 20-09-16 08:22:27, Greg KH wrote: > On Wed, Sep 16, 2020 at 10:35:40AM +0530, Anant Thazhemadam wrote: > > get_registers() copies whatever memory is written by the > > usb_control_msg() call even if the underlying urb call ends up failing. > > > > If get_registers() fails, or ends up reading 0

Re: [PATCH] net: usb: pegasus: use new api ethtool_{get|set}_link_ksettings

ng fine on real hardware. Acked-by: Petko Manolov <pet...@nucleusys.com> cheers, Petko > Signed-off-by: Philippe Reynes <trem...@gmail.com> > --- > drivers/net/usb/pegasus.c | 14 -- > 1 files changed, 8 insertions(+), 6 deletions(-) > > diff --git

Re: [PATCH] net: usb: pegasus: use new api ethtool_{get|set}_link_ksettings

ng fine on real hardware. Acked-by: Petko Manolov cheers, Petko > Signed-off-by: Philippe Reynes > --- > drivers/net/usb/pegasus.c | 14 -- > 1 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.

Re: [PATCH] net: usb: rtl8150: use new api ethtool_{get|set}_link_ksettings

On 17-03-13 17:00:20, Petko Manolov wrote: > On 17-03-12 23:16:25, Philippe Reynes wrote: > > The ethtool api {get|set}_settings is deprecated. We move this driver to > > new > > api {get|set}_link_ksettings. > > > > As I don't have the hardware, I'd be

Re: [PATCH] net: usb: rtl8150: use new api ethtool_{get|set}_link_ksettings

On 17-03-13 17:00:20, Petko Manolov wrote: > On 17-03-12 23:16:25, Philippe Reynes wrote: > > The ethtool api {get|set}_settings is deprecated. We move this driver to > > new > > api {get|set}_link_ksettings. > > > > As I don't have the hardware, I'd be

Re: [PATCH] net: usb: rtl8150: use new api ethtool_{get|set}_link_ksettings

On 17-03-12 23:16:25, Philippe Reynes wrote: > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > As I don't have the hardware, I'd be very pleased if someone may test this > patch. I've got some old adapters around and will drop you

Re: [PATCH] net: usb: rtl8150: use new api ethtool_{get|set}_link_ksettings

On 17-03-12 23:16:25, Philippe Reynes wrote: > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > As I don't have the hardware, I'd be very pleased if someone may test this > patch. I've got some old adapters around and will drop you

Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring

On 16-11-17 09:56:00, David Howells wrote: > Petko Manolov <pet...@mip-labs.com> wrote: > > > On 16-11-16 18:11:13, David Howells wrote: > > > Allow keys to be added to the system secondary certificates keyring > > > during > > > kernel initiali

Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring

On 16-11-17 09:56:00, David Howells wrote: > Petko Manolov wrote: > > > On 16-11-16 18:11:13, David Howells wrote: > > > Allow keys to be added to the system secondary certificates keyring > > > during > > > kernel initialisation in an unrestricted fa

Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring

On 16-11-16 18:11:13, David Howells wrote: > Allow keys to be added to the system secondary certificates keyring during > kernel initialisation in an unrestricted fashion. Such keys are implicitly > trusted and don't have their trust chains checked on link. Well, I for one do not explicitly

Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring

On 16-11-16 18:11:13, David Howells wrote: > Allow keys to be added to the system secondary certificates keyring during > kernel initialisation in an unrestricted fashion. Such keys are implicitly > trusted and don't have their trust chains checked on link. Well, I for one do not explicitly

Re: [PATCH] net: pegasus: Remove deprecated create_singlethread_workqueue

t; Since there are fixed number of work items, explicit concurrency >> limit is unnecessary here. >> >> Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> > >Acked-by: Tejun Heo <t...@kernel.org> > >Thanks. Acked-by: Petko Manolov <pet...@mip-labs.com> cheers, Petko

Re: [PATCH] net: pegasus: Remove deprecated create_singlethread_workqueue

xed number of work items, explicit concurrency >> limit is unnecessary here. >> >> Signed-off-by: Bhaktipriya Shridhar > >Acked-by: Tejun Heo > >Thanks. Acked-by: Petko Manolov cheers, Petko

Re: [PATCH] net: pegasus: Remove deprecated create_singlethread_workqueue

On 16-08-30 22:02:47, Bhaktipriya Shridhar wrote: > The workqueue "pegasus_workqueue" queues a single work item per pegasus > instance and hence it doesn't require execution ordering. Hence, > alloc_workqueue has been used to replace the deprecated > create_singlethread_workqueue instance. > >

Re: [PATCH] net: pegasus: Remove deprecated create_singlethread_workqueue

On 16-08-30 22:02:47, Bhaktipriya Shridhar wrote: > The workqueue "pegasus_workqueue" queues a single work item per pegasus > instance and hence it doesn't require execution ordering. Hence, > alloc_workqueue has been used to replace the deprecated > create_singlethread_workqueue instance. > >

Re: [Linux-ima-devel] [PATCH 1/7] ima: on soft reboot, restore the measurement list

On 16-08-10 14:40:13, David Laight wrote: > From: Linuxppc-dev > [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On > Behalf Of > > > > So given what you have above, you'd use something like: > > > > > > > > struct ima_kexec_hdr { > > > > u16 version; > > > >

Re: [Linux-ima-devel] [PATCH 1/7] ima: on soft reboot, restore the measurement list

On 16-08-10 14:40:13, David Laight wrote: > From: Linuxppc-dev > [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On > Behalf Of > > > > So given what you have above, you'd use something like: > > > > > > > > struct ima_kexec_hdr { > > > > u16 version; > > > >

Re: [Linux-ima-devel] [PATCH 1/7] ima: on soft reboot, restore the measurement list

On 16-08-10 08:54:36, Mimi Zohar wrote: > On Wed, 2016-08-10 at 19:52 +1000, Michael Ellerman wrote: > > Thiago Jung Bauermann writes: > > > > > Am Mittwoch, 10 August 2016, 13:41:08 schrieb Michael Ellerman: > > >> Thiago Jung Bauermann

Re: [Linux-ima-devel] [PATCH 1/7] ima: on soft reboot, restore the measurement list

On 16-08-10 08:54:36, Mimi Zohar wrote: > On Wed, 2016-08-10 at 19:52 +1000, Michael Ellerman wrote: > > Thiago Jung Bauermann writes: > > > > > Am Mittwoch, 10 August 2016, 13:41:08 schrieb Michael Ellerman: > > >> Thiago Jung Bauermann writes: > > >> > Am Dienstag, 09 August 2016, 09:01:13

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

On 16-08-05 09:34:38, Mimi Zohar wrote: > Hi Petko, > > Thank you for review! > > On Fri, 2016-08-05 at 11:44 +0300, Petko Manolov wrote: > > On 16-08-04 08:24:29, Mimi Zohar wrote: > > > The TPM PCRs are only reset on a hard reboot. In order to validate a > &g

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

On 16-08-05 09:34:38, Mimi Zohar wrote: > Hi Petko, > > Thank you for review! > > On Fri, 2016-08-05 at 11:44 +0300, Petko Manolov wrote: > > On 16-08-04 08:24:29, Mimi Zohar wrote: > > > The TPM PCRs are only reset on a hard reboot. In order to validate a > &g

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

On 16-08-04 08:24:29, Mimi Zohar wrote: > The TPM PCRs are only reset on a hard reboot. In order to validate a > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list > of the running kernel must be saved and restored on boot. This patch > restores the measurement list. > >

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

On 16-08-04 08:24:29, Mimi Zohar wrote: > The TPM PCRs are only reset on a hard reboot. In order to validate a > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list > of the running kernel must be saved and restored on boot. This patch > restores the measurement list. > >

Re: [PATCH] net: pegasus: remove unused variables and labels

Guys, come on. This code is not dead. This code is executed every time an ethernet packet is received. It takes care of various error statistics. More importantly, it sends the actual (reported by the adapter) packet length to the network layer along with the packet. This patch removes

Re: [PATCH] net: pegasus: remove unused variables and labels

Guys, come on. This code is not dead. This code is executed every time an ethernet packet is received. It takes care of various error statistics. More importantly, it sends the actual (reported by the adapter) packet length to the network layer along with the packet. This patch removes

Re: [PATCH 1/1] net: pegasus: remove dead coding

On 16-05-19 11:35:42, David Miller wrote: > From: Heinrich Schuchardt > Date: Wed, 18 May 2016 02:13:30 +0200 > > > (!count || count < 4) is always true. > > So let's remove the coding which is dead at least since 2005. > > > > Signed-off-by: Heinrich Schuchardt

Re: [PATCH 1/1] net: pegasus: remove dead coding

On 16-05-19 11:35:42, David Miller wrote: > From: Heinrich Schuchardt > Date: Wed, 18 May 2016 02:13:30 +0200 > > > (!count || count < 4) is always true. > > So let's remove the coding which is dead at least since 2005. > > > > Signed-off-by: Heinrich Schuchardt > > Applied. David, the patch

Re: [PATCH 1/1] net: pegasus: simplify logical constraint

On 16-05-18 20:40:51, Heinrich Schuchardt wrote: > If !count is true, count < 4 is also true. Yep, you're right. However, gcc optimizes away the first condition. What you really got me to think about is whether 4 is the right number. I guess i shall refer to the HW documentation.

Re: [PATCH 1/1] net: pegasus: simplify logical constraint

On 16-05-18 20:40:51, Heinrich Schuchardt wrote: > If !count is true, count < 4 is also true. Yep, you're right. However, gcc optimizes away the first condition. What you really got me to think about is whether 4 is the right number. I guess i shall refer to the HW documentation.

Re: [1/1] net: pegasus: remove dead coding

On 16-05-18 09:15:40, Oliver Neukum wrote: > On Tue, 2016-05-17 at 23:30 -0700, Guenter Roeck wrote: > > On Wed, May 18, 2016 at 02:13:30AM +0200, Heinrich Schuchardt wrote: > > > (!count || count < 4) is always true. > > > > Even if count >= 4 ? > > The check for !count is redundant, though.

Re: [1/1] net: pegasus: remove dead coding

On 16-05-18 09:15:40, Oliver Neukum wrote: > On Tue, 2016-05-17 at 23:30 -0700, Guenter Roeck wrote: > > On Wed, May 18, 2016 at 02:13:30AM +0200, Heinrich Schuchardt wrote: > > > (!count || count < 4) is always true. > > > > Even if count >= 4 ? > > The check for !count is redundant, though.

Re: [PATCH 1/1] net: pegasus: remove dead coding

On 16-05-18 02:13:30, Heinrich Schuchardt wrote: > (!count || count < 4) is always true. > So let's remove the coding which is dead at least since 2005. You may want to reconsider the above statement. Just assume that 'count' is typically between 56 and 1514 bytes. Petko >

Re: [PATCH 1/1] net: pegasus: remove dead coding

On 16-05-18 02:13:30, Heinrich Schuchardt wrote: > (!count || count < 4) is always true. > So let's remove the coding which is dead at least since 2005. You may want to reconsider the above statement. Just assume that 'count' is typically between 56 and 1514 bytes. Petko >

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

On 16-03-08 16:07:00, David Howells wrote: > Petko Manolov <pet...@mip-labs.com> wrote: > > > > How about I change it to a choice-type item, with the following options: > > > > > > (1) No addition. > > > > > > (2) Addition restricted b

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

On 16-03-08 16:07:00, David Howells wrote: > Petko Manolov wrote: > > > > How about I change it to a choice-type item, with the following options: > > > > > > (1) No addition. > > > > > > (2) Addition restricted by built-in keyring. > &g

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

On 16-03-08 14:44:24, David Howells wrote: > Petko Manolov <pet...@mip-labs.com> wrote: > > > I would suggest leaving (1) and (3). > > Do you mean dropping option (2) and leaving (1) and (3)? Or do you mean > dropping options (1) and (3)? Dropping option (2) a

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

On 16-03-08 14:44:24, David Howells wrote: > Petko Manolov wrote: > > > I would suggest leaving (1) and (3). > > Do you mean dropping option (2) and leaving (1) and (3)? Or do you mean > dropping options (1) and (3)? Dropping option (2) and leaving (1) and (3). (2) is s

Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically [ver #2]

On 16-03-08 13:13:59, David Howells wrote: > Mimi Zohar wrote: > > > but we're left with a lot of references to "system_trusted" (eg. > > restrict_link_to_system_trusted, depends on SYSTEM_TRUSTED_KEYRING > > How about I pluralise it to SYSTEM_TRUSTED_KEYRINGS? The

Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically [ver #2]

On 16-03-08 13:13:59, David Howells wrote: > Mimi Zohar wrote: > > > but we're left with a lot of references to "system_trusted" (eg. > > restrict_link_to_system_trusted, depends on SYSTEM_TRUSTED_KEYRING > > How about I pluralise it to SYSTEM_TRUSTED_KEYRINGS? The fact that one is > called

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

On 16-03-08 13:08:36, David Howells wrote: > Mimi Zohar wrote: > > > Only certificates signed by a key on the system keyring were added to > > the IMA keyring, unless IMA_MOK_KEYRING was configured. Then, the > > certificate could be signed by a either a key on the

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

On 16-03-08 13:08:36, David Howells wrote: > Mimi Zohar wrote: > > > Only certificates signed by a key on the system keyring were added to > > the IMA keyring, unless IMA_MOK_KEYRING was configured. Then, the > > certificate could be signed by a either a key on the system or ima_mok > >

Re: [RFC PATCH 00/20] KEYS: Restrict additions to 'trusted' keyrings [ver #2]

I assume this is intended for 4.6 or later, correct? Petko On 16-01-19 11:30:26, David Howells wrote: > > Here's a set of patches that changes how certificates/keys are determined > to be trusted. That's currently a two-step process: > > (1) Up until recently, when an X.509

Re: [RFC PATCH 00/20] KEYS: Restrict additions to 'trusted' keyrings [ver #2]

I assume this is intended for 4.6 or later, correct? Petko On 16-01-19 11:30:26, David Howells wrote: > > Here's a set of patches that changes how certificates/keys are determined > to be trusted. That's currently a two-step process: > > (1) Up until recently, when an X.509

Re: [RFC PATCH] X.509: Don't check the signature on apparently self-signed keys [ver #2]

On 16-01-06 13:21:27, David Howells wrote: > Mimi Zohar wrote: > > > The x509_validate_trust() was originally added for IMA to ensure, on a > > secure boot system, a certificate chain of trust rooted in hardware. The > > IMA > > MOK keyring extends this certificate chain of trust to the

Re: [RFC PATCH] X.509: Don't check the signature on apparently self-signed keys [ver #2]

On 16-01-06 13:21:27, David Howells wrote: > Mimi Zohar wrote: > > > The x509_validate_trust() was originally added for IMA to ensure, on a > > secure boot system, a certificate chain of trust rooted in hardware. The > > IMA > > MOK keyring extends this certificate

Re: [RFC PATCH] X.509: Don't check the signature on apparently self-signed keys [ver #2]

On 16-01-05 16:40:31, David Howells wrote: > Mimi Zohar wrote: > > > You're missing Petko's patch: > > 41c89b6 IMA: create machine owner and blacklist keyrings > > It should also be cc'd to the keyrings mailing list. Right. If i am not terribly mistaken there's no way to revoke a certificate

Re: [RFC PATCH] X.509: Don't check the signature on apparently self-signed keys [ver #2]

On 16-01-05 16:40:31, David Howells wrote: > Mimi Zohar wrote: > > > You're missing Petko's patch: > > 41c89b6 IMA: create machine owner and blacklist keyrings > > It should also be cc'd to the keyrings mailing list. Right. If i am not terribly mistaken there's no

Re: linux-next: manual merge of the security tree with the vfs tree

On 16-01-01 04:34:16, Al Viro wrote: > On Thu, Dec 31, 2015 at 12:45:35PM +0200, Petko Manolov wrote: > > > I introduced the write mutex when ima_write_policy() stopped being > > serialized by > > other means. Come to think about it the semaphore could be

Re: linux-next: manual merge of the security tree with the vfs tree

On 16-01-01 04:34:16, Al Viro wrote: > On Thu, Dec 31, 2015 at 12:45:35PM +0200, Petko Manolov wrote: > > > I introduced the write mutex when ima_write_policy() stopped being > > serialized by > > other means. Come to think about it the semaphore could be

Re: linux-next: manual merge of the security tree with the vfs tree

On 15-12-31 04:30:19, Al Viro wrote: > On Thu, Dec 31, 2015 at 03:24:53PM +1100, Stephen Rothwell wrote: > > Hi James, > > > > Today's linux-next merge of the security tree got a conflict in: > > > > security/integrity/ima/ima_fs.c > > > > between commit: > > > > 3bc8f29b149e ("new helper:

Re: linux-next: manual merge of the security tree with the vfs tree

On 15-12-31 04:30:19, Al Viro wrote: > On Thu, Dec 31, 2015 at 03:24:53PM +1100, Stephen Rothwell wrote: > > Hi James, > > > > Today's linux-next merge of the security tree got a conflict in: > > > > security/integrity/ima/ima_fs.c > > > > between commit: > > > > 3bc8f29b149e ("new helper:

Re: [PATCH] IMA: policy can be updated zero times

On 15-12-22 16:50:01, Sasha Levin wrote: > On 12/22/2015 04:40 PM, Petko Manolov wrote: > >> Thanks, Sasha. By the time ima_update_policy() is called > >> >ima_release_policy() has already output the policy update status > >> >message. I guess an empty polic

Re: [PATCH] IMA: policy can be updated zero times

On 15-12-22 16:50:01, Sasha Levin wrote: > On 12/22/2015 04:40 PM, Petko Manolov wrote: > >> Thanks, Sasha. By the time ima_update_policy() is called > >> >ima_release_policy() has already output the policy update status > >> >message. I guess an empty polic

Re: [PATCH] IMA: policy can be updated zero times

On December 22, 2015 9:56:28 PM GMT+02:00, Mimi Zohar wrote: >On Tue, 2015-12-22 at 08:51 -0500, Sasha Levin wrote: >> Commit "IMA: policy can now be updated multiple times" assumed that >the >> policy would be updated at least once. >> >> If there are zero updates, the temporary list head

Re: [PATCH] IMA: policy can be updated zero times

On December 22, 2015 9:56:28 PM GMT+02:00, Mimi Zohar wrote: >On Tue, 2015-12-22 at 08:51 -0500, Sasha Levin wrote: >> Commit "IMA: policy can now be updated multiple times" assumed that >the >> policy would be updated at least once. >> >> If there are zero updates,

Re: [PATCHv3 1/6] integrity: define '.evm' as a builtin 'trusted' keyring

On 15-10-23 14:43:53, Mimi Zohar wrote: > On Fri, 2015-10-23 at 16:05 +0300, Petko Manolov wrote: > > On 15-10-22 21:49:25, Dmitry Kasatkin wrote: > > > > diff --git a/security/integrity/ima/Kconfig > > > b/security/integrity/ima/Kconfig > > > index df303

Re: [PATCHv3 1/6] integrity: define '.evm' as a builtin 'trusted' keyring

On 15-10-23 14:43:53, Mimi Zohar wrote: > On Fri, 2015-10-23 at 16:05 +0300, Petko Manolov wrote: > > On 15-10-22 21:49:25, Dmitry Kasatkin wrote: > > > > diff --git a/security/integrity/ima/Kconfig > > > b/security/integrity/ima/Kconfig > > > index df303

Re: [PATCHv3 1/6] integrity: define '.evm' as a builtin 'trusted' keyring

On 15-10-22 21:49:25, Dmitry Kasatkin wrote: > Require all keys added to the EVM keyring be signed by an > existing trusted key on the system trusted keyring. > > This patch also switches IMA to use integrity_init_keyring(). > > Changes in v3: > * Added 'init_keyring' config based variable to

Re: [PATCHv3 1/6] integrity: define '.evm' as a builtin 'trusted' keyring

On 15-10-22 21:49:25, Dmitry Kasatkin wrote: > Require all keys added to the EVM keyring be signed by an > existing trusted key on the system trusted keyring. > > This patch also switches IMA to use integrity_init_keyring(). > > Changes in v3: > * Added 'init_keyring' config based variable to

Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

On 15-10-21 13:02:48, Mimi Zohar wrote: > On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote: > > Here's a set of patches that changes how keys are determined to be trusted > > - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon > > it. A keyring can then have a flag set

Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

On 15-10-21 13:02:48, Mimi Zohar wrote: > On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote: > > Here's a set of patches that changes how keys are determined to be trusted > > - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon > > it. A keyring can then have a flag set

Re: [PATCH 1/3] X.509: Fix certificate gathering again

On May 26, 2015 7:15:38 PM GMT+03:00, David Howells wrote: >Hi Michal, > >Could you have a look at the patch at the end of my branch: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7 > >It changes things from picking up arbitrary *.x509 files

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-26 18:08:13, One Thousand Gnomes wrote: > On Thu, 21 May 2015 18:53:19 +0300 > Petko Manolov wrote: > > > It is device's job to verify firmware's correctness. It is user's job to > > verify vendor's identity. Two different things, not related to each other. >

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-26 18:08:13, One Thousand Gnomes wrote: On Thu, 21 May 2015 18:53:19 +0300 Petko Manolov pet...@mip-labs.com wrote: It is device's job to verify firmware's correctness. It is user's job to verify vendor's identity. Two different things, not related to each other. The device

Re: [PATCH 1/3] X.509: Fix certificate gathering again

On May 26, 2015 7:15:38 PM GMT+03:00, David Howells dhowe...@redhat.com wrote: Hi Michal, Could you have a look at the patch at the end of my branch: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7 It changes things from picking up arbitrary

Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

On 15-05-22 08:28:17, Mimi Zohar wrote: > On Fri, 2015-05-22 at 08:48 +0100, David Howells wrote: > > Luis R. Rodriguez wrote: > > > > > > This is similar to what i am doing right now - create CA hierarchy so > > > > we can > > > > have something like: > > > > > > > >

Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

On 15-05-22 08:28:17, Mimi Zohar wrote: On Fri, 2015-05-22 at 08:48 +0100, David Howells wrote: Luis R. Rodriguez mcg...@suse.com wrote: This is similar to what i am doing right now - create CA hierarchy so we can have something like: +-

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 09:55:42, Andy Lutomirski wrote: > > I read plenty of the code. I said "data" not "file" for a reason. > I'll quote some code: > > int ima_appraise_measurement(int func, struct integrity_iint_cache *iint, > struct file *file, const unsigned char

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 10:02:36, gre...@linuxfoundation.org wrote: > On Thu, May 21, 2015 at 04:03:02PM +, Woodhouse, David wrote: > > > > In a lot of cases we have loadable firmware precisely to allow us to > > reduce the cost of the hardware. Adding cryptographic capability in the > > 'load firmware'

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 09:48:10, Andy Lutomirski wrote: > On Thu, May 21, 2015 at 9:43 AM, Petko Manolov wrote: > > On 15-05-21 16:51:49, David Howells wrote: > >> > >> I do have patches to parse PGP key data and add the public keys found > >> therein > >>

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 09:39:50, Andy Lutomirski wrote: > > It's also a performance cost because the average user of this signature stuff > doesn't actually want IMA, and IMA is checking the wrong think anyway. > IMA/EVM tells us "this file validly belongs in /lib/modules/whatever > according > to

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 16:51:49, David Howells wrote: > > I do have patches to parse PGP key data and add the public keys found therein > onto the kernel keyring, but that would mean adding an extra key data parser. PGP is widely used so i would gladly have one more parser in the kernel. > You could

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 08:45:08, Greg Kroah-Hartman wrote: > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote: > > > > Signatures don't provide any guarantees as to code quality or > > correctness. They do provide file integrity and provenance. In > > addition to the license and a Signed-off-by

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-20 23:14:53, Greg Kroah-Hartman wrote: > > Ok, but how do we know "where"? Who is going to start signing and attesting > to the validity of all of the firmware images in the linux-firmware tree > suddenly? Why is it the kernel's job to attest this "where"? Shouldn't your >

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 09:55:42, Andy Lutomirski wrote: I read plenty of the code. I said data not file for a reason. I'll quote some code: int ima_appraise_measurement(int func, struct integrity_iint_cache *iint, struct file *file, const unsigned char *filename,

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-20 23:14:53, Greg Kroah-Hartman wrote: Ok, but how do we know where? Who is going to start signing and attesting to the validity of all of the firmware images in the linux-firmware tree suddenly? Why is it the kernel's job to attest this where? Shouldn't your

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 08:45:08, Greg Kroah-Hartman wrote: On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote: Signatures don't provide any guarantees as to code quality or correctness. They do provide file integrity and provenance. In addition to the license and a Signed-off-by line,

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 09:39:50, Andy Lutomirski wrote: It's also a performance cost because the average user of this signature stuff doesn't actually want IMA, and IMA is checking the wrong think anyway. IMA/EVM tells us this file validly belongs in /lib/modules/whatever according to whomever we

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 09:48:10, Andy Lutomirski wrote: On Thu, May 21, 2015 at 9:43 AM, Petko Manolov pet...@mip-labs.com wrote: On 15-05-21 16:51:49, David Howells wrote: I do have patches to parse PGP key data and add the public keys found therein onto the kernel keyring, but that would mean

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 16:51:49, David Howells wrote: I do have patches to parse PGP key data and add the public keys found therein onto the kernel keyring, but that would mean adding an extra key data parser. PGP is widely used so i would gladly have one more parser in the kernel. You could probably

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 10:02:36, gre...@linuxfoundation.org wrote: On Thu, May 21, 2015 at 04:03:02PM +, Woodhouse, David wrote: In a lot of cases we have loadable firmware precisely to allow us to reduce the cost of the hardware. Adding cryptographic capability in the 'load firmware' state of

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-20 21:41:04, Greg Kroah-Hartman wrote: > On Wed, May 20, 2015 at 07:46:13PM +0300, Petko Manolov wrote: > > On 15-05-20 17:24:46, One Thousand Gnomes wrote: > > > > > > More to the point why do you want to sign firmware files ? Leaving aside > &g

Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

On 15-05-20 09:41:21, Andy Lutomirski wrote: > On Wed, May 20, 2015 at 9:21 AM, Petko Manolov wrote: > > On 15-05-20 08:56:21, Andy Lutomirski wrote: > >> > >> Would it make more sense to permit X.509 chains to be loaded into the > >> keyring > >> i

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-20 17:24:46, One Thousand Gnomes wrote: > > More to the point why do you want to sign firmware files ? Leaving aside the > fact that someone will produce a device with GPLv3 firmware just to p*ss you > off there's the rather more relevant fact that firmware for devices on a so >

Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

On 15-05-20 08:56:21, Andy Lutomirski wrote: > > Would it make more sense to permit X.509 chains to be loaded into the keyring > instead if we actually need that feature? IOW, let userspace (or early > initramfs stuff) extend our keyring trust to intermediate certs that validly > chain to

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-19 17:22:59, Luis R. Rodriguez wrote: > > I have a series of reasons find IMA unsuitable for the current goals at hand: > > 1) IMA is a pretty big kitchen sink, we want this to work well for > even embedded systems, or architectures that do not have or require > TPMs No, it isn't.

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-19 19:10:07, Andy Lutomirski wrote: > On Tue, May 19, 2015 at 7:05 PM, Mimi Zohar wrote: > > > > Perhaps you're referring to EVM? > > I don't know. I also couldn't figure out what IMA was and what EVM was. Try reading this: http://sourceforge.net/p/linux-ima/wiki/Home/ A little

Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

On 15-05-20 08:56:21, Andy Lutomirski wrote: Would it make more sense to permit X.509 chains to be loaded into the keyring instead if we actually need that feature? IOW, let userspace (or early initramfs stuff) extend our keyring trust to intermediate certs that validly chain to

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-20 17:24:46, One Thousand Gnomes wrote: More to the point why do you want to sign firmware files ? Leaving aside the fact that someone will produce a device with GPLv3 firmware just to p*ss you off there's the rather more relevant fact that firmware for devices on a so called

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-19 19:10:07, Andy Lutomirski wrote: On Tue, May 19, 2015 at 7:05 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote: Perhaps you're referring to EVM? I don't know. I also couldn't figure out what IMA was and what EVM was. Try reading this:

Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

On 15-05-20 09:41:21, Andy Lutomirski wrote: On Wed, May 20, 2015 at 9:21 AM, Petko Manolov pet...@mip-labs.com wrote: On 15-05-20 08:56:21, Andy Lutomirski wrote: Would it make more sense to permit X.509 chains to be loaded into the keyring instead if we actually need that feature

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-19 17:22:59, Luis R. Rodriguez wrote: I have a series of reasons find IMA unsuitable for the current goals at hand: 1) IMA is a pretty big kitchen sink, we want this to work well for even embedded systems, or architectures that do not have or require TPMs No, it isn't. I've

Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-20 21:41:04, Greg Kroah-Hartman wrote: On Wed, May 20, 2015 at 07:46:13PM +0300, Petko Manolov wrote: On 15-05-20 17:24:46, One Thousand Gnomes wrote: More to the point why do you want to sign firmware files ? Leaving aside the fact that someone will produce a device

  1   2   3   >