On 25-04-16 10:34, Jarkko Sakkinen wrote:
> diff --git a/drivers/staging/intel_sgx/isgx_ioctl.c
b/drivers/staging/intel_sgx/isgx_ioctl.c
> new file mode 100644
> index 000..9d8b36b
> --- /dev/null
> +++ b/drivers/staging/intel_sgx/isgx_ioctl.c
>
> +static long isgx_ioctl_enclave_create(struct f
> From: Cathy Avery [mailto:cav...@redhat.com]
> Sent: Wednesday, April 27, 2016 0:19
> To: Dexuan Cui ; gre...@linuxfoundation.org;
> da...@davemloft.net; net...@vger.kernel.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; Jason Wang
> ; KY Srinivasan ; Haiyang Zh
On Tue, Apr 26, 2016 at 2:52 PM, Pavel Machek wrote:
> On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote:
>> > But... that will mean that my ssh will need to be SGX-aware, and that
>> > I will not be able to switch to AMD machine in future. ... or to other
>> > Intel machine for that matter, r
On Apr 26, 2016 1:11 PM, "Pavel Machek" wrote:
>
> Hi!
>
> > >> >> The firmware uses PRMRR registers to reserve an area of physical
> > >> >> memory
> > >> >> called Enclave Page Cache (EPC). There is a hardware unit in the
> > >> >> processor called Memory Encryption Engine. The MEE encrypts and
On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote:
> > But... that will mean that my ssh will need to be SGX-aware, and that
> > I will not be able to switch to AMD machine in future. ... or to other
> > Intel machine for that matter, right?
>
> I'm not privy to AMD's CPU design plans.
>
> Ho
> But... that will mean that my ssh will need to be SGX-aware, and that
> I will not be able to switch to AMD machine in future. ... or to other
> Intel machine for that matter, right?
I'm not privy to AMD's CPU design plans.
However I think for the ssl/ssh case you'd use the same interfaces
curr
> > Storing your ssh private key encrypted such that even someone who
> > completely compromises your system can't get the actual private key
>
> Well, if someone gets root on my system, he can get my ssh private
> key right?
Potentially not. If you are using a TPM or other TEE (such as SGX
> Replay Protected Memory Block. It's a device that allows someone to
> write to it and confirm that the write happened and the old contents
> is no longer available. You could use it to implement an enclave that
> checks a password for your disk but only allows you to try a certain
> number of t
Hi!
> >> >> The firmware uses PRMRR registers to reserve an area of physical memory
> >> >> called Enclave Page Cache (EPC). There is a hardware unit in the
> >> >> processor called Memory Encryption Engine. The MEE encrypts and decrypts
> >> >> the EPC pages as they enter and leave the processor
On Tue, Apr 26, 2016 at 12:41 PM, Pavel Machek wrote:
> On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote:
>> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
>> >> Intel(R) SGX is a set of CPU instructions that can be used by
>> >> app
On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote:
> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote:
> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> >> Intel(R) SGX is a set of CPU instructions that can be used by
> >> applications to set aside private regions of code and data. The
On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> Intel(R) SGX is a set of CPU instructions that can be used by
> applications to set aside private regions of code and data. The code
> outside the enclave is disallowed to access the memory inside the
> enclave by the CPU access control.
>
> Th
On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote:
> On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
>> Intel(R) SGX is a set of CPU instructions that can be used by
>> applications to set aside private regions of code and data. The code
>> outside the enclave is disallowed to access the me
Hi,
I will be working with Dexuan to possibly port this functionality into RHEL.
Here are my initial comments. Mostly stylistic. They are prefaced by CAA.
Thanks,
Cathy Avery
On 04/07/2016 09:36 PM, Dexuan Cui wrote:
Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechan
NULL comparison has been changed to correct coding style.
---
drivers/staging/speakup/i18n.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/speakup/i18n.c b/drivers/staging/speakup/i18n.c
index 8960079..a031a2d 100644
--- a/drivers/staging/speakup/i18n.c
++
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than ze
From: Gustavo Padovan
Hi Greg,
This patchset clean up the Sync ABI and then improve in to a more optimized
version. Also it is now less likely to need changes in the future. This is not
breaking any upstream user of the sync framework, as no driver wired support
for it, so far Android is the o
From: Gustavo Padovan
This function had copies in 3 different files. Unify them in kernel.h.
Cc: Joe Perches
Cc: Andrew Morton
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
Acked-by: Daniel Vetter[drm/i915/]
Acked-by: Rob Clark[drm/
On 26/04/16 15:47, Parth Sane wrote:
> Hi,
> Yes you are right on that regard. I did do that in my previous patches.
> It’s just something that I will have to remember now onwards. Thanks.
> Regards,
> Parth Sane
Sure. It isn't a big issue, just thought it was worth mentioning as a tip.
Please ke
On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote:
> +static const char *fence_collection_get_timeline_name(struct fence *fence)
> +{
> + return "no context";
"unbound" to distinguish from fence contexts within a timeline?
> +static bool fence_collection_enable_signaling(struct
On Mon, Apr 25, 2016 at 07:33:28PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Support DRM out-fences creating a sync_file with a fence for each crtc
> update with the DRM_MODE_ATOMIC_OUT_FENCE flag.
>
> We then send an struct drm_out_fences array with the out-fences fds back in
>
On Tue, 2016-04-26 at 11:29 -0300, Gustavo Padovan wrote:
> 2016-04-26 Lucas Stach :
> > Am Donnerstag, den 21.04.2016, 12:38 -0300 schrieb Gustavo Padovan:
> > > From: Gustavo Padovan
> > >
> > > This function had copies in 3 different files. Unify them in kernel.h.
> > >
> > > Cc: Joe Perches
Hi,
Yes you are right on that regard. I did do that in my previous patches.
It’s just something that I will have to remember now onwards. Thanks.
Regards,
Parth Sane
> On 26-Apr-2016, at 8:14 PM, Luis de Bethencourt
> wrote:
>
> On 26/04/16 15:33, Parth Sane wrote:
>> Hi,
>> Thanks for the feedb
On 26/04/16 15:33, Parth Sane wrote:
> Hi,
> Thanks for the feedback. I did find this issue with the assistance
> checkpatch.pl script.
> Regards,
> Parth Sane
Normally people mention the checkpatch warning they are fixing.
For example:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux
On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct fence_collection inherits from struct fence and carries a
> collection of fences that needs to be waited together.
>
> It is useful to translate a sync_file to a fence to remove the complexity
> o
Hi,
Thanks for the feedback. I did find this issue with the assistance
checkpatch.pl script.
Regards,
Parth Sane
> On 26-Apr-2016, at 8:00 PM, Luis de Bethencourt
> wrote:
>
> On 25/04/16 16:43, Parth Sane wrote:
>> Fixed alignment to match open parenthesis.
>>
>> Signed-off-by: Parth Sane
>>
On 25/04/16 16:43, Parth Sane wrote:
> Fixed alignment to match open parenthesis.
>
> Signed-off-by: Parth Sane
>
> ---
> Changes in v6:
> -Added line before Signed-off message
>
This last version looks good to me. Did you find this issue with checkpatch.pl?
Thanks,
Luis
__
2016-04-26 Lucas Stach :
> Am Donnerstag, den 21.04.2016, 12:38 -0300 schrieb Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > This function had copies in 3 different files. Unify them in kernel.h.
> >
> > Cc: Joe Perches
> > Cc: Andrew Morton
> > Cc: David Airlie
> > Cc: Daniel Vetter
>
This patch makes the code better and it's an improvement so I'm fine
with merging it as-is.
On Sun, Apr 24, 2016 at 07:40:13PM +0300, Claudiu Beznea wrote:
> This patch frees memory allocated inside mkimage() in case mkimage()
> or any other subsequent calls inside prism2_fwapply() from prism2fw.c
135791356802467913573
从技术走向管理.xls
Description: Binary data
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Mon, Apr 25, 2016 at 01:01:24PM -0700, Andi Kleen wrote:
> Jarkko Sakkinen writes:
>
>
> > diff --git a/drivers/staging/intel_sgx/TODO b/drivers/staging/intel_sgx/TODO
> > new file mode 100644
> > index 000..05f68c2
> > --- /dev/null
> > +++ b/drivers/staging/intel_sgx/TODO
> > @@ -0,0 +1
On Mon, Apr 25, 2016 at 07:33:27PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Create one timeline context for each CRTC to be able to handle out-fences
> and signal them. It adds a few members to struct drm_crtc: fence_context,
> where we store the context we get from fence_context
On Mon, Apr 25, 2016 at 07:33:25PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> There is now a new property called FENCE_FD attached to every plane
> state that receives the sync_file fd from userspace via the atomic commit
> IOCTL.
I still don't like this property abuse. Also with
Am Donnerstag, den 21.04.2016, 12:38 -0300 schrieb Gustavo Padovan:
> From: Gustavo Padovan
>
> This function had copies in 3 different files. Unify them in kernel.h.
>
> Cc: Joe Perches
> Cc: Andrew Morton
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rob Clark
> Signed-off-by: Gustavo Pado
34 matches
Mail list logo
