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?
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 conclusio
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 th
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 can
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 bre
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 co
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 brok
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 PAGE_POI
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 hav
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. CONFIG_PA
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. CONFIG_PAGE_P
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 ye
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 physm
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 h
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, F
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 a
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:
>>>
>>>
>>> [...]
>>>
>>>
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, th
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 out,
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 an
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 differentiatin
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 tabl
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 data?
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 level,
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
>> 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
+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
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 r
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
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
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
On 26/01/18 07:35, Matthew Wilcox wrote:
> On Wed, Jan 24, 2018 at 08:10:53PM +0100, Jann Horn wrote:
>> I'm not entirely convinced by the approach of marking small parts of
>> kernel memory as readonly for hardening.
>
> It depends how significant the data stored in there are. For example,
> sto
On Wed, Jan 24, 2018 at 08:10:53PM +0100, Jann Horn wrote:
> I'm not entirely convinced by the approach of marking small parts of
> kernel memory as readonly for hardening.
It depends how significant the data stored in there are. For example,
storing function pointers in read-only memory provides
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 an attacker to bypass
> the gating mechanism this w
On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa wrote:
>
> Hi,
>
> thanks for the review. My reply below.
>
> On 24/01/18 21:10, Jann Horn wrote:
>
> > I'm not entirely convinced by the approach of marking small parts of
> > kernel memory as readonly for hardening.
>
> Because of the physmap you ment
Hi,
thanks for the review. My reply below.
On 24/01/18 21:10, Jann Horn wrote:
> I'm not entirely convinced by the approach of marking small parts of
> kernel memory as readonly for hardening.
Because of the physmap you mention later?
Regarding small parts vs big parts (what is big enough?) I
On Wed, Jan 24, 2018 at 6:56 PM, 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 furthe
37 matches
Mail list logo
