Re: [kernel-hardening] [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
On Wed, Sep 14, 2016 at 10:36:34AM +0100, Mark Rutland wrote: > On Wed, Sep 14, 2016 at 09:18:58AM +0200, Juerg Haefliger wrote: > > This patch series adds support for XPFO which protects against 'ret2dir' > > kernel attacks. The basic idea is to enforce exclusive ownership of page > > frames by either the kernel or userspace, unless explicitly requested by > > the kernel. Whenever a page destined for userspace is allocated, it is > > unmapped from physmap (the kernel's page table). When such a page is > > reclaimed from userspace, it is mapped back to physmap. > > Reference paper by the original patch authors: > > http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf > For both arm64 and x86_64, DEBUG_RODATA is mandatory (or soon to be so). > Assuming that implies a lack of execute permission for x86_64, that > should provide a similar level of protection against erroneously > branching to addresses in the linear map, without the complexity and > overhead of mapping/unmapping pages. > > So to me it looks like this approach may only be useful for > architectures without page-granular execute permission controls. > > Is this also intended to protect against erroneous *data* accesses to > the linear map? Now that I read the paper more carefully, I can see that this is the case, and this does catch issues which DEBUG_RODATA cannot. Apologies for the noise. Thanks, Mark.
Re: [kernel-hardening] [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
On Wed, Sep 14, 2016 at 10:36:34AM +0100, Mark Rutland wrote: > On Wed, Sep 14, 2016 at 09:18:58AM +0200, Juerg Haefliger wrote: > > This patch series adds support for XPFO which protects against 'ret2dir' > > kernel attacks. The basic idea is to enforce exclusive ownership of page > > frames by either the kernel or userspace, unless explicitly requested by > > the kernel. Whenever a page destined for userspace is allocated, it is > > unmapped from physmap (the kernel's page table). When such a page is > > reclaimed from userspace, it is mapped back to physmap. > > Reference paper by the original patch authors: > > http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf > For both arm64 and x86_64, DEBUG_RODATA is mandatory (or soon to be so). > Assuming that implies a lack of execute permission for x86_64, that > should provide a similar level of protection against erroneously > branching to addresses in the linear map, without the complexity and > overhead of mapping/unmapping pages. > > So to me it looks like this approach may only be useful for > architectures without page-granular execute permission controls. > > Is this also intended to protect against erroneous *data* accesses to > the linear map? Now that I read the paper more carefully, I can see that this is the case, and this does catch issues which DEBUG_RODATA cannot. Apologies for the noise. Thanks, Mark.
Re: [kernel-hardening] [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
Hi, On Wed, Sep 14, 2016 at 09:18:58AM +0200, Juerg Haefliger wrote: > This patch series adds support for XPFO which protects against 'ret2dir' > kernel attacks. The basic idea is to enforce exclusive ownership of page > frames by either the kernel or userspace, unless explicitly requested by > the kernel. Whenever a page destined for userspace is allocated, it is > unmapped from physmap (the kernel's page table). When such a page is > reclaimed from userspace, it is mapped back to physmap. > Known issues/limitations: > - Only supports x86-64 (for now) > - Only supports 4k pages (for now) > - There are most likely some legitimate uses cases where the kernel needs > to access userspace which need to be made XPFO-aware > - Performance penalty > > Reference paper by the original patch authors: > http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf Just to check, doesn't DEBUG_RODATA ensure that the linear mapping is non-executable on x86_64 (as it does for arm64)? For both arm64 and x86_64, DEBUG_RODATA is mandatory (or soon to be so). Assuming that implies a lack of execute permission for x86_64, that should provide a similar level of protection against erroneously branching to addresses in the linear map, without the complexity and overhead of mapping/unmapping pages. So to me it looks like this approach may only be useful for architectures without page-granular execute permission controls. Is this also intended to protect against erroneous *data* accesses to the linear map? Am I missing something? Thanks, Mark.
Re: [kernel-hardening] [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
Hi, On Wed, Sep 14, 2016 at 09:18:58AM +0200, Juerg Haefliger wrote: > This patch series adds support for XPFO which protects against 'ret2dir' > kernel attacks. The basic idea is to enforce exclusive ownership of page > frames by either the kernel or userspace, unless explicitly requested by > the kernel. Whenever a page destined for userspace is allocated, it is > unmapped from physmap (the kernel's page table). When such a page is > reclaimed from userspace, it is mapped back to physmap. > Known issues/limitations: > - Only supports x86-64 (for now) > - Only supports 4k pages (for now) > - There are most likely some legitimate uses cases where the kernel needs > to access userspace which need to be made XPFO-aware > - Performance penalty > > Reference paper by the original patch authors: > http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf Just to check, doesn't DEBUG_RODATA ensure that the linear mapping is non-executable on x86_64 (as it does for arm64)? For both arm64 and x86_64, DEBUG_RODATA is mandatory (or soon to be so). Assuming that implies a lack of execute permission for x86_64, that should provide a similar level of protection against erroneously branching to addresses in the linear map, without the complexity and overhead of mapping/unmapping pages. So to me it looks like this approach may only be useful for architectures without page-granular execute permission controls. Is this also intended to protect against erroneous *data* accesses to the linear map? Am I missing something? Thanks, Mark.
