Re: [PATCH 1/1] Sealable memory support

Hi Igor, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc3 next-20170602] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/1] Sealable memory support

Hi Igor, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc3 next-20170602] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/1] Sealable memory support

On 28/05/17 21:23, Kees Cook wrote: > On Wed, May 24, 2017 at 10:45 AM, Igor Stoppa wrote: [...] >> If the CPU1 were to forcibly halt anything that can race with it, then >> it would be sure that there was no interference. > > Correct. This is actually what ARM does for

Re: [PATCH 1/1] Sealable memory support

On 28/05/17 21:23, Kees Cook wrote: > On Wed, May 24, 2017 at 10:45 AM, Igor Stoppa wrote: [...] >> If the CPU1 were to forcibly halt anything that can race with it, then >> it would be sure that there was no interference. > > Correct. This is actually what ARM does for doing kernel memory >

Re: [PATCH 1/1] Sealable memory support

Hi Igor, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc3 next-20170531] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/1] Sealable memory support

Hi Igor, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc3 next-20170531] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

If i understand the current direction for smalloc, its to implement it without the ability to "unseal," which has implications on how LSM implementations and other users of these dynamic allocations handle things. If its implemented without a writeable interface for modules which need it, then

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

If i understand the current direction for smalloc, its to implement it without the ability to "unseal," which has implications on how LSM implementations and other users of these dynamic allocations handle things. If its implemented without a writeable interface for modules which need it, then

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

On Sun, May 28, 2017 at 11:56 AM, Boris Lukashev wrote: > So what about a middle ground where CoW semantics are used to enforce > the state of these allocations as RO, but provide a strictly > controlled pathway to read the RO data, copy and modify it, then write > and

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

On Sun, May 28, 2017 at 11:56 AM, Boris Lukashev wrote: > So what about a middle ground where CoW semantics are used to enforce > the state of these allocations as RO, but provide a strictly > controlled pathway to read the RO data, copy and modify it, then write > and seal into a new allocation.

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

One-time sealable memory makes the most sense from a defensive perspective - red team reads this stuff, the races mentioned will be implemented as described to win the day, and probably in other innovative ways. If a gap is left in the implementation, without explicit coverage by an adjacent

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

One-time sealable memory makes the most sense from a defensive perspective - red team reads this stuff, the races mentioned will be implemented as described to win the day, and probably in other innovative ways. If a gap is left in the implementation, without explicit coverage by an adjacent

Re: [PATCH 1/1] Sealable memory support

On Wed, May 24, 2017 at 10:45 AM, Igor Stoppa wrote: > On 23/05/17 23:11, Kees Cook wrote: >> On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa wrote: >> I meant this: >> >> CPU 1 CPU 2 >> create >> alloc >> write >> seal >> ... >> unseal >>

Re: [PATCH 1/1] Sealable memory support

On Wed, May 24, 2017 at 10:45 AM, Igor Stoppa wrote: > On 23/05/17 23:11, Kees Cook wrote: >> On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa wrote: >> I meant this: >> >> CPU 1 CPU 2 >> create >> alloc >> write >> seal >> ... >> unseal >> write >> write >> seal >> >> The CPU 2

Re: [PATCH 1/1] Sealable memory support

On 23/05/17 23:11, Kees Cook wrote: > On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa wrote: [...] > I would want hardened usercopy support as a requirement for using > smalloc(). Without it, we're regressing the over-read protection that > already exists for slab

Re: [PATCH 1/1] Sealable memory support

On 23/05/17 23:11, Kees Cook wrote: > On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa wrote: [...] > I would want hardened usercopy support as a requirement for using > smalloc(). Without it, we're regressing the over-read protection that > already exists for slab objects, if kernel code

Re: [PATCH 1/1] Sealable memory support

On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa wrote: > On 23/05/17 00:38, Kees Cook wrote: >> On Fri, May 19, 2017 at 3:38 AM, Igor Stoppa wrote: > > [...] > >> For the first bit of bikeshedding, should this really be called >> seal/unseal? My mind

Re: [PATCH 1/1] Sealable memory support

On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa wrote: > On 23/05/17 00:38, Kees Cook wrote: >> On Fri, May 19, 2017 at 3:38 AM, Igor Stoppa wrote: > > [...] > >> For the first bit of bikeshedding, should this really be called >> seal/unseal? My mind is probably just broken from having read TPM >>

Re: [PATCH 1/1] Sealable memory support

On 23/05/17 00:38, Kees Cook wrote: > On Fri, May 19, 2017 at 3:38 AM, Igor Stoppa wrote: [...] > For the first bit of bikeshedding, should this really be called > seal/unseal? My mind is probably just broken from having read TPM > documentation, but this isn't really

Re: [PATCH 1/1] Sealable memory support

On 23/05/17 00:38, Kees Cook wrote: > On Fri, May 19, 2017 at 3:38 AM, Igor Stoppa wrote: [...] > For the first bit of bikeshedding, should this really be called > seal/unseal? My mind is probably just broken from having read TPM > documentation, but this isn't really "sealing" as I'd

Re: [PATCH 1/1] Sealable memory support

On Fri, May 19, 2017 at 3:38 AM, Igor Stoppa wrote: > Dynamically allocated variables can be made read only, > after they have been initialized, provided that they reside in memory > pages devoid of any RW data. > > The implementation supplies means to create independent

Re: [PATCH 1/1] Sealable memory support

On Fri, May 19, 2017 at 3:38 AM, Igor Stoppa wrote: > Dynamically allocated variables can be made read only, > after they have been initialized, provided that they reside in memory > pages devoid of any RW data. > > The implementation supplies means to create independent pools of memory, > which

Re: [kernel-hardening] [PATCH 1/1] Sealable memory support

On 20/05/17 11:51, Greg KH wrote: > On Fri, May 19, 2017 at 01:38:11PM +0300, Igor Stoppa wrote: >> Dynamically allocated variables can be made read only, [...] > This is really nice, do you have a follow-on patch showing how any of > the kernel can be changed to use this new subsystem? Yes,

Re: [kernel-hardening] [PATCH 1/1] Sealable memory support

On 20/05/17 11:51, Greg KH wrote: > On Fri, May 19, 2017 at 01:38:11PM +0300, Igor Stoppa wrote: >> Dynamically allocated variables can be made read only, [...] > This is really nice, do you have a follow-on patch showing how any of > the kernel can be changed to use this new subsystem? Yes,

Re: [kernel-hardening] [PATCH 1/1] Sealable memory support

On Fri, May 19, 2017 at 01:38:11PM +0300, Igor Stoppa wrote: > Dynamically allocated variables can be made read only, > after they have been initialized, provided that they reside in memory > pages devoid of any RW data. > > The implementation supplies means to create independent pools of memory,

Re: [kernel-hardening] [PATCH 1/1] Sealable memory support

On Fri, May 19, 2017 at 01:38:11PM +0300, Igor Stoppa wrote: > Dynamically allocated variables can be made read only, > after they have been initialized, provided that they reside in memory > pages devoid of any RW data. > > The implementation supplies means to create independent pools of memory,

[PATCH 1/1] Sealable memory support

Dynamically allocated variables can be made read only, after they have been initialized, provided that they reside in memory pages devoid of any RW data. The implementation supplies means to create independent pools of memory, which can be individually created, sealed/unsealed and destroyed. A

[PATCH 1/1] Sealable memory support

Dynamically allocated variables can be made read only, after they have been initialized, provided that they reside in memory pages devoid of any RW data. The implementation supplies means to create independent pools of memory, which can be individually created, sealed/unsealed and destroyed. A