NIAP PP_OS certification requests that the OS shall validate the
CodeSigning extended key usage extension field for integrity
verifiction of exectable code:
https://www.niap-ccevs.org/MMO/PP/-442-/
FIA_X509_EXT.1.1
This patchset adds the logic for parsing the codeSigning EKU extension
Add an openssl command option example for generating CodeSign extended
key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU be enabled.
Signed-off-by: "Lee, Chun-Yi"
---
Documentation/admin-guide/module-signing.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/admin-guide/
Add codeSigning EKU to the X.509 key generation config for the build time
autogenerated kernel key.
Signed-off-by: "Lee, Chun-Yi"
---
certs/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/certs/Makefile b/certs/Makefile
index f4c25b67aad9..1ef4d6ca43b7 100644
--- a/certs/Makefile
++
This patch adds the logic for parsing the CodeSign extended key usage
extension in X.509. The parsing result will be set to the eku flag
which is carried by public key. It can be used in the PKCS#7
verification.
Signed-off-by: "Lee, Chun-Yi"
---
crypto/asymmetric_keys/x509_cert_parser.c | 24 +++
This patch adds the logic for checking the CodeSigning extended
key usage when verifying signature of kernel module or
kexec PE binary in PKCS#7.
Signed-off-by: "Lee, Chun-Yi"
---
certs/system_keyring.c | 2 +-
crypto/asymmetric_keys/Kconfig | 9 +
crypto/asymmetric
ARM Cortex-A72 cores running in 32-bit mode are affected by a silicon
erratum (1655431: ELR recorded incorrectly on interrupt taken between
cryptographic instructions in a sequence [0]) where the second instruction
of a AES instruction pair may execute twice if an interrupt is taken right
after the
Ok, I think I can make a patch to keep them at "include/crypto" .
-邮件原件-
发件人: Stephan Mueller [mailto:smuel...@chronox.de]
发送时间: 2020年11月19日 4:25
收件人: yumeng (J) ; herb...@gondor.apana.org.au;
da...@davemloft.net
抄送: linux-crypto@vger.kernel.org; Xu Zaibo ; Wangzhou (B)
; linux-ker...@v
On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge. I
Quoting Thara Gopinath (2020-11-19 07:52:31)
> Partial hash was being copied into the final result buffer without the
> entire message block processed. Depending on how the end user processes
> this result buffer, errors vary from result buffer corruption to result
> buffer poisoing. Fix this issue
Quoting Thara Gopinath (2020-11-19 07:52:29)
> Qualcomm CE clock resource that is managed by BCM is required
> by crypto driver to access the core clock.
>
> Reviewed-by: Bjorn Andersson
> Signed-off-by: Thara Gopinath
> ---
Applied to clk-next
Quoting Thara Gopinath (2020-11-19 07:52:28)
> Add clock id forc CE clock resource which is required to bring up the
> crypto engine on sdm845.
>
> Reviewed-by: Bjorn Andersson
> Signed-off-by: Thara Gopinath
> ---
Applied to clk-next
On Wed, Nov 25, 2020 at 12:53 AM Finn Thain wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)
Making the kernel strictly conforming is a ship that s
On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.
No, I have not said that. Please don't put words in my mouth (again).
I have said *authoring* lines of *this* kind tak
On Wed, 25 Nov 2020, Miguel Ojeda wrote:
>
> The C standard has nothing to do with this. We use compiler extensions
> of several kinds, for many years. Even discounting those extensions, the
> kernel is not even conforming to C due to e.g. strict aliasing. I am not
> sure what you are trying
On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote:
>
> What I meant was that you've used pessimism as if it was fact.
"future mistakes that it might prevent" is neither pessimism nor states a fact.
> For example, "There is no way to guess what the effect would be if the
> compiler trained program
On Tue, Nov 24, 2020 at 11:24 PM Finn Thain wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.
There is no "language spec" the kernel adheres to. Even if it did,
kernel co
On Tue, 24 Nov 2020, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at
> > all ... we really shouldn't be wasting maintainer time with it because
> > it has a cost to merge. I'm not sure
On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge. I'm not sure we understand where the balance
> lies in value
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it so
RFC 7905 defines usage of ChaCha20-Poly1305 in TLS connections. This
cipher is widely used nowadays and it's good to have a support for it
in TLS connections in kernel.
Changes v2:
nit fixes suggested by Jakub Kicinski
add linux-crypto to review patch set
Vadim Fedorenko (5):
net/tls: make
Add ChaCha-Poly specific configuration code.
Signed-off-by: Vadim Fedorenko
---
net/tls/tls_main.c | 3 +++
net/tls/tls_sw.c | 16
2 files changed, 19 insertions(+)
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 8d93cea..47b7c53 100644
--- a/net/tls/tls_main.c
++
RFC 7905 defines special behavior for ChaCha-Poly TLS sessions.
The differences are in the calculation of nonce and the absence
of explicit IV. This behavior is like TLSv1.3 partly.
Signed-off-by: Vadim Fedorenko
---
include/net/tls.h | 9 ++---
net/tls/tls_sw.c | 6 --
2 files changed,
Add new cipher as a variant of standard tls selftests
Signed-off-by: Vadim Fedorenko
---
tools/testing/selftests/net/tls.c | 40 ---
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/net/tls.c
b/tools/testing/selftests/net
Inline functions defined in tls.h have a lot of AES-specific
constants. Remove these constants and change argument to struct
tls_prot_info to have an access to cipher type in later patches
Signed-off-by: Vadim Fedorenko
---
include/net/tls.h | 26 --
net/tls/t
To provide support for ChaCha-Poly cipher we need to define
specific constants and structures.
Signed-off-by: Vadim Fedorenko
---
include/net/tls.h| 1 +
include/uapi/linux/tls.h | 15 +++
2 files changed, 16 insertions(+)
diff --git a/include/net/tls.h b/include/net/tls.h
On Mon, Nov 23, 2020 at 08:38:46PM +, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> >
> > In preparation to enable -Wimplicit-f
On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
>
> > IB/hfi1: Fix fall-through warnings for Clang
> > IB/mlx4: Fix fall-through warnings for Clang
> > IB/qedr: Fix fall-through warnings for Clang
> > R
ecdh_set_secret() casts a void* pointer to a const u64* in order to
feed it into ecc_is_key_valid(). This is not generally permitted by
the C standard, and leads to actual misalignment faults on ARMv6
cores. In some cases, these are fixed up in software, but this still
leads to performance hits tha
28 matches
Mail list logo
