在 2025/5/28 下午5:53, Stefano Garzarella 写道:
On Wed, May 28, 2025 at 05:34:49PM +0800, Qunqin Zhao wrote:
在 2025/5/28 下午5:24, Qunqin Zhao 写道:
在 2025/5/28 下午5:00, Stefano Garzarella 写道:
On Wed, May 28, 2025 at 04:42:05PM +0800, Qunqin Zhao wrote:
在 2025/5/28 下午3:57, Stefano Garzarella 写道:
On Wed, May 28, 2025 at 07:15:18PM +0200, Jann Horn wrote:
> On Wed, May 28, 2025 at 6:46 PM Kees Cook wrote:
> > On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote:
> > > If this new sanitizer is going to move forward, is there any sort of plan
> > > or
> > > guide for how to update co
On Wed, May 28, 2025 at 6:46 PM Kees Cook wrote:
> On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote:
> > If this new sanitizer is going to move forward, is there any sort of plan or
> > guide for how to update code to be compatible with it? Specifically
> > considering
> > common sit
On Wed, May 28, 2025, at 18:45, Kees Cook wrote:
> On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote:
>> On Wed, May 28, 2025 at 01:15:05PM +0800, kernel test robot wrote:
> I'm not sure how to enforce "don't enable this unless you're developing
> the Overflow Behavior Types" with curre
On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote:
> [+Kees and linux-hardening]
>
> On Wed, May 28, 2025 at 01:15:05PM +0800, kernel test robot wrote:
> >
> >
> > Hello,
> >
> > by this commit, the config has below diff:
> >
> > ---
> > /pkg/linux/x86_64-randconfig-101-20250522/cl
On 28/05/2025 09:01, Qunqin Zhao wrote:
> Changes to Loongson TPM driver would be best reviewed by the Loongson
> crypto driver maintainers.
>
> Signed-off-by: Qunqin Zhao
> Reviewed-by: Huacai Chen
> Reviewed-by: Jarkko Sakkinen
> ---
> v8-v10: None
> v7: Added tag from Jarkko and Huacai
> v
On Wed, 28 May 2025 at 11:25, Qunqin Zhao wrote:
>
>
> 在 2025/5/28 下午5:00, Stefano Garzarella 写道:
> > On Wed, May 28, 2025 at 04:42:05PM +0800, Qunqin Zhao wrote:
> >>
> >> 在 2025/5/28 下午3:57, Stefano Garzarella 写道:
> +chip = tpmm_chip_alloc(dev, &tpm_loongson_ops);
> +if (IS_ERR
On Wed, May 28, 2025 at 04:42:05PM +0800, Qunqin Zhao wrote:
在 2025/5/28 下午3:57, Stefano Garzarella 写道:
+ chip = tpmm_chip_alloc(dev, &tpm_loongson_ops);
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+ chip->flags = TPM_CHIP_FLAG_TPM2 | TPM_CHIP_FLAG_IRQ;
Why setting TPM_CHIP_FL
在 2025/5/28 下午3:57, Stefano Garzarella 写道:
+ chip = tpmm_chip_alloc(dev, &tpm_loongson_ops);
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+ chip->flags = TPM_CHIP_FLAG_TPM2 | TPM_CHIP_FLAG_IRQ;
Why setting TPM_CHIP_FLAG_IRQ?
When tpm_engine completes TPM_CC* command,
the ha
On Wed, May 28, 2025 at 5:15 PM Yanteng Si wrote:
>
> 在 5/28/25 4:17 PM, Huacai Chen 写道:
> > On Wed, May 28, 2025 at 4:06 PM Qunqin Zhao wrote:
> >>
> >>
> >> 在 2025/5/28 下午3:17, Huacai Chen 写道:
> >>> Hi, Qunqin,
> >>>
> >>> As I said before, why the patch "MAINTAINERS: Add entry for Loongson
> >
On Wed, May 28, 2025 at 05:34:49PM +0800, Qunqin Zhao wrote:
在 2025/5/28 下午5:24, Qunqin Zhao 写道:
在 2025/5/28 下午5:00, Stefano Garzarella 写道:
On Wed, May 28, 2025 at 04:42:05PM +0800, Qunqin Zhao wrote:
在 2025/5/28 下午3:57, Stefano Garzarella 写道:
+ chip = tpmm_chip_alloc(dev, &tpm_loongson
在 2025/5/28 下午5:24, Qunqin Zhao 写道:
在 2025/5/28 下午5:00, Stefano Garzarella 写道:
On Wed, May 28, 2025 at 04:42:05PM +0800, Qunqin Zhao wrote:
在 2025/5/28 下午3:57, Stefano Garzarella 写道:
+ chip = tpmm_chip_alloc(dev, &tpm_loongson_ops);
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
在 2025/5/28 下午5:00, Stefano Garzarella 写道:
On Wed, May 28, 2025 at 04:42:05PM +0800, Qunqin Zhao wrote:
在 2025/5/28 下午3:57, Stefano Garzarella 写道:
+ chip = tpmm_chip_alloc(dev, &tpm_loongson_ops);
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+ chip->flags = TPM_CHIP_FLAG_TPM2
在 5/28/25 4:17 PM, Huacai Chen 写道:
On Wed, May 28, 2025 at 4:06 PM Qunqin Zhao wrote:
在 2025/5/28 下午3:17, Huacai Chen 写道:
Hi, Qunqin,
As I said before, why the patch "MAINTAINERS: Add entry for Loongson
Security Module driver" is missing?
Hi, Huacai
https://lore.kernel.org/all/8e55801a-a
On Wed, May 28, 2025 at 4:06 PM Qunqin Zhao wrote:
>
>
> 在 2025/5/28 下午3:17, Huacai Chen 写道:
> > Hi, Qunqin,
> >
> > As I said before, why the patch "MAINTAINERS: Add entry for Loongson
> > Security Module driver" is missing?
>
> Hi, Huacai
>
> https://lore.kernel.org/all/8e55801a-a46e-58d5-cf84-2
在 2025/5/28 下午3:17, Huacai Chen 写道:
Hi, Qunqin,
As I said before, why the patch "MAINTAINERS: Add entry for Loongson
Security Module driver" is missing?
Hi, Huacai
https://lore.kernel.org/all/8e55801a-a46e-58d5-cf84-2ee8a733d...@loongson.cn/
Thanks,
Qunqin.
Huacai
On Wed, May 28, 2025
在 5/28/25 3:17 PM, Huacai Chen 写道:
Hi, Qunqin,
As I said before, why the patch "MAINTAINERS: Add entry for Loongson
Security Module driver" is missing?
Similar issues widely exist in the Loongarch mailing list.
The cause should be attributed to the mail server of Loongson.
It seems that Loong
On Wed, May 28, 2025 at 02:59:43PM +0800, Qunqin Zhao wrote:
Loongson Security Engine supports random number generation, hash,
symmetric encryption and asymmetric encryption. Based on these
encryption functions, TPM2 have been implemented in the Loongson
Security Engine firmware. This driver is r
Hi, Qunqin,
As I said before, why the patch "MAINTAINERS: Add entry for Loongson
Security Module driver" is missing?
Huacai
On Wed, May 28, 2025 at 2:59 PM Qunqin Zhao wrote:
>
> The Loongson Security Engine chip supports RNG, SM2, SM3 and SM4
> accelerator engines. Each engine have its own DMA
[+Kees and linux-hardening]
On Wed, May 28, 2025 at 01:15:05PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> by this commit, the config has below diff:
>
> ---
> /pkg/linux/x86_64-randconfig-101-20250522/clang-20/d469eaed223fa485eabebd3bcd05ddd3c891f54e/.config
> 2025-05-23 23:44:56.78171
在 2025/5/22 下午9:46, Lee Jones 写道:
On Tue, 06 May 2025, Qunqin Zhao wrote:
Loongson Security Engine chip supports RNG, SM2, SM3 and SM4 accelerator
engines. This is the base driver for other specific engine drivers.
Co-developed-by: Yinggang Gu
Signed-off-by: Yinggang Gu
Signed-off-by: Qunq
On Tue, 06 May 2025, Qunqin Zhao wrote:
> Loongson Security Engine chip supports RNG, SM2, SM3 and SM4 accelerator
> engines. This is the base driver for other specific engine drivers.
>
> Co-developed-by: Yinggang Gu
> Signed-off-by: Yinggang Gu
> Signed-off-by: Qunqin Zhao
> Reviewed-by: Hua
On Mon, May 19, 2025 at 6:58 PM Paul Moore wrote:
>
> When the kernel performs a security relevant operation, such as
> verifying the signature on a BPF program, where the result of the
> operation serves as input to a policy decision, system measurement,
> audit event, etc. the LSM hook needs to
> > > > > > No. New hook is not needed.
[...]
> > > > >
> > > > > It would be good for you to explain how the existing LSM hook is
> > > > > sufficient
> > > > > to authorize the loading of a BPF program using the signature
> > > > > validation
> > > > > state determined in the BPF verifier.
>
On Mon, May 19, 2025 at 3:20 PM KP Singh wrote:
>
> On Sun, May 18, 2025 at 11:34 PM Paul Moore wrote:
> >
> > On Sun, May 18, 2025 at 11:52 AM Alexei Starovoitov
> > wrote:
> > > On Sat, May 17, 2025 at 10:49 PM Paul Moore wrote:
> > > > On May 17, 2025 12:13:50 PM Alexei Starovoitov
> > > >
On Mon, May 19, 2025 at 6:20 PM KP Singh wrote:
> On Sun, May 18, 2025 at 11:34 PM Paul Moore wrote:
> > On Sun, May 18, 2025 at 11:52 AM Alexei Starovoitov
> > wrote:
> > > On Sat, May 17, 2025 at 10:49 PM Paul Moore wrote:
> > > > On May 17, 2025 12:13:50 PM Alexei Starovoitov
> > > > wrote:
On Sun, May 18, 2025 at 11:34 PM Paul Moore wrote:
>
> On Sun, May 18, 2025 at 11:52 AM Alexei Starovoitov
> wrote:
> > On Sat, May 17, 2025 at 10:49 PM Paul Moore wrote:
> > > On May 17, 2025 12:13:50 PM Alexei Starovoitov
> > > wrote:
> > > > On Sat, May 17, 2025 at 8:03 AM Paul Moore wrote:
在 2025/5/19 下午1:57, Herbert Xu 写道:
On Tue, May 06, 2025 at 11:19:44AM +0800, Qunqin Zhao wrote:
+static int loongson_rng_init(struct crypto_tfm *tfm)
+{
+ struct loongson_rng_ctx *ctx = crypto_tfm_ctx(tfm);
+ struct loongson_rng *rng;
+ int ret = -EBUSY;
+
+ mutex_lock(
On 2025/5/19 16:22, Herbert Xu wrote:
> On Mon, May 19, 2025 at 04:13:14PM +0800, Qunqin Zhao wrote:
>>
>> Then the HISI TRNG driver isn't a right demo?
>
> Yes the hisi trng looks wrong too.
>
We are currently updating and plan to create software TFM for users when
they unable to apply for hardw
On Mon, May 19, 2025 at 04:49:45PM +0800, Qunqin Zhao wrote:
>
> Is it fine waiting in init-callback until someone calls exit-callback?
No that's just as bad as failing. Remember this is exposed to
user-space through af_alg. If you make it wait it'll just appear
to hang for the user invoking thi
在 2025/5/19 下午4:22, Herbert Xu 写道:
On Mon, May 19, 2025 at 04:13:14PM +0800, Qunqin Zhao wrote:
Then the HISI TRNG driver isn't a right demo?
Yes the hisi trng looks wrong too.
This can also avoid concurrent access to a device, otherwise i need to
add mutex_lock/unlock in generate and seed
On Mon, May 19, 2025 at 04:13:14PM +0800, Qunqin Zhao wrote:
>
> Then the HISI TRNG driver isn't a right demo?
Yes the hisi trng looks wrong too.
> This can also avoid concurrent access to a device, otherwise i need to
>
> add mutex_lock/unlock in generate and seed callback.
Randomly failing th
On Tue, May 06, 2025 at 11:19:44AM +0800, Qunqin Zhao wrote:
>
> +static int loongson_rng_init(struct crypto_tfm *tfm)
> +{
> + struct loongson_rng_ctx *ctx = crypto_tfm_ctx(tfm);
> + struct loongson_rng *rng;
> + int ret = -EBUSY;
> +
> + mutex_lock(&rng_devices.lock);
> + list
On Sun, May 18, 2025 at 11:52 AM Alexei Starovoitov
wrote:
> On Sat, May 17, 2025 at 10:49 PM Paul Moore wrote:
> > On May 17, 2025 12:13:50 PM Alexei Starovoitov
> > wrote:
> > > On Sat, May 17, 2025 at 8:03 AM Paul Moore wrote:
> > >> On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov
> > >>
On Sat, May 17, 2025 at 10:49 PM Paul Moore wrote:
>
> On May 17, 2025 12:13:50 PM Alexei Starovoitov
> wrote:
> > On Sat, May 17, 2025 at 8:03 AM Paul Moore wrote:
> >> On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov
> >> wrote:
> >>> On Fri, May 16, 2025 at 12:49 PM Paul Moore wrote:
> >>
On May 17, 2025 12:13:50 PM Alexei Starovoitov
wrote:
On Sat, May 17, 2025 at 8:03 AM Paul Moore wrote:
On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov
wrote:
On Fri, May 16, 2025 at 12:49 PM Paul Moore wrote:
I think we need some clarification on a few of these details, it would
be go
On Sat, May 17, 2025 at 8:03 AM Paul Moore wrote:
>
> On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov
> wrote:
> > On Fri, May 16, 2025 at 12:49 PM Paul Moore wrote:
> > >
> > > I think we need some clarification on a few of these details, it would
> > > be good if you could answer the questi
On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov
wrote:
> On Fri, May 16, 2025 at 12:49 PM Paul Moore wrote:
> >
> > I think we need some clarification on a few of these details, it would
> > be good if you could answer the questions below about the
> > authorization aspects of your design?
> >
On Fri, May 16, 2025 at 12:49 PM Paul Moore wrote:
>
> On Wed, May 14, 2025 at 2:48 PM KP Singh wrote:
> > On Wed, May 14, 2025 at 5:06 AM Paul Moore wrote:
> > > On Sat, May 10, 2025 at 10:01 PM KP Singh wrote:
> > > >
> > >
> > > ...
> > >
> > > > The signature check in the verifier (during B
On Wed, May 14, 2025 at 2:48 PM KP Singh wrote:
> On Wed, May 14, 2025 at 5:06 AM Paul Moore wrote:
> > On Sat, May 10, 2025 at 10:01 PM KP Singh wrote:
> > >
> >
> > ...
> >
> > > The signature check in the verifier (during BPF_PROG_LOAD):
> > >
> > > verify_pkcs7_signature(prog->aux->sha,
On Wed, May 14, 2025 at 10:32 PM James Bottomley
wrote:
>
> On Wed, 2025-05-14 at 20:35 +0200, KP Singh wrote:
> > On Wed, May 14, 2025 at 7:45 PM James Bottomley
> > wrote:
> > >
> > > On Wed, 2025-05-14 at 19:17 +0200, KP Singh wrote:
> > > > On Wed, May 14, 2025 at 5:39 PM James Bottomley
> >
On Wed, 2025-05-14 at 20:35 +0200, KP Singh wrote:
> On Wed, May 14, 2025 at 7:45 PM James Bottomley
> wrote:
> >
> > On Wed, 2025-05-14 at 19:17 +0200, KP Singh wrote:
> > > On Wed, May 14, 2025 at 5:39 PM James Bottomley
> > > wrote:
> > > > On Sun, 2025-05-11 at 04:01 +0200, KP Singh wrote:
>
On Wed, May 14, 2025 at 5:06 AM Paul Moore wrote:
>
> On Sat, May 10, 2025 at 10:01 PM KP Singh wrote:
> >
>
> ...
>
> > The signature check in the verifier (during BPF_PROG_LOAD):
> >
> > verify_pkcs7_signature(prog->aux->sha, sizeof(prog->aux->sha),
> > sig_from_bpf_attr, …);
>
> I think we
On Wed, May 14, 2025 at 8:35 PM KP Singh wrote:
>
> On Wed, May 14, 2025 at 7:45 PM James Bottomley
> wrote:
> >
> > On Wed, 2025-05-14 at 19:17 +0200, KP Singh wrote:
> > > On Wed, May 14, 2025 at 5:39 PM James Bottomley
> > > wrote:
> > > > On Sun, 2025-05-11 at 04:01 +0200, KP Singh wrote:
>
On Wed, May 14, 2025 at 7:45 PM James Bottomley
wrote:
>
> On Wed, 2025-05-14 at 19:17 +0200, KP Singh wrote:
> > On Wed, May 14, 2025 at 5:39 PM James Bottomley
> > wrote:
> > > On Sun, 2025-05-11 at 04:01 +0200, KP Singh wrote:
> [...]
> > > > This implicitly makes the payload equivalent to the
On Wed, 2025-05-14 at 19:17 +0200, KP Singh wrote:
> On Wed, May 14, 2025 at 5:39 PM James Bottomley
> wrote:
> > On Sun, 2025-05-11 at 04:01 +0200, KP Singh wrote:
[...]
> > > This implicitly makes the payload equivalent to the signed block
> > > (B_signed)
> > >
> > > I_loader || H_meta
> >
On Wed, May 14, 2025 at 5:39 PM James Bottomley
wrote:
>
> On Sun, 2025-05-11 at 04:01 +0200, KP Singh wrote:
> [...]
> > >
> > For this specific BPF case, we will directly sign a composite of the
> > first message and the hash of the second. Let H_meta = H(M_metadata).
> > The block to be signed
On Sun, 2025-05-11 at 04:01 +0200, KP Singh wrote:
[...]
> >
> For this specific BPF case, we will directly sign a composite of the
> first message and the hash of the second. Let H_meta = H(M_metadata).
> The block to be signed is effectively:
>
> B_signed = I_loader || H_meta
>
> The signa
On Sat, May 10, 2025 at 10:01 PM KP Singh wrote:
>
...
> The signature check in the verifier (during BPF_PROG_LOAD):
>
> verify_pkcs7_signature(prog->aux->sha, sizeof(prog->aux->sha),
> sig_from_bpf_attr, …);
I think we still need to clarify the authorization aspect of your
proposed design.
Hi, Jarkko and Stefano
在 2025/5/6 上午11:19, Qunqin Zhao 写道:
Loongson Security Engine supports random number generation, hash,
symmetric encryption and asymmetric encryption. Based on these
encryption functions, TPM2 have been implemented in the Loongson
Security Engine firmware. This driver is
在 2025/5/11 下午5:34, Huacai Chen 写道:
Hi, Qunqin,
Where is the 2nd patch in V7?
Hi, Huacai
I added "loongson se. c" and "loongson se. h" to the LOONGSON CRYPTO
DRIVER entry.
or should i add a separate entry for the mfd driver as done in v7?
Thanks for your comments,
Qunqin.
Huacai
On
On Mon, May 12, 2025 at 01:01:50PM +0100, David Howells wrote:
>
> I can do unless Herbert wants to pass it through his tree?
I have no desire to do that :)
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Jarkko Sakkinen wrote:
> > Acked-by: David Howells
>
> Reviewed-by: Jarkko Sakkinen
>
> David, are you going to pick this?
I can do unless Herbert wants to pass it through his tree?
David
On Mon, May 12, 2025 at 10:19:14AM +0100, David Howells wrote:
> Herbert Xu wrote:
>
> > Invert the FINAL_PUT bit so that test_bit_acquire and clear_bit_unlock
> > can be used instead of smp_mb.
> >
> > Signed-off-by: Herbert Xu
>
> Acked-by: David Howells
Reviewed-by: Jarkko Sakkinen
Davi
Herbert Xu wrote:
> Invert the FINAL_PUT bit so that test_bit_acquire and clear_bit_unlock
> can be used instead of smp_mb.
>
> Signed-off-by: Herbert Xu
Acked-by: David Howells
Hi, Qunqin,
Where is the 2nd patch in V7?
Huacai
On Tue, May 6, 2025 at 12:33 PM Qunqin Zhao wrote:
>
> The Loongson Security Engine chip supports RNG, SM2, SM3 and SM4
> accelerator engines. Each engine have its own DMA buffer provided
> by the controller. The kernel cannot directly send comma
[...]
> Blaise started this most recent effort by attempting to address the
> concerns brought up in previous efforts, you and others rejected this
> first attempt and directed Blaise towards a light skeleton and LSM
> based approach, which is where he is at with Hornet. Once again, you
> reject
> > I think we need a more detailed explanation of this approach on-list.
> > There has been a lot of vague guidance on BPF signature validation
> > from the BPF community which I believe has partly led us into the
> > situation we are in now. If you are going to require yet another
> > approach,
Hello,
our bot applied this patch directly upon v6.15-rc5. could you let us know if
this is a correct appliment?
* a78cdfa4388ab9
(linux-review/Herbert-Xu/KEYS-Invert-FINAL_PUT-bit/20250505-122533) KEYS:
Invert FINAL_PUT bit
* 92a09c47464d04 (tag: v6.15-rc5,
below reports is based on thi
On Wed, May 07, 2025 at 09:33:32AM +0800, Qunqin Zhao wrote:
>
> 在 2025/5/6 下午10:13, Stefano Garzarella 写道:
> > On Tue, May 06, 2025 at 11:19:46AM +0800, Qunqin Zhao wrote:
> > > Loongson Security Engine supports random number generation, hash,
> > > symmetric encryption and asymmetric encryption.
On Tue, May 06, 2025 at 04:13:04PM +0200, Stefano Garzarella wrote:
> > +static int tpm_loongson_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > +{
> > + struct loongson_se_engine *tpm_engine = dev_get_drvdata(&chip->dev);
> > + struct tpm_loongson_cmd *cmd_ret = tpm_engine->command_ret;
On Thu, May 8, 2025 at 1:45 PM Alexei Starovoitov
wrote:
> On Wed, May 7, 2025 at 4:24 PM Paul Moore wrote:
> > On Wed, May 7, 2025 at 1:48 PM James Bottomley
> > wrote:
> > >
> > > I'm with Paul on this: if you could share your design ideas more fully
> > > than you have above that would help m
ecifically as a building block towards signed bpf programs:
See the cover letter from 2021:
https://lore.kernel.org/bpf/20210514003623.28033-1-alexei.starovoi...@gmail.com/
"
This is a first step towards signed bpf programs and the third approach
of that kind.
...
Future steps:
- support CO-RE in
On Wed, May 7, 2025 at 1:48 PM James Bottomley
wrote:
>
> I'm with Paul on this: if you could share your design ideas more fully
> than you have above that would help make this debate way more
> technical.
I think it would also help some of us, at the very least me, put your
objections into conte
On Mon, 2025-05-05 at 22:41 +0200, KP Singh wrote:
> On Mon, May 5, 2025 at 7:30 PM Blaise Boscaccy
> wrote:
> >
> > KP Singh writes:
> >
> > [...]
> >
> > > Now if you really care about the use-case and want to work with
> > > the maintainers and implement signing for the community, here's
>
On Wed, 7 May 2025 at 03:35, Qunqin Zhao wrote:
>
>
> 在 2025/5/6 下午10:13, Stefano Garzarella 写道:
> > On Tue, May 06, 2025 at 11:19:46AM +0800, Qunqin Zhao wrote:
> >> Loongson Security Engine supports random number generation, hash,
> >> symmetric encryption and asymmetric encryption. Based on the
在 5/6/25 8:14 PM, Qunqin Zhao 写道:
在 2025/5/6 下午5:03, Yanteng Si 写道:
在 5/6/25 11:20 AM, Qunqin Zhao 写道:
Changes to Loongson TPM driver would be best reviewed by the Loongson
crypto driver maintainers.
Signed-off-by: Qunqin Zhao
Reviewed-by: Huacai Chen
Reviewed-by: Jarkko Sakkinen
---
v8-
在 2025/5/6 下午10:13, Stefano Garzarella 写道:
On Tue, May 06, 2025 at 11:19:46AM +0800, Qunqin Zhao wrote:
Loongson Security Engine supports random number generation, hash,
symmetric encryption and asymmetric encryption. Based on these
encryption functions, TPM2 have been implemented in the Loong
On Tue, May 06, 2025 at 11:19:46AM +0800, Qunqin Zhao wrote:
Loongson Security Engine supports random number generation, hash,
symmetric encryption and asymmetric encryption. Based on these
encryption functions, TPM2 have been implemented in the Loongson
Security Engine firmware. This driver is r
在 2025/5/6 下午5:03, Yanteng Si 写道:
在 5/6/25 11:20 AM, Qunqin Zhao 写道:
Changes to Loongson TPM driver would be best reviewed by the Loongson
crypto driver maintainers.
Signed-off-by: Qunqin Zhao
Reviewed-by: Huacai Chen
Reviewed-by: Jarkko Sakkinen
---
v8-v9: None
v7: Added tag from Jarkko a
在 5/6/25 11:20 AM, Qunqin Zhao 写道:
Changes to Loongson TPM driver would be best reviewed by the Loongson
crypto driver maintainers.
Signed-off-by: Qunqin Zhao
Reviewed-by: Huacai Chen
Reviewed-by: Jarkko Sakkinen
---
v8-v9: None
v7: Added tag from Jarkko and Huacai
v6: "tpm_lsse.c" -> "tpm_lo
On Mon, May 5, 2025 at 4:41 PM KP Singh wrote:
> On Mon, May 5, 2025 at 7:30 PM Blaise Boscaccy
> wrote:
> >
> > KP Singh writes:
> >
> > [...]
> >
> > > Now if you really care about the use-case and want to work with the
> > > maintainers
> > > and implement signing for the community, here's h
On Mon, May 5, 2025 at 7:30 PM Blaise Boscaccy
wrote:
>
> KP Singh writes:
>
> [...]
>
> > Now if you really care about the use-case and want to work with the
> > maintainers
> > and implement signing for the community, here's how we think it should be
> > done:
> >
> > * The core signing logic
KP Singh writes:
[...]
> Now if you really care about the use-case and want to work with the
> maintainers
> and implement signing for the community, here's how we think it should be
> done:
>
> * The core signing logic and the tooling stays in BPF, something that the
> users
> are already
On Sun, May 4, 2025 at 7:25 PM KP Singh wrote:
> On Sun, May 4, 2025 at 7:36 PM Paul Moore wrote:
> > On Fri, May 2, 2025 at 5:00 PM KP Singh wrote:
...
> > > ... here's how we think it should be done:
> > >
> > > * The core signing logic and the tooling stays in BPF, something that the
> > >
On Sat, May 03, 2025 at 04:21:26PM -0400, Ethan Carter Edwards wrote:
> This series contains two small cleanups to improve code quality and
> readability. One removes a sizeof(char) piece of code (because it
> evaluates to 1 anyways) and one switches to the helper function
> devm_kcalloc.
>
> Sign
On 5/4/25 7:36 PM, Paul Moore wrote:
On Fri, May 2, 2025 at 5:00 PM KP Singh wrote:
[...]
From what I've seen in Blaise's efforts to implement BPF signature
validation in the upstream kernel he has been working in good faith
and has been trying to work with the greater BPF community at each
s
On Sun, May 4, 2025 at 7:36 PM Paul Moore wrote:
>
> On Fri, May 2, 2025 at 5:00 PM KP Singh wrote:
> >
> > > This patch series introduces the Hornet LSM. The goal of Hornet is to
> > > provide
> > > a signature verification mechanism for eBPF programs.
> > >
> >
> > [...]
> >
> > >
> > > Refere
On Fri, May 2, 2025 at 5:00 PM KP Singh wrote:
>
> > This patch series introduces the Hornet LSM. The goal of Hornet is to
> > provide
> > a signature verification mechanism for eBPF programs.
> >
>
> [...]
>
> >
> > References: [1]
> > https://lore.kernel.org/bpf/20220209054315.73833-1-alexei.st
On Sat, May 03, 2025 at 11:02:57PM +0800, Herbert Xu wrote:
> On Sat, May 03, 2025 at 05:39:16PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Apr 30, 2025 at 06:25:53PM +0300, Jarkko Sakkinen wrote:
> > > Rely only on the memory ordering of spin_unlock() when setting
> > > KEY_FLAG_FINAL_PUT under key
On Sat, May 03, 2025 at 11:19:21PM +0100, David Howells wrote:
> Jarkko Sakkinen wrote:
>
> > Oops, my bad (order swap), sorry. Should have been:
> >
> > spin_unlock_irqrestore(&key->user->lock, flags);
> > } else {
> >
On Fri, May 2, 2025 at 2:44 PM Blaise Boscaccy
wrote:
>
> This adds the Hornet Linux Security Module which provides signature
> verification of eBPF programs. This allows users to continue to
> maintain an invariant that all code running inside of the kernel has
> been signed.
>
> The primary targ
Herbert Xu wrote:
> + key->flags |= KEY_FLAG_DONT_GC_YET;
You need __set_bit() or 1<
On Sat, May 03, 2025 at 11:19:21PM +0100, David Howells wrote:
>
> Possibly we only need smp_mb() in the IN_QUOTA branch in key_put().
Just change the smp_mb to smp_mb__before_atomic, at least on x86
it just disappears because set_bit is already a serialising operation.
Or even better, reverse th
Jarkko Sakkinen wrote:
> Oops, my bad (order swap), sorry. Should have been:
>
> spin_unlock_irqrestore(&key->user->lock, flags);
> } else {
> smp_mb(); /* key->user before FINAL_PUT set. */
>
On Sat, May 03, 2025 at 05:39:16PM +0300, Jarkko Sakkinen wrote:
> On Wed, Apr 30, 2025 at 06:25:53PM +0300, Jarkko Sakkinen wrote:
> > Rely only on the memory ordering of spin_unlock() when setting
> > KEY_FLAG_FINAL_PUT under key->user->lock in key_put().
> >
> > Signed-off-by: Jarkko Sakkinen
On Wed, Apr 30, 2025 at 06:25:53PM +0300, Jarkko Sakkinen wrote:
> Rely only on the memory ordering of spin_unlock() when setting
> KEY_FLAG_FINAL_PUT under key->user->lock in key_put().
>
> Signed-off-by: Jarkko Sakkinen
> ---
> security/keys/key.c | 6 --
> 1 file changed, 4 insertions(+),
> This patch series introduces the Hornet LSM. The goal of Hornet is to provide
> a signature verification mechanism for eBPF programs.
>
[...]
>
> References: [1]
> https://lore.kernel.org/bpf/20220209054315.73833-1-alexei.starovoi...@gmail.com/
> [2]
> https://lore.kernel.org/bpf/CAADnVQ+wPK1KK
On Mon, Apr 28, 2025 at 12:19:50PM -0700, Dave Hansen wrote:
> On 4/28/25 11:38, Eric Biggers wrote:
> > -static int sgx_get_key_hash(const void *modulus, void *hash)
> > -{
> > - struct crypto_shash *tfm;
> > - int ret;
> > -
> > - tfm = crypto_alloc_shash("sha256", 0, CRYPTO_ALG_ASYNC);
> >
在 2025/4/30 下午4:58, Lee Jones 写道:
On Wed, 30 Apr 2025, Huacai Chen wrote:
On Wed, Apr 30, 2025 at 4:47 PM Qunqin Zhao wrote:
在 2025/4/30 下午4:18, Herbert Xu 写道:
On Wed, Apr 30, 2025 at 04:14:40PM +0800, Qunqin Zhao wrote:
Sorry to bother you, may i ask is it fine to move the Security Eng
On Wed, 30 Apr 2025, Huacai Chen wrote:
> On Wed, Apr 30, 2025 at 4:47 PM Qunqin Zhao wrote:
> >
> >
> > 在 2025/4/30 下午4:18, Herbert Xu 写道:
> > > On Wed, Apr 30, 2025 at 04:14:40PM +0800, Qunqin Zhao wrote:
> > >> Sorry to bother you, may i ask is it fine to move the Security Engine
> > >> base
On Wed, Apr 30, 2025 at 4:47 PM Qunqin Zhao wrote:
>
>
> 在 2025/4/30 下午4:18, Herbert Xu 写道:
> > On Wed, Apr 30, 2025 at 04:14:40PM +0800, Qunqin Zhao wrote:
> >> Sorry to bother you, may i ask is it fine to move the Security Engine base
> >> driver[Patch v8 1/5] to drivers/crypto ?
> >>
> >> The
在 2025/4/30 下午4:18, Herbert Xu 写道:
On Wed, Apr 30, 2025 at 04:14:40PM +0800, Qunqin Zhao wrote:
Sorry to bother you, may i ask is it fine to move the Security Engine base
driver[Patch v8 1/5] to drivers/crypto ?
The base driver uses MFD interface to register child device(tpm, rng) , as
don
On Wed, Apr 30, 2025 at 04:14:40PM +0800, Qunqin Zhao wrote:
>
> Sorry to bother you, may i ask is it fine to move the Security Engine base
> driver[Patch v8 1/5] to drivers/crypto ?
>
> The base driver uses MFD interface to register child device(tpm, rng) , as
> done in
>
> "drivers/iio/commo
在 2025/4/20 下午3:17, Huacai Chen 写道:
Hi, Qunqin,
On Fri, Apr 18, 2025 at 5:33 PM Qunqin Zhao wrote:
The Loongson Security Engine chip supports RNG, SM2, SM3 and SM4
accelerator engines. Each engine have its own DMA buffer provided
by the controller. The kernel cannot directly send commands to
在 2025/4/22 上午2:58, Jarkko Sakkinen 写道:
On Fri, Apr 18, 2025 at 05:34:06PM +0800, Qunqin Zhao wrote:
Loongson Security Engine supports random number generation, hash,
symmetric encryption and asymmetric encryption. Based on these
encryption functions, TPM2 have been implemented in the Loongson
On Mon, Apr 28, 2025 at 12:19:50PM -0700, Dave Hansen wrote:
> On 4/28/25 11:38, Eric Biggers wrote:
> > -static int sgx_get_key_hash(const void *modulus, void *hash)
> > -{
> > - struct crypto_shash *tfm;
> > - int ret;
> > -
> > - tfm = crypto_alloc_shash("sha256", 0, CRYPTO_ALG_ASYNC);
> >
On 4/28/25 11:38, Eric Biggers wrote:
> -static int sgx_get_key_hash(const void *modulus, void *hash)
> -{
> - struct crypto_shash *tfm;
> - int ret;
> -
> - tfm = crypto_alloc_shash("sha256", 0, CRYPTO_ALG_ASYNC);
> - if (IS_ERR(tfm))
> - return PTR_ERR(tfm);
> -
> -
On Fri, Apr 25, 2025 at 11:11:31PM -0700, Kees Cook wrote:
> In preparation for making the kmalloc family of allocators type aware,
> we need to make sure that the returned type from the allocation matches
> the type of the variable being assigned. (Before, the allocator would
> always return "void
James Bottomley writes:
> On Thu, 2025-04-24 at 16:41 -0700, Alexei Starovoitov wrote:
>> On Wed, Apr 23, 2025 at 7:12 AM James Bottomley
>> wrote:
>> > On Mon, 2025-04-21 at 13:12 -0700, Alexei Starovoitov wrote:
>> > [...]
>> > > Calling bpf_map_get() and
>> > > map->ops->map_lookup_elem() fro
1 - 100 of 24541 matches
Mail list logo
