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
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() from a module is not ok either.
> >
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() from a module is not ok either.
>
> I don't understand this objection.
Consider an LSM that hooks into secu
On Wed, Apr 23, 2025 at 10: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() from a module is not ok either.
>
> I don't understand this objection. The program just got passed in to
> b
On Mon, 2025-04-21 at 13:12 -0700, Alexei Starovoitov wrote:
[...]
> Calling bpf_map_get() and
> map->ops->map_lookup_elem() from a module is not ok either.
I don't understand this objection. The program just got passed in to
bpf_prog_load() as a set of attributes which, for a light skeleton,
dir
On Tue, Apr 22, 2025 at 01:24:22PM +0300, Dan Carpenter wrote:
>
> This is exactly what Kees did with the mass conversion to
> struct_size(). I occasionally run across places where Kees's mass
> conversion patches did fix real integer overflow bugs.
The point is that the reqsize shouldn't even ex
On Mon, Apr 21, 2025 at 08:05:43PM +0800, Herbert Xu wrote:
> On Mon, Apr 21, 2025 at 01:51:06PM +0800, Su Hui wrote:
> >
> > @@ -433,7 +434,7 @@ static inline struct aead_request
> > *aead_request_alloc(struct crypto_aead *tfm,
> > {
> > struct aead_request *req;
> >
> > - req = kmalloc(
On Mon, Apr 21, 2025 at 7:48 PM Alexei Starovoitov
wrote:
> On Mon, Apr 21, 2025 at 3:04 PM Paul Moore wrote:
> > On Mon, Apr 21, 2025 at 4:13 PM Alexei Starovoitov
> > wrote:
> > > On Wed, Apr 16, 2025 at 10:31 AM Blaise Boscaccy
> > > wrote:
> > > >
> > > > > Hacking into bpf internal objects
On 2025/4/21 20:05, Herbert Xu wrote:
On Mon, Apr 21, 2025 at 01:51:06PM +0800, Su Hui wrote:
@@ -433,7 +434,7 @@ static inline struct aead_request
*aead_request_alloc(struct crypto_aead *tfm,
{
struct aead_request *req;
- req = kmalloc(sizeof(*req) + crypto_aead_reqsize(tfm), gfp)
On Mon, Apr 21, 2025 at 3:04 PM Paul Moore wrote:
>
> On Mon, Apr 21, 2025 at 4:13 PM Alexei Starovoitov
> wrote:
> > On Wed, Apr 16, 2025 at 10:31 AM Blaise Boscaccy
> > wrote:
> > >
> > > > Hacking into bpf internal objects like maps is not acceptable.
> > >
> > > We've heard your concerns abo
On Mon, Apr 21, 2025 at 4:13 PM Alexei Starovoitov
wrote:
> On Wed, Apr 16, 2025 at 10:31 AM Blaise Boscaccy
> wrote:
> >
> > > Hacking into bpf internal objects like maps is not acceptable.
> >
> > We've heard your concerns about kern_sys_bpf and we agree that the LSM
> > should not be calling i
On Wed, Apr 16, 2025 at 10:31 AM Blaise Boscaccy
wrote:
>
> > Hacking into bpf internal objects like maps is not acceptable.
>
> We've heard your concerns about kern_sys_bpf and we agree that the LSM
> should not be calling it. The proposal in this email should meet both of
> our needs
> https://l
On Mon, 2025-04-21 at 14:52 -0400, Paul Moore wrote:
> On Sat, Apr 19, 2025 at 2:43 PM James Bottomley
> wrote:
> > On Fri, 2025-04-04 at 14:54 -0700, Blaise Boscaccy wrote:
> > [...]
> > > diff --git a/include/linux/kernel_read_file.h
> > > b/include/linux/kernel_read_file.h
> > > index 90451e2e1
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
> Security Engine firmware. This drive
On Fri, Apr 18, 2025 at 05:36:00PM +0800, 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: Jarkko Sakkinen
> Reviewed-by: Huacai Chen
> ---
> v8: None
> v7: Added tag from Jarkko
On Sat, Apr 19, 2025 at 2:43 PM James Bottomley
wrote:
> On Fri, 2025-04-04 at 14:54 -0700, Blaise Boscaccy wrote:
> [...]
> > diff --git a/include/linux/kernel_read_file.h
> > b/include/linux/kernel_read_file.h
> > index 90451e2e12bd..7ed9337be542 100644
> > --- a/include/linux/kernel_read_file.h
On Mon, Apr 21, 2025 at 01:51:06PM +0800, Su Hui wrote:
>
> @@ -433,7 +434,7 @@ static inline struct aead_request
> *aead_request_alloc(struct crypto_aead *tfm,
> {
> struct aead_request *req;
>
> - req = kmalloc(sizeof(*req) + crypto_aead_reqsize(tfm), gfp);
> + req = kmalloc(siz
On 2025/4/21 16:46, Su Hui wrote:
On 2025/4/21 16:32, Christophe JAILLET wrote:
Le 21/04/2025 à 09:43, Su Hui a écrit :
On 2025/4/21 15:10, Christophe JAILLET wrote:
Le 21/04/2025 à 07:51, Su Hui a écrit :
It's safer to use size_add() to replace open-coded aithmetic in
allocator
arguments, b
On 2025/4/21 16:32, Christophe JAILLET wrote:
Le 21/04/2025 à 09:43, Su Hui a écrit :
On 2025/4/21 15:10, Christophe JAILLET wrote:
Le 21/04/2025 à 07:51, Su Hui a écrit :
It's safer to use size_add() to replace open-coded aithmetic in
allocator
arguments, because size_add() can prevent possi
Le 21/04/2025 à 09:43, Su Hui a écrit :
On 2025/4/21 15:10, Christophe JAILLET wrote:
Le 21/04/2025 à 07:51, Su Hui a écrit :
It's safer to use size_add() to replace open-coded aithmetic in
allocator
arguments, because size_add() can prevent possible overflow problem.
Signed-off-by: Su Hui
-
On 2025/4/21 15:10, Christophe JAILLET wrote:
Le 21/04/2025 à 07:51, Su Hui a écrit :
It's safer to use size_add() to replace open-coded aithmetic in
allocator
arguments, because size_add() can prevent possible overflow problem.
Signed-off-by: Su Hui
---
include/crypto/aead.h | 3 ++-
Le 21/04/2025 à 07:51, Su Hui a écrit :
It's safer to use size_add() to replace open-coded aithmetic in allocator
arguments, because size_add() can prevent possible overflow problem.
Signed-off-by: Su Hui
---
include/crypto/aead.h | 3 ++-
include/crypto/akcipher.h | 4 +++-
include/cry
On 2025/4/21 13:51, Su Hui wrote:
It's safer to use size_add() to replace open-coded aithmetic in allocator
arguments, because size_add() can prevent possible overflow problem.
Signed-off-by: Su Hui
---
include/crypto/aead.h | 3 ++-
include/crypto/akcipher.h | 4 +++-
include/crypto/kp
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 the
> engine and must first send
On Fri, 2025-04-04 at 14:54 -0700, Blaise Boscaccy wrote:
[...]
> diff --git a/include/linux/kernel_read_file.h
> b/include/linux/kernel_read_file.h
> index 90451e2e12bd..7ed9337be542 100644
> --- a/include/linux/kernel_read_file.h
> +++ b/include/linux/kernel_read_file.h
> @@ -14,6 +14,7 @@
>
On Tue, Apr 15, 2025 at 3:08 PM Blaise Boscaccy
wrote:
> ... would you be ammenable to a simple patch in
> skel_internal.h that freezes maps? e.g
I have limited network access at the moment, so it is possible I've
missed it, but I think it would be helpful to get a verdict on the
RFC-esque patch
Alexei Starovoitov writes:
> History repeats itself.
> 1. the problem is hard.
> 2. you're only interested in addressing your own use case.
> There is no end-to-end design here and no attempt to
> think it through how it will work for others.
>
Well, I suppose anything worth doing is going to be
to proceed with Hornet. If or when you actually figure out how to
> sign an lskel and upstream updated LSM hooks, I can always rework Hornet
> to use that instead.
You can do whatever you want out-of-tree including re-exporting kern_sys_bpf.
> code signing last week. All we are trying to do is ma
Blaise Boscaccy writes:
> Alexei Starovoitov writes:
>
>> On Mon, Apr 14, 2025 at 5:32 PM Blaise Boscaccy
>> wrote:
>>>
>>> Alexei Starovoitov writes:
>>>
>>> > On Sat, Apr 12, 2025 at 6:58 AM Blaise Boscaccy
>>> > wrote:
>>> >>
>>> >> TAlexei Starovoitov writes:
>>> >>
>>> >> > On Fri, Apr
Alexei Starovoitov writes:
> On Mon, Apr 14, 2025 at 5:32 PM Blaise Boscaccy
> wrote:
>>
>> Alexei Starovoitov writes:
>>
>> > On Sat, Apr 12, 2025 at 6:58 AM Blaise Boscaccy
>> > wrote:
>> >>
>> >> TAlexei Starovoitov writes:
>> >>
>> >> > On Fri, Apr 4, 2025 at 2:56 PM Blaise Boscaccy
>> >>
On Mon, Apr 14, 2025 at 5:32 PM Blaise Boscaccy
wrote:
>
> Alexei Starovoitov writes:
>
> > On Sat, Apr 12, 2025 at 6:58 AM Blaise Boscaccy
> > wrote:
> >>
> >> TAlexei Starovoitov writes:
> >>
> >> > On Fri, Apr 4, 2025 at 2:56 PM Blaise Boscaccy
> >> > wrote:
> >> >> +
> >> >> +static int ho
On Mon, Apr 14, 2025 at 4:46 PM Blaise Boscaccy
wrote:
> Paul Moore writes:
> > On Apr 4, 2025 Blaise Boscaccy wrote:
...
> >> +static int hornet_check_binary(struct bpf_prog *prog, union bpf_attr
> >> *attr,
> >> + struct hornet_maps *maps)
> >> +{
> >> +struct
Alexei Starovoitov writes:
> On Sat, Apr 12, 2025 at 6:58 AM Blaise Boscaccy
> wrote:
>>
>> TAlexei Starovoitov writes:
>>
>> > On Fri, Apr 4, 2025 at 2:56 PM Blaise Boscaccy
>> > wrote:
>> >> +
>> >> +static int hornet_find_maps(struct bpf_prog *prog, struct hornet_maps
>> >> *maps)
>> >> +{
On Sat, Apr 12, 2025 at 6:58 AM Blaise Boscaccy
wrote:
>
> TAlexei Starovoitov writes:
>
> > On Fri, Apr 4, 2025 at 2:56 PM Blaise Boscaccy
> > wrote:
> >> +
> >> +static int hornet_find_maps(struct bpf_prog *prog, struct hornet_maps
> >> *maps)
> >> +{
> >> + struct bpf_insn *insn = prog
Paul Moore writes:
> On Apr 4, 2025 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.
>>
>>
Tyler Hicks writes:
> On 2025-04-04 14:54:50, Blaise Boscaccy wrote:
>> +static int hornet_verify_lskel(struct bpf_prog *prog, struct hornet_maps
>> *maps,
>> + void *sig, size_t sig_len)
>> +{
>> +int fd;
>> +u32 i;
>> +void *buf;
>> +void *new;
>> +
On Sat, Apr 12, 2025 at 9:58 AM Blaise Boscaccy
wrote:
> Alexei Starovoitov writes:
> > On Fri, Apr 4, 2025 at 2:56 PM Blaise Boscaccy
> > wrote:
...
> > Above are serious layering violations.
> > LSMs should not be looking that deep into bpf instructions.
>
> These aren't BPF internals; this
Alexei Starovoitov writes:
> On Fri, Apr 11, 2025 at 5:30 PM Matteo Croce wrote:
>>
>> Il giorno sab 12 apr 2025 alle ore 02:19 Alexei Starovoitov
>> ha scritto:
>>
>> Similar to what I proposed here?
>>
>> https://lore.kernel.org/bpf/20211203191844.69709-2-mcr...@linux.microsoft.com/
> ...
>>
TAlexei Starovoitov writes:
> On Fri, Apr 4, 2025 at 2:56 PM Blaise Boscaccy
> wrote:
>> +
>> +static int hornet_find_maps(struct bpf_prog *prog, struct hornet_maps *maps)
>> +{
>> + struct bpf_insn *insn = prog->insnsi;
>> + int insn_cnt = prog->len;
>> + int i;
>> + int
On Sat, Apr 12, 2025 at 04:30:24AM +0300, Jarkko Sakkinen wrote:
> On Fri, Apr 11, 2025 at 11:37:25PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Apr 11, 2025 at 04:59:11PM +0100, David Howells wrote:
> > > Jarkko Sakkinen wrote:
> > >
> > > > + spin_lock_irqsave(&key_graveyard_lock, flags);
On Fri, Apr 11, 2025 at 11:37:25PM +0300, Jarkko Sakkinen wrote:
> On Fri, Apr 11, 2025 at 04:59:11PM +0100, David Howells wrote:
> > Jarkko Sakkinen wrote:
> >
> > > + spin_lock_irqsave(&key_graveyard_lock, flags);
> > > + list_splice_init(&key_graveyard, &graveyard);
> > > + spin_unlock_irqrest
On Fri, Apr 11, 2025 at 5:30 PM Matteo Croce wrote:
>
> Il giorno sab 12 apr 2025 alle ore 02:19 Alexei Starovoitov
> ha scritto:
>
> Similar to what I proposed here?
>
> https://lore.kernel.org/bpf/20211203191844.69709-2-mcr...@linux.microsoft.com/
...
> @@ -1346,6 +1346,8 @@ union bpf_attr {
>
Il giorno sab 12 apr 2025 alle ore 02:19 Alexei Starovoitov
ha scritto:
Similar to what I proposed here?
https://lore.kernel.org/bpf/20211203191844.69709-2-mcr...@linux.microsoft.com/
> The verification of module signatures is a job of the module loading process.
> The same thing should be done
On Fri, Apr 4, 2025 at 2:56 PM Blaise Boscaccy
wrote:
> +
> +static int hornet_find_maps(struct bpf_prog *prog, struct hornet_maps *maps)
> +{
> + struct bpf_insn *insn = prog->insnsi;
> + int insn_cnt = prog->len;
> + int i;
> + int err;
> +
> + for (i = 0; i < insn_
On Apr 4, 2025 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 target for signat
On Fri, Apr 11, 2025 at 11:37:25PM +0300, Jarkko Sakkinen wrote:
> > This is going to enable and disable interrupts twice and that can be
> > expensive, depending on the arch. I wonder if it would be better to do:
> >
> > local_irq_save(flags);
> > spin_loc
On Fri, Apr 11, 2025 at 04:59:11PM +0100, David Howells wrote:
> Jarkko Sakkinen wrote:
>
> > + spin_lock_irqsave(&key_graveyard_lock, flags);
> > + list_splice_init(&key_graveyard, &graveyard);
> > + spin_unlock_irqrestore(&key_graveyard_lock, flags);
>
> I would wrap this bit in a check
On 2025-04-04 14:54:50, Blaise Boscaccy wrote:
> +static int hornet_verify_lskel(struct bpf_prog *prog, struct hornet_maps
> *maps,
> +void *sig, size_t sig_len)
> +{
> + int fd;
> + u32 i;
> + void *buf;
> + void *new;
> + size_t buf_sz;
> + str
Jarkko Sakkinen wrote:
> + spin_lock_irqsave(&key_graveyard_lock, flags);
> + list_splice_init(&key_graveyard, &graveyard);
> + spin_unlock_irqrestore(&key_graveyard_lock, flags);
I would wrap this bit in a check to see if key_graveyard is empty so that we
can avoid disabling irqs an
在 2025/4/6 下午5:05, Huacai Chen 写道:
Hi, Qunqin,
On Thu, Apr 3, 2025 at 10:46 AM Qunqin Zhao wrote:
Loongson's Random Number Generator is found inside Loongson security
engine.
Co-developed-by: Yinggang Gu
Signed-off-by: Yinggang Gu
Signed-off-by: Qunqin Zhao
Reviewed-by: Huacai Chen
---
On Mon, Apr 07, 2025 at 03:51:21PM +0200, Stefano Garzarella wrote:
> On Mon, Apr 07, 2025 at 03:28:05PM +0300, Jarkko Sakkinen wrote:
> > tpm2_start_auth_session() does not mask TPM RC correctly from the callers:
> >
> > [ 28.766528] tpm tpm0: A TPM error (2307) occurred start auth session
> >
在 2025/4/7 下午12:04, Herbert Xu 写道:
On Thu, Apr 03, 2025 at 10:46:42AM +0800, Qunqin Zhao wrote:
Loongson's Random Number Generator is found inside Loongson security
engine.
Is this a hardware RNG or a pseudo RNG? If it's pseudo, it should
provide a means of reseeding.
Will provide a means o
On Tue, Apr 08, 2025 at 07:01:47PM +0300, Jarkko Sakkinen wrote:
> On Mon, Apr 07, 2025 at 03:58:01PM +0300, Jarkko Sakkinen wrote:
> > From: Jarkko Sakkinen
> >
> > Add an isolated list of unreferenced keys to be queued for deletion, and
> > try to pin the keys in the garbage collector before pr
On Mon, Apr 07, 2025 at 09:13:37PM +0300, Jarkko Sakkinen wrote:
> On Mon, Apr 07, 2025 at 03:51:21PM +0200, Stefano Garzarella wrote:
> > On Mon, Apr 07, 2025 at 03:28:05PM +0300, Jarkko Sakkinen wrote:
> > > tpm2_start_auth_session() does not mask TPM RC correctly from the callers:
> > >
> > > [
On Mon, Apr 07, 2025 at 03:58:01PM +0300, Jarkko Sakkinen wrote:
> From: Jarkko Sakkinen
>
> Add an isolated list of unreferenced keys to be queued for deletion, and
> try to pin the keys in the garbage collector before processing anything.
> Skip unpinnable keys.
>
> Use this list for blocking
On Mon, Apr 07, 2025 at 03:28:05PM +0300, Jarkko Sakkinen wrote:
tpm2_start_auth_session() does not mask TPM RC correctly from the callers:
[ 28.766528] tpm tpm0: A TPM error (2307) occurred start auth session
Process TPM RCs inside tpm2_start_auth_session(), and map them to POSIX
error codes
On Mon, Apr 07, 2025 at 02:30:05PM +0300, Jarkko Sakkinen wrote:
On Mon, Apr 07, 2025 at 10:04:09AM +0200, Stefano Garzarella wrote:
On Mon, Apr 07, 2025 at 10:20:57AM +0300, Jarkko Sakkinen wrote:
> tpm2_start_auth_session() does not mask TPM RC correctly from the callers:
>
> [ 28.766528] tp
On Mon, Apr 07, 2025 at 02:42:34PM +0200, Marek Szyprowski wrote:
> On 07.04.2025 14:08, Jarkko Sakkinen wrote:
> > On Mon, Apr 07, 2025 at 02:23:49PM +0300, Jarkko Sakkinen wrote:
> >> On Mon, Apr 07, 2025 at 12:25:11PM +0200, Marek Szyprowski wrote:
> >>> On 07.04.2025 04:39, Jarkko Sakkinen wrot
On 07.04.2025 14:08, Jarkko Sakkinen wrote:
> On Mon, Apr 07, 2025 at 02:23:49PM +0300, Jarkko Sakkinen wrote:
>> On Mon, Apr 07, 2025 at 12:25:11PM +0200, Marek Szyprowski wrote:
>>> On 07.04.2025 04:39, Jarkko Sakkinen wrote:
From: Jarkko Sakkinen
Add an isolated list of unreferen
On Mon, Apr 07, 2025 at 03:28:05PM +0300, Jarkko Sakkinen wrote:
> tpm2_start_auth_session() does not mask TPM RC correctly from the callers:
>
> [ 28.766528] tpm tpm0: A TPM error (2307) occurred start auth session
>
> Process TPM RCs inside tpm2_start_auth_session(), and map them to POSIX
> e
On Mon, Apr 07, 2025 at 02:23:49PM +0300, Jarkko Sakkinen wrote:
> On Mon, Apr 07, 2025 at 12:25:11PM +0200, Marek Szyprowski wrote:
> > On 07.04.2025 04:39, Jarkko Sakkinen wrote:
> > > From: Jarkko Sakkinen
> > >
> > > Add an isolated list of unreferenced keys to be queued for deletion, and
> >
On Mon, Apr 07, 2025 at 10:04:09AM +0200, Stefano Garzarella wrote:
> On Mon, Apr 07, 2025 at 10:20:57AM +0300, Jarkko Sakkinen wrote:
> > tpm2_start_auth_session() does not mask TPM RC correctly from the callers:
> >
> > [ 28.766528] tpm tpm0: A TPM error (2307) occurred start auth session
> >
On Mon, Apr 07, 2025 at 12:25:11PM +0200, Marek Szyprowski wrote:
> On 07.04.2025 04:39, Jarkko Sakkinen wrote:
> > From: Jarkko Sakkinen
> >
> > Add an isolated list of unreferenced keys to be queued for deletion, and
> > try to pin the keys in the garbage collector before processing anything.
>
>patch (sorry).
> v3:
> - Using spin_lock() fails since key_put() is executed inside IRQs.
>Using spin_lock_irqsave() would neither work given the lock is
>acquired for /proc/keys. Therefore, separate the lock for
>graveyard and key_graveyard before reaping
On Mon, Apr 07, 2025 at 10:20:57AM +0300, Jarkko Sakkinen wrote:
tpm2_start_auth_session() does not mask TPM RC correctly from the callers:
[ 28.766528] tpm tpm0: A TPM error (2307) occurred start auth session
Process TPM RCs inside tpm2_start_auth_session(), and map them to POSIX
error codes
Hi, Lee
在 2025/4/5 上午12:06, Lee Jones 写道:
On Thu, 03 Apr 2025, Qunqin Zhao wrote:
This driver supports Loongson Security Module, which provides the control
for it's hardware encryption acceleration child devices.
Co-developed-by: Yinggang Gu
Signed-off-by: Yinggang Gu
Signed-off-by: Qunqi
On Tue, Oct 08, 2024 at 02:28:27AM +0300, Jarkko Sakkinen wrote:
>
> I guess it is TPM2_StartAuthSession returning TPM_RC_VALUE. Probably
> James should look into this as the bus encryption code is clearly
> tripping here.
OK I've just got a confirmation from the lkp that the tpm RNG is
indeed bug
On Thu, Apr 03, 2025 at 10:46:42AM +0800, Qunqin Zhao wrote:
> Loongson's Random Number Generator is found inside Loongson security
> engine.
Is this a hardware RNG or a pseudo RNG? If it's pseudo, it should
provide a means of reseeding.
If it's a hardware RNG it should register with hwrng.
Chee
On Mon, Apr 07, 2025 at 03:10:45AM +0300, Jarkko Sakkinen wrote:
> From: Jarkko Sakkinen
>
> Add an isolated list of unreferenced keys to be queued for deletion, and
> try to pin the keys in the garbage collector before processing anything.
> Skip unpinnable keys.
>
> Use this list for blocking
Hi Blaise,
kernel test robot noticed the following build errors:
[auto build test ERROR on shuah-kselftest/next]
[also build test ERROR on shuah-kselftest/fixes herbert-cryptodev-2.6/master
herbert-crypto-2.6/master masahiroy-kbuild/for-next masahiroy-kbuild/fixes
v6.14]
[cannot apply to linus/
Hi, Qunqin,
On Thu, Apr 3, 2025 at 10:46 AM Qunqin Zhao wrote:
>
> Loongson's Random Number Generator is found inside Loongson security
> engine.
>
> Co-developed-by: Yinggang Gu
> Signed-off-by: Yinggang Gu
> Signed-off-by: Qunqin Zhao
> Reviewed-by: Huacai Chen
> ---
> v7: Change the lsrng_
Hi Blaise,
kernel test robot noticed the following build errors:
[auto build test ERROR on shuah-kselftest/next]
[also build test ERROR on shuah-kselftest/fixes herbert-cryptodev-2.6/master
herbert-crypto-2.6/master masahiroy-kbuild/for-next masahiroy-kbuild/fixes
v6.14]
[cannot apply to linus/
1 - 100 of 24573 matches
Mail list logo
