From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D31783B2A4 for ; Thu, 4 Jan 2018 17:58:48 -0500 (EST) Received: from smtp24.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9BB3C24B8E; Thu, 4 Jan 2018 17:58:48 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp24.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 95E9424BFF; Thu, 4 Jan 2018 17:58:48 -0500 (EST) Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 78AC024B8E; Thu, 4 Jan 2018 17:58:48 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 04 Jan 2018 17:58:48 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app40.wa-webapps.iad3a (Postfix) with ESMTP id 69C4620055; Thu, 4 Jan 2018 17:58:48 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 4 Jan 2018 17:58:48 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Thu, 4 Jan 2018 17:58:48 -0500 (EST) From: "dpreed@deepplum.com" To: "=?utf-8?Q?Joel_Wir=C4=81mu_Pauling?=" Cc: "Jonathan Morton" , cerowrt-devel@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20180104175848000000_43143" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1515103048.715224709@apps.rackspace.com> <1515103759.340132151@apps.rackspace.com> Message-ID: <1515106728.430510671@apps.rackspace.com> X-Mailer: webmail/12.9.10-RC Subject: [Cerowrt-devel] Spectre and EBPF JIT X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 22:58:48 -0000 ------=_20180104175848000000_43143 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AAs I continue to study the Spectre bug, I read the Project Zero post abo= ut POC's they developed for Spectre.=0A =0A[ https://googleprojectzero.blog= spot.com/2018/01/reading-privileged-memory-with-side.html ]( https://google= projectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html )= =0A =0A(the Meltdown and Spectre papers, linked from that page are far bett= er at explaining the mechanics of the issue. Read Meltdown first, it's simp= ler.).=0A =0AIt was very enlightening to see that one exploit used the "in-= kernel eBPF JIT interpreter". This one also looks very practical to exploit= , and it is "network related" so of some interest here. The Project Zero p= ost doesn't describe the exploit itself, but reading the Spectre paper give= s one context on how Spectre works.=0A =0AUnlike Meltdown, Spectre really d= epends on the attacker being able to force certain instruction sequences to= get executed in some address space, such that the effect can be observed i= n another address space where the attacker's observer resides.=0A =0AWhat t= his means is that to read data from the kernel, Spectre needs to force a sp= ecific code sequence to be executed, with a branch mispredicted, *in the ke= rnel*.=0A =0AThat's where the eBPF JIT comes into play, apparently. Because= the eBPF JIT allows *kernel code* to be constructed from the attackers use= rspace code. Hmmm... sounds like the user can change the kernel binary code= and get it executed!=0A =0ASo this is a relatively practical thing to do, = and it gives full access to anything in the kernel address space, from a us= erspace program.=0A =0ANow it's easy to disable the JIT feature. Just a pac= ket processing performance hit.=0A =0ABut I bet designing the JIT so it won= 't generate Spectre-exploitable code would be tricky indeed.=0A =0AEspecial= ly since the Spectre-exploitable code is highly processor architecture spec= ific, unlike Meltdown, which appears to be Intel-only. ------=_20180104175848000000_43143 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

As I continue to study= the Spectre bug, I read the Project Zero post about POC's they developed f= or Spectre.

=0A

 

=0A

https://googleprojectzero.blogspot.com/2018/01/readi= ng-privileged-memory-with-side.html

=0A

 =0A

(the Meltdown and Spectre papers, linked from tha= t page are far better at explaining the mechanics of the issue. Read Meltdo= wn first, it's simpler.).

=0A

 

=0A

It was very enlightening to see that one exploit used the "in-= kernel eBPF JIT interpreter". This one also looks very practical to exploit= , and it is "network related" so of some interest here.  The Project Z= ero post doesn't describe the exploit itself, but reading the Spectre paper= gives one context on how Spectre works.

=0A

 <= /p>=0A

Unlike Meltdown, Spectre really depends on the a= ttacker being able to force certain instruction sequences to get executed i= n some address space, such that the effect can be observed in another addre= ss space where the attacker's observer resides.

=0A

=  

=0A

What this means is that to read data from= the kernel, Spectre needs to force a specific code sequence to be executed= , with a branch mispredicted, *in the kernel*.

=0A

&= nbsp;

=0A

That's where the eBPF JIT comes into play,= apparently. Because the eBPF JIT allows *kernel code* to be constructed fr= om the attackers userspace code. Hmmm... sounds like the user can change th= e kernel binary code and get it executed!

=0A

 =

=0A

So this is a relatively practical thing to do, = and it gives full access to anything in the kernel address space, from a us= erspace program.

=0A

 

=0A

Now it's easy to disable the JIT feature. Just a packet processing perfo= rmance hit.

=0A

 

=0A

Bu= t I bet designing the JIT so it won't generate Spectre-exploitable code wou= ld be tricky indeed.

=0A

 

=0A

Especially since the Spectre-exploitable code is highly = processor architecture specific, unlike Meltdown, which appears to be Intel= -only.

 ------=_20180104175848000000_43143--