Am Montag, 5. Oktober 2020, 08:44:39 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Mon, 5 Oct 2020 at 08:40, Stephan Mueller wrote:
> > Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel:
> >
> > Hi Ard,
> >
> > > If jitterentropy is a special case, we could put a alternate
> > > non
When memory allocation fails, an appropriate return value
should be set.
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
verification")
Signed-off-by: Tianjia Zhang
---
crypto/asymmetric_keys/public_key_sm2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --g
On Sat, Oct 03, 2020 at 12:43:13PM -0700, Joe Perches wrote:
> On Sat, 2020-10-03 at 15:31 -0400, Konstantin Ryabitsev wrote:
> > I'm worried that this can get unwieldy for series of 50 patches where 49
> > got applied. Would the following be better:
...
> > A subset of these patches was applie
On Thu, Oct 01, 2020 at 07:50:22PM +0200, Corentin Labbe wrote:
> On Tue, Mar 03, 2020 at 04:30:17PM -0500, Daniel Jordan wrote:
> > Barring other ideas, Corentin, would you be willing to boot with
> >
> > trace_event=initcall:*,module:* trace_options=stacktrace
> >
> > and
> >
> > diff --gi
The AES code uses a 'br x7' as part of a function called by
a macro, that ends up needing a BTI_J as a target. Lets
define SYN_CODE_START_LOCAL() for this and replace the
SYM_FUNC_START_LOCAL with a SYM_FUNC_CODE_LOCAL in the AES block.
Without this kernels compiled with the aes_neon_bs will OOPS
On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
>
> The AES code uses a 'br x7' as part of a function called by
> a macro, that ends up needing a BTI_J as a target.
Could we instead just drop the tail call, i.e, replace it with a ret
and do a 'bl' after it returns? The indirect call does not re
Hi,
On 10/5/20 1:54 PM, Ard Biesheuvel wrote:
On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
The AES code uses a 'br x7' as part of a function called by
a macro, that ends up needing a BTI_J as a target.
Could we instead just drop the tail call, i.e, replace it with a ret
and do a 'bl' a
On Mon, Oct 05, 2020 at 01:18:04PM -0500, Jeremy Linton wrote:
> The AES code uses a 'br x7' as part of a function called by
> a macro, that ends up needing a BTI_J as a target. Lets
> define SYN_CODE_START_LOCAL() for this and replace the
> SYM_FUNC_START_LOCAL with a SYM_FUNC_CODE_LOCAL in the A
Hi,
On 10/5/20 2:59 PM, Mark Brown wrote:
On Mon, Oct 05, 2020 at 01:18:04PM -0500, Jeremy Linton wrote:
The AES code uses a 'br x7' as part of a function called by
a macro, that ends up needing a BTI_J as a target. Lets
define SYN_CODE_START_LOCAL() for this and replace the
SYM_FUNC_START_LO
On Mon, Oct 05, 2020 at 03:10:42PM -0500, Jeremy Linton wrote:
> On 10/5/20 2:59 PM, Mark Brown wrote:
> > ...this is going to cause problems, SYM_CODE means that we should
> > assemble *exactly* what was written since it's some non-standard thing -
> > we use it for the vectors table for example.
The AES code uses a 'br x7' as part of a function called by
a macro. That branch needs a bti_j as a target. This results
in a panic as seen below. Instead of trying to replace the branch
target with a bti_jc, lets replace the indirect branch with a
bl/ret, bl sequence that can target the existing b
11 matches
Mail list logo
