Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Tue, Feb 20, 2018 at 9:16 AM, Igor Stoppa wrote: > > > On 13/02/18 20:10, Laura Abbott wrote: >> On 02/13/2018 07:20 AM, Igor Stoppa wrote: >>> Why alterations of page properties are not considered a risk and the >>> physmap is? >>> And how would it be easier (i

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Tue, Feb 20, 2018 at 9:16 AM, Igor Stoppa wrote: > > > On 13/02/18 20:10, Laura Abbott wrote: >> On 02/13/2018 07:20 AM, Igor Stoppa wrote: >>> Why alterations of page properties are not considered a risk and the >>> physmap is? >>> And how would it be easier (i suppose) to attack the latter?

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Tue, Feb 20, 2018 at 8:28 AM, Igor Stoppa wrote: > > > On 14/02/18 21:29, Kees Cook wrote: >> On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > > [...] > >>> Kernel code should be fine, if it isn't that is a bug that should be >>> fixed.

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Tue, Feb 20, 2018 at 8:28 AM, Igor Stoppa wrote: > > > On 14/02/18 21:29, Kees Cook wrote: >> On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > > [...] > >>> Kernel code should be fine, if it isn't that is a bug that should be >>> fixed. Modules yes are not fully protected. The

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 13/02/18 20:10, Laura Abbott wrote: > On 02/13/2018 07:20 AM, Igor Stoppa wrote: >> Why alterations of page properties are not considered a risk and the physmap >> is? >> And how would it be easier (i suppose) to attack the latter? > > Alterations are certainly a risk but with the physmap

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 13/02/18 20:10, Laura Abbott wrote: > On 02/13/2018 07:20 AM, Igor Stoppa wrote: >> Why alterations of page properties are not considered a risk and the physmap >> is? >> And how would it be easier (i suppose) to attack the latter? > > Alterations are certainly a risk but with the physmap

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On 14/02/18 21:29, Kees Cook wrote: > On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: [...] >> Kernel code should be fine, if it isn't that is a bug that should be >> fixed. Modules yes are not fully protected. The conclusion from past > > I think that's a pretty

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On 14/02/18 21:29, Kees Cook wrote: > On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: [...] >> Kernel code should be fine, if it isn't that is a bug that should be >> fixed. Modules yes are not fully protected. The conclusion from past > > I think that's a pretty serious problem: we

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 2:13 PM, Tycho Andersen wrote: > On Wed, Feb 14, 2018 at 11:48:38AM -0800, Kees Cook wrote: >> On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: >> > fixed. Modules yes are not fully protected. The conclusion from past >> >

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 2:13 PM, Tycho Andersen wrote: > On Wed, Feb 14, 2018 at 11:48:38AM -0800, Kees Cook wrote: >> On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: >> > fixed. Modules yes are not fully protected. The conclusion from past >> > experience has been that we cannot safely

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 11:48:38AM -0800, Kees Cook wrote: > On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > > fixed. Modules yes are not fully protected. The conclusion from past > > experience has been that we cannot safely break down larger page sizes > > at runtime

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 11:48:38AM -0800, Kees Cook wrote: > On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > > fixed. Modules yes are not fully protected. The conclusion from past > > experience has been that we cannot safely break down larger page sizes > > at runtime like x86 does. We

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On 02/14/2018 11:28 AM, Ard Biesheuvel wrote: On 14 February 2018 at 19:06, Laura Abbott wrote: On 02/13/2018 01:43 PM, Kees Cook wrote: On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: No, arm64 doesn't fixup the aliases, mostly because arm64

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On 02/14/2018 11:28 AM, Ard Biesheuvel wrote: On 14 February 2018 at 19:06, Laura Abbott wrote: On 02/13/2018 01:43 PM, Kees Cook wrote: On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger page sizes which can't be

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > fixed. Modules yes are not fully protected. The conclusion from past > experience has been that we cannot safely break down larger page sizes > at runtime like x86 does. We could theoretically > add support for fixing up

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > fixed. Modules yes are not fully protected. The conclusion from past > experience has been that we cannot safely break down larger page sizes > at runtime like x86 does. We could theoretically > add support for fixing up the alias if

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 11:29 AM, Kees Cook wrote: > Why does using finer granularity on the physmap degrade performance? I > assume TLB pressure, but what is heavily using that area? (I must not > be understanding what physmap actually gets used for -- I thought it > was

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 11:29 AM, Kees Cook wrote: > Why does using finer granularity on the physmap degrade performance? I > assume TLB pressure, but what is heavily using that area? (I must not > be understanding what physmap actually gets used for -- I thought it > was just a convenience to

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > On 02/13/2018 01:43 PM, Kees Cook wrote: >> >> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>> >>> No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger >>> page sizes which

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > On 02/13/2018 01:43 PM, Kees Cook wrote: >> >> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>> >>> No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger >>> page sizes which can't be broken down at runtime.

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On 14 February 2018 at 19:06, Laura Abbott wrote: > On 02/13/2018 01:43 PM, Kees Cook wrote: >> >> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>> >>> No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger >>> page sizes which can't

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On 14 February 2018 at 19:06, Laura Abbott wrote: > On 02/13/2018 01:43 PM, Kees Cook wrote: >> >> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>> >>> No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger >>> page sizes which can't be broken down at runtime.

arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On 02/13/2018 01:43 PM, Kees Cook wrote: On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING does use 4K pages which could be

arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On 02/13/2018 01:43 PM, Kees Cook wrote: On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING does use 4K pages which could be adjusted at runtime. So

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: > No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger > page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING > does use 4K pages which could be adjusted at runtime. So yes, you are >

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: > No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger > page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING > does use 4K pages which could be adjusted at runtime. So yes, you are > right we would have

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 02/13/2018 07:20 AM, Igor Stoppa wrote: Why alterations of page properties are not considered a risk and the physmap is? And how would it be easier (i suppose) to attack the latter? Alterations are certainly a risk but with the physmap the mapping is already there. Find the address and you

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 02/13/2018 07:20 AM, Igor Stoppa wrote: Why alterations of page properties are not considered a risk and the physmap is? And how would it be easier (i suppose) to attack the latter? Alterations are certainly a risk but with the physmap the mapping is already there. Find the address and you

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 02/12/2018 07:39 PM, Jann Horn wrote: On Tue, Feb 13, 2018 at 2:25 AM, Kees Cook wrote: On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: On 02/12/2018 03:27 PM, Kees Cook wrote: On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 02/12/2018 07:39 PM, Jann Horn wrote: On Tue, Feb 13, 2018 at 2:25 AM, Kees Cook wrote: On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: On 02/12/2018 03:27 PM, Kees Cook wrote: On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa wrote: On 04/02/18 00:29, Boris Lukashev wrote: On Sat,

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Tue, Feb 13, 2018 at 2:25 AM, Kees Cook wrote: > On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: >> On 02/12/2018 03:27 PM, Kees Cook wrote: >>> >>> On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa >>> wrote: On

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Tue, Feb 13, 2018 at 2:25 AM, Kees Cook wrote: > On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: >> On 02/12/2018 03:27 PM, Kees Cook wrote: >>> >>> On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa >>> wrote: On 04/02/18 00:29, Boris Lukashev wrote: > > On Sat, Feb 3, 2018

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: > On 02/12/2018 03:27 PM, Kees Cook wrote: >> >> On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa >> wrote: >>> >>> On 04/02/18 00:29, Boris Lukashev wrote: On Sat, Feb 3, 2018 at 3:32 PM, Igor

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: > On 02/12/2018 03:27 PM, Kees Cook wrote: >> >> On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa >> wrote: >>> >>> On 04/02/18 00:29, Boris Lukashev wrote: On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: >>> >>> >>> [...] >>>

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 02/12/2018 03:27 PM, Kees Cook wrote: On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa wrote: On 04/02/18 00:29, Boris Lukashev wrote: On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: [...] What you are suggesting, if I have understood it

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 02/12/2018 03:27 PM, Kees Cook wrote: On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa wrote: On 04/02/18 00:29, Boris Lukashev wrote: On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: [...] What you are suggesting, if I have understood it correctly, is that, when the pool is protected,

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa wrote: > On 04/02/18 00:29, Boris Lukashev wrote: >> On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: > > [...] > >>> What you are suggesting, if I have understood it correctly, is that, >>> when the

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa wrote: > On 04/02/18 00:29, Boris Lukashev wrote: >> On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: > > [...] > >>> What you are suggesting, if I have understood it correctly, is that, >>> when the pool is protected, the addresses already given

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

Re: [PATCH 4/6] Protectable Memory

On 12/02/18 17:31, Mike Rapoport wrote: [...] > Seems that kernel-doc does not consider () as a valid match for the > identifier :) > > Can you please check with the below patch? yes, it works now, than you! -- igor

Re: [PATCH 4/6] Protectable Memory

On 12/02/18 17:31, Mike Rapoport wrote: [...] > Seems that kernel-doc does not consider () as a valid match for the > identifier :) > > Can you please check with the below patch? yes, it works now, than you! -- igor

Re: [PATCH 4/6] Protectable Memory

On Mon, Feb 12, 2018 at 03:41:57PM +0200, Igor Stoppa wrote: > > > On 12/02/18 14:53, Mike Rapoport wrote: > > 'scripts/kernel-doc -v -none > > That has a quite interesting behavior. > > I run it on genalloc.c while I am in the process of adding the brackets > to the function names in the

Re: [PATCH 4/6] Protectable Memory

On Mon, Feb 12, 2018 at 03:41:57PM +0200, Igor Stoppa wrote: > > > On 12/02/18 14:53, Mike Rapoport wrote: > > 'scripts/kernel-doc -v -none > > That has a quite interesting behavior. > > I run it on genalloc.c while I am in the process of adding the brackets > to the function names in the

Re: [PATCH 4/6] Protectable Memory

On 12/02/18 14:53, Mike Rapoport wrote: > 'scripts/kernel-doc -v -none That has a quite interesting behavior. I run it on genalloc.c while I am in the process of adding the brackets to the function names in the kernel-doc description. The brackets confuse the script and it fails to output

Re: [PATCH 4/6] Protectable Memory

On 12/02/18 14:53, Mike Rapoport wrote: > 'scripts/kernel-doc -v -none That has a quite interesting behavior. I run it on genalloc.c while I am in the process of adding the brackets to the function names in the kernel-doc description. The brackets confuse the script and it fails to output

Re: [PATCH 4/6] Protectable Memory

On Mon, Feb 12, 2018 at 01:43:11PM +0200, Mike Rapoport wrote: > On Mon, Feb 12, 2018 at 01:26:28PM +0200, Igor Stoppa wrote: > > On 11/02/18 14:37, Mike Rapoport wrote: > > > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote: > > > > >> + * Return: 0 if the object does not belong to

Re: [PATCH 4/6] Protectable Memory

On Mon, Feb 12, 2018 at 01:43:11PM +0200, Mike Rapoport wrote: > On Mon, Feb 12, 2018 at 01:26:28PM +0200, Igor Stoppa wrote: > > On 11/02/18 14:37, Mike Rapoport wrote: > > > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote: > > > > >> + * Return: 0 if the object does not belong to

Re: [PATCH 4/6] Protectable Memory

On Mon, Feb 12, 2018 at 01:26:28PM +0200, Igor Stoppa wrote: > On 11/02/18 14:37, Mike Rapoport wrote: > > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote: > > >> + * Return: 0 if the object does not belong to pmalloc, 1 if it belongs to > >> + * pmalloc, -1 if it partially overlaps

Re: [PATCH 4/6] Protectable Memory

On Mon, Feb 12, 2018 at 01:26:28PM +0200, Igor Stoppa wrote: > On 11/02/18 14:37, Mike Rapoport wrote: > > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote: > > >> + * Return: 0 if the object does not belong to pmalloc, 1 if it belongs to > >> + * pmalloc, -1 if it partially overlaps

Re: [PATCH 4/6] Protectable Memory

On 11/02/18 14:37, Mike Rapoport wrote: > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote: >> + * Return: 0 if the object does not belong to pmalloc, 1 if it belongs to >> + * pmalloc, -1 if it partially overlaps pmalloc meory, but incorectly. > > typo:

Re: [PATCH 4/6] Protectable Memory

On 11/02/18 14:37, Mike Rapoport wrote: > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote: >> + * Return: 0 if the object does not belong to pmalloc, 1 if it belongs to >> + * pmalloc, -1 if it partially overlaps pmalloc meory, but incorectly. > > typo:

Re: [PATCH 4/6] Protectable Memory

On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote: > The MMU available in many systems running Linux can often provide R/O > protection to the memory pages it handles. > > However, the MMU-based protection works efficiently only when said pages > contain exclusively data that will not

Re: [PATCH 4/6] Protectable Memory

On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote: > The MMU available in many systems running Linux can often provide R/O > protection to the memory pages it handles. > > However, the MMU-based protection works efficiently only when said pages > contain exclusively data that will not

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

Re: [PATCH 4/6] Protectable Memory

On 05/02/18 00:06, Randy Dunlap wrote: > On 02/04/2018 08:47 AM, Igor Stoppa wrote: [...] >> + * pmalloc_create_pool - create a new protectable memory pool - > > Drop trailing " -". yes >> + * @name: the name of the pool, must be unique > > Is that enforced? Will return NULL if @name is

Re: [PATCH 4/6] Protectable Memory

On 05/02/18 00:06, Randy Dunlap wrote: > On 02/04/2018 08:47 AM, Igor Stoppa wrote: [...] >> + * pmalloc_create_pool - create a new protectable memory pool - > > Drop trailing " -". yes >> + * @name: the name of the pool, must be unique > > Is that enforced? Will return NULL if @name is

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 05/02/18 17:40, Christopher Lameter wrote: > On Sat, 3 Feb 2018, Igor Stoppa wrote: > >>> We could even do this in a more thorough way. Can we use a ring 1 / 2 >>> distinction to create a hardened OS core that policies the rest of >>> the ever expanding kernel with all its modules and this

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 05/02/18 17:40, Christopher Lameter wrote: > On Sat, 3 Feb 2018, Igor Stoppa wrote: > >>> We could even do this in a more thorough way. Can we use a ring 1 / 2 >>> distinction to create a hardened OS core that policies the rest of >>> the ever expanding kernel with all its modules and this

Re: [PATCH 4/6] Protectable Memory

Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on kees/for-next/pstore] [also build test ERROR on v4.15] [cannot apply to linus/master mmotm/master next-20180207] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

Re: [PATCH 4/6] Protectable Memory

Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on kees/for-next/pstore] [also build test ERROR on v4.15] [cannot apply to linus/master mmotm/master next-20180207] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

Re: [PATCH 4/6] Protectable Memory

Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on kees/for-next/pstore] [also build test ERROR on v4.15] [cannot apply to linus/master mmotm/master next-20180206] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

Re: [PATCH 4/6] Protectable Memory

Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on kees/for-next/pstore] [also build test ERROR on v4.15] [cannot apply to linus/master mmotm/master next-20180206] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Sat, 3 Feb 2018, Igor Stoppa wrote: > > We could even do this in a more thorough way. Can we use a ring 1 / 2 > > distinction to create a hardened OS core that policies the rest of > > the ever expanding kernel with all its modules and this and that feature? > > What would be the

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Sat, 3 Feb 2018, Igor Stoppa wrote: > > We could even do this in a more thorough way. Can we use a ring 1 / 2 > > distinction to create a hardened OS core that policies the rest of > > the ever expanding kernel with all its modules and this and that feature? > > What would be the

Re: [PATCH 4/6] Protectable Memory

On 02/04/2018 08:47 AM, Igor Stoppa wrote: > The MMU available in many systems running Linux can often provide R/O > protection to the memory pages it handles. > > However, the MMU-based protection works efficiently only when said pages > contain exclusively data that will not need further

Re: [PATCH 4/6] Protectable Memory

On 02/04/2018 08:47 AM, Igor Stoppa wrote: > The MMU available in many systems running Linux can often provide R/O > protection to the memory pages it handles. > > However, the MMU-based protection works efficiently only when said pages > contain exclusively data that will not need further

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 04/02/18 00:29, Boris Lukashev wrote: > On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: [...] >> What you are suggesting, if I have understood it correctly, is that, >> when the pool is protected, the addresses already given out, will become >> traps that get

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 04/02/18 00:29, Boris Lukashev wrote: > On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: [...] >> What you are suggesting, if I have understood it correctly, is that, >> when the pool is protected, the addresses already given out, will become >> traps that get resolved through a lookup

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: > > > On 03/02/18 22:12, Boris Lukashev wrote: > >> Regarding the notion of validated protected memory, is there a method >> by which the resulting checksum could be used in a lookup >> table/function to resolve the

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa wrote: > > > On 03/02/18 22:12, Boris Lukashev wrote: > >> Regarding the notion of validated protected memory, is there a method >> by which the resulting checksum could be used in a lookup >> table/function to resolve the location of the protected

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 03/02/18 22:12, Boris Lukashev wrote: > Regarding the notion of validated protected memory, is there a method > by which the resulting checksum could be used in a lookup > table/function to resolve the location of the protected data? What I have in mind is a checksum at page/vmap_area

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 03/02/18 22:12, Boris Lukashev wrote: > Regarding the notion of validated protected memory, is there a method > by which the resulting checksum could be used in a lookup > table/function to resolve the location of the protected data? What I have in mind is a checksum at page/vmap_area

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Sat, Feb 3, 2018 at 2:57 PM, Igor Stoppa wrote: >>> On Thu, 25 Jan 2018, Matthew Wilcox wrote: > It's worth having a discussion about whether we want the pmalloc API or whether we want a slab-based API. > I'd love to have some feedback specifically about the

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Sat, Feb 3, 2018 at 2:57 PM, Igor Stoppa wrote: >>> On Thu, 25 Jan 2018, Matthew Wilcox wrote: > It's worth having a discussion about whether we want the pmalloc API or whether we want a slab-based API. > I'd love to have some feedback specifically about the API. > > I have also some

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

>> On Thu, 25 Jan 2018, Matthew Wilcox wrote: >>> It's worth having a discussion about whether we want the pmalloc API >>> or whether we want a slab-based API. I'd love to have some feedback specifically about the API. I have also some idea about userspace and how to extend the pmalloc concept

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

>> On Thu, 25 Jan 2018, Matthew Wilcox wrote: >>> It's worth having a discussion about whether we want the pmalloc API >>> or whether we want a slab-based API. I'd love to have some feedback specifically about the API. I have also some idea about userspace and how to extend the pmalloc concept

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

+Boris Lukashev On 02/02/18 20:39, Christopher Lameter wrote: > On Thu, 25 Jan 2018, Matthew Wilcox wrote: > >> It's worth having a discussion about whether we want the pmalloc API >> or whether we want a slab-based API. We can have a separate discussion >> about an API to remove pages from the

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

+Boris Lukashev On 02/02/18 20:39, Christopher Lameter wrote: > On Thu, 25 Jan 2018, Matthew Wilcox wrote: > >> It's worth having a discussion about whether we want the pmalloc API >> or whether we want a slab-based API. We can have a separate discussion >> about an API to remove pages from the

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Thu, 25 Jan 2018, Matthew Wilcox wrote: > It's worth having a discussion about whether we want the pmalloc API > or whether we want a slab-based API. We can have a separate discussion > about an API to remove pages from the physmap. We could even do this in a more thorough way. Can we use a

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Thu, 25 Jan 2018, Matthew Wilcox wrote: > It's worth having a discussion about whether we want the pmalloc API > or whether we want a slab-based API. We can have a separate discussion > about an API to remove pages from the physmap. We could even do this in a more thorough way. Can we use a

Re: [PATCH 4/6] Protectable Memory

Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.15] [cannot apply to next-20180201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 4/6] Protectable Memory

Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.15] [cannot apply to next-20180201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 4/6] Protectable Memory

Hi Igor, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15] [cannot apply to next-20180201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 4/6] Protectable Memory

Hi Igor, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15] [cannot apply to next-20180201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 26/01/18 18:36, Boris Lukashev wrote: > I like the idea of making the verification call optional for consumers > allowing for fast/slow+hard paths depending on their needs. > Cant see any additional vectors for abuse (other than the original > ones effecting out-of-band modification) introduced

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 26/01/18 18:36, Boris Lukashev wrote: > I like the idea of making the verification call optional for consumers > allowing for fast/slow+hard paths depending on their needs. > Cant see any additional vectors for abuse (other than the original > ones effecting out-of-band modification) introduced

Re: [PATCH 4/6] Protectable Memory

On 24/01/18 19:56, Igor Stoppa wrote: [...] > +bool pmalloc_prealloc(struct gen_pool *pool, size_t size) > +{ [...] > +abort: > + vfree(chunk); this should be vfree_atomic() [...] > +void *pmalloc(struct gen_pool *pool, size_t size, gfp_t gfp) > +{ [...] > +free: > + vfree(chunk);

Re: [PATCH 4/6] Protectable Memory

On 24/01/18 19:56, Igor Stoppa wrote: [...] > +bool pmalloc_prealloc(struct gen_pool *pool, size_t size) > +{ [...] > +abort: > + vfree(chunk); this should be vfree_atomic() [...] > +void *pmalloc(struct gen_pool *pool, size_t size, gfp_t gfp) > +{ [...] > +free: > + vfree(chunk);

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Fri, Jan 26, 2018 at 7:28 AM, Igor Stoppa wrote: > On 25/01/18 17:38, Jerome Glisse wrote: >> On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote: >>> On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa wrote: >> >> [...] >> >>> DMA/physmap

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Fri, Jan 26, 2018 at 7:28 AM, Igor Stoppa wrote: > On 25/01/18 17:38, Jerome Glisse wrote: >> On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote: >>> On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa wrote: >> >> [...] >> >>> DMA/physmap access coupled with a knowledge of which virtual

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 25/01/18 17:38, Jerome Glisse wrote: > On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote: >> On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa wrote: > > [...] > >> DMA/physmap access coupled with a knowledge of which virtual mappings >> are in the physical

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 25/01/18 17:38, Jerome Glisse wrote: > On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote: >> On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa wrote: > > [...] > >> DMA/physmap access coupled with a knowledge of which virtual mappings >> are in the physical space should be enough for

  1   2   >