<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include/keys, branch v4.5-rc6</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next</title>
<updated>2015-12-26T05:06:53+00:00</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2015-12-26T05:06:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3cb92fe48138d225b8d0ceedf148642f9103f841'/>
<id>3cb92fe48138d225b8d0ceedf148642f9103f841</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>keys, trusted: seal with a TPM2 authorization policy</title>
<updated>2015-12-20T13:27:13+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2015-10-31T15:53:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5beb0c435bdde35a09376566b0e28f7df87c9f68'/>
<id>5beb0c435bdde35a09376566b0e28f7df87c9f68</id>
<content type='text'>
TPM2 supports authorization policies, which are essentially
combinational logic statements repsenting the conditions where the data
can be unsealed based on the TPM state. This patch enables to use
authorization policies to seal trusted keys.

Two following new options have been added for trusted keys:

* 'policydigest=': provide an auth policy digest for sealing.
* 'policyhandle=': provide a policy session handle for unsealing.

If 'hash=' option is supplied after 'policydigest=' option, this
will result an error because the state of the option would become
mixed.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Tested-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Acked-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
TPM2 supports authorization policies, which are essentially
combinational logic statements repsenting the conditions where the data
can be unsealed based on the TPM state. This patch enables to use
authorization policies to seal trusted keys.

Two following new options have been added for trusted keys:

* 'policydigest=': provide an auth policy digest for sealing.
* 'policyhandle=': provide a policy session handle for unsealing.

If 'hash=' option is supplied after 'policydigest=' option, this
will result an error because the state of the option would become
mixed.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Tested-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Acked-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>keys, trusted: select hash algorithm for TPM2 chips</title>
<updated>2015-12-20T13:27:12+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2015-11-05T19:43:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5ca4c20cfd37bac6486de040e9951b3b34755238'/>
<id>5ca4c20cfd37bac6486de040e9951b3b34755238</id>
<content type='text'>
Added 'hash=' option for selecting the hash algorithm for add_key()
syscall and documentation for it.

Added entry for sm3-256 to the following tables in order to support
TPM_ALG_SM3_256:

* hash_algo_name
* hash_digest_size

Includes support for the following hash algorithms:

* sha1
* sha256
* sha384
* sha512
* sm3-256

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Tested-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Reviewed-by: James Morris &lt;james.l.morris@oracle.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Acked-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Added 'hash=' option for selecting the hash algorithm for add_key()
syscall and documentation for it.

Added entry for sm3-256 to the following tables in order to support
TPM_ALG_SM3_256:

* hash_algo_name
* hash_digest_size

Includes support for the following hash algorithms:

* sha1
* sha256
* sha384
* sha512
* sm3-256

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Tested-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Reviewed-by: James Morris &lt;james.l.morris@oracle.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Acked-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>IMA: create machine owner and blacklist keyrings</title>
<updated>2015-12-15T15:01:43+00:00</updated>
<author>
<name>Petko Manolov</name>
<email>petkan@mip-labs.com</email>
</author>
<published>2015-12-02T15:47:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=41c89b64d7184a780f12f2cccdabe65cb2408893'/>
<id>41c89b64d7184a780f12f2cccdabe65cb2408893</id>
<content type='text'>
This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
intermediate keyring that sits between .system and .ima keyrings,
effectively forming a simple CA hierarchy.  To successfully import a key
into .ima_mok it must be signed by a key which CA is in .system keyring.
On turn any key that needs to go in .ima keyring must be signed by CA in
either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot.

IMA blacklist keyring contains all revoked IMA keys.  It is consulted
before any other keyring.  If the search is successful the requested
operation is rejected and error is returned to the caller.

Signed-off-by: Petko Manolov &lt;petkan@mip-labs.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
intermediate keyring that sits between .system and .ima keyrings,
effectively forming a simple CA hierarchy.  To successfully import a key
into .ima_mok it must be signed by a key which CA is in .system keyring.
On turn any key that needs to go in .ima keyring must be signed by CA in
either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot.

IMA blacklist keyring contains all revoked IMA keys.  It is consulted
before any other keyring.  If the search is successful the requested
operation is rejected and error is returned to the caller.

Signed-off-by: Petko Manolov &lt;petkan@mip-labs.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Merge the type-specific data with the payload data</title>
<updated>2015-10-21T14:18:36+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2015-10-21T13:04:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc'/>
<id>146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc</id>
<content type='text'>
Merge the type-specific data with the payload data into one four-word chunk
as it seems pointless to keep them separate.

Use user_key_payload() for accessing the payloads of overloaded
user-defined keys.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: linux-cifs@vger.kernel.org
cc: ecryptfs@vger.kernel.org
cc: linux-ext4@vger.kernel.org
cc: linux-f2fs-devel@lists.sourceforge.net
cc: linux-nfs@vger.kernel.org
cc: ceph-devel@vger.kernel.org
cc: linux-ima-devel@lists.sourceforge.net
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Merge the type-specific data with the payload data into one four-word chunk
as it seems pointless to keep them separate.

Use user_key_payload() for accessing the payloads of overloaded
user-defined keys.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: linux-cifs@vger.kernel.org
cc: ecryptfs@vger.kernel.org
cc: linux-ext4@vger.kernel.org
cc: linux-f2fs-devel@lists.sourceforge.net
cc: linux-nfs@vger.kernel.org
cc: ceph-devel@vger.kernel.org
cc: linux-ima-devel@lists.sourceforge.net
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: seal/unseal for TPM 2.0</title>
<updated>2015-10-18T23:01:21+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2015-05-30T05:09:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=954650efb79f99d5c817c121bb0a7c6c53362048'/>
<id>954650efb79f99d5c817c121bb0a7c6c53362048</id>
<content type='text'>
Added tpm_trusted_seal() and tpm_trusted_unseal() API for sealing
trusted keys.

This patch implements basic sealing and unsealing functionality for
TPM 2.0:

* Seal with a parent key using a 20 byte auth value.
* Unseal with a parent key using a 20 byte auth value.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Added tpm_trusted_seal() and tpm_trusted_unseal() API for sealing
trusted keys.

This patch implements basic sealing and unsealing functionality for
TPM 2.0:

* Seal with a parent key using a 20 byte auth value.
* Unseal with a parent key using a 20 byte auth value.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>keys, trusted: move struct trusted_key_options to trusted-type.h</title>
<updated>2015-10-18T23:01:21+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2015-06-12T21:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fe351e8d4eec801beeba1df1f36d76316be6f1a2'/>
<id>fe351e8d4eec801beeba1df1f36d76316be6f1a2</id>
<content type='text'>
Moved struct trusted_key_options to trustes-type.h so that the fields
can be accessed from drivers/char/tpm.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Moved struct trusted_key_options to trustes-type.h so that the fields
can be accessed from drivers/char/tpm.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PKCS#7: Appropriately restrict authenticated attributes and content type</title>
<updated>2015-08-12T16:01:01+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2015-08-05T14:22:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=99db44350672c8a5ee9a7b0a6f4cd6ff10136065'/>
<id>99db44350672c8a5ee9a7b0a6f4cd6ff10136065</id>
<content type='text'>
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature.  If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.

Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].

We should really validate the authattrs if they exist or forbid them
entirely as appropriate.  To this end:

 (1) Alter the PKCS#7 parser to reject any message that has more than one
     signature where at least one signature has authattrs and at least one
     that does not.

 (2) Validate authattrs if they are present and strongly restrict them.
     Only the following authattrs are permitted and all others are
     rejected:

     (a) contentType.  This is checked to be an OID that matches the
     	 content type in the SignedData object.

     (b) messageDigest.  This must match the crypto digest of the data.

     (c) signingTime.  If present, we check that this is a valid, parseable
     	 UTCTime or GeneralTime and that the date it encodes fits within
     	 the validity window of the matching X.509 cert.

     (d) S/MIME capabilities.  We don't check the contents.

     (e) Authenticode SP Opus Info.  We don't check the contents.

     (f) Authenticode Statement Type.  We don't check the contents.

     The message is rejected if (a) or (b) are missing.  If the message is
     an Authenticode type, the message is rejected if (e) is missing; if
     not Authenticode, the message is rejected if (d) - (f) are present.

     The S/MIME capabilities authattr (d) unfortunately has to be allowed
     to support kernels already signed by the pesign program.  This only
     affects kexec.  sign-file suppresses them (CMS_NOSMIMECAP).

     The message is also rejected if an authattr is given more than once or
     if it contains more than one element in its set of values.

 (3) Add a parameter to pkcs7_verify() to select one of the following
     restrictions and pass in the appropriate option from the callers:

     (*) VERIFYING_MODULE_SIGNATURE

	 This requires that the SignedData content type be pkcs7-data and
	 forbids authattrs.  sign-file sets CMS_NOATTR.  We could be more
	 flexible and permit authattrs optionally, but only permit minimal
	 content.

     (*) VERIFYING_FIRMWARE_SIGNATURE

	 This requires that the SignedData content type be pkcs7-data and
	 requires authattrs.  In future, this will require an attribute
	 holding the target firmware name in addition to the minimal set.

     (*) VERIFYING_UNSPECIFIED_SIGNATURE

	 This requires that the SignedData content type be pkcs7-data but
	 allows either no authattrs or only permits the minimal set.

     (*) VERIFYING_KEXEC_PE_SIGNATURE

	 This only supports the Authenticode SPC_INDIRECT_DATA content type
	 and requires at least an SpcSpOpusInfo authattr in addition to the
	 minimal set.  It also permits an SPC_STATEMENT_TYPE authattr (and
	 an S/MIME capabilities authattr because the pesign program doesn't
	 remove these).

     (*) VERIFYING_KEY_SIGNATURE
     (*) VERIFYING_KEY_SELF_SIGNATURE

	 These are invalid in this context but are included for later use
	 when limiting the use of X.509 certs.

 (4) The pkcs7_test key type is given a module parameter to select between
     the above options for testing purposes.  For example:

	echo 1 &gt;/sys/module/pkcs7_test_key/parameters/usage
	keyctl padd pkcs7_test foo @s &lt;/tmp/stuff.pkcs7

     will attempt to check the signature on stuff.pkcs7 as if it contains a
     firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).

Suggested-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Reviewed-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature.  If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.

Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].

We should really validate the authattrs if they exist or forbid them
entirely as appropriate.  To this end:

 (1) Alter the PKCS#7 parser to reject any message that has more than one
     signature where at least one signature has authattrs and at least one
     that does not.

 (2) Validate authattrs if they are present and strongly restrict them.
     Only the following authattrs are permitted and all others are
     rejected:

     (a) contentType.  This is checked to be an OID that matches the
     	 content type in the SignedData object.

     (b) messageDigest.  This must match the crypto digest of the data.

     (c) signingTime.  If present, we check that this is a valid, parseable
     	 UTCTime or GeneralTime and that the date it encodes fits within
     	 the validity window of the matching X.509 cert.

     (d) S/MIME capabilities.  We don't check the contents.

     (e) Authenticode SP Opus Info.  We don't check the contents.

     (f) Authenticode Statement Type.  We don't check the contents.

     The message is rejected if (a) or (b) are missing.  If the message is
     an Authenticode type, the message is rejected if (e) is missing; if
     not Authenticode, the message is rejected if (d) - (f) are present.

     The S/MIME capabilities authattr (d) unfortunately has to be allowed
     to support kernels already signed by the pesign program.  This only
     affects kexec.  sign-file suppresses them (CMS_NOSMIMECAP).

     The message is also rejected if an authattr is given more than once or
     if it contains more than one element in its set of values.

 (3) Add a parameter to pkcs7_verify() to select one of the following
     restrictions and pass in the appropriate option from the callers:

     (*) VERIFYING_MODULE_SIGNATURE

	 This requires that the SignedData content type be pkcs7-data and
	 forbids authattrs.  sign-file sets CMS_NOATTR.  We could be more
	 flexible and permit authattrs optionally, but only permit minimal
	 content.

     (*) VERIFYING_FIRMWARE_SIGNATURE

	 This requires that the SignedData content type be pkcs7-data and
	 requires authattrs.  In future, this will require an attribute
	 holding the target firmware name in addition to the minimal set.

     (*) VERIFYING_UNSPECIFIED_SIGNATURE

	 This requires that the SignedData content type be pkcs7-data but
	 allows either no authattrs or only permits the minimal set.

     (*) VERIFYING_KEXEC_PE_SIGNATURE

	 This only supports the Authenticode SPC_INDIRECT_DATA content type
	 and requires at least an SpcSpOpusInfo authattr in addition to the
	 minimal set.  It also permits an SPC_STATEMENT_TYPE authattr (and
	 an S/MIME capabilities authattr because the pesign program doesn't
	 remove these).

     (*) VERIFYING_KEY_SIGNATURE
     (*) VERIFYING_KEY_SELF_SIGNATURE

	 These are invalid in this context but are included for later use
	 when limiting the use of X.509 certs.

 (4) The pkcs7_test key type is given a module parameter to select between
     the above options for testing purposes.  For example:

	echo 1 &gt;/sys/module/pkcs7_test_key/parameters/usage
	keyctl padd pkcs7_test foo @s &lt;/tmp/stuff.pkcs7

     will attempt to check the signature on stuff.pkcs7 as if it contains a
     firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).

Suggested-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Reviewed-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MODSIGN: Extract the blob PKCS#7 signature verifier from module signing</title>
<updated>2015-08-07T15:26:13+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2015-07-20T20:16:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=091f6e26eb326adbd718f406e440c838bed8ebb6'/>
<id>091f6e26eb326adbd718f406e440c838bed8ebb6</id>
<content type='text'>
Extract the function that drives the PKCS#7 signature verification given a
data blob and a PKCS#7 blob out from the module signing code and lump it with
the system keyring code as it's generic.  This makes it independent of module
config options and opens it to use by the firmware loader.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Cc: Luis R. Rodriguez &lt;mcgrof@suse.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Ming Lei &lt;ming.lei@canonical.com&gt;
Cc: Seth Forshee &lt;seth.forshee@canonical.com&gt;
Cc: Kyle McMartin &lt;kyle@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Extract the function that drives the PKCS#7 signature verification given a
data blob and a PKCS#7 blob out from the module signing code and lump it with
the system keyring code as it's generic.  This makes it independent of module
config options and opens it to use by the firmware loader.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Cc: Luis R. Rodriguez &lt;mcgrof@suse.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Ming Lei &lt;ming.lei@canonical.com&gt;
Cc: Seth Forshee &lt;seth.forshee@canonical.com&gt;
Cc: Kyle McMartin &lt;kyle@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Restore partial ID matching functionality for asymmetric keys</title>
<updated>2014-10-06T14:21:05+00:00</updated>
<author>
<name>Dmitry Kasatkin</name>
<email>d.kasatkin@samsung.com</email>
</author>
<published>2014-10-06T14:21:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f1b731dbc2530cab93fcfc5fcb18c9f3a100feeb'/>
<id>f1b731dbc2530cab93fcfc5fcb18c9f3a100feeb</id>
<content type='text'>
Bring back the functionality whereby an asymmetric key can be matched with a
partial match on one of its IDs.

Whilst we're at it, allow for the possibility of having an increased number of
IDs.

Reported-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Signed-off-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Bring back the functionality whereby an asymmetric key can be matched with a
partial match on one of its IDs.

Whilst we're at it, allow for the possibility of having an increased number of
IDs.

Reported-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Signed-off-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
