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 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 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 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 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
On Tue, Apr 15, 2025 at 8:45 AM Blaise Boscaccy
wrote:
>
> The eBPF dev community has spent what, 4-5 years on this, with little to
> no progress. I have little faith that this is going to progress on your
> end in a timely manner or at all, and frankly we (and others) needed
> this yesterday.
Hi
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
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
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 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 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
its/Blaise-Boscaccy/security-Hornet-LSM/20250405-055741
base:
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git next
patch link:
https://lore.kernel.org/r/20250404215527.1563146-2-bboscaccy%40linux.microsoft.com
patch subject: [PATCH v2 security-next 1/4] security: Hornet
its/Blaise-Boscaccy/security-Hornet-LSM/20250405-055741
base:
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git next
patch link:
https://lore.kernel.org/r/20250404215527.1563146-2-bboscaccy%40linux.microsoft.com
patch subject: [PATCH v2 security-next 1/4] security: Hornet
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 signature verification is light-skeleton based
eBPF programs
31 matches
Mail list logo
