Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 3 Feb 2018 15:12:20 -0500
From: Boris Lukashev <>
To: Igor Stoppa <>
Cc: Christopher Lameter <>, Matthew Wilcox <>, Jann Horn <>, 
	Jerome Glisse <>, Kees Cook <>, 
	Michal Hocko <>, Laura Abbott <>, 
	Christoph Hellwig <>, 
	linux-security-module <>, Linux-MM <>, 
	kernel list <>, 
	Kernel Hardening <>
Subject: Re: [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 idea about userspace and how to extend the pmalloc
> concept to it:
> I'll be AFK intermittently for about 2 weeks, so i might not be able to
> reply immediately, but from my perspective this would be just the
> beginning of a broader hardening of both kernel and userspace that I'd
> like to pursue.
> --
> igor

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?
Effectively a hash table of protected allocations, with a benefit of
dedup since any data matching the same key would be the same data
(multiple identical cred structs being pushed around). Should leave
the resolver address/csum in recent memory to check against, right?

Boris Lukashev
Systems Architect
Semper Victus

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.