lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 7 Dec 2017 19:37:38 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        platform-driver-x86@...r.kernel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Alexander Viro <viro@...iv.linux.org.uk>,
        "open list:FILESYSTEMS (VFS and infrastructure)" 
        <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and
 replace_fd()

On Mon, Dec 04, 2017 at 11:00:59AM +0200, Jarkko Sakkinen wrote:
> On Thu, Nov 30, 2017 at 10:38:30AM -0800, James Bottomley wrote:
> > On Thu, 2017-11-30 at 18:43 +0200, Jarkko Sakkinen wrote:
> > > On Wed, Nov 29, 2017 at 03:13:57PM -0800, Christoph Hellwig wrote:
> > > > 
> > > > On Tue, Nov 28, 2017 at 11:57:53PM +0200, Jarkko Sakkinen wrote:
> > > > > 
> > > > > > 
> > > > > > Yes.  You still shall not play nasty games with file
> > > > > > descriptors.
> > > > > 
> > > > > I need to put something to file descriptors in order to have a IO
> > > > > channels for the launch enclave hosting process.
> > > > 
> > > > Just do it like any other program - open it from your userspace
> > > > program using open() and related syscalls.
> > > 
> > > In this case it would not work as the launch enclave is still part of
> > > the kernel and it would create a dependency how the user space
> > > defines paths. If using pipe specifically is an issue, I could easily
> > > use shmem file as a mean for communiation.
> > 
> > Can't you simply use 
> > 
> > sys_pipe2()
> > sys_close()
> > sys_dup2()
> > 
> > To achieve the same effect as replace_fd()/create_pipe_files()?
> > 
> > The point Christoph is making is that you can call sys_ interfaces from
> > within the kernel (carefully) and have them operate like direct
> > invocations.  Look at main.c:kernel_init_freeable() it's doing
> > something similar to what you want, except with the console, not a pipe
> > and it begins with the file table empty.
> 
> Thank you. I'll take a peek.

It doesn't apply here as it depends of the filesystem paths.

I think I could replace pipes with anonymous inodes. Is that a better
idea than pipes? I can work on that v8 if the export is a show stopper
as it seems. We are using that to do some other stuff in tpm_vtpm_proxy.

I submitted v7 of the patch set still as a self-contained driver. For
that I'm looking forward to get feedback on:

1. Could the first upstream version be a self-contained driver even if
some stuff would be eventually moved to arch/x86? There is nothing
preventing on doing that and that would be a non-intrusive way to
upstream such a large piece of functionality.
2. If for the first upstream version something needs to be placed to
arch/x86, I would like to get some guidelines on deployment. I guess
it would go under arch/x86/kernel/cpu/sgx?
3. I fixed the AES issue. Is there anything else BIG that needs to be
fixed?

/Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ