Date: Sat, 3 Feb 2018 15:12:20 -0500 From: Boris Lukashev <blukashev@...pervictus.com> To: Igor Stoppa <igor.stoppa@...wei.com> Cc: Christopher Lameter <cl@...ux.com>, Matthew Wilcox <willy@...radead.org>, Jann Horn <jannh@...gle.com>, Jerome Glisse <jglisse@...hat.com>, Kees Cook <keescook@...omium.org>, Michal Hocko <mhocko@...nel.org>, Laura Abbott <labbott@...hat.com>, Christoph Hellwig <hch@...radead.org>, linux-security-module <linux-security-module@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>, kernel list <linux-kernel@...r.kernel.org>, Kernel Hardening <kernel-hardening@...ts.openwall.com> Subject: Re: [PATCH 4/6] Protectable Memory On Sat, Feb 3, 2018 at 2:57 PM, Igor Stoppa <igor.stoppa@...wei.com> 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: > > http://www.openwall.com/lists/kernel-hardening/2018/01/30/20 > > 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.