Hi Denis,
On Thu, May 24, 2018 at 07:56:50PM -0500, Denis Kenzior wrote:
> Hi Ted,
>
> > > I'm not really here to criticize or judge the past. AF_ALG exists now. It
> > > is being used. Can we just make it better? Or are we going to whinge at
> > > every user that tries to use (and improve) ke
Hi Ted,
I'm not really here to criticize or judge the past. AF_ALG exists now. It
is being used. Can we just make it better? Or are we going to whinge at
every user that tries to use (and improve) kernel features that (some)
people disagree with because it can 'compromise' kernel security?
One more thought about why userspace using AF_ALG is a bad idea ---
there is no guarantee that all kernels will have all of the crypto
algorithms you need built into the kernel. People who build custom
kernels very often only include those kernel modules they need. So by
default I don't normally
On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote:
>
> But seriously, how is it a fault of the 'random person on the mailing list'
> that AF_ALG exists and is being used for its (seemingly intended) purpose?
>
> I'm not really here to criticize or judge the past. AF_ALG exists now. I
Hi Ted,
On 05/24/2018 06:25 PM, Theodore Y. Ts'o wrote:
On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote:
Actually for the use case we have, speed is something pretty low on the
priority list; not having to deal with userspace crypto library dependencies
was a goal in and of itself
On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote:
> Actually for the use case we have, speed is something pretty low on the
> priority list; not having to deal with userspace crypto library dependencies
> was a goal in and of itself. Each one has its own issues and you can never
> sup
Hi Ted,
On 05/24/2018 04:05 PM, Theodore Y. Ts'o wrote:
Has anyone actually done the experiment and verified that it was in
fact a win to use AF_ALG on at least _some_ platform? What about the
common cast for most platforms, even those that had some kind of
hardware accleration that could only
On Thu, May 24, 2018 at 12:11:35PM -0500, Denis Kenzior wrote:
>
> Well, I'm not sure where the laziness comment is coming from. We have at
> least two user-space implementations that implement PBKDF on top of AF_ALG.
> But a typical invocation of PBKDF runs a couple of thousand iterations.
> Tha
Hi Eric,
No, we don't add random code to the kernel just because people are lazy. IMO it
was a mistake that AF_ALG allows access to software crypto implementations by
default (as opposed to just hardware crypto devices), but it's not an excuse to
I understand, but my point is, AF_ALG is out t
On Thu, May 24, 2018 at 09:36:15AM -0500, Denis Kenzior wrote:
> Hi Stephan,
>
> On 05/24/2018 12:57 AM, Stephan Mueller wrote:
> > Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
> >
> > Hi Eric,
> >
> > >
> > > "Not having to rely on any third-party library" is not an excuse
Hi Stephan,
On 05/24/2018 12:57 AM, Stephan Mueller wrote:
Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
Hi Eric,
"Not having to rely on any third-party library" is not an excuse to add
random code to the kernel, which runs in a privileged context. Please do
PBKDF2 in use
Use managed clock handling, differentiate between no clock (possibly OK)
and clock init failure (never OK) and correctly handle clock detection
being deferred.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccree/cc_driver.c | 20 +++-
1 file
The cache parameter register configuration was being too verbose.
Use dev_dbg() to only provide the information if needed.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccree/cc_driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/ccree/cc_driver
Add bindings for CryptoCell instance in the SoC.
Signed-off-by: Gilad Ben-Yossef
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index d842940..3ac75db 1
This patch adds the clock used by the CryptoCell 630p instance in the SoC.
Signed-off-by: Gilad Ben-Yossef
---
This patch depends upon the "clk: renesas: r8a7795: Add CR clock" patch
from Geert Uytterhoeven.
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --g
The patch set enables the use of CryptoCell found in some Renesas R-Car
Salvator-X boards and fixes some driver issues uncovered that prevented
to work properly.
Changes from v1:
- Properly fix the bug that caused us to read a bad signature register
rather than dropping the check
- Proper DT fie
The product signature and HW revision register have different offset on the
older HW revisions.
This fixes the problem of the driver failing sanity check on silicon
despite working on the FPGA emulation systems.
Fixes: 27b3b22dd98c ("crypto: ccree - add support for older HW revs")
Cc: sta...@vger.
Hi Gilad,
On Thu, May 24, 2018 at 3:20 PM, Gilad Ben-Yossef wrote:
> On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven
> wrote:
>> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef
>> wrote:
>>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
>>> wrote:
Indeed. From a quick glance
On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven
wrote:
> Hi Gilad,
>
> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef wrote:
>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
>> wrote:
>>> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
>>> does not disti
It includes Fixes and cleanup .
Harsh Jain (3):
crypto:chelsio:Return -ENOSPC for transient busy indication.
crypt:chelsio:Send IV as Immediate for cipher algo
crypto:chelsio: Remove separate buffer used for DMA map B0 block in
CCM
drivers/crypto/chelsio/chcr_algo.c | 303 +++
Change the return type based on following patch
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg28552.html
Signed-off-by: Harsh Jain
---
drivers/crypto/chelsio/chcr_algo.c | 56 ++
1 file changed, 26 insertions(+), 30 deletions(-)
diff --git a/dr
Send IV in WR as immediate instead of dma mapped entry for cipher.
Signed-off-by: Harsh Jain
---
drivers/crypto/chelsio/chcr_algo.c | 49 +++-
drivers/crypto/chelsio/chcr_algo.h | 3 +--
drivers/crypto/chelsio/chcr_core.h | 2 +-
drivers/crypto/chelsio/chc
Extends memory required for IV to include B0 Block and DMA map in
single operation.
Signed-off-by: Harsh Jain
---
drivers/crypto/chelsio/chcr_algo.c | 198 ---
drivers/crypto/chelsio/chcr_crypto.h | 12 +--
2 files changed, 97 insertions(+), 113 deletions(-)
d
On Thursday, May 24, 2018 11:36:04 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki:
>
> Hi Rafael,
>
> > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysoc
Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki:
Hi Rafael,
> On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
> >
> > Hi Rafael,
>
> Hi Stephan,
>
> > > So the problem is that Yu wo
On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
>
> Hi Rafael,
Hi Stephan,
> > So the problem is that Yu would like to use this for hibernation encryption
> > done entirely in the kernel.
>
> But why do yo
Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
Hi Rafael,
> So the problem is that Yu would like to use this for hibernation encryption
> done entirely in the kernel.
But why do you need to perform PBKDF in kernel space?
If you retain the password information in the kerne
On Thursday, May 24, 2018 7:57:37 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
>
> Hi Eric,
>
> >
> > "Not having to rely on any third-party library" is not an excuse to add
> > random code to the kernel, which runs in a privileged context. P
28 matches
Mail list logo
