On Thu, May 06, 2021 at 11:47:47AM -0700, James Bottomley wrote:
> On Thu, 2021-05-06 at 10:33 -0700, Kees Cook wrote:
> > On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:
>
> > What's happening with O_CLOEXEC in this code? I don't see that
> > mentioned in the cover letter
On Thu, May 06, 2021 at 11:47:47AM -0700, James Bottomley wrote:
> On Thu, 2021-05-06 at 10:33 -0700, Kees Cook wrote:
> > On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:
> [...]
> > > > I think that a very complete description of the threats which
> > > > this feature addresses
On 07.05.21 01:16, Nick Kossifidis wrote:
Στις 2021-05-06 20:05, James Bottomley έγραψε:
On Thu, 2021-05-06 at 18:45 +0200, David Hildenbrand wrote:
Also, there is a way to still read that memory when root by
1. Having kdump active (which would often be the case, but maybe not
to dump user
Στις 2021-05-06 20:05, James Bottomley έγραψε:
On Thu, 2021-05-06 at 18:45 +0200, David Hildenbrand wrote:
Also, there is a way to still read that memory when root by
1. Having kdump active (which would often be the case, but maybe not
to dump user pages )
2. Triggering a kernel crash (easy
On Thu, 2021-05-06 at 10:33 -0700, Kees Cook wrote:
> On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:
[...]
> >1. Memory safety for user space code. Once the secret memory is
> > allocated, the user can't accidentally pass it into the
> > kernel to be
> >
On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:
> On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote:
> > On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport
> > wrote:
> >
> > > This is an implementation of "secret" mappings backed by a file
> > > descriptor.
tl;dr: I like
Is this intended to protect keys/etc after the attacker has
gained the ability to run arbitrary kernel-mode code? If so,
that seems optimistic, doesn't it?
Not exactly: there are many types of kernel attack, but mostly the
attacker either manages to effect a privilege escalation to root or
On Thu, 2021-05-06 at 18:45 +0200, David Hildenbrand wrote:
> On 06.05.21 17:26, James Bottomley wrote:
> > On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote:
> > > On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport > > >
> > > wrote:
> > >
> > > > This is an implementation of "secret"
On 06.05.21 17:26, James Bottomley wrote:
On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote:
On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport
wrote:
This is an implementation of "secret" mappings backed by a file
descriptor.
The file descriptor backing secret memory mappings is created
On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote:
> On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport
> wrote:
>
> > This is an implementation of "secret" mappings backed by a file
> > descriptor.
> >
> > The file descriptor backing secret memory mappings is created using
> > a dedicated
On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport wrote:
> This is an implementation of "secret" mappings backed by a file descriptor.
>
> The file descriptor backing secret memory mappings is created using a
> dedicated memfd_secret system call The desired protection mode for the
> memory is
11 matches
Mail list logo
