On Fri, Jun 8, 2018 at 2:57 PM Matthew Garrett wrote:
>
> When EVM attempts to appraise a file signed with a crypto algorithm the
> kernel doesn't have support for, it will cause the kernel to trigger a
> module load. If the EVM policy includes appraisal of kernel modules this
&g
rypto initialisation is complete, this triggers a deadlock. Add a
CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag
in the EVM case in order to fail gracefully with an error message
instead of deadlocking.
Signed-off-by: Matthew Garrett
---
crypto/api.c
Same as V2, but rebased on next-integrity
s
for validation.
Signed-off-by: Matthew Garrett
---
security/integrity/evm/evm.h| 10 --
security/integrity/evm/evm_crypto.c | 47 +++--
security/integrity/evm/evm_main.c | 19 +++-
3 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/sec
s
for validation.
Signed-off-by: Matthew Garrett
---
security/integrity/evm/evm.h| 10 --
security/integrity/evm/evm_crypto.c | 47 +++--
security/integrity/evm/evm_main.c | 19 +++-
3 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/sec
rypto initialisation is complete, this triggers a deadlock. Add a
CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag
in the EVM case in order to fail gracefully with an error message
instead of deadlocking.
Signed-off-by: Matthew Garrett
---
crypto/api.c
On Sat, Jun 2, 2018 at 8:54 AM Herbert Xu wrote:
>
> On Fri, Jun 01, 2018 at 04:02:43PM -0700, Matthew Garrett wrote:
> > Trying to instantiate a non-existent crypto algorithm will cause the
> > kernel to trigger a module load. If EVM appraisal is enabled, this will
> > i
s
for validation.
Signed-off-by: Matthew Garrett
---
security/integrity/evm/evm.h| 10 --
security/integrity/evm/evm_crypto.c | 47 +++--
security/integrity/evm/evm_main.c | 19 +++-
3 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/sec
ng if it's set, and add that flag in the EVM case.
Signed-off-by: Matthew Garrett
---
crypto/api.c| 2 +-
include/linux/crypto.h | 5 +
security/integrity/evm/evm_crypto.c | 3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/cryp
On Sun, Sep 01, 2013 at 06:40:41PM +0200, Florian Weimer wrote:
> * Matthew Garrett:
>
> > On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
> >
> >> But if you don't generate fresh keys on every boot, the persistent
> >> keys are mor expose
different UEFI applications, so if anyone gets a generic UEFI variable
> dumper (or setter) signed by the trusted key, this cryptographic
> validation of hibernate snapshots is bypassable.
If anyone can execute arbitrary code in your UEFI environment then
you've already lost.
--
Matth
On Sun, Aug 25, 2013 at 06:22:43PM +0200, Pavel Machek wrote:
> On Thu 2013-08-22 19:01:49, Lee, Chun-Yi wrote:
> > From: Matthew Garrett
> >
> > The firmware has a set of flags that indicate whether secure boot is enabled
> > and enforcing. Use them to indicate whe
the initramfs containing the
bootsplash theme and users expecting to be able to change that without
having to generate crypto keys, but that's probably not a showstopper.
But realistically, the first three problems make it unlikely that most
distributions will be willing to depend on or
13 matches
Mail list logo
