> 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 2:21 PM, Nadav Amit wrote:
>>>>
>>>>> On Feb 22, 2
> On 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 2:21 PM, Nadav Amit wrote:
>>>
>>>> On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
>>>>
>>>> On Fr
> On Feb 22, 2019, at 2:21 PM, Nadav Amit wrote:
>
>> On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
>>
>> On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
>>>> On Feb 22, 2019, at 1:43 PM, Jann Horn wrote:
>>>>
>>>> (adding s
> On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
>
> On 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 1:43 PM, Jann Horn wrote:
>
> (adding some people from the text_poke series to the thread, removing stable@)
>
> On Fri, Feb 22, 2019 at 8:55 PM Andy Lutomirski wrote:
>>> On Feb 22, 2019, at 11:34 AM, Alexei Starovoitov
>>> wrote:
On Fri, Feb 22, 2019 at 02:30:26PM
> On Dec 13, 2018, at 11:02 AM, Edgecombe, Rick P
> wrote:
>
> On Wed, 2018-12-12 at 23:40 +, Nadav Amit wrote:
>>> On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
>>> wrote:
>>>
>>> Add new flags for handling freeing of special permissioned me
> On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
> wrote:
>
> Add new flags for handling freeing of special permissioned memory in vmalloc,
> and remove places where the handling was done in module.c.
>
> This will enable this flag for all architectures.
>
> Signed-off-by: Rick Edgecombe
> ---
>
> On Dec 12, 2018, at 1:05 PM, Edgecombe, Rick P
> wrote:
>
> On Wed, 2018-12-12 at 06:30 +, Nadav Amit wrote:
>>> On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
>>> wrote:
>>>
>>> This adds a more efficient x86 architecture specific implement
> On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
> wrote:
>
> This adds a more efficient x86 architecture specific implementation of
> arch_vunmap, that can free any type of special permission memory with only 1
> TLB
> flush.
>
> In order to enable this, _set_pages_p and _set_pages_np are made n
> On Dec 6, 2018, at 12:17 PM, 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, D
> 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:
If we are going to unmap the linear alias, why not do it at vmalloc()
time rather than vfree() time?
>>>
> On Dec 4, 2018, at 5:45 PM, Edgecombe, Rick P
> wrote:
>
> On Tue, 2018-12-04 at 16:53 -0800, Nadav Amit wrote:
>>> On Dec 4, 2018, at 4:29 PM, Edgecombe, Rick P
>>> wrote:
>>>
>>> On Tue, 2018-12-04 at 16:01 -0800, Nadav Amit wrote:
>
> On Dec 4, 2018, at 5:09 PM, Edgecombe, Rick P
> wrote:
>
> On Tue, 2018-12-04 at 14:48 -0800, 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:
>>>>&g
> On Dec 4, 2018, at 4:29 PM, Edgecombe, Rick P
> wrote:
>
> On Tue, 2018-12-04 at 16:01 -0800, Nadav Amit wrote:
>>> On Dec 4, 2018, at 3:51 PM, Edgecombe, Rick P
>>> wrote:
>>>
>>> On Tue, 2018-12-04 at 12:36 -0800, Nadav Amit wrote:
>
> On Dec 4, 2018, at 3:51 PM, Edgecombe, Rick P
> wrote:
>
> On Tue, 2018-12-04 at 12:36 -0800, Nadav Amit wrote:
>>> On 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:27 PM, Andy Lutomirski wrote:
>
>
>
>
> 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 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, Dec 3, 2018 at 5:43 PM Nadav Amit wrote:
>>>>> On Nov
> On 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:
>>>
> 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:
>>>
>>> Since vfree will lazily flush the TLB, but not lazily free the underly
In other words: disable_ro_nx() is called by free_module() before freeing
the memory. Wouldn’t inverting the logic makes much more sense? I am
confused.
-- >8 --
From: Nadav Amit
Subject: [PATCH] modules: disable_ro_nx() should enable nx
---
kernel/module.c | 5 ++---
1 file changed, 2 insert
> On Nov 28, 2018, at 1:57 AM, Will Deacon wrote:
>
> On Tue, Nov 27, 2018 at 05:21:08PM -0800, Nadav Amit wrote:
>>> On Nov 27, 2018, at 5:06 PM, Nadav Amit wrote:
>>>
>>>> On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
>>>> wrote:
>&
> On Nov 27, 2018, at 5:06 PM, Nadav Amit wrote:
>
>> On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
>> wrote:
>>
>> Sometimes when memory is freed via the module subsystem, an executable
>> permissioned TLB entry can remain to a freed page. If the page is re-
> On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> wrote:
>
> Sometimes when memory is freed via the module subsystem, an executable
> permissioned TLB entry can remain to a freed page. If the page is re-used to
> back an address that will receive data from userspace, it can result in user
> data b
Edward Cree via iovisor-dev wrote:
> I managed to come up with a test for the swapped bounds in BPF_SUB, so here
> it is along with a patch that fixes it, separated out from my 'rewrite
> everything' series so it can go to -stable.
>
> Edward Cree (2):
> selftests/bpf: subtraction bounds test
>
Edward Cree wrote:
> On 07/07/17 18:45, Nadav Amit wrote:
>> For me changes such as:
>>
>>> if (dst_reg->min_value != BPF_REGISTER_MIN_RANGE)
>>> - dst_reg->min_value -= min_val;
>>> + dst_reg->min_value -
Nadav Amit wrote:
> Edward Cree wrote:
>
>> On 06/07/17 22:21, Nadav Amit wrote:
>>> I find it a bit surprising that such huge changes that can affect security
>>> and robustness are performed in one patch.
>> In the first version of the series, this was t
Edward Cree wrote:
> On 06/07/17 22:21, Nadav Amit wrote:
>> I find it a bit surprising that such huge changes that can affect security
>> and robustness are performed in one patch.
> In the first version of the series, this was two patches, with "feed
> pointer-to
Edward Cree via iovisor-dev wrote:
> Tracks value alignment by means of tracking known & unknown bits.
> Tightens some min/max value checks and fixes a couple of bugs therein.
> If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES,
> treat the pointer as an unknown scalar and
28 matches
Mail list logo
