Tim Chen wrote:
> > > Your approach is quite complicated. I think something simpler like the
> > > following will work:
> >
> > We cannot benefit from PCLMULQDQ. Is it acceptable for you?
>
>
> The following code in crct10dif-pclmul_glue.c
>
> static const struct x86_cpu_id crct10dif_cpu_id[] =
Hi,
I am working on a driver for OMAP 3DES hardware similar to OMAP AES
(drivers/crypto/omap-aes). The hardware is similar in many ways and a lot of it
can be reused from first look.
Can anyone comment if its ok to add to omap-aes, calling it
drivers/crypto/omap-aesdes. That will ensure maximum r
Support for additional hash algorithms with larger digests, as well as
support for additional file metadata, in the IMA measurement list, have
been proposed for a long time. Unfortunately, the IMA measurement list
entries, which are exposed to userspace via the securityfs
ascii/binary_runtime_meas
The IMA measurement list contains two hashes - a template data hash
and a filedata hash. The template data hash is committed to the TPM,
which is limited, by the TPM v1.2 specification, to 20 bytes. The
filedata hash is defined as 20 bytes as well.
Now that support for variable length measuremen
From: Roberto Sassu
The original 'ima' template is fixed length, containing the filedata hash
and pathname. The filedata hash is limited to 20 bytes (md5/sha1). The
pathname is a null terminated string, limited to 255 characters. To
overcome these limitations and to add additional file metadat
From: Roberto Sassu
Pass the filename argument to ima_add_template_entry() in order to
eliminate a dependency on template specific data (third argument of
integrity_audit_msg).
This change is required because, with the new template management
mechanism, the generation of a new measurement entry
The TPM v1.2 limits the template hash size to 20 bytes. This
patch differentiates between the template hash size, as defined
in the ima_template_entry, and the file data hash size, as
defined in the ima_template_data. Subsequent patches add support
for different file data hash algorithms.
Change
From: Roberto Sassu
This patch defines a library containing two initial template fields,
inode digest (d) and file name (n), the 'ima' template descriptor,
whose format is 'd|n', and two helper functions,
ima_write_template_field_data() and ima_show_template_field_data().
Changelog:
- replace im
From: Dmitry Kasatkin
All files on the filesystem, currently, are hashed using the same hash
algorithm. In preparation for files from different packages being
signed using different hash algorithms, this patch adds support for
reading the signature hash algorithm from the 'security.ima' extended
From: Roberto Sassu
This patch allows users to specify from the kernel command line the
template descriptor, among those defined, that will be used to generate
and display measurement entries. If an user specifies a wrong template,
IMA reverts to the template descriptor set in the kernel configur
This patch adds a Kconfig option to select the default IMA
measurement list template. The 'ima' template limited the
filedata hash to 20 bytes and the pathname to 255 charaters.
The 'ima-ng' measurement list template permits larger hash
digests and longer pathnames.
Changelog:
- keep 'select CRYP
From: Dmitry Kasatkin
With multiple hash algorithms, ima_hash_tfm is no longer guarantied to be sha1.
Need to force to use sha1.
Changelog:
- pass ima_digest_data to ima_calc_boot_aggregate() instead of char *
(Roberto Sassu);
- create an ima_digest_data structure in ima_add_boot_aggregate()
From: Dmitry Kasatkin
ima_calc_buffer_hash will be used with different hash algorithms.
This patch provides support for arbitrary hash algorithms in
ima_calc_buffer_hash.
Signed-off-by: Dmitry Kasatkin
Signed-off-by: Mimi Zohar
---
security/integrity/ima/ima_api.c| 3 +++
security/integr
From: Dmitry Kasatkin
This patch provides dedicated hash algo allocation and
deallocation function which can be used by different clients.
Signed-off-by: Dmitry Kasatkin
Signed-off-by: Mimi Zohar
---
security/integrity/ima/ima_crypto.c | 43 +
1 file change
From: Dmitry Kasatkin
For each inode in the IMA policy, an iint is allocated. To support
larger hash digests, the iint digest size changed from 20 bytes to
the maximum supported hash digest size. Instead of allocating the
maximum size, which most likely is not needed, this patch dynamically
all
From: Roberto Sassu
Pass the file descriptor instead of the inode to ima_add_violation(),
to make the latter consistent with ima_store_measurement() in
preparation for the new template architecture.
Signed-off-by: Roberto Sassu
Signed-off-by: Mimi Zohar
---
security/integrity/ima/ima.h |
From: Roberto Sassu
This patch performs the switch to the new template mechanism by modifying
the functions ima_alloc_init_template(), ima_measurements_show() and
ima_ascii_measurements_show(). The old function ima_template_show() was
removed as it is no longer needed. Also, if the template descr
From: Roberto Sassu
Instead of allocating and initializing the template entry from multiple
places (eg. boot aggregate, violation, and regular measurements), this
patch defines a new function called ima_alloc_init_template(). The new
function allocates and initializes the measurement entry with
From: Roberto Sassu
The same hash algorithm should be used for calculating the file
data hash for the IMA measurement list, as for appraising the file
data integrity. (The appraise hash algorithm is stored in the
'security.ima' extended attribute.) The exception is when the
reference file data
From: Roberto Sassu
This patch adds support for the new template 'ima-ng', whose format
is defined as 'd-ng|n-ng'. These new field definitions remove the
size limitations of the original 'ima' template. Further, the 'd-ng'
field prefixes the inode digest with the hash algorithim, when
displayin
From: Dmitry Kasatkin
In preparation of supporting more hash algorithms with larger hash sizes
needed for signature verification, this patch replaces the 20 byte sized
digest, with a more flexible structure. The new structure includes the
hash algorithm, digest size, and digest.
Changelog:
- re
From: Dmitry Kasatkin
This patch provides single place for information about hash algorithms,
such as hash sizes, and kernel driver names. Will be used by IMA and
public key code.
Changelog:
- Fix sparse and checkpatch warnings
- Move hash algo enums to uapi for userspace signing functions.
Sig
From: Dmitry Kasatkin
This patch makes use of the newly defined common hash algorithm info,
replacing, for example, PKEY_HASH with HASH_ALGO.
Changelog:
- Lindent fixes - Mimi
Signed-off-by: Dmitry Kasatkin
Signed-off-by: Mimi Zohar
---
crypto/asymmetric_keys/Kconfig| 1 +
crypt
On Thu, 2013-07-18 at 05:50 +0900, Tetsuo Handa wrote:
> Tim Chen wrote:
> > > Therefore, I think possible solutions are either
> > >
> > > (a) built-in the dependent modules
> > >
> > > # grep crc /lib/modules/3.11.0-rc1+/modules.dep
> > > kernel/drivers/scsi/sd_mod.ko: kernel/lib/
On Thu, 2013-07-18 at 05:50 +0900, Tetsuo Handa wrote:
> Tim Chen wrote:
> > > Therefore, I think possible solutions are either
> > >
> > > (a) built-in the dependent modules
> > >
> > > # grep crc /lib/modules/3.11.0-rc1+/modules.dep
> > > kernel/drivers/scsi/sd_mod.ko: kernel/lib/
Tim Chen wrote:
> > Therefore, I think possible solutions are either
> >
> > (a) built-in the dependent modules
> >
> > # grep crc /lib/modules/3.11.0-rc1+/modules.dep
> > kernel/drivers/scsi/sd_mod.ko: kernel/lib/crc-t10dif.ko
> > kernel/lib/crc-t10dif.ko:
>
> This approach
On Wed, 2013-07-17 at 20:52 +0900, Tetsuo Handa wrote:
> Tim Chen wrote:
> > Herbert, seems like modules.dep generator wants explicit
> >
> > - select CRYPTO_CRCT10DIF
> > + depends on CRYPTO_CRCT10DIF
> >
> > But it seems to me like it should have known CRC_T10DIF needs
> > CRYPTO_CRCT10DIF
Tim Chen wrote:
> Herbert, seems like modules.dep generator wants explicit
>
> - select CRYPTO_CRCT10DIF
> + depends on CRYPTO_CRCT10DIF
>
> But it seems to me like it should have known CRC_T10DIF needs
> CRYPTO_CRCT10DIF when we do
> select CRYPTO_CRCT10DIF
>
> Your thoughts?
"s
28 matches
Mail list logo
