Re: [PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst
On Mon, May 07, 2018 at 06:35:39AM -0300, Mauro Carvalho Chehab wrote: > A number of new docs were added, but they're currently not on > the index.rst from the session they're supposed to be, causing > Sphinx warnings. > > Add them. > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Greg Kroah-Hartman
[PATCH v2] fscrypt: add Speck128/256 support
fscrypt currently only supports AES encryption. However, many low-end mobile devices have older CPUs that don't have AES instructions, e.g. the ARMv8 Cryptography Extensions. Currently, user data on such devices is not encrypted at rest because AES is too slow, even when the NEON bit-sliced implementation of AES is used. Unfortunately, it is infeasible to encrypt these devices at all when AES is the only option. Therefore, this patch updates fscrypt to support the Speck block cipher, which was recently added to the crypto API. The C implementation of Speck is not especially fast, but Speck can be implemented very efficiently with general-purpose vector instructions, e.g. ARM NEON. For example, on an ARMv7 processor, we measured the NEON-accelerated Speck128/256-XTS at 69 MB/s for both encryption and decryption, while AES-256-XTS with the NEON bit-sliced implementation was only 22 MB/s encryption and 19 MB/s decryption. There are multiple variants of Speck. This patch only adds support for Speck128/256, which is the variant with a 128-bit block size and 256-bit key size -- the same as AES-256. This is believed to be the most secure variant of Speck, and it's only about 6% slower than Speck128/128. Speck64/128 would be at least 20% faster because it has 20% rounds, and it can be even faster on CPUs that can't efficiently do the 64-bit operations needed for Speck128. However, Speck64's 64-bit block size is not preferred security-wise. ARM NEON also supports the needed 64-bit operations even on 32-bit CPUs, resulting in Speck128 being fast enough for our targeted use cases so far. The chosen modes of operation are XTS for contents and CTS-CBC for filenames. These are the same modes of operation that fscrypt defaults to for AES. Note that as with the other fscrypt modes, Speck will not be used unless userspace chooses to use it. Nor are any of the existing modes (which are all AES-based) being removed, of course. We intentionally don't make CONFIG_FS_ENCRYPTION select CONFIG_CRYPTO_SPECK, so people will have to enable Speck support themselves if they need it. This is because we shouldn't bloat the FS_ENCRYPTION dependencies with every new cipher, especially ones that aren't recommended for most users. Moreover, CRYPTO_SPECK is just the generic implementation, which won't be fast enough for many users; in practice, they'll need to enable CRYPTO_SPECK_NEON to get acceptable performance. More details about our choice of Speck can be found in our patches that added Speck to the crypto API, and the follow-on discussion threads. We're planning a publication that explains the choice in more detail. But briefly, we can't use ChaCha20 as we previously proposed, since it would be insecure to use a stream cipher in this context, with potential IV reuse during writes on f2fs and/or on wear-leveling flash storage. We also evaluated many other lightweight and/or ARX-based block ciphers such as Chaskey-LTS, RC5, LEA, CHAM, Threefish, RC6, NOEKEON, SPARX, and XTEA. However, all had disadvantages vs. Speck, such as insufficient performance with NEON, much less published cryptanalysis, or an insufficient security level. Various design choices in Speck make it perform better with NEON than competing ciphers while still having a security margin similar to AES, and in the case of Speck128 also the same available security levels. Unfortunately, Speck does have some political baggage attached -- it's an NSA designed cipher, and was rejected from an ISO standard (though for context, as far as I know none of the above-mentioned alternatives are ISO standards either). Nevertheless, we believe it is a good solution to the problem from a technical perspective. Certain algorithms constructed from ChaCha or the ChaCha permutation, such as MEM (Masked Even-Mansour) or HPolyC, may also meet our performance requirements. However, these are new constructions that need more time to receive the cryptographic review and acceptance needed to be confident in their security. HPolyC hasn't been published yet, and we are concerned that MEM makes stronger assumptions about the underlying permutation than the ChaCha stream cipher does. In contrast, the XTS mode of operation is relatively well accepted, and Speck has over 70 cryptanalysis papers. Of course, these ChaCha-based algorithms can still be added later if they become ready. The best known attack on Speck128/256 is a differential cryptanalysis attack on 25 of 34 rounds with 2^253 time complexity and 2^125 chosen plaintexts, i.e. only marginally faster than brute force. There is no known attack on the full 34 rounds. Signed-off-by: Eric Biggers --- Changed since v1: - Improved commit message and documentation. Documentation/filesystems/fscrypt.rst | 10 ++ fs/crypto/fscrypt_private.h | 4 fs/crypto/keyinfo.c | 2 ++ include/uapi/linux/fs.h | 2 ++ 4 files changed, 18 insertions(+) diff --git a/Documenta
Re: [PATCH v2 0/5] crypto: Speck support
Hi Samuel, On Thu, Apr 26, 2018 at 03:05:44AM +0100, Samuel Neves wrote: > On Wed, Apr 25, 2018 at 8:49 PM, Eric Biggers wrote: > > I agree that my explanation should have been better, and should have > > considered > > more crypto algorithms. The main difficulty is that we have extreme > > performance > > requirements -- it needs to be 50 MB/s at the very least on even low-end ARM > > devices like smartwatches. And even with the NEON-accelerated Speck128-XTS > > performance exceeding that after much optimization, we've been getting a > > lot of > > pushback as people want closer to 100 MB/s. > > > > I couldn't find any NEON-capable ARMv7 chip below 800 MHz, so this > would put the performance upper bound around 15 cycles per byte, with > the comfortable number being ~7. That's indeed tough, though not > impossible. > > > > > That's why I also included Speck64-XTS in the patches, since it was > > straightforward to include, and some devices may really need that last > > 20-30% of > > performance for encryption to be feasible at all. (And when the choice is > > between unencrypted and a 64-bit block cipher, used in a context where the > > weakest points in the cryptosystem are actually elsewhere such as the user's > > low-entropy PIN and the flash storage doing wear-leveling, I'd certainly > > take > > the 64-bit block cipher.) So far we haven't had to use Speck64 though, and > > if > > that continues to be the case I'd be fine with Speck64 being removed, > > leaving > > just Speck128. > > > > I would very much prefer that to be the case. As many of us know, > "it's better than nothing" has been often used to justify other bad > choices, like RC4, that end up preventing better ones from being > adopted. At a time where we're trying to get rid of 64-bit ciphers in > TLS, where data volumes per session are comparatively low, it would be > unfortunate if the opposite starts happening on encryption at rest. > > > > > Note that in practice, to have any chance at meeting the performance > > requirement > > the cipher needed to be NEON accelerated. That made benchmarking really > > hard > > and time-consuming, since to definitely know how an algorithm performs it > > can > > take upwards of a week to implement a NEON version. It needs to be very > > well > > optimized too, to compare the algorithms fairly -- e.g. with Speck I got a > > 20% > > performance improvement on some CPUs just by changing the NEON instructions > > used > > to implement the 8-bit rotates, an optimization that is not possible with > > ciphers that don't use rotate amounts that are multiples of 8. (This was an > > intentional design choice by the Speck designers; they do know what they're > > doing, actually.) > > > > Thus, we had to be pretty aggressive about dropping algorithms from > > consideration if there were preliminary indications that they wouldn't > > perform > > well, or had too little cryptanalysis, or had other issues such as an > > unclear > > patent situation. Threefish for example I did test the C implementation at > > https://github.com/wernerd/Skein3Fish, but on ARM32 it was over 4 times > > slower > > than my NEON implementation of Speck128/256-XTS. And I did not see a clear > > way > > that it could be improved over 4x with NEON, if at all, so I did not take > > the > > long time it would have taken to write an optimized NEON implementation to > > benchmark it properly. Perhaps that was a mistake. But, time is not > > unlimited. > > > > In my limited experience with NEON and 64-bit ARX, there's usually a > ~2x speedup solely from NEON's native 64-bit operations on ARMv7-A. > The extra speedup from encrypting 2 block in parallel is then > somewhere between 1x and 2x, depending on various details. Getting > near 4x might be feasible, but it is indeed time-consuming to get > there. > > > > > As for the wide-block mode using ChaCha20 and Poly1305, you'd have to ask > > Paul > > Crowley to explain it properly, but briefly it's actually a pseudorandom > > permutation over an arbitrarily-sized message. So with dm-crypt for > > example, it > > would operate on a whole 512-byte sector, and if any bit of the 512-byte > > plaintext is changed, then every bit in the 512-byte ciphertext would change > > with 50% probability. To make this possible, the construction uses a > > polynomial > > evalution in GF(2^130-5) as a universal hash function, similar to the > > Poly1305 > > mode. > > > > Oh, OK, that sounds like something resembling Naor-Reingold or its > relatives. That would work, but with 3 or 4 passes I guess it wouldn't > be very fast. > > > > > Using ChaCha20's underlying 512-bit permutation to build a tweakable block > > cipher is an interesting idea. But maybe in my crypto-naivety, it is not > > obvious to me how to do so. Do you have references to any relevant papers? > > Remember that we strongly prefer a published cipher to a custom one -- even > > if > > the core is reused,
[PATCH v17 3/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}
In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq and writeq are defined. If they are not, then the wrappers that always use non-atomic operations from include/linux/io-64-nonatomic*.h will be used. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Arnd Bergmann Cc: Suresh Warrier Cc: Nicholas Piggin --- arch/powerpc/include/asm/io.h | 2 + include/asm-generic/iomap.h | 26 +++-- lib/iomap.c | 132 ++ 3 files changed, 154 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h index af074923d598..4cc420cfaa78 100644 --- a/arch/powerpc/include/asm/io.h +++ b/arch/powerpc/include/asm/io.h @@ -788,8 +788,10 @@ extern void __iounmap_at(void *ea, unsigned long size); #define mmio_read16be(addr)readw_be(addr) #define mmio_read32be(addr)readl_be(addr) +#define mmio_read64be(addr)readq_be(addr) #define mmio_write16be(val, addr) writew_be(val, addr) #define mmio_write32be(val, addr) writel_be(val, addr) +#define mmio_write64be(val, addr) writeq_be(val, addr) #define mmio_insb(addr, dst, count)readsb(addr, dst, count) #define mmio_insw(addr, dst, count)readsw(addr, dst, count) #define mmio_insl(addr, dst, count)readsl(addr, dst, count) diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h index 5b63b94ef6b5..5a4af0199b32 100644 --- a/include/asm-generic/iomap.h +++ b/include/asm-generic/iomap.h @@ -31,9 +31,16 @@ extern unsigned int ioread16(void __iomem *); extern unsigned int ioread16be(void __iomem *); extern unsigned int ioread32(void __iomem *); extern unsigned int ioread32be(void __iomem *); -#ifdef CONFIG_64BIT -extern u64 ioread64(void __iomem *); -extern u64 ioread64be(void __iomem *); + +#ifdef readq +#define ioread64_lo_hi ioread64_lo_hi +#define ioread64_hi_lo ioread64_hi_lo +#define ioread64be_lo_hi ioread64be_lo_hi +#define ioread64be_hi_lo ioread64be_hi_lo +extern u64 ioread64_lo_hi(void __iomem *addr); +extern u64 ioread64_hi_lo(void __iomem *addr); +extern u64 ioread64be_lo_hi(void __iomem *addr); +extern u64 ioread64be_hi_lo(void __iomem *addr); #endif extern void iowrite8(u8, void __iomem *); @@ -41,9 +48,16 @@ extern void iowrite16(u16, void __iomem *); extern void iowrite16be(u16, void __iomem *); extern void iowrite32(u32, void __iomem *); extern void iowrite32be(u32, void __iomem *); -#ifdef CONFIG_64BIT -extern void iowrite64(u64, void __iomem *); -extern void iowrite64be(u64, void __iomem *); + +#ifdef writeq +#define iowrite64_lo_hi iowrite64_lo_hi +#define iowrite64_hi_lo iowrite64_hi_lo +#define iowrite64be_lo_hi iowrite64be_lo_hi +#define iowrite64be_hi_lo iowrite64be_hi_lo +extern void iowrite64_lo_hi(u64 val, void __iomem *addr); +extern void iowrite64_hi_lo(u64 val, void __iomem *addr); +extern void iowrite64be_lo_hi(u64 val, void __iomem *addr); +extern void iowrite64be_hi_lo(u64 val, void __iomem *addr); #endif /* diff --git a/lib/iomap.c b/lib/iomap.c index 2c293b22569f..e909ab71e995 100644 --- a/lib/iomap.c +++ b/lib/iomap.c @@ -67,6 +67,7 @@ static void bad_io_access(unsigned long port, const char *access) #ifndef mmio_read16be #define mmio_read16be(addr) swab16(readw(addr)) #define mmio_read32be(addr) swab32(readl(addr)) +#define mmio_read64be(addr) swab64(readq(addr)) #endif unsigned int ioread8(void __iomem *addr) @@ -100,6 +101,80 @@ EXPORT_SYMBOL(ioread16be); EXPORT_SYMBOL(ioread32); EXPORT_SYMBOL(ioread32be); +#ifdef readq +static u64 pio_read64_lo_hi(unsigned long port) +{ + u64 lo, hi; + + lo = inl(port); + hi = inl(port + sizeof(u32)); + + return lo | (hi << 32); +} + +static u64 pio_read64_hi_lo(unsigned long port) +{ + u64 lo, hi; + + hi = inl(port + sizeof(u32)); + lo = inl(port); + + return lo | (hi << 32); +} + +static u64 pio_read64be_lo_hi(unsigned long port) +{ + u64 lo, hi; + + lo = pio_read32be(port + sizeof(u32)); + hi = pio_read32be(port); + + return lo | (hi << 32); +} + +static u64 pio_read64be_hi_lo(unsigned long port) +{ + u64 lo, hi; + + hi = pio_read32be(port); + lo = pio_read32be(port + sizeof(u32)); + + return lo | (hi << 32); +} + +u64 ioread64_lo_hi(void __iomem *addr) +{ + IO_COND(addr, return pio_read64_lo_hi(port), return readq(addr)); + return 0xULL; +} + +u64 ioread64_hi_lo(void __iomem *addr) +{ + IO_COND(addr, return pio_read64_hi_lo(port), return readq(addr)); + return 0xULL; +} + +u64 ioread64be_lo_hi(void __iomem *addr) +{ +
[PATCH v17 2/7] parisc: iomap: introduce io{read|write}64
Add support for io{read|write}64() functions in parisc architecture. These are pretty straightforward copies of similar functions which make use of readq and writeq. Also, indicate that the lo_hi and hi_lo variants of these functions are not provided by this architecture. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Helge Deller Cc: "James E.J. Bottomley" Cc: Greg Kroah-Hartman Cc: Philippe Ombredanne Cc: Kate Stewart Cc: Thomas Gleixner --- arch/parisc/include/asm/io.h | 9 +++ arch/parisc/lib/iomap.c | 64 2 files changed, 73 insertions(+) diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h index afe493b23d04..30a8315d5c07 100644 --- a/arch/parisc/include/asm/io.h +++ b/arch/parisc/include/asm/io.h @@ -311,6 +311,15 @@ extern void outsl (unsigned long port, const void *src, unsigned long count); * value for either 32 or 64 bit mode */ #define F_EXTEND(x) ((unsigned long)((x) | (0xULL))) +#define ioread64 ioread64 +#define ioread64be ioread64be +#define iowrite64 iowrite64 +#define iowrite64be iowrite64be +extern u64 ioread64(void __iomem *addr); +extern u64 ioread64be(void __iomem *addr); +extern void iowrite64(u64 val, void __iomem *addr); +extern void iowrite64be(u64 val, void __iomem *addr); + #include /* diff --git a/arch/parisc/lib/iomap.c b/arch/parisc/lib/iomap.c index 4b19e6e64fb7..0195aec657e2 100644 --- a/arch/parisc/lib/iomap.c +++ b/arch/parisc/lib/iomap.c @@ -48,11 +48,15 @@ struct iomap_ops { unsigned int (*read16be)(void __iomem *); unsigned int (*read32)(void __iomem *); unsigned int (*read32be)(void __iomem *); + u64 (*read64)(void __iomem *); + u64 (*read64be)(void __iomem *); void (*write8)(u8, void __iomem *); void (*write16)(u16, void __iomem *); void (*write16be)(u16, void __iomem *); void (*write32)(u32, void __iomem *); void (*write32be)(u32, void __iomem *); + void (*write64)(u64, void __iomem *); + void (*write64be)(u64, void __iomem *); void (*read8r)(void __iomem *, void *, unsigned long); void (*read16r)(void __iomem *, void *, unsigned long); void (*read32r)(void __iomem *, void *, unsigned long); @@ -171,6 +175,16 @@ static unsigned int iomem_read32be(void __iomem *addr) return __raw_readl(addr); } +static u64 iomem_read64(void __iomem *addr) +{ + return readq(addr); +} + +static u64 iomem_read64be(void __iomem *addr) +{ + return __raw_readq(addr); +} + static void iomem_write8(u8 datum, void __iomem *addr) { writeb(datum, addr); @@ -196,6 +210,16 @@ static void iomem_write32be(u32 datum, void __iomem *addr) __raw_writel(datum, addr); } +static void iomem_write64(u64 datum, void __iomem *addr) +{ + writel(datum, addr); +} + +static void iomem_write64be(u64 datum, void __iomem *addr) +{ + __raw_writel(datum, addr); +} + static void iomem_read8r(void __iomem *addr, void *dst, unsigned long count) { while (count--) { @@ -250,11 +274,15 @@ static const struct iomap_ops iomem_ops = { .read16be = iomem_read16be, .read32 = iomem_read32, .read32be = iomem_read32be, + .read64 = iomem_read64, + .read64be = iomem_read64be, .write8 = iomem_write8, .write16 = iomem_write16, .write16be = iomem_write16be, .write32 = iomem_write32, .write32be = iomem_write32be, + .write64 = iomem_write64, + .write64be = iomem_write64be, .read8r = iomem_read8r, .read16r = iomem_read16r, .read32r = iomem_read32r, @@ -304,6 +332,20 @@ unsigned int ioread32be(void __iomem *addr) return *((u32 *)addr); } +u64 ioread64(void __iomem *addr) +{ + if (unlikely(INDIRECT_ADDR(addr))) + return iomap_ops[ADDR_TO_REGION(addr)]->read64(addr); + return le64_to_cpup((u64 *)addr); +} + +u64 ioread64be(void __iomem *addr) +{ + if (unlikely(INDIRECT_ADDR(addr))) + return iomap_ops[ADDR_TO_REGION(addr)]->read64be(addr); + return *((u64 *)addr); +} + void iowrite8(u8 datum, void __iomem *addr) { if (unlikely(INDIRECT_ADDR(addr))) { @@ -349,6 +391,24 @@ void iowrite32be(u32 datum, void __iomem *addr) } } +void iowrite64(u64 datum, void __iomem *addr) +{ + if (unlikely(INDIRECT_ADDR(addr))) { + iomap_ops[ADDR_TO_REGION(addr)]->write64(datum, addr); + } else { + *((u64 *)addr) = cpu_to_le64(datum); + } +} + +void iowrite64be(u64 datum, void __iomem *addr) +{ + if (unlikely(INDIRECT_ADDR(addr))) { + iomap_ops[ADDR_TO_REGION(addr)]->write64be(datum, addr); + } else { + *((u64 *)addr) = datum; + } +} + /* Repeating interfaces */ void ioread8_rep(void __iomem *addr, void *dst, unsigned long count) @@ -449,11 +509,15 @@ EXPORT_SYMBOL(iore
[PATCH v17 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from / written to first, followed by the upper address. Indeed the I/O accessors in CAAM driver currently don't follow the spec, however this is a good opportunity to fix the code. Signed-off-by: Logan Gunthorpe Reviewed-by: Horia Geantă Reviewed-by: Andy Shevchenko Cc: Dan Douglass Cc: Herbert Xu Cc: "David S. Miller" --- drivers/crypto/caam/regs.h | 30 +++--- 1 file changed, 3 insertions(+), 27 deletions(-) diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h index fee363865d88..f887b371040f 100644 --- a/drivers/crypto/caam/regs.h +++ b/drivers/crypto/caam/regs.h @@ -10,7 +10,7 @@ #include #include -#include +#include /* * Architecture-specific register access methods @@ -136,10 +136,9 @@ static inline void clrsetbits_32(void __iomem *reg, u32 clear, u32 set) *base + 0x : least-significant 32 bits *base + 0x0004 : most-significant 32 bits */ -#ifdef CONFIG_64BIT static inline void wr_reg64(void __iomem *reg, u64 data) { - if (caam_little_end) + if (!caam_imx && caam_little_end) iowrite64(data, reg); else iowrite64be(data, reg); @@ -147,35 +146,12 @@ static inline void wr_reg64(void __iomem *reg, u64 data) static inline u64 rd_reg64(void __iomem *reg) { - if (caam_little_end) + if (!caam_imx && caam_little_end) return ioread64(reg); else return ioread64be(reg); } -#else /* CONFIG_64BIT */ -static inline void wr_reg64(void __iomem *reg, u64 data) -{ - if (!caam_imx && caam_little_end) { - wr_reg32((u32 __iomem *)(reg) + 1, data >> 32); - wr_reg32((u32 __iomem *)(reg), data); - } else { - wr_reg32((u32 __iomem *)(reg), data >> 32); - wr_reg32((u32 __iomem *)(reg) + 1, data); - } -} - -static inline u64 rd_reg64(void __iomem *reg) -{ - if (!caam_imx && caam_little_end) - return ((u64)rd_reg32((u32 __iomem *)(reg) + 1) << 32 | - (u64)rd_reg32((u32 __iomem *)(reg))); - - return ((u64)rd_reg32((u32 __iomem *)(reg)) << 32 | - (u64)rd_reg32((u32 __iomem *)(reg) + 1)); -} -#endif /* CONFIG_64BIT */ - static inline u64 cpu_to_caam_dma64(dma_addr_t value) { if (caam_imx) -- 2.11.0
[PATCH v17 5/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang Acked-by: Allen Hubbe Acked-by: Jon Mason --- drivers/ntb/hw/intel/ntb_hw_intel.c | 30 +- 1 file changed, 1 insertion(+), 29 deletions(-) diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c b/drivers/ntb/hw/intel/ntb_hw_intel.c index 156b45cd4a19..5cf40ab21366 100644 --- a/drivers/ntb/hw/intel/ntb_hw_intel.c +++ b/drivers/ntb/hw/intel/ntb_hw_intel.c @@ -59,6 +59,7 @@ #include #include #include +#include #include "ntb_hw_intel.h" @@ -149,35 +150,6 @@ MODULE_PARM_DESC(xeon_b2b_dsd_bar5_addr32, static inline enum ntb_topo xeon_ppd_topo(struct intel_ntb_dev *ndev, u8 ppd); static int xeon_init_isr(struct intel_ntb_dev *ndev); -#ifndef ioread64 -#ifdef readq -#define ioread64 readq -#else -#define ioread64 _ioread64 -static inline u64 _ioread64(void __iomem *mmio) -{ - u64 low, high; - - low = ioread32(mmio); - high = ioread32(mmio + sizeof(u32)); - return low | (high << 32); -} -#endif -#endif - -#ifndef iowrite64 -#ifdef writeq -#define iowrite64 writeq -#else -#define iowrite64 _iowrite64 -static inline void _iowrite64(u64 val, void __iomem *mmio) -{ - iowrite32(val, mmio); - iowrite32(val >> 32, mmio + sizeof(u32)); -} -#endif -#endif - static inline int pdev_is_xeon(struct pci_dev *pdev) { switch (pdev->device) { -- 2.11.0
[PATCH v17 4/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are encouraged to use ioreadXX, et al instead of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly. [1] LDD3: section 9.4.2 Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Cc: Christoph Hellwig Cc: Arnd Bergmann Cc: Alan Cox Cc: Greg Kroah-Hartman --- include/linux/io-64-nonatomic-hi-lo.h | 64 +++ include/linux/io-64-nonatomic-lo-hi.h | 64 +++ 2 files changed, 128 insertions(+) diff --git a/include/linux/io-64-nonatomic-hi-lo.h b/include/linux/io-64-nonatomic-hi-lo.h index 862d786a904f..ae21b72cce85 100644 --- a/include/linux/io-64-nonatomic-hi-lo.h +++ b/include/linux/io-64-nonatomic-hi-lo.h @@ -55,4 +55,68 @@ static inline void hi_lo_writeq_relaxed(__u64 val, volatile void __iomem *addr) #define writeq_relaxed hi_lo_writeq_relaxed #endif +#ifndef ioread64_hi_lo +#define ioread64_hi_lo ioread64_hi_lo +static inline u64 ioread64_hi_lo(void __iomem *addr) +{ + u32 low, high; + + high = ioread32(addr + sizeof(u32)); + low = ioread32(addr); + + return low + ((u64)high << 32); +} +#endif + +#ifndef iowrite64_hi_lo +#define iowrite64_hi_lo iowrite64_hi_lo +static inline void iowrite64_hi_lo(u64 val, void __iomem *addr) +{ + iowrite32(val >> 32, addr + sizeof(u32)); + iowrite32(val, addr); +} +#endif + +#ifndef ioread64be_hi_lo +#define ioread64be_hi_lo ioread64be_hi_lo +static inline u64 ioread64be_hi_lo(void __iomem *addr) +{ + u32 low, high; + + high = ioread32be(addr); + low = ioread32be(addr + sizeof(u32)); + + return low + ((u64)high << 32); +} +#endif + +#ifndef iowrite64be_hi_lo +#define iowrite64be_hi_lo iowrite64be_hi_lo +static inline void iowrite64be_hi_lo(u64 val, void __iomem *addr) +{ + iowrite32be(val >> 32, addr); + iowrite32be(val, addr + sizeof(u32)); +} +#endif + +#ifndef ioread64 +#define ioread64_is_nonatomic +#define ioread64 ioread64_hi_lo +#endif + +#ifndef iowrite64 +#define iowrite64_is_nonatomic +#define iowrite64 iowrite64_hi_lo +#endif + +#ifndef ioread64be +#define ioread64be_is_nonatomic +#define ioread64be ioread64be_hi_lo +#endif + +#ifndef iowrite64be +#define iowrite64be_is_nonatomic +#define iowrite64be iowrite64be_hi_lo +#endif + #endif /* _LINUX_IO_64_NONATOMIC_HI_LO_H_ */ diff --git a/include/linux/io-64-nonatomic-lo-hi.h b/include/linux/io-64-nonatomic-lo-hi.h index d042e7bb5adb..faaa842dbdb9 100644 --- a/include/linux/io-64-nonatomic-lo-hi.h +++ b/include/linux/io-64-nonatomic-lo-hi.h @@ -55,4 +55,68 @@ static inline void lo_hi_writeq_relaxed(__u64 val, volatile void __iomem *addr) #define writeq_relaxed lo_hi_writeq_relaxed #endif +#ifndef ioread64_lo_hi +#define ioread64_lo_hi ioread64_lo_hi +static inline u64 ioread64_lo_hi(void __iomem *addr) +{ + u32 low, high; + + low = ioread32(addr); + high = ioread32(addr + sizeof(u32)); + + return low + ((u64)high << 32); +} +#endif + +#ifndef iowrite64_lo_hi +#define iowrite64_lo_hi iowrite64_lo_hi +static inline void iowrite64_lo_hi(u64 val, void __iomem *addr) +{ + iowrite32(val, addr); + iowrite32(val >> 32, addr + sizeof(u32)); +} +#endif + +#ifndef ioread64be_lo_hi +#define ioread64be_lo_hi ioread64be_lo_hi +static inline u64 ioread64be_lo_hi(void __iomem *addr) +{ + u32 low, high; + + low = ioread32be(addr + sizeof(u32)); + high = ioread32be(addr); + + return low + ((u64)high << 32); +} +#endif + +#ifndef iowrite64be_lo_hi +#define iowrite64be_lo_hi iowrite64be_lo_hi +static inline void iowrite64be_lo_hi(u64 val, void __iomem *addr) +{ + iowrite32be(val, addr + sizeof(u32)); + iowrite32be(val >> 32, addr); +} +#endif + +#ifndef ioread64 +#define ioread64_is_nonatomic +#define ioread64 ioread64_lo_hi +#endif + +#ifndef iowrite64 +#define iowrite64_is_nonatomic +#define iowrite64 iowrite64_lo_hi +#endif + +#ifndef ioread64be +#define ioread64be_is_nonatomic +#define ioread64be ioread64be_lo_hi +#endif + +#ifndef iowrite64be +#define iowrite64be_is_nonatomic +#define iowrite64be iowrite64be_lo_hi +#endif + #endif /* _LINUX_IO_64_NONATOMIC_LO_HI_H_ */ -- 2.11.0
[PATCH v17 0/7] Add io{read|write}64 to io-64-atomic headers
This is a resend of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their own copies. This cleanup was originally requested by Greg after he reviewed my Switchtec NTB code. @Andrew, can you please consider merging this series as it has a number of cross-tree pieces? It has been around for a number of cycles, has had some reviews, and a few small pieces of it have been already accepted through various other trees. Thanks, Logan -- Changes since v16: - Rebased onto v4.17-rc4 (No Changes) Changes since v15: - Rebased onto v4.17-rc1, dropping the powerpc patches which were picked up by Michael Changes since v14: - Rebased onto v4.16-rc7 - Replace the first two patches so that instead of correcting the endianness annotations we change to using writeX() and readX() with swabX() calls. This makes the big-endian functions more symmetric with the little-endian versions (with respect to barriers that are not included in the raw functions). As a side effect, it also fixes the kbuild warnings that the first two patches tried to address. Changes since v13: - Changed the subject of patch 0001 to correct a nit pointed out by Luc Changes since v12: - Rebased onto v4.16-rc6 - Split patch 0001 into two and reworked the commit log as requested by Luc Van Oostenryck Changes since v11: - Rebased onto v4.16-rc5 - Added a patch (0001) to fix some old and new sparse warnings that the kbuild robot warned about this cycle. The latest version of sparse was required to reproduce these. - Added a patch (0002) to add io{read|write}64 to parisc which the kbuild robot also found errors for this cycle Changes since v10: - Rebased onto v4.16-rc4, this droped the drm/tilcdc patch which was picked up by that tree and is already in 4.16. Changes since v9: - Rebased onto v4.15-rc6 - Fixed a couple of issues in the new version of the CAAM patch as pointed out by Horia Changes since v8: - Rebased onto v4.15-rc2, as a result rewrote patch 7 seeing someone did some similar cleanup in that area. - Added a patch to clean up the Switchtec NTB driver which landed in v4.15-rc1 Changes since v7: - Fix minor nits from Andy Shevchenko - Rebased onto v4.14-rc1 Changes since v6: ** none ** Changes since v5: - Added a fix to the tilcdc driver to ensure it doesn't use the non-atomic operation. (This includes adding io{read|write}64[be]_is_nonatomic defines). Changes since v4: - Add functions so the powerpc implementation of iomap.c compiles. (As noticed by Horia) Changes since v3: - I noticed powerpc didn't use the appropriate functions seeing readq/writeq were not defined when iomap.h was included. Thus I've included a patch to adjust this - Fixed some mistakes with a couple of the defines in io-64-nonatomic* headers - Fixed a typo noticed by Horia. (earlier versions were drastically different) Logan Gunthorpe (7): iomap: Use non-raw io functions for io{read|write}XXbe parisc: iomap: introduce io{read|write}64 iomap: introduce io{read|write}64_{lo_hi|hi_lo} io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header arch/parisc/include/asm/io.h | 9 +++ arch/parisc/lib/iomap.c| 64 +++ arch/powerpc/include/asm/io.h | 2 + drivers/crypto/caam/regs.h | 30 +-- drivers/ntb/hw/intel/ntb_hw_intel.c| 30 +-- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 36 + include/asm-generic/iomap.h| 26 -- include/linux/io-64-nonatomic-hi-lo.h | 64 +++ include/linux/io-64-nonatomic-lo-hi.h | 64 +++ lib/iomap.c| 140 - 10 files changed, 367 insertions(+), 98 deletions(-) -- 2.11.0
[PATCH v17 1/7] iomap: Use non-raw io functions for io{read|write}XXbe
Fix an asymmetry in the io{read|write}XXbe functions in that the big-endian variants make use of the raw io accessors while the little-endian variants use the regular accessors. Some architectures implement barriers to order against both spinlocks and DMA accesses and for these case, the big-endian variant of the API would not be protected. Thus, change the mmio_be macros to use the appropriate swab() function wrapping the regular accessor. This is similar to what was done for PIO. When this code was originally written, barriers in the IO accessors were not common and the accessors simply wrapped the raw functions in a conversion to CPU endianness. Since then, barriers have been added in some architectures and are now missing in the big endian variant of the API. This also manages to silence a few sparse warnings that check for using the correct endian types which the original code did not annotate correctly. Signed-off-by: Logan Gunthorpe Cc: Thomas Gleixner Cc: Kate Stewart Cc: Philippe Ombredanne Cc: Greg Kroah-Hartman Cc: Arnd Bergmann Link: http://lkml.kernel.org/r/cak8p3a25zqdxyay3ivv+jmsszs7f6ssgc+hdbkgs54zfvix...@mail.gmail.com --- lib/iomap.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/iomap.c b/lib/iomap.c index 541d926da95e..2c293b22569f 100644 --- a/lib/iomap.c +++ b/lib/iomap.c @@ -65,8 +65,8 @@ static void bad_io_access(unsigned long port, const char *access) #endif #ifndef mmio_read16be -#define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr)) -#define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr)) +#define mmio_read16be(addr) swab16(readw(addr)) +#define mmio_read32be(addr) swab32(readl(addr)) #endif unsigned int ioread8(void __iomem *addr) @@ -106,8 +106,8 @@ EXPORT_SYMBOL(ioread32be); #endif #ifndef mmio_write16be -#define mmio_write16be(val,port) __raw_writew(be16_to_cpu(val),port) -#define mmio_write32be(val,port) __raw_writel(be32_to_cpu(val),port) +#define mmio_write16be(val,port) writew(swab16(val),port) +#define mmio_write32be(val,port) writel(swab32(val),port) #endif void iowrite8(u8 val, void __iomem *addr) -- 2.11.0
[PATCH v17 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header
Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Cc: Jon Mason --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 36 -- 1 file changed, 4 insertions(+), 32 deletions(-) diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c index f624ae27eabe..f403da24b833 100644 --- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c +++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c @@ -13,12 +13,13 @@ * */ -#include -#include +#include +#include #include #include -#include +#include #include +#include MODULE_DESCRIPTION("Microsemi Switchtec(tm) NTB Driver"); MODULE_VERSION("0.1"); @@ -35,35 +36,6 @@ module_param(use_lut_mws, bool, 0644); MODULE_PARM_DESC(use_lut_mws, "Enable the use of the LUT based memory windows"); -#ifndef ioread64 -#ifdef readq -#define ioread64 readq -#else -#define ioread64 _ioread64 -static inline u64 _ioread64(void __iomem *mmio) -{ - u64 low, high; - - low = ioread32(mmio); - high = ioread32(mmio + sizeof(u32)); - return low | (high << 32); -} -#endif -#endif - -#ifndef iowrite64 -#ifdef writeq -#define iowrite64 writeq -#else -#define iowrite64 _iowrite64 -static inline void _iowrite64(u64 val, void __iomem *mmio) -{ - iowrite32(val, mmio); - iowrite32(val >> 32, mmio + sizeof(u32)); -} -#endif -#endif - #define SWITCHTEC_NTB_MAGIC 0x45CC0001 #define MAX_MWS 128 -- 2.11.0
Re: IV generation
On Mon, May 7, 2018 at 2:29 PM, Stephan Mueller wrote: > Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> ah... so if I have hardware that can implement say, seqiv, I can >> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are >> right, it will be used? > > That is the question I cannot fully answer. Seqiv is a template and thus not > subjet to prios by itself. So, you hardware however could register the full > seqiv(rfc) cipher. I am not fully sure that such registered cipher is then > picked up by the IPSec stack. > > Look into net/xfrm/xfrm_algos.c -- there you see the individual cipher names > and the IV generator added separately. What I have not traced yet is whether > the code assembles the IV generator name and the cipher name before making the > call to crypto_alloc_aead. > > What I can say for sure is that the kernel crypto API knows of the > seqiv(rfc...) cipher name and generates the IV for your (the invocation field > that is). I see. I think the code does the assembly in esp4.c esp_init_aead() and esp_init_authenc() So it should all Just Work(TM). Many thanks for the clarification. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: IV generation
Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > ah... so if I have hardware that can implement say, seqiv, I can > register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are > right, it will be used? That is the question I cannot fully answer. Seqiv is a template and thus not subjet to prios by itself. So, you hardware however could register the full seqiv(rfc) cipher. I am not fully sure that such registered cipher is then picked up by the IPSec stack. Look into net/xfrm/xfrm_algos.c -- there you see the individual cipher names and the IV generator added separately. What I have not traced yet is whether the code assembles the IV generator name and the cipher name before making the call to crypto_alloc_aead. What I can say for sure is that the kernel crypto API knows of the seqiv(rfc...) cipher name and generates the IV for your (the invocation field that is). Ciao Stephan
Re: IV generation
On Mon, May 7, 2018 at 2:02 PM, Stephan Mueller wrote: > Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> Hi, >> >> A quick question: am I correct in my understanding that there is now >> no automatic IV generation support for either skcipher nor aead? >> And if I'm wrong, can someone point to an example of a driver that >> implements either, as all the ones I see are the deprecated ablkcipher >> interface. >> >> BTW, I'm perfectly fine with not having one, I just want to understand >> I am not missing something... > > The automated IV generation is implemented with the generators such as seqiv > or chainiv. > > For example, AES-GCM as used for IPSec compliant with RFC4106 generates the IV > (the invocation field part of the IV) with the seqiv. This is handled by the > IPSec stack to initialize the cipher of, say, seqiv(rfc4106(gcm(aes))). > > The CTR mode uses the chainiv implementation to manage the IV. ah... so if I have hardware that can implement say, seqiv, I can register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are right, it will be used? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: IV generation
Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > Hi, > > A quick question: am I correct in my understanding that there is now > no automatic IV generation support for either skcipher nor aead? > And if I'm wrong, can someone point to an example of a driver that > implements either, as all the ones I see are the deprecated ablkcipher > interface. > > BTW, I'm perfectly fine with not having one, I just want to understand > I am not missing something... The automated IV generation is implemented with the generators such as seqiv or chainiv. For example, AES-GCM as used for IPSec compliant with RFC4106 generates the IV (the invocation field part of the IV) with the seqiv. This is handled by the IPSec stack to initialize the cipher of, say, seqiv(rfc4106(gcm(aes))). The CTR mode uses the chainiv implementation to manage the IV. > > Thanks in advance, > Gilad Ciao Stephan
Re: [PATCH] crypto: chtls - fix a missing-check bug
Hi Wenwen, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on cryptodev/master] [also build test WARNING on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Wenwen-Wang/crypto-chtls-fix-a-missing-check-bug/20180506-091039 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master :: branch date: 26 hours ago :: commit date: 26 hours ago New smatch warnings: drivers/crypto/chelsio/chtls/chtls_main.c:496 do_chtls_setsockopt() warn: potential pointer math issue ('crypto_info' is a 32 bit pointer) Old smatch warnings: drivers/crypto/chelsio/chtls/chtls_main.c:253 chtls_uld_add() error: buffer overflow 'cdev->rspq_skb_cache' 32 <= 32 drivers/crypto/chelsio/chtls/chtls_main.c:350 chtls_recv_packet() error: double free of 'skb' drivers/crypto/chelsio/chtls/chtls_main.c:390 chtls_recv_rsp() error: double free of 'skb' drivers/crypto/chelsio/chtls/chtls_main.c:408 chtls_recv() error: double free of 'skb' # https://github.com/0day-ci/linux/commit/183b5e3e71c75e3149dac2698883f0bd63a89c75 git remote add linux-review https://github.com/0day-ci/linux git remote update linux-review git checkout 183b5e3e71c75e3149dac2698883f0bd63a89c75 vim +496 drivers/crypto/chelsio/chtls/chtls_main.c a0894394 Atul Gupta 2018-03-31 461 a0894394 Atul Gupta 2018-03-31 462 static int do_chtls_setsockopt(struct sock *sk, int optname, a0894394 Atul Gupta 2018-03-31 463 char __user *optval, unsigned int optlen) a0894394 Atul Gupta 2018-03-31 464 { a0894394 Atul Gupta 2018-03-31 465struct tls_crypto_info *crypto_info, tmp_crypto_info; a0894394 Atul Gupta 2018-03-31 466struct chtls_sock *csk; a0894394 Atul Gupta 2018-03-31 467int keylen; a0894394 Atul Gupta 2018-03-31 468int rc = 0; a0894394 Atul Gupta 2018-03-31 469 a0894394 Atul Gupta 2018-03-31 470csk = rcu_dereference_sk_user_data(sk); a0894394 Atul Gupta 2018-03-31 471 a0894394 Atul Gupta 2018-03-31 472if (!optval || optlen < sizeof(*crypto_info)) { a0894394 Atul Gupta 2018-03-31 473rc = -EINVAL; a0894394 Atul Gupta 2018-03-31 474goto out; a0894394 Atul Gupta 2018-03-31 475} a0894394 Atul Gupta 2018-03-31 476 a0894394 Atul Gupta 2018-03-31 477rc = copy_from_user(&tmp_crypto_info, optval, sizeof(*crypto_info)); a0894394 Atul Gupta 2018-03-31 478if (rc) { a0894394 Atul Gupta 2018-03-31 479rc = -EFAULT; a0894394 Atul Gupta 2018-03-31 480goto out; a0894394 Atul Gupta 2018-03-31 481} a0894394 Atul Gupta 2018-03-31 482 a0894394 Atul Gupta 2018-03-31 483/* check version */ a0894394 Atul Gupta 2018-03-31 484if (tmp_crypto_info.version != TLS_1_2_VERSION) { a0894394 Atul Gupta 2018-03-31 485rc = -ENOTSUPP; a0894394 Atul Gupta 2018-03-31 486goto out; a0894394 Atul Gupta 2018-03-31 487} a0894394 Atul Gupta 2018-03-31 488 a0894394 Atul Gupta 2018-03-31 489crypto_info = (struct tls_crypto_info *)&csk->tlshws.crypto_info; a0894394 Atul Gupta 2018-03-31 490 a0894394 Atul Gupta 2018-03-31 491switch (tmp_crypto_info.cipher_type) { a0894394 Atul Gupta 2018-03-31 492case TLS_CIPHER_AES_GCM_128: { 183b5e3e Wenwen Wang 2018-05-05 493/* Obtain version and type from previous copy */ 183b5e3e Wenwen Wang 2018-05-05 494crypto_info[0] = tmp_crypto_info; 183b5e3e Wenwen Wang 2018-05-05 495/* Now copy the following data */ 183b5e3e Wenwen Wang 2018-05-05 @496rc = copy_from_user(crypto_info + sizeof(*crypto_info), 183b5e3e Wenwen Wang 2018-05-05 497optval + sizeof(*crypto_info), 183b5e3e Wenwen Wang 2018-05-05 498sizeof(struct tls12_crypto_info_aes_gcm_128) 183b5e3e Wenwen Wang 2018-05-05 499- sizeof(*crypto_info)); a0894394 Atul Gupta 2018-03-31 500 a0894394 Atul Gupta 2018-03-31 501if (rc) { a0894394 Atul Gupta 2018-03-31 502rc = -EFAULT; a0894394 Atul Gupta 2018-03-31 503goto out; a0894394 Atul Gupta 2018-03-31 504} a0894394 Atul Gupta 2018-03-31 505 a0894394 Atul Gupta 2018-03-31 506keylen = TLS_CIPHER_AES_GCM_128_KEY_SIZE; a0894394 Atul Gupta 2018-03-31 507rc = chtls_setkey(csk, keylen, optname); a0894394 Atul Gupta 2018-03-31 508break; a0894394 Atul Gupta 2018-03-31 509} a0894394 Atul Gupta 2018-03-31 510default: a0894394 Atul Gupta 2018-03-31 511rc = -EINVAL; a0894394 Atul Gupta 2018-03-31 512goto out; a0894394 Atul Gupta 2018-03-31 513} a0894394 Atul Gupta 2018-03-31 514 out: a0894394 Atul Gupta 2018-03-31 515return rc; a0894394 Atul Gupta 20
[PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst
A number of new docs were added, but they're currently not on the index.rst from the session they're supposed to be, causing Sphinx warnings. Add them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/crypto/index.rst | 1 + Documentation/driver-api/index.rst | 1 + Documentation/process/index.rst| 1 + Documentation/security/index.rst | 2 ++ 4 files changed, 5 insertions(+) diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst index 94c4786f2573..c4ff5d791233 100644 --- a/Documentation/crypto/index.rst +++ b/Documentation/crypto/index.rst @@ -20,5 +20,6 @@ for cryptographic use cases, as well as programming examples. architecture devel-algos userspace-if + crypto_engine api api-samples diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 6d8352c0f354..3ac51c94f97b 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -18,6 +18,7 @@ available subsections can be seen below. infrastructure pm/index device-io + device_connection dma-buf device_link message-based diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 1c9fe657ed01..37bd0628b6ee 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -52,6 +52,7 @@ lack of a better place. adding-syscalls magic-number volatile-considered-harmful + clang-format .. only:: subproject and html diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst index 298a94a33f05..85492bfca530 100644 --- a/Documentation/security/index.rst +++ b/Documentation/security/index.rst @@ -9,5 +9,7 @@ Security Documentation IMA-templates keys/index LSM + LSM-sctp + SELinux-sctp self-protection tpm/index -- 2.17.0
[PATCH 11/18] docs: crypto_engine.rst: Fix two parse warnings
./Documentation/crypto/crypto_engine.rst:13: WARNING: Unexpected indentation. ./Documentation/crypto/crypto_engine.rst:15: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab --- Documentation/crypto/crypto_engine.rst | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst index 8272ac92a14f..1d56221dfe35 100644 --- a/Documentation/crypto/crypto_engine.rst +++ b/Documentation/crypto/crypto_engine.rst @@ -8,11 +8,13 @@ The crypto engine API (CE), is a crypto queue manager. Requirement --- -You have to put at start of your tfm_ctx the struct crypto_engine_ctx -struct your_tfm_ctx { +You have to put at start of your tfm_ctx the struct crypto_engine_ctx:: + + struct your_tfm_ctx { struct crypto_engine_ctx enginectx; ... -}; + }; + Why: Since CE manage only crypto_async_request, it cannot know the underlying request_type and so have access only on the TFM. So using container_of for accessing __ctx is impossible. -- 2.17.0
[PATCH 00/18] Fix some build warnings/errors with Sphinx
I decided to give a try with Sphinx last stable version (1.17.4), and noticed several issues. The worse one was with the networking book: a non-standard footnote there with [*] instead of a number causes it to break PDF building. So, I took some spare time to address some warnings all over the tree, and moved a few text documents to a book. I with I had more time to move the other ones and to solve other warnings. Mauro Carvalho Chehab (18): docs: can.rst: fix a footnote reference docs: fix location of request_firmware & friends docs: */index.rst: Add newer documents to their respective index.rst docs: admin-guide: add bcache documentation docs: core-api: add cachetlb documentation docs: core-api: add cgroup-v2 documentation docs: core-api: add circular-buffers documentation docs: driver-api: add clk documentation net: mac80211.h: fix a bad comment line rcu: rcupdate.h: get rid of Sphinx warnings at rcu_pointer_handoff() docs: crypto_engine.rst: Fix two parse warnings time: timer.c: adjust a kernel-doc comment wait: wait.h: Get rid of a kernel-doc/Sphinx warnings fbdev: modedb.c: fix a kernel-doc markup iio: iio.h: use nested struct support on kernel-doc markup mtd: rawnand.h: use nested union kernel-doc markups docs: uio-howto.rst: use a code block to solve a warning w1: w1_io.c: fix a kernel-doc warning Documentation/00-INDEX| 10 --- .../{bcache.txt => admin-guide/bcache.rst}| 0 .../cgroup-v2.rst}| 0 Documentation/admin-guide/index.rst | 2 ++ .../admin-guide/kernel-parameters.txt | 2 +- .../{cachetlb.txt => core-api/cachetlb.rst} | 0 .../circular-buffers.rst} | 0 Documentation/core-api/index.rst | 2 ++ Documentation/crypto/crypto_engine.rst| 8 +++--- Documentation/crypto/index.rst| 1 + Documentation/dell_rbu.txt| 4 +-- Documentation/{clk.txt => driver-api/clk.rst} | 0 .../firmware/fallback-mechanisms.rst | 2 +- .../driver-api/firmware/request_firmware.rst | 17 +++- Documentation/driver-api/index.rst| 2 ++ Documentation/driver-api/infrastructure.rst | 2 +- Documentation/driver-api/uio-howto.rst| 3 ++- Documentation/memory-barriers.txt | 4 +-- Documentation/networking/can.rst | 4 +-- .../power/suspend-and-cpuhotplug.txt | 2 +- Documentation/process/index.rst | 1 + Documentation/security/index.rst | 2 ++ .../translations/ko_KR/memory-barriers.txt| 4 +-- drivers/video/fbdev/core/modedb.c | 22 drivers/w1/w1_io.c| 1 + include/linux/iio/iio.h | 24 - include/linux/mtd/rawnand.h | 26 +-- include/linux/rcupdate.h | 5 ++-- include/linux/wait.h | 2 +- include/net/mac80211.h| 2 +- kernel/time/timer.c | 14 +- 31 files changed, 93 insertions(+), 75 deletions(-) rename Documentation/{bcache.txt => admin-guide/bcache.rst} (100%) rename Documentation/{cgroup-v2.txt => admin-guide/cgroup-v2.rst} (100%) rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%) rename Documentation/{circular-buffers.txt => core-api/circular-buffers.rst} (100%) rename Documentation/{clk.txt => driver-api/clk.rst} (100%) -- 2.17.0
Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support
On Tue, May 01, 2018 at 10:39:15PM +, Dey, Megha wrote: > > crypto/simd.c provides a simd_skcipher_create_compat. I have used the same > template to introduce simd_ahash_create_compat > which would wrap around the inner hash algorithm. > > Hence we would still register 2 algs, outer and inner. Right. > Currently we have outer_alg -> mcryptd alg -> inner_alg > > Mcryptd is mainly providing the following: > 1. Ensuring the lanes(8 in case of AVX2) are full before dispatching to the > lower inner algorithm. This is obviously why we would expect better > performance for multi-buffer as opposed to the present single-buffer > algorithms. > 2. If there no new incoming jobs, issue a flush. > 3. A glue layer which sends the correct pointers and completions. > > If we get rid of mcryptd, these functions needs to be done by someone. Since > all multi-buffer algorithms would require this tasks, where do you suggest > these helpers live, if not the current mcryptd.c? That's the issue. I don't think mcryptd is doing any of these claimed functions except for hosting the flush helper which could really live anywhere. All these functions are actually being carried out in the inner algorithm already. > I am not sure if you are suggesting that we need to get rid of the mcryptd > work queue itself. In that case, we would need to execute in the context of > the job requesting the crypto transformation. Which is fine as long as you can disable the FPU. If not the simd wrapper will defer the job to kthread context as required. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt