From: Hannes Frederic Sowa
Date: Tue, 2 Sep 2014 22:53:44 +0200
> From: Daniel Borkmann
>
> With eBPF getting more extended and exposure to user space is on it's way,
> hardening the memory range the interpreter uses to steer its command flow
> seems appropriate. This patch moves the to be in
On Tue, Sep 2, 2014 at 2:43 PM, Hannes Frederic Sowa
wrote:
> On Tue, Sep 2, 2014, at 23:40, Eric Dumazet wrote:
>> On Tue, 2014-09-02 at 14:31 -0700, Alexei Starovoitov wrote:
>>
>> > > +static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
>> > > +{
>> > > + set_memory_rw((unsigned lo
On 09/02/2014 11:31 PM, Alexei Starovoitov wrote:
...
+#ifdef CONFIG_DEBUG_SET_MODULE_RONX
+static inline void bpf_prog_lock_ro(struct bpf_prog *fp)
+{
+ set_memory_ro((unsigned long)fp, fp->pages);
since ronx are ifdef checked together,
would probably make sense to set nx too?
In case
On Tue, Sep 2, 2014, at 23:40, Eric Dumazet wrote:
> On Tue, 2014-09-02 at 14:31 -0700, Alexei Starovoitov wrote:
>
> > > +static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
> > > +{
> > > + set_memory_rw((unsigned long)fp, fp->pages);
> >
> > why rw is needed?
> > since fp is alloc
On Tue, 2014-09-02 at 14:31 -0700, Alexei Starovoitov wrote:
> > +static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
> > +{
> > + set_memory_rw((unsigned long)fp, fp->pages);
>
> why rw is needed?
> since fp is allocated with vmalloc, vfree doesn't need
> to touch the pages to free
On Tue, Sep 2, 2014, at 23:31, Alexei Starovoitov wrote:
> On Tue, Sep 2, 2014 at 1:53 PM, Hannes Frederic Sowa
> wrote:
> > From: Daniel Borkmann
> >
> > With eBPF getting more extended and exposure to user space is on it's way,
> > hardening the memory range the interpreter uses to steer its co
On Tue, Sep 2, 2014 at 1:53 PM, Hannes Frederic Sowa
wrote:
> From: Daniel Borkmann
>
> With eBPF getting more extended and exposure to user space is on it's way,
> hardening the memory range the interpreter uses to steer its command flow
> seems appropriate. This patch moves the to be interpret
From: Daniel Borkmann
With eBPF getting more extended and exposure to user space is on it's way,
hardening the memory range the interpreter uses to steer its command flow
seems appropriate. This patch moves the to be interpreted bytecode to
read-only pages.
In case we execute a corrupted BPF in
8 matches
Mail list logo
