02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
22 Dec, 2015
1 commit
-
Some crypto drivers cannot process empty data message and return a
precalculated hash for md5/sha1/sha224/sha256.This patch add thoses precalculated hash in include/crypto.
Signed-off-by: LABBE Corentin
Signed-off-by: Herbert Xu
10 Apr, 2015
6 commits
-
This updated the generic SHA-512 implementation to use the
generic shared SHA-512 glue code.It also implements a .finup hook crypto_sha512_finup() and exports
it to other modules. The import and export() functions and the
.statesize member are dropped, since the default implementation
is perfectly suitable for this module.Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu -
This updates the generic SHA-256 implementation to use the
new shared SHA-256 glue code.It also implements a .finup hook crypto_sha256_finup() and exports
it to other modules. The import and export() functions and the
.statesize member are dropped, since the default implementation
is perfectly suitable for this module.Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu -
This updated the generic SHA-1 implementation to use the generic
shared SHA-1 glue code.It also implements a .finup hook crypto_sha1_finup() and exports
it to other modules. The import and export() functions and the
.statesize member are dropped, since the default implementation
is perfectly suitable for this module.Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu -
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-512
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.The users need to supply an implementation of
void (sha512_block_fn)(struct sha512_state *sst, u8 const *src, int blocks)
and pass it to the SHA-512 base functions. For easy casting between the
prototype above and existing block functions that take a 'u64 state[]'
as their first argument, the 'state' member of struct sha512_state is
moved to the base of the struct.Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu -
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-256
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.The users need to supply an implementation of
void (sha256_block_fn)(struct sha256_state *sst, u8 const *src, int blocks)
and pass it to the SHA-256 base functions. For easy casting between the
prototype above and existing block functions that take a 'u32 state[]'
as their first argument, the 'state' member of struct sha256_state is
moved to the base of the struct.Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu -
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-1
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.The users need to supply an implementation of
void (sha1_block_fn)(struct sha1_state *sst, u8 const *src, int blocks)
and pass it to the SHA-1 base functions. For easy casting between the
prototype above and existing block functions that take a 'u32 state[]'
as their first argument, the 'state' member of struct sha1_state is
moved to the base of the struct.Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
25 Apr, 2013
1 commit
-
Other SHA512 routines may need to use the generic routine when
FPU is not available.Signed-off-by: Tim Chen
Signed-off-by: Herbert Xu
03 Apr, 2013
1 commit
-
Other SHA256 routine may need to use the generic routine when
FPU is not available.Signed-off-by: Tim Chen
Signed-off-by: Herbert Xu
16 Aug, 2011
1 commit
-
On Tue, Aug 16, 2011 at 03:22:34PM +1000, Stephen Rothwell wrote:
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
>
> In file included from security/integrity/ima/../integrity.h:16:0,
> from security/integrity/ima/ima.h:27,
> from security/integrity/ima/ima_policy.c:20:
> include/crypto/sha.h:86:10: warning: 'struct shash_desc' declared inside parameter list
> include/crypto/sha.h:86:10: warning: its scope is only this definition or declaration, which is probably not what you want
>
> Introduced by commit 7c390170b493 ("crypto: sha1 - export sha1_update for
> reuse"). I guess you need to include crypto/hash.h in crypto/sha.h.This patch fixes this by providing a declaration for struct shash_desc.
Reported-by: Stephen Rothwell
Signed-off-by: Herbert Xu
10 Aug, 2011
1 commit
-
Export the update function as crypto_sha1_update() to not have the need
to reimplement the same algorithm for each SHA-1 implementation. This
way the generic SHA-1 implementation can be used as fallback for other
implementations that fail to run under certain circumstances, like the
need for an FPU context while executing in IRQ context.Signed-off-by: Mathias Krause
Signed-off-by: Herbert Xu
22 Jul, 2009
2 commits
-
This patch replaces the 32-bit counters in sha512_generic with
64-bit counters. It also switches the bit count to the simpler
byte count.Signed-off-by: Herbert Xu
-
This patch renames struct sha512_ctx and exports it as struct
sha512_state so that other sha512 implementations can use it
as the reference structure for exporting their state.Signed-off-by: Herbert Xu
11 Jul, 2009
2 commits
-
This patch adds export/import support to sha256_generic. The exported
type is defined by struct sha256_state, which is basically the entire
descriptor state of sha256_generic.Signed-off-by: Herbert Xu
-
This patch adds export/import support to sha1_generic. The exported
type is defined by struct sha1_state, which is basically the entire
descriptor state of sha1_generic.Signed-off-by: Herbert Xu
11 Jan, 2008
1 commit
-
Resubmitting this patch which extends sha256_generic.c to support SHA-224 as
described in FIPS 180-2 and RFC 3874. HMAC-SHA-224 as described in RFC4231
is then supported through the hmac interface.Patch includes test vectors for SHA-224 and HMAC-SHA-224.
SHA-224 chould be chosen as a hash algorithm when 112 bits of security
strength is required.Patch generated against the 2.6.24-rc1 kernel and tested against
2.6.24-rc1-git14 which includes fix for scatter gather implementation for HMAC.Signed-off-by: Jonathan Lynch
Signed-off-by: Herbert Xu
11 Oct, 2007
1 commit
-
There are currently several SHA implementations that all define their own
initialization vectors and size values. Since this values are idential
move them to a header file under include/crypto.Signed-off-by: Jan Glauber
Signed-off-by: Herbert Xu
