On Thu, 2018-06-21 at 14:32 +0200, Jann Horn wrote:
> On Thu, Jun 21, 2018 at 12:12 AM Rick Edgecombe
> wrote:
> >
> > Add debugfs file "modfraginfo" for providing info on module space
> > fragmentation. This can be used for determining if loadable module
> > randomization is causing any
On Wed, 2018-06-20 at 15:33 -0700, Kees Cook wrote:
> > The new __vmalloc_node_try_addr function uses the existing function
> > __vmalloc_node_range, in order to introduce this algorithm with the
> > least
> > invasive change. The side effect is that each time there is a
> > collision when
> >
On Wed, 2018-06-20 at 15:26 -0700, Matthew Wilcox wrote:
> Not needed:
>
> void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char
> *fmt, ...)
> {
> ...
> if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(_rs))
> return;
>
Yes, thanks!
On Thu, 2018-06-21 at 15:37 +0200, Jann Horn wrote:
> On Thu, Jun 21, 2018 at 12:34 AM Kees Cook
> wrote:
> > And most systems have <200 modules, really. I have 113 on a desktop
> > right now, 63 on a server. So this looks like a trivial win.
> But note that the eBPF JIT also uses module_alloc().
Forgot to include this:
Reviewed-by: Kees Cook
On Mon, 2018-10-01 at 14:38 -0700, Rick Edgecombe wrote:
> Create __vmalloc_node_try_addr function that tries to allocate at a specific
> address and supports caller specified behavior for whether any lazy purging
> happens if there is a collision.
For a previous version before making asked for corrections, this was:
Reviewed-by: Kees Cook
On Mon, 2018-10-01 at 14:38 -0700, Rick Edgecombe wrote:
> Add debugfs file "modfraginfo" for providing info on module space
> fragmentation.
> This can be used for determining if loadable module
On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 1:40 AM Rick Edgecombe
> wrote:
> > This introduces a new rlimit, RLIMIT_MODSPACE, which limits the amount of
> > module space a user can use. The intention is to be able to limit module
> > space
> > allocations that
On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> +++ Dave Hansen [11/10/18 16:47 -0700]:
> > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > + if (check_inc_mod_rlimit(size))
> > > + return NULL;
> > > +
> > > p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> >
On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> wrote:
> > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > Why all the rbtree stuff instead of stashing a pointer in struct
> > > vmap_area, or somet
On Fri, 2018-10-12 at 22:01 +, Edgecombe, Rick P wrote:
> On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> > +++ Dave Hansen [11/10/18 16:47 -0700]:
> > > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > > + if (check_inc_mod_rlimit(size))
>
On Sat, 2018-10-20 at 19:20 +0200, Ard Biesheuvel wrote:
> Hi Rick,
>
> On 19 October 2018 at 22:47, Rick Edgecombe
> wrote:
> > If BPF JIT is on, there is no effective limit to prevent filling the entire
> > module space with JITed e/BPF filters.
>
> Why do BPF filters use the module space,
On Tue, 2018-11-06 at 13:04 -0800, Andrew Morton wrote:
> On Fri, 2 Nov 2018 12:25:16 -0700 Rick Edgecombe
> wrote:
>
> > This is V8 of the "KASLR feature to randomize each loadable module"
> > patchset.
> > The purpose is to increase the randomization and also to make the modules
> >
On Tue, 2018-11-06 at 13:05 -0800, Andrew Morton wrote:
> On Fri, 2 Nov 2018 12:25:17 -0700 Rick Edgecombe
> wrote:
>
> > Create __vmalloc_node_try_addr function that tries to allocate at a specific
> > address without triggering any lazy purging. In order to support this
> > behavior
> > a
On Tue, 2018-11-06 at 13:05 -0800, Andrew Morton wrote:
> On Fri, 2 Nov 2018 12:25:18 -0700 Rick Edgecombe
> wrote:
>
> > This changes the behavior of the KASLR logic for allocating memory for the
> > text
> > sections of loadable modules. It randomizes the location of each module text
> >
On Tue, 2018-11-06 at 13:05 -0800, Andrew Morton wrote:
> On Fri, 2 Nov 2018 12:25:20 -0700 Rick Edgecombe
> wrote:
>
> > This adds a test module in lib/, and a script in kselftest that does
> > benchmarking on the allocation of memory in the module space. Performance
> > here
> > would have
On Mon, 2018-09-24 at 12:58 -0700, Kees Cook wrote:
> On Mon, Sep 24, 2018 at 11:57 AM, Edgecombe, Rick P
> wrote:
> > > Instead of having two open-coded __vmalloc_node_range() calls left in
> > > this after the change, can this be done in terms of a call to
> > &
On Fri, 2018-09-21 at 12:05 -0700, Kees Cook wrote:
> On Thu, Sep 13, 2018 at 2:31 PM, Rick Edgecombe
> wrote:
> I would find this much more readable as:
> static unsigned long get_module_vmalloc_start(void)
> {
> unsigned long addr = MODULES_VADDR;
>
> if (kaslr_randomize_base())
On Fri, 2018-09-21 at 11:56 -0700, Kees Cook wrote:
> On Thu, Sep 13, 2018 at 2:31 PM, Rick Edgecombe
> wrote:
> > +done:
> > + gap = (MODULES_END - last_end);
> > + if (gap > largest_free)
> > + largest_free = gap;
> > + total_free += gap;
> > +
> > +
On Thu, 2018-12-06 at 10:52 -0800, Andy Lutomirski wrote:
> On Wed, Dec 5, 2018 at 12:52 AM Nadav Amit wrote:
> >
> > When module memory is about to be freed, there is no apparent reason to
> > make it (and its data) executable, but that's exactly what is done
> > today. This is not efficient
On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote:
> +++ Rick Edgecombe [20/11/18 15:23 -0800]:
[snip]
> Hi Rick!
>
> Sorry for the delay. I'd like to take a step back and ask some broader
> questions -
>
> - Is the end goal of this patchset to randomize loading kernel modules, or
> most/all
>
On Thu, 2021-01-21 at 13:19 +, Matthew Wilcox wrote:
> On Wed, Jan 20, 2021 at 05:41:18PM -0800, Rick Edgecombe wrote:
> > When VM_MAP_PUT_PAGES was added, it was defined with the same value
> > as
> > VM_FLUSH_RESET_PERMS. This doesn't seem like it will cause any big
> > functional problems
On Tue, 2020-09-29 at 16:06 +0300, Mike Rapoport wrote:
> On Tue, Sep 29, 2020 at 04:58:44AM +0000, Edgecombe, Rick P wrote:
> > On Thu, 2020-09-24 at 16:29 +0300, Mike Rapoport wrote:
> > > Introduce "memfd_secret" system call with the ability to create
> >
On Wed, 2020-09-30 at 13:35 +0300, Mike Rapoport wrote:
> On Tue, Sep 29, 2020 at 08:06:03PM +0000, Edgecombe, Rick P wrote:
> > On Tue, 2020-09-29 at 16:06 +0300, Mike Rapoport wrote:
> > > On Tue, Sep 29, 2020 at 04:58:44AM +0000, Edgecombe, Rick P
> > > wrote:
>
On Tue, 2020-08-11 at 23:54 +0200, John Paul Adrian Glaubitz wrote:
> Hi Rick!
>
> I have been bisecting some regressions on ia64 and one problem I ran
> into is that
> udev is causing the kernel to crash after the following change from
> 2019:
>
> commit 868b104d7379e28013e9d48bdd2db25e0bdcf751
On Tue, 2020-10-27 at 10:49 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 06:57:32PM +0000, Edgecombe, Rick P wrote:
> > On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> > > On Mon, Oct 26, 2020 at 12:38:32AM +0000, Edgecombe, Rick P
> > > wrote:
>
On Wed, 2020-10-28 at 13:30 +0200, Mike Rapoport wrote:
> On Wed, Oct 28, 2020 at 11:20:12AM +, Will Deacon wrote:
> > On Tue, Oct 27, 2020 at 10:38:16AM +0200, Mike Rapoport wrote:
> > > On Mon, Oct 26, 2020 at 06:05:30PM +0000, Edgecombe, Rick P
> > > wrote:
>
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> + if (IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
> + unsigned long addr = (unsigned
> long)page_address(page);
> + int ret;
> +
> + if (enable)
> + ret =
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may
> be
> not present in the direct map and has to be explicitly mapped before
> it
> could be copied.
>
> On arm64 it is possible that a page
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> index 7f248fc45317..16f878c26667 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -2228,7 +2228,6 @@ void __kernel_map_pages(struct page *page, int
> numpages, int enable)
> }
> #endif /*
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP
> it is
> possible that __kernel_map_pages() would fail, but since this
> function is
> void, the failure will go unnoticed.
Could you elaborate on how this could happen?
On Tue, 2020-10-20 at 15:20 +0200, David Hildenbrand wrote:
> On 20.10.20 14:18, David Hildenbrand wrote:
> > On 20.10.20 08:18, Kirill A. Shutemov wrote:
> > > If the protected memory feature enabled, unmap guest memory from
> > > kernel's direct mappings.
> >
> > Gah, ugly. I guess this also
On Tue, 2020-10-20 at 09:18 +0300, Kirill A. Shutemov wrote:
> include/linux/mm.h | 8
> mm/gup.c| 20
> mm/huge_memory.c| 20
> mm/memory.c | 3 +++
> mm/mmap.c | 3 +++
> virt/kvm/async_pf.c | 2 +-
>
On Tue, 2020-10-20 at 09:18 +0300, Kirill A. Shutemov wrote:
> If the protected memory feature enabled, unmap guest memory from
> kernel's direct mappings.
>
> Migration and KSM is disabled for protected memory as it would
> require a
> special treatment.
>
So do we care about this scenario
On Tue, 2020-10-20 at 09:18 +0300, Kirill A. Shutemov wrote:
> We cannot access protected pages directly. Use ioremap() to
> create a temporary mapping of the page. The mapping is destroyed
> on __kvm_unmap_gfn().
>
> The new interface gfn_to_pfn_memslot_protected() is used to detect if
> the
On Thu, 2020-10-22 at 15:06 +0300, Kirill A. Shutemov wrote:
> > I think the page could have got unmapped since the gup via the
> > hypercall on another CPU. It could be an avenue for the guest to
> > crash
> > the host.
>
> Hm.. I'm not sure I follow. Could you elaborate on what scenario you
>
On Mon, 2020-10-26 at 11:05 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 01:13:52AM +0000, Edgecombe, Rick P wrote:
> > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > Indeed, for architectures that define
> > > CONFIG_ARCH_HAS_SET_DIRECT_MAP
On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 12:38:32AM +0000, Edgecombe, Rick P wrote:
> > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > When DEBUG_PAGEALLOC or ARCH_
On Mon, 2020-10-26 at 10:37 +0200, Mike Rapoport wrote:
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -2184,14 +2184,14 @@ static int __set_pages_np(struct page *page,
> int numpages)
> return __change_page_attr_set_clr(, 0);
> }
>
> -int set_direct_map_invalid_noflush(struct page *page)
>
On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> The intention of this series is to disallow usage of
> __kernel_map_pages() when DEBUG_PAGEALLOC=n. I'll update this patch
> to
> better handle possible errors, but I still want to keep WARN in the
> caller.
Sorry, I missed this snippet at
On Thu, 2020-10-29 at 10:12 +0200, Mike Rapoport wrote:
> This series goal was primarily to separate dependincies and make it
> clearer what DEBUG_PAGEALLOC and what SET_DIRECT_MAP are. As it
> turned
> out, there is also some lack of consistency between architectures
> that
> implement either of
On Thu, 2020-10-29 at 09:54 +0200, Mike Rapoport wrote:
> __kernel_map_pages() on arm64 will also bail out if rodata_full is
> false:
> void __kernel_map_pages(struct page *page, int numpages, int enable)
> {
> if (!debug_pagealloc_enabled() && !rodata_full)
> return;
>
>
On Sat, 2020-11-21 at 20:10 -0800, Andy Lutomirski wrote:
> On Fri, Nov 20, 2020 at 12:30 PM Rick Edgecombe
> wrote:
> > In order to allow for future arch specific optimizations for
> > vmalloc
> > permissions, first add an implementation of a new interface that
> > will
> > work cross arch by
On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote:
> Support huge page vmalloc mappings. Config option
> HAVE_ARCH_HUGE_VMALLOC
> enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
> supports PMD sized vmap mappings.
>
> vmalloc will attempt to allocate PMD-sized pages if
On Mon, 2020-11-30 at 12:21 -0800, Rick Edgecombe wrote:
> another option could be to use the changes here:
> https://lore.kernel.org/lkml/20201125092208.12544-4-r...@kernel.org/
> to reset the direct map for a large page range at a time for large
> vmalloc pages.
Oops, sorry. This wouldn't be
On Mon, 2020-11-23 at 09:00 +, Christoph Hellwig wrote:
> First thanks for doing this, having a vmalloc variant that starts out
> with proper permissions has been on my todo list for a while.
>
> > +#define PERM_R 1
> > +#define PERM_W 2
> > +#define PERM_X 4
> > +#define PERM_RWX
On Fri, 2020-12-04 at 18:12 +1000, Nicholas Piggin wrote:
> Excerpts from Edgecombe, Rick P's message of December 1, 2020 6:21
> am:
> > On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote:
> > > Support huge page vmalloc mappings. Config option
> > > HAVE_ARCH_HUGE_VMALLOC
> > > enables
On Tue, 2020-11-24 at 10:19 +, h...@infradead.org wrote:
> But I thought that using those pgprot flags was still sort
> overloading
> > the meaning of pgprot. My understanding was that it is supposed to
> > hold
> > the actual bits set in the PTE. For example large pages or TLB
> > hints
> >
On Tue, 2020-11-24 at 10:16 +, Christoph Hellwig wrote:
> On Mon, Nov 23, 2020 at 12:01:35AM +0000, Edgecombe, Rick P wrote:
> > Another option could be putting the new metadata in vm_struct and
> > just
> > return that, like get_vm_area(). Then we don't need to in
On Thu, 2019-05-30 at 10:44 +0300, Meelis Roos wrote:
> > > The addition of VM_FLUSH_RESET_PERMS for BPF JIT allocations was
> > > bisected to prevent boot on an UltraSparc III machine. It was
> > > found
> > > that
> > > sometime shortly after the TLB flush this flag does on vfree of
> > > the
>
On Wed, 2020-10-28 at 13:09 +0200, Mike Rapoport wrote:
> On Tue, Oct 27, 2020 at 09:46:35AM +0100, David Hildenbrand wrote:
> > On 27.10.20 09:38, Mike Rapoport wrote:
> > > On Mon, Oct 26, 2020 at 06:05:30PM +0000, Edgecombe, Rick P
> > > wrote:
> > >
&g
On Thu, 2020-09-24 at 16:29 +0300, Mike Rapoport wrote:
> Introduce "memfd_secret" system call with the ability to create
> memory
> areas visible only in the context of the owning process and not
> mapped not
> only to other processes but in the kernel page tables as well.
>
> The user will
On Wed, 2021-02-03 at 16:01 -0800, Sean Christopherson wrote:
>
> - unsigned long cr3_lm_rsvd_bits;
> + u64 reserved_gpa_bits;
LAM defines bits above the GFN in CR3:
On Mon, 2019-05-20 at 14:25 -0700, Andy Lutomirski wrote:
>
>
> > On May 20, 2019, at 1:07 PM, Rick Edgecombe <
> > rick.p.edgeco...@intel.com> wrote:
> >
> > Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> > vm_unmap_aliases() and fix calculation of the direct map for the
>
On Tue, 2019-05-21 at 00:36 +0300, Meelis Roos wrote:
> > Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> > vm_unmap_aliases() and fix calculation of the direct map for the
> > CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> >
> > Meelis Roos reported issues with the new
On Mon, 2019-05-20 at 16:38 -0700, Rick Edgecombe wrote:
> These two patches address issues with the recently added
> VM_FLUSH_RESET_PERMS vmalloc flag. It is now split into two patches,
> which
> made sense to me, but can split it further if desired.
>
Oops, this was supposed to say PATCH v3.
On Mon, 2019-05-20 at 15:48 -0700, David Miller wrote:
> From: "Edgecombe, Rick P"
> Date: Mon, 20 May 2019 22:17:49 +
>
> > Thanks for testing. So I guess that suggests it's the TLB flush
> > causing
> > the problem on sparc and not any lazy purge deadlo
On Mon, 2019-05-20 at 20:33 -0400, David Miller wrote:
> From: "Edgecombe, Rick P"
> Date: Tue, 21 May 2019 00:20:13 +
>
> > This behavior shouldn't happen until modules or BPF are being
> > freed.
>
> Then that would rule out my theory.
>
> The
On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> From: "Edgecombe, Rick P"
> Date: Tue, 21 May 2019 01:20:33 +
>
> > Should it handle executing an unmapped page gracefully? Because
> > this
> > change is causing that to happen much
On Tue, 2019-05-21 at 09:17 -0700, Andy Lutomirski wrote:
> On Mon, May 20, 2019 at 4:39 PM Rick Edgecombe
> wrote:
> > From: Rick Edgecombe
> >
> > Calling vm_unmap_alias() in vm_remove_mappings() could potentially
> > be a
> > lot of work to do on a free operation. Simply flushing the TLB
> >
On Tue, 2019-05-21 at 10:00 -0700, Andy Lutomirski wrote:
> On Tue, May 21, 2019 at 9:51 AM Edgecombe, Rick P
> wrote:
> > On Tue, 2019-05-21 at 09:17 -0700, Andy Lutomirski wrote:
> > > On Mon, May 20, 2019 at 4:39 PM Rick Edgecombe
> > > wrote
On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> From: "Edgecombe, Rick P"
> Date: Tue, 21 May 2019 01:59:54 +
>
> > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> > > From: "Edgecombe, Rick P"
> > > Date: Tue, 21 Ma
On Wed, 2019-05-22 at 12:26 -0700, Rick Edgecombe wrote:
> On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> > From: "Edgecombe, Rick P"
> > Date: Tue, 21 May 2019 01:59:54 +
> >
> > > On Mon, 2019-05-20 at 18:43 -0700, David Miller
On Wed, 2019-05-22 at 15:40 -0700, Rick Edgecombe wrote:
> On Wed, 2019-05-22 at 12:26 -0700, Rick Edgecombe wrote:
> > On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> > > From: "Edgecombe, Rick P"
> > > Date: Tue, 21 May 2019 01:59:54 +
>
On Tue, 2019-05-28 at 17:23 -0700, David Miller wrote:
> From: Rick Edgecombe
> Date: Mon, 27 May 2019 14:10:56 -0700
>
> > These two patches address issues with the recently added
> > VM_FLUSH_RESET_PERMS vmalloc flag.
> >
> > Patch 1 addresses an issue that could cause a crash after other
> >
On Tue, 2019-05-28 at 22:51 -0700, Rick Edgecombe wrote:
> The addition of VM_FLUSH_RESET_PERMS for BPF JIT allocations was
> bisected to prevent boot on an UltraSparc III machine. It was found
> that
> sometime shortly after the TLB flush this flag does on vfree of the
> BPF
> program, the
On Fri, 2019-10-04 at 09:22 +0200, Paolo Bonzini wrote:
> On 03/10/19 23:23, Rick Edgecombe wrote:
> > Since software would have previously received a #PF with the RSVD error code
> > set, when the HW encountered any set bits in the region 51 to M, there was
> > some
> > internal discussion on
On Fri, 2019-10-04 at 09:27 +0200, Paolo Bonzini wrote:
> On 03/10/19 23:23, Rick Edgecombe wrote:
> > Add XO memslot type to create execute-only guest physical memory based on
> > the RO memslot. Like the RO memslot, disallow changing the memslot type
> > to/from XO.
> >
> > In the EPT case
On Fri, 2019-10-04 at 09:24 +0200, Paolo Bonzini wrote:
> On 03/10/19 23:23, Rick Edgecombe wrote:
> > Add a KVM capability for the KVM_MEM_EXECONLY memslot type. This memslot
> > type is supported if the HW supports execute-only TDP.
> >
> > Signed-off-by: Rick Edgecombe
> > ---
> >
On Fri, 2019-10-04 at 09:42 +0200, Paolo Bonzini wrote:
> On 03/10/19 23:23, Rick Edgecombe wrote:
> > + if (!vcpu->arch.gva_available)
> > + return 0;
>
> Please return RET_PF_* constants, RET_PF_EMULATE here.
Ok.
> > + if (error_code & PFERR_WRITE_MASK)
> > +
On Fri, 2019-10-04 at 09:34 +0200, Paolo Bonzini wrote:
> On 03/10/19 23:23, Rick Edgecombe wrote:
> > +
> > + protection_map[4] = PAGE_EXECONLY;
> > + protection_map[12] = PAGE_EXECONLY;
>
> Can you add #defines for the bits in protection_map? Also perhaps you
> can replace the
On Fri, 2019-10-04 at 07:56 -0700, Andy Lutomirski wrote:
> On Thu, Oct 3, 2019 at 2:38 PM Rick Edgecombe
> wrote:
> >
> > This patchset enables the ability for KVM guests to create execute-only (XO)
> > memory by utilizing EPT based XO permissions. XO memory is currently
> > supported
> > on
On Fri, 2019-10-04 at 18:33 -0700, Andy Lutomirski wrote:
> On Fri, Oct 4, 2019 at 1:10 PM Edgecombe, Rick P
> wrote:
> >
> > On Fri, 2019-10-04 at 07:56 -0700, Andy Lutomirski wrote:
> > > On Thu, Oct 3, 2019 at 2:38 PM Rick Edgecombe
> > > wrote:
&g
On Mon, 2019-10-14 at 14:47 +0800, Yu Zhang wrote:
> On Thu, Oct 03, 2019 at 02:23:48PM -0700, Rick Edgecombe wrote:
> > Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
> > guests view of gfn is used when high bits of the physical memory are
> > used as extra permissions bits.
On Mon, 2019-05-27 at 14:20 +0200, Peter Zijlstra wrote:
> On Tue, May 21, 2019 at 01:51:36PM -0700, Rick Edgecombe wrote:
> > The calculation of the direct map address range to flush was wrong.
> > This could cause problems on x86 if a RO direct map alias ever got
> > loaded
> > into the TLB.
On Thu, 2019-07-04 at 12:53 +0300, Meelis Roos wrote:
> I noticed that while 5.1 works on my HP Integrity RX2620, 5.2-rc6
> crashed on boot nondeterministically.
> Bisecting it took many tries sice it does not happen on each boot and
> when it happes, the symptoms are
> different each time. But
On Thu, 2019-01-17 at 10:39 +0100, Pavel Machek wrote:
> Hi!
>
> > For architectures with CONFIG_ARCH_HAS_SET_ALIAS, pages can be unmapped
> > briefly on the directmap, even when CONFIG_DEBUG_PAGEALLOC is not
> > configured.
> > So this changes kernel_map_pages and kernel_page_present to be
On Fri, 2019-01-18 at 00:41 +0100, Pavel Machek wrote:
> Hi!
>
> > > > For architectures with CONFIG_ARCH_HAS_SET_ALIAS, pages can be unmapped
> > > > briefly on the directmap, even when CONFIG_DEBUG_PAGEALLOC is not
> > > > configured.
> > > > So this changes kernel_map_pages and
On Wed, 2019-02-06 at 11:23 -0500, Steven Rostedt wrote:
> On Wed, 16 Jan 2019 16:32:58 -0800
> Rick Edgecombe wrote:
>
> > Add new flag for handling freeing of special permissioned memory in vmalloc
> > and remove places where memory was set RW before freeing which is no longer
> > needed.
> >
On Thu, 2019-02-07 at 12:49 -0500, Steven Rostedt wrote:
> On Thu, 7 Feb 2019 17:33:37 +
> "Edgecombe, Rick P" wrote:
>
>
> > > > ---
> > > > arch/x86/kernel/ftrace.c | 6 +--
> > >
> > > For the ftrace code.
>
On Thu, 2018-06-21 at 14:32 +0200, Jann Horn wrote:
> On Thu, Jun 21, 2018 at 12:12 AM Rick Edgecombe
> wrote:
> >
> > Add debugfs file "modfraginfo" for providing info on module space
> > fragmentation. This can be used for determining if loadable module
> > randomization is causing any
On Wed, 2018-06-20 at 15:33 -0700, Kees Cook wrote:
> > The new __vmalloc_node_try_addr function uses the existing function
> > __vmalloc_node_range, in order to introduce this algorithm with the
> > least
> > invasive change. The side effect is that each time there is a
> > collision when
> >
On Thu, 2018-06-21 at 15:37 +0200, Jann Horn wrote:
> On Thu, Jun 21, 2018 at 12:34 AM Kees Cook
> wrote:
> > And most systems have <200 modules, really. I have 113 on a desktop
> > right now, 63 on a server. So this looks like a trivial win.
> But note that the eBPF JIT also uses module_alloc().
On Wed, 2018-06-20 at 15:26 -0700, Matthew Wilcox wrote:
> Not needed:
>
> void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char
> *fmt, ...)
> {
> ...
> if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(_rs))
> return;
>
Yes, thanks!
On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote:
> +++ Rick Edgecombe [20/11/18 15:23 -0800]:
[snip]
> Hi Rick!
>
> Sorry for the delay. I'd like to take a step back and ask some broader
> questions -
>
> - Is the end goal of this patchset to randomize loading kernel modules, or
> most/all
>
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 11:50 AM Edgecombe, Rick P
> > > wrote:
On Mon, 2018-12-17 at 05:41 +0100, Jessica Yu wrote:
> +++ Edgecombe, Rick P [12/12/18 23:05 +]:
> > On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote:
> > > On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> > > > On 11/27/2018 01:
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_SPECIAL_PERMS, for
> > enabling vfree operations to immediately clear executable TLB entries to
> > freed
> > pages,
On Tue, 2018-12-11 at 18:24 -0800, Andy Lutomirski wrote:
> On Tue, Dec 11, 2018 at 4:12 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.
>
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 implementation of
> > arch_vunmap, that can free any type of special permission memory with only 1
> > TLB
> > flush.
> >
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 Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> > > wrote:
>
On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote:
> On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> > On 11/27/2018 01:19 AM, Edgecombe, Rick P wrote:
> > > On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote:
> > > > +++ Rick E
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 memory in
> > vmalloc,
> > and remove places where the handling was done in module.c.
> >
> > This will enable this
On Thu, 2018-12-13 at 19:27 +, Nadav Amit wrote:
> > 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:
>
On Thu, 2018-12-06 at 10:52 -0800, Andy Lutomirski wrote:
> On Wed, Dec 5, 2018 at 12:52 AM Nadav Amit wrote:
> >
> > When module memory is about to be freed, there is no apparent reason to
> > make it (and its data) executable, but that's exactly what is done
> > today. This is not efficient
Forgot to include this:
Reviewed-by: Kees Cook
On Mon, 2018-10-01 at 14:38 -0700, Rick Edgecombe wrote:
> Create __vmalloc_node_try_addr function that tries to allocate at a specific
> address and supports caller specified behavior for whether any lazy purging
> happens if there is a collision.
For a previous version before making asked for corrections, this was:
Reviewed-by: Kees Cook
On Mon, 2018-10-01 at 14:38 -0700, Rick Edgecombe wrote:
> Add debugfs file "modfraginfo" for providing info on module space
> fragmentation.
> This can be used for determining if loadable module
On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> +++ Dave Hansen [11/10/18 16:47 -0700]:
> > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > + if (check_inc_mod_rlimit(size))
> > > + return NULL;
> > > +
> > > p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> >
On Fri, 2018-10-12 at 22:01 +, Edgecombe, Rick P wrote:
> On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> > +++ Dave Hansen [11/10/18 16:47 -0700]:
> > > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > > + if (check_inc_mod_rlimit(size))
>
On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> wrote:
> > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > Why all the rbtree stuff instead of stashing a pointer in struct
> > > vmap_area, or somet
On Fri, 2018-09-21 at 12:05 -0700, Kees Cook wrote:
> On Thu, Sep 13, 2018 at 2:31 PM, Rick Edgecombe
> wrote:
> I would find this much more readable as:
> static unsigned long get_module_vmalloc_start(void)
> {
> unsigned long addr = MODULES_VADDR;
>
> if (kaslr_randomize_base())
1 - 100 of 146 matches
Mail list logo
