* [PATCH 2/2] SolutionEngine771x: add Ether TSU resource
From: Sergei Shtylyov @ 2018-01-06 18:53 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, linux-sh; +Cc: netdev, Sergei Shtylyov
[-- Attachment #1: SolutionEngine771x-add-Ether-TSU-resource-v2.patch --]
[-- Type: text/plain, Size: 2212 bytes --]
After the Ether platform data is fixed, the driver probe() method would
still fail since the 'struct sh_eth_cpu_data' corresponding to SH771x
indicates the presence of TSU but the memory resource for it is absent.
Add the missing TSU resource to both Ether devices and fix the harmless
off-by-one error in the main memory resources, while at it...
Fixes: 4986b996882d ("net: sh_eth: remove the SH_TSU_ADDR")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- corrected the TSU resource size.
arch/sh/boards/mach-se/770x/setup.c | 14 ++++++++++++--
arch/sh/include/mach-se/mach/se.h | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
Index: linux/arch/sh/boards/mach-se/770x/setup.c
===================================================================
--- linux.orig/arch/sh/boards/mach-se/770x/setup.c
+++ linux/arch/sh/boards/mach-se/770x/setup.c
@@ -124,10 +124,15 @@ static struct sh_eth_plat_data sh_eth_pl
static struct resource sh_eth0_resources[] = {
[0] = {
.start = SH_ETH0_BASE,
- .end = SH_ETH0_BASE + 0x1B8,
+ .end = SH_ETH0_BASE + 0x1B8 - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
+ .start = SH_TSU_BASE,
+ .end = SH_TSU_BASE + 0x200 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [2] = {
.start = SH_ETH0_IRQ,
.end = SH_ETH0_IRQ,
.flags = IORESOURCE_IRQ,
@@ -147,10 +152,15 @@ static struct platform_device sh_eth0_de
static struct resource sh_eth1_resources[] = {
[0] = {
.start = SH_ETH1_BASE,
- .end = SH_ETH1_BASE + 0x1B8,
+ .end = SH_ETH1_BASE + 0x1B8 - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
+ .start = SH_TSU_BASE,
+ .end = SH_TSU_BASE + 0x200 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [2] = {
.start = SH_ETH1_IRQ,
.end = SH_ETH1_IRQ,
.flags = IORESOURCE_IRQ,
Index: linux/arch/sh/include/mach-se/mach/se.h
===================================================================
--- linux.orig/arch/sh/include/mach-se/mach/se.h
+++ linux/arch/sh/include/mach-se/mach/se.h
@@ -100,6 +100,7 @@
/* Base address */
#define SH_ETH0_BASE 0xA7000000
#define SH_ETH1_BASE 0xA7000400
+#define SH_TSU_BASE 0xA7000800
/* PHY ID */
#if defined(CONFIG_CPU_SUBTYPE_SH7710)
# define PHY_ID 0x00
^ permalink raw reply
* Re: [iproute2 1/2] ss: fix crash when skipping disabled header field
From: Stefano Brivio @ 2018-01-06 18:53 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20180106183150.10530-1-a@unstable.cc>
On Sun, 7 Jan 2018 02:31:49 +0800
Antonio Quartulli <a@unstable.cc> wrote:
> When the first header field is disabled (i.e. when passing the -t
> option), field_flush() is invoked with the `buffer` global variable
> still zero'd.
> However, in field_flush() we try to access buffer.cur->len
> during variables initialization, thus leading to a SIGSEGV.
Good catch, thanks for fixing this.
> It's interesting to note that this bug appears only when the code
> is compiled with -O0, because the compiler is smart
> enough to immediately jump to the return statement if optimizations
> are enabled and skip the faulty instruction.
I should really have tested all the options with -O0 as well. :( Done
now.
> Cc: Stefano Brivio <sbrivio@redhat.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Antonio Quartulli <a@unstable.cc>
Fixes: 691bd854bf4a ("ss: Buffer raw fields first, then render them as a table")
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
--
Stefano
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Dan Williams @ 2018-01-06 18:54 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alan Cox, Linus Torvalds, Linux Kernel Mailing List, linux-arch,
Andi Kleen, Arnd Bergmann, Greg Kroah-Hartman, Peter Zijlstra,
Netdev, Ingo Molnar, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <20180106183937.vkseldf4arkdlkum@ast-mbp>
On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
[..]
>> retpoline is variant-2, this patch series is about variant-1.
>
> that's exactly the point. Don't slow down the kernel with lfences
> to solve variant 1. retpoline for 2 is ok from long term kernel
> viability perspective.
>
Setting aside that we still need to measure the impact of these
changes the end result will still be nospec_array_ptr() sprinkled in
various locations. So can we save the debate about what's inside that
macro on various architectures and at least proceed with annotating
the problematic locations? Perhaps we can go a step further and have a
config option to switch between the clever array_access() approach
from Linus that might be fine depending on the compiler, and the
cpu-vendor-recommended not to speculate implementation of
nospec_array_ptr().
^ permalink raw reply
* [PATCH 0/2] Ether fixes for the SolutionEngine771x boards
From: Sergei Shtylyov @ 2018-01-06 18:53 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, linux-sh; +Cc: netdev, Sergei Shtylyov
Hello!
Here's the series of 2 patches against Linus' repo. This series should
(hoplefully) fix the Ether support on the SolutionEngine771x boards...
[1/2] SolutionEngine771x: fix Ether platform data
[2/2] SolutionEngine771x: add Ether TSU resource
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 0/2] Ether fixes for the SolutionEngine771x boards
From: Sergei Shtylyov @ 2018-01-06 18:56 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, linux-sh; +Cc: netdev
In-Reply-To: <20180106185325.481875686@cogentembedded.com>
Oops, forgot to add v2 to the subjects... :-/
^ permalink raw reply
* Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
From: Florian Fainelli @ 2018-01-06 18:56 UTC (permalink / raw)
To: Dan Williams, linux-kernel
Cc: Mark Rutland, peterz, Alan Cox, Srinivas Pandruvada, Will Deacon,
Solomon Peachy, H. Peter Anvin, Christian Lamparter,
Elena Reshetova, linux-arch, Andi Kleen, James E.J. Bottomley,
linux-scsi, Jonathan Corbet, x86, Ingo Molnar, Alexey Kuznetsov,
Zhang Rui, linux-media, Arnd Bergmann, Jan Kara, Eduardo Valentin
In-Reply-To: <151520099201.32271.4677179499894422956.stgit@dwillia2-desk3.amr.corp.intel.com>
Le 01/05/18 à 17:09, Dan Williams a écrit :
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [1]
> and the Documentation patch in this series."
>
> This series incorporates Mark Rutland's latest api and adds the x86
> specific implementation of nospec_barrier. The
> nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
> wide analysis performed by Elena Reshetova to address static analysis
> reports where speculative execution on a userspace controlled value
> could bypass a bounds check. The patches address a precondition for the
> attack discussed in the Spectre paper [2].
>
> A consideration worth noting for reviewing these patches is to weigh the
> dramatic cost of being wrong about whether a given report is exploitable
> vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
> lets make the bar for applying these patches be "can you prove that the
> bounds check bypass is *not* exploitable". Consider that the Spectre
> paper reports one example of a speculation window being ~180 cycles.
>
> Note that there is also a proposal from Linus, array_access [3], that
> attempts to quash speculative execution past a bounds check without
> introducing an lfence instruction. That may be a future optimization
> possibility that is compatible with this api, but it would appear to
> need guarantees from the compiler that it is not clear the kernel can
> rely on at this point. It is also not clear that it would be a
> significant performance win vs lfence.
>
> These patches also will also be available via the 'nospec' git branch
> here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec
Although I suppose -stable and distribution maintainers will keep a
close eye on these patches, is there a particular reason why they don't
include the relevant CVE number in their commit messages?
It sounds like Coverity was used to produce these patches? If so, is
there a plan to have smatch (hey Dan) or other open source static
analysis tool be possibly enhanced to do a similar type of work?
Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing
From: Pravin Shelar @ 2018-01-06 18:57 UTC (permalink / raw)
To: Ed Swierk; +Cc: ovs-dev, netdev, Benjamin Warren, Keith Holleman
In-Reply-To: <CAO_EM_=2qt3zSW1xprkLvcQVKGRTFMUQxCc4-cVLsUcRLj63Hg@mail.gmail.com>
On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk <eswierk@skyportsystems.com> wrote:
>
>
> On Jan 5, 2018 22:17, "Pravin Shelar" <pshelar@ovn.org> wrote:
>
> On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk <eswierk@skyportsystems.com>
> wrote:
>> On Fri, Jan 5, 2018 at 10:14 AM, Ed Swierk <eswierk@skyportsystems.com>
>> wrote:
>>> On Thu, Jan 4, 2018 at 7:36 PM, Pravin Shelar <pshelar@ovn.org> wrote:
>>>> OVS already pull all required headers in skb linear data, so no need
>>>> to redo all of it. only check required is the ip-checksum validation.
>>>> I think we could avoid it in most of cases by checking skb length to
>>>> ipheader length before verifying the ip header-checksum.
>>>
>>> Shouldn't the IP header checksum be verified even earlier, like in
>>> key_extract(), before actually using any of the fields in the IP
>>> header?
>>
>> Something like this for verifying the IP header checksum (not tested):
>>
> AFAIU openflow does not need this verification, so it is not required
> in flow extract.
>
>
> Okay. How about my proposed trimming implementation, caching the pad length
> in the ovs cb?
>
Caching the length is not that simple, OVS actions can change the
length. Keeping it consistent with packet would be more work, so lets
calculate it in ovs-ct function.
^ permalink raw reply
* Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
From: Arjan van de Ven @ 2018-01-06 18:59 UTC (permalink / raw)
To: Florian Fainelli, Dan Williams, linux-kernel
Cc: Mark Rutland, peterz, Alan Cox, Srinivas Pandruvada, Will Deacon,
Solomon Peachy, H. Peter Anvin, Christian Lamparter,
Elena Reshetova, linux-arch, Andi Kleen, James E.J. Bottomley,
linux-scsi, Jonathan Corbet, x86, Ingo Molnar, Alexey Kuznetsov,
Zhang Rui, linux-media, Arnd Bergmann, Jan Kara, Eduardo Valentin
In-Reply-To: <ca6f24c0-d6cf-e309-aa68-92f1378ee75a@gmail.com>
> It sounds like Coverity was used to produce these patches? If so, is
> there a plan to have smatch (hey Dan) or other open source static
> analysis tool be possibly enhanced to do a similar type of work?
I'd love for that to happen; the tricky part is being able to have even a
sort of sensible concept of "trusted" vs "untrusted" value...
if you look at a very small window of code, that does not work well;
you likely need to even look (as tool) across .c file boundaries
^ permalink raw reply
* [iproute2 1/2] ss: fix crash when skipping disabled header field
From: Antonio Quartulli @ 2018-01-06 18:31 UTC (permalink / raw)
To: netdev; +Cc: Antonio Quartulli, Stefano Brivio, Stephen Hemminger
When the first header field is disabled (i.e. when passing the -t
option), field_flush() is invoked with the `buffer` global variable
still zero'd.
However, in field_flush() we try to access buffer.cur->len
during variables initialization, thus leading to a SIGSEGV.
It's interesting to note that this bug appears only when the code
is compiled with -O0, because the compiler is smart
enough to immediately jump to the return statement if optimizations
are enabled and skip the faulty instruction.
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
---
misc/ss.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index 1abf43d0..b35859dc 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -1018,12 +1018,15 @@ static void print_right_spacing(struct column *f, int printed)
/* Done with field: update buffer pointer, start new token after current one */
static void field_flush(struct column *f)
{
- struct buf_chunk *chunk = buffer.tail;
- unsigned int pad = buffer.cur->len % 2;
+ struct buf_chunk *chunk;
+ unsigned int pad;
if (f->disabled)
return;
+ chunk = buffer.tail;
+ pad = buffer.cur->len % 2;
+
if (buffer.cur->len > f->max_len)
f->max_len = buffer.cur->len;
--
2.15.1
^ permalink raw reply related
* [iproute2 2/2] ss: fix NULL pointer access when parsing unix sockets with oldformat
From: Antonio Quartulli @ 2018-01-06 18:31 UTC (permalink / raw)
To: netdev; +Cc: Antonio Quartulli, Stefano Brivio, Stephen Hemminger
In-Reply-To: <20180106183150.10530-1-a@unstable.cc>
When parsing and printing the unix sockets in unix_show(),
if the oldformat is detected, the peer_name member of the sockstat
object is left uninitialized (NULL).
For this reason, if a filter has been specified on the command line,
a strcmp() will crash when trying to access it.
Avoid crash by checking that peer_name is not NULL before
passing it to strcmp().
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
---
To crash ss, simply execute the following on a system using the old
socket format:
ss -x dst 192.168.1.1
or
ss dst 192.168.1.1
(crash reproduced on linux-4.12.12)
misc/ss.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/misc/ss.c b/misc/ss.c
index b35859dc..29a25070 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -3711,7 +3711,10 @@ static int unix_show(struct filter *f)
};
memcpy(st.local.data, &u->name, sizeof(u->name));
- if (strcmp(u->peer_name, "*"))
+ /* when parsing the old format rport is set to 0 and
+ * therefore peer_name remains NULL
+ */
+ if (u->peer_name && strcmp(u->peer_name, "*"))
memcpy(st.remote.data, &u->peer_name,
sizeof(u->peer_name));
if (run_ssfilter(f->f, &st) == 0) {
--
2.15.1
^ permalink raw reply related
* Re: [PATCH 02/31] fs: add new vfs_poll and file_can_poll helpers
From: Al Viro @ 2018-01-06 19:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-kernel
In-Reply-To: <20180104080043.14506-3-hch@lst.de>
On Thu, Jan 04, 2018 at 09:00:14AM +0100, Christoph Hellwig wrote:
> These abstract out calls to the poll method in preparation for changes to
> those methods.
FWIW, I would make vfs_poll()
static inline __poll_t vfs_poll(struct file *file, struct poll_table_struct *pt)
{
if (unlikely(!file->f_op->poll))
return DEFAULT_POLLMASK;
return file->f_op->poll(file, pt);
}
That's safe for any struct file, some of the callers already do just that,
the ones that have vfs_poll() under the check for file_can_poll() will
simply optimize that piece away and the few that rely upon the knowledge
of file_operations they are dealing with (vhost, etc.) can bloody well
cope with the cost of the check.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 03/31] fs: introduce new ->get_poll_head and ->poll_mask methods
From: Al Viro @ 2018-01-06 19:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-kernel
In-Reply-To: <20180104080043.14506-4-hch@lst.de>
On Thu, Jan 04, 2018 at 09:00:15AM +0100, Christoph Hellwig wrote:
> ->get_poll_head returns the waitqueue that the poll operation is going
> to sleep on. Note that this means we can only use a single waitqueue
> for the poll, unlike some current drivers that use two waitqueues for
> different events. But now that we have keyed wakeups and heavily use
> those for poll there aren't that many good reason left to keep the
> multiple waitqueues, and if there are any ->poll is still around, the
> driver just won't support aio poll.
*UGH*
Gotta love the optimism, but have you actually done the conversion?
I'm particularly suspicious about the locking rules here...
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 04/31] net: add support for ->poll_mask in proto_ops
From: Al Viro @ 2018-01-06 19:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-kernel
In-Reply-To: <20180104080043.14506-5-hch@lst.de>
On Thu, Jan 04, 2018 at 09:00:16AM +0100, Christoph Hellwig wrote:
> The socket file operations still implement ->poll until all protocols are
> switched over.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/net.h | 3 +++
> net/socket.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++----
> 2 files changed, 60 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/net.h b/include/linux/net.h
> index c2d468cb9821..94d65de30cb7 100644
> --- a/include/linux/net.h
> +++ b/include/linux/net.h
> @@ -147,6 +147,9 @@ struct proto_ops {
> int (*getname) (struct socket *sock,
> struct sockaddr *addr,
> int *sockaddr_len, int peer);
> + void (*pre_poll) (const struct sock *sk);
Description? Or more descriptive name, for that matter...
> + __poll_t (*poll_mask) (struct file *file, struct socket *sock,
> + __poll_t events);
Does that sucker need struct file?
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [RFC PATCH 3/3] tcp: Add tunable parameters for TSQ
From: Natale Patriciello @ 2018-01-06 19:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, carloaugusto.grazia
In-Reply-To: <1515153226.131759.8.camel@gmail.com>
Thank you, Eric and David, for the time spent in reviewing our work.
Some comments inline:
On 05/01/18 at 03:53am, Eric Dumazet wrote:
> I do not want to add yet another condition in fast path.
> Just put an arbitrary large value in the existing sysctl, no need for
> extra code.
Due to the minimum statement at the line 2202, the algorithm will ignore
the arbitrarily large value and will use ~1 ms of data at the current
rate or 2 segments instead. Therefore, right now there is not the
possibility to completely disable TSQ, while there was in the first
version of it.
> You provide dubious reasons, and no real tests done on various
> hardwares.
We did perform some test internally on a 4.13 kernel for an academic
submission. By varying the parameters, we were able to double the
throughput reachable by any congestion {avoidance, control} algorithm on
top of 2.4GHz networks with a channel of 40 MHz, and to reduce latency
(maybe there is some kind of data waiting that is done at
driver/firmware/hardware level). Then we saw the patch, and we became
aware of the community interest in the topic and decided to ask for
feedback on a revised version.
We will for sure increase the number of test cases (including CPU usage)
and report as soon as the academic world allows us. We are happily using
Flent for the testing phase.
> A linux host can have one 10Gbit NIC and a wifi adapter, they require
> different tunings.
This is an excellent example that we did not consider while developing
the patch. Thanks.
> This is why we added sk_pacing_shift_update(). If this needs
> refinement, lets talk.
We believe that it is fundamental to give the user the runtime control
of the algorithm, which right now starts with latency-saving default
values but is tailored for a specific kind of network. As you pointed
out, these should be tuned per-interface. In the following days, we will
perform more focused testing, trying to assess if there are cases in
which a fine-tuning is preferable to a logarithmic one.
Meanwhile, what would be the best way to expose sk_pacing_shift to the
userspace?
Thank you again
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Alexei Starovoitov @ 2018-01-06 19:25 UTC (permalink / raw)
To: Dan Williams
Cc: Alan Cox, Linus Torvalds, Linux Kernel Mailing List, linux-arch,
Andi Kleen, Arnd Bergmann, Greg Kroah-Hartman, Peter Zijlstra,
Netdev, Ingo Molnar, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <CAPcyv4hyRfPhnnS=aDf=jMMP+-EJM3ojPC0gX9ChawT3vidkJQ@mail.gmail.com>
On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote:
> On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> [..]
> >> retpoline is variant-2, this patch series is about variant-1.
> >
> > that's exactly the point. Don't slow down the kernel with lfences
> > to solve variant 1. retpoline for 2 is ok from long term kernel
> > viability perspective.
> >
>
> Setting aside that we still need to measure the impact of these
> changes the end result will still be nospec_array_ptr() sprinkled in
> various locations. So can we save the debate about what's inside that
> macro on various architectures and at least proceed with annotating
> the problematic locations? Perhaps we can go a step further and have a
> config option to switch between the clever array_access() approach
> from Linus that might be fine depending on the compiler, and the
> cpu-vendor-recommended not to speculate implementation of
> nospec_array_ptr().
recommended by panicing vendors who had no better ideas?
Ohh, speculation is exploitable, let's stop speculation.
Instead of fighting it we can safely steer it where it doesn't leak
kernel data. AND approach is doing exactly that.
It probably can be made independent of compiler choice to use setbe-like insn.
^ permalink raw reply
* Re: [iproute2 2/2] ss: fix NULL pointer access when parsing unix sockets with oldformat
From: Stefano Brivio @ 2018-01-06 19:28 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: netdev, Stephen Hemminger, Phil Sutter
In-Reply-To: <20180106183150.10530-2-a@unstable.cc>
On Sun, 7 Jan 2018 02:31:50 +0800
Antonio Quartulli <a@unstable.cc> wrote:
> When parsing and printing the unix sockets in unix_show(),
> if the oldformat is detected, the peer_name member of the sockstat
> object is left uninitialized (NULL).
Luckily, it is initialized. I'd rather say:
[...]
object is not set (NULL).
> For this reason, if a filter has been specified on the command line,
> a strcmp() will crash when trying to access it.
>
> Avoid crash by checking that peer_name is not NULL before
> passing it to strcmp().
>
> Cc: Stefano Brivio <sbrivio@redhat.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Antonio Quartulli <a@unstable.cc>
Fixes: 2d0e538f3e1c ("ss: Drop list traversal from unix_stats_print()")
> [...]
>
> diff --git a/misc/ss.c b/misc/ss.c
> index b35859dc..29a25070 100644
> --- a/misc/ss.c
> +++ b/misc/ss.c
> @@ -3711,7 +3711,10 @@ static int unix_show(struct filter *f)
> };
>
> memcpy(st.local.data, &u->name, sizeof(u->name));
> - if (strcmp(u->peer_name, "*"))
> + /* when parsing the old format rport is set to 0 and
> + * therefore peer_name remains NULL
> + */
Maybe this comment is a bit redundant, but I don't have a strong
preference either.
> + if (u->peer_name && strcmp(u->peer_name, "*"))
> memcpy(st.remote.data, &u->peer_name,
> sizeof(u->peer_name));
> if (run_ssfilter(f->f, &st) == 0) {
FWIW:
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
--
Stefano
^ permalink raw reply
* Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share filter block instances
From: David Ahern @ 2018-01-06 19:29 UTC (permalink / raw)
To: Jamal Hadi Salim, Jiri Pirko
Cc: netdev, davem, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, saeedm, matanb, leonro,
idosch, jakub.kicinski, simon.horman, pieter.jansenvanvuuren,
john.hurley, alexander.h.duyck, ogerlitz, john.fastabend, daniel
In-Reply-To: <c658f390-3996-d1e2-7e43-0cec6eb03c67@mojatatu.com>
On 1/6/18 11:02 AM, Jamal Hadi Salim wrote:
> BTW: From your output, DavidA, i noticed something strange:
> two flower filters with the same handle id 0x1 (different prios)
> and also two filters with the same prio (but different handles).
> I see one was added using :dev .." - how were the other 2 added?
> Consequence of patch, maybe?
Not clear from the command history. I was running commands (add by
device and add by block) in various orders to see what happens.
>
> Note:
> Expected behavior is two filters of same kind on the same chain
> should be distinguished by priority. There are filters like u32
> (which hide hash tables under the same priority) which may
> allow the same prio for multiple handles - just dont see that
> fit with flower, but maybe missing something.
>
> cheers,
> jamal
^ permalink raw reply
* Re: [PATCH 0/2] Ether fixes for the SolutionEngine771x boards
From: Sergei Shtylyov @ 2018-01-06 19:31 UTC (permalink / raw)
To: David Miller; +Cc: ysato, dalias, linux-sh, netdev
In-Reply-To: <20180105.105400.382726554616187086.davem@davemloft.net>
On 01/05/2018 06:54 PM, David Miller wrote:
>> Here's the series of 2 patches against Linus' repo. This series should
>> (hoplefully) fix the Ether support on the SolutionEngine771x boards...
>>
>> [1/2] SolutionEngine771x: fix Ether platform data
>> [2/2] SolutionEngine771x: add Ether TSU resource
>
> Looks like this doesn't go through my tree.
Yeah, we have the SH kernel maintained now... but I have a bad feeling
looking at their patchwork: it shows no recently applied patches. :-/
> Let me know if it should.
We'll wait and see, I think...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Dan Williams @ 2018-01-06 19:36 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alan Cox, Linus Torvalds, Linux Kernel Mailing List, linux-arch,
Andi Kleen, Arnd Bergmann, Greg Kroah-Hartman, Peter Zijlstra,
Netdev, Ingo Molnar, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <20180106192517.ykvlcq4564cqy4u6@ast-mbp>
On Sat, Jan 6, 2018 at 11:25 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote:
>> On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>> [..]
>> >> retpoline is variant-2, this patch series is about variant-1.
>> >
>> > that's exactly the point. Don't slow down the kernel with lfences
>> > to solve variant 1. retpoline for 2 is ok from long term kernel
>> > viability perspective.
>> >
>>
>> Setting aside that we still need to measure the impact of these
>> changes the end result will still be nospec_array_ptr() sprinkled in
>> various locations. So can we save the debate about what's inside that
>> macro on various architectures and at least proceed with annotating
>> the problematic locations? Perhaps we can go a step further and have a
>> config option to switch between the clever array_access() approach
>> from Linus that might be fine depending on the compiler, and the
>> cpu-vendor-recommended not to speculate implementation of
>> nospec_array_ptr().
>
> recommended by panicing vendors who had no better ideas?
> Ohh, speculation is exploitable, let's stop speculation.
> Instead of fighting it we can safely steer it where it doesn't leak
> kernel data. AND approach is doing exactly that.
> It probably can be made independent of compiler choice to use setbe-like insn.
Right, when that 'probably' is 'certainly' for the architecture you
care about just update the nospec_array_ptr() definition at that
point.
^ permalink raw reply
* Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
From: Dan Williams @ 2018-01-06 19:37 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Mark Rutland, Peter Zijlstra, Alan Cox, Srinivas Pandruvada,
Will Deacon, Solomon Peachy, H. Peter Anvin, Christian Lamparter,
Elena Reshetova, linux-arch, Andi Kleen, James E.J. Bottomley,
linux-scsi, Jonathan Corbet, X86 ML, Ingo Molnar,
Alexey Kuznetsov, Zhang Rui, Linux-media@vger.kernel.org,
Arnd Bergmann <arn
In-Reply-To: <151520099201.32271.4677179499894422956.stgit@dwillia2-desk3.amr.corp.intel.com>
On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [1]
> and the Documentation patch in this series."
>
> This series incorporates Mark Rutland's latest api and adds the x86
> specific implementation of nospec_barrier. The
> nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
> wide analysis performed by Elena Reshetova to address static analysis
> reports where speculative execution on a userspace controlled value
> could bypass a bounds check. The patches address a precondition for the
> attack discussed in the Spectre paper [2].
>
> A consideration worth noting for reviewing these patches is to weigh the
> dramatic cost of being wrong about whether a given report is exploitable
> vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
> lets make the bar for applying these patches be "can you prove that the
> bounds check bypass is *not* exploitable". Consider that the Spectre
> paper reports one example of a speculation window being ~180 cycles.
>
> Note that there is also a proposal from Linus, array_access [3], that
> attempts to quash speculative execution past a bounds check without
> introducing an lfence instruction. That may be a future optimization
> possibility that is compatible with this api, but it would appear to
> need guarantees from the compiler that it is not clear the kernel can
> rely on at this point. It is also not clear that it would be a
> significant performance win vs lfence.
>
> These patches also will also be available via the 'nospec' git branch
> here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec
It appears that git.kernel.org has not mirrored out the new branch. In
the meantime here's an alternative location:
https://github.com/djbw/linux.git nospec
If there are updates to these patches they will appear in nospec-v2,
nospec-v3, etc... branches.
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Thomas Gleixner @ 2018-01-06 19:41 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Dan Williams, Alan Cox, Linus Torvalds, Linux Kernel Mailing List,
linux-arch, Andi Kleen, Arnd Bergmann, Greg Kroah-Hartman,
Peter Zijlstra, Netdev, Ingo Molnar, H. Peter Anvin
In-Reply-To: <20180106192517.ykvlcq4564cqy4u6@ast-mbp>
On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote:
> > On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > [..]
> > >> retpoline is variant-2, this patch series is about variant-1.
> > >
> > > that's exactly the point. Don't slow down the kernel with lfences
> > > to solve variant 1. retpoline for 2 is ok from long term kernel
> > > viability perspective.
> > >
> >
> > Setting aside that we still need to measure the impact of these
> > changes the end result will still be nospec_array_ptr() sprinkled in
> > various locations. So can we save the debate about what's inside that
> > macro on various architectures and at least proceed with annotating
> > the problematic locations? Perhaps we can go a step further and have a
> > config option to switch between the clever array_access() approach
> > from Linus that might be fine depending on the compiler, and the
> > cpu-vendor-recommended not to speculate implementation of
> > nospec_array_ptr().
>
> recommended by panicing vendors who had no better ideas?
> Ohh, speculation is exploitable, let's stop speculation.
> Instead of fighting it we can safely steer it where it doesn't leak
> kernel data. AND approach is doing exactly that.
For one particular architecture and that's not a solution for generic
code.
Aside of that I fundamentally disagree with your purely performance
optimized argumentation. We need to make sure that we have a solution which
kills the problem safely and then take it from there. Correctness first,
optimization later is the rule for this. Better safe than sorry.
Thanks,
tglx
^ permalink raw reply
* Re: [iproute2 2/2] ss: fix NULL pointer access when parsing unix sockets with oldformat
From: Antonio Quartulli @ 2018-01-06 19:51 UTC (permalink / raw)
To: Stefano Brivio; +Cc: netdev, Stephen Hemminger, Phil Sutter
In-Reply-To: <20180106202818.2160a475@elisabeth>
[-- Attachment #1.1: Type: text/plain, Size: 2160 bytes --]
Hi,
On 07/01/18 03:28, Stefano Brivio wrote:
> On Sun, 7 Jan 2018 02:31:50 +0800
> Antonio Quartulli <a@unstable.cc> wrote:
>
>> When parsing and printing the unix sockets in unix_show(),
>> if the oldformat is detected, the peer_name member of the sockstat
>> object is left uninitialized (NULL).
>
> Luckily, it is initialized. I'd rather say:
>
> [...]
> object is not set (NULL).
ops, you are right! "is not set" makes more sense.
>
>> For this reason, if a filter has been specified on the command line,
>> a strcmp() will crash when trying to access it.
>>
>> Avoid crash by checking that peer_name is not NULL before
>> passing it to strcmp().
>>
>> Cc: Stefano Brivio <sbrivio@redhat.com>
>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Antonio Quartulli <a@unstable.cc>
>
> Fixes: 2d0e538f3e1c ("ss: Drop list traversal from unix_stats_print()")
>
>> [...]
>>
>> diff --git a/misc/ss.c b/misc/ss.c
>> index b35859dc..29a25070 100644
>> --- a/misc/ss.c
>> +++ b/misc/ss.c
>> @@ -3711,7 +3711,10 @@ static int unix_show(struct filter *f)
>> };
>>
>> memcpy(st.local.data, &u->name, sizeof(u->name));
>> - if (strcmp(u->peer_name, "*"))
>> + /* when parsing the old format rport is set to 0 and
>> + * therefore peer_name remains NULL
>> + */
>
> Maybe this comment is a bit redundant, but I don't have a strong
> preference either.
>
I thought explaining "why" it could be NULL would help the casual reader
understand why we do check it.
But now that we have the check, I think it's quick to understand why we
need it.
I'd leave to whoever is going to merge the match to decide to keep or
not the comment.
>> + if (u->peer_name && strcmp(u->peer_name, "*"))
>> memcpy(st.remote.data, &u->peer_name,
>> sizeof(u->peer_name));
>> if (run_ssfilter(f->f, &st) == 0) {
>
> FWIW:
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
>
Thanks a lot, Stefano!
Should I send v2 with the commit message changed? Or can we leave this
to who will merge the change?
Regards,
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: dvb usb issues since kernel 4.9
From: Mauro Carvalho Chehab @ 2018-01-06 19:54 UTC (permalink / raw)
To: Josef Griebichler, Greg Kroah-Hartman, Alan Stern, linux-usb
Cc: Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa,
Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet,
LMML, Peter Zijlstra, David Miller, torvalds
In-Reply-To: <trinity-1fa14556-8596-44b1-95cb-b8919d94d2d4-1515251056328@3c-app-gmx-bs15>
Hi Josef,
Em Sat, 6 Jan 2018 16:04:16 +0100
"Josef Griebichler" <griebichler.josef@gmx.at> escreveu:
> Hi,
>
> the causing commit has been identified.
> After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882
> its working again.
Just replying to me won't magically fix this. The ones that were involved on
this patch should also be c/c, plus USB people. Just added them.
> Please have a look into the thread https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13
> here are several users aknowledging the revert solves their issues with usb dvb cards.
I read the entire (long) thread there. In order to make easier for the
others, from what I understand, the problem happens on both x86 and arm,
although almost all comments there are mentioning tests with raspbian
Kernel (with uses a different USB host driver than the upstream one).
It happens when watching digital TV DVB-C channels, with usually means
a sustained bit rate of 11 MBps to 54 MBps.
The reports mention the dvbsky, with uses USB URB bulk transfers.
On every several minutes (5 to 10 mins), the stream suffer "glitches"
caused by frame losses.
The part of the thread that contains the bisect is at:
https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965
It indirectly mentions another comment on the thread with points
to:
https://github.com/raspberrypi/linux/issues/2134
There, it says that this fix part of the issues:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4
but it affects URB packet losses on a lesser extend.
The main issue is really the logic changes a the core softirq logic.
Using Kernel 4.14.10 on a Raspberry Pi 3 with 4cd13c2 commit reverted
fixed the issue.
Joseph, is the above right? Anything else to mention? Does the
same issue affect also on x86 with vanilla Kernel 4.14.10?
-
It seems that the original patch were designed to solve some IRQ issues
with network cards with causes data losses on high traffic. However,
it is also causing bad effects on sustained high bandwidth demands
required by DVB cards, at least on some USB host drivers.
Alan/Greg/Eric/David:
Any ideas about how to fix it without causing regressions to
network?
Regards,
Mauro
> Gesendet: Sonntag, 17. Dezember 2017 um 14:27 Uhr
> Von: "Mauro Carvalho Chehab" <mchehab@s-opensource.com>
> An: "Sean Young" <sean@mess.org>
> Cc: "Josef Griebichler" <griebichler.josef@gmx.at>, lcaumont2@gmail.com, gregkh@linuxfoundation.org, linux-media@vger.kernel.org, linux-usb@vger.kernel.org
> Betreff: Re: dvb usb issues since kernel 4.9
> Em Sun, 17 Dec 2017 12:06:37 +0000
> Sean Young <sean@mess.org> escreveu:
>
> > Hi Josef,
>
> Em Sun, 17 Dec 2017 11:19:38 +0100
> "Josef Griebichler" <griebichler.josef@gmx.at> escreveu:
>
> > > Hello Mr. Caumont,
> > >
> > > since switch to kernel 4.9 there are several users which have issues with their usb dvb cards.
> > > Some get artifacts when watching livetv, I'm getting discontinuity errors in tvheadend when recording.
> > > I'm using latest test build of LibreElec with kernel 4.14.6 but the issues are still there.
> > > There's an librelec forum thread for this topic
> > > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/
> > > and also an open kernel bug
> > > https://bugzilla.kernel.org/show_bug.cgi?id=197835[https://bugzilla.kernel.org/show_bug.cgi?id=197835]
> > >
> > > This is my dmesg http://sprunge.us/WRIE[http://sprunge.us/WRIE]
> > > and tvh service log http://sprunge.us/bEiE[http://sprunge.us/bEiE]
> > >
> > > I saw in kernel changelog that you made an improvement/change for dvb und usb (commit 9a11204d2b26324636ff54f8d28095ed5dd17e91)
> > >
> > > Is there anything that can be done to improve our situation or are we forced to stay with kernel 4.8?
> > >
> > > Thanks for support!
> > >
> > > Josef
> >
> > Between kernel v4.8 and v4.9 there are many changes, and it is unlikely that
> > commit 9a11204d2b26324636ff54f8d28095ed5dd17e91 is responsible for this.
>
> Let me add linux-media@vger.kernel.org and linux-usb@vger.kernel.org ML.
>
> Josef, Please be sure that your e-mailer won't be sending e-mails with
> HTML tags on it, otherwise the ML server will automatically drop.
>
> > What would be really helpful is if you could find out which commit did
> > cause a regression. This can be done by bisecting the kernel. There are
> > various guides to this:
> >
> > https://wiki.ubuntu.com/Kernel/KernelBisection[https://wiki.ubuntu.com/Kernel/KernelBisection]
> > or
> > https://wiki.archlinux.org/index.php/Bisecting_bugs[https://wiki.archlinux.org/index.php/Bisecting_bugs]
> >
> > Once the commit has been identified we can work together to narrow it down
> > to the exact change, and then work together on a fix.
>
> Yeah, we need more data in order to start tracking it. I suspect,
> however, that a simple git bisect may not work in this case, due to the
> USB changes that forbids DMA on stack that was added to Kernel 4.9, if
> the card Josef is using was affected by such change.
>
> Probably, he'll need to disable CONFIG_VMAP_STACK in the middle
> of bisect (e. g. when the patch that implements it is added),
> or to cherry-pick any needed DMA fixup patch on the top of Kernel
> 4.8 before starting bisect.
>
> It is also worth mentioning what's the USB host controller that
> are used, and what's the media driver, as this could be an issue
> there.
>
> That's said, from the bug report, it seems that this is
> happening on RPi3. Could you please test it also on a PC? That
> will help to identify if the bug is at RPi's host driver or
> on media drivers.
>
> With regards to RPi3, there are actually two different drivers
> for it: one used on Raspbian Kernel, and another one upstream.
> They're completely different ones.
>
> What driver are you using?
>
> Thanks,
> Mauro
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Alan Cox @ 2018-01-06 19:55 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Linus Torvalds, Dan Williams, linux-kernel, linux-arch,
Andi Kleen, Arnd Bergmann, Greg Kroah-Hartman, Peter Zijlstra,
netdev, Ingo Molnar, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <20180106185134.dzn2en4vw2hj3p6h@ast-mbp>
> cpus execute what they see. speculative execution does the same
> except results are not committed to visible registers and stay
> in renanmed/shadow set. There is no 'undo' of the speculative execution.
> The whole issue is that cache and branch predictor don't have
> a shadow unlike registers.
Can I suggest you read something like "Exploitig Value Locaity to Exceed
The Dataflow Limit" by Lipasti and Shen 1996.
In other words there are at least two problems with Linus proposal
1. The ffff/0000 mask has to be generated and that has to involve
speculative flows.
2. There are processors on the planet that may speculate not just what
instruction to execute but faced with a stall on an input continue by
using an educated guess at the value that will appear at the input in
future.
> > > I think "lets sprinkle lfence everywhere" approach is going to
> > > cause serious performance degradation. Yet people pushing for lfence
> > > didn't present any numbers.
> >
> > Normally people who propose security fixes don't have to argue about the
> > fact they added 30 clocks to avoid your box being 0wned.
> >
> > If you look at the patches very very few are in remotely hot paths, which
> > is good news. The ones in hot paths definitely need careful scrutiny but
> > the priority ought to be fixing and then optimizing unless its obvious
> > how to tackle it.
>
> fdtable, access_ok and networking are clearly hot,
Those points are not when compared to a lot of paths executed far far
more (like packet processing). The ipv4/6 ones are mixing lfences and a
lot of stores so probably hurt with lfence. fdtable worries me
a lot less and is anyway clearly required.
I have reviewing the packet building ones on my TODO list for a reason.
Alan
^ permalink raw reply
* Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
From: Dan Williams @ 2018-01-06 20:07 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Mark Rutland, Peter Zijlstra, Alan Cox, Srinivas Pandruvada,
Will Deacon, Solomon Peachy, H. Peter Anvin, Christian Lamparter,
Elena Reshetova, linux-arch, Andi Kleen, James E.J. Bottomley,
linux-scsi, Jonathan Corbet, X86 ML, Ingo Molnar,
Alexey Kuznetsov, Zhang Rui, Linux-media@vger.kernel.org,
Arnd Bergmann <arn
In-Reply-To: <CAPcyv4gQbo+Bvf89QVL=mJrRy+id=sj3hiNePS=o_aAZv6hu0w@mail.gmail.com>
On Sat, Jan 6, 2018 at 11:37 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One of these, known as variant-1, allows
>> explicit bounds checks to be bypassed under speculation, providing an
>> arbitrary read gadget. Further details can be found on the GPZ blog [1]
>> and the Documentation patch in this series."
>>
>> This series incorporates Mark Rutland's latest api and adds the x86
>> specific implementation of nospec_barrier. The
>> nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
>> wide analysis performed by Elena Reshetova to address static analysis
>> reports where speculative execution on a userspace controlled value
>> could bypass a bounds check. The patches address a precondition for the
>> attack discussed in the Spectre paper [2].
>>
>> A consideration worth noting for reviewing these patches is to weigh the
>> dramatic cost of being wrong about whether a given report is exploitable
>> vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
>> lets make the bar for applying these patches be "can you prove that the
>> bounds check bypass is *not* exploitable". Consider that the Spectre
>> paper reports one example of a speculation window being ~180 cycles.
>>
>> Note that there is also a proposal from Linus, array_access [3], that
>> attempts to quash speculative execution past a bounds check without
>> introducing an lfence instruction. That may be a future optimization
>> possibility that is compatible with this api, but it would appear to
>> need guarantees from the compiler that it is not clear the kernel can
>> rely on at this point. It is also not clear that it would be a
>> significant performance win vs lfence.
>>
>> These patches also will also be available via the 'nospec' git branch
>> here:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec
>
> It appears that git.kernel.org has not mirrored out the new branch. In
> the meantime here's an alternative location:
>
> https://github.com/djbw/linux.git nospec
>
> If there are updates to these patches they will appear in nospec-v2,
> nospec-v3, etc... branches.
For completeness I appended the bpf fix [1] to the git branch.
https://lwn.net/Articles/743288/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox