> -Original Message-
> From: Huang, Kai
> Sent: Thursday, August 7, 2025 3:24 AM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Huang, Kai
> Sent: Thursday, August 7, 2025 3:15 AM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Huang, Kai
> Sent: Thursday, August 7, 2025 2:42 AM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Huang, Kai
> Sent: Thursday, August 7, 2025 2:50 AM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Huang, Kai
> Sent: Thursday, August 7, 2025 2:40 AM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Huang, Kai
> Sent: Thursday, August 7, 2025 2:39 AM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Hansen, Dave
> Sent: Monday, August 4, 2025 5:20 PM
> To: Reshetova, Elena
> Cc: jar...@kernel.org; sea...@google.com; Huang, Kai
> ; mi...@kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; Mallick
> -Original Message-
> From: Hansen, Dave
> Sent: Friday, August 1, 2025 8:13 PM
> To: Reshetova, Elena
> Cc: jar...@kernel.org; sea...@google.com; Huang, Kai
> ; mi...@kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; Mallick
> -Original Message-
> From: Hansen, Dave
> Sent: Friday, August 1, 2025 7:57 PM
> To: Reshetova, Elena
> Cc: jar...@kernel.org; sea...@google.com; Huang, Kai
> ; mi...@kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; Mallick
> -Original Message-
> From: Hansen, Dave
> Sent: Friday, August 1, 2025 7:45 PM
> To: Reshetova, Elena
> Cc: jar...@kernel.org; sea...@google.com; Huang, Kai
> ; mi...@kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; Mallick
> On 8/1/25 04:25, Elena Reshetova wrote:
> > In order to introduce the counting of active sgx users on top
> > of clean functions that allocate vepc structures, covert existing
> > sgx_(vepc_)open to __sgx_(vepc_)open. Later patch will introduce the
> > top level wrappers that manage the usage c
> -Original Message-
> From: Huang, Kai
> Sent: Friday, July 25, 2025 12:43 AM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; linux-...@vger.kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linu
> -Original Message-
> From: Huang, Kai
> Sent: Thursday, July 24, 2025 2:13 PM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Huang, Kai
> Sent: Thursday, July 24, 2025 1:18 PM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Huang, Kai
> Sent: Thursday, July 24, 2025 1:25 PM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: sea...@google.com; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; jar...@kernel.org;
> Annapurve, Vishal ; linux-kernel@vg
> -Original Message-
> From: Hansen, Dave
> Sent: Monday, July 21, 2025 7:48 PM
> To: Reshetova, Elena
> Cc: jar...@kernel.org; sea...@google.com; Huang, Kai
> ; mi...@kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; Mallick
>
> On Sat, Jul 19, 2025 at 02:15:16PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Jul 15, 2025 at 03:40:18PM +0300, Elena Reshetova wrote:
> > > Currently SGX does not have a global counter to count the
> > > active users from userspace or hypervisor. Implement such a counter,
> > > sgx_usage_count
> On Tue, 2025-07-15 at 15:40 +0300, Elena Reshetova wrote:
> > Changes since v7 following reviews by Dave:
> >
> > - change sgx_usage_count to be a normal int type
> > and greatly simplify the sgx_inc_usage_count func.
> > This results in requiring a mutex for each sgx_(vepc_)open
> > but giv
> On 7/11/25 09:50, Elena Reshetova wrote:
> > == Background ==
> >
> > ENCLS[EUPDATESVN] is a new SGX instruction [1] which allows enclave
> > attestation to include information about updated microcode SVN without a
> > reboot. Before an EUPDATESVN operation can be successful, all SGX memory
> > (
> >
> > +/**
> > + * sgx_updatesvn() - Attempt to call ENCLS[EUPDATESVN].
>
> sgx_updatesvn() -> sgx_update_svn():
>
> arch/x86/kernel/cpu/sgx/main.c:941: warning: expecting prototype for
> sgx_updatesvn(). Prototype was for sgx_update_svn() instead
>
>
> > + * This instruction attempts to upd
> -Original Message-
> From: Huang, Kai
> Sent: Tuesday, May 27, 2025 2:20 AM
> To: Reshetova, Elena ; jar...@kernel.org
> Cc: Raynor, Scott ; Hansen, Dave
> ; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; linux-...@vger.kernel.org;
> Annapurv
> -Original Message-
> From: Jarkko Sakkinen
> Sent: Saturday, May 24, 2025 2:46 AM
> To: Hansen, Dave
> Cc: Reshetova, Elena ; sea...@google.com;
> Huang, Kai ; mi...@kernel.org; linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org; x...@kernel.org; Mallick
> -Original Message-
> From: Jarkko Sakkinen
> Sent: Friday, May 23, 2025 6:54 PM
> To: Reshetova, Elena
> Cc: Hansen, Dave ; sea...@google.com; Huang, Kai
> ; mi...@kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; Mallick
> > + /*
> > +* SVN was already up-to-date. This is the most
> > +* common case.
> > +*/
> > + if (ret == SGX_NO_UPDATE)
> > + return 0;
> > +
> > + /*
> > +* SVN update failed due to lack of entropy in DRNG.
> > +* Indicate to userspace that it should retry.
> >
> -Original Message-
> From: Huang, Kai
> Sent: Friday, May 23, 2025 3:18 AM
> To: Reshetova, Elena ; Hansen, Dave
>
> Cc: Raynor, Scott ; sea...@google.com;
> mi...@kernel.org; Scarlata, Vincent R ;
> x...@kernel.org; jar...@kernel.org; Annapurve, Vishal
> ; l
>
> On Mon, May 19, 2025 at 10:24:31AM +0300, Elena Reshetova wrote:
> > SGX enclaves have an attestation mechanism. An enclave might,
> > for instance, need to attest to its state before it is given
> > a special decryption key. Since SGX must trust the CPU microcode,
> > attestation incorporat
> > Yes, meaning is different, see above.
>
> So that's rather convoluted:
>
> atomic64_inc_not_zero(): returns 1 on successful increase, 0 on
> failure
> sgx_inc_usage_count(): returns 0 on successful increase, 1 on
> failure
> sgx_open():returns 0 on
> >
> > > Why not just fail sgx_open() (e.g., return -EBUSY, or -EAGAIN) in that
> > > case?
> > > Userspace can then retry?
> >
> > The idea on the patch was that such a scenario where we run out of entropy
> > should not happen in real life unless RDSEED is under stress (in case we
> > accident
> +/**
> > + * sgx_updatesvn() - Attempt to call ENCLS[EUPDATESVN]
> > + * If EPC is empty, this instruction attempts to update CPUSVN to the
> > + * currently loaded microcode update SVN and generate new
> > + * cryptographic assets.sgx_updatesvn() Most of the time, there will
>
> Is there somet
> Maybe just use raw atomic_inc() and atomic_dec() at the sites?
>
> IMHO, it makes only sense to wrap, when it makes sense to wrap.
You mean for this patch or overall? For overall we discussed in v4
why we would like to raise it to atomic64.
Or do I misunderstand your comment?
Best Regards,
Ele
> > > > diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> > > b/arch/x86/kernel/cpu/sgx/driver.c
> > > > index 7f8d1e11dbee..b5ffe104af4c 100644
> > > > --- a/arch/x86/kernel/cpu/sgx/driver.c
> > > > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > > > @@ -19,6 +19,7 @@ static int sgx_open(struct inode *in
> On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > Currently SGX does not have a global counter to count the
> > active users from userspace or hypervisor. Implement such a counter,
> > sgx_usage_count. It will be used by the driver when attempting
> > to call EUPDATESVN SGX instructio
> * Elena Reshetova wrote:
>
> > Add a flag indicating whenever ENCLS[EUPDATESVN] SGX instruction
> > is supported. This will be used by SGX driver to perform CPU
> > SVN updates.
> >
> > Signed-off-by: Elena Reshetova
> > ---
> > arch/x86/include/asm/cpufeatures.h | 1 +
> > arch/x86/ke
> On Mon, 2025-05-19 at 10:47 +, Huang, Kai wrote:
> > > +/* Counter to count the active SGX users */
> > > +static atomic64_t sgx_usage_count;
> > > +
> > > +int sgx_inc_usage_count(void)
> > > +{
> > > + atomic64_inc(&sgx_usage_count);
> > > + return 0;
> > > +}
> >
> > What's the purpose of
> On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > The SGX attestation architecture assumes a compromise
> > of all running enclaves and cryptographic assets
> > (like internal SGX encryption keys) whenever a microcode
> > update affects SGX. To mitigate the impact of this presumed
> >
> On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> > process can know the execution state of EUPDATESVN and notify
> > userspace.
> >
> > Signed-off-by: Elena Reshetova
> > ---
>
> [...]
>
> >
> > /**
> > @@ -73,6 +74,
> On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > Add a flag indicating whenever ENCLS[EUPDATESVN] SGX instruction
> > is supported. This will be used by SGX driver to perform CPU
> > SVN updates.
> >
> > Signed-off-by: Elena Reshetova
> > ---
> > arch/x86/include/asm/cpufeatures.
> * Elena Reshetova wrote:
>
> > @@ -19,10 +19,15 @@ static int sgx_open(struct inode *inode, struct file
> *file)
> > struct sgx_encl *encl;
> > int ret;
> >
> > + ret = sgx_inc_usage_count();
> > + if (ret)
> > + return -EBUSY;
>
> So if sgx_inc_usage_count() returns no
> > >>> +static bool sgx_has_eupdatesvn;
> > >>
> > >> We have CPUID "caches" of sorts. Why open code this?
> > >
> > > You mean X86_FEATURE_*?
> >
> > Yes.
> >
> > > SGX CPUID is only defined in SGX code currently (btw, I am not sure
> > > why they are made special) so it doesn’t support this.
> >
> On Wed, May 07, 2025 at 02:14:00PM +0300, Elena Reshetova wrote:
>
> > diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> b/arch/x86/kernel/cpu/sgx/driver.c
> > index 7f8d1e11dbee..669e44d61f9f 100644
> > --- a/arch/x86/kernel/cpu/sgx/driver.c
> > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > @@ -19,6
> >>> +static bool sgx_has_eupdatesvn;
> >>
> >> We have CPUID "caches" of sorts. Why open code this?
> >
> > You mean X86_FEATURE_*?
>
> Yes.
>
> > SGX CPUID is only defined in SGX code currently (btw, I am not sure
> > why they are made special) so it doesn’t support this.
>
> It's only used i
Thank you very much for your detailed review, Dave!
Responses inline below.
> On 5/7/25 04:14, Elena Reshetova wrote:
> > In case an SGX vulnerability is discovered and TCB recovery
> > for SGX is triggered, Intel specifies a process that must be
> > followed for a given vulnerability. Steps to
>
> On Wed, Apr 30, 2025 at 06:53:32AM +, Reshetova, Elena wrote:
> > 2. Switch to Sean's approach to execute EUPDATESVN during the
> sgx_open().
> > Btw, Sean do you agree that we don't gain much doing it second time during
> > release() given the mic
> On 4/29/25 04:44, Reshetova, Elena wrote:
> >> On 4/25/25 14:58, Sean Christopherson wrote:
> >>> On Fri, Apr 25, 2025, Dave Hansen wrote:
> >>>> On 4/25/25 14:04, Sean Christopherson wrote:
> >>>>> Userspace is going to be waiting o
> On 4/25/25 14:58, Sean Christopherson wrote:
> > On Fri, Apr 25, 2025, Dave Hansen wrote:
> >> On 4/25/25 14:04, Sean Christopherson wrote:
> >>> Userspace is going to be waiting on ->release() no matter what.
> >> Unless it isn't even involved and it happens automatically.
> > With my Google h
> So then why on earth is the kernel implementing automatic updates? I read
> back
> through most of the cover letters, and IIUC, we went straight from "destroy
> all
> enclaves and force an update" to "blindly try to do EUPDATESVN every time
> the
> number of enclaves goes from 0=>1". Those are
> On Thu, Apr 24, 2025, Elena Reshetova wrote:
> > > On Thu, Apr 24, 2025, Elena Reshetova wrote:
> > > +void sgx_dec_usage_count(void)
> > > +{
> > > + if (atomic_dec_return(&sgx_usage_count))
> > > + return;
> > > +
> > > + guard(mutex)(&sgx_svn_lock);
> > > +
> > > + if (atomic_read(&sgx
> On Thu, Apr 24, 2025, Elena Reshetova wrote:
> > > On Tue, Apr 22, 2025, Kai Huang wrote:
> > > > On Fri, 2025-04-18 at 07:55 -0700, Sean Christopherson wrote:
> > > > > On Tue, Apr 15, 2025, Elena Reshetova wrote:
> > > > > That said, handling this deep in the bowels of EPC page allocation
> see
> On Tue, Apr 22, 2025, Kai Huang wrote:
> > On Fri, 2025-04-18 at 07:55 -0700, Sean Christopherson wrote:
> > > On Tue, Apr 15, 2025, Elena Reshetova wrote:
> > > That said, handling this deep in the bowels of EPC page allocation seems
> > > unnecessary. The only way for there to be no active EP
> On Tue, 2025-04-15 at 14:51 +0300, Elena Reshetova wrote:
> > SGX architecture introduced a new instruction called EUPDATESVN
>
> "a new ENCLS leaf function EUPDATESVN"?
Yes, you are right, better wording, will fix.
>
> > to Ice Lake. It allows updating security SVN version, given that EPC
> On Tue, 2025-04-15 at 14:51 +0300, Elena Reshetova wrote:
> > sgx_nr_free_pages is an atomic that is used to keep track of
> > free EPC pages and detect whenever page reclaiming should start.
> > Since successful execution of ENCLS[EUPDATESVN] requires empty
>
> The mentioning of ENCLS[EUPDATE
>
> On Tue, Apr 08, 2025 at 06:54:14AM +, Reshetova, Elena wrote:
> > >
> > > On Tue, Apr 08, 2025 at 09:40:14AM +0300, Jarkko Sakkinen wrote:
> > > > On Tue, Apr 08, 2025 at 12:06:32AM +, Huang, Kai wrote:
> > > > > On Mon
>
> On Tue, Apr 08, 2025 at 09:40:14AM +0300, Jarkko Sakkinen wrote:
> > On Tue, Apr 08, 2025 at 12:06:32AM +, Huang, Kai wrote:
> > > On Mon, 2025-04-07 at 08:23 +0000, Reshetova, Elena wrote:
> > > > > On Fri, Apr 04, 2025 at 06:53:17AM +, Reshetov
> On Fri, Apr 04, 2025 at 06:53:17AM +0000, Reshetova, Elena wrote:
> > > On Wed, Apr 02, 2025 at 01:11:25PM +0000, Reshetova, Elena wrote:
> > > > > > current SGX kernel code does not handle such errors in any other
> way
> > > > > > than not
>
> On Fri, Mar 28, 2025 at 07:50:43PM +0200, Jarkko Sakkinen wrote:
> > On Fri, Mar 28, 2025 at 02:57:41PM +0200, Elena Reshetova wrote:
> > > SGX architecture introduced a new instruction called EUPDATESVN
> > > to Ice Lake. It allows updating security SVN version, given that EPC
> > > is comple
> On Mon, Mar 31, 2025 at 07:26:45AM +0000, Reshetova, Elena wrote:
> > > > > + default:
> > > > > + pr_err("EUPDATESVN: unknown error %d\n", ret);
> > > > > + break;
> > > > > + }
> >
> On Wed, Apr 02, 2025 at 01:11:25PM +0000, Reshetova, Elena wrote:
> > > > current SGX kernel code does not handle such errors in any other way
> > > > than notifying that operation failed for other ENCLS leaves. So, I don't
> > > > see why ENCLS[E
> On Tue, Apr 01, 2025 at 09:35:33AM +0000, Reshetova, Elena wrote:
> > > > None of these exceptional conditions are fatal or present an
> > > > immediate danger to the system security. So, allowing the re-tries
> > > > seems logical in this case.
> oN Thu, Mar 27, 2025 at 03:29:53PM +0000, Reshetova, Elena wrote:
> >
> > > On Mon, Mar 24, 2025 at 12:12:41PM +, Reshetova, Elena wrote:
> > > > > On Fri, Mar 21, 2025 at 02:34:40PM +0200, Elena Reshetova wrote:
> > > > > > In order to
> On Fri, Mar 28, 2025 at 08:07:24AM +0000, Reshetova, Elena wrote:
> > > Yes but obviously I cannot promise that I'll accept this as it is
> > > until I see the final version
> >
> > Are you saying you prefer *this version with spinlock* vs.
> >
> On Thu, Mar 27, 2025 at 03:42:30PM +0000, Reshetova, Elena wrote:
> > > > > > + case SGX_NO_UPDATE:
> > > > > > + pr_debug("EUPDATESVN was successful, but CPUSVN
> was not
> > > > > updated, "
> > > > &
> On Mon, Mar 24, 2025 at 12:26:38PM +0000, Reshetova, Elena wrote:
> >
> > > On Fri, Mar 21, 2025 at 02:34:43PM +0200, Elena Reshetova wrote:
> > > > SGX architecture introduced a new instruction called EUPDATESVN [1]
> > > > to Ice Lake. It allows upd
> On Mon, Mar 24, 2025 at 12:21:14PM +0000, Reshetova, Elena wrote:
> >
> >
> > > On Fri, Mar 21, 2025 at 02:34:42PM +0200, Elena Reshetova wrote:
> > > > Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> > > > pr
> On Mon, Mar 24, 2025 at 12:19:37PM +0000, Reshetova, Elena wrote:
> >
> > > On Fri, Mar 21, 2025 at 02:34:41PM +0200, Elena Reshetova wrote:
> > > > sgx_nr_free_pages is an atomic that is used to keep track of
> > > > free EPC pages and detect whenever p
> On Mon, Mar 24, 2025 at 12:12:41PM +0000, Reshetova, Elena wrote:
> > > On Fri, Mar 21, 2025 at 02:34:40PM +0200, Elena Reshetova wrote:
> > > > In order to successfully execute ENCLS[EUPDATESVN], EPC must be
> empty.
> > > > SGX already has a vari
> On Fri, Mar 21, 2025 at 02:34:42PM +0200, Elena Reshetova wrote:
> > Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> > process can know the execution state of EUPDATESVN.
> >
>
> Enumerate the error codes.
You mean in the commit message or?
> Do we need all of the three ad
> On Fri, Mar 21, 2025 at 02:34:43PM +0200, Elena Reshetova wrote:
> > SGX architecture introduced a new instruction called EUPDATESVN [1]
> > to Ice Lake. It allows updating security SVN version, given that EPC
> > is completely empty. The latter is required for security reasons
> > in order to
> On Fri, Mar 21, 2025 at 02:34:41PM +0200, Elena Reshetova wrote:
> > sgx_nr_free_pages is an atomic that is used to keep track of
> > free EPC pages and detect whenever page reclaiming should start.
> > Since successful execution of ENCLS[EUPDATESVN] requires empty
> > EPC and a fast way of che
> On Fri, Mar 21, 2025 at 02:34:40PM +0200, Elena Reshetova wrote:
> > In order to successfully execute ENCLS[EUPDATESVN], EPC must be empty.
> > SGX already has a variable sgx_nr_free_pages that tracks free
> > EPC pages. Add a new variable, sgx_nr_total_pages, that will keep
> > track of total nu
> > I have these ones also here in case anyone is interested:
> > https://github.com/ereshetova/linux-stable/commits/refcount_t_fs
> > https://github.com/ereshetova/linux-stable/commits/refcount_t_block
> >
> > They haven't been rebased for a while, but if there is an interest,
> > I can certainly
> On Mon, Jun 15, 2020 at 10:10:08AM +0800, Xiaoming Ni wrote:
> > On 2020/6/13 2:34, Kees Cook wrote:
> > > This series was never applied[1], and was recently pointed out as
> > > missing[2]. If someone has a tree for this, please take it. Otherwise,
> > > please Ack and I'll send it to Linus.
> >
>> The in-stack randomization is really a very small change both code wise and
>> logic wise.
>> It does not affect real workloads and does not require enablement of other
>> features (such as GCC plugins).
>> So, I think we should really reconsider its inclusion.
>I'd agree: the code is tiny and
Ingo, Andy,
I want to summarize here the data (including the performance numbers)
and reasoning for the in-stack randomization feature. I have organized
it in a simple set of Q&A below.
Q: Why do we need in-stack per-syscall randomization when we already have
all known attack vectors covered with
> I confess I've kind of lost the plot on the performance requirements
> at this point. Instead of measuring and evaluating potential
> solutions, can we try to approach this from the opposite direction and
> ask what the requirements are?
>
> What's the maximum number of CPU cycles that we are a
> > With 5 bits there's a ~96.9% chance of crashing the system in an attempt,
> > the exploit cannot be used for a range of attacks, including spear
> > attacks and fast-spreading worms, right? A crashed and inaccessible
> > system also increases the odds of leaving around unfinished attack code
>
> > I find it ridiculous that even with 4K blocked get_random_bytes(), which
> > gives us 32k bits, which with 5 bits should amortize the RNG call to
> > something like "once per 6553 calls", we still see 17% overhead? It's
> > either a measurement artifact, or something doesn't compute.
>
> If
> * Reshetova, Elena wrote:
>
> > > * Reshetova, Elena wrote:
> > >
> > > > CONFIG_PAGE_TABLE_ISOLATION=n:
> > > >
> > > > base: Simple syscall: 0.0510
> > > > microsecon
> * Reshetova, Elena wrote:
>
> > CONFIG_PAGE_TABLE_ISOLATION=n:
> >
> > base: Simple syscall: 0.0510 microseconds
> > get_random_bytes(4096 bytes buffer): Simple syscall: 0.0597 microseconds
> >
> > So, pure speed w
..
> > rdrand (calling every 8 syscalls): Simple syscall: 0.0795 microseconds
>
> You could try something like:
> u64 rand_val = cpu_var->syscall_rand
>
> while (unlikely(rand_val == 0))
> rand_val = rdrand64();
>
> stack_offset = rand_val & 0xff;
> rand_val
> * Andy Lutomirski wrote:
>
> > Or we decide that calling get_random_bytes() is okay with IRQs off and
> > this all gets a bit simpler.
>
> BTW., before we go down this path any further, is the plan to bind this
> feature to a real CPU-RNG capability, i.e. to the RDRAND instruction,
> which exc
> From: Reshetova, Elena
> > Sent: 03 May 2019 17:17
> ...
> > rdrand (calling every 8 syscalls): Simple syscall: 0.0795 microseconds
>
> You could try something like:
> u64 rand_val = cpu_var->syscall_rand
>
> while (unlikely(rand_val == 0))
>> On Fri, May 3, 2019 at 9:40 AM David Laight wrote:
> >
> > That gives you 10 system calls per rdrand instruction
> > and mostly takes the latency out of line.
>
> Do we really want to do this? What is the attack scenario?
>
> With no VLA's, and the stackleak plugin, what's the upside? Are we
> * David Laight wrote:
>
> > It has already been measured - it is far too slow.
>
> I don't think proper buffering was tested, was it? Only a per syscall
> RDRAND overhead which I can imagine being not too good.
>
Well, I have some numbers, but I am struggling to understand one
aspect there.
From: Reshetova, Elena
> > Sent: 30 April 2019 18:51
> ...
> > +unsigned char random_get_byte(void)
> > +{
> > +struct rnd_buffer *buffer = &get_cpu_var(stack_rand_offset);
> > +unsigned char res;
> > +
> > +
> From: Reshetova, Elena
> > Sent: 30 April 2019 18:51
> ...
> > I guess this is true, so I did a quick implementation now to estimate the
> > performance hits.
> > Here are the preliminary numbers (proper ones will take a bit more time):
> >
> >
>
> > On Apr 29, 2019, at 12:46 AM, Reshetova, Elena
> wrote:
> >
> >
> >>>> On Apr 26, 2019, at 7:01 AM, Theodore Ts'o wrote:
> >>>
> >
> >> It seems to me
> >> that we should be using the “fast-erasure” constructi
> On Fri, Apr 26, 2019 at 10:01:02AM -0400, Theodore Ts'o wrote:
> > On Fri, Apr 26, 2019 at 11:33:09AM +0000, Reshetova, Elena wrote:
> > > Adding Eric and Herbert to continue discussion for the chacha part.
> > > So, as a short summary I am trying to fi
> On Fri, Apr 26, 2019 at 11:33:09AM +0000, Reshetova, Elena wrote:
> > Adding Eric and Herbert to continue discussion for the chacha part.
> > So, as a short summary I am trying to find out a fast (fast enough to be
> > used per
> syscall
> > invocation) source o
> > On Apr 26, 2019, at 7:01 AM, Theodore Ts'o wrote:
> >
> >> On Fri, Apr 26, 2019 at 11:33:09AM +, Reshetova, Elena wrote:
> >> Adding Eric and Herbert to continue discussion for the chacha part.
> >> So, as a short summary I am trying to find
> Hi,
>
> Sorry for the delay - Easter holidays + I was trying to arrange my brain
> around
> proposed options.
> Here what I think our options are with regards to the source of randomness:
>
> 1) rdtsc or variations based on it (David proposed some CRC-based variants for
> example)
> 2) prandom
> From: Reshetova, Elena
> > Sent: 24 April 2019 12:43
> >
> > Sorry for the delay - Easter holidays + I was trying to arrange my brain
> > around
> proposed options.
> > Here what I think our options are with regards to the source of randomness:
> >
>
Hi,
Sorry for the delay - Easter holidays + I was trying to arrange my brain around
proposed options.
Here what I think our options are with regards to the source of randomness:
1) rdtsc or variations based on it (David proposed some CRC-based variants for
example)
2) prandom-based options
3
> On Tue, Apr 16, 2019 at 11:10:16AM +0000, Reshetova, Elena wrote:
> > >
> > > The kernel can execute millions of syscalls per second, I'm pretty sure
> > > there's a statistical attack against:
> > >
> > > * This is a maximally equid
> So a couple of comments; I wasn't able to find the full context for
> this patch, and looking over the thread on kernel-hardening from late
> February still left me confused exactly what attacks this would help
> us protect against (since this isn't my area and I didn't take the
> time to read al
Adding Theodore & Daniel since I guess they are the best positioned to comment
on
exact strengths of prandom. See my comments below.
> * Reshetova, Elena wrote:
>
> > > 4)
> > >
> > > But before you tweak the patch, a more fundamental question:
> > &
Hi Ingo,
Thank you for your feedback! See my comments below.
> * Elena Reshetova wrote:
>
> > This is an example of produced assembly code for gcc x86_64:
> >
> > ...
> > add_random_stack_offset();
> > 0x810022e9 callq 0x81459570
> > 0x810022ee movzbl %al,%eax
> >
> On Wed, Apr 10, 2019 at 3:24 AM Reshetova, Elena
> wrote:
> >
> >
> > > > > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > > > > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > > > > &g
> * Elena Reshetova wrote:
>
> > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys
> > base:1000 loops in 1.62224s
> > = 162.22 nsec / loop
> > random_offset (prandom_u32() every syscall): 1000 loops in 1.64660s
> > =
> 166.2
> > > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > > > index 7bc105f47d21..38ddc213a5e9 100644
> > > > --- a/arch/x86/entry/common.c
> > > > +++ b/arch/x86/entry/common.c
> > > > @@ -35,6 +35,12 @@
> >
> * Josh Poimboeuf wrote:
>
> > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > > index 7bc105f47d21..38ddc213a5e9 100644
> > > --- a/arch/x86/entry/common.c
> > > +++ b/arch/x86/entry/common.c
> > > @@ -35,
1 - 100 of 278 matches
Mail list logo
