> On Apr 19, 2021, at 11:33 AM, Dave Hansen wrote:
>
> On 4/19/21 11:10 AM, Andy Lutomirski wrote:
>> I’m confused by this scenario. This should only affect physical pages
>> that are in the 2M area that contains guest memory. But, if we have a
>> 2M direct map PMD
> On Apr 19, 2021, at 10:58 AM, Dave Hansen wrote:
>
> On 4/19/21 10:46 AM, Brijesh Singh wrote:
>> - guest wants to make gpa 0x1000 as a shared page. To support this, we
>> need to psmash the large RMP entry into 512 4K entries. The psmash
>> instruction breaks the large RMP entry into 512 4
On Wed, Mar 24, 2021 at 10:04 AM Brijesh Singh wrote:
>
> If hardware detects an RMP violation, it will raise a page-fault exception
> with the RMP bit set. To help the debug, dump the RMP entry of the faulting
> address.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Joe
On Tue, Feb 23, 2021 at 4:54 PM Dey, Megha wrote:
>
> Hi Andy,
>
> On 1/24/2021 8:23 AM, Andy Lutomirski wrote:
> > On Fri, Jan 22, 2021 at 11:29 PM Megha Dey wrote:
> >> Optimize crypto algorithms using AVX512 instructions - VAES and VPCLMULQDQ
> >> (first i
On Fri, Jan 22, 2021 at 11:29 PM Megha Dey wrote:
>
> Optimize crypto algorithms using AVX512 instructions - VAES and VPCLMULQDQ
> (first implemented on Intel's Icelake client and Xeon CPUs).
>
> These algorithms take advantage of the AVX512 registers to keep the CPU
> busy and increase memory ban
On Wed, Dec 16, 2020 at 9:46 AM Chang S. Bae wrote:
>
> Key Locker [1][2] is a new security feature available in new Intel CPUs to
> protect data encryption keys for the Advanced Encryption Standard
> algorithm. The protection limits the amount of time an AES key is exposed
> in memory by sealing
On Wed, Dec 16, 2020 at 9:46 AM Chang S. Bae wrote:
>
> Key Locker (KL) is Intel's new security feature that protects the AES key
> at the time of data transformation. New AES SIMD instructions -- as a
> successor of Intel's AES-NI -- are provided to encode an AES key and
> reference it for the AE
On Tue, Sep 15, 2020 at 9:38 PM Eric Biggers wrote:>
> From: Eric Biggers
>
> Remove some dead code that was left over following commit 90ea1c6436d2
> ("random: remove the blocking pool").
>
Looks good to me.
Reviewed-by: Andy Lutomirski
On Mon, Oct 7, 2019 at 8:12 AM Ard Biesheuvel wrote:
>
> On Mon, 7 Oct 2019 at 17:02, Andy Lutomirski wrote:
> >
> > On Sun, Oct 6, 2019 at 10:24 PM Ard Biesheuvel
> > wrote:
> > >
> > > On Mon, 7 Oct 2019 at 06:44, Andy Lutomirski wrote:
> > &
On Sun, Oct 6, 2019 at 10:24 PM Ard Biesheuvel
wrote:
>
> On Mon, 7 Oct 2019 at 06:44, Andy Lutomirski wrote:
> >
> > > Actually, this can be addressed by retaining the module dependencies
> > > as before, but permitting the arch module to be omitted at load time.
> On Oct 5, 2019, at 12:24 AM, Ard Biesheuvel wrote:
>
> On Fri, 4 Oct 2019 at 16:56, Ard Biesheuvel
> wrote:
>>
>>> On Fri, 4 Oct 2019 at 16:53, Andy Lutomirski wrote:
>>>
>>>
>>>
>>>> On Oct 4, 2019, at 6:52 AM, Ar
> On Oct 4, 2019, at 6:52 AM, Ard Biesheuvel wrote:
>
> On Fri, 4 Oct 2019 at 15:42, Jason A. Donenfeld wrote:
>>
>>> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
>>> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel
>>> wrote:
>>> ...
In the future, I would
> On Oct 4, 2019, at 6:42 AM, Jason A. Donenfeld wrote:
>
> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
>>> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel
>>> wrote:
>>>
>> ...
>>>
>>> In the future, I would like to extend these interfaces to use static calls,
>>> so that
On Thu, Sep 26, 2019 at 8:54 PM Herbert Xu wrote:
>
> On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote:
> >
> > Side note: almost nobody does this.
> >
> > Almost every single async interface I've ever seen ends up being "only
> > designed for async".
> >
> > And I think the reason i
> On Sep 26, 2019, at 6:38 PM, Linus Torvalds
> wrote:
>
> - let the caller know what the state size is and allocate the
> synchronous state in its own data structures
>
> - let the caller just call a static "decrypt_xyz()" function for xyz
> decryptrion.
>
> - if you end up doing it synchronousl
On Thu, Sep 26, 2019 at 1:52 PM Jason A. Donenfeld wrote:
>
> Hi Ard,
>
>
> Our goals are that chacha20_arch() from each of these arch glues gets
> included in the lib/crypto/chacha20.c compilation unit. The reason why
> we want it in its own unit is so that the inliner can get rid of
> unreached
On Fri, Oct 5, 2018 at 10:28 AM Ard Biesheuvel
wrote:
>
> On 5 October 2018 at 19:26, Andy Lutomirski wrote:
> > On Fri, Oct 5, 2018 at 10:15 AM Ard Biesheuvel
> > wrote:
> >>
> >> On 5 October 2018 at 15:37, Jason A. Donenfeld wrote:
> >> ...
On Fri, Oct 5, 2018 at 10:38 AM Jason A. Donenfeld wrote:
>
> On Fri, Oct 5, 2018 at 7:29 PM Andy Lutomirski wrote:
> > (None of this is to say that I disagree with Jason, though -- I'm not
> > entirely convinced that this makes sense for Zinc. But maybe it can
> >
On Fri, Oct 5, 2018 at 10:23 AM Ard Biesheuvel
wrote:
>
> On 5 October 2018 at 19:20, Andy Lutomirski wrote:
> > On Fri, Oct 5, 2018 at 10:11 AM Ard Biesheuvel
> > wrote:
> >>
> >> On 5 October 2018 at 18:58, Andy Lutomirski wrote:
> >> &g
On Fri, Oct 5, 2018 at 10:15 AM Ard Biesheuvel
wrote:
>
> On 5 October 2018 at 15:37, Jason A. Donenfeld wrote:
> ...
> > Therefore, I think this patch goes in exactly the wrong direction. I
> > mean, if you want to introduce dynamic patching as a means for making
> > the crypto API's dynamic dis
On Fri, Oct 5, 2018 at 10:11 AM Ard Biesheuvel
wrote:
>
> On 5 October 2018 at 18:58, Andy Lutomirski wrote:
> > On Fri, Oct 5, 2018 at 8:24 AM Ard Biesheuvel
> > wrote:
> >>
> >> On 5 October 2018 at 17:08, Andy Lutomirski wrote:
> >> >
On Fri, Oct 5, 2018 at 8:24 AM Ard Biesheuvel wrote:
>
> On 5 October 2018 at 17:08, Andy Lutomirski wrote:
> >
> >
> >> On Oct 5, 2018, at 7:14 AM, Peter Zijlstra wrote:
> >>
> >>> On Fri, Oct 05, 2018 at 10:13:25AM +0200, Ard Biesheuvel wrote:
> On Oct 5, 2018, at 7:14 AM, Peter Zijlstra wrote:
>
>> On Fri, Oct 05, 2018 at 10:13:25AM +0200, Ard Biesheuvel wrote:
>> diff --git a/include/linux/ffp.h b/include/linux/ffp.h
>> new file mode 100644
>> index ..8fc3b4c9b38f
>> --- /dev/null
>> +++ b/include/linux/ffp.h
>> @@ -0,
> On Sep 29, 2018, at 9:20 PM, Joe Perches wrote:
>
>> On Fri, 2018-09-28 at 16:01 +0200, Jason A. Donenfeld wrote:
>> On Fri, Sep 28, 2018 at 4:00 PM Ard Biesheuvel
>> wrote:
>>>
On 28 September 2018 at 15:59, Jason A. Donenfeld wrote:
On Fri, Sep 28, 2018 at 3:58 PM Ard Biesheuv
> On Sep 27, 2018, at 8:19 AM, Jason A. Donenfeld wrote:
>
> Hey again Thomas,
>
>> On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote:
>>
>> Hi Thomas,
>>
>> I'm trying to optimize this for crypto performance while still taking
>> into account preemption concerns. I'm having a bit o
> On Sep 26, 2018, at 10:03 AM, Jason A. Donenfeld wrote:
>
>> On Wed, Sep 26, 2018 at 6:21 PM Andy Lutomirski wrote:
>> Are, is what you’re saying that the Zinc chacha20 functions should call
>> simd_relax() every n bytes automatically for some reasonable value
> On Sep 26, 2018, at 7:02 AM, Ard Biesheuvel wrote:
>
> (+ Herbert, Thomas)
>
>> On Wed, 26 Sep 2018 at 15:33, Jason A. Donenfeld wrote:
>>
>> Hi Ard,
>> .
>
>> And if it becomes one,
>> this is something we can address *later*, but certainly there's no use
>> of adding additional complex
> On Sep 25, 2018, at 12:43 PM, Jason A. Donenfeld wrote:
>
>> On Tue, Sep 25, 2018 at 8:33 PM Joe Perches wrote:
>> I think the -Dpr_fmt is especially odd and not
>> really acceptable as it not used anywhere else
>> in the kernel.
>
> There are about 2000 cases in the kernel of the same '#d
> On Sep 20, 2018, at 9:30 PM, Ard Biesheuvel wrote:
>
>> On 20 September 2018 at 21:15, Jason A. Donenfeld wrote:
>> Hi Andy,
>>
>>> On Fri, Sep 21, 2018 at 5:23 AM Andy Lutomirski wrote:
>>> At the risk on suggesting something awful: on x86_64,
> On Sep 20, 2018, at 8:12 PM, Andrew Lunn wrote:
>
>> On Fri, Sep 21, 2018 at 02:11:43AM +0200, Jason A. Donenfeld wrote:
>> Hey Arnd,
>>
>>> On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann wrote:
>>> Right, if you hit a stack requirement like this, it's usually the compiler
>>> doing somethin
> On Sep 20, 2018, at 8:41 AM, Ard Biesheuvel wrote:
>
> (+ Arnd, Eric)
>
> On 18 September 2018 at 09:16, Jason A. Donenfeld wrote:
> ...
>
>> diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
>> new file mode 100644
>> index ..83dfd63988c0
>> --- /dev/null
>> +++ b/lib/zinc/M
> On Sep 18, 2018, at 6:35 PM, Jason A. Donenfeld wrote:
>
>> On Wed, Sep 19, 2018 at 2:50 AM Eric Biggers wrote:
>> Hardcoding the 'input' array to 600 bytes forces the full amount of space to
>> be
>> reserved in the kernel image for every test vector. Also, if anyone adds a
>> longer test
> On Sep 17, 2018, at 9:16 AM, Jason A. Donenfeld wrote:
>
>> On Mon, Sep 17, 2018 at 6:14 PM Andy Lutomirski wrote:
>> Indeed. What I'm saying is that you shouldn't refactor it this way
>> because it will be slow. I agree it would be conceptually
On Mon, Sep 17, 2018 at 8:32 AM Jason A. Donenfeld wrote:
>
> On Mon, Sep 17, 2018 at 4:52 PM Andy Lutomirski wrote:
> > I think the module organization needs to change. It needs to be possible to
> > have chacha20 built in but AES or whatever as a module.
>
> Okay, I&#x
> On Sep 17, 2018, at 8:28 AM, Jason A. Donenfeld wrote:
>
> On Mon, Sep 17, 2018 at 4:52 PM Andy Lutomirski wrote:
>>> * (Nit) The GCC command line -include'd .h files contain variable and
>>> function definitions so they are actually .c files.
>>
>>
> On Sep 16, 2018, at 9:45 PM, David Miller wrote:
>
> From: Andy Lutomirski
> Date: Sun, 16 Sep 2018 21:09:11 -0700
>
>> CRYPTO API
>> M: Herbert Xu
>> M: "David S. Miller"
>> L: linux-crypto@vger.kernel.org
>>
>>
> On Sep 16, 2018, at 10:07 PM, Jason A. Donenfeld wrote:
>
> Hey Andy,
>
> Thanks a lot for your feedback.
>
>> On Mon, Sep 17, 2018 at 6:09 AM Andy Lutomirski wrote:
>> 1. Zinc conflates the addition of a new API with the replacement of
>> some
> On Sep 16, 2018, at 10:26 PM, Ard Biesheuvel
> wrote:
>
> As far as I can tell (i.e., as a user not a network dev), WireGuard is
> an excellent piece of code, and I would like to see it merged. I also
> think there is little disagreement about the quality of the proposed
> algorithm implem
On Tue, Sep 11, 2018 at 4:57 PM David Miller wrote:
>
> From: Andrew Lunn
> Date: Wed, 12 Sep 2018 01:30:15 +0200
>
> > Just as an FYI:
> >
> > 1) I don't think anybody in netdev has taken a serious look at the
> > network code yet. There is little point until the controversial part
> > of the co
> On Sep 12, 2018, at 11:39 PM, Milan Broz wrote:
>
>> On 13/09/18 01:45, Andy Lutomirski wrote:
>> On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel
> ...
>> b) Crypto that is used dynamically. This includes dm-crypt
>> (aes-xts-plain64, aes-cbc-essiv, e
On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel
wrote:
> I realize you've put a lot of good and hard work into the existing
> I am also concerned about your claim that all software algorithms will
> be moved into this crypto library. You are not specific about whose
> responsibility it will be tha
> On Sep 11, 2018, at 3:18 PM, Jason A. Donenfeld wrote:
>
>> On Tue, Sep 11, 2018 at 4:16 PM Andy Lutomirski wrote:
>> Jason, can you do one of these conversions as an example?
>
> My preference is really to leave that to a different patch series. But
> if you t
> On Sep 11, 2018, at 2:47 PM, Eric Biggers wrote:
>
>> On Tue, Sep 11, 2018 at 04:56:24PM +0200, Greg Kroah-Hartman wrote:
>> On Tue, Sep 11, 2018 at 12:08:56PM +0200, Ard Biesheuvel wrote:
As Zinc is simply library code, its config options are un-menued, with
the exception of CONFI
On Tue, Aug 7, 2018 at 6:51 PM, Jason A. Donenfeld wrote:
> On Tue, Aug 7, 2018 at 6:49 PM Andy Lutomirski wrote:
>> I really wish we had a way to see that we use asm-generic’s copy of a header
>> in all cases except where an arch opts out.
>
> It's really not that
> On Aug 7, 2018, at 4:48 PM, Jason A. Donenfeld wrote:
>
> Hey Andy,
>
>> On Tue, Aug 7, 2018 at 12:43 PM Andy Lutomirski wrote:
>> For "zinc: add simd helper", I think it should be in include/linux,
>> and include/linux/simd.h should (immediatel
On Tue, Aug 7, 2018 at 11:54 AM, Jason A. Donenfeld wrote:
> Hey Andy, Eric, & all,
>
> I've started the work of separating this out into 16 individual
> commits, have addressed numerous other things brought up like the
> ifdef maze, and have begun rewriting (parts of) the original commit
> messag
On Thu, Aug 2, 2018 at 7:48 PM, Jason A. Donenfeld wrote:
> Hey Andy,
>
> Thanks too for the feedback. Responses below:
>
> On Wed, Aug 1, 2018 at 7:09 PM Andy Lutomirski wrote:
>> > I think the above changes would also naturally lead to a much saner
>> > pat
[I reordered the snippets below for readability.]
> On Aug 1, 2018, at 12:22 AM, Eric Biggers wrote:
> In general this is great work, and I'm very excited for WireGuard to be
> upstreamed! But for the new crypto code, I think a few things are on
> the wrong track, for example treating it is a sp
On Fri, Oct 13, 2017 at 12:09 PM, Linus Torvalds
wrote:
> On Fri, Oct 13, 2017 at 6:56 AM, Andrey Ryabinin
> wrote:
>>
>> This could be fixed by s/vmovdqa/vmovdqu change like bellow, but maybe the
>> right fix
>> would be to align the data properly?
>
> I suspect anything that has the SHA extens
On Mon, Oct 2, 2017 at 10:26 PM, Herbert Xu wrote:
> On Mon, Oct 02, 2017 at 09:18:24PM -0700, Andy Lutomirski wrote:
>> > On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai wrote:
>> >
>> > The SCTP program may sleep under a spinlock, and the function call path is:
>> &
> On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai wrote:
>
> The SCTP program may sleep under a spinlock, and the function call path is:
> sctp_generate_t3_rtx_event (acquire the spinlock)
> sctp_do_sm
>sctp_side_effects
> sctp_cmd_interpreter
>sctp_make_init_ack
> sctp_pack_cook
On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf wrote:
> On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
>> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote:
>> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>> >> On Thu, J
On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote:
> On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
>> wrote:
>> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf
>> > wrote:
>> &
On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
wrote:
> On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote:
>>
>> Just to clarify, I think you're asking if, for versions of gcc which
>> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
>> functions to ensure their stacks
On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu
wrote:
> On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
>>
>> I'm pretty sure we have random asm code that may not maintain a
>> 16-byte stack alignment when it calls other code (including, in some
>> cases, calling C code).
>>
>> So I'
On Wed, Jan 11, 2017 at 11:47 PM, Herbert Xu
wrote:
> Andy Lutomirski wrote:
>> There are some hashes (e.g. sha224) that have some internal trickery
>> to make sure that only the correct number of output bytes are
>> generated. If something goes wrong, they could poten
On Tue, Jan 10, 2017 at 10:01 PM, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu
> wrote:
>> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
>>>
>>> That said, I do think that the "don't assume stack alignment, d
On Wed, Jan 11, 2017 at 12:09 AM, Herbert Xu
wrote:
> On Wed, Jan 11, 2017 at 08:06:54AM +, Ard Biesheuvel wrote:
>>
>> Couldn't we update the __aligned(x) macro to emit 32 if arch == x86
>> and x == 16? All other cases should work just fine afaict
>
> Not everyone uses that macro. You'd also
On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann wrote:
> Hi Andy,
>
> On 01/11/2017 04:11 AM, Andy Lutomirski wrote:
>>
>> On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann
>> wrote:
>>>
>>> On 01/11/2017 12:24 AM, Andy Lutomirski wrote:
>>>
On Wed, Jan 11, 2017 at 7:13 AM, David Laight wrote:
> From: Andy Lutomirski
>> Sent: 10 January 2017 23:25
>> There are some hashes (e.g. sha224) that have some internal trickery
>> to make sure that only the correct number of output bytes are
>> generated. If somet
On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu wrote:
> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
>>
>> That said, I do think that the "don't assume stack alignment, do it by
>> hand" may be the safer thing. Because who knows what the random rules
>> will be on other architectur
On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann wrote:
> On 01/11/2017 12:24 AM, Andy Lutomirski wrote:
>>
>> This makes it easier to add another digest algorithm down the road if
>> needed. It also serves to force any programs that might have been
>> written agains
as no released kernel
has ever had TCA*BPF_DIGEST.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Andy Lutomirski
---
include/uapi/linux/pkt_cls.h | 2 +-
include/uapi/linux/tc_act/tc_bpf.h | 2 +-
net/sched/act_bpf.c| 2 +-
net/sched/cls_bpf.c
calling vmalloc().
I moved the digest field to keep all of the bpf program metadata in
the same cache line.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Andy Lutomirski
---
include/linux/filter.h | 11 +++
init/Kconfig | 1 +
kernel/bpf/core.c | 42
ad 'prog_digest'.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Andy Lutomirski
---
kernel/bpf/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index e89acea22ecf..956370b80296 100644
--- a/kernel/bpf/s
On Tue, Jan 10, 2017 at 12:00 PM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 19:22, Andy Lutomirski wrote:
>> On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel
>> wrote:
>>> On 10 January 2017 at 19:00, Andy Lutomirski wrote:
>>>> On Tue, Jan 10, 2017 at
hould be a considerable speedup as vmalloc() is quite
slow.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Andy Lutomirski
---
kernel/bpf/core.c | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/co
This just moves code around -- no code changes in this patch. This
wil let BPF-based tracing link against the SHA256 core code without
depending on the crypto core.
Cc: Ard Biesheuvel
Cc: Herbert Xu
Signed-off-by: Andy Lutomirski
---
crypto/Kconfig | 8 ++
crypto/Makefile
output size so that memory debugging will catch the error if
the output is overrun.
Tested by intentionally breaking sha224 to output all 256
internally-generated bits while running on KASAN.
Cc: Ard Biesheuvel
Cc: Herbert Xu
Signed-off-by: Andy Lutomirski
---
crypto/testmgr.c | 9 +
1 file
depend on
crypto.
Cc: Ard Biesheuvel
Cc: Herbert Xu
Signed-off-by: Andy Lutomirski
---
crypto/sha256_generic.c | 31 ++-
include/crypto/sha.h | 24
include/crypto/sha256_base.h | 13 -
3 files changed, 50 insertions
o. I haven't yet because I
wanted to minimize churn. Also, the changes will be essentially
identical to the SHA-256 changes and I want to get the latter
reviewed first.
Andy Lutomirski (8):
crypto/sha256: Factor out the parts of base API that don't use
shash_desc
crypto/s
I want to expose a minimal SHA256 API that can be used without the
depending on the crypto core. To prepare for this, factor out the
meat of the sha256_base_*() helpers.
Cc: Ard Biesheuvel
Cc: Herbert Xu
Signed-off-by: Andy Lutomirski
---
include/crypto/sha256_base.h | 53
On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 14:33, Herbert Xu wrote:
>> I recently applied the patch
>>
>> https://patchwork.kernel.org/patch/9468391/
>>
>> and ended up with a boot crash when it tried to run the x86 chacha20
>> code. It turned out that
On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 19:00, Andy Lutomirski wrote:
>> On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
>> wrote:
>>> On 10 January 2017 at 14:33, Herbert Xu wrote:
>>>> I recently appli
;
> So I'm not at all convinced that this is a good idea. We shouldn't
> expect 16-byte alignment to be something trustworthy.
>
> Linus
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe l
On Tue, Dec 27, 2016 at 6:16 AM, Daniel Borkmann wrote:
> On 12/27/2016 10:58 AM, Herbert Xu wrote:
>>
>> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>>>
>>>
>>> According to Daniel, the networking folks want to let embedded sys
On Mon, Dec 26, 2016 at 5:36 PM, Alexei Starovoitov
wrote:
> On Sat, Dec 24, 2016 at 08:59:53PM +0100, Daniel Borkmann wrote:
>> On 12/24/2016 03:22 AM, Andy Lutomirski wrote:
>> >BPF digests are intended to be used to avoid reloading programs that
>> >are already l
On Mon, Dec 26, 2016 at 9:51 AM, Ard Biesheuvel
wrote:
> On 26 December 2016 at 07:57, Herbert Xu wrote:
>> On Sat, Dec 24, 2016 at 09:57:53AM -0800, Andy Lutomirski wrote:
>>>
>>> I actually do use incremental hashing later on. BPF currently
>>> vmallocs
On Sat, Dec 24, 2016 at 2:33 AM, Ard Biesheuvel
wrote:
> Hi Andy,
>
> On 24 December 2016 at 02:22, Andy Lutomirski wrote:
>> There are some pieecs of kernel code that want to compute SHA256
>> directly without going through the crypto core. Adjust the exported
>>
On Fri, Dec 23, 2016 at 6:22 PM, Andy Lutomirski wrote:
> There are some pieecs of kernel code that want to compute SHA256
> directly without going through the crypto core. Adjust the exported
> API to decouple it from the crypto core.
>
> I suspect this will very slightly spee
same cache line.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Andy Lutomirski
---
include/linux/filter.h | 11 +++
init/Kconfig | 1 +
kernel/bpf/core.c | 41 +++--
3 files changed, 11 insertions(+), 42 deletions(-)
diff
This will let other kernel code call into sha256_init(), etc. without
pulling in the core crypto code.
Signed-off-by: Andy Lutomirski
---
crypto/Kconfig | 8
crypto/Makefile | 2 +-
crypto/sha256_generic.c | 4
include/crypto/sha.h| 4
4 files changed, 17
involved.
Cc: Ard Biesheuvel
Cc: Herbert Xu
Signed-off-by: Andy Lutomirski
---
arch/arm/crypto/sha2-ce-glue.c | 10 ---
arch/arm/crypto/sha256_glue.c | 23 ++-
arch/arm/crypto/sha256_neon_glue.c | 34 +++--
arch/arm64/crypto/sha2-ce-glue.c| 13
hould be a considerable speedup as vmalloc() is quite
slow.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Andy Lutomirski
---
kernel/bpf/core.c | 34 ++
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/co
ad 'prog_digest'.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Andy Lutomirski
---
kernel/bpf/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index e89acea22ecf..956370b80296 100644
--- a/kernel/bpf/s
as no released kernel
has ever had TCA*BPF_DIGEST.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Andy Lutomirski
---
include/uapi/linux/pkt_cls.h | 2 +-
include/uapi/linux/tc_act/tc_bpf.h | 2 +-
net/sched/act_bpf.c| 2 +-
net/sched/cls_bpf.c
4.10. If this series misses 4.10 and nothing
takes its place, then we'll have an unpleasant ABI stability
situation.
Andy Lutomirski (6):
crypto/sha256: Refactor the API so it can be used without shash
crypto/sha256: Make the sha256 library functions selectable
bpf: Use SHA256 instead of
On Fri, Dec 23, 2016 at 8:23 AM, Andy Lutomirski wrote:
> On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann wrote:
>> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
>>>
>>> On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
>>>>
>>>>
On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann wrote:
> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
>>
>> On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
>>>
>>> On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
>>>>
>>&g
On Thu, Dec 22, 2016 at 11:34 AM, Alexei Starovoitov
wrote:
> On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote:
>> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
>> wrote:
>>> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>>>
>>
On Thu, Dec 22, 2016 at 11:24 AM, George Spelvin
wrote:
>> Having slept on this, I like it less. The problem is that a
>> backtracking attacker doesn't just learn H(random seed || entropy_0 ||
>> secret || ...) -- they learn the internal state of the hash function
>> that generates that value. T
On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
wrote:
> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
>> wrote:
>> > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
>> >
On Thu, Dec 22, 2016 at 8:28 AM, Jason A. Donenfeld wrote:
> Hi all,
>
> I don't know what your design requirements are for this. It looks like
> you're generating some kind of crypto digest of a program, and you
> need to avoid collisions. If you'd like to go with a PRF (keyed hash
> function) th
On Wed, Dec 21, 2016 at 6:07 PM, Andy Lutomirski wrote:
> On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin
> wrote:
>> As a separate message, to disentangle the threads, I'd like to
>> talk about get_random_long().
>>
>> After some thinking, I still like the &qu
On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
wrote:
> On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
>> Hi Hannes,
>>
>> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
>> wrote:
>> > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
>> > You don't
On Wed, Dec 21, 2016 at 9:01 PM, George Spelvin
wrote:
> Andy Lutomirski wrote:
>> I don't even think it needs that. This is just adding a
>> non-destructive final operation, right?
>
> It is, but the problem is that SipHash is intended for *small* inputs,
> so
On Wed, Dec 21, 2016 at 6:07 PM, Hannes Frederic Sowa
wrote:
> On 22.12.2016 00:42, Andy Lutomirski wrote:
>> On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote:
>>> unsigned int get_random_int(void)
>>> {
>>> - __u32 *hash;
>>> -
On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin
wrote:
> As a separate message, to disentangle the threads, I'd like to
> talk about get_random_long().
>
> After some thinking, I still like the "state-preserving" construct
> that's equivalent to the current MD5 code. Yes, we could just do
> sipha
On Wed, Dec 21, 2016 at 9:25 AM, Linus Torvalds
wrote:
> On Wed, Dec 21, 2016 at 7:55 AM, George Spelvin
> wrote:
>>
>> How much does kernel_fpu_begin()/kernel_fpu_end() cost?
>
> It's now better than it used to be, but it's absolutely disastrous
> still. We're talking easily many hundreds of cyc
On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote:
> unsigned int get_random_int(void)
> {
> - __u32 *hash;
> - unsigned int ret;
> -
> - if (arch_get_random_int(&ret))
> - return ret;
> -
> - hash = get_cpu_var(get_random_int_hash);
> -
> - ha
1 - 100 of 155 matches
Mail list logo
