Re: [PATCH 0/2] Use ccm(aes) aead transform in staging drivers
On Fri, 16 Aug 2019 at 10:00, Christina Quast wrote: > > Use ccm(aes) aead transform instead of invoking the AES block cipher > block by block. > Thanks! This eliminates another two users of the bare cipher API, which is not the right abstraction for drivers to use. Reviewed-by: Ard Biesheuvel I don't have the hardware, so I can't test this. > Christina Quast (2): > staging: rtl8192u: ieee80211: ieee80211_crypt_ccmp.c: Use crypto API > ccm(aes) > staging: rtl8192e: rtllib_crypt_ccmp.c: Use crypto API ccm(aes) > > drivers/staging/rtl8192e/Kconfig | 1 + > drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 187 -- > drivers/staging/rtl8192u/Kconfig | 2 + > .../rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 187 -- > 4 files changed, 159 insertions(+), 218 deletions(-) > > -- > 2.20.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 27 June 2018 at 20:00, Luis R. Rodriguez wrote: > On Mon, Jun 25, 2018 at 05:08:08PM -0700, Bjorn Andersson wrote: >> On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote: >> >> > On 7 June 2018 at 20:21, Bjorn Andersson >> > wrote: >> > > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote: >> [..] >> > >> >> > >> Why not just use kmalloc, it will always return a DMAable buffer. >> > >> >> > > >> > > For the buffers being targeted by request_firmware_into_buf() the >> > > problem is that some of them has requirements of physical placement and >> > > they are all too big for kmalloc() (i.e. tens of mb). >> > > >> > > >> > > For the dma_alloc_coherent() buffer that was mentioned earlier, which is >> > > not related to the firmware loading, it's not used because the buffer is >> > > passed to secure world, which temporarily locks Linux out from the >> > > memory region. Traditionally this region was kmalloc'ed downstream, but >> > > due to speculative access violations this code moved to use the DMA >> > > streaming API, although there's no actual DMA going on. >> > > >> > >> > OK, so you are relying on the fact that dma_alloc_coherent() gives you >> > a device mapping (because the qcom_scm device is described as non >> > cache coherent), but this sounds risky to me. The linear alias of that >> > memory will still be mapped cacheable, and could potentially still be >> > accessed speculatively AFAIK. >> > >> >> Yes and we are aware of the risk of having the linear alias present, but >> have yet to find a suitable way to handle this. >> >> The proposed mechanism was to use reserved-memory and memremap() the >> region while it should be available in Linux, > > That's still IO memory, and so it would be up to the specific device if > or not it could access the memory before a full write is done. > The risk here is about having aliases with mismatched attributes, which may result in loss of coherency and corrupt your data. This is not about the risk of loading a file with an invalid signature And what do you mean by 'IO memory'? Bus masters that are not behind an IOMMU can access all of the kernel's memory all of the time, regardless of whether and how it chooses to use it. So from a security perspective, there is no distinction, and you can only distinguish between before and after informing the device where it can find the firmware buffer in memory. So given that we are dealing here with other masters that can change all of your memory behind your back, including the actual code you are running that implements the signature check, I wonder if there is a point to obsessing about this use case from a validation point of view. The higher privilege level protects itself by doing its own signature check, and doing the same at a lower privilege level seems redundant to me. >> but while this would work >> for some cases (e.g. memory regions for semi-static firmware executed by >> co-processors) it doesn't handle the scenarios where the memory-need is >> dynamic. >> >> So suggestions are very welcome on how to better handle this. > > I *believe* Vlastimil's seems to suggest kvmalloc(), but note that if getting > the > memory to be contiguous fails, it would fallback to a non-contiguous (vmalloc) > allocation. > > Luis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 28 June 2018 at 01:33, Luis R. Rodriguez wrote: > On Thu, Jun 28, 2018 at 12:21:47AM +0200, Ard Biesheuvel wrote: >> On 27 June 2018 at 20:00, Luis R. Rodriguez wrote: >> > On Mon, Jun 25, 2018 at 05:08:08PM -0700, Bjorn Andersson wrote: >> >> On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote: >> >> >> >> > On 7 June 2018 at 20:21, Bjorn Andersson >> >> > wrote: >> >> > > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote: >> >> [..] >> >> > >> >> >> > >> Why not just use kmalloc, it will always return a DMAable buffer. >> >> > >> >> >> > > >> >> > > For the buffers being targeted by request_firmware_into_buf() the >> >> > > problem is that some of them has requirements of physical placement >> >> > > and >> >> > > they are all too big for kmalloc() (i.e. tens of mb). >> >> > > >> >> > > >> >> > > For the dma_alloc_coherent() buffer that was mentioned earlier, which >> >> > > is >> >> > > not related to the firmware loading, it's not used because the buffer >> >> > > is >> >> > > passed to secure world, which temporarily locks Linux out from the >> >> > > memory region. Traditionally this region was kmalloc'ed downstream, >> >> > > but >> >> > > due to speculative access violations this code moved to use the DMA >> >> > > streaming API, although there's no actual DMA going on. >> >> > > >> >> > >> >> > OK, so you are relying on the fact that dma_alloc_coherent() gives you >> >> > a device mapping (because the qcom_scm device is described as non >> >> > cache coherent), but this sounds risky to me. The linear alias of that >> >> > memory will still be mapped cacheable, and could potentially still be >> >> > accessed speculatively AFAIK. >> >> > >> >> >> >> Yes and we are aware of the risk of having the linear alias present, but >> >> have yet to find a suitable way to handle this. >> >> >> >> The proposed mechanism was to use reserved-memory and memremap() the >> >> region while it should be available in Linux, >> > >> > That's still IO memory, and so it would be up to the specific device if >> > or not it could access the memory before a full write is done. >> > >> >> The risk here is about having aliases with mismatched attributes, >> which may result in loss of coherency and corrupt your data. > > That risk is a perhaps a practical risk. > >> This is >> not about the risk of loading a file with an invalid signature > > This is a theoretical risk LSMs wish to determine and based on information > assess what to do. > >> And what do you mean by 'IO memory'? Bus masters that are not behind >> an IOMMU can access all of the kernel's memory all of the time, >> regardless of whether and how it chooses to use it. So from a security >> perspective, there is no distinction, and you can only distinguish >> between before and after informing the device where it can find the >> firmware buffer in memory. > > I mean that using memremap() or ioremap() will is designed to give > hardware access to memory for IO purposes, and how writes occur > will vary, and as such we cannot give LSMs guarantees over that > the firmware API will finish a write and that the data provided > really is correct. > No, memremap() and ioremap() give the *CPU* access to memory. Other bus masters can freely access memory [unless they are behind an IOMMU] >> So given that we are dealing here with other masters that can change >> all of your memory behind your back, including the actual code you are >> running that implements the signature check, > > LSMs have the option to trust the kernel, its about context and letting LSMs > decide. They have the right to not trust IO devices to a memory segment, as it > could break guarantees the kernel is making, so this is not about trust or > not, its about *information* and letting LSMs choose. > But what point is there to letting LSMs decide that they do not trust an I/O device if there is nothing we can do about it? How can we prevent such an I/O device from modifying our memory? >> I wonder if there is a >> point to obsessing about this use case from a validation point of >> view. The higher privilege level protects
Re: [PATCH v6 17/18] crypto: ccm: Remove VLA usage
On 24 July 2018 at 18:49, Kees Cook wrote:
> From: Ard Biesheuvel
>
> In the quest to remove all stack VLA usage from the kernel[1], this
> drops AHASH_REQUEST_ON_STACK by preallocated the ahash request area
> with the skcipher area (which are not used at the same time).
>
-EGRAMMAR
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Ard Biesheuvel
> Signed-off-by: Kees Cook
> ---
> crypto/ccm.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/crypto/ccm.c b/crypto/ccm.c
> index 0a083342ec8c..b242fd0d3262 100644
> --- a/crypto/ccm.c
> +++ b/crypto/ccm.c
> @@ -50,7 +50,10 @@ struct crypto_ccm_req_priv_ctx {
> u32 flags;
> struct scatterlist src[3];
> struct scatterlist dst[3];
> - struct skcipher_request skreq;
> + union {
> + struct ahash_request ahreq;
> + struct skcipher_request skreq;
> + };
> };
>
> struct cbcmac_tfm_ctx {
> @@ -181,7 +184,7 @@ static int crypto_ccm_auth(struct aead_request *req,
> struct scatterlist *plain,
> struct crypto_ccm_req_priv_ctx *pctx = crypto_ccm_reqctx(req);
> struct crypto_aead *aead = crypto_aead_reqtfm(req);
> struct crypto_ccm_ctx *ctx = crypto_aead_ctx(aead);
> - AHASH_REQUEST_ON_STACK(ahreq, ctx->mac);
> + struct ahash_request *ahreq = &pctx->ahreq;
> unsigned int assoclen = req->assoclen;
> struct scatterlist sg[3];
> u8 *odata = pctx->odata;
> @@ -427,7 +430,7 @@ static int crypto_ccm_init_tfm(struct crypto_aead *tfm)
> crypto_aead_set_reqsize(
> tfm,
> align + sizeof(struct crypto_ccm_req_priv_ctx) +
> - crypto_skcipher_reqsize(ctr));
> + max(crypto_ahash_reqsize(mac), crypto_skcipher_reqsize(ctr)));
>
> return 0;
>
> --
> 2.17.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 6 June 2018 at 22:32, Luis R. Rodriguez wrote: > On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: >> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> > > >> > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already >> > > cc'd here) are better suited to answer that question. >> > >> > Andy, David, Bjorn? >> >> Andy, David, Bjorn? > > A month now with no answer... > > Perhaps someone who has this hardware can find out empirically for us, as > follows (mm folks is this right?): > > page = virt_to_page(address); > if (!page) >fail closed... > if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32) > this is a DMA buffer > else > not DMA! > As I replied in the other thread, this code makes no sense. In general, any address covered by the kernel direct mapping can be passed to the streaming DMA api and be mapped for device read xor device write. Only DMA mappings that will be accessed randomly by the device and the CPU at the same time require the use of dma_alloc_coherent(), so it can take special precautions (e.g, create an uncached mapping if DMA is non cache coherent) The DMA zone thing is primarily about reserving low memory ranges for DMA because some hardware may not have sufficient address lines wired up to access all of DRAM. > Note that when request_firmware_into_buf() was being reviewed Mimi had asked > back > in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA > should be > used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine. > > If it is a DMA buffer *now*, why / how did this change? > > [0] https://patchwork.kernel.org/patch/9074611/ > > Luis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 7 June 2018 at 00:29, Luis R. Rodriguez wrote: > On Wed, Jun 06, 2018 at 10:41:07PM +0200, Ard Biesheuvel wrote: >> On 6 June 2018 at 22:32, Luis R. Rodriguez wrote: >> > On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> >> On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: >> >> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> >> > > >> >> > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already >> >> > > cc'd here) are better suited to answer that question. >> >> > >> >> > Andy, David, Bjorn? >> >> >> >> Andy, David, Bjorn? >> > >> > A month now with no answer... >> > >> > Perhaps someone who has this hardware can find out empirically for us, as >> > follows (mm folks is this right?): >> > >> > page = virt_to_page(address); >> > if (!page) >> >fail closed... >> > if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32) >> > this is a DMA buffer >> > else >> > not DMA! >> > >> >> As I replied in the other thread, this code makes no sense. > > OK thanks. If we can't figure it out in code we will have no option > but to expect the worst, specially considering the silence. > >> In general, any address covered by the kernel direct mapping can be >> passed to the streaming DMA api and be mapped for device read xor >> device write. > > Right, thanks for the details -- on the other thread [0] you've clarified > that with streaming DMA API the CPU *should not* use the buffer and so > *should *be "safe", however that's still a judgement and design call. > True. > [0] https://lkml.kernel.org/r/20180606220605.gj4...@wotan.suse.de > >> Only DMA mappings that will be accessed randomly by the >> device and the CPU at the same time require the use of >> dma_alloc_coherent(), so it can take special precautions (e.g, create >> an uncached mapping if DMA is non cache coherent) > > Right and the qcom drivers *does not* use the streaming DMA API, it uses > use dma_alloc_coherent() which explicitly allows the CPU to *immediately* > have access the buffer. We have no control over the CPU and have no ways > to vet that the data we give is complete and correct. > Do you mean 'device' rather than 'CPU' here? The CPU always has access to memory allocation, but the device generally can only access the buffer after it has been mapped. Do note that especially in pc-centric code (which uses cache coherent DMA that is mapped 1:1 between the CPU physical address space and the DMA address space), you can actually get away with ignoring map/unmap entirely, in which case this becomes a 'should' as well. >> The DMA zone thing is primarily about reserving low memory ranges for >> DMA because some hardware may not have sufficient address lines wired >> up to access all of DRAM. > > Right. > > The point to all this is that it is up to LSMs to decide and trust something, > and in this case, even with the streaming DMA API in mind, it is up to LSMs > to decide. In this case we have only *one* user of request_firmware_into_buf() > and code inspection is finding that very likely the dma_alloc_coherent() calls > on the path is actually using this same coherent DMA buffer for firmware. > >> > Note that when request_firmware_into_buf() was being reviewed Mimi had >> > asked back >> > in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA >> > should be >> > used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine. >> > >> > If it is a DMA buffer *now*, why / how did this change? >> > >> > [0] https://patchwork.kernel.org/patch/9074611/ > > So it is *specially* very odd and disappointing that even though Mimi > *specifically* asked a long time ago that if a DMA buffer would be used it > should be annotated as such with READING_FIRMWARE_DMA, why the annotation > continued forward with READING_FIRMWARE_PREALLOC_BUFFER instead. > > Just as Mimi asked for READING_FIRMWARE_DMA it would seem we could reasonably > also > ask now or READING_FIRMWARE_DMA_COHERENT and READING_FIRMWARE_DMA_STREAM and > some > LSMs will just reject these calls. We don't need READING_FIRMWARE_DMA_STREAM > now > as request_firmware_into_buf() users are using dma_alloc_coherent() so we are > trying to determine if request_firmware_into_buf() should pass: > > READING_FIRMWARE_DMA_COHERENT > > Given no one is providing a clear answer, and we cannot easily describe the > buffer at run time we'll just move forward with READING_FIRMWARE_DMA_COHERENT. > I seriously wonder whether the QCOM code cannot switch to the streaming API instead. That is generally preferred anyway (for performance, although that should not matter for loading firmware) but also removes this single wart for which we have to invent new flags and new security code plus the associated validation overhead. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 7 June 2018 at 18:18, Bjorn Andersson wrote: > On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote: > >> On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> > On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: >> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> > > > >> > > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already >> > > > cc'd here) are better suited to answer that question. >> > > >> > > Andy, David, Bjorn? >> > >> > Andy, David, Bjorn? >> >> A month now with no answer... >> > > The patch at the top of this thread doesn't interest me and you didn't > bother sending your question To me. > > As a matter of fact I'm confused to what the actual question is. > The actual question is whether it is really required that the firmware is loaded by the kernel into a buffer that is already mapped for DMA at that point, and thus accessible by the device. To me, it is not entirely clear what the nature is of the firmware that we are talking about, since it seems to be getting passed to the secure world as well? In any case, the preferred model in terms of validation/sig checking is 1) allocate a CPU accessible buffer 2) request the firmware into it (which may include a sig check under the hood) 3) map the buffer for DMA to the device so it can load the firmware. 4) kick off the DMA transfer. The use of dma_alloc_coherent() for this purpose seems unnecessary, given that the DMA transfer is not bidirectional. Would it be possible to replace it with something like the above sequence? -- Ard. >> Perhaps someone who has this hardware can find out empirically for us, as >> follows (mm folks is this right?): >> >> page = virt_to_page(address); >> if (!page) >>fail closed... >> if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32) >> this is a DMA buffer >> else >> not DMA! >> > > Where do you want to put this? > >> Note that when request_firmware_into_buf() was being reviewed Mimi had asked >> back >> in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA >> should be >> used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine. >> >> If it is a DMA buffer *now*, why / how did this change? >> > > From what I can see [0] says is to use READING_FIRMWARE_PREALLOC_BUFFER > regardless of where the memory comes from. > > Regards, > Bjorn > >> [0] https://patchwork.kernel.org/patch/9074611/ >> >> Luis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 7 June 2018 at 18:33, Greg Kroah-Hartman wrote: > On Thu, Jun 07, 2018 at 06:23:01PM +0200, Ard Biesheuvel wrote: >> On 7 June 2018 at 18:18, Bjorn Andersson wrote: >> > On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote: >> > >> >> On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> >> > On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: >> >> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> >> > > > >> >> > > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already >> >> > > > cc'd here) are better suited to answer that question. >> >> > > >> >> > > Andy, David, Bjorn? >> >> > >> >> > Andy, David, Bjorn? >> >> >> >> A month now with no answer... >> >> >> > >> > The patch at the top of this thread doesn't interest me and you didn't >> > bother sending your question To me. >> > >> > As a matter of fact I'm confused to what the actual question is. >> > >> >> The actual question is whether it is really required that the firmware >> is loaded by the kernel into a buffer that is already mapped for DMA >> at that point, and thus accessible by the device. >> >> To me, it is not entirely clear what the nature is of the firmware >> that we are talking about, since it seems to be getting passed to the >> secure world as well? >> >> In any case, the preferred model in terms of validation/sig checking is >> >> 1) allocate a CPU accessible buffer >> >> 2) request the firmware into it (which may include a sig check under the >> hood) >> >> 3) map the buffer for DMA to the device so it can load the firmware. >> >> 4) kick off the DMA transfer. >> >> The use of dma_alloc_coherent() for this purpose seems unnecessary, >> given that the DMA transfer is not bidirectional. Would it be possible >> to replace it with something like the above sequence? > > Why not just use kmalloc, it will always return a DMAable buffer. > On a PC maybe. But there are plenty of systems where bidirectional DMA mappings require uncached memory (i.e., if the device doesn't snoop the caches), in which case a kmalloc'ed buffer is useless. dma_alloc_coherent() hides the platform constraints from the driver, so it is a very useful abstraction for this use case. > Is the problem that vmalloc() might not? > > We need to drop the whole DMA zone crud, it confuses everyone who sees > it and was primarily for really really old systems. > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 7 June 2018 at 18:49, Greg Kroah-Hartman wrote: > On Thu, Jun 07, 2018 at 06:43:05PM +0200, Ard Biesheuvel wrote: >> On 7 June 2018 at 18:33, Greg Kroah-Hartman >> wrote: >> > On Thu, Jun 07, 2018 at 06:23:01PM +0200, Ard Biesheuvel wrote: >> >> On 7 June 2018 at 18:18, Bjorn Andersson >> >> wrote: >> >> > On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote: >> >> > >> >> >> On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> >> >> > On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: >> >> >> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> >> >> > > > >> >> >> > > > I think the Qualcomm folks owning this (Andy, David, Bjorn, >> >> >> > > > already >> >> >> > > > cc'd here) are better suited to answer that question. >> >> >> > > >> >> >> > > Andy, David, Bjorn? >> >> >> > >> >> >> > Andy, David, Bjorn? >> >> >> >> >> >> A month now with no answer... >> >> >> >> >> > >> >> > The patch at the top of this thread doesn't interest me and you didn't >> >> > bother sending your question To me. >> >> > >> >> > As a matter of fact I'm confused to what the actual question is. >> >> > >> >> >> >> The actual question is whether it is really required that the firmware >> >> is loaded by the kernel into a buffer that is already mapped for DMA >> >> at that point, and thus accessible by the device. >> >> >> >> To me, it is not entirely clear what the nature is of the firmware >> >> that we are talking about, since it seems to be getting passed to the >> >> secure world as well? >> >> >> >> In any case, the preferred model in terms of validation/sig checking is >> >> >> >> 1) allocate a CPU accessible buffer >> >> >> >> 2) request the firmware into it (which may include a sig check under the >> >> hood) >> >> >> >> 3) map the buffer for DMA to the device so it can load the firmware. >> >> >> >> 4) kick off the DMA transfer. >> >> >> >> The use of dma_alloc_coherent() for this purpose seems unnecessary, >> >> given that the DMA transfer is not bidirectional. Would it be possible >> >> to replace it with something like the above sequence? >> > >> > Why not just use kmalloc, it will always return a DMAable buffer. >> > >> >> On a PC maybe. But there are plenty of systems where bidirectional DMA >> mappings require uncached memory (i.e., if the device doesn't snoop >> the caches), in which case a kmalloc'ed buffer is useless. >> dma_alloc_coherent() hides the platform constraints from the driver, >> so it is a very useful abstraction for this use case. > > kmalloc should always return a DMAble buffer. If that is not true, we > have a _LOT_ of broken drivers. What systems is this not true on, and > how are you running USB on them? :) > Non-cache coherent EHCI and XHCI work absolutely fine in Linux. The driver stack is perfectly well behaved, in the sense that it uses dma_alloc_coherent() for the data structures that are shared between the CPUs and the host controller. For the actual data that gets passed over USB, streaming DMA is used rather than coherent aka consistent aka bidirectional DMA, and that works fine with kmalloc'ed buffers, since you can use bounce buffering if the memory is not accessible to the device directly. That also means that you may prefer to allocate from a special DMA zone to prevent his, i.e., to ensure that the memory passed into the streaming DMA api does not require bounce buffering in the first place. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 7 June 2018 at 20:21, Bjorn Andersson wrote: > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote: > >> On Thu, Jun 07, 2018 at 06:23:01PM +0200, Ard Biesheuvel wrote: >> > On 7 June 2018 at 18:18, Bjorn Andersson >> > wrote: >> > > On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote: >> > > >> > >> On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> > >> > On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: >> > >> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> > >> > > > >> > >> > > > I think the Qualcomm folks owning this (Andy, David, Bjorn, >> > >> > > > already >> > >> > > > cc'd here) are better suited to answer that question. >> > >> > > >> > >> > > Andy, David, Bjorn? >> > >> > >> > >> > Andy, David, Bjorn? >> > >> >> > >> A month now with no answer... >> > >> >> > > >> > > The patch at the top of this thread doesn't interest me and you didn't >> > > bother sending your question To me. >> > > >> > > As a matter of fact I'm confused to what the actual question is. >> > > >> > >> > The actual question is whether it is really required that the firmware >> > is loaded by the kernel into a buffer that is already mapped for DMA >> > at that point, and thus accessible by the device. >> > >> > To me, it is not entirely clear what the nature is of the firmware >> > that we are talking about, since it seems to be getting passed to the >> > secure world as well? >> > >> > In any case, the preferred model in terms of validation/sig checking is >> > >> > 1) allocate a CPU accessible buffer >> > >> > 2) request the firmware into it (which may include a sig check under the >> > hood) >> > >> > 3) map the buffer for DMA to the device so it can load the firmware. >> > >> > 4) kick off the DMA transfer. >> > >> > The use of dma_alloc_coherent() for this purpose seems unnecessary, >> > given that the DMA transfer is not bidirectional. Would it be possible >> > to replace it with something like the above sequence? >> >> Why not just use kmalloc, it will always return a DMAable buffer. >> > > For the buffers being targeted by request_firmware_into_buf() the > problem is that some of them has requirements of physical placement and > they are all too big for kmalloc() (i.e. tens of mb). > > > For the dma_alloc_coherent() buffer that was mentioned earlier, which is > not related to the firmware loading, it's not used because the buffer is > passed to secure world, which temporarily locks Linux out from the > memory region. Traditionally this region was kmalloc'ed downstream, but > due to speculative access violations this code moved to use the DMA > streaming API, although there's no actual DMA going on. > OK, so you are relying on the fact that dma_alloc_coherent() gives you a device mapping (because the qcom_scm device is described as non cache coherent), but this sounds risky to me. The linear alias of that memory will still be mapped cacheable, and could potentially still be accessed speculatively AFAIK. > For this a way to allocate a chunk of physical memory dynamically and > then unmapping and remapping it dynamically in Linux sounds like a > solution, instead of (ab)using the DMA API. This could also serve as > basis for the firmware memory, where firmware is position independent - > in which case this would be passed to request_firmware_into_buf(). > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API
On 19 July 2017 at 19:28, Andy Shevchenko
wrote:
> There are new types and helpers that are supposed to be used in new code.
>
> As a preparation to get rid of legacy types and API functions do
> the conversion here.
>
> Cc: Matt Fleming
> Cc: Ard Biesheuvel
> Signed-off-by: Andy Shevchenko
Acked-by: Ard Biesheuvel
> ---
> drivers/firmware/efi/cper.c | 10 ++---
> include/linux/cper.h| 94
> ++---
> include/linux/efi.h | 4 +-
> 3 files changed, 54 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index 48a8f69da42a..684e65c11dde 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -534,7 +534,7 @@ static void
> cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data
> *gdata,
>int sec_no)
> {
> - uuid_le *sec_type = (uuid_le *)gdata->section_type;
> + guid_t *sec_type = (guid_t *)gdata->section_type;
> __u16 severity;
> char newpfx[64];
>
> @@ -545,12 +545,12 @@ cper_estatus_print_section(const char *pfx, struct
> acpi_hest_generic_data *gdata
> printk("%s""Error %d, type: %s\n", pfx, sec_no,
>cper_severity_str(severity));
> if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
> - printk("%s""fru_id: %pUl\n", pfx, (uuid_le *)gdata->fru_id);
> + printk("%s""fru_id: %pUl\n", pfx, gdata->fru_id);
> if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
> printk("%s""fru_text: %.20s\n", pfx, gdata->fru_text);
>
> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
> - if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
> + if (guid_equal(sec_type, &CPER_SEC_PROC_GENERIC)) {
> struct cper_sec_proc_generic *proc_err =
> acpi_hest_get_payload(gdata);
>
> printk("%s""section_type: general processor error\n", newpfx);
> @@ -558,7 +558,7 @@ cper_estatus_print_section(const char *pfx, struct
> acpi_hest_generic_data *gdata
> cper_print_proc_generic(newpfx, proc_err);
> else
> goto err_section_too_small;
> - } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
> + } else if (guid_equal(sec_type, &CPER_SEC_PLATFORM_MEM)) {
> struct cper_sec_mem_err *mem_err =
> acpi_hest_get_payload(gdata);
>
> printk("%s""section_type: memory error\n", newpfx);
> @@ -568,7 +568,7 @@ cper_estatus_print_section(const char *pfx, struct
> acpi_hest_generic_data *gdata
>gdata->error_data_length);
> else
> goto err_section_too_small;
> - } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
> + } else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
> struct cper_sec_pcie *pcie = acpi_hest_get_payload(gdata);
>
> printk("%s""section_type: PCIe error\n", newpfx);
> diff --git a/include/linux/cper.h b/include/linux/cper.h
> index 4c671fc2081e..723e952fde0d 100644
> --- a/include/linux/cper.h
> +++ b/include/linux/cper.h
> @@ -74,36 +74,36 @@ enum {
> * Corrected Machine Check
> */
> #define CPER_NOTIFY_CMC
> \
> - UUID_LE(0x2DCE8BB1, 0xBDD7, 0x450e, 0xB9, 0xAD, 0x9C, 0xF4, \
> - 0xEB, 0xD4, 0xF8, 0x90)
> + GUID_INIT(0x2DCE8BB1, 0xBDD7, 0x450e, 0xB9, 0xAD, 0x9C, 0xF4, \
> + 0xEB, 0xD4, 0xF8, 0x90)
> /* Corrected Platform Error */
> #define CPER_NOTIFY_CPE
> \
> - UUID_LE(0x4E292F96, 0xD843, 0x4a55, 0xA8, 0xC2, 0xD4, 0x81, \
> - 0xF2, 0x7E, 0xBE, 0xEE)
> + GUID_INIT(0x4E292F96, 0xD843, 0x4a55, 0xA8, 0xC2, 0xD4, 0x81, \
> + 0xF2, 0x7E, 0xBE, 0xEE)
> /* Machine Check Exception */
> #define CPER_NOTIFY_MCE
> \
> - UUID_LE(0xE8F56FFE, 0x919C, 0x4cc5, 0xBA, 0x88, 0x65, 0xAB, \
> - 0xE1, 0x49, 0x13, 0xBB)
> + GUID_INIT(0xE8F56FFE, 0x919C, 0x4cc5, 0xBA, 0x88, 0x65, 0xAB, \
> + 0xE1, 0x49, 0x13, 0xBB)
> /* PCI Express Error */
> #define CPER_NOTIFY_PCIE \
> - UUID_LE(0xCF93C01F, 0x1A16, 0x4dfc, 0x
Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API
On 26 July 2017 at 08:52, Christoph Hellwig wrote: > On Tue, Jul 25, 2017 at 01:40:06PM +0300, Andy Shevchenko wrote: >> Christoph, can we apply this one at least to move things forward? > > Id be happy to pick this up for 4.14. Does everyone involved agree > that the uuid tree is the right one? Fine by me for EFI ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 5/7] crypto: n2 - remove ecb(arc4) support
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 6a828bbecea4..c347e58cd9a1 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7 +662,6 @@ struct n2_skcipher_context {
u8 aes[AES_MAX_KEY_SIZE];
u8 des[DES_KEY_SIZE];
u8 des3[3 * DES_KEY_SIZE];
- u8 arc4[258]; /* S-box, X, Y */
} key;
};
@@ -789,36 +788,6 @@ static int n2_3des_setkey(struct crypto_skcipher
*skcipher, const u8 *key,
return 0;
}
-static int n2_arc4_setkey(struct crypto_skcipher *skcipher, const u8 *key,
- unsigned int keylen)
-{
- struct crypto_tfm *tfm = crypto_skcipher_tfm(skcipher);
- struct n2_skcipher_context *ctx = crypto_tfm_ctx(tfm);
- struct n2_skcipher_alg *n2alg = n2_skcipher_alg(skcipher);
- u8 *s = ctx->key.arc4;
- u8 *x = s + 256;
- u8 *y = x + 1;
- int i, j, k;
-
- ctx->enc_type = n2alg->enc_type;
-
- j = k = 0;
- *x = 0;
- *y = 0;
- for (i = 0; i < 256; i++)
- s[i] = i;
- for (i = 0; i < 256; i++) {
- u8 a = s[i];
- j = (j + key[k] + a) & 0xff;
- s[i] = s[j];
- s[j] = a;
- if (++k >= keylen)
- k = 0;
- }
-
- return 0;
-}
-
static inline int skcipher_descriptor_len(int nbytes, unsigned int block_size)
{
int this_len = nbytes;
@@ -1122,21 +1091,6 @@ struct n2_skcipher_tmpl {
};
static const struct n2_skcipher_tmpl skcipher_tmpls[] = {
- /* ARC4: only ECB is supported (chaining bits ignored) */
- { .name = "ecb(arc4)",
- .drv_name = "ecb-arc4",
- .block_size = 1,
- .enc_type = (ENC_TYPE_ALG_RC4_STREAM |
- ENC_TYPE_CHAINING_ECB),
- .skcipher = {
- .min_keysize= 1,
- .max_keysize= 256,
- .setkey = n2_arc4_setkey,
- .encrypt= n2_encrypt_ecb,
- .decrypt= n2_decrypt_ecb,
- },
- },
-
/* DES: ECB CBC and CFB are supported */
{ .name = "ecb(des)",
.drv_name = "ecb-des",
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API
Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
a maintenance perspective, since it does not quite behave like other
skciphers do in terms of key vs IV lifetime. Since we are leaving the
library interface in place, which is used by the various WEP and TKIP
implementations we have in the tree, we can safely drop this code now
it no longer has any users.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 12
crypto/Makefile | 1 -
crypto/arc4.c| 76
drivers/net/wireless/intel/ipw2x00/Kconfig | 1 -
drivers/net/wireless/intersil/hostap/Kconfig | 1 -
5 files changed, 91 deletions(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 091c0a0bbf26..fd0d1f78ac47 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1197,18 +1197,6 @@ config CRYPTO_ANUBIS
<https://www.cosic.esat.kuleuven.be/nessie/reports/>
<http://www.larc.usp.br/~pbarreto/AnubisPage.html>
-config CRYPTO_ARC4
- tristate "ARC4 cipher algorithm"
- select CRYPTO_SKCIPHER
- select CRYPTO_LIB_ARC4
- help
- ARC4 cipher algorithm.
-
- ARC4 is a stream cipher using keys ranging from 8 bits to 2048
- bits in length. This algorithm is required for driver-based
- WEP, but it should not be for other purposes because of the
- weakness of the algorithm.
-
config CRYPTO_BLOWFISH
tristate "Blowfish cipher algorithm"
select CRYPTO_ALGAPI
diff --git a/crypto/Makefile b/crypto/Makefile
index 4ca12b6044f7..af88c7e30b3c 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -128,7 +128,6 @@ obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia_generic.o
obj-$(CONFIG_CRYPTO_CAST_COMMON) += cast_common.o
obj-$(CONFIG_CRYPTO_CAST5) += cast5_generic.o
obj-$(CONFIG_CRYPTO_CAST6) += cast6_generic.o
-obj-$(CONFIG_CRYPTO_ARC4) += arc4.o
obj-$(CONFIG_CRYPTO_TEA) += tea.o
obj-$(CONFIG_CRYPTO_KHAZAD) += khazad.o
obj-$(CONFIG_CRYPTO_ANUBIS) += anubis.o
diff --git a/crypto/arc4.c b/crypto/arc4.c
deleted file mode 100644
index aa79571dbd49..
--- a/crypto/arc4.c
+++ /dev/null
@@ -1,76 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Cryptographic API
- *
- * ARC4 Cipher Algorithm
- *
- * Jon Oberheide
- */
-
-#include
-#include
-#include
-#include
-#include
-
-static int crypto_arc4_setkey(struct crypto_skcipher *tfm, const u8 *in_key,
- unsigned int key_len)
-{
- struct arc4_ctx *ctx = crypto_skcipher_ctx(tfm);
-
- return arc4_setkey(ctx, in_key, key_len);
-}
-
-static int crypto_arc4_crypt(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct arc4_ctx *ctx = crypto_skcipher_ctx(tfm);
- struct skcipher_walk walk;
- int err;
-
- err = skcipher_walk_virt(&walk, req, false);
-
- while (walk.nbytes > 0) {
- arc4_crypt(ctx, walk.dst.virt.addr, walk.src.virt.addr,
- walk.nbytes);
- err = skcipher_walk_done(&walk, 0);
- }
-
- return err;
-}
-
-static struct skcipher_alg arc4_alg = {
- /*
-* For legacy reasons, this is named "ecb(arc4)", not "arc4".
-* Nevertheless it's actually a stream cipher, not a block cipher.
-*/
- .base.cra_name = "ecb(arc4)",
- .base.cra_driver_name = "ecb(arc4)-generic",
- .base.cra_priority = 100,
- .base.cra_blocksize = ARC4_BLOCK_SIZE,
- .base.cra_ctxsize = sizeof(struct arc4_ctx),
- .base.cra_module= THIS_MODULE,
- .min_keysize= ARC4_MIN_KEY_SIZE,
- .max_keysize= ARC4_MAX_KEY_SIZE,
- .setkey = crypto_arc4_setkey,
- .encrypt= crypto_arc4_crypt,
- .decrypt= crypto_arc4_crypt,
-};
-
-static int __init arc4_init(void)
-{
- return crypto_register_skcipher(&arc4_alg);
-}
-
-static void __exit arc4_exit(void)
-{
- crypto_unregister_skcipher(&arc4_alg);
-}
-
-subsys_initcall(arc4_init);
-module_exit(arc4_exit);
-
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("ARC4 Cipher Algorithm");
-MODULE_AUTHOR("Jon Oberheide ");
-MODULE_ALIAS_CRYPTO("ecb(arc4)");
diff --git a/drivers/net/wireless/intel/ipw2x00/Kconfig
b/drivers/net/wireless/intel/ipw2x00/Kconfig
index d00386915a9d..82b7eea3495f 100644
--- a/drivers/net/wireless/intel/ipw2x00/Kconfig
+++ b/drivers/net/wireless/intel/ipw2x00/Kconfig
@@ -160,7 +160,6 @@ config LIBIPW
select WIRELESS_EXT
select WEXT_SPY
select CRYPTO
- select CRYPTO_ARC4
select CRYPTO_ECB
select CRYPTO_AES
select CRYPTO_
[RFC PATCH 0/7] crypto: get rid of ecb(arc4)
The RC4 algorithm does not fit the sckipher model very well: it is a stream cipher that combines the key and IV into a single vector, which implies that using the same key more than once amounts to stream cipher IV reuse, and therefore catastrophic failure. So let's replace the remaining legacy users (WEP and TKIP in the staging tree) to the ARC4 library interface, which does not rely on the crypto API at all. Also, remove the obsolete RC4-HMAC-MD5 algorithm from the SUNRPC driver stack. NOTE: It should not be too difficult to switch the kerberos code over to the ARC4 library interface as well, given that much of it uses a different code path already. But we should only do so if we really need to keep this support around, and it seems that this was only ever intended as a transitional algorithm for Windows NT/2000 clients. That leaves no remaining users of the ecb(arc4) skcipher, so we can remove any implementations as well. Cc: Herbert Xu Cc: "David S. Miller" Cc: Greg Kroah-Hartman Cc: Trond Myklebust Cc: Anna Schumaker Cc: "J. Bruce Fields" Cc: Chuck Lever Cc: Eric Biggers Cc: linux-cry...@vger.kernel.org Cc: net...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: linux-...@vger.kernel.org Ard Biesheuvel (7): staging/rtl8192e: switch to RC4 library interface staging/rtl8192u: switch to RC4 library interface SUNRPC: remove RC4-HMAC-MD5 support from KerberosV crypto: remove ARC4 support from the skcipher API crypto: n2 - remove ecb(arc4) support crypto: bcm-iproc - remove ecb(arc4) support crypto: tcrypt - remove ecb(arc4) testing/benchmarking support crypto/Kconfig| 12 - crypto/Makefile | 1 - crypto/arc4.c | 76 - crypto/tcrypt.c | 21 +- crypto/testmgr.c | 7 - crypto/testmgr.h | 62 drivers/crypto/bcm/cipher.c | 96 +- drivers/crypto/bcm/cipher.h | 1 - drivers/crypto/bcm/spu.c | 23 +- drivers/crypto/bcm/spu.h | 1 - drivers/crypto/bcm/spu2.c | 12 +- drivers/crypto/bcm/spu2.h | 1 - drivers/crypto/n2_core.c | 46 --- drivers/net/wireless/intel/ipw2x00/Kconfig| 1 - drivers/net/wireless/intersil/hostap/Kconfig | 1 - drivers/staging/rtl8192e/Kconfig | 4 +- drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 70 + drivers/staging/rtl8192e/rtllib_crypt_wep.c | 72 + drivers/staging/rtl8192u/Kconfig | 1 + .../rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 82 +- .../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 64 +--- include/linux/sunrpc/gss_krb5.h | 11 - include/linux/sunrpc/gss_krb5_enctypes.h | 9 +- net/sunrpc/Kconfig| 1 - net/sunrpc/auth_gss/gss_krb5_crypto.c | 276 -- net/sunrpc/auth_gss/gss_krb5_mech.c | 95 -- net/sunrpc/auth_gss/gss_krb5_seal.c | 1 - net/sunrpc/auth_gss/gss_krb5_seqnum.c | 87 -- net/sunrpc/auth_gss/gss_krb5_unseal.c | 1 - net/sunrpc/auth_gss/gss_krb5_wrap.c | 65 + 30 files changed, 78 insertions(+), 1122 deletions(-) delete mode 100644 crypto/arc4.c -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 2/7] staging/rtl8192u: switch to RC4 library interface
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
---
drivers/staging/rtl8192u/Kconfig | 1 +
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 82
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 64 +++
3 files changed, 27 insertions(+), 120 deletions(-)
diff --git a/drivers/staging/rtl8192u/Kconfig b/drivers/staging/rtl8192u/Kconfig
index 1edca5c304fb..ef883d462d3d 100644
--- a/drivers/staging/rtl8192u/Kconfig
+++ b/drivers/staging/rtl8192u/Kconfig
@@ -8,3 +8,4 @@ config RTL8192U
select CRYPTO
select CRYPTO_AES
select CRYPTO_CCM
+ select CRYPTO_LIB_ARC4
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index ffe624ed0c0c..a315133c20db 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -5,6 +5,7 @@
* Copyright (c) 2003-2004, Jouni Malinen
*/
+#include
#include
#include
#include
@@ -17,9 +18,7 @@
#include "ieee80211.h"
-#include
-#include
- #include
+#include
#include
MODULE_AUTHOR("Jouni Malinen");
@@ -49,9 +48,9 @@ struct ieee80211_tkip_data {
int key_idx;
- struct crypto_sync_skcipher *rx_tfm_arc4;
+ struct arc4_ctx rx_ctx_arc4;
+ struct arc4_ctx tx_ctx_arc4;
struct crypto_shash *rx_tfm_michael;
- struct crypto_sync_skcipher *tx_tfm_arc4;
struct crypto_shash *tx_tfm_michael;
/* scratch buffers for virt_to_page() (crypto API) */
@@ -62,19 +61,14 @@ static void *ieee80211_tkip_init(int key_idx)
{
struct ieee80211_tkip_data *priv;
+ if (fips_enabled)
+ return NULL;
+
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
goto fail;
priv->key_idx = key_idx;
- priv->tx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->tx_tfm_arc4)) {
- printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
- "crypto API arc4\n");
- priv->tx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
@@ -83,14 +77,6 @@ static void *ieee80211_tkip_init(int key_idx)
goto fail;
}
- priv->rx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->rx_tfm_arc4)) {
- printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
- "crypto API arc4\n");
- priv->rx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
@@ -104,9 +90,7 @@ static void *ieee80211_tkip_init(int key_idx)
fail:
if (priv) {
crypto_free_shash(priv->tx_tfm_michael);
- crypto_free_sync_skcipher(priv->tx_tfm_arc4);
crypto_free_shash(priv->rx_tfm_michael);
- crypto_free_sync_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -120,11 +104,9 @@ static void ieee80211_tkip_deinit(void *priv)
if (_priv) {
crypto_free_shash(_priv->tx_tfm_michael);
- crypto_free_sync_skcipher(_priv->tx_tfm_arc4);
crypto_free_shash(_priv->rx_tfm_michael);
- crypto_free_sync_skcipher(_priv->rx_tfm_arc4);
}
- kfree(priv);
+ kzfree(priv);
}
@@ -290,10 +272,8 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
u8 *pos;
struct rtl_80211_hdr_4addr *hdr;
struct cb_desc *tcb_desc = (struct cb_desc *)(skb->cb +
MAX_DEV_ADDR_SIZE);
- int ret = 0;
u8 rc4key[16], *icv;
u32 crc;
- struct scatterlist sg;
if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 ||
skb->len < hdr_len)
@@ -334,21 +314,15 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb,
int hdr_len, void *priv)
*pos++ = (tkey->tx_iv32 >> 24) & 0xff;
if (!tcb_desc->bHwSec) {
- SYNC_SKCIPHER_REQUEST_ON_STACK(req, tkey->tx_tfm_arc4);
-
icv = skb_put(skb, 4);
crc = ~crc32_le(~0, pos, len);
[RFC PATCH 1/7] staging/rtl8192e: switch to RC4 library interface
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 70 ---
drivers/staging/rtl8192e/rtllib_crypt_wep.c | 72
3 files changed, 28 insertions(+), 118 deletions(-)
diff --git a/drivers/staging/rtl8192e/Kconfig b/drivers/staging/rtl8192e/Kconfig
index 1007eea6c8fc..4c440bdaaf6e 100644
--- a/drivers/staging/rtl8192e/Kconfig
+++ b/drivers/staging/rtl8192e/Kconfig
@@ -25,7 +25,7 @@ config RTLLIB_CRYPTO_CCMP
config RTLLIB_CRYPTO_TKIP
tristate "Support for rtllib TKIP crypto"
depends on RTLLIB
- select CRYPTO_ARC4
+ select CRYPTO_LIB_ARC4
select CRYPTO_MICHAEL_MIC
default y
help
@@ -35,7 +35,7 @@ config RTLLIB_CRYPTO_TKIP
config RTLLIB_CRYPTO_WEP
tristate "Support for rtllib WEP crypto"
- select CRYPTO_ARC4
+ select CRYPTO_LIB_ARC4
depends on RTLLIB
default y
help
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
index 8d2a58e706d5..8c2ff37b2d3a 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
@@ -5,8 +5,9 @@
* Copyright (c) 2003-2004, Jouni Malinen
*/
+#include
#include
-#include
+#include
#include
#include
#include
@@ -16,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
@@ -45,9 +45,9 @@ struct rtllib_tkip_data {
u32 dot11RSNAStatsTKIPLocalMICFailures;
int key_idx;
- struct crypto_sync_skcipher *rx_tfm_arc4;
+ struct arc4_ctx rx_ctx_arc4;
+ struct arc4_ctx tx_ctx_arc4;
struct crypto_shash *rx_tfm_michael;
- struct crypto_sync_skcipher *tx_tfm_arc4;
struct crypto_shash *tx_tfm_michael;
/* scratch buffers for virt_to_page() (crypto API) */
u8 rx_hdr[16];
@@ -58,16 +58,13 @@ static void *rtllib_tkip_init(int key_idx)
{
struct rtllib_tkip_data *priv;
+ if (fips_enabled)
+ return NULL;
+
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
if (priv == NULL)
goto fail;
priv->key_idx = key_idx;
- priv->tx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->tx_tfm_arc4)) {
- pr_debug("Could not allocate crypto API arc4\n");
- priv->tx_tfm_arc4 = NULL;
- goto fail;
- }
priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
@@ -76,13 +73,6 @@ static void *rtllib_tkip_init(int key_idx)
goto fail;
}
- priv->rx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->rx_tfm_arc4)) {
- pr_debug("Could not allocate crypto API arc4\n");
- priv->rx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
pr_debug("Could not allocate crypto API michael_mic\n");
@@ -94,9 +84,7 @@ static void *rtllib_tkip_init(int key_idx)
fail:
if (priv) {
crypto_free_shash(priv->tx_tfm_michael);
- crypto_free_sync_skcipher(priv->tx_tfm_arc4);
crypto_free_shash(priv->rx_tfm_michael);
- crypto_free_sync_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -110,11 +98,9 @@ static void rtllib_tkip_deinit(void *priv)
if (_priv) {
crypto_free_shash(_priv->tx_tfm_michael);
- crypto_free_sync_skcipher(_priv->tx_tfm_arc4);
crypto_free_shash(_priv->rx_tfm_michael);
- crypto_free_sync_skcipher(_priv->rx_tfm_arc4);
}
- kfree(priv);
+ kzfree(priv);
}
@@ -289,7 +275,6 @@ static int rtllib_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
int ret = 0;
u8 rc4key[16], *icv;
u32 crc;
- struct scatterlist sg;
if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 ||
skb->len < hdr_len)
@@ -331,8 +316,6 @@ static int rtllib_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
*pos++ = (tkey->tx_iv32 >> 24) & 0xff;
if (!tcb_desc->bHwSec) {
- SYNC_SKCIPHER_REQUEST_ON_STACK(req, tkey->tx_tfm_arc4);
-
icv = skb_put(skb, 4);
crc = ~crc32_le(~0, pos, len);
icv[0] = crc;
@@ -340,15 +323,8 @@ static int rtllib
[RFC PATCH 6/7] crypto: bcm-iproc - remove ecb(arc4) support
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6 insertions(+), 128 deletions(-)
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index a353217a0d33..f73b4bd86482 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -165,10 +165,6 @@ spu_skcipher_rx_sg_create(struct brcm_message *mssg,
return -EFAULT;
}
- if (ctx->cipher.alg == CIPHER_ALG_RC4)
- /* Add buffer to catch 260-byte SUPDT field for RC4 */
- sg_set_buf(sg++, rctx->msg_buf.c.supdt_tweak, SPU_SUPDT_LEN);
-
if (stat_pad_len)
sg_set_buf(sg++, rctx->msg_buf.rx_stat_pad, stat_pad_len);
@@ -317,7 +313,6 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
u8 local_iv_ctr[MAX_IV_SIZE];
u32 stat_pad_len; /* num bytes to align status field */
u32 pad_len;/* total length of all padding */
- bool update_key = false;
struct brcm_message *mssg; /* mailbox message */
/* number of entries in src and dst sg in mailbox message. */
@@ -391,28 +386,6 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
}
}
- if (ctx->cipher.alg == CIPHER_ALG_RC4) {
- rx_frag_num++;
- if (chunk_start) {
- /*
-* for non-first RC4 chunks, use SUPDT from previous
-* response as key for this chunk.
-*/
- cipher_parms.key_buf = rctx->msg_buf.c.supdt_tweak;
- update_key = true;
- cipher_parms.type = CIPHER_TYPE_UPDT;
- } else if (!rctx->is_encrypt) {
- /*
-* First RC4 chunk. For decrypt, key in pre-built msg
-* header may have been changed if encrypt required
-* multiple chunks. So revert the key to the
-* ctx->enckey value.
-*/
- update_key = true;
- cipher_parms.type = CIPHER_TYPE_INIT;
- }
- }
-
if (ctx->max_payload == SPU_MAX_PAYLOAD_INF)
flow_log("max_payload infinite\n");
else
@@ -425,14 +398,9 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
memcpy(rctx->msg_buf.bcm_spu_req_hdr, ctx->bcm_spu_req_hdr,
sizeof(rctx->msg_buf.bcm_spu_req_hdr));
- /*
-* Pass SUPDT field as key. Key field in finish() call is only used
-* when update_key has been set above for RC4. Will be ignored in
-* all other cases.
-*/
spu->spu_cipher_req_finish(rctx->msg_buf.bcm_spu_req_hdr + BCM_HDR_LEN,
ctx->spu_req_hdr_len, !(rctx->is_encrypt),
- &cipher_parms, update_key, chunksize);
+ &cipher_parms, chunksize);
atomic64_add(chunksize, &iproc_priv.bytes_out);
@@ -527,9 +495,6 @@ static void handle_skcipher_resp(struct iproc_reqctx_s
*rctx)
__func__, rctx->total_received, payload_len);
dump_sg(req->dst, rctx->total_received, payload_len);
- if (ctx->cipher.alg == CIPHER_ALG_RC4)
- packet_dump(" supdt ", rctx->msg_buf.c.supdt_tweak,
- SPU_SUPDT_LEN);
rctx->total_received += payload_len;
if (rctx->total_received == rctx->total_todo) {
@@ -1853,26 +1818,6 @@ static int aes_setkey(struct crypto_skcipher *cipher,
const u8 *key,
return 0;
}
-static int rc4_setkey(struct crypto_skcipher *cipher, const u8 *key,
- unsigned int keylen)
-{
- struct iproc_ctx_s *ctx = crypto_skcipher_ctx(cipher);
- int i;
-
- ctx->enckeylen = ARC4_MAX_KEY_SIZE + ARC4_STATE_SIZE;
-
- ctx->enckey[0] = 0x00; /* 0x00 */
- ctx->enckey[1] = 0x00; /* i*/
- ctx->enckey[2] = 0x00; /* 0x00 */
- ctx->enckey[3] = 0x00; /* j*/
- for (i = 0; i < ARC4_MAX_KEY_SIZE; i++)
- ctx->enckey[i + ARC4_STATE_SIZE] = key[i % keylen];
-
- ctx->cipher_type = CIPHER_TYPE_INIT;
-
- return 0;
-}
-
static int skcipher_setkey(struct crypto_skcipher *cipher, const u8 *key,
unsigned int keylen)
{
@@ -1895,9 +1840,6 @@ static int skcipher_setkey(struct crypto_skcipher
*cipher, const u8 *key,
case CIPHER_ALG_AES:
err = aes_setkey(cipher, key, keylen);
brea
[RFC PATCH 7/7] crypto: tcrypt - remove ecb(arc4) testing/benchmarking support
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 21 +--
crypto/testmgr.c | 7 ---
crypto/testmgr.h | 62
3 files changed, 1 insertion(+), 89 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index ba0b7702f2e9..72828c4acd3a 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -68,7 +68,7 @@ static char *tvmem[TVMEMSIZE];
static const char *check[] = {
"des", "md5", "des3_ede", "rot13", "sha1", "sha224", "sha256", "sm3",
"blowfish", "twofish", "serpent", "sha384", "sha512", "md4", "aes",
- "cast6", "arc4", "michael_mic", "deflate", "crc32c", "tea", "xtea",
+ "cast6", "michael_mic", "deflate", "crc32c", "tea", "xtea",
"khazad", "wp512", "wp384", "wp256", "tnepres", "xeta", "fcrypt",
"camellia", "seed", "salsa20", "rmd128", "rmd160", "rmd256", "rmd320",
"lzo", "lzo-rle", "cts", "sha3-224", "sha3-256", "sha3-384",
@@ -1762,10 +1762,6 @@ static int do_test(const char *alg, u32 type, u32 mask,
int m, u32 num_mb)
ret += tcrypt_test("xts(cast6)");
break;
- case 16:
- ret += tcrypt_test("ecb(arc4)");
- break;
-
case 17:
ret += tcrypt_test("michael_mic");
break;
@@ -2201,11 +2197,6 @@ static int do_test(const char *alg, u32 type, u32 mask,
int m, u32 num_mb)
speed_template_32_64);
break;
- case 208:
- test_cipher_speed("ecb(arc4)", ENCRYPT, sec, NULL, 0,
- speed_template_8);
- break;
-
case 209:
test_cipher_speed("ecb(cast5)", ENCRYPT, sec, NULL, 0,
speed_template_8_16);
@@ -2720,11 +2711,6 @@ static int do_test(const char *alg, u32 type, u32 mask,
int m, u32 num_mb)
speed_template_32_48_64);
break;
- case 505:
- test_acipher_speed("ecb(arc4)", ENCRYPT, sec, NULL, 0,
- speed_template_8);
- break;
-
case 506:
test_acipher_speed("ecb(cast5)", ENCRYPT, sec, NULL, 0,
speed_template_8_16);
@@ -2932,11 +2918,6 @@ static int do_test(const char *alg, u32 type, u32 mask,
int m, u32 num_mb)
speed_template_32_48_64, num_mb);
break;
- case 605:
- test_mb_skcipher_speed("ecb(arc4)", ENCRYPT, sec, NULL, 0,
- speed_template_8, num_mb);
- break;
-
case 606:
test_mb_skcipher_speed("ecb(cast5)", ENCRYPT, sec, NULL, 0,
speed_template_8_16, num_mb);
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6863f911fcee..7c1bdc5690e2 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -4783,13 +4783,6 @@ static const struct alg_test_desc alg_test_descs[] = {
.suite = {
.cipher = __VECS(anubis_tv_template)
}
- }, {
- .alg = "ecb(arc4)",
- .generic_driver = "ecb(arc4)-generic",
- .test = alg_test_skcipher,
- .suite = {
- .cipher = __VECS(arc4_tv_template)
- }
}, {
.alg = "ecb(blowfish)",
.test = alg_test_skcipher,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index d29983908c38..48cd6330ec8d 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -22490,68 +22490,6 @@ static const struct cipher_testvec
cast5_ctr_tv_template[] = {
},
};
-/*
- * ARC4 test vectors from OpenSSL
- */
-static const struct cipher_testvec arc4_tv_template[] = {
- {
- .key= "\x01\x23\x45\x67\x89\xab\xcd\xef",
- .klen = 8,
- .ptext = "\x01\x23\x45\x67\x89\xab\xcd\xef",
- .ctext = "\x75\xb7\x87\x80\x99\xe0\xc5\x96",
- .len= 8,
- }, {
- .key= "\x01\x23\x45\x67\x89\xab\xcd\xef",
- .klen = 8,
- .ptext = "\x00\x00\x00\x00\x00\x00\x00\x00",
- .ctext = "\x74\x94\xc2\xe7\x10\x4b\x08\x79",
-
[RFC PATCH 3/7] SUNRPC: remove RC4-HMAC-MD5 support from KerberosV
The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
was specifically issued for interoperability with Windows 2000, but was
never intended to receive the same level of support. The RFC says
The IETF Kerberos community supports publishing this specification as
an informational document in order to describe this widely
implemented technology. However, while these encryption types
provide the operations necessary to implement the base Kerberos
specification [RFC4120], they do not provide all the required
operations in the Kerberos cryptography framework [RFC3961]. As a
result, it is not generally possible to implement potential
extensions to Kerberos using these encryption types. The Kerberos
encryption type negotiation mechanism [RFC4537] provides one approach
for using such extensions even when a Kerberos infrastructure uses
long-term RC4 keys. Because this specification does not implement
operations required by RFC 3961 and because of security concerns with
the use of RC4 and MD4 discussed in Section 8, this specification is
not appropriate for publication on the standards track.
The RC4-HMAC encryption types are used to ease upgrade of existing
Windows NT environments, provide strong cryptography (128-bit key
lengths), and provide exportable (meet United States government
export restriction requirements) encryption. This document describes
the implementation of those encryption types.
Furthermore, this RFC was re-classified as 'historic' by RFC 8429 [1] in
2018, stating that 'none of the encryption types it specifies should be
used'
Note that other outdated algorithms are left in place (some of which are
guarded by CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES), so this should only
adversely affect interoperability with Windows NT/2000 systems that have
not received any updates since 2008 (but are connected to a network
nonetheless)
[0] https://tools.ietf.org/html/rfc4757
[1] https://tools.ietf.org/html/rfc8429
Signed-off-by: Ard Biesheuvel
---
include/linux/sunrpc/gss_krb5.h | 11 -
include/linux/sunrpc/gss_krb5_enctypes.h | 9 +-
net/sunrpc/Kconfig | 1 -
net/sunrpc/auth_gss/gss_krb5_crypto.c| 276
net/sunrpc/auth_gss/gss_krb5_mech.c | 95 ---
net/sunrpc/auth_gss/gss_krb5_seal.c | 1 -
net/sunrpc/auth_gss/gss_krb5_seqnum.c| 87 --
net/sunrpc/auth_gss/gss_krb5_unseal.c| 1 -
net/sunrpc/auth_gss/gss_krb5_wrap.c | 65 +
9 files changed, 16 insertions(+), 530 deletions(-)
diff --git a/include/linux/sunrpc/gss_krb5.h b/include/linux/sunrpc/gss_krb5.h
index e8f8ffe7448b..91f43d86879d 100644
--- a/include/linux/sunrpc/gss_krb5.h
+++ b/include/linux/sunrpc/gss_krb5.h
@@ -141,14 +141,12 @@ enum sgn_alg {
SGN_ALG_MD2_5 = 0x0001,
SGN_ALG_DES_MAC = 0x0002,
SGN_ALG_3 = 0x0003, /* not published */
- SGN_ALG_HMAC_MD5 = 0x0011, /* microsoft w2k; no support */
SGN_ALG_HMAC_SHA1_DES3_KD = 0x0004
};
enum seal_alg {
SEAL_ALG_NONE = 0x,
SEAL_ALG_DES = 0x,
SEAL_ALG_1 = 0x0001,/* not published */
- SEAL_ALG_MICROSOFT_RC4 = 0x0010,/* microsoft w2k; no support */
SEAL_ALG_DES3KD = 0x0002
};
@@ -316,14 +314,5 @@ gss_krb5_aes_decrypt(struct krb5_ctx *kctx, u32 offset,
u32 len,
struct xdr_buf *buf, u32 *plainoffset,
u32 *plainlen);
-int
-krb5_rc4_setup_seq_key(struct krb5_ctx *kctx,
- struct crypto_sync_skcipher *cipher,
- unsigned char *cksum);
-
-int
-krb5_rc4_setup_enc_key(struct krb5_ctx *kctx,
- struct crypto_sync_skcipher *cipher,
- s32 seqnum);
void
gss_krb5_make_confounder(char *p, u32 conflen);
diff --git a/include/linux/sunrpc/gss_krb5_enctypes.h
b/include/linux/sunrpc/gss_krb5_enctypes.h
index 981c89cef19d..87eea679d750 100644
--- a/include/linux/sunrpc/gss_krb5_enctypes.h
+++ b/include/linux/sunrpc/gss_krb5_enctypes.h
@@ -13,15 +13,13 @@
#ifdef CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES
/*
- * NB: This list includes encryption types that were deprecated
- * by RFC 8429 (DES3_CBC_SHA1 and ARCFOUR_HMAC).
+ * NB: This list includes DES3_CBC_SHA1, which was deprecated by RFC 8429.
*
* ENCTYPE_AES256_CTS_HMAC_SHA1_96
* ENCTYPE_AES128_CTS_HMAC_SHA1_96
* ENCTYPE_DES3_CBC_SHA1
- * ENCTYPE_ARCFOUR_HMAC
*/
-#define KRB5_SUPPORTED_ENCTYPES "18,17,16,23"
+#define KRB5_SUPPORTED_ENCTYPES "18,17,16"
#else /* CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES */
@@ -32,12 +30,11 @@
* ENCTYPE_AES256_CTS_HMAC_SHA1_96
* ENCTYPE_AES128_CTS_HMAC_SHA1_96
* ENCTYPE_DES3_CBC_SHA1
- * ENCTYPE_ARCFOUR_HMAC
* ENCTYPE_DES_CBC_MD5
* ENCTYPE_DES_CBC_CRC
* ENCTYPE_DES_CBC_MD4
*/
-#define KRB5_SUPPORTED_ENCTYPES "18,17,16,23,3,1,2"
+#define
Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API
On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
>
> [+linux-wireless, Marcel Holtmann, and Denis Kenzior]
>
> On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
> > a maintenance perspective, since it does not quite behave like other
> > skciphers do in terms of key vs IV lifetime. Since we are leaving the
> > library interface in place, which is used by the various WEP and TKIP
> > implementations we have in the tree, we can safely drop this code now
> > it no longer has any users.
> >
> > Signed-off-by: Ard Biesheuvel
>
> Last year there was a discussion where it was mentioned that iwd uses
> "ecb(arc4)" via AF_ALG. So can we really remove it yet?
> See
> https://lkml.kernel.org/r/97bb95f6-4a4c-4984-9eab-6069e19b4...@holtmann.org
> Note that the code isn't in "iwd" itself but rather in "libell" which iwd
> depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/
>
> Apparently it also uses md4 and ecb(des) too.
>
Ah yes, I remember now :-(
> Marcel and Denis, what's your deprecation plan for these obsolete and insecure
> algorithms?
>
Given Denis's statement:
It sounds to me like it was broken and should be fixed. So our vote /
preference is to have ARC4 fixed to follow the proper semantics. We
can deal with the kernel behavioral change on our end easily enough;
the required workarounds are the worse evil.
I would think that an ABI break is not the end of the world for them,
and given how trivial it is to implement RC4 in C, the workaround
should be to simply implement RC4 in user space, and not even bother
trying to use AF_ALG to get at ecb(arc4)
(same applies to md4 and ecb(des) btw)
There will always be a long tail of use cases, and at some point, we
just have to draw the line and remove obsolete and insecure cruft,
especially when it impedes progress on other fronts.
Full implementation of arc4 aka ecb(arc4) below.
void arc4_crypt(struct arc4_ctx *ctx, u8 *out, const u8 *in, unsigned int len)
{
u32 *const S = ctx->S;
u32 x, y, a, b;
u32 ty, ta, tb;
if (len == 0)
return;
x = ctx->x;
y = ctx->y;
a = S[x];
y = (y + a) & 0xff;
b = S[y];
do {
S[y] = a;
a = (a + b) & 0xff;
S[x] = b;
x = (x + 1) & 0xff;
ta = S[x];
ty = (y + ta) & 0xff;
tb = S[ty];
*out++ = *in++ ^ S[a];
if (--len == 0)
break;
y = ty;
a = ta;
b = tb;
} while (true);
ctx->x = x;
ctx->y = y;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API
On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from > > > a maintenance perspective, since it does not quite behave like other > > > skciphers do in terms of key vs IV lifetime. Since we are leaving the > > > library interface in place, which is used by the various WEP and TKIP > > > implementations we have in the tree, we can safely drop this code now > > > it no longer has any users. > > > > > > Signed-off-by: Ard Biesheuvel > > > > Last year there was a discussion where it was mentioned that iwd uses > > "ecb(arc4)" via AF_ALG. So can we really remove it yet? > > See > > https://lkml.kernel.org/r/97bb95f6-4a4c-4984-9eab-6069e19b4...@holtmann.org > > Note that the code isn't in "iwd" itself but rather in "libell" which iwd > > depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/ > > > > Apparently it also uses md4 and ecb(des) too. > > > > Ah yes, I remember now :-( > > > Marcel and Denis, what's your deprecation plan for these obsolete and > > insecure > > algorithms? > > > > Given Denis's statement: > > It sounds to me like it was broken and should be fixed. So our vote / > preference is to have ARC4 fixed to follow the proper semantics. We > can deal with the kernel behavioral change on our end easily enough; > the required workarounds are the worse evil. > > I would think that an ABI break is not the end of the world for them, > and given how trivial it is to implement RC4 in C, the workaround > should be to simply implement RC4 in user space, and not even bother > trying to use AF_ALG to get at ecb(arc4) > > (same applies to md4 and ecb(des) btw) > > There will always be a long tail of use cases, and at some point, we > just have to draw the line and remove obsolete and insecure cruft, > especially when it impedes progress on other fronts. > I have ported iwd to Nettle's LGPL 2.1 implementation of ARC4, and the diffstat is src/crypto.c | 80 src/main.c| 8 -- unit/test-eapol.c | 3 +- 3 files changed, 51 insertions(+), 40 deletions(-) https://git.kernel.org/pub/scm/linux/kernel/git/ardb/iwd.git/log/?h=arc4-cleanup ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API
On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > > > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from > > > > a maintenance perspective, since it does not quite behave like other > > > > skciphers do in terms of key vs IV lifetime. Since we are leaving the > > > > library interface in place, which is used by the various WEP and TKIP > > > > implementations we have in the tree, we can safely drop this code now > > > > it no longer has any users. > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > Last year there was a discussion where it was mentioned that iwd uses > > > "ecb(arc4)" via AF_ALG. So can we really remove it yet? > > > See > > > https://lkml.kernel.org/r/97bb95f6-4a4c-4984-9eab-6069e19b4...@holtmann.org > > > Note that the code isn't in "iwd" itself but rather in "libell" which iwd > > > depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/ > > > > > > Apparently it also uses md4 and ecb(des) too. > > > > > > > Ah yes, I remember now :-( > > > > > Marcel and Denis, what's your deprecation plan for these obsolete and > > > insecure > > > algorithms? > > > > > > > Given Denis's statement: > > > > It sounds to me like it was broken and should be fixed. So our vote / > > preference is to have ARC4 fixed to follow the proper semantics. We > > can deal with the kernel behavioral change on our end easily enough; > > the required workarounds are the worse evil. > > > > I would think that an ABI break is not the end of the world for them, > > and given how trivial it is to implement RC4 in C, the workaround > > should be to simply implement RC4 in user space, and not even bother > > trying to use AF_ALG to get at ecb(arc4) > > > > (same applies to md4 and ecb(des) btw) > > > > There will always be a long tail of use cases, and at some point, we > > just have to draw the line and remove obsolete and insecure cruft, > > especially when it impedes progress on other fronts. > > > > I have ported iwd to Nettle's LGPL 2.1 implementation of ARC4, and the > diffstat is > > src/crypto.c | 80 > src/main.c| 8 -- > unit/test-eapol.c | 3 +- > 3 files changed, 51 insertions(+), 40 deletions(-) > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/iwd.git/log/?h=arc4-cleanup Marcel, Denis, Do you have any objections to the ecb(arc4) skcipher being dropped from the kernel, given the fallback i proposed above (which is a much better way of doing rc4 in user space anyway)? For libell, I would suggest dropping rc4 entirely, once iwd stops relying on it, as using rc4 for tls is obsolete as well. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API
On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote: > > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > > > > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome > > > > > from > > > > > a maintenance perspective, since it does not quite behave like other > > > > > skciphers do in terms of key vs IV lifetime. Since we are leaving the > > > > > library interface in place, which is used by the various WEP and TKIP > > > > > implementations we have in the tree, we can safely drop this code now > > > > > it no longer has any users. > > > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > Last year there was a discussion where it was mentioned that iwd uses > > > > "ecb(arc4)" via AF_ALG. So can we really remove it yet? > > > > See > > > > https://lkml.kernel.org/r/97bb95f6-4a4c-4984-9eab-6069e19b4...@holtmann.org > > > > Note that the code isn't in "iwd" itself but rather in "libell" which > > > > iwd > > > > depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/ > > > > > > > > Apparently it also uses md4 and ecb(des) too. > > > > > > > > > > Ah yes, I remember now :-( > > > > > > > Marcel and Denis, what's your deprecation plan for these obsolete and > > > > insecure > > > > algorithms? > > > > > > > > > > Given Denis's statement: > > > > > > It sounds to me like it was broken and should be fixed. So our vote / > > > preference is to have ARC4 fixed to follow the proper semantics. We > > > can deal with the kernel behavioral change on our end easily enough; > > > the required workarounds are the worse evil. > > > > > > I would think that an ABI break is not the end of the world for them, > > > and given how trivial it is to implement RC4 in C, the workaround > > > should be to simply implement RC4 in user space, and not even bother > > > trying to use AF_ALG to get at ecb(arc4) > > > > > > (same applies to md4 and ecb(des) btw) > > > > > > There will always be a long tail of use cases, and at some point, we > > > just have to draw the line and remove obsolete and insecure cruft, > > > especially when it impedes progress on other fronts. > > > > > > > I have ported iwd to Nettle's LGPL 2.1 implementation of ARC4, and the > > diffstat is > > > > src/crypto.c | 80 > > src/main.c| 8 -- > > unit/test-eapol.c | 3 +- > > 3 files changed, 51 insertions(+), 40 deletions(-) > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/iwd.git/log/?h=arc4-cleanup > > Marcel, Denis, > > Do you have any objections to the ecb(arc4) skcipher being dropped > from the kernel, given the fallback i proposed above (which is a much > better way of doing rc4 in user space anyway)? > > For libell, I would suggest dropping rc4 entirely, once iwd stops > relying on it, as using rc4 for tls is obsolete as well. Ping? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API
On Sat, 25 Jul 2020 at 10:06, Ard Biesheuvel wrote: > > On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote: > > > > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > > > > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > > > > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > > > > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > > > > > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome > > > > > > from > > > > > > a maintenance perspective, since it does not quite behave like other > > > > > > skciphers do in terms of key vs IV lifetime. Since we are leaving > > > > > > the > > > > > > library interface in place, which is used by the various WEP and > > > > > > TKIP > > > > > > implementations we have in the tree, we can safely drop this code > > > > > > now > > > > > > it no longer has any users. > > > > > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > > > Last year there was a discussion where it was mentioned that iwd uses > > > > > "ecb(arc4)" via AF_ALG. So can we really remove it yet? > > > > > See > > > > > https://lkml.kernel.org/r/97bb95f6-4a4c-4984-9eab-6069e19b4...@holtmann.org > > > > > Note that the code isn't in "iwd" itself but rather in "libell" which > > > > > iwd > > > > > depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/ > > > > > > > > > > Apparently it also uses md4 and ecb(des) too. > > > > > > > > > > > > > Ah yes, I remember now :-( > > > > > > > > > Marcel and Denis, what's your deprecation plan for these obsolete and > > > > > insecure > > > > > algorithms? > > > > > > > > > > > > > Given Denis's statement: > > > > > > > > It sounds to me like it was broken and should be fixed. So our vote / > > > > preference is to have ARC4 fixed to follow the proper semantics. We > > > > can deal with the kernel behavioral change on our end easily enough; > > > > the required workarounds are the worse evil. > > > > > > > > I would think that an ABI break is not the end of the world for them, > > > > and given how trivial it is to implement RC4 in C, the workaround > > > > should be to simply implement RC4 in user space, and not even bother > > > > trying to use AF_ALG to get at ecb(arc4) > > > > > > > > (same applies to md4 and ecb(des) btw) > > > > > > > > There will always be a long tail of use cases, and at some point, we > > > > just have to draw the line and remove obsolete and insecure cruft, > > > > especially when it impedes progress on other fronts. > > > > > > > > > > I have ported iwd to Nettle's LGPL 2.1 implementation of ARC4, and the > > > diffstat is > > > > > > src/crypto.c | 80 > > > src/main.c| 8 -- > > > unit/test-eapol.c | 3 +- > > > 3 files changed, 51 insertions(+), 40 deletions(-) > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/iwd.git/log/?h=arc4-cleanup > > > > Marcel, Denis, > > > > Do you have any objections to the ecb(arc4) skcipher being dropped > > from the kernel, given the fallback i proposed above (which is a much > > better way of doing rc4 in user space anyway)? > > > > For libell, I would suggest dropping rc4 entirely, once iwd stops > > relying on it, as using rc4 for tls is obsolete as well. > > Ping? Denis was kind enough to take the changes to iwd and libell that remove all dependencies on the ecb(arc4) skcipher exposed by the kernel, so we can at least deprecate it in the short term, and hopefully remove it entirely at a later stage. Perhaps we should introduce a Kconfig symbol that needs to be set to enable deprecated algorithms? That way, we can work with the distros to phase out the old junk that is piling up, but in a way that doesn't break people's systems. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 3/7] SUNRPC: remove RC4-HMAC-MD5 support from KerberosV
The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
was specifically issued for interoperability with Windows 2000, but was
never intended to receive the same level of support. The RFC says
The IETF Kerberos community supports publishing this specification as
an informational document in order to describe this widely
implemented technology. However, while these encryption types
provide the operations necessary to implement the base Kerberos
specification [RFC4120], they do not provide all the required
operations in the Kerberos cryptography framework [RFC3961]. As a
result, it is not generally possible to implement potential
extensions to Kerberos using these encryption types. The Kerberos
encryption type negotiation mechanism [RFC4537] provides one approach
for using such extensions even when a Kerberos infrastructure uses
long-term RC4 keys. Because this specification does not implement
operations required by RFC 3961 and because of security concerns with
the use of RC4 and MD4 discussed in Section 8, this specification is
not appropriate for publication on the standards track.
The RC4-HMAC encryption types are used to ease upgrade of existing
Windows NT environments, provide strong cryptography (128-bit key
lengths), and provide exportable (meet United States government
export restriction requirements) encryption. This document describes
the implementation of those encryption types.
Furthermore, this RFC was re-classified as 'historic' by RFC 8429 [1] in
2018, stating that 'none of the encryption types it specifies should be
used'
Note that other outdated algorithms are left in place (some of which are
guarded by CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES), so this should only
adversely affect interoperability with Windows NT/2000 systems that have
not received any updates since 2008 (but are connected to a network
nonetheless)
[0] https://tools.ietf.org/html/rfc4757
[1] https://tools.ietf.org/html/rfc8429
Signed-off-by: Ard Biesheuvel
Acked-by: J. Bruce Fields
---
include/linux/sunrpc/gss_krb5.h | 11 -
include/linux/sunrpc/gss_krb5_enctypes.h | 9 +-
net/sunrpc/Kconfig | 1 -
net/sunrpc/auth_gss/gss_krb5_crypto.c| 276
net/sunrpc/auth_gss/gss_krb5_mech.c | 95 ---
net/sunrpc/auth_gss/gss_krb5_seal.c | 1 -
net/sunrpc/auth_gss/gss_krb5_seqnum.c| 87 --
net/sunrpc/auth_gss/gss_krb5_unseal.c| 1 -
net/sunrpc/auth_gss/gss_krb5_wrap.c | 65 +
9 files changed, 16 insertions(+), 530 deletions(-)
diff --git a/include/linux/sunrpc/gss_krb5.h b/include/linux/sunrpc/gss_krb5.h
index e8f8ffe7448b..91f43d86879d 100644
--- a/include/linux/sunrpc/gss_krb5.h
+++ b/include/linux/sunrpc/gss_krb5.h
@@ -141,14 +141,12 @@ enum sgn_alg {
SGN_ALG_MD2_5 = 0x0001,
SGN_ALG_DES_MAC = 0x0002,
SGN_ALG_3 = 0x0003, /* not published */
- SGN_ALG_HMAC_MD5 = 0x0011, /* microsoft w2k; no support */
SGN_ALG_HMAC_SHA1_DES3_KD = 0x0004
};
enum seal_alg {
SEAL_ALG_NONE = 0x,
SEAL_ALG_DES = 0x,
SEAL_ALG_1 = 0x0001,/* not published */
- SEAL_ALG_MICROSOFT_RC4 = 0x0010,/* microsoft w2k; no support */
SEAL_ALG_DES3KD = 0x0002
};
@@ -316,14 +314,5 @@ gss_krb5_aes_decrypt(struct krb5_ctx *kctx, u32 offset,
u32 len,
struct xdr_buf *buf, u32 *plainoffset,
u32 *plainlen);
-int
-krb5_rc4_setup_seq_key(struct krb5_ctx *kctx,
- struct crypto_sync_skcipher *cipher,
- unsigned char *cksum);
-
-int
-krb5_rc4_setup_enc_key(struct krb5_ctx *kctx,
- struct crypto_sync_skcipher *cipher,
- s32 seqnum);
void
gss_krb5_make_confounder(char *p, u32 conflen);
diff --git a/include/linux/sunrpc/gss_krb5_enctypes.h
b/include/linux/sunrpc/gss_krb5_enctypes.h
index 981c89cef19d..87eea679d750 100644
--- a/include/linux/sunrpc/gss_krb5_enctypes.h
+++ b/include/linux/sunrpc/gss_krb5_enctypes.h
@@ -13,15 +13,13 @@
#ifdef CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES
/*
- * NB: This list includes encryption types that were deprecated
- * by RFC 8429 (DES3_CBC_SHA1 and ARCFOUR_HMAC).
+ * NB: This list includes DES3_CBC_SHA1, which was deprecated by RFC 8429.
*
* ENCTYPE_AES256_CTS_HMAC_SHA1_96
* ENCTYPE_AES128_CTS_HMAC_SHA1_96
* ENCTYPE_DES3_CBC_SHA1
- * ENCTYPE_ARCFOUR_HMAC
*/
-#define KRB5_SUPPORTED_ENCTYPES "18,17,16,23"
+#define KRB5_SUPPORTED_ENCTYPES "18,17,16"
#else /* CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES */
@@ -32,12 +30,11 @@
* ENCTYPE_AES256_CTS_HMAC_SHA1_96
* ENCTYPE_AES128_CTS_HMAC_SHA1_96
* ENCTYPE_DES3_CBC_SHA1
- * ENCTYPE_ARCFOUR_HMAC
* ENCTYPE_DES_CBC_MD5
* ENCTYPE_DES_CBC_CRC
* ENCTYPE_DES_CBC_MD4
*/
-#define KRB5_SUPPORTED_ENCTYPES "18,17,16,23,3,1,2"
+#define
[PATCH v2 1/7] staging/rtl8192e: switch to RC4 library interface
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 70 ---
drivers/staging/rtl8192e/rtllib_crypt_wep.c | 72
3 files changed, 28 insertions(+), 118 deletions(-)
diff --git a/drivers/staging/rtl8192e/Kconfig b/drivers/staging/rtl8192e/Kconfig
index 1007eea6c8fc..4c440bdaaf6e 100644
--- a/drivers/staging/rtl8192e/Kconfig
+++ b/drivers/staging/rtl8192e/Kconfig
@@ -25,7 +25,7 @@ config RTLLIB_CRYPTO_CCMP
config RTLLIB_CRYPTO_TKIP
tristate "Support for rtllib TKIP crypto"
depends on RTLLIB
- select CRYPTO_ARC4
+ select CRYPTO_LIB_ARC4
select CRYPTO_MICHAEL_MIC
default y
help
@@ -35,7 +35,7 @@ config RTLLIB_CRYPTO_TKIP
config RTLLIB_CRYPTO_WEP
tristate "Support for rtllib WEP crypto"
- select CRYPTO_ARC4
+ select CRYPTO_LIB_ARC4
depends on RTLLIB
default y
help
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
index 8d2a58e706d5..8c2ff37b2d3a 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
@@ -5,8 +5,9 @@
* Copyright (c) 2003-2004, Jouni Malinen
*/
+#include
#include
-#include
+#include
#include
#include
#include
@@ -16,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
@@ -45,9 +45,9 @@ struct rtllib_tkip_data {
u32 dot11RSNAStatsTKIPLocalMICFailures;
int key_idx;
- struct crypto_sync_skcipher *rx_tfm_arc4;
+ struct arc4_ctx rx_ctx_arc4;
+ struct arc4_ctx tx_ctx_arc4;
struct crypto_shash *rx_tfm_michael;
- struct crypto_sync_skcipher *tx_tfm_arc4;
struct crypto_shash *tx_tfm_michael;
/* scratch buffers for virt_to_page() (crypto API) */
u8 rx_hdr[16];
@@ -58,16 +58,13 @@ static void *rtllib_tkip_init(int key_idx)
{
struct rtllib_tkip_data *priv;
+ if (fips_enabled)
+ return NULL;
+
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
if (priv == NULL)
goto fail;
priv->key_idx = key_idx;
- priv->tx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->tx_tfm_arc4)) {
- pr_debug("Could not allocate crypto API arc4\n");
- priv->tx_tfm_arc4 = NULL;
- goto fail;
- }
priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
@@ -76,13 +73,6 @@ static void *rtllib_tkip_init(int key_idx)
goto fail;
}
- priv->rx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->rx_tfm_arc4)) {
- pr_debug("Could not allocate crypto API arc4\n");
- priv->rx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
pr_debug("Could not allocate crypto API michael_mic\n");
@@ -94,9 +84,7 @@ static void *rtllib_tkip_init(int key_idx)
fail:
if (priv) {
crypto_free_shash(priv->tx_tfm_michael);
- crypto_free_sync_skcipher(priv->tx_tfm_arc4);
crypto_free_shash(priv->rx_tfm_michael);
- crypto_free_sync_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -110,11 +98,9 @@ static void rtllib_tkip_deinit(void *priv)
if (_priv) {
crypto_free_shash(_priv->tx_tfm_michael);
- crypto_free_sync_skcipher(_priv->tx_tfm_arc4);
crypto_free_shash(_priv->rx_tfm_michael);
- crypto_free_sync_skcipher(_priv->rx_tfm_arc4);
}
- kfree(priv);
+ kzfree(priv);
}
@@ -289,7 +275,6 @@ static int rtllib_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
int ret = 0;
u8 rc4key[16], *icv;
u32 crc;
- struct scatterlist sg;
if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 ||
skb->len < hdr_len)
@@ -331,8 +316,6 @@ static int rtllib_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
*pos++ = (tkey->tx_iv32 >> 24) & 0xff;
if (!tcb_desc->bHwSec) {
- SYNC_SKCIPHER_REQUEST_ON_STACK(req, tkey->tx_tfm_arc4);
-
icv = skb_put(skb, 4);
crc = ~crc32_le(~0, pos, len);
icv[0] = crc;
@@ -340,15 +323,8 @@ static int rtllib
[PATCH v2 0/7] crypto: mark ecb(arc4) skcipher as obsolete
RC4 hasn't aged very well, and is a poor fit for the skcipher API so it would be good if we could get rid of the ecb(arc4) drivers in the kernel at some point in the future. This prevents new users from creeping in, and allows us to improve the skcipher API without having to care too much about obsolete algorithms that may be difficult to support going forward. So let's get rid of any remaining in-kernel users, either by switching them to the arc4 library API (for cases which simply cannot change algorithms, e.g., WEP), or dropping the code entirely. Also remove the remaining h/w accelerated implementations, and mark the generic s/w implementation as obsolete in Kconfig. Changes since RFC [0]: - keep ecb(arc4) generic C implementation, and the associated test vectors, but print a warning about ecb(arc4) being obsolete so we can identify remaining users - add a Kconfig option to en/disable obsolete algorithms that are only kept around to prevent breaking users that rely on it via the socket interface - add a patch to clean up some bogus Kconfig dependencies - add acks to patches #1, #2 and #3 [0] https://lore.kernel.org/driverdev-devel/20200702101947.682-1-a...@kernel.org/ Cc: Herbert Xu Cc: "David S. Miller" Cc: Greg Kroah-Hartman Cc: Trond Myklebust Cc: Anna Schumaker Cc: "J. Bruce Fields" Cc: Chuck Lever Cc: Eric Biggers Cc: Arnd Bergmann Cc: linux-cry...@vger.kernel.org Cc: net...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: linux-...@vger.kernel.org Ard Biesheuvel (7): staging/rtl8192e: switch to RC4 library interface staging/rtl8192u: switch to RC4 library interface SUNRPC: remove RC4-HMAC-MD5 support from KerberosV crypto: n2 - remove ecb(arc4) support crypto: bcm-iproc - remove ecb(arc4) support net: wireless: drop bogus CRYPTO_xxx Kconfig selects crypto: arc4 - mark ecb(arc4) skcipher as obsolete crypto/Kconfig| 10 + crypto/arc4.c | 10 + drivers/crypto/bcm/cipher.c | 96 +- drivers/crypto/bcm/cipher.h | 1 - drivers/crypto/bcm/spu.c | 23 +- drivers/crypto/bcm/spu.h | 1 - drivers/crypto/bcm/spu2.c | 12 +- drivers/crypto/bcm/spu2.h | 1 - drivers/crypto/n2_core.c | 46 --- drivers/net/wireless/intel/ipw2x00/Kconfig| 4 - drivers/net/wireless/intersil/hostap/Kconfig | 4 - drivers/staging/rtl8192e/Kconfig | 4 +- drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 70 + drivers/staging/rtl8192e/rtllib_crypt_wep.c | 72 + drivers/staging/rtl8192u/Kconfig | 1 + .../rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 81 + .../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 64 +--- include/linux/sunrpc/gss_krb5.h | 11 - include/linux/sunrpc/gss_krb5_enctypes.h | 9 +- net/sunrpc/Kconfig| 1 - net/sunrpc/auth_gss/gss_krb5_crypto.c | 276 -- net/sunrpc/auth_gss/gss_krb5_mech.c | 95 -- net/sunrpc/auth_gss/gss_krb5_seal.c | 1 - net/sunrpc/auth_gss/gss_krb5_seqnum.c | 87 -- net/sunrpc/auth_gss/gss_krb5_unseal.c | 1 - net/sunrpc/auth_gss/gss_krb5_wrap.c | 65 + 26 files changed, 97 insertions(+), 949 deletions(-) -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 4/7] crypto: n2 - remove ecb(arc4) support
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index d8aec5153b21..8c8e17d5fb20 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7 +662,6 @@ struct n2_skcipher_context {
u8 aes[AES_MAX_KEY_SIZE];
u8 des[DES_KEY_SIZE];
u8 des3[3 * DES_KEY_SIZE];
- u8 arc4[258]; /* S-box, X, Y */
} key;
};
@@ -789,36 +788,6 @@ static int n2_3des_setkey(struct crypto_skcipher
*skcipher, const u8 *key,
return 0;
}
-static int n2_arc4_setkey(struct crypto_skcipher *skcipher, const u8 *key,
- unsigned int keylen)
-{
- struct crypto_tfm *tfm = crypto_skcipher_tfm(skcipher);
- struct n2_skcipher_context *ctx = crypto_tfm_ctx(tfm);
- struct n2_skcipher_alg *n2alg = n2_skcipher_alg(skcipher);
- u8 *s = ctx->key.arc4;
- u8 *x = s + 256;
- u8 *y = x + 1;
- int i, j, k;
-
- ctx->enc_type = n2alg->enc_type;
-
- j = k = 0;
- *x = 0;
- *y = 0;
- for (i = 0; i < 256; i++)
- s[i] = i;
- for (i = 0; i < 256; i++) {
- u8 a = s[i];
- j = (j + key[k] + a) & 0xff;
- s[i] = s[j];
- s[j] = a;
- if (++k >= keylen)
- k = 0;
- }
-
- return 0;
-}
-
static inline int skcipher_descriptor_len(int nbytes, unsigned int block_size)
{
int this_len = nbytes;
@@ -1122,21 +1091,6 @@ struct n2_skcipher_tmpl {
};
static const struct n2_skcipher_tmpl skcipher_tmpls[] = {
- /* ARC4: only ECB is supported (chaining bits ignored) */
- { .name = "ecb(arc4)",
- .drv_name = "ecb-arc4",
- .block_size = 1,
- .enc_type = (ENC_TYPE_ALG_RC4_STREAM |
- ENC_TYPE_CHAINING_ECB),
- .skcipher = {
- .min_keysize= 1,
- .max_keysize= 256,
- .setkey = n2_arc4_setkey,
- .encrypt= n2_encrypt_ecb,
- .decrypt= n2_decrypt_ecb,
- },
- },
-
/* DES: ECB CBC and CFB are supported */
{ .name = "ecb(des)",
.drv_name = "ecb-des",
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/7] staging/rtl8192u: switch to RC4 library interface
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192u/Kconfig | 1 +
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 81
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 64 +++-
3 files changed, 27 insertions(+), 119 deletions(-)
diff --git a/drivers/staging/rtl8192u/Kconfig b/drivers/staging/rtl8192u/Kconfig
index 1edca5c304fb..ef883d462d3d 100644
--- a/drivers/staging/rtl8192u/Kconfig
+++ b/drivers/staging/rtl8192u/Kconfig
@@ -8,3 +8,4 @@ config RTL8192U
select CRYPTO
select CRYPTO_AES
select CRYPTO_CCM
+ select CRYPTO_LIB_ARC4
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index ffe624ed0c0c..4b415cc76715 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -5,6 +5,7 @@
* Copyright (c) 2003-2004, Jouni Malinen
*/
+#include
#include
#include
#include
@@ -17,9 +18,8 @@
#include "ieee80211.h"
+#include
#include
-#include
- #include
#include
MODULE_AUTHOR("Jouni Malinen");
@@ -49,9 +49,9 @@ struct ieee80211_tkip_data {
int key_idx;
- struct crypto_sync_skcipher *rx_tfm_arc4;
+ struct arc4_ctx rx_ctx_arc4;
+ struct arc4_ctx tx_ctx_arc4;
struct crypto_shash *rx_tfm_michael;
- struct crypto_sync_skcipher *tx_tfm_arc4;
struct crypto_shash *tx_tfm_michael;
/* scratch buffers for virt_to_page() (crypto API) */
@@ -62,19 +62,14 @@ static void *ieee80211_tkip_init(int key_idx)
{
struct ieee80211_tkip_data *priv;
+ if (fips_enabled)
+ return NULL;
+
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
goto fail;
priv->key_idx = key_idx;
- priv->tx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->tx_tfm_arc4)) {
- printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
- "crypto API arc4\n");
- priv->tx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
@@ -83,14 +78,6 @@ static void *ieee80211_tkip_init(int key_idx)
goto fail;
}
- priv->rx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->rx_tfm_arc4)) {
- printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
- "crypto API arc4\n");
- priv->rx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
@@ -104,9 +91,7 @@ static void *ieee80211_tkip_init(int key_idx)
fail:
if (priv) {
crypto_free_shash(priv->tx_tfm_michael);
- crypto_free_sync_skcipher(priv->tx_tfm_arc4);
crypto_free_shash(priv->rx_tfm_michael);
- crypto_free_sync_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -120,11 +105,9 @@ static void ieee80211_tkip_deinit(void *priv)
if (_priv) {
crypto_free_shash(_priv->tx_tfm_michael);
- crypto_free_sync_skcipher(_priv->tx_tfm_arc4);
crypto_free_shash(_priv->rx_tfm_michael);
- crypto_free_sync_skcipher(_priv->rx_tfm_arc4);
}
- kfree(priv);
+ kzfree(priv);
}
@@ -290,10 +273,8 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
u8 *pos;
struct rtl_80211_hdr_4addr *hdr;
struct cb_desc *tcb_desc = (struct cb_desc *)(skb->cb +
MAX_DEV_ADDR_SIZE);
- int ret = 0;
u8 rc4key[16], *icv;
u32 crc;
- struct scatterlist sg;
if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 ||
skb->len < hdr_len)
@@ -334,21 +315,15 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb,
int hdr_len, void *priv)
*pos++ = (tkey->tx_iv32 >> 24) & 0xff;
if (!tcb_desc->bHwSec) {
- SYNC_SKCIPHER_REQUEST_ON_STACK(req, tkey->tx_tfm_arc4);
-
icv = skb_put(skb, 4);
crc =
[PATCH v2 7/7] crypto: arc4 - mark ecb(arc4) skcipher as obsolete
Cryptographic algorithms may have a lifespan that is significantly
shorter than Linux's, and so we need to start phasing out algorithms
that are known to be broken, and are no longer fit for general use.
RC4 (or arc4) is a good example here: there are a few areas where its
use is still somewhat acceptable, e.g., for interoperability with legacy
wifi hardware that can only use WEP or TKIP data encryption, but that
should not imply that, for instance, use of RC4 based EAP-TLS by the WPA
supplicant for negotiating TKIP keys is equally acceptable, or that RC4
should remain available as a general purpose cryptographic transform for
all in-kernel and user space clients.
Now that all in-kernel users that need to retain support have moved to
the arc4 library interface, and the known users of ecb(arc4) via the
socket API (iwd [0] and libell [1][2]) have been updated to switch to a
local implementation, we can take the next step, and mark the ecb(arc4)
skcipher as obsolete, and only provide it if the socket API is enabled in
the first place, as well as provide the option to disable all algorithms
that have been marked as obsolete.
[0]
https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=1db8a85a60c64523
[1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2
[2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 10 ++
crypto/arc4.c | 10 ++
2 files changed, 20 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 1b57419fa2e7..89d63d240c2e 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -136,6 +136,15 @@ config CRYPTO_USER
Userspace configuration for cryptographic instantiations such as
cbc(aes).
+config CRYPTO_USER_ENABLE_OBSOLETE
+ bool "Enable obsolete cryptographic algorithms for userspace"
+ depends on CRYPTO_USER
+ default y
+ help
+ Allow obsolete cryptographic algorithms to be selected that have
+ already been phased out from internal use by the kernel, and are
+ only useful for userspace clients that still rely on them.
+
config CRYPTO_MANAGER_DISABLE_TESTS
bool "Disable run-time self tests"
default y
@@ -1199,6 +1208,7 @@ config CRYPTO_ANUBIS
config CRYPTO_ARC4
tristate "ARC4 cipher algorithm"
+ depends on CRYPTO_USER_ENABLE_OBSOLETE
select CRYPTO_SKCIPHER
select CRYPTO_LIB_ARC4
help
diff --git a/crypto/arc4.c b/crypto/arc4.c
index aa79571dbd49..923aa7a6cd60 100644
--- a/crypto/arc4.c
+++ b/crypto/arc4.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
static int crypto_arc4_setkey(struct crypto_skcipher *tfm, const u8 *in_key,
unsigned int key_len)
@@ -39,6 +40,14 @@ static int crypto_arc4_crypt(struct skcipher_request *req)
return err;
}
+static int crypto_arc4_init(struct crypto_skcipher *tfm)
+{
+ pr_warn_ratelimited("\"%s\" (%ld) uses obsolete ecb(arc4) skcipher\n",
+ current->comm, (unsigned long)current->pid);
+
+ return 0;
+}
+
static struct skcipher_alg arc4_alg = {
/*
* For legacy reasons, this is named "ecb(arc4)", not "arc4".
@@ -55,6 +64,7 @@ static struct skcipher_alg arc4_alg = {
.setkey = crypto_arc4_setkey,
.encrypt= crypto_arc4_crypt,
.decrypt= crypto_arc4_crypt,
+ .init = crypto_arc4_init,
};
static int __init arc4_init(void)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 5/7] crypto: bcm-iproc - remove ecb(arc4) support
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6 insertions(+), 128 deletions(-)
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index 8a7fa1ae1ade..5d38b87b9d77 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -165,10 +165,6 @@ spu_skcipher_rx_sg_create(struct brcm_message *mssg,
return -EFAULT;
}
- if (ctx->cipher.alg == CIPHER_ALG_RC4)
- /* Add buffer to catch 260-byte SUPDT field for RC4 */
- sg_set_buf(sg++, rctx->msg_buf.c.supdt_tweak, SPU_SUPDT_LEN);
-
if (stat_pad_len)
sg_set_buf(sg++, rctx->msg_buf.rx_stat_pad, stat_pad_len);
@@ -317,7 +313,6 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
u8 local_iv_ctr[MAX_IV_SIZE];
u32 stat_pad_len; /* num bytes to align status field */
u32 pad_len;/* total length of all padding */
- bool update_key = false;
struct brcm_message *mssg; /* mailbox message */
/* number of entries in src and dst sg in mailbox message. */
@@ -391,28 +386,6 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
}
}
- if (ctx->cipher.alg == CIPHER_ALG_RC4) {
- rx_frag_num++;
- if (chunk_start) {
- /*
-* for non-first RC4 chunks, use SUPDT from previous
-* response as key for this chunk.
-*/
- cipher_parms.key_buf = rctx->msg_buf.c.supdt_tweak;
- update_key = true;
- cipher_parms.type = CIPHER_TYPE_UPDT;
- } else if (!rctx->is_encrypt) {
- /*
-* First RC4 chunk. For decrypt, key in pre-built msg
-* header may have been changed if encrypt required
-* multiple chunks. So revert the key to the
-* ctx->enckey value.
-*/
- update_key = true;
- cipher_parms.type = CIPHER_TYPE_INIT;
- }
- }
-
if (ctx->max_payload == SPU_MAX_PAYLOAD_INF)
flow_log("max_payload infinite\n");
else
@@ -425,14 +398,9 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
memcpy(rctx->msg_buf.bcm_spu_req_hdr, ctx->bcm_spu_req_hdr,
sizeof(rctx->msg_buf.bcm_spu_req_hdr));
- /*
-* Pass SUPDT field as key. Key field in finish() call is only used
-* when update_key has been set above for RC4. Will be ignored in
-* all other cases.
-*/
spu->spu_cipher_req_finish(rctx->msg_buf.bcm_spu_req_hdr + BCM_HDR_LEN,
ctx->spu_req_hdr_len, !(rctx->is_encrypt),
- &cipher_parms, update_key, chunksize);
+ &cipher_parms, chunksize);
atomic64_add(chunksize, &iproc_priv.bytes_out);
@@ -527,9 +495,6 @@ static void handle_skcipher_resp(struct iproc_reqctx_s
*rctx)
__func__, rctx->total_received, payload_len);
dump_sg(req->dst, rctx->total_received, payload_len);
- if (ctx->cipher.alg == CIPHER_ALG_RC4)
- packet_dump(" supdt ", rctx->msg_buf.c.supdt_tweak,
- SPU_SUPDT_LEN);
rctx->total_received += payload_len;
if (rctx->total_received == rctx->total_todo) {
@@ -1853,26 +1818,6 @@ static int aes_setkey(struct crypto_skcipher *cipher,
const u8 *key,
return 0;
}
-static int rc4_setkey(struct crypto_skcipher *cipher, const u8 *key,
- unsigned int keylen)
-{
- struct iproc_ctx_s *ctx = crypto_skcipher_ctx(cipher);
- int i;
-
- ctx->enckeylen = ARC4_MAX_KEY_SIZE + ARC4_STATE_SIZE;
-
- ctx->enckey[0] = 0x00; /* 0x00 */
- ctx->enckey[1] = 0x00; /* i*/
- ctx->enckey[2] = 0x00; /* 0x00 */
- ctx->enckey[3] = 0x00; /* j*/
- for (i = 0; i < ARC4_MAX_KEY_SIZE; i++)
- ctx->enckey[i + ARC4_STATE_SIZE] = key[i % keylen];
-
- ctx->cipher_type = CIPHER_TYPE_INIT;
-
- return 0;
-}
-
static int skcipher_setkey(struct crypto_skcipher *cipher, const u8 *key,
unsigned int keylen)
{
@@ -1895,9 +1840,6 @@ static int skcipher_setkey(struct crypto_skcipher
*cipher, const u8 *key,
case CIPHER_ALG_AES:
err = aes_setkey(cipher, key, keylen);
brea
[PATCH v2 6/7] net: wireless: drop bogus CRYPTO_xxx Kconfig selects
Drop some bogus Kconfig selects that are not entirely accurate, and unnecessary to begin with, since the same Kconfig options also select LIB80211 features that already imply the selected functionality (AES for CCMP, ARC4 and ECB for TKIP) Signed-off-by: Ard Biesheuvel --- drivers/net/wireless/intel/ipw2x00/Kconfig | 4 drivers/net/wireless/intersil/hostap/Kconfig | 4 2 files changed, 8 deletions(-) diff --git a/drivers/net/wireless/intel/ipw2x00/Kconfig b/drivers/net/wireless/intel/ipw2x00/Kconfig index b1e7b4470842..1650d5865aa0 100644 --- a/drivers/net/wireless/intel/ipw2x00/Kconfig +++ b/drivers/net/wireless/intel/ipw2x00/Kconfig @@ -160,11 +160,7 @@ config LIBIPW select WIRELESS_EXT select WEXT_SPY select CRYPTO - select CRYPTO_ARC4 - select CRYPTO_ECB - select CRYPTO_AES select CRYPTO_MICHAEL_MIC - select CRYPTO_ECB select CRC32 select LIB80211 select LIB80211_CRYPT_WEP diff --git a/drivers/net/wireless/intersil/hostap/Kconfig b/drivers/net/wireless/intersil/hostap/Kconfig index 6ad88299432f..c865d3156cea 100644 --- a/drivers/net/wireless/intersil/hostap/Kconfig +++ b/drivers/net/wireless/intersil/hostap/Kconfig @@ -5,11 +5,7 @@ config HOSTAP select WEXT_SPY select WEXT_PRIV select CRYPTO - select CRYPTO_ARC4 - select CRYPTO_ECB - select CRYPTO_AES select CRYPTO_MICHAEL_MIC - select CRYPTO_ECB select CRC32 select LIB80211 select LIB80211_CRYPT_WEP -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 7/7] crypto: arc4 - mark ecb(arc4) skcipher as obsolete
On Mon, 24 Aug 2020 at 15:35, Herbert Xu wrote: > > On Mon, Aug 24, 2020 at 03:30:01PM +0200, Ard Biesheuvel wrote: > > > > +config CRYPTO_USER_ENABLE_OBSOLETE > > + bool "Enable obsolete cryptographic algorithms for userspace" > > + depends on CRYPTO_USER > > That should be CRYPTO_USER_API which is the option for af_alg. > CRYPTO_USER is the configuration interface which has nothing to > do with af_alg. > OK, will fix. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 0/7] crypto: mark ecb(arc4) skcipher as obsolete
RC4 hasn't aged very well, and is a poor fit for the skcipher API so it would be good if we could get rid of the ecb(arc4) drivers in the kernel at some point in the future. This prevents new users from creeping in, and allows us to improve the skcipher API without having to care too much about obsolete algorithms that may be difficult to support going forward. So let's get rid of any remaining in-kernel users, either by switching them to the arc4 library API (for cases which simply cannot change algorithms, e.g., WEP), or dropping the code entirely. Also remove the remaining h/w accelerated implementations, and mark the generic s/w implementation as obsolete in Kconfig. Changes since v2: - depend on CRYPTO_USER_API not CRYPTO_USER - rename CRYPTO_USER_ENABLE_OBSOLETE to CRYPTO_USER_API_ENABLE_OBSOLETE for clarity Changes since RFC [0]: - keep ecb(arc4) generic C implementation, and the associated test vectors, but print a warning about ecb(arc4) being obsolete so we can identify remaining users - add a Kconfig option to en/disable obsolete algorithms that are only kept around to prevent breaking users that rely on it via the socket interface - add a patch to clean up some bogus Kconfig dependencies - add acks to patches #1, #2 and #3 [0] https://lore.kernel.org/driverdev-devel/20200702101947.682-1-a...@kernel.org/ Cc: Herbert Xu Cc: "David S. Miller" Cc: Greg Kroah-Hartman Cc: Trond Myklebust Cc: Anna Schumaker Cc: "J. Bruce Fields" Cc: Chuck Lever Cc: Eric Biggers Cc: Arnd Bergmann Cc: linux-cry...@vger.kernel.org Cc: net...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: linux-...@vger.kernel.org Ard Biesheuvel (7): staging/rtl8192e: switch to RC4 library interface staging/rtl8192u: switch to RC4 library interface SUNRPC: remove RC4-HMAC-MD5 support from KerberosV crypto: n2 - remove ecb(arc4) support crypto: bcm-iproc - remove ecb(arc4) support net: wireless: drop bogus CRYPTO_xxx Kconfig selects crypto: arc4 - mark ecb(arc4) skcipher as obsolete crypto/Kconfig| 10 + crypto/arc4.c | 10 + drivers/crypto/bcm/cipher.c | 96 +- drivers/crypto/bcm/cipher.h | 1 - drivers/crypto/bcm/spu.c | 23 +- drivers/crypto/bcm/spu.h | 1 - drivers/crypto/bcm/spu2.c | 12 +- drivers/crypto/bcm/spu2.h | 1 - drivers/crypto/n2_core.c | 46 --- drivers/net/wireless/intel/ipw2x00/Kconfig| 4 - drivers/net/wireless/intersil/hostap/Kconfig | 4 - drivers/staging/rtl8192e/Kconfig | 4 +- drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 70 + drivers/staging/rtl8192e/rtllib_crypt_wep.c | 72 + drivers/staging/rtl8192u/Kconfig | 1 + .../rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 81 + .../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 64 +--- include/linux/sunrpc/gss_krb5.h | 11 - include/linux/sunrpc/gss_krb5_enctypes.h | 9 +- net/sunrpc/Kconfig| 1 - net/sunrpc/auth_gss/gss_krb5_crypto.c | 276 -- net/sunrpc/auth_gss/gss_krb5_mech.c | 95 -- net/sunrpc/auth_gss/gss_krb5_seal.c | 1 - net/sunrpc/auth_gss/gss_krb5_seqnum.c | 87 -- net/sunrpc/auth_gss/gss_krb5_unseal.c | 1 - net/sunrpc/auth_gss/gss_krb5_wrap.c | 65 + 26 files changed, 97 insertions(+), 949 deletions(-) -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 6/7] net: wireless: drop bogus CRYPTO_xxx Kconfig selects
Drop some bogus Kconfig selects that are not entirely accurate, and unnecessary to begin with, since the same Kconfig options also select LIB80211 features that already imply the selected functionality (AES for CCMP, ARC4 and ECB for TKIP) Signed-off-by: Ard Biesheuvel --- drivers/net/wireless/intel/ipw2x00/Kconfig | 4 drivers/net/wireless/intersil/hostap/Kconfig | 4 2 files changed, 8 deletions(-) diff --git a/drivers/net/wireless/intel/ipw2x00/Kconfig b/drivers/net/wireless/intel/ipw2x00/Kconfig index b1e7b4470842..1650d5865aa0 100644 --- a/drivers/net/wireless/intel/ipw2x00/Kconfig +++ b/drivers/net/wireless/intel/ipw2x00/Kconfig @@ -160,11 +160,7 @@ config LIBIPW select WIRELESS_EXT select WEXT_SPY select CRYPTO - select CRYPTO_ARC4 - select CRYPTO_ECB - select CRYPTO_AES select CRYPTO_MICHAEL_MIC - select CRYPTO_ECB select CRC32 select LIB80211 select LIB80211_CRYPT_WEP diff --git a/drivers/net/wireless/intersil/hostap/Kconfig b/drivers/net/wireless/intersil/hostap/Kconfig index 6ad88299432f..c865d3156cea 100644 --- a/drivers/net/wireless/intersil/hostap/Kconfig +++ b/drivers/net/wireless/intersil/hostap/Kconfig @@ -5,11 +5,7 @@ config HOSTAP select WEXT_SPY select WEXT_PRIV select CRYPTO - select CRYPTO_ARC4 - select CRYPTO_ECB - select CRYPTO_AES select CRYPTO_MICHAEL_MIC - select CRYPTO_ECB select CRC32 select LIB80211 select LIB80211_CRYPT_WEP -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 4/7] crypto: n2 - remove ecb(arc4) support
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index d8aec5153b21..8c8e17d5fb20 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7 +662,6 @@ struct n2_skcipher_context {
u8 aes[AES_MAX_KEY_SIZE];
u8 des[DES_KEY_SIZE];
u8 des3[3 * DES_KEY_SIZE];
- u8 arc4[258]; /* S-box, X, Y */
} key;
};
@@ -789,36 +788,6 @@ static int n2_3des_setkey(struct crypto_skcipher
*skcipher, const u8 *key,
return 0;
}
-static int n2_arc4_setkey(struct crypto_skcipher *skcipher, const u8 *key,
- unsigned int keylen)
-{
- struct crypto_tfm *tfm = crypto_skcipher_tfm(skcipher);
- struct n2_skcipher_context *ctx = crypto_tfm_ctx(tfm);
- struct n2_skcipher_alg *n2alg = n2_skcipher_alg(skcipher);
- u8 *s = ctx->key.arc4;
- u8 *x = s + 256;
- u8 *y = x + 1;
- int i, j, k;
-
- ctx->enc_type = n2alg->enc_type;
-
- j = k = 0;
- *x = 0;
- *y = 0;
- for (i = 0; i < 256; i++)
- s[i] = i;
- for (i = 0; i < 256; i++) {
- u8 a = s[i];
- j = (j + key[k] + a) & 0xff;
- s[i] = s[j];
- s[j] = a;
- if (++k >= keylen)
- k = 0;
- }
-
- return 0;
-}
-
static inline int skcipher_descriptor_len(int nbytes, unsigned int block_size)
{
int this_len = nbytes;
@@ -1122,21 +1091,6 @@ struct n2_skcipher_tmpl {
};
static const struct n2_skcipher_tmpl skcipher_tmpls[] = {
- /* ARC4: only ECB is supported (chaining bits ignored) */
- { .name = "ecb(arc4)",
- .drv_name = "ecb-arc4",
- .block_size = 1,
- .enc_type = (ENC_TYPE_ALG_RC4_STREAM |
- ENC_TYPE_CHAINING_ECB),
- .skcipher = {
- .min_keysize= 1,
- .max_keysize= 256,
- .setkey = n2_arc4_setkey,
- .encrypt= n2_encrypt_ecb,
- .decrypt= n2_decrypt_ecb,
- },
- },
-
/* DES: ECB CBC and CFB are supported */
{ .name = "ecb(des)",
.drv_name = "ecb-des",
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/7] staging/rtl8192e: switch to RC4 library interface
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 70 ---
drivers/staging/rtl8192e/rtllib_crypt_wep.c | 72
3 files changed, 28 insertions(+), 118 deletions(-)
diff --git a/drivers/staging/rtl8192e/Kconfig b/drivers/staging/rtl8192e/Kconfig
index 1007eea6c8fc..4c440bdaaf6e 100644
--- a/drivers/staging/rtl8192e/Kconfig
+++ b/drivers/staging/rtl8192e/Kconfig
@@ -25,7 +25,7 @@ config RTLLIB_CRYPTO_CCMP
config RTLLIB_CRYPTO_TKIP
tristate "Support for rtllib TKIP crypto"
depends on RTLLIB
- select CRYPTO_ARC4
+ select CRYPTO_LIB_ARC4
select CRYPTO_MICHAEL_MIC
default y
help
@@ -35,7 +35,7 @@ config RTLLIB_CRYPTO_TKIP
config RTLLIB_CRYPTO_WEP
tristate "Support for rtllib WEP crypto"
- select CRYPTO_ARC4
+ select CRYPTO_LIB_ARC4
depends on RTLLIB
default y
help
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
index 8d2a58e706d5..8c2ff37b2d3a 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
@@ -5,8 +5,9 @@
* Copyright (c) 2003-2004, Jouni Malinen
*/
+#include
#include
-#include
+#include
#include
#include
#include
@@ -16,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
@@ -45,9 +45,9 @@ struct rtllib_tkip_data {
u32 dot11RSNAStatsTKIPLocalMICFailures;
int key_idx;
- struct crypto_sync_skcipher *rx_tfm_arc4;
+ struct arc4_ctx rx_ctx_arc4;
+ struct arc4_ctx tx_ctx_arc4;
struct crypto_shash *rx_tfm_michael;
- struct crypto_sync_skcipher *tx_tfm_arc4;
struct crypto_shash *tx_tfm_michael;
/* scratch buffers for virt_to_page() (crypto API) */
u8 rx_hdr[16];
@@ -58,16 +58,13 @@ static void *rtllib_tkip_init(int key_idx)
{
struct rtllib_tkip_data *priv;
+ if (fips_enabled)
+ return NULL;
+
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
if (priv == NULL)
goto fail;
priv->key_idx = key_idx;
- priv->tx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->tx_tfm_arc4)) {
- pr_debug("Could not allocate crypto API arc4\n");
- priv->tx_tfm_arc4 = NULL;
- goto fail;
- }
priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
@@ -76,13 +73,6 @@ static void *rtllib_tkip_init(int key_idx)
goto fail;
}
- priv->rx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->rx_tfm_arc4)) {
- pr_debug("Could not allocate crypto API arc4\n");
- priv->rx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
pr_debug("Could not allocate crypto API michael_mic\n");
@@ -94,9 +84,7 @@ static void *rtllib_tkip_init(int key_idx)
fail:
if (priv) {
crypto_free_shash(priv->tx_tfm_michael);
- crypto_free_sync_skcipher(priv->tx_tfm_arc4);
crypto_free_shash(priv->rx_tfm_michael);
- crypto_free_sync_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -110,11 +98,9 @@ static void rtllib_tkip_deinit(void *priv)
if (_priv) {
crypto_free_shash(_priv->tx_tfm_michael);
- crypto_free_sync_skcipher(_priv->tx_tfm_arc4);
crypto_free_shash(_priv->rx_tfm_michael);
- crypto_free_sync_skcipher(_priv->rx_tfm_arc4);
}
- kfree(priv);
+ kzfree(priv);
}
@@ -289,7 +275,6 @@ static int rtllib_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
int ret = 0;
u8 rc4key[16], *icv;
u32 crc;
- struct scatterlist sg;
if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 ||
skb->len < hdr_len)
@@ -331,8 +316,6 @@ static int rtllib_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
*pos++ = (tkey->tx_iv32 >> 24) & 0xff;
if (!tcb_desc->bHwSec) {
- SYNC_SKCIPHER_REQUEST_ON_STACK(req, tkey->tx_tfm_arc4);
-
icv = skb_put(skb, 4);
crc = ~crc32_le(~0, pos, len);
icv[0] = crc;
@@ -340,15 +323,8 @@ static int rtllib
[PATCH v3 5/7] crypto: bcm-iproc - remove ecb(arc4) support
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6 insertions(+), 128 deletions(-)
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index 8a7fa1ae1ade..5d38b87b9d77 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -165,10 +165,6 @@ spu_skcipher_rx_sg_create(struct brcm_message *mssg,
return -EFAULT;
}
- if (ctx->cipher.alg == CIPHER_ALG_RC4)
- /* Add buffer to catch 260-byte SUPDT field for RC4 */
- sg_set_buf(sg++, rctx->msg_buf.c.supdt_tweak, SPU_SUPDT_LEN);
-
if (stat_pad_len)
sg_set_buf(sg++, rctx->msg_buf.rx_stat_pad, stat_pad_len);
@@ -317,7 +313,6 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
u8 local_iv_ctr[MAX_IV_SIZE];
u32 stat_pad_len; /* num bytes to align status field */
u32 pad_len;/* total length of all padding */
- bool update_key = false;
struct brcm_message *mssg; /* mailbox message */
/* number of entries in src and dst sg in mailbox message. */
@@ -391,28 +386,6 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
}
}
- if (ctx->cipher.alg == CIPHER_ALG_RC4) {
- rx_frag_num++;
- if (chunk_start) {
- /*
-* for non-first RC4 chunks, use SUPDT from previous
-* response as key for this chunk.
-*/
- cipher_parms.key_buf = rctx->msg_buf.c.supdt_tweak;
- update_key = true;
- cipher_parms.type = CIPHER_TYPE_UPDT;
- } else if (!rctx->is_encrypt) {
- /*
-* First RC4 chunk. For decrypt, key in pre-built msg
-* header may have been changed if encrypt required
-* multiple chunks. So revert the key to the
-* ctx->enckey value.
-*/
- update_key = true;
- cipher_parms.type = CIPHER_TYPE_INIT;
- }
- }
-
if (ctx->max_payload == SPU_MAX_PAYLOAD_INF)
flow_log("max_payload infinite\n");
else
@@ -425,14 +398,9 @@ static int handle_skcipher_req(struct iproc_reqctx_s *rctx)
memcpy(rctx->msg_buf.bcm_spu_req_hdr, ctx->bcm_spu_req_hdr,
sizeof(rctx->msg_buf.bcm_spu_req_hdr));
- /*
-* Pass SUPDT field as key. Key field in finish() call is only used
-* when update_key has been set above for RC4. Will be ignored in
-* all other cases.
-*/
spu->spu_cipher_req_finish(rctx->msg_buf.bcm_spu_req_hdr + BCM_HDR_LEN,
ctx->spu_req_hdr_len, !(rctx->is_encrypt),
- &cipher_parms, update_key, chunksize);
+ &cipher_parms, chunksize);
atomic64_add(chunksize, &iproc_priv.bytes_out);
@@ -527,9 +495,6 @@ static void handle_skcipher_resp(struct iproc_reqctx_s
*rctx)
__func__, rctx->total_received, payload_len);
dump_sg(req->dst, rctx->total_received, payload_len);
- if (ctx->cipher.alg == CIPHER_ALG_RC4)
- packet_dump(" supdt ", rctx->msg_buf.c.supdt_tweak,
- SPU_SUPDT_LEN);
rctx->total_received += payload_len;
if (rctx->total_received == rctx->total_todo) {
@@ -1853,26 +1818,6 @@ static int aes_setkey(struct crypto_skcipher *cipher,
const u8 *key,
return 0;
}
-static int rc4_setkey(struct crypto_skcipher *cipher, const u8 *key,
- unsigned int keylen)
-{
- struct iproc_ctx_s *ctx = crypto_skcipher_ctx(cipher);
- int i;
-
- ctx->enckeylen = ARC4_MAX_KEY_SIZE + ARC4_STATE_SIZE;
-
- ctx->enckey[0] = 0x00; /* 0x00 */
- ctx->enckey[1] = 0x00; /* i*/
- ctx->enckey[2] = 0x00; /* 0x00 */
- ctx->enckey[3] = 0x00; /* j*/
- for (i = 0; i < ARC4_MAX_KEY_SIZE; i++)
- ctx->enckey[i + ARC4_STATE_SIZE] = key[i % keylen];
-
- ctx->cipher_type = CIPHER_TYPE_INIT;
-
- return 0;
-}
-
static int skcipher_setkey(struct crypto_skcipher *cipher, const u8 *key,
unsigned int keylen)
{
@@ -1895,9 +1840,6 @@ static int skcipher_setkey(struct crypto_skcipher
*cipher, const u8 *key,
case CIPHER_ALG_AES:
err = aes_setkey(cipher, key, keylen);
brea
[PATCH v3 3/7] SUNRPC: remove RC4-HMAC-MD5 support from KerberosV
The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
was specifically issued for interoperability with Windows 2000, but was
never intended to receive the same level of support. The RFC says
The IETF Kerberos community supports publishing this specification as
an informational document in order to describe this widely
implemented technology. However, while these encryption types
provide the operations necessary to implement the base Kerberos
specification [RFC4120], they do not provide all the required
operations in the Kerberos cryptography framework [RFC3961]. As a
result, it is not generally possible to implement potential
extensions to Kerberos using these encryption types. The Kerberos
encryption type negotiation mechanism [RFC4537] provides one approach
for using such extensions even when a Kerberos infrastructure uses
long-term RC4 keys. Because this specification does not implement
operations required by RFC 3961 and because of security concerns with
the use of RC4 and MD4 discussed in Section 8, this specification is
not appropriate for publication on the standards track.
The RC4-HMAC encryption types are used to ease upgrade of existing
Windows NT environments, provide strong cryptography (128-bit key
lengths), and provide exportable (meet United States government
export restriction requirements) encryption. This document describes
the implementation of those encryption types.
Furthermore, this RFC was re-classified as 'historic' by RFC 8429 [1] in
2018, stating that 'none of the encryption types it specifies should be
used'
Note that other outdated algorithms are left in place (some of which are
guarded by CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES), so this should only
adversely affect interoperability with Windows NT/2000 systems that have
not received any updates since 2008 (but are connected to a network
nonetheless)
[0] https://tools.ietf.org/html/rfc4757
[1] https://tools.ietf.org/html/rfc8429
Signed-off-by: Ard Biesheuvel
Acked-by: J. Bruce Fields
---
include/linux/sunrpc/gss_krb5.h | 11 -
include/linux/sunrpc/gss_krb5_enctypes.h | 9 +-
net/sunrpc/Kconfig | 1 -
net/sunrpc/auth_gss/gss_krb5_crypto.c| 276
net/sunrpc/auth_gss/gss_krb5_mech.c | 95 ---
net/sunrpc/auth_gss/gss_krb5_seal.c | 1 -
net/sunrpc/auth_gss/gss_krb5_seqnum.c| 87 --
net/sunrpc/auth_gss/gss_krb5_unseal.c| 1 -
net/sunrpc/auth_gss/gss_krb5_wrap.c | 65 +
9 files changed, 16 insertions(+), 530 deletions(-)
diff --git a/include/linux/sunrpc/gss_krb5.h b/include/linux/sunrpc/gss_krb5.h
index e8f8ffe7448b..91f43d86879d 100644
--- a/include/linux/sunrpc/gss_krb5.h
+++ b/include/linux/sunrpc/gss_krb5.h
@@ -141,14 +141,12 @@ enum sgn_alg {
SGN_ALG_MD2_5 = 0x0001,
SGN_ALG_DES_MAC = 0x0002,
SGN_ALG_3 = 0x0003, /* not published */
- SGN_ALG_HMAC_MD5 = 0x0011, /* microsoft w2k; no support */
SGN_ALG_HMAC_SHA1_DES3_KD = 0x0004
};
enum seal_alg {
SEAL_ALG_NONE = 0x,
SEAL_ALG_DES = 0x,
SEAL_ALG_1 = 0x0001,/* not published */
- SEAL_ALG_MICROSOFT_RC4 = 0x0010,/* microsoft w2k; no support */
SEAL_ALG_DES3KD = 0x0002
};
@@ -316,14 +314,5 @@ gss_krb5_aes_decrypt(struct krb5_ctx *kctx, u32 offset,
u32 len,
struct xdr_buf *buf, u32 *plainoffset,
u32 *plainlen);
-int
-krb5_rc4_setup_seq_key(struct krb5_ctx *kctx,
- struct crypto_sync_skcipher *cipher,
- unsigned char *cksum);
-
-int
-krb5_rc4_setup_enc_key(struct krb5_ctx *kctx,
- struct crypto_sync_skcipher *cipher,
- s32 seqnum);
void
gss_krb5_make_confounder(char *p, u32 conflen);
diff --git a/include/linux/sunrpc/gss_krb5_enctypes.h
b/include/linux/sunrpc/gss_krb5_enctypes.h
index 981c89cef19d..87eea679d750 100644
--- a/include/linux/sunrpc/gss_krb5_enctypes.h
+++ b/include/linux/sunrpc/gss_krb5_enctypes.h
@@ -13,15 +13,13 @@
#ifdef CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES
/*
- * NB: This list includes encryption types that were deprecated
- * by RFC 8429 (DES3_CBC_SHA1 and ARCFOUR_HMAC).
+ * NB: This list includes DES3_CBC_SHA1, which was deprecated by RFC 8429.
*
* ENCTYPE_AES256_CTS_HMAC_SHA1_96
* ENCTYPE_AES128_CTS_HMAC_SHA1_96
* ENCTYPE_DES3_CBC_SHA1
- * ENCTYPE_ARCFOUR_HMAC
*/
-#define KRB5_SUPPORTED_ENCTYPES "18,17,16,23"
+#define KRB5_SUPPORTED_ENCTYPES "18,17,16"
#else /* CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES */
@@ -32,12 +30,11 @@
* ENCTYPE_AES256_CTS_HMAC_SHA1_96
* ENCTYPE_AES128_CTS_HMAC_SHA1_96
* ENCTYPE_DES3_CBC_SHA1
- * ENCTYPE_ARCFOUR_HMAC
* ENCTYPE_DES_CBC_MD5
* ENCTYPE_DES_CBC_CRC
* ENCTYPE_DES_CBC_MD4
*/
-#define KRB5_SUPPORTED_ENCTYPES "18,17,16,23,3,1,2"
+#define
[PATCH v3 2/7] staging/rtl8192u: switch to RC4 library interface
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192u/Kconfig | 1 +
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 81
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 64 +++-
3 files changed, 27 insertions(+), 119 deletions(-)
diff --git a/drivers/staging/rtl8192u/Kconfig b/drivers/staging/rtl8192u/Kconfig
index 1edca5c304fb..ef883d462d3d 100644
--- a/drivers/staging/rtl8192u/Kconfig
+++ b/drivers/staging/rtl8192u/Kconfig
@@ -8,3 +8,4 @@ config RTL8192U
select CRYPTO
select CRYPTO_AES
select CRYPTO_CCM
+ select CRYPTO_LIB_ARC4
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index ffe624ed0c0c..4b415cc76715 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -5,6 +5,7 @@
* Copyright (c) 2003-2004, Jouni Malinen
*/
+#include
#include
#include
#include
@@ -17,9 +18,8 @@
#include "ieee80211.h"
+#include
#include
-#include
- #include
#include
MODULE_AUTHOR("Jouni Malinen");
@@ -49,9 +49,9 @@ struct ieee80211_tkip_data {
int key_idx;
- struct crypto_sync_skcipher *rx_tfm_arc4;
+ struct arc4_ctx rx_ctx_arc4;
+ struct arc4_ctx tx_ctx_arc4;
struct crypto_shash *rx_tfm_michael;
- struct crypto_sync_skcipher *tx_tfm_arc4;
struct crypto_shash *tx_tfm_michael;
/* scratch buffers for virt_to_page() (crypto API) */
@@ -62,19 +62,14 @@ static void *ieee80211_tkip_init(int key_idx)
{
struct ieee80211_tkip_data *priv;
+ if (fips_enabled)
+ return NULL;
+
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
goto fail;
priv->key_idx = key_idx;
- priv->tx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->tx_tfm_arc4)) {
- printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
- "crypto API arc4\n");
- priv->tx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
@@ -83,14 +78,6 @@ static void *ieee80211_tkip_init(int key_idx)
goto fail;
}
- priv->rx_tfm_arc4 = crypto_alloc_sync_skcipher("ecb(arc4)", 0, 0);
- if (IS_ERR(priv->rx_tfm_arc4)) {
- printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
- "crypto API arc4\n");
- priv->rx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
@@ -104,9 +91,7 @@ static void *ieee80211_tkip_init(int key_idx)
fail:
if (priv) {
crypto_free_shash(priv->tx_tfm_michael);
- crypto_free_sync_skcipher(priv->tx_tfm_arc4);
crypto_free_shash(priv->rx_tfm_michael);
- crypto_free_sync_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -120,11 +105,9 @@ static void ieee80211_tkip_deinit(void *priv)
if (_priv) {
crypto_free_shash(_priv->tx_tfm_michael);
- crypto_free_sync_skcipher(_priv->tx_tfm_arc4);
crypto_free_shash(_priv->rx_tfm_michael);
- crypto_free_sync_skcipher(_priv->rx_tfm_arc4);
}
- kfree(priv);
+ kzfree(priv);
}
@@ -290,10 +273,8 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
u8 *pos;
struct rtl_80211_hdr_4addr *hdr;
struct cb_desc *tcb_desc = (struct cb_desc *)(skb->cb +
MAX_DEV_ADDR_SIZE);
- int ret = 0;
u8 rc4key[16], *icv;
u32 crc;
- struct scatterlist sg;
if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 ||
skb->len < hdr_len)
@@ -334,21 +315,15 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb,
int hdr_len, void *priv)
*pos++ = (tkey->tx_iv32 >> 24) & 0xff;
if (!tcb_desc->bHwSec) {
- SYNC_SKCIPHER_REQUEST_ON_STACK(req, tkey->tx_tfm_arc4);
-
icv = skb_put(skb, 4);
crc =
[PATCH v3 7/7] crypto: arc4 - mark ecb(arc4) skcipher as obsolete
Cryptographic algorithms may have a lifespan that is significantly
shorter than Linux's, and so we need to start phasing out algorithms
that are known to be broken, and are no longer fit for general use.
RC4 (or arc4) is a good example here: there are a few areas where its
use is still somewhat acceptable, e.g., for interoperability with legacy
wifi hardware that can only use WEP or TKIP data encryption, but that
should not imply that, for instance, use of RC4 based EAP-TLS by the WPA
supplicant for negotiating TKIP keys is equally acceptable, or that RC4
should remain available as a general purpose cryptographic transform for
all in-kernel and user space clients.
Now that all in-kernel users that need to retain support have moved to
the arc4 library interface, and the known users of ecb(arc4) via the
socket API (iwd [0] and libell [1][2]) have been updated to switch to a
local implementation, we can take the next step, and mark the ecb(arc4)
skcipher as obsolete, and only provide it if the socket API is enabled in
the first place, as well as provide the option to disable all algorithms
that have been marked as obsolete.
[0]
https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=1db8a85a60c64523
[1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2
[2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 10 ++
crypto/arc4.c | 10 ++
2 files changed, 20 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 1b57419fa2e7..e85d8a059489 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1199,6 +1199,7 @@ config CRYPTO_ANUBIS
config CRYPTO_ARC4
tristate "ARC4 cipher algorithm"
+ depends on CRYPTO_USER_API_ENABLE_OBSOLETE
select CRYPTO_SKCIPHER
select CRYPTO_LIB_ARC4
help
@@ -1881,6 +1882,15 @@ config CRYPTO_USER_API_AEAD
This option enables the user-spaces interface for AEAD
cipher algorithms.
+config CRYPTO_USER_API_ENABLE_OBSOLETE
+ bool "Enable obsolete cryptographic algorithms for userspace"
+ depends on CRYPTO_USER_API
+ default y
+ help
+ Allow obsolete cryptographic algorithms to be selected that have
+ already been phased out from internal use by the kernel, and are
+ only useful for userspace clients that still rely on them.
+
config CRYPTO_STATS
bool "Crypto usage statistics for User-space"
depends on CRYPTO_USER
diff --git a/crypto/arc4.c b/crypto/arc4.c
index aa79571dbd49..923aa7a6cd60 100644
--- a/crypto/arc4.c
+++ b/crypto/arc4.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
static int crypto_arc4_setkey(struct crypto_skcipher *tfm, const u8 *in_key,
unsigned int key_len)
@@ -39,6 +40,14 @@ static int crypto_arc4_crypt(struct skcipher_request *req)
return err;
}
+static int crypto_arc4_init(struct crypto_skcipher *tfm)
+{
+ pr_warn_ratelimited("\"%s\" (%ld) uses obsolete ecb(arc4) skcipher\n",
+ current->comm, (unsigned long)current->pid);
+
+ return 0;
+}
+
static struct skcipher_alg arc4_alg = {
/*
* For legacy reasons, this is named "ecb(arc4)", not "arc4".
@@ -55,6 +64,7 @@ static struct skcipher_alg arc4_alg = {
.setkey = crypto_arc4_setkey,
.encrypt= crypto_arc4_crypt,
.decrypt= crypto_arc4_crypt,
+ .init = crypto_arc4_init,
};
static int __init arc4_init(void)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
