lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1552955080.2785.26.camel@linux.ibm.com>
Date:   Mon, 18 Mar 2019 17:24:40 -0700
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        jarkko.sakkinen@...ux.intel.com
Cc:     Roberto Sassu <roberto.sassu@...wei.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        David Howells <dhowells@...hat.com>, keyrings@...r.kernel.org,
        linux-nvdimm@...ts.01.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] security/keys/trusted: Allow operation without hardware
 TPM

On Mon, 2019-03-18 at 16:45 -0700, Dan Williams wrote:
> Rather than fail initialization of the trusted.ko module, arrange for
> the module to load, but rely on trusted_instantiate() to fail
> trusted-key operations.

What actual problem is this fixing?  To me it would seem like an
enhancement to make the trusted module fail at load time if there's no
TPM rather than waiting until first use to find out it can never work. 
Is there some piece of user code that depends on the successful
insertion of trusted.ko?

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ