* [PATCH] lib/crypto: gf128hash: mark clmul32() as noinline_for_stack
From: Arnd Bergmann @ 2026-06-11 12:59 UTC (permalink / raw)
To: Eric Biggers, Jason A. Donenfeld, Ard Biesheuvel,
Nathan Chancellor
Cc: Arnd Bergmann, Nick Desaulniers, Bill Wendling, Justin Stitt,
linux-crypto, linux-kernel, llvm
From: Arnd Bergmann <arnd@arndb.de>
During randconfig testing, I came across a lot of warnings for the newly
added carryless multiplication function triggering excessive stack usage
from spilling temporary variables to the stack:
lib/crypto/gf128hash.c:166:1: error: stack frame size (1192) exceeds limit (1024) in 'polyval_mul_generic' [-Werror,-Wframe-larger-than]
In addition to the possible risk of overflowing the kernel stack,
the generated object code surely performs very poorly.
This only happens on architectures that don't provide uint128_t
(which should be all 32-bit architectures on modern compilers), but
though I tested random x86 and arm configs, I only saw this with arm's
CONFIG_THUMB2_KERNEL, which adds more pressure to the register allocator.
The testing was done using clang-22, I don't know if gcc has the same
problem. Marking clmul32() as noinline_for_stack experimentally shows
all of the affected builds to completely solve the problem, reducing
the stack usage to a few bytes as expected.
Since u64 arithmetic frequently leads to compilers badly optimizing
32-bit targets, keeping clmul32 out of line is likely to help on
other 32-bit configurations as well when they run into this problem,
though it may also result in a small performance degradation in
configurations that would benefit from inlining.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
---
lib/crypto/gf128hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/crypto/gf128hash.c b/lib/crypto/gf128hash.c
index 2650603d8ba8..8dcdf5ec98be 100644
--- a/lib/crypto/gf128hash.c
+++ b/lib/crypto/gf128hash.c
@@ -109,7 +109,7 @@ static void clmul64(u64 a, u64 b, u64 *out_lo, u64 *out_hi)
#else /* CONFIG_ARCH_SUPPORTS_INT128 */
/* Do a 32 x 32 => 64 bit carryless multiplication. */
-static u64 clmul32(u32 a, u32 b)
+static noinline_for_stack u64 clmul32(u32 a, u32 b)
{
/*
* With 32-bit multiplicands and one term every 4 bits, there are up to
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 1/3] xfrm: extend ESP offload infrastructure for packet engines
From: Jihong Min @ 2026-06-11 12:23 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christian Marangi, Antoine Tenart, Herbert Xu, David S . Miller,
Lorenzo Bianconi, Andrew Lunn, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Steffen Klassert, linux-kernel,
linux-crypto, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260611115646.GN327369@unreal>
On 6/11/26 20:56, Leon Romanovsky wrote:
> On Sat, May 23, 2026 at 09:15:20PM +0900, Jihong Min wrote:
>> Some ESP offload engines operate on whole ESP packets rather than the
>> generic software trailer layout. They can generate outbound ESP padding,
>> next-header and ICV bytes in hardware, and inbound decapsulation can
>> return an already-trimmed packet with the recovered next-header value.
>
> How does this differ from the existing IPsec packet‑offload support in the
> Linux kernel?
>
> Thanks
Hi Leon,
The short answer is that the series did not explain the relationship
with the existing XFRM packet-offload model clearly enough.
Existing XFRM_DEV_OFFLOAD_PACKET already represents the high-level model
where hardware handles ESP packet processing instead of only crypto
transforms. What I was trying to handle in this series was a narrower
case: EIP93 is a look-aside crypto/IPsec engine, not the netdev itself,
so the Airoha netdev had to attach that engine into its TX/RX path and
let it generate or consume the ESP packet framing. The extra hooks in
this series were meant for that look-aside integration, but looking
back, the split between the existing packet-offload model and the new
plumbing was not clean enough.
At this point, though, I think the right thing is to withdraw this
EIP93/Airoha series.
The reason is related to the SOE work I mentioned in the other patch
thread. Many Airoha SoCs also have a higher-performance IP block called
SOE (Secure Offload Engine). I recently wrote and tested a driver for
that block, and I am currently carrying it here: [kernel: add bonding
LAG XFRM offload infrastructure and Airoha
support](https://github.com/hurryman2212/OpenW1700k-test/commit/fbfe8f919f836bb62b3849f803865a4d9b8dc76f).
With the EIP93 path I could get around 1 Gbps, while the SOE path can
reach about 5 Gbps in my current setup. Because of that, integrating
this EIP93 ESP packet path directly into `airoha_eth` is no longer the
most useful direction for Airoha Ethernet.
That said, SOE exists only on some Airoha SoCs. EIP93 can still be
useful on other platforms as a look-aside ESP packet offloader, but I
think that needs a cleaner infrastructure than this series had. The
look-aside offloader should be able to live as a separate module, not be
tied directly to one specific netdev driver, while still allowing
compatible netdevs to attach it into the XFRM path. I think that needs a
more general infrastructure extension, so I would rather revisit the
EIP93 work later on top of that kind of model.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH 2/3] crypto: inside-secure: add EIP93 ESP packet backend
From: Jihong Min @ 2026-06-11 12:17 UTC (permalink / raw)
To: Simon Horman
Cc: Christian Marangi, Antoine Tenart, Herbert Xu, David S . Miller,
Lorenzo Bianconi, Andrew Lunn, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Steffen Klassert, linux-kernel, linux-crypto,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260527100824.GJ2256768@horms.kernel.org>
On 5/27/26 19:08, Simon Horman wrote:
> On Sat, May 23, 2026 at 09:15:21PM +0900, Jihong Min wrote:
>> Expose an EIP93 packet-mode IPsec backend for netdev drivers that need
>> ESP encapsulation and decapsulation offload without advertising EIP93
>> itself as a netdev.
>>
>> Add provider selection, capability reporting, SA lifecycle management,
>> IPsec request completion, and provider fault notification around the
>> existing EIP93 descriptor path.
>>
>> Assisted-by: Codex:gpt-5.5
>> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
>
> ...
>
>> diff --git a/drivers/crypto/inside-secure/eip93/eip93-ipsec.c b/drivers/crypto/inside-secure/eip93/eip93-ipsec.c
>
> ...
>
>> +static void eip93_ipsec_abort_requests(struct eip93_ipsec *ipsec, int err)
>> +{
>> + struct eip93_ipsec_sa *sa;
>> +
>> + while (true) {
>> + bool found = false;
>> +
>> + spin_lock_bh(&ipsec->lock);
>> + list_for_each_entry(sa, &ipsec->sa_list, node) {
>> + spin_lock(&sa->lock);
>> + if (sa->aborting) {
>> + spin_unlock(&sa->lock);
>> + continue;
>> + }
>> +
>> + sa->aborting = true;
>> + found = refcount_inc_not_zero(&sa->refcnt);
>> + spin_unlock(&sa->lock);
>> + if (found)
>> + break;
>> + }
>> + spin_unlock_bh(&ipsec->lock);
>> + if (!found)
>> + return;
>> +
>> + eip93_ipsec_abort_sa(sa, err);
>> + eip93_ipsec_sa_put(sa);
>
> sa is the iterator for the list_for_each_entry loop.
> However, here it is used outside of that context.
>
> "If list_for_each_entry, etc complete a traversal of the list, the
> iterator variable ends up pointing to an address at an offset from
> the list head, and not a meaningful structure. Thus this value
> should not be used after the end of the iterator.
>
> https://www.spinics.net/lists/linux-kernel-janitors/msg11994.html
>
> Flagged by Coccinelle.
>
Hi Simon,
Thanks for the feedback, and sorry for noticing this mail so late.
Your point is correct. The `list_for_each_entry()` iterator should not
be used outside the loop like that. If I continued with this series, I
would fix it by keeping a separate selected SA pointer before dropping
the lock.
At this point, though, I think the right thing is to withdraw this
EIP93/Airoha series.
The reason is that many Airoha SoCs also have a higher-performance IP
block called SOE (Secure Offload Engine). I recently wrote and tested a
driver for that block, and I am currently carrying it here: [kernel: add
bonding LAG XFRM offload infrastructure and Airoha
support](https://github.com/hurryman2212/OpenW1700k-test/commit/fbfe8f919f836bb62b3849f803865a4d9b8dc76f).
With the EIP93 path I could get around 1 Gbps, while the SOE path can
reach about 5 Gbps in my current setup. Because of that, integrating
this EIP93 ESP packet path directly into `airoha_eth` is no longer the
most useful direction for Airoha Ethernet.
That said, SOE exists only on some Airoha SoCs. EIP93 can still be
useful on other platforms as a look-aside ESP packet offloader, but I
think that needs a cleaner infrastructure than this series had. The
look-aside offloader should be able to live as a separate module, not be
tied directly to one specific netdev driver, while still allowing
compatible netdevs to attach it into the XFRM path. I think that needs a
more general infrastructure extension, so I would rather revisit the
EIP93 work later on top of that kind of model.
Sincerely,
Jihong Min
>> + }
>> +}
>
> ...
^ permalink raw reply
* Re: [PATCH 1/3] xfrm: extend ESP offload infrastructure for packet engines
From: Leon Romanovsky @ 2026-06-11 11:56 UTC (permalink / raw)
To: Jihong Min
Cc: Christian Marangi, Antoine Tenart, Herbert Xu, David S . Miller,
Lorenzo Bianconi, Andrew Lunn, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Steffen Klassert, linux-kernel,
linux-crypto, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260523121522.3023992-2-hurryman2212@gmail.com>
On Sat, May 23, 2026 at 09:15:20PM +0900, Jihong Min wrote:
> Some ESP offload engines operate on whole ESP packets rather than the
> generic software trailer layout. They can generate outbound ESP padding,
> next-header and ICV bytes in hardware, and inbound decapsulation can
> return an already-trimmed packet with the recovered next-header value.
How does this differ from the existing IPsec packet‑offload support in the
Linux kernel?
Thanks
^ permalink raw reply
* Re: [PATCH] crypto: atmel-ecc - remove stale comments in atmel_ecc_remove
From: Thorsten Blum @ 2026-06-11 10:55 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <aipH0NgL4Gbe7Oz1@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 01:29:52PM +0800, Herbert Xu wrote:
> On Tue, Jun 02, 2026 at 06:52:49PM +0200, Thorsten Blum wrote:
> > atmel_ecc_remove() no longer returns -EBUSY since commit 7df7563b16aa
> > ("crypto: atmel-ecc - Remove duplicated error reporting in .remove()")
> > and is a void function since commit ed5c2f5fd10d ("i2c: Make remove
> > callback return void").
> >
> > Remove and update the outdated comments.
> >
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > ---
> > drivers/crypto/atmel-ecc.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
> > index 9c380351d2f9..e6068dc0a0c1 100644
> > --- a/drivers/crypto/atmel-ecc.c
> > +++ b/drivers/crypto/atmel-ecc.c
> > @@ -347,13 +347,11 @@ static void atmel_ecc_remove(struct i2c_client *client)
> > {
> > struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
> >
> > - /* Return EBUSY if i2c client already allocated. */
> > if (atomic_read(&i2c_priv->tfm_count)) {
> > /*
> > * After we return here, the memory backing the device is freed.
> > - * That happens no matter what the return value of this function
> > - * is because in the Linux device model there is no error
> > - * handling for unbinding a driver.
> > + * That happens because in the Linux device model there is no
> > + * error handling for unbinding a driver.
> > * If there is still some action pending, it probably involves
> > * accessing the freed memory.
> > */
>
> Please fix this properly rather than fiddling with the comments.
>
> Drivers should always fail gracefully if the hardware disappears.
Yes, I'm working on a fix, but it's not ready yet.
Thanks,
Thorsten
^ permalink raw reply
* [PATCH] crypto: atmel-ecc - drop unused curve id from atmel_ecdh_ctx
From: Thorsten Blum @ 2026-06-11 10:52 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
->curve_id is only set once, but never used - remove it.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 9da9dd6585df..93f219558c2f 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -33,7 +33,6 @@ static struct atmel_ecc_driver_data driver_data;
* @public_key : generated when calling set_secret(). It's the responsibility
* of the user to not call set_secret() while
* generate_public_key() or compute_shared_secret() are in flight.
- * @curve_id : elliptic curve id
* @do_fallback: true when the device doesn't support the curve or when the user
* wants to use its own private key.
*/
@@ -41,7 +40,6 @@ struct atmel_ecdh_ctx {
struct i2c_client *client;
struct crypto_kpp *fallback;
const u8 *public_key;
- unsigned int curve_id;
bool do_fallback;
};
@@ -250,7 +248,6 @@ static int atmel_ecdh_init_tfm(struct crypto_kpp *tfm)
struct crypto_kpp *fallback;
struct atmel_ecdh_ctx *ctx = kpp_tfm_ctx(tfm);
- ctx->curve_id = ECC_CURVE_NIST_P256;
ctx->client = atmel_ecc_i2c_client_alloc();
if (IS_ERR(ctx->client)) {
pr_err("tfm - i2c_client binding failed\n");
^ permalink raw reply related
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Michael S. Tsirkin @ 2026-06-11 10:42 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <aip9nja-Oz2RxkWi@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 05:19:26PM +0800, Herbert Xu wrote:
> On Thu, Jun 11, 2026 at 05:10:32AM -0400, Michael S. Tsirkin wrote:
> >
> > data_avail is under hypervisor control
> >
> > avail = min_t(unsigned int, vi->data_avail, sizeof(vi->data));
> > if (vi->data_idx >= avail) {
> > vi->data_idx = 0;
> >
> > and maybe this can speculate past the if?
> >
> > I agree, this is all speculation )
>
> Either it is vulnerable to Spectre, or it isn't. Adding nospec
> markers when you're not sure is cargo cult programming.
AKA defence is depth programming)
Alright we can drop this. No biggie.
--
MST
^ permalink raw reply
* [PATCH v2] crypto: atmel-tdes - use scatterlist length before DMA mapping
From: Thorsten Blum @ 2026-06-11 10:36 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Nicolas Royer, Eric Bénard
Cc: Thorsten Blum, stable, linux-crypto, linux-arm-kernel,
linux-kernel
Using sg_dma_len() is only valid after mapping the scatterlist with
dma_map_sg(). However, atmel_tdes_crypt_start() uses it before mapping
to compare input/output lengths and to compute the transfer count.
Use the original scatterlist lengths before DMA mapping to avoid reading
stale or uninitialized DMA lengths when CONFIG_NEED_SG_DMA_LENGTH=y.
Drop the output scatterlist length in the fast path since it is equal to
->in_sg->length and does not change the transfer count.
Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver")
Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Drop ->out_sg->length in the fast path (Herbert)
- v1: https://lore.kernel.org/lkml/20260531204115.689052-3-thorsten.blum@linux.dev/
---
drivers/crypto/atmel-tdes.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c
index 643e507f9c02..d380f6741a2c 100644
--- a/drivers/crypto/atmel-tdes.c
+++ b/drivers/crypto/atmel-tdes.c
@@ -463,14 +463,13 @@ static int atmel_tdes_crypt_start(struct atmel_tdes_dev *dd)
IS_ALIGNED(dd->out_sg->length, dd->ctx->block_size);
fast = in && out;
- if (sg_dma_len(dd->in_sg) != sg_dma_len(dd->out_sg))
+ if (dd->in_sg->length != dd->out_sg->length)
fast = 0;
}
if (fast) {
- count = min_t(size_t, dd->total, sg_dma_len(dd->in_sg));
- count = min_t(size_t, count, sg_dma_len(dd->out_sg));
+ count = min_t(size_t, dd->total, dd->in_sg->length);
err = dma_map_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
if (!err) {
^ permalink raw reply related
* Re: [PATCH 2/2] crypto: qce: Fix CTR-AES for partial block requests
From: Kuldeep Singh @ 2026-06-11 9:49 UTC (permalink / raw)
To: Eric Biggers
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Bartosz Golaszewski,
Thara Gopinath, linux-crypto, linux-arm-msm, linux-kernel
In-Reply-To: <20260610184610.GC1158828@google.com>
> This fix isn't Cc'ed to stable, so stable kernels will remain vulnerable
> to this bug.
Sure, I'll Cc stable tag in v2 with any other feedback/comments on these
patches.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH 0/2] Fix Qualcomm Crypto engine self tests failures
From: Kuldeep Singh @ 2026-06-11 9:47 UTC (permalink / raw)
To: Eric Biggers, Bartosz Golaszewski
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Bartosz Golaszewski,
Thara Gopinath, linux-crypto, linux-arm-msm, linux-kernel
In-Reply-To: <20260610184205.GB1158828@google.com>
On 11-06-2026 00:12, Eric Biggers wrote:
> On Wed, Jun 10, 2026 at 11:24:03AM +0530, Kuldeep Singh wrote:
>> Steps followed:
>> - Enable EXPERT and CRYPTO_SEFLTESTS config.
>
> So the full tests (CRYPTO_SELFTESTS_FULL) still haven't been run?
Crypto_selftests was only run as there's some discussion ongoing with
Bartosz on removal of deprecated/unsafe algos.
Seems Bartosz will be sending patches for algorithm removal changes.
The rest relevant selftests issues we'll fix accordingly.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Herbert Xu @ 2026-06-11 9:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <20260611050731-mutt-send-email-mst@kernel.org>
On Thu, Jun 11, 2026 at 05:10:32AM -0400, Michael S. Tsirkin wrote:
>
> data_avail is under hypervisor control
>
> avail = min_t(unsigned int, vi->data_avail, sizeof(vi->data));
> if (vi->data_idx >= avail) {
> vi->data_idx = 0;
>
> and maybe this can speculate past the if?
>
> I agree, this is all speculation )
Either it is vulnerable to Spectre, or it isn't. Adding nospec
markers when you're not sure is cargo cult programming.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Michael S. Tsirkin @ 2026-06-11 9:10 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <aipvZhfvdtRxOQm0@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 04:18:46PM +0800, Herbert Xu wrote:
> On Thu, Jun 11, 2026 at 03:58:17AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 11, 2026 at 03:46:58PM +0800, Herbert Xu wrote:
> > > On Thu, Jun 11, 2026 at 03:30:14AM -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jun 11, 2026 at 12:43:09PM +0800, Herbert Xu wrote:
> > > > > On Sun, May 31, 2026 at 10:22:51AM -0400, Michael Bommarito wrote:
> > > > > >
> > > > > > + size = min_t(unsigned int, size, avail - vi->data_idx);
> > > > > > + idx = array_index_nospec(vi->data_idx, sizeof(vi->data));
> > > > > > + memcpy(buf, vi->data + idx, size);
> > > >
> > > > All the "malicious device" things are confusing. Spectre things -
> > > > doubly so.
> > > >
> > > > So if an access is speculated then CPU might speculate feeding a kernel
> > > > secret into RNG. And then the speculated RNG value maybe can be also
> > > > speculatively be used by some kernel code as an index
> > > > to trigger a cache access, finally leaking the secret?
> > > >
> > > > Maybe?
> > >
> > > The way Spectre works is if you have an actual instruction using
> > > idx directly. I don't see how that translates to memcpy.
> >
> > I am not sure it has to be direct:
> >
> > if (malicious_idx > SIZE)
> > return;
> > src += malicious_idx;
>
> Wait but vi->data_idx isn't even under the hypervisor's control.
>
> It's an index maintained by our own driver. So how can it be
> malicious?
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
data_avail is under hypervisor control
avail = min_t(unsigned int, vi->data_avail, sizeof(vi->data));
if (vi->data_idx >= avail) {
vi->data_idx = 0;
and maybe this can speculate past the if?
I agree, this is all speculation )
--
MST
^ permalink raw reply
* Re: [PATCH] crypto: tegra: fix refcount leak in tegra_se_host1x_submit()
From: Herbert Xu @ 2026-06-11 8:55 UTC (permalink / raw)
To: Wentao Liang
Cc: akhilrajeev, davem, thierry.reding, jonathanh, linux-crypto,
linux-tegra, linux-kernel, stable
In-Reply-To: <20260604102706.3787771-1-vulab@iscas.ac.cn>
On Thu, Jun 04, 2026 at 10:27:06AM +0000, Wentao Liang wrote:
> The timeout error path in tegra_se_host1x_submit() returns without
> calling host1x_job_put(), while all other paths (success, submit
> error, pin error) properly release the job reference through the
> job_put label. Since host1x_job_alloc() initializes the reference
> count and host1x_job_put() is required to drop it, omitting it on
> timeout causes a permanent refcount leak.
>
> Fix this by redirecting the timeout return to the existing job_put
> label, ensuring the job reference and any associated syncpt
> references are consistently released.
>
> Cc: stable@vger.kernel.org
> Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/crypto/tegra/tegra-se-main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: testmgr - allow authenc(hmac(sha{256,384}),cts(cbc(aes))) in FIPS mode
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Ilya Dryomov; +Cc: David Howells, linux-crypto, ceph-devel, linux-kernel
In-Reply-To: <20260603155008.736872-1-idryomov@gmail.com>
On Wed, Jun 03, 2026 at 05:50:04PM +0200, Ilya Dryomov wrote:
> hmac(sha256), hmac(sha384) and cts(cbc(aes)) algorithms have been
> marked as FIPS allowed for years. Mark the respective authenc()
> constructions per RFC 8009 ("AES Encryption with HMAC-SHA2 for
> Kerberos 5") as such as well.
>
> SP 800-57 Part 3 Rev. 1 from Jan 2015 [1] links the draft of what
> became RFC 8009 in Oct 2016 as approved in section 6.3 Procurement
> Guidance (item/recommendation 3).
>
> [1] https://csrc.nist.gov/pubs/sp/800/57/pt3/r1/final
>
> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
> ---
> crypto/testmgr.c | 2 ++
> 1 file changed, 2 insertions(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: jh7110: fix refcount leak in starfive_trng_read()
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Wentao Liang; +Cc: jiajie.ho, olivia, linux-crypto, linux-kernel, stable
In-Reply-To: <20260603110327.3750514-1-vulab@iscas.ac.cn>
On Wed, Jun 03, 2026 at 11:03:27AM +0000, Wentao Liang wrote:
> The starfive_trng_read() function acquires a runtime PM reference
> via pm_runtime_get_sync() but fails to release it on two error
> paths. If starfive_trng_wait_idle() or starfive_trng_cmd() returns
> an error, the function exits without calling
> pm_runtime_put_sync_autosuspend(), leaving the runtime PM usage
> counter permanently elevated and preventing the device from entering
> runtime suspend.
>
> Refactor the function to use a unified error path that calls
> pm_runtime_put_sync_autosuspend() before returning.
>
> Cc: stable@vger.kernel.org
> Fixes: c388f458bc34 ("hwrng: starfive - Add TRNG driver for StarFive SoC")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/char/hw_random/jh7110-trng.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: atmel-ecc - drop dead code in atmel_ecdh_max_size
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260602222517.1071850-3-thorsten.blum@linux.dev>
On Wed, Jun 03, 2026 at 12:25:19AM +0200, Thorsten Blum wrote:
> atmel_ecdh_init_tfm() always allocates ctx->fallback, so it is never
> NULL in atmel_ecdh_max_size(). Remove the dead code and return
> crypto_kpp_maxsize() directly.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-ecc.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: cavium/cpt - fix DMA cleanup using wrong loop index
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Felix Gu
Cc: George Cherian, David S. Miller, David Daney, George Cherian,
linux-crypto, linux-kernel
In-Reply-To: <20260602-cptvf-v1-1-d68e58e59173@gmail.com>
On Tue, Jun 02, 2026 at 10:55:35PM +0800, Felix Gu wrote:
> The sg_cleanup error path used list[i] instead of list[j] when unmapping
> DMA buffers, leaking successfully mapped entries and repeatedly unmapping
> the failed one.
>
> Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: marvell/octeontx - fix DMA cleanup using wrong loop index
From: Herbert Xu @ 2026-06-11 8:53 UTC (permalink / raw)
To: Felix Gu
Cc: Srujana Challa, Bharat Bhushan, David S. Miller, Lukasz Bartosik,
linux-crypto, linux-kernel
In-Reply-To: <20260602-otx-v1-1-e0c9ec50cb04@gmail.com>
On Tue, Jun 02, 2026 at 10:38:26PM +0800, Felix Gu wrote:
> The sg_cleanup path used list[i] instead of list[j] when unmapping DMA
> buffers, leaking successfully mapped entries and repeatedly unmapping
> the failed one.
>
> Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: make myself the maintainer of the Qualcomm QCE driver
From: Herbert Xu @ 2026-06-11 8:53 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Demi Marie Obenour, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King, Eric Biggers, Ard Biesheuvel, Kuldeep Singh,
linux-crypto, linux-arm-msm, linux-kernel, brgl
In-Reply-To: <20260602-qcom-qce-broken-v1-1-a4ef756089e0@oss.qualcomm.com>
On Tue, Jun 02, 2026 at 02:46:56PM +0200, Bartosz Golaszewski wrote:
> Qualcomm wants to keep supporting and extending the crypto engine driver.
> Thara has not been active for many months, so change the maintainer to
> myself and upgrade the driver to Supported.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> I've considered also marking the driver as BROKEN but decided not to.
> Next week I plan to address the failing self tests as well as go through
> all the ciphers it provides and remove ones that are known to be weak or
> deprecated.
>
> Regarding the series that proposed to remove this[1], let this be the
> official objection. Qualcomm's clients use this IP, we have support for
> new features planned and intend to refactor it significantly.
>
> [1] https://lore.kernel.org/all/20260523-delete-qce-v1-0-86105cd7f406@gmail.com/
> ---
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: amcc - convert irq_of_parse_and_map to platform_get_irq
From: Herbert Xu @ 2026-06-11 8:53 UTC (permalink / raw)
To: Rosen Penev; +Cc: linux-crypto, David S. Miller, open list
In-Reply-To: <20260602014645.522137-1-rosenp@gmail.com>
On Mon, Jun 01, 2026 at 06:46:45PM -0700, Rosen Penev wrote:
> Replace the deprecated irq_of_parse_and_map() call with the modern
> platform_get_irq() in the probe function. This also improves error
> handling: platform_get_irq() returns a negative errno on failure,
> whereas irq_of_parse_and_map() returned 0.
>
> Change the irq field in struct crypto4xx_core_device from u32 to int
> to match the return type of platform_get_irq().
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/crypto/amcc/crypto4xx_core.c | 6 +++++-
> drivers/crypto/amcc/crypto4xx_core.h | 2 +-
> 2 files changed, 6 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] crypto: sun4i-ss - Remove insecure and unused rng_alg
From: Herbert Xu @ 2026-06-11 8:50 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-sunxi, linux-arm-kernel, linux-kernel,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Corentin Labbe,
stable, Tianchu Chen
In-Reply-To: <20260601160757.79645-1-ebiggers@kernel.org>
On Mon, Jun 01, 2026 at 04:07:57PM +0000, Eric Biggers wrote:
> Remove sun4i_ss_rng, as it is insecure and unused:
>
> - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing
> locking and has a buffer overflow. sun4i_ss_prng_generate() fails to
> fill the entire buffer with cryptographic random bytes, because it
> rounds the destination length down and also doesn't actually wait for
> the hardware to be ready before pulling bytes from it.
>
> - No user of this code is known. It's usable only theoretically via the
> "rng" algorithm type of AF_ALG. But userspace actually just uses the
> actual Linux RNG (/dev/random etc) instead. And rng_algs don't
> contribute entropy to the actual Linux RNG either. (This may have
> been confused with hwrng, which does contribute entropy.)
>
> The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen
> and discovered by Atuin - Automated Vulnerability Discovery Engine
>
> There's no point in fixing all these vulnerabilities individually when
> this is unused code, so let's just remove it.
>
> Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security System PRNG")
> Cc: stable@vger.kernel.org
> Reported-by: Tianchu Chen <flynnnchen@tencent.com>
> Closes: https://lore.kernel.org/r/af749a8447bd7f0e9dd26ca6c87e9c6afecb09d9@linux.dev/
> Acked-by: Corentin LABBE <clabbe.montjoie@gmail.com>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>
> This patch is targeting crypto/master
>
> v2: rebased onto crypto/master, and added Acked-by and Reported-by
>
> arch/arm/configs/sunxi_defconfig | 1 -
> drivers/crypto/allwinner/Kconfig | 8 ---
> drivers/crypto/allwinner/sun4i-ss/Makefile | 1 -
> .../crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 36 ----------
> .../crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 69 -------------------
> drivers/crypto/allwinner/sun4i-ss/sun4i-ss.h | 20 ------
> 6 files changed, 135 deletions(-)
> delete mode 100644 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/4] Xilinx TRNG fix and simplification
From: Herbert Xu @ 2026-06-11 8:49 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, Mounika Botcha, Harsh Jain,
Olivia Mackall, Michal Simek, linux-arm-kernel
In-Reply-To: <20260531191738.55843-1-ebiggers@kernel.org>
On Sun, May 31, 2026 at 12:17:34PM -0700, Eric Biggers wrote:
> This series fixes and greatly simplifies the Xilinx TRNG driver by:
>
> - Removing the gratuitous crypto_rng interface, leaving just hwrng which
> is the one that actually matters.
>
> - Replacing the really complicated AES based entropy extraction
> algorithm with a much simpler one.
>
> Note that this mirrors similar changes in other drivers.
>
> Eric Biggers (4):
> crypto: xilinx-trng - Remove crypto_rng interface
> crypto: xilinx-trng - Fix return value of xtrng_hwrng_trng_read()
> crypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512
> hwrng: xilinx - Move xilinx-rng into drivers/char/hw_random/
>
> MAINTAINERS | 2 +-
> arch/arm64/configs/defconfig | 2 +-
> crypto/Kconfig | 5 -
> crypto/Makefile | 2 -
> crypto/df_sp80090a.c | 222 ------------------
> drivers/char/hw_random/Kconfig | 11 +
> drivers/char/hw_random/Makefile | 1 +
> .../xilinx => char/hw_random}/xilinx-trng.c | 134 ++---------
> drivers/crypto/Kconfig | 13 -
> drivers/crypto/xilinx/Makefile | 1 -
> include/crypto/df_sp80090a.h | 53 -----
> 11 files changed, 37 insertions(+), 409 deletions(-)
> delete mode 100644 crypto/df_sp80090a.c
> rename drivers/{crypto/xilinx => char/hw_random}/xilinx-trng.c (75%)
> delete mode 100644 include/crypto/df_sp80090a.h
>
>
> base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> prerequisite-patch-id: 07e982b663ac3f8312ca524f6b91b5b38661df5e
> prerequisite-patch-id: 72064361a8f36e015ab0b7e1fa4d364b40d90506
> prerequisite-patch-id: 8978b8e0db7f47935e5f6f0aff14a97f55d3073c
> prerequisite-patch-id: 6aa0e3e93a008279d71e535a3d0cf48643f55e19
> --
> 2.54.0
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: exynos-rng - Remove exynos-rng driver
From: Herbert Xu @ 2026-06-11 8:49 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-samsung-soc, Krzysztof Kozlowski, Alim Akhtar,
linux-kernel
In-Reply-To: <20260531175932.32171-1-ebiggers@kernel.org>
On Sun, May 31, 2026 at 10:59:31AM -0700, Eric Biggers wrote:
> This driver has no purpose. It doesn't feed into the Linux RNG, nor
> does it implement the hwrng interface. It is accessible only via the
> "rng" algorithm type of AF_ALG, which isn't used in practice. Everyone
> uses either the Linux RNG, or rarely /dev/hwrng.
>
> Moreover, this is a PRNG whose only source of entropy is the 160-bit
> seed the user passes in. So this can be used only by a user who already
> has a source of cryptographically secure random numbers, such as
> /dev/random. Which they can, and do, just use in the first place.
>
> Just remove this driver. There's no need to keep useless code around.
>
> Note that the other crypto_rng drivers in drivers/crypto/ are similarly
> unused and are being removed too. This commit just handles exynos-rng.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> MAINTAINERS | 8 -
> arch/arm/configs/exynos_defconfig | 1 -
> arch/arm/configs/multi_v7_defconfig | 1 -
> drivers/crypto/Kconfig | 18 --
> drivers/crypto/Makefile | 1 -
> drivers/crypto/exynos-rng.c | 399 ----------------------------
> 6 files changed, 428 deletions(-)
> delete mode 100644 drivers/crypto/exynos-rng.c
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/2] HiSilicon TRNG fix and simplification
From: Herbert Xu @ 2026-06-11 8:48 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, Olivia Mackall, Weili Qian, Wei Xu, Longfang Liu,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260530202624.20768-1-ebiggers@kernel.org>
On Sat, May 30, 2026 at 01:26:22PM -0700, Eric Biggers wrote:
> This series fixes and greatly simplifies the HiSilicon TRNG driver by
> removing the gratuitous crypto_rng interface, leaving just hwrng which
> is the one that actually matters.
>
> Note that this mirrors similar changes in other drivers such as qcom-rng
> (https://lore.kernel.org/r/20260530020332.143058-1-ebiggers@kernel.org)
>
> Eric Biggers (2):
> crypto: hisi-trng - Remove crypto_rng interface
> hwrng: hisi-trng - Move hisi-trng into drivers/char/hw_random/
>
> MAINTAINERS | 2 +-
> arch/arm64/configs/defconfig | 2 +-
> drivers/char/hw_random/Kconfig | 10 +
> drivers/char/hw_random/Makefile | 1 +
> drivers/char/hw_random/hisi-trng-v2.c | 98 +++++++
> drivers/crypto/hisilicon/Kconfig | 8 -
> drivers/crypto/hisilicon/Makefile | 1 -
> drivers/crypto/hisilicon/trng/Makefile | 2 -
> drivers/crypto/hisilicon/trng/trng.c | 390 -------------------------
> 9 files changed, 111 insertions(+), 403 deletions(-)
> create mode 100644 drivers/char/hw_random/hisi-trng-v2.c
> delete mode 100644 drivers/crypto/hisilicon/trng/Makefile
> delete mode 100644 drivers/crypto/hisilicon/trng/trng.c
>
>
> base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> prerequisite-patch-id: 07e982b663ac3f8312ca524f6b91b5b38661df5e
> prerequisite-patch-id: 72064361a8f36e015ab0b7e1fa4d364b40d90506
> prerequisite-patch-id: 8978b8e0db7f47935e5f6f0aff14a97f55d3073c
> prerequisite-patch-id: 6aa0e3e93a008279d71e535a3d0cf48643f55e19
> --
> 2.54.0
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: loongson - Remove broken and unused loongson-rng
From: Herbert Xu @ 2026-06-11 8:48 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, loongarch, Qunqin Zhao, Huacai Chen,
Yinggang Gu, Lee Jones, stable
In-Reply-To: <20260529233208.8703-1-ebiggers@kernel.org>
On Fri, May 29, 2026 at 04:32:08PM -0700, Eric Biggers wrote:
> The loongson-rng rng_alg has several vulnerabilities, including not
> providing forward security, and a use-after-free bug due to the use of
> wait_for_completion_interruptible().
>
> Meanwhile, the rng_alg framework doesn't really have any purpose in the
> first place other than to access the software algorithms crypto/drbg.c
> and crypto/jitterentropy.c. Hardware-specific rng_algs have no
> in-kernel user, and unlike hwrng there's no feed into the actual Linux
> RNG. As such, there's really no point to this code. There are of
> course other rng_alg drivers that are similarly unused, but they're
> similarly in the process of being phased out, e.g.
> https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and
> https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org
>
> Given that, there's no point in fixing forward these vulnerabilities,
> and it makes much more sense to simply roll back the addition of this
> driver. If this platform provides TRNG (not PRNG) functionality, it
> could make sense to add a hwrng driver, but it would be quite different.
>
> Link: https://lore.kernel.org/linux-crypto/20260525145939.GC2018@quark/
> Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> MAINTAINERS | 1 -
> arch/loongarch/configs/loongson32_defconfig | 1 -
> arch/loongarch/configs/loongson64_defconfig | 1 -
> drivers/crypto/Kconfig | 1 -
> drivers/crypto/Makefile | 1 -
> drivers/crypto/loongson/Kconfig | 6 -
> drivers/crypto/loongson/Makefile | 1 -
> drivers/crypto/loongson/loongson-rng.c | 209 --------------------
> 8 files changed, 221 deletions(-)
> delete mode 100644 drivers/crypto/loongson/Kconfig
> delete mode 100644 drivers/crypto/loongson/Makefile
> delete mode 100644 drivers/crypto/loongson/loongson-rng.c
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox