> On Feb 24, 2021, at 12:03 AM, wanghongzhe wrote:
>
> As Kees haved accepted the v2 patch at a381b70a1 which just
> replaced rmb() with smp_rmb(), this patch will base on that and just adjust
> the smp_rmb() to the correct position.
>
> As the original comment shown (and indeed it should be)
> On Feb 1, 2021, at 4:06 AM, wanghongzhe wrote:
>
> If a thread(A)'s TSYNC flag is set from seccomp(), then it will
> synchronize its seccomp filter to other threads(B) in same thread
> group. To avoid race condition, seccomp puts rmb() between
> reading the mode and filter in seccomp check
> On Sep 22, 2020, at 2:01 AM, Arnd Bergmann wrote:
>
> On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov
> wrote:
>>> On 22/09/2020 10:23, Arnd Bergmann wrote:
>>> On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov
>>> wrote:
>>>> On 22/09/2
On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov wrote:
>
>
>
> On 22/09/2020 02:51, Andy Lutomirski wrote:
> > On Mon, Sep 21, 2020 at 9:15 AM Pavel Begunkov
> > wrote:
> >>
> >> On 21/09/2020 19:10, Pavel Begunkov wrote:
> >>> On 20/09/2020
On Mon, Sep 21, 2020 at 9:15 AM Pavel Begunkov wrote:
>
> On 21/09/2020 19:10, Pavel Begunkov wrote:
> > On 20/09/2020 01:22, Andy Lutomirski wrote:
> >>
> >>> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote:
> >>>
> >>> On Sat, Sep 1
If you're a 32-bit process, you don't get to use io_uring. Would
> any real users actually care about that?
We could go one step farther and declare that we're done adding *any*
new compat syscalls :)
--
Andy Lutomirski
AMA Capital Management, LLC
On Sun, Sep 20, 2020 at 11:07 AM Al Viro wrote:
>
> On Sun, Sep 20, 2020 at 04:15:10PM +0100, Matthew Wilcox wrote:
> > On Fri, Sep 18, 2020 at 02:45:25PM +0200, Christoph Hellwig wrote:
> > > Add a flag to force processing a syscall as a compat syscall. This is
> > > required so that in_compat_s
On Sat, Sep 19, 2020 at 7:57 PM Al Viro wrote:
>
> On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote:
>
> > > 2) have you counted the syscalls that do and do not need that?
> >
> > No.
>
> Might be illuminating...
>
> > > 3) how m
On Sat, Sep 19, 2020 at 4:24 PM Al Viro wrote:
>
> On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote:
>
> > > It would not be a win - most of the syscalls don't give a damn
> > > about 32bit vs. 64bit...
> >
> > Any reasonable implementa
> On Sep 19, 2020, at 3:41 PM, Al Viro wrote:
>
> On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote:
>>
>>>> On Sep 19, 2020, at 3:09 PM, Al Viro wrote:
>>>
>>> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
&
> On Sep 19, 2020, at 3:09 PM, Al Viro wrote:
>
> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>> Said that, why not provide a variant that would take an explicit
>>> "is it compat" argument and use it there?
> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote:
>
> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote:
>>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>>> Said that, wh
On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
>
> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > Said that, why not provide a variant that would take an explicit
> > "is it compat" argument and use it there? And have the normal
> > one pass in_compat_syscall() to that...
> On Aug 8, 2020, at 12:03 PM, George Spelvin wrote:
>
> On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>>> - Cryptographically strong ChaCha, batched
>>> - Cryptographically strong ChaCha, with anti-backtracking.
>>
>> I think w
> On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
>
> And apparently switching to the fastest secure PRNG currently
> in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> would cause too much performance penalty.
Can someone explain *why* the slow path latency is particularly r
> On Aug 7, 2020, at 12:57 PM, Linus Torvalds
> wrote:
>
> On Fri, Aug 7, 2020 at 12:33 PM Andy Lutomirski wrote:
>>
>> No one said we have to do only one ChaCha20 block per slow path hit.
>
> Sure, doing more might be better for amortizing the cost.
>
> On Aug 7, 2020, at 12:21 PM, Linus Torvalds
> wrote:
>
> On Fri, Aug 7, 2020 at 12:08 PM Andy Lutomirski wrote:
>> 4 cycles per byte on Core 2
>
> I took the reference C implementation as-is, and just compiled it with
> O2, so my numbers may not be what some
> On Aug 7, 2020, at 11:10 AM, Linus Torvalds
> wrote:
>
> On Fri, Aug 7, 2020 at 10:55 AM Andy Lutomirski wrote:
>>
>> I think the real random.c can run plenty fast. It’s ChaCha20 plus ludicrous
>> overhead right now.
>
> I doubt it.
>
> I t
>> On Aug 5, 2020, at 3:06 PM, ty...@mit.edu wrote:
>>
>> On Wed, Aug 05, 2020 at 09:06:40AM -0700, Marc Plumb wrote:
>> Isn't get_random_u32 the function you wrote to do that? If this needs to be
>> cryptographically secure, that's an existing option that's safe.
>> The fundamental question is
On Tue, Jul 21, 2020 at 10:43 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:473309fb net: dp83640: fix SIOCSHWTSTAMP to update the str..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=175443e710
> kernel config: htt
On Fri, Sep 6, 2019 at 4:10 PM Alexei Starovoitov wrote:
>
> Split BPF and perf/tracing operations that are allowed under
> CAP_SYS_ADMIN into corresponding CAP_BPF and CAP_TRACING.
> For backward compatibility include them in CAP_SYS_ADMIN as well.
>
> The end result provides simple safety model
On Thu, Aug 29, 2019 at 10:23 AM Alexei Starovoitov
wrote:
>
> On Thu, Aug 29, 2019 at 08:43:23AM -0700, Andy Lutomirski wrote:
> >
> > I can imagine splitting it into three capabilities:
> >
> > CAP_TRACE_KERNEL: learn which kernel functions are called when. This
> On Aug 29, 2019, at 8:47 AM, Daniel Borkmann wrote:
>
>> On 8/29/19 7:12 AM, Alexei Starovoitov wrote:
>> [...]
>> +/*
>> + * CAP_BPF allows the following BPF operations:
>> + * - Loading all types of BPF programs
>> + * - Creating all types of BPF maps except:
>> + *- stackmap that needs C
On Thu, Aug 29, 2019 at 6:34 AM Steven Rostedt wrote:
>
> On Wed, 28 Aug 2019 15:08:28 -0700
> Alexei Starovoitov wrote:
>
> > On Wed, Aug 28, 2019 at 09:14:21AM +0200, Peter Zijlstra wrote:
> > > On Tue, Aug 27, 2019 at 04:01:08PM -0700, Andy Lutomirski wro
> On Aug 28, 2019, at 4:38 PM, Alexei Starovoitov
> wrote:
>
>> On Tue, Aug 27, 2019 at 11:20:19PM -0700, Andy Lutomirski wrote:
>> On Tue, Aug 27, 2019 at 9:49 PM Alexei Starovoitov
>> wrote:
>>>
>>>> On Tue, Aug 27, 2019 at 07:00:40PM -07
> On Aug 28, 2019, at 5:45 PM, Andy Lutomirski wrote:
>
>
>>> On Aug 28, 2019, at 3:55 PM, Alexei Starovoitov
>>> wrote:
>>>
>>> On Tue, Aug 27, 2019 at 11:12:29PM -0700, Andy Lutomirski wrote:
>>>>>
>>>>>
&
> On Aug 28, 2019, at 3:55 PM, Alexei Starovoitov
> wrote:
>
>> On Tue, Aug 27, 2019 at 11:12:29PM -0700, Andy Lutomirski wrote:
>>>>
>>>>
>>>> From the previous discussion, you want to make progress toward solving
>>>&
On Tue, Aug 27, 2019 at 9:49 PM Alexei Starovoitov
wrote:
>
> On Tue, Aug 27, 2019 at 07:00:40PM -0700, Andy Lutomirski wrote:
> >
> > Let me put this a bit differently. Part of the point is that
> > CAP_TRACING should allow a user or program to trace without being able
&
On Tue, Aug 27, 2019 at 9:43 PM Alexei Starovoitov
wrote:
>
> On Tue, Aug 27, 2019 at 05:55:41PM -0700, Andy Lutomirski wrote:
> >
> > I was hoping for something in Documentation/admin-guide, not in a
> > changelog that's hard to find.
>
> eventually yes.
>
> On Aug 27, 2019, at 5:55 PM, Andy Lutomirski wrote:
>
> On Tue, Aug 27, 2019 at 5:34 PM Alexei Starovoitov
> wrote:
>>
> From the previous discussion, you want to make progress toward solving
> a lot of problems with CAP_BPF. One of them was making BPF
> firewallin
> On Aug 27, 2019, at 5:44 PM, Steven Rostedt wrote:
>
> On Tue, 27 Aug 2019 16:34:47 -0700
> Andy Lutomirski wrote:
>
>>>> CAP_TRACING does not override normal permissions on sysfs or debugfs.
>>>> This means that, unless a new interface for program
On Tue, Aug 27, 2019 at 5:34 PM Alexei Starovoitov
wrote:
>
> On Tue, Aug 27, 2019 at 04:01:08PM -0700, Andy Lutomirski wrote:
> > [adding some security and tracing folks to cc]
> >
> > On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov wrote:
> > >
> >
On Tue, Aug 27, 2019 at 4:21 PM Steven Rostedt wrote:
>
> On Tue, 27 Aug 2019 16:01:08 -0700
> Andy Lutomirski wrote:
>
> > [adding some security and tracing folks to cc]
> >
> > On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov wrote:
> > >
> >
[adding some security and tracing folks to cc]
On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov wrote:
>
> Introduce CAP_BPF that allows loading all types of BPF programs,
> create most map types, load BTF, iterate programs and maps.
> CAP_BPF alone is not enough to attach or run programs.
>
>
> On Aug 26, 2019, at 3:36 PM, Alexei Starovoitov
> wrote:
>
>> On Fri, Aug 23, 2019 at 04:09:11PM -0700, Andy Lutomirski wrote:
>> On Thu, Aug 22, 2019 at 4:26 PM Alexei Starovoitov
>> wrote:
>>> You're proposing all of the above in addition to CAP_BPF
On Thu, Aug 22, 2019 at 4:26 PM Alexei Starovoitov
wrote:
> You're proposing all of the above in addition to CAP_BPF, right?
> Otherwise I don't see how it addresses the use cases I kept
> explaining for the last few weeks.
None of my proposal is intended to exclude changes like CAP_BPF to
make p
BPF security strawman, v0.1
This is very rough. Most of this, especially the API details, needs
work before it's ready to implement. The whole concept also needs
review.
= Goals =
The overall goal is to make it possible to use eBPF without having
what is effectively administrator access. For
On Thu, Aug 22, 2019 at 7:17 AM Daniel Borkmann wrote:
>
> On 8/7/19 7:24 AM, Andy Lutomirski wrote:
> > On Mon, Aug 5, 2019 at 6:11 PM Alexei Starovoitov
> > wrote:
> >> On Mon, Aug 05, 2019 at 02:25:35PM -0700, Andy Lutomirski wrote:
> >>> It tries to m
> On Aug 19, 2019, at 10:27 AM, Alexei Starovoitov
> wrote:
>
>> On Mon, Aug 19, 2019 at 11:15:11AM +0200, Thomas Gleixner wrote:
>> Alexei,
>>
>>> On Sat, 17 Aug 2019, Alexei Starovoitov wrote:
On Fri, Aug 16, 2019 at 10:28:29PM +0200, Thomas Gleixner wrote:
On Fri, 16 Aug 2019, A
> On Aug 17, 2019, at 8:02 AM, Alexei Starovoitov
> wrote:
>
> Can any of the mechanisms 1/2/3 address the concern in mds.rst?
>
seccomp() can. It’s straightforward to use seccomp to disable bpf() outright
for a process tree. In this regard, bpf() isn’t particularly unique — it’s a
syst
> On Aug 15, 2019, at 4:46 PM, Alexei Starovoitov
> wrote:
>>
>> I'm not sure why you draw the line for VMs -- they're just as buggy
>> as anything else. Regardless, I reject this line of thinking: yes,
>> all software is buggy, but that isn't a reason to give up.
>
> hmm. are you saying y
On Thu, Aug 15, 2019 at 10:29 AM Alexei Starovoitov
wrote:
>
> On Thu, Aug 15, 2019 at 11:24:54AM +, Jordan Glover wrote:
> > systemd --user processes aren't "less privileged". The are COMPLETELY
> > unprivileged.
> > Granting them cap_bpf is the same as granting it to every other
> > unpriv
> On Aug 14, 2019, at 4:33 PM, Alexei Starovoitov
> wrote:
>
>> On Wed, Aug 14, 2019 at 03:30:51PM -0700, Andy Lutomirski wrote:
>>
>>
>>>> On Aug 14, 2019, at 3:05 PM, Alexei Starovoitov
>>>> wrote:
>>>>
>&
> On Aug 14, 2019, at 3:05 PM, Alexei Starovoitov
> wrote:
>
>> On Wed, Aug 14, 2019 at 10:51:23AM -0700, Andy Lutomirski wrote:
>>
>> If eBPF is genuinely not usable by programs that are not fully trusted
>> by the admin, then no kernel changes at all are
On Tue, Aug 13, 2019 at 5:57 PM Alexei Starovoitov
wrote:
> hmm. No. Kernel developers should not make any assumptions.
> They should guide their design by real use cases instead. That includes
> studing
> what people do now and hacks they use to workaround lack of interfaces.
> Effecitvely bpf
On Tue, Aug 13, 2019 at 3:27 PM Daniel Colascione wrote:
>
> On Tue, Aug 13, 2019 at 2:58 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, Aug 06, 2019 at 10:24:25PM -0700, Andy Lutomirski wrote:
> > > >
> > > > Inside containers and inside nested c
On Tue, Aug 13, 2019 at 2:58 PM Alexei Starovoitov
wrote:
>
> On Tue, Aug 06, 2019 at 10:24:25PM -0700, Andy Lutomirski wrote:
> > >
> > > Inside containers and inside nested containers we need to start processes
> > > that will use bpf. All of the processes are
> On Aug 7, 2019, at 2:03 AM, Lorenz Bauer wrote:
>
>> On Wed, 7 Aug 2019 at 06:24, Andy Lutomirski wrote:
>> a) Those that, by design, control privileged operations. This
>> includes most attach calls, but it also includes allow_ptr_leaks,
>> bpf_probe_read()
On Mon, Aug 5, 2019 at 6:11 PM Alexei Starovoitov
wrote:
>
> On Mon, Aug 05, 2019 at 02:25:35PM -0700, Andy Lutomirski wrote:
> > It tries to make the kernel respect the access modes for fds. Without
> > this patch, there seem to be some holes: nothing looked at program fds
> On Aug 5, 2019, at 2:25 PM, Andy Lutomirski wrote:
>
> On Mon, Aug 5, 2019 at 12:21 PM Alexei Starovoitov
> wrote:
>
>> What we need is to drop privileges sooner in daemons like systemd.
>
> This is doable right now: systemd could fork off a subproces
On Mon, Aug 5, 2019 at 12:21 PM Alexei Starovoitov
wrote:
>
> On Mon, Aug 05, 2019 at 10:23:10AM -0700, Andy Lutomirski wrote:
> >
> > I refreshed the branch again. I had a giant hole in my previous idea
> > that we could deprivilege program loading: some BPF functions ne
On Mon, Aug 5, 2019 at 12:37 AM Song Liu wrote:
>
> Hi Andy,
>
> >
> > # mount -t bpf bpf /sys/fs/bpf
> > # cd /sys/fs/bpf
> > # mkdir luto
> > # chown luto: luto
> > # setpriv --euid=1000 --ruid=1000 bash
> > $ pwd
> > /sys/fs/bpf
> > bash-5.0$ ls -l
> > total 0
> > drwxr-xr-x 2 luto luto 0 Aug
On Sun, Aug 4, 2019 at 5:08 PM Andy Lutomirski wrote:
>
> On Sun, Aug 4, 2019 at 3:16 PM Andy Lutomirski wrote:
> >
> > On Fri, Aug 2, 2019 at 12:22 AM Song Liu wrote:
> > >
> > > Hi Andy,
> > >
> > >> I actually agree CAP_BPF_ADMIN make
On Sun, Aug 4, 2019 at 3:16 PM Andy Lutomirski wrote:
>
> On Fri, Aug 2, 2019 at 12:22 AM Song Liu wrote:
> >
> > Hi Andy,
> >
> >> I actually agree CAP_BPF_ADMIN makes sense. The hard part is to make
> > >> existing tools (setcap, get
On Fri, Aug 2, 2019 at 12:22 AM Song Liu wrote:
>
> Hi Andy,
>
>> I actually agree CAP_BPF_ADMIN makes sense. The hard part is to make
> >> existing tools (setcap, getcap, etc.) and libraries aware of the new CAP.
> >
> > It's been done before -- it's not that hard. IMO the main tricky bit
> > w
On Wed, Jul 31, 2019 at 1:10 AM Song Liu wrote:
>
>
>
> > On Jul 30, 2019, at 1:24 PM, Andy Lutomirski wrote:
> >
> > On Mon, Jul 29, 2019 at 10:07 PM Song Liu wrote:
> >>
> >> Hi Andy,
> >>
> >>>
On Mon, Jul 29, 2019 at 10:07 PM Song Liu wrote:
>
> Hi Andy,
>
> > On Jul 27, 2019, at 11:20 AM, Song Liu wrote:
> >
> > Hi Andy,
> >
> >
>
> Well, yes. sys_bpf() is pretty powerful.
>
> The goal of /dev/bpf is to enable special users to call sys_bpf(). In
> the mean
On Sat, Jul 27, 2019 at 11:20 AM Song Liu wrote:
>
> Hi Andy,
>
>
> >>>
> >>> Well, yes. sys_bpf() is pretty powerful.
> >>>
> >>> The goal of /dev/bpf is to enable special users to call sys_bpf(). In
> >>> the meanwhile, such users should not take down the whole system easily
> >>> by accide
> On Jul 23, 2019, at 3:56 PM, Song Liu wrote:
>
>
>
>> On Jul 23, 2019, at 8:11 AM, Andy Lutomirski wrote:
>>
>> On Mon, Jul 22, 2019 at 1:54 PM Song Liu wrote:
>>>
>>> Hi Andy, Lorenz, and all,
>>>
>>>> On Jul
On Mon, Jul 22, 2019 at 1:54 PM Song Liu wrote:
>
> Hi Andy, Lorenz, and all,
>
> > On Jul 2, 2019, at 2:32 PM, Andy Lutomirski wrote:
> >
> > On Tue, Jul 2, 2019 at 2:04 PM Kees Cook wrote:
> >>
> >> On Mon, Jul 01, 2019 at 06:59:13PM -0
On Tue, Jul 2, 2019 at 2:04 PM Kees Cook wrote:
>
> On Mon, Jul 01, 2019 at 06:59:13PM -0700, Andy Lutomirski wrote:
> > I think I'm understanding your motivation. You're not trying to make
> > bpf() generically usable without privilege -- you're trying to create
On Mon, Jul 1, 2019 at 2:03 AM Song Liu wrote:
>
> Hi Andy,
>
> Thanks for these detailed analysis.
>
> > On Jun 30, 2019, at 8:12 AM, Andy Lutomirski wrote:
> >
> > On Fri, Jun 28, 2019 at 12:05 PM Song Liu wrote:
> >>
> >> Hi Andy,
>
On Fri, Jun 28, 2019 at 12:05 PM Song Liu wrote:
>
> Hi Andy,
>
> > On Jun 27, 2019, at 4:40 PM, Andy Lutomirski wrote:
> >
> > On 6/27/19 1:19 PM, Song Liu wrote:
> >> This patch introduce unprivileged BPF access. The access control is
> >> achieved
[sigh, I finally set up lore nntp, and I goofed some addresses. Hi
Kees and linux-api.]
On Thu, Jun 27, 2019 at 4:40 PM Andy Lutomirski wrote:
>
> On 6/27/19 1:19 PM, Song Liu wrote:
> > This patch introduce unprivileged BPF access. The access control is
> > achieved via devi
On 6/27/19 1:19 PM, Song Liu wrote:
This patch introduce unprivileged BPF access. The access control is
achieved via device /dev/bpf. Users with write access to /dev/bpf are able
to call sys_bpf().
Two ioctl command are added to /dev/bpf:
The two commands enable/disable permission to call sys_b
> On May 16, 2019, at 8:25 PM, Felipe wrote:
>
> Author: Felipe Gasper
> Date: Thu May 16 12:16:53 2019 -0500
>
>Add UNIX_DIAG_UID to Netlink UNIX socket diagnostics.
>
>This adds the ability for Netlink to report a socket’s UID along with the
>other UNIX socket diagnostic informati
On Sat, Feb 23, 2019 at 12:30 AM Nadav Amit wrote:
>
> > On Feb 22, 2019, at 3:59 PM, Andy Lutomirski wrote:
> >
> > On Fri, Feb 22, 2019 at 3:02 PM Jann Horn wrote:
> >> On Fri, Feb 22, 2019 at 11:39 PM Nadav Amit wrote:
> >>>> On Feb 22, 2019, at
Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
> > >>>> On Feb 22, 2019, at 1:43 PM, Jann Horn wrote:
> > >>>>
> > >>>> (adding some people from the text_poke series to the thread, removing
> > >>>> stable@)
> > &
> On Feb 22, 2019, at 11:34 AM, Alexei Starovoitov
> wrote:
>
>> On Fri, Feb 22, 2019 at 02:30:26PM -0500, Steven Rostedt wrote:
>> On Fri, 22 Feb 2019 11:27:05 -0800
>> Alexei Starovoitov wrote:
>>
On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
Then we shou
On Thu, Feb 21, 2019 at 2:14 PM Kees Cook wrote:
>
> On Thu, Feb 21, 2019 at 12:36 PM Alexei Starovoitov
> wrote:
> > I also would like to touch on your comment:
> > "A lot of changes will be needed for seccomp ebpf"
> > There were two attempts to add it in the past and the patches were
> > small
On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
>
> On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > - Once we get to 512, we clash with the x32 numbers (unless
> > > we remove x32 suppor
On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
>
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This g
> On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel wrote:
>
>> On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote:
>>
>> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
>> wrote:
>>>
>>> This adds two new flags VM_IMMEDIATE_UNMAP and VM_HAS_SPE
On Mon, Dec 17, 2018 at 4:24 PM Edgecombe, Rick P
wrote:
>
> On Sat, 2018-12-15 at 10:52 -0800, Andy Lutomirski wrote:
> > On Wed, Dec 12, 2018 at 2:01 PM Edgecombe, Rick P
> > wrote:
> > >
> > > On Wed, 2018-12-12 at 11:57 -0800, Andy Lutomirski wrote:
>
On Wed, Dec 12, 2018 at 2:01 PM Edgecombe, Rick P
wrote:
>
> On Wed, 2018-12-12 at 11:57 -0800, Andy Lutomirski wrote:
> > On Wed, Dec 12, 2018 at 11:50 AM Edgecombe, Rick P
> > wrote:
> > >
> > > On Tue, 2018-12-11 at 18:20 -0800, Andy Lutomirski wrote:
>
On Wed, Dec 12, 2018 at 11:50 AM Edgecombe, Rick P
wrote:
>
> On Tue, 2018-12-11 at 18:20 -0800, Andy Lutomirski wrote:
> > On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> > wrote:
> > >
> > > This adds two new flags VM_IMMEDIATE_UNMAP and VM_HAS_SPE
pages_np are made non-static
> and
> renamed set_pages_p_noflush and set_pages_np_noflush to better communicate
> their different (non-flushing) behavior from the rest of the set_pages_*
> functions.
>
> The method for doing this with only 1 TLB flush was suggested by Andy
> Lut
is just
> centralized here.
>
> This implementation derives from two sketches from Dave Hansen and Andy
> Lutomirski.
>
> Suggested-by: Dave Hansen
> Suggested-by: Andy Lutomirski
> Suggested-by: Will Deacon
> Signed-off-by: Rick Edgec
On Thu, Dec 6, 2018 at 12:20 PM Edgecombe, Rick P
wrote:
>
> On Thu, 2018-12-06 at 11:19 -0800, Andy Lutomirski wrote:
> > On Thu, Dec 6, 2018 at 11:01 AM Tycho Andersen wrote:
> > >
> > > On Thu, Dec 06, 2018 at 10:53:50AM -0800, Andy Lutomirski wrote:
> >
On Thu, Dec 6, 2018 at 11:39 AM Nadav Amit wrote:
>
> > On Dec 6, 2018, at 11:19 AM, Andy Lutomirski wrote:
> >
> > On Thu, Dec 6, 2018 at 11:01 AM Tycho Andersen wrote:
> >> On Thu, Dec 06, 2018 at 10:53:50AM -0800, Andy Lutomirski wrote:
> >>>> I
On Thu, Dec 6, 2018 at 11:04 AM Ard Biesheuvel
wrote:
>
> On Thu, 6 Dec 2018 at 19:54, Andy Lutomirski wrote:
> >
> > That’s not totally nuts. Do we ever have code that expects __va() to
> > work on module data? Perhaps crypto code trying to encrypt static
> &g
On Thu, Dec 6, 2018 at 11:01 AM Tycho Andersen wrote:
>
> On Thu, Dec 06, 2018 at 10:53:50AM -0800, Andy Lutomirski wrote:
> > > If we are going to unmap the linear alias, why not do it at vmalloc()
> > > time rather than vfree() time?
> >
> > That’s not tot
> On Dec 5, 2018, at 11:29 PM, Ard Biesheuvel wrote:
>
>> On Thu, 6 Dec 2018 at 00:16, Andy Lutomirski wrote:
>>
>>> On Wed, Dec 5, 2018 at 3:41 AM Will Deacon wrote:
>>>
>>>> On Tue, Dec 04, 2018 at 12:09:49PM -0800, Andy Lutomirski wrote:
>&g
On Wed, Dec 5, 2018 at 3:41 AM Will Deacon wrote:
>
> On Tue, Dec 04, 2018 at 12:09:49PM -0800, Andy Lutomirski wrote:
> > On Tue, Dec 4, 2018 at 12:02 PM Edgecombe, Rick P
> > wrote:
> > >
> > > On Tue, 2018-12-04 at 16:03 +, Will Deacon wrote:
> &
> On Dec 4, 2018, at 3:52 PM, Edgecombe, Rick P
> wrote:
>
>> On Tue, 2018-12-04 at 12:09 -0800, Andy Lutomirski wrote:
>> On Tue, Dec 4, 2018 at 12:02 PM Edgecombe, Rick P
>> wrote:
>>>
>>>> On Tue, 2018-12-04 at 16:03 +, Will Deaco
On Dec 4, 2018, at 2:48 PM, Nadav Amit wrote:
>> On Dec 4, 2018, at 11:48 AM, Andy Lutomirski wrote:
>>
>> On Tue, Dec 4, 2018 at 11:45 AM Nadav Amit wrote:
>>>> On Dec 4, 2018, at 10:56 AM, Andy Lutomirski wrote:
>>>>
>>>> On Mon, D
On Tue, Dec 4, 2018 at 12:02 PM Edgecombe, Rick P
wrote:
>
> On Tue, 2018-12-04 at 16:03 +, Will Deacon wrote:
> > On Mon, Dec 03, 2018 at 05:43:11PM -0800, Nadav Amit wrote:
> > > > On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> > > > wrote:
> > > >
> > > > Since vfree will lazily flush the T
On Tue, Dec 4, 2018 at 11:45 AM Nadav Amit wrote:
>
> > On Dec 4, 2018, at 10:56 AM, Andy Lutomirski wrote:
> >
> > On Mon, Dec 3, 2018 at 5:43 PM Nadav Amit wrote:
> >>> On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> >>> wrote:
> >>>
&g
On Mon, Dec 3, 2018 at 5:43 PM Nadav Amit wrote:
>
> > On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> > wrote:
> >
> > Since vfree will lazily flush the TLB, but not lazily free the underlying
> > pages,
> > it often leaves stale TLB entries to freed pages that could get re-used.
> > This is
>
> On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> wrote:
>
> Change the module allocations to flush before freeing the pages.
>
> Signed-off-by: Rick Edgecombe
> ---
> arch/x86/kernel/module.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/module.c b/ar
> On Sep 27, 2018, at 8:19 AM, Jason A. Donenfeld wrote:
>
> Hey again Thomas,
>
>> On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote:
>>
>> Hi Thomas,
>>
>> I'm trying to optimize this for crypto performance while still taking
>> into account preemption concerns. I'm having a bit o
On Tue, Sep 11, 2018 at 4:57 PM David Miller wrote:
>
> From: Andrew Lunn
> Date: Wed, 12 Sep 2018 01:30:15 +0200
>
> > Just as an FYI:
> >
> > 1) I don't think anybody in netdev has taken a serious look at the
> > network code yet. There is little point until the controversial part
> > of the co
At the risk of further muddying the waters, there's another minor tweak
that could improve performance on certain workloads. Currently you mmap()
a range for a given socket and then getsockopt() to receive. If you made
it so you could mmap() something once for any number of sockets (by
mmapping /
ements
>> >> the transfert of pages from skbs to one VMA.
>> >> This operation only uses down_read(¤t->mm->mmap_sem) after
>> >> holding TCP lock, thus solving the lockdep issue.
>> >>
>> >> This new implementation was suggeste
On Mon, Apr 23, 2018 at 2:38 PM, Eric Dumazet wrote:
> Hi Andy
>
> On 04/23/2018 02:14 PM, Andy Lutomirski wrote:
>> I would suggest that you rework the interface a bit. First a user would
>> call mmap() on a TCP socket, which would create an empty VMA. (It would set
On 04/20/2018 08:55 AM, Eric Dumazet wrote:
This patch series provide a new mmap_hook to fs willing to grab
a mutex before mm->mmap_sem is taken, to ensure lockdep sanity.
This hook allows us to shorten tcp_mmap() execution time (while mmap_sem
is held), and improve multi-threading scalability.
On Sun, Apr 8, 2018 at 6:13 AM, Mickaël Salaün wrote:
>
> On 02/27/2018 10:48 PM, Mickaël Salaün wrote:
>>
>> On 27/02/2018 17:39, Andy Lutomirski wrote:
>>> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov
>>> wrote:
>>>> On Tue, Feb 27,
On Thu, Mar 22, 2018 at 8:54 PM, Luis R. Rodriguez wrote:
> If we can ensure that these usermode modules don't take *any time at all* on
> their init *from the start*, it would be wonderful and we'd end up avoiding
> some really odd corner case issues later.
>
I don't see why this issue needs to
On Thu, Mar 22, 2018 at 5:40 PM, Alexei Starovoitov
wrote:
> On Thu, Mar 22, 2018 at 10:33:43AM +0100, Ingo Molnar wrote:
>>
>> - I think the BPF JIT, whose byte code machine languge is used by an
>>increasing number of kernel subsystems, could benefit from having vector
>> ops.
>>It wou
On Wed, Mar 21, 2018 at 6:32 AM, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
>> And even if you ignore that "maintenance problems down the line" issue
>> ("we can fix them when they happen") I don't want to see games like
>> this, because I'm pretty sure it breaks the optimized xsave by tagg
1 - 100 of 375 matches
Mail list logo
