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
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
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
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
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
> >
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
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,
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
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
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.
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
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
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
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
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
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
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
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
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
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
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.
>
>
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.
>
>
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;
> > > >
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;
> > > >
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
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
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
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
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.
>
>
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.
>
>
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
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
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
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
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.
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.
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.
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.
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
>
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
>
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
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
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
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
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
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
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
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
> >
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
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
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
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
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
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
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
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
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:
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:
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
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
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
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,
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
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
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
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
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
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
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
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.
>
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
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
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:
> > > >
> > > >
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:
+-
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
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'
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
> >>
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
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
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
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
>
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,
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
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,
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
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
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
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
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
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
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
>
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
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.
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
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
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
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:
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
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
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 - 100 of 260 matches
Mail list logo