From owner-freebsd-arch@freebsd.org Sun Dec 31 15:03:14 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49169EB8AA1 for ; Sun, 31 Dec 2017 15:03:14 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 1186176195 for ; Sun, 31 Dec 2017 15:03:13 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id vBVF3DqQ040555 for ; Sun, 31 Dec 2017 09:03:13 -0600 (CST) (envelope-from karels@FreeBSD.org) Message-Id: <201712311503.vBVF3DqQ040555@mail.karels.net> To: freebsd-arch@freebsd.org From: Mike Karels Reply-to: karels@FreeBSD.org Subject: Re: making SW_WATCHDOG dynamic MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40553.1514732593.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Sun, 31 Dec 2017 09:03:13 -0600 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 15:03:14 -0000 My proposed change is in Phabricator, https://reviews.freebsd.org/D13713. A couple of notes: - I retained the SW_WATCHDOG option; it now just enables the software watchdog even if a hardware watchdog is attached, as it would have done in the past. I updated NOTES and the watchdog(4) information accordingly. I did not provide for any other combination of watchdogs or actions; that would require a complete rework of the kernel API. Note that the hardware watchdogs provide no choice of action; they simply reset the box. - I have tested this with and without the SW_WATCHDOG option, but do not have a hardware watchdog to test with. If someone could test this, it wou= ld be much apprectiated. I tested by enabling watchdogd with default paramet= ers, doing b"killall -STOP watchdogd", and then observing that the system dropp= ed into the debugger after about 128 sec. It drops into the debugger if KDB is defined and KDB_UNATTENDED is not; otherise it panics (as before). I neglected to respond this this from Andriy Gapon: > P.S. > And maybe just using the second software watchdog would be good enough f= or what > you are doing? I think the hardclock-based SW_WATCHDOG is better than the --softtimeout wactchdog because it runs at a lower level (hardclock vs callout/softclock= ). In particular, I have found it to work in situations where a locking deadly embrace started in the network stack, and then a callout routine got stuck as well when a function it called blocked on the offending lock. That caused watchdogd to fail to be rescheduled, and the watchdog fired as a result. The callout-based facility could have been blocked out as well. Mike From owner-freebsd-arch@freebsd.org Sun Dec 31 18:01:48 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C92DE8A125 for ; Sun, 31 Dec 2017 18:01:48 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F6F77CDD2; Sun, 31 Dec 2017 18:01:48 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBVI1eE1082421; Sun, 31 Dec 2017 10:01:40 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBVI1eCP082420; Sun, 31 Dec 2017 10:01:40 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712311801.vBVI1eCP082420@pdx.rh.CN85.dnsmgr.net> Subject: Re: making SW_WATCHDOG dynamic In-Reply-To: <201712311503.vBVF3DqQ040555@mail.karels.net> To: karels@freebsd.org Date: Sun, 31 Dec 2017 10:01:40 -0800 (PST) CC: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 18:01:48 -0000 > My proposed change is in Phabricator, https://reviews.freebsd.org/D13713. > > A couple of notes: > > - I retained the SW_WATCHDOG option; it now just enables the software > watchdog even if a hardware watchdog is attached, as it would have done > in the past. The SW_WATCHDOG option has changed in function, it use to control if this code was compiled in at all, it now does something different. This code is compile in now no matter what with no option to remove it, which means there is one more rarely used option in the GENERIC kernel that can not be removed. 1 byte or 100 does not matter, it is that policy has been shoved down the users throat. "You shall have a software watchdog timer in your kernel weither you want it there or not, and it is turned off by default." We have way to many of those types of things already, adding to this list is going in the wrong direction. > I updated NOTES and the watchdog(4) information accordingly. This change as it stands requires a RELNOTES flag. > I did not provide for any other combination of watchdogs or actions; that > would require a complete rework of the kernel API. Note that the hardware > watchdogs provide no choice of action; they simply reset the box. > > - I have tested this with and without the SW_WATCHDOG option, but do not > have a hardware watchdog to test with. If someone could test this, it would > be much apprectiated. I tested by enabling watchdogd with default parameters, > doing b"killall -STOP watchdogd", and then observing that the system dropped > into the debugger after about 128 sec. It drops into the debugger if KDB > is defined and KDB_UNATTENDED is not; otherise it panics (as before). > > I neglected to respond this this from Andriy Gapon: > > P.S. > > And maybe just using the second software watchdog would be good enough for what > > you are doing? > > I think the hardclock-based SW_WATCHDOG is better than the --softtimeout > wactchdog because it runs at a lower level (hardclock vs callout/softclock). > In particular, I have found it to work in situations where a locking > deadly embrace started in the network stack, and then a callout routine > got stuck as well when a function it called blocked on the offending lock. > That caused watchdogd to fail to be rescheduled, and the watchdog fired as > a result. The callout-based facility could have been blocked out as well. > > Mike > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Sun Dec 31 22:52:22 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9E15EABD0D for ; Sun, 31 Dec 2017 22:52:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A83CE6814D for ; Sun, 31 Dec 2017 22:52:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id b5so35584682itc.3 for ; Sun, 31 Dec 2017 14:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cArmbUE407r5V1zBuui/zA2yfXUajir0jlTYxEnO8W8=; b=H7dxY1wb81OFYEQrIQwieDQnx3CzTAzZKIc4qAJH5n0YE/FeHh3L5BFDCDYPcGRTSw IAKyYyZQ86SJF1s1K27EjMZaDxtiMgMELeOxGilZ378ZaYMmQ8Nl10E/MIcMvzmq9ig0 dQyrcPgnj3pCPagWwGv913jXBxdhGFs0IkdvN32piw0C124saLsj8ys/4vx1UvwP9JZ+ M94Z5H/c9zXLi3yi0RfylBombjPB0uYMPuRo4zjaIcvq7cD2+j56HNcpul7Iu/ZlGl+q IVEu7rklV9vnIv9pIvJ3OuuL8RY30l2Cp6Rzos59/hNjS3Fld/pKtIRSt5wKfQWsyt5c C96Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cArmbUE407r5V1zBuui/zA2yfXUajir0jlTYxEnO8W8=; b=B4vJ7daAdQEuJPFLsLw1BrI6JMxkTZyX82YlzIZABt1241V/UsINIL5QkXXW2EPqHo C32ZVhAdgoDKpEC1CTGXHbPgL/cvX+TLacMuPLe63OwQHYwhqv8a0cD58sefRC4YXshy lq66TKdnJRFalzLCOStX/x94LUytoLmTFnW+p5mL2AfhDC7qJFXbf1esCetXSXfOhsEc qqmJp3PKPNuAV0bSqRK7Go5DSqvBiIteAJWYe7aD4rrQQ3ddafq/8IPX7r9m0l9jgZ6K suqbV0Sn4h4pJ2ubJLoqkdTDWJQWJtVimVHVIwSY6QGTsTq0REpAlUlOg+66Qz1N9wEY 1/Ww== X-Gm-Message-State: AKGB3mKinBhZjewwuN0DD2R1287ykyXKEUAPP0R78YQqpgeQ3WWD78ve ZWy9NvyBNln9jrAgIW0yLkJ+00A0c4N4l7xK+EP//A== X-Google-Smtp-Source: ACJfBov7r01uvipcInmdIE9iQIBLiYMkhfZHXswL0dt3DENRUKFugWrpN0aP0wBqU8e7xPQ8gG0g+A6Mx0k76tCjOYM= X-Received: by 10.36.133.135 with SMTP id r129mr57713960itd.69.1514760741836; Sun, 31 Dec 2017 14:52:21 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 31 Dec 2017 14:52:20 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <201712311801.vBVI1eCP082420@pdx.rh.CN85.dnsmgr.net> References: <201712311503.vBVF3DqQ040555@mail.karels.net> <201712311801.vBVI1eCP082420@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Sun, 31 Dec 2017 15:52:20 -0700 X-Google-Sender-Auth: LHT6ATjvcC-wBXGDKfQWHcSE9QE Message-ID: Subject: Re: making SW_WATCHDOG dynamic To: "Rodney W. Grimes" Cc: karels@freebsd.org, "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 22:52:22 -0000 On Sun, Dec 31, 2017 at 11:01 AM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > My proposed change is in Phabricator, https://reviews.freebsd.org/D13713 > . > > > > A couple of notes: > > > > - I retained the SW_WATCHDOG option; it now just enables the software > > watchdog even if a hardware watchdog is attached, as it would have done > > in the past. > The SW_WATCHDOG option has changed in function, it use to control > if this code was compiled in at all, it now does something different. > This code is compile in now no matter what with no option to remove > it, which means there is one more rarely used option in the GENERIC > kernel that can not be removed. 1 byte or 100 does not matter, it > is that policy has been shoved down the users throat. "You shall have > a software watchdog timer in your kernel weither you want it there > or not, and it is turned off by default." > > We have way to many of those types of things already, > adding to this list is going in the wrong direction. Except the code does nothing of the sort. All it does is allow one to enable software watchdogs if one wants as an always-available (but off by default) feature. I don't see what the big deal is. If you don't enable watchdogd, things are exactly as before. If you do enable it, you don't have to rebuild a kernel to get it going. This isn't worth a fight. Warner > > > I updated NOTES and the watchdog(4) information accordingly. > > This change as it stands requires a RELNOTES flag. > > > I did not provide for any other combination of watchdogs or actions; that > > would require a complete rework of the kernel API. Note that the > hardware > > watchdogs provide no choice of action; they simply reset the box. > > > > - I have tested this with and without the SW_WATCHDOG option, but do not > > have a hardware watchdog to test with. If someone could test this, it > would > > be much apprectiated. I tested by enabling watchdogd with default > parameters, > > doing b"killall -STOP watchdogd", and then observing that the system > dropped > > into the debugger after about 128 sec. It drops into the debugger if KDB > > is defined and KDB_UNATTENDED is not; otherise it panics (as before). > > > > I neglected to respond this this from Andriy Gapon: > > > P.S. > > > And maybe just using the second software watchdog would be good enough > for what > > > you are doing? > > > > I think the hardclock-based SW_WATCHDOG is better than the --softtimeout > > wactchdog because it runs at a lower level (hardclock vs > callout/softclock). > > In particular, I have found it to work in situations where a locking > > deadly embrace started in the network stack, and then a callout routine > > got stuck as well when a function it called blocked on the offending > lock. > > That caused watchdogd to fail to be rescheduled, and the watchdog fired > as > > a result. The callout-based facility could have been blocked out as > well. > > > > Mike > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Thu Jan 4 14:50:53 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F2B7EB9AFC; Thu, 4 Jan 2018 14:50:53 +0000 (UTC) (envelope-from srs0=fypj=d7=freebsd.org=kp@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E07526C91F; Thu, 4 Jan 2018 14:50:52 +0000 (UTC) (envelope-from srs0=fypj=d7=freebsd.org=kp@codepro.be) Received: from [172.16.2.10] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id D24884506C; Thu, 4 Jan 2018 15:50:49 +0100 (CET) From: "Kristof Provost" To: freebsd-arch@freebsd.org Cc: freebsd-hackers , "FreeBSD Current" Subject: RFC: mallocarray() Date: Thu, 04 Jan 2018 15:51:09 +0100 X-Mailer: MailMate (2.0BETAr6102) Message-ID: <070C0DEB-E70C-42D9-B734-E0735A6C9B8E@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:50:53 -0000 Hi, I’d like to make it easier to avoid integer overflow issues in the kernel. It’d be a lot nicer to have a malloc function figure this out for us, so I’d like mallocarray(). https://reviews.freebsd.org/D13766 Are there any objections to this? Regards, Kristof From owner-freebsd-arch@freebsd.org Fri Jan 5 10:08:19 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC3A3EC1C0A for ; Fri, 5 Jan 2018 10:08:19 +0000 (UTC) (envelope-from repeatable_compression@yahoo.com) Received: from sonic301-31.consmr.mail.ne1.yahoo.com (sonic301-31.consmr.mail.ne1.yahoo.com [66.163.184.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACB811746 for ; Fri, 5 Jan 2018 10:08:19 +0000 (UTC) (envelope-from repeatable_compression@yahoo.com) X-YMail-OSG: tPYEH6cVM1l5zIptmFMmFqUhIFFALqD8GkaWzpDhwxio1eTwycVVAuvDaQws9vP T4FAG3Z72GpY5tsIACENF9XWn7CyNMsO5o7oCssBN2b1VQddpq5B5wNuc9czB_5uiCBXCXnwJFcB z0o39Y2Y7zeyqB4Zy_Bx7DlA8.Mi2C2ZX5hVux87tRiKciJ.7GMC97yb.U4rr40EcZSEe2bUNmxu cyS4aFQFI_U0TntrAKi5tpmQE6FL5xv71QULySgUkX1A_WqZk4jOSQsDV71pLw_nV.LjNol9Ty7C MR6I5ZFNwCX4utWVPsLme3moztVNWxzPq1jTOTPG.bpLahDnonhYqwzTSyCrx0MhXGwZSVoXDBgJ 6bX8gEn7FjeJvGqrxo5V9yuJ72hU.90AS6kD4sJ0zyy5ZiNdEPair8fqLBRs2iHVb4er3FMzQa.E Mw4tQgasMi.tB3lHeSZRrq8PD44MUp0jsgvOvaw5KBzpb2escrDY56ScyLmwEi_mNPLzJnpEPfPe UqvsqDklmsz1Irp9ICob3dA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 5 Jan 2018 10:08:18 +0000 Date: Fri, 5 Jan 2018 10:07:01 +0000 (UTC) From: Jules Gilbert To: "Ronald F. Guilmette" , Eric McCorkle , Freebsd Security , Brett Glass , =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Message-ID: <809675000.867372.1515146821354@mail.yahoo.com> In-Reply-To: <2594.1515141192@segfault.tristatelogic.com> References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> Subject: Re: Intel hardware bug MIME-Version: 1.0 X-Mailer: WebService/1.1.11150 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:57.0) Gecko/20100101 Firefox/57.0 X-Mailman-Approved-At: Fri, 05 Jan 2018 11:30:47 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 10:08:20 -0000 Sorry guys, you just convinced me that no one, not the NSA, not the FSB, no= one!, has in the past, or will in the future be able to exploit this to ac= tually do something not nice. I'm not saying that the hardware shouldn't be fixed, I am saying that we do= n't need to worry about this. In the early days of DOS their was a hardware bug in nearly all floppy cont= rollers, it wasn't even discovered until (I think,) 1985 or so.=C2=A0 The t= hing is..., no one reported unusual problems. So what is this, really?, it's a market exploit opportunity for AMD. =20 On Friday, January 5, 2018, 3:33:31 AM EST, Ronald F. Guilmette wrote: =20 =20 =20 In message <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net>,=20 Eric McCorkle wrote: >The attack looks like this: > >1) Fetch kernel/other process memory, which eventually faults >2) Do a bit-shift/mask operation to pluck out one bit of the fetched >value.=C2=A0 This gets executed speculatively on the fetched value in (1). >3) Execute fetches of two different addresses depending on some bit in >the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1).=C2=A0 Th= is >also gets executed speculatively despite the fact that (1) ends up faultin= g. >4) Recover from fault in (1) >5) Measure performance of accesses to the two addresses to determine >which one is cached. I must say, that's one hell of a round-about way to read just one bit that you wern't supposed to have access to.=C2=A0 But of course, that doesn't re= ally matter if you are an attacker. If the above steps can be repeated, programatically, ad infinitum, to read bits from "protected" memory... and I see no reason why they can't be... then yea, this bug is every bit as bad as the media is making it out to be, and maybe even worse. All your secrets are belong to us! Time to invest in abacuses... or is that abacai? Regards, rfg _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" =20 From owner-freebsd-arch@freebsd.org Fri Jan 5 12:42:55 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0D1AEA6BA7; Fri, 5 Jan 2018 12:42:55 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id C44D8670C3; Fri, 5 Jan 2018 12:42:55 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.82] (unknown [172.16.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 3ED298850; Fri, 5 Jan 2018 12:42:54 +0000 (UTC) Subject: Re: Intel hardware bug To: Jules Gilbert , "Ronald F. Guilmette" , Freebsd Security , Brett Glass , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> <809675000.867372.1515146821354@mail.yahoo.com> From: Eric McCorkle Message-ID: <250f3a77-822b-fba5-dcd7-758dfec94554@metricspace.net> Date: Fri, 5 Jan 2018 07:42:53 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <809675000.867372.1515146821354@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 05 Jan 2018 12:48:42 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 12:42:56 -0000 On 01/05/2018 05:07, Jules Gilbert wrote: > Sorry guys, you just convinced me that no one, not the NSA, not the FSB, > no one!, has in the past, or will in the future be able to exploit this > to actually do something not nice. Attacks have already been demonstrated, pulling secrets out of kernel space with meltdown and http headers/passwords out of a browser with spectre. Javascript PoCs are already in existence, and we can expect them to find their way into adware-based malware within a week or two. Also, I'd be willing to bet you a year's rent that certain three-letter organizations have known about and used this for some time. > So what is this, really?, it's a market exploit opportunity for AMD. Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. I doubt any major architecture is going to make it out unscathed. (But if one does, my money's on Power) From owner-freebsd-arch@freebsd.org Fri Jan 5 13:30:32 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 370F1EA923D; Fri, 5 Jan 2018 13:30:32 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E414668C62; Fri, 5 Jan 2018 13:30:31 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w05DTiQ3014492; Fri, 5 Jan 2018 05:30:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=Rq10H2AKnhJa6OQt+JES3iPtcqyMMxVpJ8rjOFIiCR0=; b=nA2Jv9BZbdDRqYZr9CEPdyO298kV445+NaO05/NX7bi6/PeaDmNFl0EehV6xiLVSikff sC3fZdfLmVURWW3wg7TMvLD4uxmOq/iGYHBfrpbOtAmH1GsNGTXmTyYC4iRXoKBzcGTc iU2m2GslE3owIGc7XhMfOAhJdusb6LEYjvd+o5kfPYYL7Foqp7zTUSD1+0S52S0KD+cU Ek5cUnBVym/SOL5l68st5elNoylP+PLqU58dCuSltZJYXpdegI8GUO/yAUb9QdSMg4jE owJv7vz269JIY6iGmL3rUXMzMj5nppzORhwBBjnxWHhw0ZHZhDLOoCZdm/jXsdQjjH7X oA== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0022.outbound.protection.outlook.com [216.32.180.22]) by mx0a-00273201.pphosted.com with ESMTP id 2fa9ymr13j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Jan 2018 05:30:27 -0800 Received: from SN1PR0501MB2125.namprd05.prod.outlook.com (10.163.228.152) by SN1PR0501MB1693.namprd05.prod.outlook.com (10.163.130.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Fri, 5 Jan 2018 13:30:26 +0000 Received: from SN1PR0501MB2125.namprd05.prod.outlook.com ([10.163.228.152]) by SN1PR0501MB2125.namprd05.prod.outlook.com ([10.163.228.152]) with mapi id 15.20.0407.000; Fri, 5 Jan 2018 13:30:26 +0000 From: Andrew Duane To: Eric McCorkle , Jules Gilbert , "Ronald F. Guilmette" , Freebsd Security , Brett Glass , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Subject: RE: Intel hardware bug Thread-Topic: Intel hardware bug Thread-Index: AQHThhm6gtRbndOyekeN4M7Qcuy2NqNlOTSAgAAMhiA= Date: Fri, 5 Jan 2018 13:30:26 +0000 Message-ID: References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> <809675000.867372.1515146821354@mail.yahoo.com> <250f3a77-822b-fba5-dcd7-758dfec94554@metricspace.net> In-Reply-To: <250f3a77-822b-fba5-dcd7-758dfec94554@metricspace.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1693; 7:5aYxUZZcdWX6ZDNcffZq8FqMPnCx+mx3MXNLc2/udTNDnhkzQzmumE+DdiNTjTR1BtKeMihQNc15xux2UI0tTjMTONlkHptUb77yHz7uV9DfHPnI7jhfP/C/qZWFuK2aGIWzrBcBrxPI6IO/Y0n79rb1d4L0bk5yqD2P3uv3jyTtd6NxBhe1P2eXDjQZFBmFFiv8sQsPcVC0c1AjVVOUjlfkSxsO6xUheIX4e1FrUWVVZH7KxIlUPyXSdzVR9yrl x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 54d83e8a-b5b8-4844-b342-08d554407afc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(48565401081)(5600026)(4604075)(3008032)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:SN1PR0501MB1693; x-ms-traffictypediagnostic: SN1PR0501MB1693: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(192374486261705)(138986009662008)(201166117486090); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041268)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:SN1PR0501MB1693; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN1PR0501MB1693; x-forefront-prvs: 05437568AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(396003)(39380400002)(366004)(199004)(189003)(13464003)(24454002)(551544002)(86362001)(68736007)(6246003)(7116003)(229853002)(77096006)(5660300001)(7736002)(3660700001)(33656002)(106356001)(6436002)(6116002)(7416002)(8936002)(3846002)(97736004)(55016002)(2501003)(39060400002)(305945005)(110136005)(316002)(2950100002)(53936002)(81166006)(81156014)(2906002)(53546011)(2900100001)(3280700002)(9686003)(93886005)(8676002)(6506007)(105586002)(99286004)(3480700004)(2521001)(478600001)(74316002)(14454004)(102836004)(59450400001)(25786009)(76176011)(7696005)(66066001)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1693; H:SN1PR0501MB2125.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: crjRIwDX+1fBxiiPleRIx7Ldfgx6Ycl8CntGyXBX33M43E4qXDlbW9Z1yDgZ4Nh2iTbqKC68AG8ZwWePouqWyA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 54d83e8a-b5b8-4844-b342-08d554407afc X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2018 13:30:26.0345 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1693 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-05_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801050191 X-Mailman-Approved-At: Fri, 05 Jan 2018 14:29:51 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 13:30:32 -0000 I wouldn't think Javascript would have the accurate timing required to leve= rage this attack, but I don't really know enough about the language. Regardless, is there someone within FreeBSD that is working on patches for = this set of problems, at least for Intel? Linux already has at least some, = and I believe NetBSD does too. Of course Windows has already pushed out a W= indows10 fix, 7 and 8 are coming. .................................... Andrew L. Duane - Principal Resident Engineer AT&T Advanced Services Technical Lead Juniper Quality Ambassador m=A0=A0=A0+1 603.770.7088 o +1 408.933.6944 (2-6944) skype: andrewlduane aduane@juniper.net -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of Eric McCorkle Sent: Friday, January 5, 2018 7:43 AM To: Jules Gilbert ; Ronald F. Guilmette <= rfg@tristatelogic.com>; Freebsd Security ; Br= ett Glass ; Dag-Erling Sm=F8rgrav ; Poul-Henn= ing Kamp ; freebsd-arch@freebsd.org; FreeBSD Hackers ; Shawn Webb ; Natha= n Whitehorn Subject: Re: Intel hardware bug On 01/05/2018 05:07, Jules Gilbert wrote: > Sorry guys, you just convinced me that no one, not the NSA, not the=20 > FSB, no one!, has in the past, or will in the future be able to=20 > exploit this to actually do something not nice. Attacks have already been demonstrated, pulling secrets out of kernel space= with meltdown and http headers/passwords out of a browser with spectre. J= avascript PoCs are already in existence, and we can expect them to find the= ir way into adware-based malware within a week or two. Also, I'd be willing to bet you a year's rent that certain three-letter org= anizations have known about and used this for some time. > So what is this, really?, it's a market exploit opportunity for AMD. Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. I doubt any major architecture is going to make it out unscathed. (But if = one does, my money's on Power) From owner-freebsd-arch@freebsd.org Fri Jan 5 14:48:50 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27A19EAD345; Fri, 5 Jan 2018 14:48:50 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DD7BC6BE94; Fri, 5 Jan 2018 14:48:49 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id BC691107C6; Fri, 5 Jan 2018 14:48:47 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 7E0425CEB6; Fri, 5 Jan 2018 14:47:15 +0000 (UTC) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jules Gilbert Cc: "Ronald F. Guilmette" , Eric McCorkle , Freebsd Security , Poul-Henning Kamp , "freebsd-arch\@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Subject: Re: Intel hardware bug References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> <809675000.867372.1515146821354@mail.yahoo.com> Date: Fri, 05 Jan 2018 15:47:15 +0100 In-Reply-To: <809675000.867372.1515146821354@mail.yahoo.com> (Jules Gilbert's message of "Fri, 5 Jan 2018 10:07:01 +0000 (UTC)") Message-ID: <861sj4tlak.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 14:48:50 -0000 Jules Gilbert writes: > Sorry guys, you just convinced me that no one, not the NSA, not the > FSB, no one!, has in the past, or will in the future be able to > exploit this to actually do something not nice. The technique has already been proven by multiple independent parties to work quite well, allowing an attacker to read kernel memory at speeds of up to 500 kB/s. But I guess you know better... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@freebsd.org Fri Jan 5 15:26:04 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D58BEAF1FE for ; Fri, 5 Jan 2018 15:26:04 +0000 (UTC) (envelope-from repeatable_compression@yahoo.com) Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB4E66DB11 for ; Fri, 5 Jan 2018 15:26:03 +0000 (UTC) (envelope-from repeatable_compression@yahoo.com) X-YMail-OSG: _SddRmcVM1nJxZCtrZgFURVxnQKAGb2iASLhSLJnIiLQbCS6oOI8qaV3dM1hi4w SuR4XEcrNnbotGWzz2cB1RcWpSB1xsID_7tekZTsYHGjwmwhBZUX3Uxfer74oK8ZZpq8DHeO5LEY eeuAb2eFA0_m8B3xyJ0U9s7AytItHsCZ2yzBpQ0SVkTfx.35GjTd0xjGnxD7fy5Qy78qAvRFRsfQ ZNhBUrCcDhnNBIutlsAj5myteoKJ6ntp2NWJeF_A2g2fE84MDuDpIkG3d2Jc_3QRHuWg2.avm5ZM 4da9fZS0GqBoVA8_ekbGtdIOen3sOKRQsarEddWTozNERLkluYwivu3wNG1Gra.4Dbh7zxMjNU5H Ygk40Y9ORP7d7EB11heasRrxS71RutuocaLB4dtCiPv.moiQvwyFRwC8SHS2NcWahwFfIvURAPJt hplC7FHgei1GlSYZHPAvV6Zp7zHb5Rzw8XdNxdkRVR85EoNzCwHRicSwc4O9q4oRvn7_tNhaVrNR FFCBnZyqu3qz5DNmNLgU9Hw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Fri, 5 Jan 2018 15:25:57 +0000 Date: Fri, 5 Jan 2018 15:25:34 +0000 (UTC) From: Jules Gilbert To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: "Ronald F. Guilmette" , Eric McCorkle , Freebsd Security , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Message-ID: <302406914.1010662.1515165934929@mail.yahoo.com> In-Reply-To: <861sj4tlak.fsf@desk.des.no> References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> <809675000.867372.1515146821354@mail.yahoo.com> <861sj4tlak.fsf@desk.des.no> Subject: Re: Intel hardware bug MIME-Version: 1.0 X-Mailer: WebService/1.1.11150 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:57.0) Gecko/20100101 Firefox/57.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 15:26:04 -0000 Ah, sorry I'm wrong.=C2=A0 I apologize.=C2=A0 I won't intrude further.=C2= =A0 I spoke up because selectively choosing to read sections of kernel memo= ry is one thing, obtaining useful information from an arbitrary block of ke= rnel memory you don't get to choose is quite another. But their are several people here I respect very much and if they say I'm w= rong about an area they focus on,... me bad. On Friday, January 5, 2018, 9:48:50 AM EST, Dag-Erling Sm=C3=B8rgrav wrote: =20 =20 Jules Gilbert writes: > Sorry guys, you just convinced me that no one, not the NSA, not the > FSB, no one!, has in the past, or will in the future be able to > exploit this to actually do something not nice. The technique has already been proven by multiple independent parties to work quite well, allowing an attacker to read kernel memory at speeds of up to 500 kB/s.=C2=A0 But I guess you know better... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no =20 From owner-freebsd-arch@freebsd.org Fri Jan 5 15:53:01 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BABB9EB0A16; Fri, 5 Jan 2018 15:53:01 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 921806F00F; Fri, 5 Jan 2018 15:53:01 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-166-171-187-244.mycingular.net [166.171.187.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 1FE5D8900; Fri, 5 Jan 2018 15:35:14 +0000 (UTC) Subject: Re: Intel hardware bug To: =?UTF-8?Q?C_Bergstr=c3=b6m?= Cc: Freebsd Security , "freebsd-arch@freebsd.org" , FreeBSD Hackers References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> <809675000.867372.1515146821354@mail.yahoo.com> <250f3a77-822b-fba5-dcd7-758dfec94554@metricspace.net> From: Eric McCorkle Message-ID: <755a65eb-b02e-05c5-e1a2-701cfd8bc837@metricspace.net> Date: Fri, 5 Jan 2018 10:35:13 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 15:53:01 -0000 On 01/05/2018 09:55, C Bergström wrote: > Don't bet on it.  There's reports of AMD vulnerabilities, also for ARM. > I doubt any major architecture is going to make it out unscathed.  (But > if one does, my money's on Power) > > > Nope, the only arch that I'm aware of that gets past this is SPARC(hah!) > due to the seperate userland and kernel memory virtualization. Alas, poor Sparc. I knew them, Horatio... It looks like Red Hat is indeed reporting Power9 to be vulnerable: https://access.redhat.com/security/vulnerabilities/speculativeexecution Unfortunate. I hope they get fixed silicon out in time for the Talos II workstation. From owner-freebsd-arch@freebsd.org Fri Jan 5 14:55:36 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5131EADBD3 for ; Fri, 5 Jan 2018 14:55:36 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 664D06C89E for ; Fri, 5 Jan 2018 14:55:36 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: by mail-qt0-x22d.google.com with SMTP id w10so5960943qtb.10 for ; Fri, 05 Jan 2018 06:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pathscale-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4PD0Zfi+So7k9EVdvPlqubBSbdOt7U6U7UmHZ4hrJJQ=; b=Xokg4wOEZfSx4nOCr2bW8OeUDcNsk4cP12sEOsQAMNhZt1HkGLLCMO4PYiRIoxAqjH +xGX4uTdMHxAcrR14EBws2oSYKjXKLDbtTZxVk4psFepbUO+RMf9Sc/LAoMqAlU2qSsy OGxeD4DHh1X+BqNW7My7kk08sMfVwA5IBPI80CEPaJ/LSQAra1/m03feM12mpuFKLPLs NmxWmf4ylUUQVXGqN279GMFhc3EztWR6CP/Ir8xEO4tql/TRWgupmOgYmJbwIWkcBSBl +iFOPm+2CziRbPDQalaTxnDcbmvTbuzktUpCymeK7pgFdvrIeiQRJsV3rnKjXiasaFwp QdQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4PD0Zfi+So7k9EVdvPlqubBSbdOt7U6U7UmHZ4hrJJQ=; b=sjHbShY0EV9RLUaw+IsbmDWML1u8UP4AVitCeBkEE+RaqtbDx9xsAAfW/6u/qyzt6E j0C7x3isgibmf1GiGoFOVmOWhVX+/p3OgB8+hWuiERFJVFpEUlV7iZSKD6c1Tmi5Xovi e1gA2J9ccNiBMg1jYx5Go8XPWFPIwYR7dFG2a3jRfdIEZwfu1U3B+MHh+ut53P6YCftz IzbLIoSf/GPmKp+3gWNHuicXBt10Npcxs0qT0hhVrErzTvnzBWTEO2y4X8y9R9ACAYXS tIZdfyr5A2YzstF+U1sIC9/j8ogc7EfEXnPcvTiofpLW0pW6rz15ZdKd1wgMvatNTr6A A1KQ== X-Gm-Message-State: AKwxytfo8OYs1e2PS+ymsI8tjlnMLVSUirbF9q9BuATyly7pFEuNNmBd KS6t/91341Lxl3ASVOgWDHUKtx9jTLorcT24qyOTtg== X-Google-Smtp-Source: ACJfBouxeRPh4iDo+U5erDZNZHzWjCcih60x2pDe8UTfSk98drVvsV41tDpZAWQkpTHCPThKblkQWFpVHO6ZMuR8MSQ= X-Received: by 10.237.33.154 with SMTP id l26mr4553016qtc.100.1515164135206; Fri, 05 Jan 2018 06:55:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.210.3 with HTTP; Fri, 5 Jan 2018 06:55:14 -0800 (PST) X-Originating-IP: [202.83.99.25] In-Reply-To: <250f3a77-822b-fba5-dcd7-758dfec94554@metricspace.net> References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> <809675000.867372.1515146821354@mail.yahoo.com> <250f3a77-822b-fba5-dcd7-758dfec94554@metricspace.net> From: =?UTF-8?B?QyBCZXJnc3Ryw7Zt?= Date: Fri, 5 Jan 2018 22:55:14 +0800 Message-ID: Subject: Re: Intel hardware bug To: Eric McCorkle Cc: Jules Gilbert , "Ronald F. Guilmette" , Freebsd Security , Brett Glass , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn X-Mailman-Approved-At: Fri, 05 Jan 2018 15:54:09 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 14:55:36 -0000 On Fri, Jan 5, 2018 at 8:42 PM, Eric McCorkle wrote: > On 01/05/2018 05:07, Jules Gilbert wrote: > > Sorry guys, you just convinced me that no one, not the NSA, not the FSB, > > no one!, has in the past, or will in the future be able to exploit this > > to actually do something not nice. > > Attacks have already been demonstrated, pulling secrets out of kernel > space with meltdown and http headers/passwords out of a browser with > spectre. Javascript PoCs are already in existence, and we can expect > them to find their way into adware-based malware within a week or two. > > Also, I'd be willing to bet you a year's rent that certain three-letter > organizations have known about and used this for some time. > > > So what is this, really?, it's a market exploit opportunity for AMD. > > Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. > I doubt any major architecture is going to make it out unscathed. (But > if one does, my money's on Power) > Nope, the only arch that I'm aware of that gets past this is SPARC(hah!) due to the seperate userland and kernel memory virtualization. From owner-freebsd-arch@freebsd.org Fri Jan 5 16:40:53 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C6FEEB30CB; Fri, 5 Jan 2018 16:40:53 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5067171044; Fri, 5 Jan 2018 16:40:52 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (cpe-75-82-218-62.socal.res.rr.com [75.82.218.62]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w05GeeDm023309 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jan 2018 08:40:40 -0800 Subject: Re: Intel hardware bug To: =?UTF-8?Q?C_Bergstr=c3=b6m?= , Eric McCorkle Cc: FreeBSD Hackers , "freebsd-arch@freebsd.org" , Shawn Webb , Freebsd Security , Poul-Henning Kamp , "Ronald F. Guilmette" , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= , Brett Glass , Jules Gilbert References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> <809675000.867372.1515146821354@mail.yahoo.com> <250f3a77-822b-fba5-dcd7-758dfec94554@metricspace.net> From: Nathan Whitehorn Message-ID: Date: Fri, 5 Jan 2018 08:40:39 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVZILE4do3EwanuIbHwb+oXQqQMbU4e5/RAi1Rs7bbWb8We8TNMbM+6jFRuna3/GZxymxTMek3deOLiPVdx5Re4Gm/lJED6aZkw= X-Sonic-ID: C;anAGKjfy5xGXhCeh2dYaJA== M;xAySKjfy5xGXhCeh2dYaJA== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-Mailman-Approved-At: Fri, 05 Jan 2018 16:47:13 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 16:40:53 -0000 On 01/05/18 06:55, C Bergström wrote: > On Fri, Jan 5, 2018 at 8:42 PM, Eric McCorkle wrote: > >> On 01/05/2018 05:07, Jules Gilbert wrote: >>> Sorry guys, you just convinced me that no one, not the NSA, not the FSB, >>> no one!, has in the past, or will in the future be able to exploit this >>> to actually do something not nice. >> Attacks have already been demonstrated, pulling secrets out of kernel >> space with meltdown and http headers/passwords out of a browser with >> spectre. Javascript PoCs are already in existence, and we can expect >> them to find their way into adware-based malware within a week or two. >> >> Also, I'd be willing to bet you a year's rent that certain three-letter >> organizations have known about and used this for some time. >> >>> So what is this, really?, it's a market exploit opportunity for AMD. >> Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. >> I doubt any major architecture is going to make it out unscathed. (But >> if one does, my money's on Power) >> > Nope, the only arch that I'm aware of that gets past this is SPARC(hah!) > due to the seperate userland and kernel memory virtualization. > _______________________________________________ POWER has the same thing. It's actually stronger separation, since user processes don't share addresses either -- all processes, including the kernel, have windowed access to an 80-bit address space, so no process can even describe an address in another process's address space. There are ways, of course, in which IBM could have messed up the implementation, so the fact that it *should* be secure does not mean it *is*. SPARC avoids the issue because almost all implementations are in-order. -Nathan From owner-freebsd-arch@freebsd.org Fri Jan 5 18:24:23 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35CB0EB83A4; Fri, 5 Jan 2018 18:24:23 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D01AF76945; Fri, 5 Jan 2018 18:24:16 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w05IO4bV079748; Fri, 5 Jan 2018 10:24:10 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "=?UTF-8?B?RnJlZWJzZCBTZWN1cml0eSIgPGZyZWVic2Qtc2VjdXJpdHlAZnJlZWJzZC5vcmc+LCAiRnJlZUJTRCBIYWNrZXJzIiA8ZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnPiwgIiBmcmVlYnNkLWFyY2hAZnJlZWJzZC5vcmc+IiA8ZnJlZWJzZC1hcmNoQGZyZWVic2Qub3JnPiwgIkMgQmVyZ3N0csO2bSIgPGNiZXJnc3Ryb21AcGF0aHNjYWxlLmNvbT4=?= In-Reply-To: <755a65eb-b02e-05c5-e1a2-701cfd8bc837@metricspace.net> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Eric McCorkle" Subject: Re: Intel hardware bug Date: Fri, 05 Jan 2018 10:24:10 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 05 Jan 2018 18:40:10 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 18:24:24 -0000 On Fri, 5 Jan 2018 10:35:13 -0500 "Eric McCorkle" sa= id > On 01/05/2018 09:55, C Bergstr=C3=B6m wrote: >=20 > > Don't bet on it=2E=C2=A0 There's reports of AMD vulnerabilities, also= for ARM=2E > > I doubt any major architecture is going to make it out unscathed=2E= =C2=A0 (But > > if one does, my money's on Power) > >=20 > >=20 > > Nope, the only arch that I'm aware of that gets past this is SPARC(hah!= ) > > due to the seperate userland and kernel memory virtualization=2E >=20 > Alas, poor Sparc=2E I knew them, Horatio=2E=2E=2E Ahh, good ol' SPARC! >=20 > It looks like Red Hat is indeed reporting Power9 to be vulnerable: >=20 > https://access=2Eredhat=2Ecom/security/vulnerabilities/speculativeexecution >=20 > Unfortunate=2E I hope they get fixed silicon out in time for the Talos II > workstation=2E What *I* want to know; is whether they're going to drastically reduce the price on all the affected processors? As it stands, they should be practically giving them away=2E How is it that the burden lies on the OS vendors, and not the manufacturers?! --Chris From owner-freebsd-arch@freebsd.org Fri Jan 5 19:11:53 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BB74EBA7E3; Fri, 5 Jan 2018 19:11:53 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EFB8E78A87; Fri, 5 Jan 2018 19:11:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id XXP8eEwCzS7BpXXP9eXXNd; Fri, 05 Jan 2018 12:11:51 -0700 X-Authority-Analysis: v=2.2 cv=NKylwwyg c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=EA5itrwUPoEA:10 a=RgaUWeydRksA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=Vd537ib8pVup7S2X7pQA:9 a=r4kWtJy-rJYS1cas:21 a=y9lL4hI3jn-rAOdh:21 a=pILNOxqGKmIA:10 a=COlSyhbwSJSHYInWLu4A:9 a=BC4vU4yZLJsX9d_B:21 a=NuoWA5lUaQeHgTHG:21 a=TUJ8KVh8p4i7ngx5:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [10.168.3.146] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id 404BC335; Fri, 5 Jan 2018 11:11:44 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Intel hardware bug Date: Fri, 5 Jan 2018 11:11:49 -0800 To: Eric McCorkle , Jules Gilbert , "Ronald F. Guilmette" , Freebsd Security , Brett Glass , =?Windows-1252?Q?Dag-Erling_Sm=F8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Message-Id: <20180105191145.404BC335@spqr.komquats.com> X-CMAE-Envelope: MS4wfH322YrJxfBdQecR2LYFVCLIcE5yPI+FMR67fSdSbX5SZNmSHuWMZP7kLJHrNWkbgGHQJ/Or6pAKfo03lnxd/sr7jTjNhJOjwkd44edBoGATMMjkXkI3 QM1dGSB6Vp70ELNp2fudaiCoxqi/sSxgNbHOxHCZPKco7vbxWasxjK/xIeNfsQ90oMZy78xsGjH7/42XYf0s1tOdrO79NeTAaOgpEhVdcGycCsSKn1Vrsyf/ 0b7qFEzTR+OrUYKggiGe3R39N7Tsq7kRSH9ozokVOVGtkXPsIXHtFR4Ha+0FH6geOENSSPbrnLQDlqkVK1tB1JSwwxlfvtrLzqbnGebFHY7UbeABwcbKbREQ E957EaJEwBCxDZeXdMMRAz0wJG0rsDbL5/RqnCasMHNFNZHtXsB9gpwx6uFN5fe/x2JZp+z2wyYPcnfhOsDFKNnxIIsT93mQKpo0CGwZBe/aP/WNW108+A7J m4inBWLIpFHQhB+k3DJ7NuRQtWHCRRMsfRyDgciOvgFdJs5uInksvHNLeCs2dCVcxrd/0OEtesKcffNmJ202SvP9sfcio88q7p06NcgR5ZnbgIPasMXEyIkx A18St45WB/9j3BJcLTKyp/qHS5n+0oAkT6FYhBYcXnYjW7/clj7YZhl8vEKwc3DmV/wAV2OUS3GEUraS4JMGa5Dz X-Mailman-Approved-At: Fri, 05 Jan 2018 19:22:12 +0000 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 19:11:53 -0000 According to a Red Hat announcement, Power and Series z are also vulnerable= . --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Eric McCorkle Sent: 05/01/2018 04:48 To: Jules Gilbert; Ronald F. Guilmette; Freebsd Security; Brett Glass; Dag-= Erling Sm=F8rgrav; Poul-Henning Kamp; freebsd-arch@freebsd.org; FreeBSD Hac= kers; Shawn Webb; Nathan Whitehorn Subject: Re: Intel hardware bug On 01/05/2018 05:07, Jules Gilbert wrote: > Sorry guys, you just convinced me that no one, not the NSA, not the FSB, > no one!, has in the past, or will in the future be able to exploit this > to actually do something not nice. Attacks have already been demonstrated, pulling secrets out of kernel space with meltdown and http headers/passwords out of a browser with spectre. Javascript PoCs are already in existence, and we can expect them to find their way into adware-based malware within a week or two. Also, I'd be willing to bet you a year's rent that certain three-letter organizations have known about and used this for some time. > So what is this, really?, it's a market exploit opportunity for AMD. Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. I doubt any major architecture is going to make it out unscathed. (But if one does, my money's on Power) _______________________________________________ freebsd-arch@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Jan 5 19:53:44 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14885EBD0B2; Fri, 5 Jan 2018 19:53:44 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BBFD7B171; Fri, 5 Jan 2018 19:53:43 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id h137so6244147lfe.8; Fri, 05 Jan 2018 11:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ky/ziy21wuNrx6LeM9kDYxphvOfDrWGuamPAcyLFoyQ=; b=d8mikptJfKSgq/Plw56qX0mkSPbAkIBgFcClyMWNHXZXn+wHIce4L6MLc1kzIh62O+ 0q4RdjMmwq59nCzRaOdHKKhiunrexnPIsHgfsBsdgqMGEDIbMeXcq9kH395EiZyBSWMi l5I22tyz+G+c9yLiLd4vHlnYCSKRr67+etdr7aUySD95fsDubjnJ3C27ftXZ/ZfcymuB wozHvReBFr//b6vtFTWDirbR9N7rDg3kwBhRJNh/i/j7a6uVm7epHtYwvbr5zX+Pi9d+ CJqfAvpFSIIOzJ7JEGDb2zNt7fBekkf4t9wPSwcM0zOTUsCdfbqXtDyDUxLhzZNvesPs 8Dqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ky/ziy21wuNrx6LeM9kDYxphvOfDrWGuamPAcyLFoyQ=; b=XV2td7OqIzB3pAiVLMF3ZDrAR1t1wWA8F8RCFZdBn7KT1nQucK+Igu1HglVrkzP+Se YG+c8jeQlKIb+Vk2pZ+GuUe1kYF4IERh2suuWfG0Y29rhY39HleWIHWJ3wwn5TuBA/aB FN4a6CW13LKJsVKAeq504l/cfacJiDuR1OxlMyAp3fzjt0zi2NMCrdBehkruDfsTFlVf KPZbRSLuNkrA7qdubBxD/y7gSFpg9Gm52taYZErEINHD1bi9Jzfzmu5U6jjcdqRph/RI KGf7oV3AQkK1Zw2rg/gVfcTJF8SaNAN3Or48aktiwBqt6WOqbU3tDsU498fvLUUCzD9v lYvQ== X-Gm-Message-State: AKGB3mKU7PCS7WU6xVb5/uZ7EQUeeAE/wXUha2jxrM9jOjQ9nvcMZalV 2Q3JbN2Vj7JI09d3sr8FDG0rXAsgNfz1AlO0gUgHweck X-Google-Smtp-Source: ACJfBovbFN+wtgncUsoK8jC9T2axtY4jre5KXApipVpLUMad7mBkpUq+3SkJ9VzkZirFREU+19DtnlSJhitlqJl1FGA= X-Received: by 10.25.42.68 with SMTP id f65mr2037762lfl.25.1515182020362; Fri, 05 Jan 2018 11:53:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.207 with HTTP; Fri, 5 Jan 2018 11:53:39 -0800 (PST) In-Reply-To: <20180105191145.404BC335@spqr.komquats.com> References: <20180105191145.404BC335@spqr.komquats.com> From: Freddie Cash Date: Fri, 5 Jan 2018 11:53:39 -0800 Message-ID: Subject: Re: Intel hardware bug To: Cy Schubert Cc: Freebsd Security , "freebsd-arch@freebsd.org" , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 19:53:44 -0000 On Fri, Jan 5, 2018 at 11:11 AM, Cy Schubert wrote: > According to a Red Hat announcement, Power and Series z are also > vulnerable. > =E2=80=8B > =E2=80=8BThere's a lot of confusion in the media, press releases, and annou= ncements due to conflating Spectre and Meltdown. Meltdown (aka CVE-2017-5754) is the issue that affects virtually all Intel CPUs and specific ARM Cortex-A CPUs. This allows read-access to kernel memory from unprivileged processes (ring 3 apps get read access to ring 0 memory).=E2=80=8B IBM POWER, Oracle Sparc, and AMD Zen are not affected by= this issue as they provide proper separation between kernel memory maps and userland memory maps; or they aren't OoO architectures that use speculative execution in this manner. Spectre (aka CVE-2017-5715 and CVE-2017-5753) is the issue that affects all CPUs (Intel, AMD, ARM, IBM, Oracle, etc) and allows userland processes to read memory assigned to other userland processes (but does NOT give access to kernel memory). =E2=80=8BIOW, POWER and Sparc are vulnerable to Spectre, but not vulnerable= to Meltdown. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-arch@freebsd.org Fri Jan 5 20:20:18 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBAB3EBE46C for ; Fri, 5 Jan 2018 20:20:18 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 57D057C425 for ; Fri, 5 Jan 2018 20:20:18 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: (qmail 64581 invoked by uid 89); 5 Jan 2018 20:12:51 -0000 Received: from c-24-0-179-87.hsd1.nj.comcast.net (HELO iMac.local) (jan@digitaldaemon.com@24.0.179.87) by digitaldaemon.com with SMTP; 5 Jan 2018 20:12:51 -0000 Subject: Re: Intel hardware bug To: Freddie Cash Cc: Freebsd Security , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <20180105191145.404BC335@spqr.komquats.com> From: Jan Knepper Message-ID: <65e5dcae-b973-a54e-868e-bdc4abf007cb@digitaldaemon.com> Date: Fri, 5 Jan 2018 15:12:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 20:20:18 -0000 Thank you! The news indeed does not properly understand the difference, nor which problem affects which hardware/CPU and in many ways acts like it is "the end of the world". On 01/05/2018 14:53, Freddie Cash wrote: > On Fri, Jan 5, 2018 at 11:11 AM, Cy Schubert > wrote: > >> According to a Red Hat announcement, Power and Series z are also >> vulnerable. >> ​ >> > ​There's a lot of confusion in the media, press releases, and announcements > due to conflating Spectre and Meltdown. > > Meltdown (aka CVE-2017-5754) is the issue that affects virtually all Intel > CPUs and specific ARM Cortex-A CPUs. This allows read-access to kernel > memory from unprivileged processes (ring 3 apps get read access to ring 0 > memory).​ IBM POWER, Oracle Sparc, and AMD Zen are not affected by this > issue as they provide proper separation between kernel memory maps and > userland memory maps; or they aren't OoO architectures that use speculative > execution in this manner. > > Spectre (aka CVE-2017-5715 and CVE-2017-5753) is the issue that affects all > CPUs (Intel, AMD, ARM, IBM, Oracle, etc) and allows userland processes to > read memory assigned to other userland processes (but does NOT give access > to kernel memory). > > ​IOW, POWER and Sparc are vulnerable to Spectre, but not vulnerable to > Meltdown. > From owner-freebsd-arch@freebsd.org Fri Jan 5 19:37:18 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91EA0EBC262; Fri, 5 Jan 2018 19:37:18 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50BC77A4F7; Fri, 5 Jan 2018 19:37:18 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id j14so3774508oih.3; Fri, 05 Jan 2018 11:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=j5Lww5hOJTkHgnR5QlIw9v5SKLLqOgRo4YfIbtQFYNY=; b=YSvKHjrzNa3uzNxadLBIeSbptOZiF6XWNn+K/6xxbYxxmHAj5+zfQtUyUwjwj+BFNH 7gt+qqizXsgyDgTqr+hwK4XRuxIsRDdoo0C7tusyla3b/uM6TGK20KztmKG2M3Y3hz6W FEC0acah+MxEVSjn6NiVZVaCAVScADylhEG3NjIMhKCSszFGvCAMRCeM5dtGAMjroLa2 XOTDCphqH/gxAU+5xJ5OOvzk4aex/lNtUGgQpwxwFoWOXiSud7M43L6GGk2MNNKrQ52q MHHFom8BkpK9EI7E/9gBl0/FzbAgv7qGtJRMOwx/A3P8iTS6HupuPf5GGixr0ClyF62N +ASg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=j5Lww5hOJTkHgnR5QlIw9v5SKLLqOgRo4YfIbtQFYNY=; b=lzET+UPxNoSBeWwbBymKzjfTyW1JKPRm4j4j0GC7IaFWpxzAiyO4cu8vOK4P6kHR6K McBGUOV/KxHCqWCADkIjD8ehtk6zjHtPO4G4bgUuaxu0GHBiLYxJYYT9I4kY1778Q4gY RFEUEH57gxq+SdZbHs04F7AfYGeagI025O21RMLqdt0ENc1hWyrKcLsI1xYDY+X/SVVr VypMiEuYBHGvKurAcNhvptHRbkZCOSxMMLAF3OJncho0eKOCPl5Cky3sSDiJ0a/UAirL /jI1irxEbalRVMBoiM33BDpgUcxHJ1ShsQnpgPwO9Sfd3izgvrn4WEx23QbMOIBelqMA 15ZQ== X-Gm-Message-State: AKGB3mIY3HV5Suq6vzxgaAim+/eqSfKjgmuT9CU40eWHCE/443KPWPtf ZyzWuyQO4H+S/B2kK8D+Se4l0EcIJPiE8JQa7aIxSg== X-Google-Smtp-Source: ACJfBovkWnm66+zvXb4XM73KT3niZsopBq7jwSyGn99gc6HbVmGi9ZgcIyGONAzc/eDT05C0HccurmJpmrajRkmJ3Vs= X-Received: by 10.202.57.87 with SMTP id g84mr2035556oia.201.1515181037442; Fri, 05 Jan 2018 11:37:17 -0800 (PST) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.157.88.201 with HTTP; Fri, 5 Jan 2018 11:37:17 -0800 (PST) In-Reply-To: <20180105191145.404BC335@spqr.komquats.com> References: <20180105191145.404BC335@spqr.komquats.com> From: "K. Macy" Date: Fri, 5 Jan 2018 11:37:17 -0800 X-Google-Sender-Auth: YcqGLBjADoDtXpu6XXvSQHD1BXU Message-ID: Subject: Re: Intel hardware bug To: Cy Schubert Cc: Eric McCorkle , Jules Gilbert , "Ronald F. Guilmette" , Freebsd Security , Brett Glass , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 05 Jan 2018 20:33:09 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 19:37:18 -0000 On Fri, Jan 5, 2018 at 11:11 AM, Cy Schubert wr= ote: > According to a Red Hat announcement, Power and Series z are also vulnerab= le. > Link? > --- > > -----Original Message----- > From: Eric McCorkle > Sent: 05/01/2018 04:48 > To: Jules Gilbert; Ronald F. Guilmette; Freebsd Security; Brett Glass; Da= g-Erling Sm=C3=B8rgrav; Poul-Henning Kamp; freebsd-arch@freebsd.org; FreeBS= D Hackers; Shawn Webb; Nathan Whitehorn > Subject: Re: Intel hardware bug > > On 01/05/2018 05:07, Jules Gilbert wrote: >> Sorry guys, you just convinced me that no one, not the NSA, not the FSB, >> no one!, has in the past, or will in the future be able to exploit this >> to actually do something not nice. > > Attacks have already been demonstrated, pulling secrets out of kernel > space with meltdown and http headers/passwords out of a browser with > spectre. Javascript PoCs are already in existence, and we can expect > them to find their way into adware-based malware within a week or two. > > Also, I'd be willing to bet you a year's rent that certain three-letter > organizations have known about and used this for some time. > >> So what is this, really?, it's a market exploit opportunity for AMD. > > Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. > I doubt any major architecture is going to make it out unscathed. (But > if one does, my money's on Power) > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Jan 5 19:47:46 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2408EBC993; Fri, 5 Jan 2018 19:47:46 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E84F7ABE9; Fri, 5 Jan 2018 19:47:46 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-oi0-x22f.google.com with SMTP id w125so3778605oie.7; Fri, 05 Jan 2018 11:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=SBVbEq8aFAKbgpNgZlwITSCuachsMiVKCY3Y34M+Ok4=; b=icbzQZqRsdIYvp/iVR07/aVfxXJdvVjGAQTc2YCbFZv1//6BsJ+m8FXjLFzBDaKDhC 5twVcgXWEBf+gMWd6B7oBvZrZ7k42F3yj4K+SleKcBGU3/XFgjuJ0odnjmKpNSVfq4Et d5RqDi2khJZhkQ7NUwWVEGTg+zgGwJ6fw4y6EetTb9wb/llPeYNX1VKeYFvYxTtCNjnH 1XC17egYymlAixoGDcj4IwXTWAiSXsz5a5jC2F0y9+YEAX7WHc64i/DRAqM2V823keH8 nmjCQREqBKXzUV8V4qDxTnoftESHIibJQkLS8Syadi+2yODgdwyddHZyQUVHhkd5kqdE o/lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=SBVbEq8aFAKbgpNgZlwITSCuachsMiVKCY3Y34M+Ok4=; b=RITX5oNIw2bMGmQXllVjz9ZJCKiCmIScNR22vQs6jJL9wv+ebQjssS9CUNt9nyZOq3 Ry4BMiDsTwSIfH/n+ppTctlzVzuRcWy4pVgGBv4tDr+IQTRGRSFqQh7uDtodAq4cqd31 qd7dfb82GGVAw2CAQegeosROliTz+ez8yHO/l9VUChIlvU3cBb2iFw5IGrbM+Gb2UAVQ u11yI6yJvBSMNrF3HWNIhQ5wIKCrCu3Lz8139WkHuQq+YDse8XMm2QNrSYHtrTClza4l yMyoIQsXYutUQ6qEIF6e8qMNkEJ/RJauk5XwV/d7pQ+YtFxNd1b2uP7C1KH9gOSG15/e 8u7g== X-Gm-Message-State: AKGB3mJkaqJvEQE9ZS09s+Uap2zgtP9gTFP6gquNpPY22xHJHnpqAZd8 q6pklZL+FJQd9dfAa0c6F91pVQB70zjwKRye/zs= X-Google-Smtp-Source: ACJfBosiwiG1zx9hC6ZAi3zdYyVSAHiUbRLdW3Spf9Ljt82P0aumoVmMV+GWR08/NJk62dzyCnAj++/kie4Izd5IrcE= X-Received: by 10.202.57.87 with SMTP id g84mr2049019oia.201.1515181665680; Fri, 05 Jan 2018 11:47:45 -0800 (PST) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.157.88.201 with HTTP; Fri, 5 Jan 2018 11:47:45 -0800 (PST) In-Reply-To: References: <20180105191145.404BC335@spqr.komquats.com> From: "K. Macy" Date: Fri, 5 Jan 2018 11:47:45 -0800 X-Google-Sender-Auth: bznOiYGbOMhIL_8UvY7BwimpOhY Message-ID: Subject: Re: Intel hardware bug To: Cy Schubert Cc: Eric McCorkle , Jules Gilbert , "Ronald F. Guilmette" , Freebsd Security , Brett Glass , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 05 Jan 2018 21:02:17 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 19:47:46 -0000 On Fri, Jan 5, 2018 at 11:37 AM, K. Macy wrote: > On Fri, Jan 5, 2018 at 11:11 AM, Cy Schubert = wrote: >> According to a Red Hat announcement, Power and Series z are also vulnera= ble. >> > > Link? Spectre yes. Meltdown no. Spectre is a problem but much harder to exploit. It's Intel's handling of meltdown that is seriously grounds for table flipping. https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/ > > >> --- >> >> -----Original Message----- >> From: Eric McCorkle >> Sent: 05/01/2018 04:48 >> To: Jules Gilbert; Ronald F. Guilmette; Freebsd Security; Brett Glass; D= ag-Erling Sm=C3=B8rgrav; Poul-Henning Kamp; freebsd-arch@freebsd.org; FreeB= SD Hackers; Shawn Webb; Nathan Whitehorn >> Subject: Re: Intel hardware bug >> >> On 01/05/2018 05:07, Jules Gilbert wrote: >>> Sorry guys, you just convinced me that no one, not the NSA, not the FSB= , >>> no one!, has in the past, or will in the future be able to exploit this >>> to actually do something not nice. >> >> Attacks have already been demonstrated, pulling secrets out of kernel >> space with meltdown and http headers/passwords out of a browser with >> spectre. Javascript PoCs are already in existence, and we can expect >> them to find their way into adware-based malware within a week or two. >> >> Also, I'd be willing to bet you a year's rent that certain three-letter >> organizations have known about and used this for some time. >> >>> So what is this, really?, it's a market exploit opportunity for AMD. >> >> Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. >> I doubt any major architecture is going to make it out unscathed. (But >> if one does, my money's on Power) >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Jan 5 19:47:48 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 278A4EBC99B; Fri, 5 Jan 2018 19:47:48 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BFA097ABEA; Fri, 5 Jan 2018 19:47:47 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id XXxxeF6ugS7BpXXxyeXg6c; Fri, 05 Jan 2018 12:47:46 -0700 X-Authority-Analysis: v=2.2 cv=NKylwwyg c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=RgaUWeydRksA:10 a=20KFwNOVAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=uzSovi_1LZDTydRZN2AA:9 a=8J4chuak_uIRPK4g:21 a=pVYAQAJm03auPRN6:21 a=QEXdDO2ut3YA:10 a=MMjiIUenpLf6ge6zeOQA:9 a=ZsGH8CjA44_So7fI:21 a=I18adWnKP6q6kCHM:21 a=Th99hHS62kTuvYDY:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [10.168.3.146] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id EAFBB3EA; Fri, 5 Jan 2018 11:47:43 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Intel hardware bug Date: Fri, 5 Jan 2018 11:47:49 -0800 To: "K. Macy" , Cy Schubert CC: Eric McCorkle , Jules Gilbert , "Ronald F. Guilmette" , Freebsd Security , Brett Glass , =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Message-Id: <20180105194743.EAFBB3EA@spqr.komquats.com> X-CMAE-Envelope: MS4wfDfdNQ2Axb8uIQDJJKM+DFEBFjWsWorXKt0r8ks+tP0iKOErSoRXaeUrk2rDccno983U/CQgBtyh3RxCJ8FYzS+MJTKRz/sNso857+DlZa38tr0/3+VV c+vz41Fndb7Z5Hy3sIKDK7QnsHQdNUaCySGj5ONXpi1Yyl5x0iiGcN/9otJZkc26KDXwd2iJ9ZFok/nFmkacXxzE8TW4iDDV9qu5dI031RM9GDyQnZFAqfC/ m16owC1IwLIZs+FX0NcKdPZCDDS+X8GtOmMVeG5wnAj7YcqNBfUrUC8Vn8BHfpHoh1mkcQQ+UVEB5oU8tee/fYO7uuZCeGXdvyWbEAHWKnl+jj4++BfhudXA LnUklwoijzWov8l+P8h0dZl0K9Mv/7eQ/f4Ak5bJsQOY82hYGTHr8FZXoqjks345GWdMBUIGoLY7CgkI3qIpdgAmC+nz+mxNBsgp4qjR/D99e2jTznHpkukE dsk5H+6SULQcJ4XPRC0igRLJYvAWOpc+j7EgZYXs8shYOKtZNLJFlmPAMsFuMwm48eQU6CexknliTsA6/G8XYS8mDZ9ZwL7Q6U1SZiPEhUzgex4Yzo7wVIuC eyxaQfebLC9cLMj+FTKpQ9af70utNzbeL1nNqK5zaWQistOf/g99kRc7nJnjI2/XT+bhzBxL81UTDQSc542RpYoW5FywQPa4nqwAXdBH10aInabgLxudA5IY TyCIfunthjw= X-Mailman-Approved-At: Fri, 05 Jan 2018 21:31:14 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 19:47:48 -0000 https://access.redhat.com/security/vulnerabilities/speculativeexecution?sc_= cid=3D701f2000000tsLNAAY& --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: K. Macy Sent: 05/01/2018 11:37 To: Cy Schubert Cc: Eric McCorkle; Jules Gilbert; Ronald F. Guilmette; Freebsd Security; Br= ett Glass; Dag-Erling Sm=C3=B8rgrav; Poul-Henning Kamp; freebsd-arch@freebs= d.org; FreeBSD Hackers; Shawn Webb; Nathan Whitehorn Subject: Re: Intel hardware bug On Fri, Jan 5, 2018 at 11:11 AM, Cy Schubert wr= ote: > According to a Red Hat announcement, Power and Series z are also vulnerab= le. > Link? > --- > > -----Original Message----- > From: Eric McCorkle > Sent: 05/01/2018 04:48 > To: Jules Gilbert; Ronald F. Guilmette; Freebsd Security; Brett Glass; Da= g-Erling Sm=C3=B8rgrav; Poul-Henning Kamp; freebsd-arch@freebsd.org; FreeBS= D Hackers; Shawn Webb; Nathan Whitehorn > Subject: Re: Intel hardware bug > > On 01/05/2018 05:07, Jules Gilbert wrote: >> Sorry guys, you just convinced me that no one, not the NSA, not the FSB, >> no one!, has in the past, or will in the future be able to exploit this >> to actually do something not nice. > > Attacks have already been demonstrated, pulling secrets out of kernel > space with meltdown and http headers/passwords out of a browser with > spectre. Javascript PoCs are already in existence, and we can expect > them to find their way into adware-based malware within a week or two. > > Also, I'd be willing to bet you a year's rent that certain three-letter > organizations have known about and used this for some time. > >> So what is this, really?, it's a market exploit opportunity for AMD. > > Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. > I doubt any major architecture is going to make it out unscathed. (But > if one does, my money's on Power) > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Jan 5 22:02:15 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90F42EC347A; Fri, 5 Jan 2018 22:02:15 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 622EA80BCA; Fri, 5 Jan 2018 22:02:15 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-166-171-187-244.mycingular.net [166.171.187.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 944EC8A2A; Fri, 5 Jan 2018 22:02:12 +0000 (UTC) Subject: Fwd: A more general possible meltdown/spectre countermeasure References: To: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" From: Eric McCorkle X-Forwarded-Message-Id: Message-ID: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> Date: Fri, 5 Jan 2018 17:02:11 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:02:15 -0000 Re-posting to -hackers and -arch. I'm going to start working on something like this over the weekend. -------- Forwarded Message -------- Subject: A more general possible meltdown/spectre countermeasure Date: Thu, 4 Jan 2018 23:05:40 -0500 From: Eric McCorkle To: freebsd-security@freebsd.org I've thought more about how to deal with meltdown/spectre, and I have an idea I'd like to put forward. However, I'm still in something of a panic mode, so I'm not certain as to its effectiveness. Needless to say, I welcome any feedback on this, and I may be completely off-base. I'm calling this a "countermeasure" as opposed to a "mitigation", as it's something that requires modification of code as opposed to a drop-in patch. == Summary == Provide a kernel and userland API by which memory allocation can be done with extended attributes. In userland, this could be accomplished by extending MMAP flags, and I could imagine a malloc-with-attributes flag. In kernel space, this must already exist, as drivers need to allocate memory with various MTRR-type attributes set. The immediate aim here is to store sensitive information that must remain memory-resident in non-cacheable memory locations (or, if more effective attribute combinations exist, using those instead). See the rationale for the argument why this should work. Assuming the rationale holds, then the attack surface should be greatly reduced. Attackers would need to grab sensitive data out of stack frames or similar locations if/when it gets copied there for faster use. Moreover, if this is done right, it could dovetail nicely into a framework for storing and processing sensitive assets in more secure hardware[0] (like smart cards, the FPGAs I posted earlier, or other options). The obvious downside is that you take a performance hit storing things in non-cacheable locations, especially if you plan on doing heavy computation in that memory (say, encryption/decryption). However, this is almost certainly going to be less than the projected 30-50% performance hit from other mitigations. Also, this technique should work against spectre as well as meltdown (assuming the rationale holds). The second downside is that you have to modify code for this to work, and you have to be careful not to keep copies of sensitive information around too long (this gets tricky in userland, where you might get interrupted and switched out). [0]: Full disclosure, enabling open hardware implementations of this kind of thing is something of an agenda of mine. == Rationale == (Again, I'm tired, rushed, and somewhat panicked so my logic could be faulty at any point, so please point it out if it is) The rationale for why this should work relies on assumptions about out-of-order pipelines that cannot be guaranteed to hold, but are extremely likely to be true. As background, these attacks depend on out-of-order execution performing operations that end up affecting cache and branch-prediction state, ultimately storing information about sensitive data in these side-channels before the fault conditions are detected and acted upon. I'll borrow terminology from the paper, using "transient instructions" to refer to speculatively executed instructions that will eventually be cancelled by a fault. These attacks depend entirely on transient instructions being able to get sensitive information into the processor core and then perform some kind of instruction on them before the fault condition cancels them. Therefore, anything that prevents them from doing this *should* counter the attack. If the actual sensitive data never makes it to the core before the fault is detected, the dependent memory accesses/branches never get executed and the data never makes it to the side-channels. Another assumption here is that CPU architects are going to want to squash faulted instructions ASAP and stop issuing along those speculative branches, so as to reclaim execution units. So I'm assuming once a fault comes back from address translation, then transient execution stops dead. Now, break down the cases for whether the address containing sensitive data is in cache and TLB or not. (I'm assuming here that caches are virtually-indexed, which enables cache lookups to bypass address translation.) * In cache, in TLB: You end up basically racing between the cache and TLB, which will very likely end up detecting the fault before the data arrives, but at the very worst, you get one or two cycles of transient instruction execution before the fault. * In cache, not in TLB: Virtually-indexed tagged means you get a cache lookup racing a page-table walk. The cache lookup beats the page table walk by potentially hundreds (maybe thousands) of cycles, giving you a bunch of transient instructions before a fault gets triggered. This is the main attack case. * Not in cache, in TLB: Memory access requires address translation, which comes back almost immediately as a fault. * Not in cache, not in TLB: You have to do a page table walk before you can fetch the location, as you have to go out to physical memory (and therefore need a physical address). The page table walk will come back with a fault, stopping the attack. So, unless I'm missing something here, both non-cached cases defeat the meltdown attack, as you *cannot* get the data unless you do address translation first (and therefore detect faults). As for why this defeats the spectre attack, the logic is similar: you've jumped into someone else's executable code, hoping to scoop up enough information into your branch predictor before the fault kicks you out. However, to capture anything about sensitive information in your side-channels, the transient instructions need to actually get it into the core before a fault gets detected. The same case analysis as above applies, so you never actually get the sensitive info into the core before a fault comes back and you get squashed. [1]: A physically-indexed cache would be largely immune to this attack, as you'd have to do address translation before doing a cache lookup. I have some ideas that can build on this, but I'd like to get some feedback first. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Jan 5 22:10:29 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 534F4EC3AF4 for ; Fri, 5 Jan 2018 22:10:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13F931148 for ; Fri, 5 Jan 2018 22:10:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id e20so7194322iof.12 for ; Fri, 05 Jan 2018 14:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jci+Z9Xe8awaerfggkkSkVqYjBtP7tk6M6Xctaj+xa8=; b=tEUd4qLuvqDE18qbUAndFd/UJbs+9ElRtkDhAW03Waa72e9NNDtzoud7r2QujU8IZw XoIriXE4Nf3yzsuO+W0sw5CLkMmIRQlwR4DXPwkNLw17jpwL/x0xUmUb2LmH1X43w6Qc yILyXS+ZZouUwuF1ZRiSjkhLXZd/a1J7V8s8dSlqbekpfljh+QGqGIy+B7+5VFBu/z1W jeXw4dkF0ldUPPpflN1GLGwr8yaFazq6acW8OIaqhEGot8ifhrlnSik/oPtVJEndgCPZ vzNnOhMHWsvPK35YfhytYq6CR8jPvf8Yjm4KjTSE54VptFb84mgXYKVv4cdBqRdKWS3Z NThA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jci+Z9Xe8awaerfggkkSkVqYjBtP7tk6M6Xctaj+xa8=; b=cOLpkQu0CrBT7BxKUE/X3wNlMukx7+LeKEVrt7AT7uWbD/KGdENYLip74zzOgk7iwE 32KGcj7FO0yaJn1fSCDm6ORTWkW6+KybYmpsCKJZ4Ma28/fAFbW3GL3J2pbbJUyty8qB OlSETHo8xBzbx9PLHxmFtGpi3FjV0Vxu7gM8uZOubYqllfKsEqJKwXl5jT/wP0ibDH2v 5zr311fpJAM3YS0ELoOwRuc9A+E4qUf+35WMTOBeZy9dFv58z56aZOrlfLIFDod7czeP u2hFawJZ6Pd2Y5hwaxfQ6ktBagSvCgW4qq3k0pA4XNQLFk1uYHJSZrgfzc6w2zeXWQ9y YtIA== X-Gm-Message-State: AKwxytffIHPEiQLKrNeVGEBI9sTWKTXpiKTlpzof9K+5reGhlQcOx9Sr 0wGQWizGvEwA+kBuFP6wMLtngsRe7z5+gF/d0PUXWg== X-Google-Smtp-Source: ACJfBotloPRlXMoKAWC+qNeHs2vWdnYqKBHbANltsOo6Ymgt9q4iQG5LVcYj3Zxk9O2j2tzmzS9KnHqJH5XAZdr/X1o= X-Received: by 10.107.78.12 with SMTP id c12mr4360284iob.63.1515190228036; Fri, 05 Jan 2018 14:10:28 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Fri, 5 Jan 2018 14:10:27 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> From: Warner Losh Date: Fri, 5 Jan 2018 15:10:27 -0700 X-Google-Sender-Auth: gx4T-5845RC6oqVpg5Hx_fwx1ls Message-ID: Subject: Re: A more general possible meltdown/spectre countermeasure To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:10:29 -0000 I think this is fatally flawed. The side channel is the cache. Not the data at risk. Any mapped memory, cached or not, can be used to influence the cache. Storing stuff in uncached memory won't affect the side channel one bit. Basically, all attacks boil down to tricking the processor, at elevated privs, to doing something like a = foo[offset]; where foo + offset are designed to communicate information by populating a cache line. offset need not be cached itself and can be the result of simple computations that depend on anything accessible at all in the kernel. Warner On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle wrote: > Re-posting to -hackers and -arch. I'm going to start working on > something like this over the weekend. > > -------- Forwarded Message -------- > Subject: A more general possible meltdown/spectre countermeasure > Date: Thu, 4 Jan 2018 23:05:40 -0500 > From: Eric McCorkle > To: freebsd-security@freebsd.org > > I've thought more about how to deal with meltdown/spectre, and I have an > idea I'd like to put forward. However, I'm still in something of a > panic mode, so I'm not certain as to its effectiveness. Needless to > say, I welcome any feedback on this, and I may be completely off-base. > > I'm calling this a "countermeasure" as opposed to a "mitigation", as > it's something that requires modification of code as opposed to a > drop-in patch. > > == Summary == > > Provide a kernel and userland API by which memory allocation can be done > with extended attributes. In userland, this could be accomplished by > extending MMAP flags, and I could imagine a malloc-with-attributes flag. > In kernel space, this must already exist, as drivers need to allocate > memory with various MTRR-type attributes set. > > The immediate aim here is to store sensitive information that must > remain memory-resident in non-cacheable memory locations (or, if more > effective attribute combinations exist, using those instead). See the > rationale for the argument why this should work. > > Assuming the rationale holds, then the attack surface should be greatly > reduced. Attackers would need to grab sensitive data out of stack > frames or similar locations if/when it gets copied there for faster use. > Moreover, if this is done right, it could dovetail nicely into a > framework for storing and processing sensitive assets in more secure > hardware[0] (like smart cards, the FPGAs I posted earlier, or other > options). > > The obvious downside is that you take a performance hit storing things > in non-cacheable locations, especially if you plan on doing heavy > computation in that memory (say, encryption/decryption). However, this > is almost certainly going to be less than the projected 30-50% > performance hit from other mitigations. Also, this technique should > work against spectre as well as meltdown (assuming the rationale holds). > > The second downside is that you have to modify code for this to work, > and you have to be careful not to keep copies of sensitive information > around too long (this gets tricky in userland, where you might get > interrupted and switched out). > > > [0]: Full disclosure, enabling open hardware implementations of this > kind of thing is something of an agenda of mine. > > == Rationale == > > (Again, I'm tired, rushed, and somewhat panicked so my logic could be > faulty at any point, so please point it out if it is) > > The rationale for why this should work relies on assumptions about > out-of-order pipelines that cannot be guaranteed to hold, but are > extremely likely to be true. > > As background, these attacks depend on out-of-order execution performing > operations that end up affecting cache and branch-prediction state, > ultimately storing information about sensitive data in these > side-channels before the fault conditions are detected and acted upon. > I'll borrow terminology from the paper, using "transient instructions" > to refer to speculatively executed instructions that will eventually be > cancelled by a fault. > > These attacks depend entirely on transient instructions being able to > get sensitive information into the processor core and then perform some > kind of instruction on them before the fault condition cancels them. > Therefore, anything that prevents them from doing this *should* counter > the attack. If the actual sensitive data never makes it to the core > before the fault is detected, the dependent memory accesses/branches > never get executed and the data never makes it to the side-channels. > > Another assumption here is that CPU architects are going to want to > squash faulted instructions ASAP and stop issuing along those > speculative branches, so as to reclaim execution units. So I'm assuming > once a fault comes back from address translation, then transient > execution stops dead. > > Now, break down the cases for whether the address containing sensitive > data is in cache and TLB or not. (I'm assuming here that caches are > virtually-indexed, which enables cache lookups to bypass address > translation.) > > * In cache, in TLB: You end up basically racing between the cache and > TLB, which will very likely end up detecting the fault before the data > arrives, but at the very worst, you get one or two cycles of transient > instruction execution before the fault. > > * In cache, not in TLB: Virtually-indexed tagged means you get a cache > lookup racing a page-table walk. The cache lookup beats the page table > walk by potentially hundreds (maybe thousands) of cycles, giving you a > bunch of transient instructions before a fault gets triggered. This is > the main attack case. > > * Not in cache, in TLB: Memory access requires address translation, > which comes back almost immediately as a fault. > > * Not in cache, not in TLB: You have to do a page table walk before you > can fetch the location, as you have to go out to physical memory (and > therefore need a physical address). The page table walk will come back > with a fault, stopping the attack. > > So, unless I'm missing something here, both non-cached cases defeat the > meltdown attack, as you *cannot* get the data unless you do address > translation first (and therefore detect faults). > > As for why this defeats the spectre attack, the logic is similar: you've > jumped into someone else's executable code, hoping to scoop up enough > information into your branch predictor before the fault kicks you out. > However, to capture anything about sensitive information in your > side-channels, the transient instructions need to actually get it into > the core before a fault gets detected. The same case analysis as above > applies, so you never actually get the sensitive info into the core > before a fault comes back and you get squashed. > > > [1]: A physically-indexed cache would be largely immune to this attack, > as you'd have to do address translation before doing a cache lookup. > > > I have some ideas that can build on this, but I'd like to get some > feedback first. > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Fri Jan 5 21:01:59 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04A41EC07A4; Fri, 5 Jan 2018 21:01:59 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9B2C7E572; Fri, 5 Jan 2018 21:01:58 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id m11so5617286iti.1; Fri, 05 Jan 2018 13:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XgGGWIXJEyUixN2cD60ywZtybr4KTK3Y8243ZQ53278=; b=TnQt2LdirHwWS48ve8NiXhPwBgme9ZxKaV8Z2csqjCA1S0kQLQf3B11nwa9oNsMlFX M/xCknHXQzVVO+h09ZJazmiNsvS8EqenX9vPgHnjY/zMFeda54dVXTg4ljzjlJqeWGqk j9FnOkxaCgtZRAU35CUODWdzVm+t4pyVFekp2mnkPB2Y7lo53g1g9yyXexjrYdsy+B3N Z9hcu2Itmrm/NHlGyVnqvwbbAarb1qoAW1wM3AREWjAQeNe50ty3ARGDzDGL07WvOjV+ MhMvBw0ux4i71Iv2Xur9J/ujNn44+gyO82JTw+nA2cj/j67rvA5tBtS+ErNdioC9oTXa Rc+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XgGGWIXJEyUixN2cD60ywZtybr4KTK3Y8243ZQ53278=; b=J7vTH+LsX0R6v3m4sUaCn2rsGY1BWcbxpWYuHIh7RU9Sux/VEOhOcRfmZ/eFq8y0gD MClD3gxGMrxq5A5gvjAQ2EhK3LQKGrK7dOm+EOGH9D9zHfuG2rEMajovM2vHt8nRHrsm +dZveW7xioMYGKREA7GB+ougut2G0jemIBuMABvA/Lq0aJFB0JvEs0A7Fz+OQjn2vcxf 5DPZ6oQErZZlJnl1IHn5EcsVTQDdws/Cq7hcsQK0hwgANfKZb62YbDycPhgabMptCEUu Z0EzdH3xkROzSYrf3+Pr0E8DZq1wreokZbY8BUlX8EL4SxuycBLDNDHOUxl1lqhO+E4f kzXw== X-Gm-Message-State: AKGB3mJyNfRh4UqwzZY2c0lld2X/x/iPSVD9HQGqzprTHssEVFz8J5Ja aqeSY96BSTHCCObVmrAavS8tKcStDHGHeYlw0lRxww== X-Google-Smtp-Source: ACJfBov5EyZIUpx+1q3qOpBJGKLLD3n4O2v6Y8BjJMVCJ5kRxNgEukReHCxElPjxPClWUwCA9KTdiwWbeGxA0f8/Ek8= X-Received: by 10.36.138.134 with SMTP id v128mr4604359itd.153.1515186117757; Fri, 05 Jan 2018 13:01:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.180.34 with HTTP; Fri, 5 Jan 2018 13:01:57 -0800 (PST) In-Reply-To: References: <20180105191145.404BC335@spqr.komquats.com> From: Adam Vande More Date: Fri, 5 Jan 2018 15:01:57 -0600 Message-ID: Subject: Re: Intel hardware bug To: "K. Macy" Cc: Cy Schubert , Eric McCorkle , FreeBSD Hackers , "freebsd-arch@freebsd.org" , Shawn Webb , Freebsd Security , Poul-Henning Kamp , Nathan Whitehorn , "Ronald F. Guilmette" , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Brett Glass , Jules Gilbert X-Mailman-Approved-At: Fri, 05 Jan 2018 22:14:41 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 21:01:59 -0000 On Fri, Jan 5, 2018 at 1:37 PM, K. Macy wrote: > On Fri, Jan 5, 2018 at 11:11 AM, Cy Schubert > wrote: > > According to a Red Hat announcement, Power and Series z are also > vulnerable. > > > > Link? > https://access.redhat.com/security/vulnerabilities/speculativeexecution -- Adam From owner-freebsd-arch@freebsd.org Fri Jan 5 22:15:30 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91986EC4059; Fri, 5 Jan 2018 22:15:30 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 48089190F; Fri, 5 Jan 2018 22:15:30 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-166-171-187-244.mycingular.net [166.171.187.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 01C848A55; Fri, 5 Jan 2018 22:15:27 +0000 (UTC) Subject: Re: A more general possible meltdown/spectre countermeasure To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> From: Eric McCorkle Message-ID: <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> Date: Fri, 5 Jan 2018 17:15:26 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:15:30 -0000 Right, but you have to get the value "foo" into the pipeline in order for it to affect the side-channels. This technique attempts to stop that from happening. Unless I made a mistake, non-cached memory reads force address translation to happen first, which detects faults and blocks the meltdown attack. It also stops spectre with very high probability, as it's very unlikely that an uncached load will arrive before the speculative thread gets squashed. On 01/05/2018 17:10, Warner Losh wrote: > I think this is fatally flawed. > > The side channel is the cache. Not the data at risk. > > Any mapped memory, cached or not, can be used to influence the cache. > Storing stuff in uncached memory won't affect the side channel one bit. > > Basically, all attacks boil down to tricking the processor, at elevated > privs, to doing something like > > a = foo[offset]; > > where foo + offset are designed to communicate information by populating > a cache line. offset need not be cached itself and can be the result of > simple computations that depend on anything accessible at all in the kernel. > > Warner > > On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle > wrote: > > Re-posting to -hackers and -arch.  I'm going to start working on > something like this over the weekend. > > -------- Forwarded Message -------- > Subject: A more general possible meltdown/spectre countermeasure > Date: Thu, 4 Jan 2018 23:05:40 -0500 > From: Eric McCorkle > > To: freebsd-security@freebsd.org > > > > I've thought more about how to deal with meltdown/spectre, and I have an > idea I'd like to put forward.  However, I'm still in something of a > panic mode, so I'm not certain as to its effectiveness.  Needless to > say, I welcome any feedback on this, and I may be completely off-base. > > I'm calling this a "countermeasure" as opposed to a "mitigation", as > it's something that requires modification of code as opposed to a > drop-in patch. > > == Summary == > > Provide a kernel and userland API by which memory allocation can be done > with extended attributes.  In userland, this could be accomplished by > extending MMAP flags, and I could imagine a malloc-with-attributes flag. >  In kernel space, this must already exist, as drivers need to allocate > memory with various MTRR-type attributes set. > > The immediate aim here is to store sensitive information that must > remain memory-resident in non-cacheable memory locations (or, if more > effective attribute combinations exist, using those instead).  See the > rationale for the argument why this should work. > > Assuming the rationale holds, then the attack surface should be greatly > reduced.  Attackers would need to grab sensitive data out of stack > frames or similar locations if/when it gets copied there for faster use. >  Moreover, if this is done right, it could dovetail nicely into a > framework for storing and processing sensitive assets in more secure > hardware[0] (like smart cards, the FPGAs I posted earlier, or other > options). > > The obvious downside is that you take a performance hit storing things > in non-cacheable locations, especially if you plan on doing heavy > computation in that memory (say, encryption/decryption).  However, this > is almost certainly going to be less than the projected 30-50% > performance hit from other mitigations.  Also, this technique should > work against spectre as well as meltdown (assuming the rationale holds). > > The second downside is that you have to modify code for this to work, > and you have to be careful not to keep copies of sensitive information > around too long (this gets tricky in userland, where you might get > interrupted and switched out). > > > [0]: Full disclosure, enabling open hardware implementations of this > kind of thing is something of an agenda of mine. > > == Rationale == > > (Again, I'm tired, rushed, and somewhat panicked so my logic could be > faulty at any point, so please point it out if it is) > > The rationale for why this should work relies on assumptions about > out-of-order pipelines that cannot be guaranteed to hold, but are > extremely likely to be true. > > As background, these attacks depend on out-of-order execution performing > operations that end up affecting cache and branch-prediction state, > ultimately storing information about sensitive data in these > side-channels before the fault conditions are detected and acted upon. > I'll borrow terminology from the paper, using "transient instructions" > to refer to speculatively executed instructions that will eventually be > cancelled by a fault. > > These attacks depend entirely on transient instructions being able to > get sensitive information into the processor core and then perform some > kind of instruction on them before the fault condition cancels them. > Therefore, anything that prevents them from doing this *should* counter > the attack.  If the actual sensitive data never makes it to the core > before the fault is detected, the dependent memory accesses/branches > never get executed and the data never makes it to the side-channels. > > Another assumption here is that CPU architects are going to want to > squash faulted instructions ASAP and stop issuing along those > speculative branches, so as to reclaim execution units.  So I'm assuming > once a fault comes back from address translation, then transient > execution stops dead. > > Now, break down the cases for whether the address containing sensitive > data is in cache and TLB or not.  (I'm assuming here that caches are > virtually-indexed, which enables cache lookups to bypass address > translation.) > > * In cache, in TLB: You end up basically racing between the cache and > TLB, which will very likely end up detecting the fault before the data > arrives, but at the very worst, you get one or two cycles of transient > instruction execution before the fault. > > * In cache, not in TLB: Virtually-indexed tagged means you get a cache > lookup racing a page-table walk.  The cache lookup beats the page table > walk by potentially hundreds (maybe thousands) of cycles, giving you a > bunch of transient instructions before a fault gets triggered.  This is > the main attack case. > > * Not in cache, in TLB: Memory access requires address translation, > which comes back almost immediately as a fault. > > * Not in cache, not in TLB: You have to do a page table walk before you > can fetch the location, as you have to go out to physical memory (and > therefore need a physical address).  The page table walk will come back > with a fault, stopping the attack. > > So, unless I'm missing something here, both non-cached cases defeat the > meltdown attack, as you *cannot* get the data unless you do address > translation first (and therefore detect faults). > > As for why this defeats the spectre attack, the logic is similar: you've > jumped into someone else's executable code, hoping to scoop up enough > information into your branch predictor before the fault kicks you out. > However, to capture anything about sensitive information in your > side-channels, the transient instructions need to actually get it into > the core before a fault gets detected.  The same case analysis as above > applies, so you never actually get the sensitive info into the core > before a fault comes back and you get squashed. > > > [1]: A physically-indexed cache would be largely immune to this attack, > as you'd have to do address translation before doing a cache lookup. > > > I have some ideas that can build on this, but I'd like to get some > feedback first. > _______________________________________________ > freebsd-security@freebsd.org > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org > " > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org > " > > From owner-freebsd-arch@freebsd.org Fri Jan 5 22:22:23 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F4E1EC4841 for ; Fri, 5 Jan 2018 22:22:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E45022D2 for ; Fri, 5 Jan 2018 22:22:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id q188so7250106iod.1 for ; Fri, 05 Jan 2018 14:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wvzaGdMzjJqu1Pqz+bsTMZ5lBVm4cRDLEetf2um4frc=; b=C4k+vKT4i1WxIG6rZL2Duj5jkuzy2agePNJKm+qDnsidA48B7MtvrDPNpL5EMwGUtN T5ClgGyQ6MrRf3/Jdzi8LiinrBs/bVVKbaYH3HJ9fOF1CdYFI5zO98qVgJ2hsSrbpAd2 YDlrdJkOkxpVHyAHxlyWeN2M7IgFRgn1O099DgOAnHoOLCHxzLCfMwk8cl8A0eJ3eA6v Tj+RTt6BT2yPXVOMqZ5lZpL6QgdmvZQbPW++hVxLgJmkEf5yfnjbmHNLdcjqgsqOVlG5 nyb5tSI6/kjCaPdL6FGhb5MhSjdR7MeF0fmg4Uwv0glie/Vb0ZHce5+0V2k8xdB4ipP+ Dszw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wvzaGdMzjJqu1Pqz+bsTMZ5lBVm4cRDLEetf2um4frc=; b=n56pD/hKRrJshgYAeEuoCPkqWhs9qokACuUasSMkSVVlD4zn0dsrqbWIoEcyg+npzO YrrjXd7AMQHDyTXgO4OgR91k2eRZvuV41z3w2+4hhaaPhBpuqFsVnQ6XOngEzCQk8Ot8 6ch9iaYQyewsRXFGXnKEmovjUcZZ94Mu2Da/zS22HHln3BkV1frYZxjDSqBT1054H7s1 lZS+u7Lg3M4eBrbVji3hPYvgMF++N8duk7Uz7Syp3Vb/2kRu8JNz19n75oIXUwcTmhTO +fBoyp3QUnfS5UcyanYnkbqwVkvcwgcWcOdTa8fynwf3vC326W9acvTM69crPqUGZr3l 5qhw== X-Gm-Message-State: AKwxytfMFn+vae8vHPyR2jEq3Pe9e+NiGD5duRNlGObDDi+UiuijjKMU 4eoknYn/bt0bsn98n1WYoXS3v9MEMoM17KGIsARjeg== X-Google-Smtp-Source: ACJfBotWWLMZX6peHiF5E7bcio4qPyN8zHJt2SXwK+tH6TWCAjL9bEIDuJVn7Pyzvy4/dn0aD50I6TzXFT4sqp911qg= X-Received: by 10.107.78.12 with SMTP id c12mr4387650iob.63.1515190942020; Fri, 05 Jan 2018 14:22:22 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Fri, 5 Jan 2018 14:22:21 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> From: Warner Losh Date: Fri, 5 Jan 2018 15:22:21 -0700 X-Google-Sender-Auth: InOhVvYEc7Gg0JlflKXzLo25Ivg Message-ID: Subject: Re: A more general possible meltdown/spectre countermeasure To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:22:23 -0000 While you might be right, I've seen no indication that a cache miss would defeat these attacks in the public and non-public data I've looked at, even though a large number of alternatives to the published workarounds have been discussed. I'm therefore somewhat skeptical this would be effective. I'm open, however, to data that changes that skepticism... Warner On Fri, Jan 5, 2018 at 3:15 PM, Eric McCorkle wrote: > Right, but you have to get the value "foo" into the pipeline in order > for it to affect the side-channels. This technique attempts to stop > that from happening. > > Unless I made a mistake, non-cached memory reads force address > translation to happen first, which detects faults and blocks the > meltdown attack. > > It also stops spectre with very high probability, as it's very unlikely > that an uncached load will arrive before the speculative thread gets > squashed. > > On 01/05/2018 17:10, Warner Losh wrote: > > I think this is fatally flawed. > > > > The side channel is the cache. Not the data at risk. > > > > Any mapped memory, cached or not, can be used to influence the cache. > > Storing stuff in uncached memory won't affect the side channel one bit. > > > > Basically, all attacks boil down to tricking the processor, at elevated > > privs, to doing something like > > > > a = foo[offset]; > > > > where foo + offset are designed to communicate information by populating > > a cache line. offset need not be cached itself and can be the result of > > simple computations that depend on anything accessible at all in the > kernel. > > > > Warner > > > > On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle > > wrote: > > > > Re-posting to -hackers and -arch. I'm going to start working on > > something like this over the weekend. > > > > -------- Forwarded Message -------- > > Subject: A more general possible meltdown/spectre countermeasure > > Date: Thu, 4 Jan 2018 23:05:40 -0500 > > From: Eric McCorkle eric@metricspace.net>> > > To: freebsd-security@freebsd.org > > > > > > > > I've thought more about how to deal with meltdown/spectre, and I > have an > > idea I'd like to put forward. However, I'm still in something of a > > panic mode, so I'm not certain as to its effectiveness. Needless to > > say, I welcome any feedback on this, and I may be completely > off-base. > > > > I'm calling this a "countermeasure" as opposed to a "mitigation", as > > it's something that requires modification of code as opposed to a > > drop-in patch. > > > > == Summary == > > > > Provide a kernel and userland API by which memory allocation can be > done > > with extended attributes. In userland, this could be accomplished by > > extending MMAP flags, and I could imagine a malloc-with-attributes > flag. > > In kernel space, this must already exist, as drivers need to > allocate > > memory with various MTRR-type attributes set. > > > > The immediate aim here is to store sensitive information that must > > remain memory-resident in non-cacheable memory locations (or, if more > > effective attribute combinations exist, using those instead). See > the > > rationale for the argument why this should work. > > > > Assuming the rationale holds, then the attack surface should be > greatly > > reduced. Attackers would need to grab sensitive data out of stack > > frames or similar locations if/when it gets copied there for faster > use. > > Moreover, if this is done right, it could dovetail nicely into a > > framework for storing and processing sensitive assets in more secure > > hardware[0] (like smart cards, the FPGAs I posted earlier, or other > > options). > > > > The obvious downside is that you take a performance hit storing > things > > in non-cacheable locations, especially if you plan on doing heavy > > computation in that memory (say, encryption/decryption). However, > this > > is almost certainly going to be less than the projected 30-50% > > performance hit from other mitigations. Also, this technique should > > work against spectre as well as meltdown (assuming the rationale > holds). > > > > The second downside is that you have to modify code for this to work, > > and you have to be careful not to keep copies of sensitive > information > > around too long (this gets tricky in userland, where you might get > > interrupted and switched out). > > > > > > [0]: Full disclosure, enabling open hardware implementations of this > > kind of thing is something of an agenda of mine. > > > > == Rationale == > > > > (Again, I'm tired, rushed, and somewhat panicked so my logic could be > > faulty at any point, so please point it out if it is) > > > > The rationale for why this should work relies on assumptions about > > out-of-order pipelines that cannot be guaranteed to hold, but are > > extremely likely to be true. > > > > As background, these attacks depend on out-of-order execution > performing > > operations that end up affecting cache and branch-prediction state, > > ultimately storing information about sensitive data in these > > side-channels before the fault conditions are detected and acted > upon. > > I'll borrow terminology from the paper, using "transient > instructions" > > to refer to speculatively executed instructions that will eventually > be > > cancelled by a fault. > > > > These attacks depend entirely on transient instructions being able to > > get sensitive information into the processor core and then perform > some > > kind of instruction on them before the fault condition cancels them. > > Therefore, anything that prevents them from doing this *should* > counter > > the attack. If the actual sensitive data never makes it to the core > > before the fault is detected, the dependent memory accesses/branches > > never get executed and the data never makes it to the side-channels. > > > > Another assumption here is that CPU architects are going to want to > > squash faulted instructions ASAP and stop issuing along those > > speculative branches, so as to reclaim execution units. So I'm > assuming > > once a fault comes back from address translation, then transient > > execution stops dead. > > > > Now, break down the cases for whether the address containing > sensitive > > data is in cache and TLB or not. (I'm assuming here that caches are > > virtually-indexed, which enables cache lookups to bypass address > > translation.) > > > > * In cache, in TLB: You end up basically racing between the cache and > > TLB, which will very likely end up detecting the fault before the > data > > arrives, but at the very worst, you get one or two cycles of > transient > > instruction execution before the fault. > > > > * In cache, not in TLB: Virtually-indexed tagged means you get a > cache > > lookup racing a page-table walk. The cache lookup beats the page > table > > walk by potentially hundreds (maybe thousands) of cycles, giving you > a > > bunch of transient instructions before a fault gets triggered. This > is > > the main attack case. > > > > * Not in cache, in TLB: Memory access requires address translation, > > which comes back almost immediately as a fault. > > > > * Not in cache, not in TLB: You have to do a page table walk before > you > > can fetch the location, as you have to go out to physical memory (and > > therefore need a physical address). The page table walk will come > back > > with a fault, stopping the attack. > > > > So, unless I'm missing something here, both non-cached cases defeat > the > > meltdown attack, as you *cannot* get the data unless you do address > > translation first (and therefore detect faults). > > > > As for why this defeats the spectre attack, the logic is similar: > you've > > jumped into someone else's executable code, hoping to scoop up enough > > information into your branch predictor before the fault kicks you > out. > > However, to capture anything about sensitive information in your > > side-channels, the transient instructions need to actually get it > into > > the core before a fault gets detected. The same case analysis as > above > > applies, so you never actually get the sensitive info into the core > > before a fault comes back and you get squashed. > > > > > > [1]: A physically-indexed cache would be largely immune to this > attack, > > as you'd have to do address translation before doing a cache lookup. > > > > > > I have some ideas that can build on this, but I'd like to get some > > feedback first. > > _______________________________________________ > > freebsd-security@freebsd.org > > mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-security > > > > To unsubscribe, send any mail to > > "freebsd-security-unsubscribe@freebsd.org > > " > > _______________________________________________ > > freebsd-arch@freebsd.org mailing > list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > > > To unsubscribe, send any mail to > > "freebsd-arch-unsubscribe@freebsd.org > > " > > > > > From owner-freebsd-arch@freebsd.org Fri Jan 5 22:31:57 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1DC8EC5317; Fri, 5 Jan 2018 22:31:57 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF82304D; Fri, 5 Jan 2018 22:31:57 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-166-171-187-244.mycingular.net [166.171.187.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B616E8A89; Fri, 5 Jan 2018 22:31:55 +0000 (UTC) Subject: Re: A more general possible meltdown/spectre countermeasure To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> From: Eric McCorkle Message-ID: <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> Date: Fri, 5 Jan 2018 17:31:54 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:31:57 -0000 Well, the only way to find out would be to try it out. However, unless I'm missing something, if you're trying to pull a meltdown attack, you try and fetch from the kernel. If that location isn't cached (or if your cache is physically indexed), you need the physical address (otherwise you don't know where to look), and thus have to go through address translation, at which point you detect that the page isn't accessible and fault. In the mean time, you can't speculatively execute any of the operations that load up the side-channels, because you don't have the sensitive data. The reason you can pull off a meltdown attack at all is that a virtually-indexed cache lets you get the data in parallel with address translation (breaking the dependency between address translation and fetching data), which takes 1000s of cycles for a TLB miss, during which you have the data and can launch a whole bunch of transient ops. Again, these are uncharted waters we're in; so it's entirely possible I'm missing something here. On 01/05/2018 17:22, Warner Losh wrote: > While you might be right, I've seen no indication that a cache miss > would defeat these attacks in the public and non-public data I've looked > at, even though a large number of alternatives to the published > workarounds have been discussed. I'm therefore somewhat skeptical this > would be effective. I'm open, however, to data that changes that > skepticism... > > Warner > > On Fri, Jan 5, 2018 at 3:15 PM, Eric McCorkle > wrote: > > Right, but you have to get the value "foo" into the pipeline in order > for it to affect the side-channels.  This technique attempts to stop > that from happening. > > Unless I made a mistake, non-cached memory reads force address > translation to happen first, which detects faults and blocks the > meltdown attack. > > It also stops spectre with very high probability, as it's very unlikely > that an uncached load will arrive before the speculative thread gets > squashed. > > On 01/05/2018 17:10, Warner Losh wrote: > > I think this is fatally flawed. > > > > The side channel is the cache. Not the data at risk. > > > > Any mapped memory, cached or not, can be used to influence the cache. > > Storing stuff in uncached memory won't affect the side channel one bit. > > > > Basically, all attacks boil down to tricking the processor, at elevated > > privs, to doing something like > > > > a = foo[offset]; > > > > where foo + offset are designed to communicate information by populating > > a cache line. offset need not be cached itself and can be the result of > > simple computations that depend on anything accessible at all in the kernel. > > > > Warner > > > > On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle > > >> wrote: > > > >     Re-posting to -hackers and -arch.  I'm going to start working on > >     something like this over the weekend. > > > >     -------- Forwarded Message -------- > >     Subject: A more general possible meltdown/spectre countermeasure > >     Date: Thu, 4 Jan 2018 23:05:40 -0500 > >     From: Eric McCorkle >> > >     To: freebsd-security@freebsd.org > > >      > > >      >> > > > >     I've thought more about how to deal with meltdown/spectre, and > I have an > >     idea I'd like to put forward.  However, I'm still in something > of a > >     panic mode, so I'm not certain as to its effectiveness.  > Needless to > >     say, I welcome any feedback on this, and I may be completely > off-base. > > > >     I'm calling this a "countermeasure" as opposed to a > "mitigation", as > >     it's something that requires modification of code as opposed to a > >     drop-in patch. > > > >     == Summary == > > > >     Provide a kernel and userland API by which memory allocation > can be done > >     with extended attributes.  In userland, this could be > accomplished by > >     extending MMAP flags, and I could imagine a > malloc-with-attributes flag. > >      In kernel space, this must already exist, as drivers need to > allocate > >     memory with various MTRR-type attributes set. > > > >     The immediate aim here is to store sensitive information that must > >     remain memory-resident in non-cacheable memory locations (or, > if more > >     effective attribute combinations exist, using those instead).  > See the > >     rationale for the argument why this should work. > > > >     Assuming the rationale holds, then the attack surface should > be greatly > >     reduced.  Attackers would need to grab sensitive data out of stack > >     frames or similar locations if/when it gets copied there for > faster use. > >      Moreover, if this is done right, it could dovetail nicely into a > >     framework for storing and processing sensitive assets in more > secure > >     hardware[0] (like smart cards, the FPGAs I posted earlier, or > other > >     options). > > > >     The obvious downside is that you take a performance hit > storing things > >     in non-cacheable locations, especially if you plan on doing heavy > >     computation in that memory (say, encryption/decryption).  > However, this > >     is almost certainly going to be less than the projected 30-50% > >     performance hit from other mitigations.  Also, this technique > should > >     work against spectre as well as meltdown (assuming the > rationale holds). > > > >     The second downside is that you have to modify code for this > to work, > >     and you have to be careful not to keep copies of sensitive > information > >     around too long (this gets tricky in userland, where you might get > >     interrupted and switched out). > > > > > >     [0]: Full disclosure, enabling open hardware implementations > of this > >     kind of thing is something of an agenda of mine. > > > >     == Rationale == > > > >     (Again, I'm tired, rushed, and somewhat panicked so my logic > could be > >     faulty at any point, so please point it out if it is) > > > >     The rationale for why this should work relies on assumptions about > >     out-of-order pipelines that cannot be guaranteed to hold, but are > >     extremely likely to be true. > > > >     As background, these attacks depend on out-of-order execution > performing > >     operations that end up affecting cache and branch-prediction > state, > >     ultimately storing information about sensitive data in these > >     side-channels before the fault conditions are detected and > acted upon. > >     I'll borrow terminology from the paper, using "transient > instructions" > >     to refer to speculatively executed instructions that will > eventually be > >     cancelled by a fault. > > > >     These attacks depend entirely on transient instructions being > able to > >     get sensitive information into the processor core and then > perform some > >     kind of instruction on them before the fault condition cancels > them. > >     Therefore, anything that prevents them from doing this > *should* counter > >     the attack.  If the actual sensitive data never makes it to > the core > >     before the fault is detected, the dependent memory > accesses/branches > >     never get executed and the data never makes it to the > side-channels. > > > >     Another assumption here is that CPU architects are going to > want to > >     squash faulted instructions ASAP and stop issuing along those > >     speculative branches, so as to reclaim execution units.  So > I'm assuming > >     once a fault comes back from address translation, then transient > >     execution stops dead. > > > >     Now, break down the cases for whether the address containing > sensitive > >     data is in cache and TLB or not.  (I'm assuming here that > caches are > >     virtually-indexed, which enables cache lookups to bypass address > >     translation.) > > > >     * In cache, in TLB: You end up basically racing between the > cache and > >     TLB, which will very likely end up detecting the fault before > the data > >     arrives, but at the very worst, you get one or two cycles of > transient > >     instruction execution before the fault. > > > >     * In cache, not in TLB: Virtually-indexed tagged means you get > a cache > >     lookup racing a page-table walk.  The cache lookup beats the > page table > >     walk by potentially hundreds (maybe thousands) of cycles, > giving you a > >     bunch of transient instructions before a fault gets > triggered.  This is > >     the main attack case. > > > >     * Not in cache, in TLB: Memory access requires address > translation, > >     which comes back almost immediately as a fault. > > > >     * Not in cache, not in TLB: You have to do a page table walk > before you > >     can fetch the location, as you have to go out to physical > memory (and > >     therefore need a physical address).  The page table walk will > come back > >     with a fault, stopping the attack. > > > >     So, unless I'm missing something here, both non-cached cases > defeat the > >     meltdown attack, as you *cannot* get the data unless you do > address > >     translation first (and therefore detect faults). > > > >     As for why this defeats the spectre attack, the logic is > similar: you've > >     jumped into someone else's executable code, hoping to scoop up > enough > >     information into your branch predictor before the fault kicks > you out. > >     However, to capture anything about sensitive information in your > >     side-channels, the transient instructions need to actually get > it into > >     the core before a fault gets detected.  The same case analysis > as above > >     applies, so you never actually get the sensitive info into the > core > >     before a fault comes back and you get squashed. > > > > > >     [1]: A physically-indexed cache would be largely immune to > this attack, > >     as you'd have to do address translation before doing a cache > lookup. > > > > > >     I have some ideas that can build on this, but I'd like to get some > >     feedback first. > >     _______________________________________________ > >     freebsd-security@freebsd.org > > > > >     mailing list > >     https://lists.freebsd.org/mailman/listinfo/freebsd-security > > >      > > >     To unsubscribe, send any mail to > >     "freebsd-security-unsubscribe@freebsd.org > > >      >" > >     _______________________________________________ > >     freebsd-arch@freebsd.org > > > mailing list > >     https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > >      > > >     To unsubscribe, send any mail to > >     "freebsd-arch-unsubscribe@freebsd.org > > >      >" > > > > > > From owner-freebsd-arch@freebsd.org Fri Jan 5 23:08:21 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EF34EA5624 for ; Fri, 5 Jan 2018 23:08:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D01F643CF for ; Fri, 5 Jan 2018 23:08:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id p139so3265911itb.1 for ; Fri, 05 Jan 2018 15:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7xFTD5DLONb1wsY6ElzO43YqgPVZ7fUSBkUxbNwkFNE=; b=QjKqaUaJ0zF+B7Wmafw+NafpFGz/hPPIqv91FEzr/s0ZWjWobuHTa/eYlaEZuD1YAZ Wx+0CzYEOxs1UslzEkv4nQMYW/0I0j15dqgET221coqG2hpfNGekBXOzFhG/HoqHqebN eNLIDlmrZa8Jq0ziGib5+dj6J7pnOIy3oE9QH0dkXDqEHVOebIlhleIsWPpNCMmb9mpu tJEpMjCGtQJvQGSVY9lkQPnwyAuywCCnKuXJaSavaWmpQOWbpSWQhUBWZmbYkVUaSyfH BLE6Ba1ymj5Fb45qaPtLBd1M4MAsVbnv6B0lsz1fPYsvwV1rl69sdEyw7I4yBSv+Ex+k W73A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7xFTD5DLONb1wsY6ElzO43YqgPVZ7fUSBkUxbNwkFNE=; b=pQHoGsBVz3VLmJ9jPiplu0TNWuqXlhNZSLJ9vP4r95o0j3Kp7hQubPlMUy4wi13BG3 mtZqfGHhkkyMxaZgwg48J+vZsfOIpY5RVq2Tu17+/L97+t2GXkj3xCqw5M8HArWHowO4 95iFYfqwsxgSdMS4gFx9resg2UowBHQ8/q0j7mQhhsvrw8kV+4IXAXXSoaqUurIZTINq CG8zWUN/cznjUDbNh/G34bwdhbW/SosvH8ea74E5i8j+6vY5Gqj7Nt76EwR9ML/akxqo OK8H4Wu7BOQhMtMvmo2F+MaqSmLIkYuxLQvN7ffI5Dm2UScBgLZv9vIIt0OSR0Ikkxkq Wv3g== X-Gm-Message-State: AKGB3mLKn3hPHIDOMLy0BaYx2jx48AlJJGiDeCy7xVNvVBXV5+RIovws rJdHesAOly5eu+0ZmDPe/mVFspL4AnBkZvPyy6q7wA== X-Google-Smtp-Source: ACJfBosDmT/gqelm6+SREn2hv4byfPTI8OYeqUjMDdp8DaHGMPAm0pqFR3cqm1hkaD54Iio+Z5ApgNJK9m15k2JASu4= X-Received: by 10.36.131.8 with SMTP id d8mr4806255ite.115.1515193700441; Fri, 05 Jan 2018 15:08:20 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Fri, 5 Jan 2018 15:08:19 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> From: Warner Losh Date: Fri, 5 Jan 2018 16:08:19 -0700 X-Google-Sender-Auth: ipJBatNBLHw8pt4DKZfnbJTfRIA Message-ID: Subject: Re: A more general possible meltdown/spectre countermeasure To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 23:08:21 -0000 Wouldn't you have to also unmap it from the direct map for this to be effective? Warner On Fri, Jan 5, 2018 at 3:31 PM, Eric McCorkle wrote: > Well, the only way to find out would be to try it out. > > However, unless I'm missing something, if you're trying to pull a > meltdown attack, you try and fetch from the kernel. If that location > isn't cached (or if your cache is physically indexed), you need the > physical address (otherwise you don't know where to look), and thus have > to go through address translation, at which point you detect that the > page isn't accessible and fault. In the mean time, you can't > speculatively execute any of the operations that load up the > side-channels, because you don't have the sensitive data. > > The reason you can pull off a meltdown attack at all is that a > virtually-indexed cache lets you get the data in parallel with address > translation (breaking the dependency between address translation and > fetching data), which takes 1000s of cycles for a TLB miss, during which > you have the data and can launch a whole bunch of transient ops. > > Again, these are uncharted waters we're in; so it's entirely possible > I'm missing something here. > > On 01/05/2018 17:22, Warner Losh wrote: > > While you might be right, I've seen no indication that a cache miss > > would defeat these attacks in the public and non-public data I've looked > > at, even though a large number of alternatives to the published > > workarounds have been discussed. I'm therefore somewhat skeptical this > > would be effective. I'm open, however, to data that changes that > > skepticism... > > > > Warner > > > > On Fri, Jan 5, 2018 at 3:15 PM, Eric McCorkle > > wrote: > > > > Right, but you have to get the value "foo" into the pipeline in order > > for it to affect the side-channels. This technique attempts to stop > > that from happening. > > > > Unless I made a mistake, non-cached memory reads force address > > translation to happen first, which detects faults and blocks the > > meltdown attack. > > > > It also stops spectre with very high probability, as it's very > unlikely > > that an uncached load will arrive before the speculative thread gets > > squashed. > > > > On 01/05/2018 17:10, Warner Losh wrote: > > > I think this is fatally flawed. > > > > > > The side channel is the cache. Not the data at risk. > > > > > > Any mapped memory, cached or not, can be used to influence the > cache. > > > Storing stuff in uncached memory won't affect the side channel one > bit. > > > > > > Basically, all attacks boil down to tricking the processor, at > elevated > > > privs, to doing something like > > > > > > a = foo[offset]; > > > > > > where foo + offset are designed to communicate information by > populating > > > a cache line. offset need not be cached itself and can be the > result of > > > simple computations that depend on anything accessible at all in > the kernel. > > > > > > Warner > > > > > > On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle < > eric@metricspace.net > > > >> > wrote: > > > > > > Re-posting to -hackers and -arch. I'm going to start working > on > > > something like this over the weekend. > > > > > > -------- Forwarded Message -------- > > > Subject: A more general possible meltdown/spectre > countermeasure > > > Date: Thu, 4 Jan 2018 23:05:40 -0500 > > > From: Eric McCorkle > > >> > > > To: freebsd-security@freebsd.org > > > > > > > > > > > > >> > > > > > > I've thought more about how to deal with meltdown/spectre, and > > I have an > > > idea I'd like to put forward. However, I'm still in something > > of a > > > panic mode, so I'm not certain as to its effectiveness. > > Needless to > > > say, I welcome any feedback on this, and I may be completely > > off-base. > > > > > > I'm calling this a "countermeasure" as opposed to a > > "mitigation", as > > > it's something that requires modification of code as opposed > to a > > > drop-in patch. > > > > > > == Summary == > > > > > > Provide a kernel and userland API by which memory allocation > > can be done > > > with extended attributes. In userland, this could be > > accomplished by > > > extending MMAP flags, and I could imagine a > > malloc-with-attributes flag. > > > In kernel space, this must already exist, as drivers need to > > allocate > > > memory with various MTRR-type attributes set. > > > > > > The immediate aim here is to store sensitive information that > must > > > remain memory-resident in non-cacheable memory locations (or, > > if more > > > effective attribute combinations exist, using those instead). > > See the > > > rationale for the argument why this should work. > > > > > > Assuming the rationale holds, then the attack surface should > > be greatly > > > reduced. Attackers would need to grab sensitive data out of > stack > > > frames or similar locations if/when it gets copied there for > > faster use. > > > Moreover, if this is done right, it could dovetail nicely > into a > > > framework for storing and processing sensitive assets in more > > secure > > > hardware[0] (like smart cards, the FPGAs I posted earlier, or > > other > > > options). > > > > > > The obvious downside is that you take a performance hit > > storing things > > > in non-cacheable locations, especially if you plan on doing > heavy > > > computation in that memory (say, encryption/decryption). > > However, this > > > is almost certainly going to be less than the projected 30-50% > > > performance hit from other mitigations. Also, this technique > > should > > > work against spectre as well as meltdown (assuming the > > rationale holds). > > > > > > The second downside is that you have to modify code for this > > to work, > > > and you have to be careful not to keep copies of sensitive > > information > > > around too long (this gets tricky in userland, where you might > get > > > interrupted and switched out). > > > > > > > > > [0]: Full disclosure, enabling open hardware implementations > > of this > > > kind of thing is something of an agenda of mine. > > > > > > == Rationale == > > > > > > (Again, I'm tired, rushed, and somewhat panicked so my logic > > could be > > > faulty at any point, so please point it out if it is) > > > > > > The rationale for why this should work relies on assumptions > about > > > out-of-order pipelines that cannot be guaranteed to hold, but > are > > > extremely likely to be true. > > > > > > As background, these attacks depend on out-of-order execution > > performing > > > operations that end up affecting cache and branch-prediction > > state, > > > ultimately storing information about sensitive data in these > > > side-channels before the fault conditions are detected and > > acted upon. > > > I'll borrow terminology from the paper, using "transient > > instructions" > > > to refer to speculatively executed instructions that will > > eventually be > > > cancelled by a fault. > > > > > > These attacks depend entirely on transient instructions being > > able to > > > get sensitive information into the processor core and then > > perform some > > > kind of instruction on them before the fault condition cancels > > them. > > > Therefore, anything that prevents them from doing this > > *should* counter > > > the attack. If the actual sensitive data never makes it to > > the core > > > before the fault is detected, the dependent memory > > accesses/branches > > > never get executed and the data never makes it to the > > side-channels. > > > > > > Another assumption here is that CPU architects are going to > > want to > > > squash faulted instructions ASAP and stop issuing along those > > > speculative branches, so as to reclaim execution units. So > > I'm assuming > > > once a fault comes back from address translation, then > transient > > > execution stops dead. > > > > > > Now, break down the cases for whether the address containing > > sensitive > > > data is in cache and TLB or not. (I'm assuming here that > > caches are > > > virtually-indexed, which enables cache lookups to bypass > address > > > translation.) > > > > > > * In cache, in TLB: You end up basically racing between the > > cache and > > > TLB, which will very likely end up detecting the fault before > > the data > > > arrives, but at the very worst, you get one or two cycles of > > transient > > > instruction execution before the fault. > > > > > > * In cache, not in TLB: Virtually-indexed tagged means you get > > a cache > > > lookup racing a page-table walk. The cache lookup beats the > > page table > > > walk by potentially hundreds (maybe thousands) of cycles, > > giving you a > > > bunch of transient instructions before a fault gets > > triggered. This is > > > the main attack case. > > > > > > * Not in cache, in TLB: Memory access requires address > > translation, > > > which comes back almost immediately as a fault. > > > > > > * Not in cache, not in TLB: You have to do a page table walk > > before you > > > can fetch the location, as you have to go out to physical > > memory (and > > > therefore need a physical address). The page table walk will > > come back > > > with a fault, stopping the attack. > > > > > > So, unless I'm missing something here, both non-cached cases > > defeat the > > > meltdown attack, as you *cannot* get the data unless you do > > address > > > translation first (and therefore detect faults). > > > > > > As for why this defeats the spectre attack, the logic is > > similar: you've > > > jumped into someone else's executable code, hoping to scoop up > > enough > > > information into your branch predictor before the fault kicks > > you out. > > > However, to capture anything about sensitive information in > your > > > side-channels, the transient instructions need to actually get > > it into > > > the core before a fault gets detected. The same case analysis > > as above > > > applies, so you never actually get the sensitive info into the > > core > > > before a fault comes back and you get squashed. > > > > > > > > > [1]: A physically-indexed cache would be largely immune to > > this attack, > > > as you'd have to do address translation before doing a cache > > lookup. > > > > > > > > > I have some ideas that can build on this, but I'd like to get > some > > > feedback first. > > > _______________________________________________ > > > freebsd-security@freebsd.org > > > > > > > > > mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-security > > > > > > > > > > To unsubscribe, send any mail to > > > "freebsd-security-unsubscribe@freebsd.org > > > > > > >" > > > _______________________________________________ > > > freebsd-arch@freebsd.org > > > > > mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > > > > > > > > > To unsubscribe, send any mail to > > > "freebsd-arch-unsubscribe@freebsd.org > > > > > > >" > > > > > > > > > > > From owner-freebsd-arch@freebsd.org Fri Jan 5 23:10:56 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86E96EA5987; Fri, 5 Jan 2018 23:10:56 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8C064698; Fri, 5 Jan 2018 23:10:55 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-166-171-187-244.mycingular.net [166.171.187.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id F00C08AB6; Fri, 5 Jan 2018 23:10:54 +0000 (UTC) Subject: Re: A more general possible meltdown/spectre countermeasure To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> From: Eric McCorkle Message-ID: Date: Fri, 5 Jan 2018 18:10:53 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 23:10:56 -0000 I'm not sure what you mean by direct map. Do you mean TLB? On 01/05/2018 18:08, Warner Losh wrote: > Wouldn't you have to also unmap it from the direct map for this to be > effective? > > Warner > > > On Fri, Jan 5, 2018 at 3:31 PM, Eric McCorkle > wrote: > > Well, the only way to find out would be to try it out. > > However, unless I'm missing something, if you're trying to pull a > meltdown attack, you try and fetch from the kernel.  If that location > isn't cached (or if your cache is physically indexed), you need the > physical address (otherwise you don't know where to look), and thus have > to go through address translation, at which point you detect that the > page isn't accessible and fault.  In the mean time, you can't > speculatively execute any of the operations that load up the > side-channels, because you don't have the sensitive data. > > The reason you can pull off a meltdown attack at all is that a > virtually-indexed cache lets you get the data in parallel with address > translation (breaking the dependency between address translation and > fetching data), which takes 1000s of cycles for a TLB miss, during which > you have the data and can launch a whole bunch of transient ops. > > Again, these are uncharted waters we're in; so it's entirely possible > I'm missing something here. > > On 01/05/2018 17:22, Warner Losh wrote: > > While you might be right, I've seen no indication that a cache miss > > would defeat these attacks in the public and non-public data I've looked > > at, even though a large number of alternatives to the published > > workarounds have been discussed. I'm therefore somewhat skeptical this > > would be effective. I'm open, however, to data that changes that > > skepticism... > > > > Warner > > > > On Fri, Jan 5, 2018 at 3:15 PM, Eric McCorkle > > >> wrote: > > > >     Right, but you have to get the value "foo" into the pipeline in order > >     for it to affect the side-channels.  This technique attempts to stop > >     that from happening. > > > >     Unless I made a mistake, non-cached memory reads force address > >     translation to happen first, which detects faults and blocks the > >     meltdown attack. > > > >     It also stops spectre with very high probability, as it's very unlikely > >     that an uncached load will arrive before the speculative thread gets > >     squashed. > > > >     On 01/05/2018 17:10, Warner Losh wrote: > >     > I think this is fatally flawed. > >     > > >     > The side channel is the cache. Not the data at risk. > >     > > >     > Any mapped memory, cached or not, can be used to influence the cache. > >     > Storing stuff in uncached memory won't affect the side channel one bit. > >     > > >     > Basically, all attacks boil down to tricking the processor, at elevated > >     > privs, to doing something like > >     > > >     > a = foo[offset]; > >     > > >     > where foo + offset are designed to communicate information by populating > >     > a cache line. offset need not be cached itself and can be the result of > >     > simple computations that depend on anything accessible at all in the kernel. > >     > > >     > Warner > >     > > >     > On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle > > > >     > > >>> wrote: > >     > > >     >     Re-posting to -hackers and -arch.  I'm going to start working on > >     >     something like this over the weekend. > >     > > >     >     -------- Forwarded Message -------- > >     >     Subject: A more general possible meltdown/spectre countermeasure > >     >     Date: Thu, 4 Jan 2018 23:05:40 -0500 > >     >     From: Eric McCorkle > >     > > > >     >>> > >     >     To: freebsd-security@freebsd.org > >     > > >     >      > >     >> > > >     > > >     >      > >      >>> > >     > > >     >     I've thought more about how to deal with > meltdown/spectre, and > >     I have an > >     >     idea I'd like to put forward.  However, I'm still in > something > >     of a > >     >     panic mode, so I'm not certain as to its effectiveness.  > >     Needless to > >     >     say, I welcome any feedback on this, and I may be completely > >     off-base. > >     > > >     >     I'm calling this a "countermeasure" as opposed to a > >     "mitigation", as > >     >     it's something that requires modification of code as > opposed to a > >     >     drop-in patch. > >     > > >     >     == Summary == > >     > > >     >     Provide a kernel and userland API by which memory allocation > >     can be done > >     >     with extended attributes.  In userland, this could be > >     accomplished by > >     >     extending MMAP flags, and I could imagine a > >     malloc-with-attributes flag. > >     >      In kernel space, this must already exist, as drivers > need to > >     allocate > >     >     memory with various MTRR-type attributes set. > >     > > >     >     The immediate aim here is to store sensitive information > that must > >     >     remain memory-resident in non-cacheable memory locations > (or, > >     if more > >     >     effective attribute combinations exist, using those > instead).  > >     See the > >     >     rationale for the argument why this should work. > >     > > >     >     Assuming the rationale holds, then the attack surface should > >     be greatly > >     >     reduced.  Attackers would need to grab sensitive data > out of stack > >     >     frames or similar locations if/when it gets copied there for > >     faster use. > >     >      Moreover, if this is done right, it could dovetail > nicely into a > >     >     framework for storing and processing sensitive assets in > more > >     secure > >     >     hardware[0] (like smart cards, the FPGAs I posted > earlier, or > >     other > >     >     options). > >     > > >     >     The obvious downside is that you take a performance hit > >     storing things > >     >     in non-cacheable locations, especially if you plan on > doing heavy > >     >     computation in that memory (say, encryption/decryption).  > >     However, this > >     >     is almost certainly going to be less than the projected > 30-50% > >     >     performance hit from other mitigations.  Also, this > technique > >     should > >     >     work against spectre as well as meltdown (assuming the > >     rationale holds). > >     > > >     >     The second downside is that you have to modify code for this > >     to work, > >     >     and you have to be careful not to keep copies of sensitive > >     information > >     >     around too long (this gets tricky in userland, where you > might get > >     >     interrupted and switched out). > >     > > >     > > >     >     [0]: Full disclosure, enabling open hardware implementations > >     of this > >     >     kind of thing is something of an agenda of mine. > >     > > >     >     == Rationale == > >     > > >     >     (Again, I'm tired, rushed, and somewhat panicked so my logic > >     could be > >     >     faulty at any point, so please point it out if it is) > >     > > >     >     The rationale for why this should work relies on > assumptions about > >     >     out-of-order pipelines that cannot be guaranteed to > hold, but are > >     >     extremely likely to be true. > >     > > >     >     As background, these attacks depend on out-of-order > execution > >     performing > >     >     operations that end up affecting cache and branch-prediction > >     state, > >     >     ultimately storing information about sensitive data in these > >     >     side-channels before the fault conditions are detected and > >     acted upon. > >     >     I'll borrow terminology from the paper, using "transient > >     instructions" > >     >     to refer to speculatively executed instructions that will > >     eventually be > >     >     cancelled by a fault. > >     > > >     >     These attacks depend entirely on transient instructions > being > >     able to > >     >     get sensitive information into the processor core and then > >     perform some > >     >     kind of instruction on them before the fault condition > cancels > >     them. > >     >     Therefore, anything that prevents them from doing this > >     *should* counter > >     >     the attack.  If the actual sensitive data never makes it to > >     the core > >     >     before the fault is detected, the dependent memory > >     accesses/branches > >     >     never get executed and the data never makes it to the > >     side-channels. > >     > > >     >     Another assumption here is that CPU architects are going to > >     want to > >     >     squash faulted instructions ASAP and stop issuing along > those > >     >     speculative branches, so as to reclaim execution units.  So > >     I'm assuming > >     >     once a fault comes back from address translation, then > transient > >     >     execution stops dead. > >     > > >     >     Now, break down the cases for whether the address containing > >     sensitive > >     >     data is in cache and TLB or not.  (I'm assuming here that > >     caches are > >     >     virtually-indexed, which enables cache lookups to bypass > address > >     >     translation.) > >     > > >     >     * In cache, in TLB: You end up basically racing between the > >     cache and > >     >     TLB, which will very likely end up detecting the fault > before > >     the data > >     >     arrives, but at the very worst, you get one or two cycles of > >     transient > >     >     instruction execution before the fault. > >     > > >     >     * In cache, not in TLB: Virtually-indexed tagged means > you get > >     a cache > >     >     lookup racing a page-table walk.  The cache lookup beats the > >     page table > >     >     walk by potentially hundreds (maybe thousands) of cycles, > >     giving you a > >     >     bunch of transient instructions before a fault gets > >     triggered.  This is > >     >     the main attack case. > >     > > >     >     * Not in cache, in TLB: Memory access requires address > >     translation, > >     >     which comes back almost immediately as a fault. > >     > > >     >     * Not in cache, not in TLB: You have to do a page table walk > >     before you > >     >     can fetch the location, as you have to go out to physical > >     memory (and > >     >     therefore need a physical address).  The page table walk > will > >     come back > >     >     with a fault, stopping the attack. > >     > > >     >     So, unless I'm missing something here, both non-cached cases > >     defeat the > >     >     meltdown attack, as you *cannot* get the data unless you do > >     address > >     >     translation first (and therefore detect faults). > >     > > >     >     As for why this defeats the spectre attack, the logic is > >     similar: you've > >     >     jumped into someone else's executable code, hoping to > scoop up > >     enough > >     >     information into your branch predictor before the fault > kicks > >     you out. > >     >     However, to capture anything about sensitive information > in your > >     >     side-channels, the transient instructions need to > actually get > >     it into > >     >     the core before a fault gets detected.  The same case > analysis > >     as above > >     >     applies, so you never actually get the sensitive info > into the > >     core > >     >     before a fault comes back and you get squashed. > >     > > >     > > >     >     [1]: A physically-indexed cache would be largely immune to > >     this attack, > >     >     as you'd have to do address translation before doing a cache > >     lookup. > >     > > >     > > >     >     I have some ideas that can build on this, but I'd like > to get some > >     >     feedback first. > >     >     _______________________________________________ > >     >     freebsd-security@freebsd.org > > >      > > >      > >     >> > >     >     mailing list > >     >     https://lists.freebsd.org/mailman/listinfo/freebsd-security > > >      > > >     >      > >      >> > >     >     To unsubscribe, send any mail to > >     >     "freebsd-security-unsubscribe@freebsd.org > > >      > > >     >      > >      >>" > >     >     _______________________________________________ > >     >     freebsd-arch@freebsd.org > > > >      >> > >     mailing list > >     >     https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > >      > > >     >      > >      >> > >     >     To unsubscribe, send any mail to > >     >     "freebsd-arch-unsubscribe@freebsd.org > > >      > > >     >      > >      >>" > >     > > >     > > > > > > > From owner-freebsd-arch@freebsd.org Fri Jan 5 23:24:16 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28596EA677A for ; Fri, 5 Jan 2018 23:24:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC41F65322 for ; Fri, 5 Jan 2018 23:24:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id m11so5891124iti.1 for ; Fri, 05 Jan 2018 15:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GvG3oejfW9xjGvyN+mpfbk9gY590zsaEmxr2Bt4IGBs=; b=UXVoLH4lulIUsy+NYRKNw0AwThI0h3D+KEWlWL7JY9DfoobR58rNZjEB9J0z7LiyVv wyCICrFHU3Ohfsqe5QnAzADhQGAN5oOQSZFKAiktpWu3XUzy3RCo9KISM+GPBbaNgpwu U3D2Q63D/KP4PdZw0VrAmy8dAy6QwuLcnz6szYan3943jXP4bSALFzdWHupItwLCRe83 rdMRzF/gLM5Lu/n33CVNlIPfv3DHgePH3sxLDA0r0eQjwtUHzpc32tiHZ1Jt7Uc7R88+ XCd5NwMKEwDHOIABaW1y9JioJBafHYdCWhFPe9GF6Af5k5m3wVE7j4Y6sYBo0K9IJosc G4+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GvG3oejfW9xjGvyN+mpfbk9gY590zsaEmxr2Bt4IGBs=; b=oGSGq0C6DwBDfz65EIGSjanbnJFNq5mf+8MnHRlNPYk3urxefV9NwKR3zW5WTWebIc gQk8Pj5SVr1bq8Jhw8JUurQ+rupTGflmiKFXcwAXCURg/gV6FD5RptWlYx2jUXCkeE+D k2ER0XdPVOMLYpe45YHtR+YUZbEBFj86XYe6j4jTV8O4+L5JjFULP6PYOSNzube2ey3g 0bkwmUxPnc7lOwD/B7BDqTSFD08/w3UvHPtvOFTp5PPReMv4YqVHmgrGmi0ezbQFY9X4 b3pCqJmO91fpUFovfBs/lIdhCj6tzOBGHoY0nXnLTYKxt1ai4GpYnNSow5G3+qJ9NisP QqXw== X-Gm-Message-State: AKGB3mI14xPSp2gbGXlB75SRFO0IqrACDgEBsIcjPFJ0oa6reZw0szdb oyAYOXhNjFu8GMMxMrAIQTno2ZQAKvoJMjCN1hT5yA== X-Google-Smtp-Source: ACJfBotay+hdT0zImMRgcDqFBUqPj9lPbxTCPzQIaeyKtI7szzc/eXzmbasFn0RJh6o900rWOnWQIXKVhnr95api23E= X-Received: by 10.36.74.200 with SMTP id k191mr5053802itb.69.1515194654806; Fri, 05 Jan 2018 15:24:14 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Fri, 5 Jan 2018 15:24:14 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> From: Warner Losh Date: Fri, 5 Jan 2018 16:24:14 -0700 X-Google-Sender-Auth: Q92uxMC-UbzBj8sh-MwHrMUtbsg Message-ID: Subject: Re: A more general possible meltdown/spectre countermeasure To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 23:24:16 -0000 I mean the mappings we have in the kernel that map all of memory to a specific page using 512GB pages in sys/amd64/amd64/pmap.c:create_pagetables. This allows us to map any PA to a VA with simple math rather than a page table walk. Warner On Fri, Jan 5, 2018 at 4:10 PM, Eric McCorkle wrote: > I'm not sure what you mean by direct map. Do you mean TLB? > > On 01/05/2018 18:08, Warner Losh wrote: > > Wouldn't you have to also unmap it from the direct map for this to be > > effective? > > > > Warner > > > > > > On Fri, Jan 5, 2018 at 3:31 PM, Eric McCorkle > > wrote: > > > > Well, the only way to find out would be to try it out. > > > > However, unless I'm missing something, if you're trying to pull a > > meltdown attack, you try and fetch from the kernel. If that location > > isn't cached (or if your cache is physically indexed), you need the > > physical address (otherwise you don't know where to look), and thus > have > > to go through address translation, at which point you detect that the > > page isn't accessible and fault. In the mean time, you can't > > speculatively execute any of the operations that load up the > > side-channels, because you don't have the sensitive data. > > > > The reason you can pull off a meltdown attack at all is that a > > virtually-indexed cache lets you get the data in parallel with > address > > translation (breaking the dependency between address translation and > > fetching data), which takes 1000s of cycles for a TLB miss, during > which > > you have the data and can launch a whole bunch of transient ops. > > > > Again, these are uncharted waters we're in; so it's entirely possible > > I'm missing something here. > > > > On 01/05/2018 17:22, Warner Losh wrote: > > > While you might be right, I've seen no indication that a cache miss > > > would defeat these attacks in the public and non-public data I've > looked > > > at, even though a large number of alternatives to the published > > > workarounds have been discussed. I'm therefore somewhat skeptical > this > > > would be effective. I'm open, however, to data that changes that > > > skepticism... > > > > > > Warner > > > > > > On Fri, Jan 5, 2018 at 3:15 PM, Eric McCorkle < > eric@metricspace.net > > > >> > wrote: > > > > > > Right, but you have to get the value "foo" into the pipeline > in order > > > for it to affect the side-channels. This technique attempts > to stop > > > that from happening. > > > > > > Unless I made a mistake, non-cached memory reads force address > > > translation to happen first, which detects faults and blocks > the > > > meltdown attack. > > > > > > It also stops spectre with very high probability, as it's very > unlikely > > > that an uncached load will arrive before the speculative > thread gets > > > squashed. > > > > > > On 01/05/2018 17:10, Warner Losh wrote: > > > > I think this is fatally flawed. > > > > > > > > The side channel is the cache. Not the data at risk. > > > > > > > > Any mapped memory, cached or not, can be used to influence > the cache. > > > > Storing stuff in uncached memory won't affect the side > channel one bit. > > > > > > > > Basically, all attacks boil down to tricking the processor, > at elevated > > > > privs, to doing something like > > > > > > > > a = foo[offset]; > > > > > > > > where foo + offset are designed to communicate information > by populating > > > > a cache line. offset need not be cached itself and can be > the result of > > > > simple computations that depend on anything accessible at > all in the kernel. > > > > > > > > Warner > > > > > > > > On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle < > eric@metricspace.net > > > > > > > > > >>> wrote: > > > > > > > > Re-posting to -hackers and -arch. I'm going to start > working on > > > > something like this over the weekend. > > > > > > > > -------- Forwarded Message -------- > > > > Subject: A more general possible meltdown/spectre > countermeasure > > > > Date: Thu, 4 Jan 2018 23:05:40 -0500 > > > > From: Eric McCorkle eric@metricspace.net> > > > > > > > > > >>> > > > > To: freebsd-security@freebsd.org freebsd-security@freebsd.org> > > > freebsd.org>> > > > > freebsd-security@freebsd.org> > > > freebsd.org>>> > > > > > freebsd.org>> > > > > > > > > > >>> > > > > > > > > I've thought more about how to deal with > > meltdown/spectre, and > > > I have an > > > > idea I'd like to put forward. However, I'm still in > > something > > > of a > > > > panic mode, so I'm not certain as to its effectiveness. > > > Needless to > > > > say, I welcome any feedback on this, and I may be > completely > > > off-base. > > > > > > > > I'm calling this a "countermeasure" as opposed to a > > > "mitigation", as > > > > it's something that requires modification of code as > > opposed to a > > > > drop-in patch. > > > > > > > > == Summary == > > > > > > > > Provide a kernel and userland API by which memory > allocation > > > can be done > > > > with extended attributes. In userland, this could be > > > accomplished by > > > > extending MMAP flags, and I could imagine a > > > malloc-with-attributes flag. > > > > In kernel space, this must already exist, as drivers > > need to > > > allocate > > > > memory with various MTRR-type attributes set. > > > > > > > > The immediate aim here is to store sensitive information > > that must > > > > remain memory-resident in non-cacheable memory locations > > (or, > > > if more > > > > effective attribute combinations exist, using those > > instead). > > > See the > > > > rationale for the argument why this should work. > > > > > > > > Assuming the rationale holds, then the attack surface > should > > > be greatly > > > > reduced. Attackers would need to grab sensitive data > > out of stack > > > > frames or similar locations if/when it gets copied there > for > > > faster use. > > > > Moreover, if this is done right, it could dovetail > > nicely into a > > > > framework for storing and processing sensitive assets in > > more > > > secure > > > > hardware[0] (like smart cards, the FPGAs I posted > > earlier, or > > > other > > > > options). > > > > > > > > The obvious downside is that you take a performance hit > > > storing things > > > > in non-cacheable locations, especially if you plan on > > doing heavy > > > > computation in that memory (say, encryption/decryption). > > > However, this > > > > is almost certainly going to be less than the projected > > 30-50% > > > > performance hit from other mitigations. Also, this > > technique > > > should > > > > work against spectre as well as meltdown (assuming the > > > rationale holds). > > > > > > > > The second downside is that you have to modify code for > this > > > to work, > > > > and you have to be careful not to keep copies of > sensitive > > > information > > > > around too long (this gets tricky in userland, where you > > might get > > > > interrupted and switched out). > > > > > > > > > > > > [0]: Full disclosure, enabling open hardware > implementations > > > of this > > > > kind of thing is something of an agenda of mine. > > > > > > > > == Rationale == > > > > > > > > (Again, I'm tired, rushed, and somewhat panicked so my > logic > > > could be > > > > faulty at any point, so please point it out if it is) > > > > > > > > The rationale for why this should work relies on > > assumptions about > > > > out-of-order pipelines that cannot be guaranteed to > > hold, but are > > > > extremely likely to be true. > > > > > > > > As background, these attacks depend on out-of-order > > execution > > > performing > > > > operations that end up affecting cache and > branch-prediction > > > state, > > > > ultimately storing information about sensitive data in > these > > > > side-channels before the fault conditions are detected > and > > > acted upon. > > > > I'll borrow terminology from the paper, using "transient > > > instructions" > > > > to refer to speculatively executed instructions that will > > > eventually be > > > > cancelled by a fault. > > > > > > > > These attacks depend entirely on transient instructions > > being > > > able to > > > > get sensitive information into the processor core and > then > > > perform some > > > > kind of instruction on them before the fault condition > > cancels > > > them. > > > > Therefore, anything that prevents them from doing this > > > *should* counter > > > > the attack. If the actual sensitive data never makes it > to > > > the core > > > > before the fault is detected, the dependent memory > > > accesses/branches > > > > never get executed and the data never makes it to the > > > side-channels. > > > > > > > > Another assumption here is that CPU architects are going > to > > > want to > > > > squash faulted instructions ASAP and stop issuing along > > those > > > > speculative branches, so as to reclaim execution units. > So > > > I'm assuming > > > > once a fault comes back from address translation, then > > transient > > > > execution stops dead. > > > > > > > > Now, break down the cases for whether the address > containing > > > sensitive > > > > data is in cache and TLB or not. (I'm assuming here that > > > caches are > > > > virtually-indexed, which enables cache lookups to bypass > > address > > > > translation.) > > > > > > > > * In cache, in TLB: You end up basically racing between > the > > > cache and > > > > TLB, which will very likely end up detecting the fault > > before > > > the data > > > > arrives, but at the very worst, you get one or two > cycles of > > > transient > > > > instruction execution before the fault. > > > > > > > > * In cache, not in TLB: Virtually-indexed tagged means > > you get > > > a cache > > > > lookup racing a page-table walk. The cache lookup beats > the > > > page table > > > > walk by potentially hundreds (maybe thousands) of cycles, > > > giving you a > > > > bunch of transient instructions before a fault gets > > > triggered. This is > > > > the main attack case. > > > > > > > > * Not in cache, in TLB: Memory access requires address > > > translation, > > > > which comes back almost immediately as a fault. > > > > > > > > * Not in cache, not in TLB: You have to do a page table > walk > > > before you > > > > can fetch the location, as you have to go out to physical > > > memory (and > > > > therefore need a physical address). The page table walk > > will > > > come back > > > > with a fault, stopping the attack. > > > > > > > > So, unless I'm missing something here, both non-cached > cases > > > defeat the > > > > meltdown attack, as you *cannot* get the data unless you > do > > > address > > > > translation first (and therefore detect faults). > > > > > > > > As for why this defeats the spectre attack, the logic is > > > similar: you've > > > > jumped into someone else's executable code, hoping to > > scoop up > > > enough > > > > information into your branch predictor before the fault > > kicks > > > you out. > > > > However, to capture anything about sensitive information > > in your > > > > side-channels, the transient instructions need to > > actually get > > > it into > > > > the core before a fault gets detected. The same case > > analysis > > > as above > > > > applies, so you never actually get the sensitive info > > into the > > > core > > > > before a fault comes back and you get squashed. > > > > > > > > > > > > [1]: A physically-indexed cache would be largely immune > to > > > this attack, > > > > as you'd have to do address translation before doing a > cache > > > lookup. > > > > > > > > > > > > I have some ideas that can build on this, but I'd like > > to get some > > > > feedback first. > > > > _______________________________________________ > > > > freebsd-security@freebsd.org > > > > > > > > > > > > > > freebsd.org>>> > > > > mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd- > security > > > > > > > > > > > security > > > > > > >> > > > > To unsubscribe, send any mail to > > > > "freebsd-security-unsubscribe@freebsd.org > > > > > > > > > > > > > > > > >>" > > > > _______________________________________________ > > > > freebsd-arch@freebsd.org org> > > > > > > > > >> > > > mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > > > > > > > > > > > > > > > >> > > > > To unsubscribe, send any mail to > > > > "freebsd-arch-unsubscribe@freebsd.org > > > > > > > > > > > > > > > > >>" > > > > > > > > > > > > > > > > > > > From owner-freebsd-arch@freebsd.org Fri Jan 5 23:30:21 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 946F4EA6C9A; Fri, 5 Jan 2018 23:30:21 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id CAFD56582F; Fri, 5 Jan 2018 23:30:20 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.148.202.109] (mobile-166-171-187-244.mycingular.net [166.171.187.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id C40378AD8; Fri, 5 Jan 2018 23:30:16 +0000 (UTC) Date: Fri, 05 Jan 2018 18:30:14 -0500 User-Agent: K-9 Mail for Android In-Reply-To: References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> MIME-Version: 1.0 Subject: Re: A more general possible meltdown/spectre countermeasure To: Warner Losh CC: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" From: Eric McCorkle Message-ID: <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 23:30:21 -0000 Ah, superpages=2E I wouldn't think so=2E The cpu still has to do a page tab= le walk (just stopping at the top level page table), and would discover tha= t it's not accessible=2E On January 5, 2018 6:24:14 PM EST, Warner Losh wrote: >I mean the mappings we have in the kernel that map all of memory to a >specific page using 512GB pages in >sys/amd64/amd64/pmap=2Ec:create_pagetables=2E This allows us to map any P= A >to a >VA with simple math rather than a page table walk=2E > >Warner > >On Fri, Jan 5, 2018 at 4:10 PM, Eric McCorkle >wrote: > >> I'm not sure what you mean by direct map=2E Do you mean TLB? >> >> On 01/05/2018 18:08, Warner Losh wrote: >> > Wouldn't you have to also unmap it from the direct map for this to >be >> > effective? >> > >> > Warner >> > >> > >> > On Fri, Jan 5, 2018 at 3:31 PM, Eric McCorkle > > > wrote: >> > >> > Well, the only way to find out would be to try it out=2E >> > >> > However, unless I'm missing something, if you're trying to pull >a >> > meltdown attack, you try and fetch from the kernel=2E If that >location >> > isn't cached (or if your cache is physically indexed), you need >the >> > physical address (otherwise you don't know where to look), and >thus >> have >> > to go through address translation, at which point you detect >that the >> > page isn't accessible and fault=2E In the mean time, you can't >> > speculatively execute any of the operations that load up the >> > side-channels, because you don't have the sensitive data=2E >> > >> > The reason you can pull off a meltdown attack at all is that a >> > virtually-indexed cache lets you get the data in parallel with >> address >> > translation (breaking the dependency between address >translation and >> > fetching data), which takes 1000s of cycles for a TLB miss, >during >> which >> > you have the data and can launch a whole bunch of transient >ops=2E >> > >> > Again, these are uncharted waters we're in; so it's entirely >possible >> > I'm missing something here=2E >> > >> > On 01/05/2018 17:22, Warner Losh wrote: >> > > While you might be right, I've seen no indication that a >cache miss >> > > would defeat these attacks in the public and non-public data >I've >> looked >> > > at, even though a large number of alternatives to the >published >> > > workarounds have been discussed=2E I'm therefore somewhat >skeptical >> this >> > > would be effective=2E I'm open, however, to data that changes >that >> > > skepticism=2E=2E=2E >> > > >> > > Warner >> > > >> > > On Fri, Jan 5, 2018 at 3:15 PM, Eric McCorkle < >> eric@metricspace=2Enet >> > > >= > >> wrote: >> > > >> > > Right, but you have to get the value "foo" into the >pipeline >> in order >> > > for it to affect the side-channels=2E This technique >attempts >> to stop >> > > that from happening=2E >> > > >> > > Unless I made a mistake, non-cached memory reads force >address >> > > translation to happen first, which detects faults and >blocks >> the >> > > meltdown attack=2E >> > > >> > > It also stops spectre with very high probability, as it's >very >> unlikely >> > > that an uncached load will arrive before the speculative >> thread gets >> > > squashed=2E >> > > >> > > On 01/05/2018 17:10, Warner Losh wrote: >> > > > I think this is fatally flawed=2E >> > > > >> > > > The side channel is the cache=2E Not the data at risk=2E >> > > > >> > > > Any mapped memory, cached or not, can be used to >influence >> the cache=2E >> > > > Storing stuff in uncached memory won't affect the side >> channel one bit=2E >> > > > >> > > > Basically, all attacks boil down to tricking the >processor, >> at elevated >> > > > privs, to doing something like >> > > > >> > > > a =3D foo[offset]; >> > > > >> > > > where foo + offset are designed to communicate >information >> by populating >> > > > a cache line=2E offset need not be cached itself and can >be >> the result of >> > > > simple computations that depend on anything accessible >at >> all in the kernel=2E >> > > > >> > > > Warner >> > > > >> > > > On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle < >> eric@metricspace=2Enet >> > > >> > > > >> > >>> >wrote: >> > > > >> > > > Re-posting to -hackers and -arch=2E I'm going to >start >> working on >> > > > something like this over the weekend=2E >> > > > >> > > > -------- Forwarded Message -------- >> > > > Subject: A more general possible meltdown/spectre >> countermeasure >> > > > Date: Thu, 4 Jan 2018 23:05:40 -0500 >> > > > From: Eric McCorkle > eric@metricspace=2Enet> >> > > > >> > >> > > >>> >> > > > To: freebsd-security@freebsd=2Eorg > freebsd-security@freebsd=2Eorg> >> > > > freebsd=2Eorg>> >> > > > > freebsd-security@freebsd=2Eorg> >> > > > freebsd=2Eorg>>> >> > >> > > > freebsd=2Eorg>> >> > > > > > >> > > > > >>> >> > > > >> > > > I've thought more about how to deal with >> > meltdown/spectre, and >> > > I have an >> > > > idea I'd like to put forward=2E However, I'm still >in >> > something >> > > of a >> > > > panic mode, so I'm not certain as to its >effectiveness=2E >> > > Needless to >> > > > say, I welcome any feedback on this, and I may be >> completely >> > > off-base=2E >> > > > >> > > > I'm calling this a "countermeasure" as opposed to a >> > > "mitigation", as >> > > > it's something that requires modification of code >as >> > opposed to a >> > > > drop-in patch=2E >> > > > >> > > > =3D=3D Summary =3D=3D >> > > > >> > > > Provide a kernel and userland API by which memory >> allocation >> > > can be done >> > > > with extended attributes=2E In userland, this could >be >> > > accomplished by >> > > > extending MMAP flags, and I could imagine a >> > > malloc-with-attributes flag=2E >> > > > In kernel space, this must already exist, as >drivers >> > need to >> > > allocate >> > > > memory with various MTRR-type attributes set=2E >> > > > >> > > > The immediate aim here is to store sensitive >information >> > that must >> > > > remain memory-resident in non-cacheable memory >locations >> > (or, >> > > if more >> > > > effective attribute combinations exist, using those >> > instead)=2E >> > > See the >> > > > rationale for the argument why this should work=2E >> > > > >> > > > Assuming the rationale holds, then the attack >surface >> should >> > > be greatly >> > > > reduced=2E Attackers would need to grab sensitive >data >> > out of stack >> > > > frames or similar locations if/when it gets copied >there >> for >> > > faster use=2E >> > > > Moreover, if this is done right, it could dovetail >> > nicely into a >> > > > framework for storing and processing sensitive >assets in >> > more >> > > secure >> > > > hardware[0] (like smart cards, the FPGAs I posted >> > earlier, or >> > > other >> > > > options)=2E >> > > > >> > > > The obvious downside is that you take a performance >hit >> > > storing things >> > > > in non-cacheable locations, especially if you plan >on >> > doing heavy >> > > > computation in that memory (say, >encryption/decryption)=2E >> > > However, this >> > > > is almost certainly going to be less than the >projected >> > 30-50% >> > > > performance hit from other mitigations=2E Also, this >> > technique >> > > should >> > > > work against spectre as well as meltdown (assuming >the >> > > rationale holds)=2E >> > > > >> > > > The second downside is that you have to modify code >for >> this >> > > to work, >> > > > and you have to be careful not to keep copies of >> sensitive >> > > information >> > > > around too long (this gets tricky in userland, >where you >> > might get >> > > > interrupted and switched out)=2E >> > > > >> > > > >> > > > [0]: Full disclosure, enabling open hardware >> implementations >> > > of this >> > > > kind of thing is something of an agenda of mine=2E >> > > > >> > > > =3D=3D Rationale =3D=3D >> > > > >> > > > (Again, I'm tired, rushed, and somewhat panicked so >my >> logic >> > > could be >> > > > faulty at any point, so please point it out if it >is) >> > > > >> > > > The rationale for why this should work relies on >> > assumptions about >> > > > out-of-order pipelines that cannot be guaranteed to >> > hold, but are >> > > > extremely likely to be true=2E >> > > > >> > > > As background, these attacks depend on out-of-order >> > execution >> > > performing >> > > > operations that end up affecting cache and >> branch-prediction >> > > state, >> > > > ultimately storing information about sensitive data >in >> these >> > > > side-channels before the fault conditions are >detected >> and >> > > acted upon=2E >> > > > I'll borrow terminology from the paper, using >"transient >> > > instructions" >> > > > to refer to speculatively executed instructions >that will >> > > eventually be >> > > > cancelled by a fault=2E >> > > > >> > > > These attacks depend entirely on transient >instructions >> > being >> > > able to >> > > > get sensitive information into the processor core >and >> then >> > > perform some >> > > > kind of instruction on them before the fault >condition >> > cancels >> > > them=2E >> > > > Therefore, anything that prevents them from doing >this >> > > *should* counter >> > > > the attack=2E If the actual sensitive data never >makes it >> to >> > > the core >> > > > before the fault is detected, the dependent memory >> > > accesses/branches >> > > > never get executed and the data never makes it to >the >> > > side-channels=2E >> > > > >> > > > Another assumption here is that CPU architects are >going >> to >> > > want to >> > > > squash faulted instructions ASAP and stop issuing >along >> > those >> > > > speculative branches, so as to reclaim execution >units=2E >> So >> > > I'm assuming >> > > > once a fault comes back from address translation, >then >> > transient >> > > > execution stops dead=2E >> > > > >> > > > Now, break down the cases for whether the address >> containing >> > > sensitive >> > > > data is in cache and TLB or not=2E (I'm assuming >here that >> > > caches are >> > > > virtually-indexed, which enables cache lookups to >bypass >> > address >> > > > translation=2E) >> > > > >> > > > * In cache, in TLB: You end up basically racing >between >> the >> > > cache and >> > > > TLB, which will very likely end up detecting the >fault >> > before >> > > the data >> > > > arrives, but at the very worst, you get one or two >> cycles of >> > > transient >> > > > instruction execution before the fault=2E >> > > > >> > > > * In cache, not in TLB: Virtually-indexed tagged >means >> > you get >> > > a cache >> > > > lookup racing a page-table walk=2E The cache lookup >beats >> the >> > > page table >> > > > walk by potentially hundreds (maybe thousands) of >cycles, >> > > giving you a >> > > > bunch of transient instructions before a fault gets >> > > triggered=2E This is >> > > > the main attack case=2E >> > > > >> > > > * Not in cache, in TLB: Memory access requires >address >> > > translation, >> > > > which comes back almost immediately as a fault=2E >> > > > >> > > > * Not in cache, not in TLB: You have to do a page >table >> walk >> > > before you >> > > > can fetch the location, as you have to go out to >physical >> > > memory (and >> > > > therefore need a physical address)=2E The page table >walk >> > will >> > > come back >> > > > with a fault, stopping the attack=2E >> > > > >> > > > So, unless I'm missing something here, both >non-cached >> cases >> > > defeat the >> > > > meltdown attack, as you *cannot* get the data >unless you >> do >> > > address >> > > > translation first (and therefore detect faults)=2E >> > > > >> > > > As for why this defeats the spectre attack, the >logic is >> > > similar: you've >> > > > jumped into someone else's executable code, hoping >to >> > scoop up >> > > enough >> > > > information into your branch predictor before the >fault >> > kicks >> > > you out=2E >> > > > However, to capture anything about sensitive >information >> > in your >> > > > side-channels, the transient instructions need to >> > actually get >> > > it into >> > > > the core before a fault gets detected=2E The same >case >> > analysis >> > > as above >> > > > applies, so you never actually get the sensitive >info >> > into the >> > > core >> > > > before a fault comes back and you get squashed=2E >> > > > >> > > > >> > > > [1]: A physically-indexed cache would be largely >immune >> to >> > > this attack, >> > > > as you'd have to do address translation before >doing a >> cache >> > > lookup=2E >> > > > >> > > > >> > > > I have some ideas that can build on this, but I'd >like >> > to get some >> > > > feedback first=2E >> > > > _______________________________________________ >> > > > freebsd-security@freebsd=2Eorg >> > >> > > > > > >> > > > > >> > > > freebsd=2Eorg>>> >> > > > mailing list >> > > > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebs= d- >> security >> > >> > > =20 >> > = > >> > > > =20 >> security >> > >> > > =20 >> > = >> >> > > > To unsubscribe, send any mail to >> > > > "freebsd-security-unsubscribe@freebsd=2Eorg >> > >> > > > > > >> > > > > > >> > > > > >>" >> > > > _______________________________________________ >> > > > freebsd-arch@freebsd=2Eorg >> org> >> > > >> > > > > >> > >> >> > > mailing list >> > > > =20 >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-arch >> > >> > > > > > >> > > > =20 >> > >> > > > > >> >> > > > To unsubscribe, send any mail to >> > > > "freebsd-arch-unsubscribe@freebsd=2Eorg >> > >> > > > > > >> > > > > > >> > > > > >>" >> > > > >> > > > >> > > >> > > >> > >> > >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-arch@freebsd.org Sat Jan 6 04:33:28 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A4E7EB86CB for ; Sat, 6 Jan 2018 04:33:28 +0000 (UTC) (envelope-from ndd@cis.upenn.edu) Received: from fox.seas.upenn.edu (fox.seas.upenn.edu [IPv6:2607:f470:8:64:5ea5::2c]) by mx1.freebsd.org (Postfix) with ESMTP id BB1B57214B for ; Sat, 6 Jan 2018 04:33:27 +0000 (UTC) (envelope-from ndd@cis.upenn.edu) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (authenticated bits=0) by fox.seas.upenn.edu (8.15.2/8.14.5) with ESMTPSA id w064XPRr009136 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 5 Jan 2018 23:33:26 -0500 Received: by mail-it0-f48.google.com with SMTP id b5so3728849itc.3 for ; Fri, 05 Jan 2018 20:33:26 -0800 (PST) X-Gm-Message-State: AKGB3mJlM+Coj92jyotFWIVyk+aCk3Q+UtUHA0dSh/5ifT4IiZ912Lxn 3Z8lINj/QV8vSWGloE/XEJRq2XL49mZDFFJaws5sog== X-Google-Smtp-Source: ACJfBos7DP42kbJk6US/uImtsQr1opuq3pic7I8T0mUJbgDwzX3/S/gQr4UePcKMqgsi5o02rRsCZHue0E3K9UxOKoA= X-Received: by 10.36.40.141 with SMTP id h135mr5120760ith.77.1515213200310; Fri, 05 Jan 2018 20:33:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.132.76 with HTTP; Fri, 5 Jan 2018 20:32:59 -0800 (PST) In-Reply-To: <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> From: Nathan Dautenhahn Date: Fri, 5 Jan 2018 23:32:59 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: A more general possible meltdown/spectre countermeasure To: Eric McCorkle Cc: Warner Losh , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=5800 signatures=585085 X-PP-Spam-Details: rule=add_spam_details policy=default score=0 spamscore=0 suspectscore=7 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1410280000 definitions=main-1703040151 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 04:33:28 -0000 No this isn't quite superpages. There is a data structure that is a direct map (DMAP) that deterministically maps all physical pages in the system so that all physical pages are accessible through virtual memory. The DMAP has some simple offset calculations allowing it to find the right virtual address mapping (in the DMAP) for the physical address. The more important observation that Warner makes is that to mitigate the problem you have to make sure you get all aliases to each secret. How many exist for each one? How do you know you get them all? Can a attacker create bogus mappings (like ret2dir attack) and then use the new attacks? Another solution, which would handle the more complex attack above, (I know I'm piggybacking, not sure if that's bad) could be to partition a subset of the kernel address space for secrets, and then map those in only when needed, and flush out when done. I did some work a while back on page table isolation and protection from potentially malicious OSs called the nested kernel. I haven't reviewed these new side-channel attacks in great detail yet, but I'm currently working on pushing fine grained intra-address space isolation that might be a nice solution for easily managing and subsets of kernel data. The paper and associated code etc. is all linked on nestedkernel.org. I think these attacks really motivate the nested kernel approach, although we didn't consider secret protection from side-channels. Cheers, -- :: Nathan Dautenhahn :: -- On Fri, Jan 5, 2018 at 6:30 PM, Eric McCorkle wrote: > Ah, superpages. I wouldn't think so. The cpu still has to do a page table walk (just stopping at the top level page table), and would discover that it's not accessible. > > On January 5, 2018 6:24:14 PM EST, Warner Losh wrote: >>I mean the mappings we have in the kernel that map all of memory to a >>specific page using 512GB pages in >>sys/amd64/amd64/pmap.c:create_pagetables. This allows us to map any PA >>to a >>VA with simple math rather than a page table walk. >> >>Warner >> >>On Fri, Jan 5, 2018 at 4:10 PM, Eric McCorkle >>wrote: >> >>> I'm not sure what you mean by direct map. Do you mean TLB? >>> >>> On 01/05/2018 18:08, Warner Losh wrote: >>> > Wouldn't you have to also unmap it from the direct map for this to >>be >>> > effective? >>> > >>> > Warner >>> > >>> > >>> > On Fri, Jan 5, 2018 at 3:31 PM, Eric McCorkle >> > > wrote: >>> > >>> > Well, the only way to find out would be to try it out. >>> > >>> > However, unless I'm missing something, if you're trying to pull >>a >>> > meltdown attack, you try and fetch from the kernel. If that >>location >>> > isn't cached (or if your cache is physically indexed), you need >>the >>> > physical address (otherwise you don't know where to look), and >>thus >>> have >>> > to go through address translation, at which point you detect >>that the >>> > page isn't accessible and fault. In the mean time, you can't >>> > speculatively execute any of the operations that load up the >>> > side-channels, because you don't have the sensitive data. >>> > >>> > The reason you can pull off a meltdown attack at all is that a >>> > virtually-indexed cache lets you get the data in parallel with >>> address >>> > translation (breaking the dependency between address >>translation and >>> > fetching data), which takes 1000s of cycles for a TLB miss, >>during >>> which >>> > you have the data and can launch a whole bunch of transient >>ops. >>> > >>> > Again, these are uncharted waters we're in; so it's entirely >>possible >>> > I'm missing something here. >>> > >>> > On 01/05/2018 17:22, Warner Losh wrote: >>> > > While you might be right, I've seen no indication that a >>cache miss >>> > > would defeat these attacks in the public and non-public data >>I've >>> looked >>> > > at, even though a large number of alternatives to the >>published >>> > > workarounds have been discussed. I'm therefore somewhat >>skeptical >>> this >>> > > would be effective. I'm open, however, to data that changes >>that >>> > > skepticism... >>> > > >>> > > Warner >>> > > >>> > > On Fri, Jan 5, 2018 at 3:15 PM, Eric McCorkle < >>> eric@metricspace.net >>> > > >> >>> wrote: >>> > > >>> > > Right, but you have to get the value "foo" into the >>pipeline >>> in order >>> > > for it to affect the side-channels. This technique >>attempts >>> to stop >>> > > that from happening. >>> > > >>> > > Unless I made a mistake, non-cached memory reads force >>address >>> > > translation to happen first, which detects faults and >>blocks >>> the >>> > > meltdown attack. >>> > > >>> > > It also stops spectre with very high probability, as it's >>very >>> unlikely >>> > > that an uncached load will arrive before the speculative >>> thread gets >>> > > squashed. >>> > > >>> > > On 01/05/2018 17:10, Warner Losh wrote: >>> > > > I think this is fatally flawed. >>> > > > >>> > > > The side channel is the cache. Not the data at risk. >>> > > > >>> > > > Any mapped memory, cached or not, can be used to >>influence >>> the cache. >>> > > > Storing stuff in uncached memory won't affect the side >>> channel one bit. >>> > > > >>> > > > Basically, all attacks boil down to tricking the >>processor, >>> at elevated >>> > > > privs, to doing something like >>> > > > >>> > > > a = foo[offset]; >>> > > > >>> > > > where foo + offset are designed to communicate >>information >>> by populating >>> > > > a cache line. offset need not be cached itself and can >>be >>> the result of >>> > > > simple computations that depend on anything accessible >>at >>> all in the kernel. >>> > > > >>> > > > Warner >>> > > > >>> > > > On Fri, Jan 5, 2018 at 3:02 PM, Eric McCorkle < >>> eric@metricspace.net >>> > > >>> > > > > >>> > >>> >>wrote: >>> > > > >>> > > > Re-posting to -hackers and -arch. I'm going to >>start >>> working on >>> > > > something like this over the weekend. >>> > > > >>> > > > -------- Forwarded Message -------- >>> > > > Subject: A more general possible meltdown/spectre >>> countermeasure >>> > > > Date: Thu, 4 Jan 2018 23:05:40 -0500 >>> > > > From: Eric McCorkle >> eric@metricspace.net> >>> > > >> >>> > >>> > > >>>> >>> > > > To: freebsd-security@freebsd.org >> freebsd-security@freebsd.org> >>> > > >>> freebsd.org>> >>> > > > >> freebsd-security@freebsd.org> >>> > > >>> freebsd.org>>> >>> > > >>> > > >>> freebsd.org>> >>> > > > >> > >>> > > >> > >>> >>> > > > >>> > > > I've thought more about how to deal with >>> > meltdown/spectre, and >>> > > I have an >>> > > > idea I'd like to put forward. However, I'm still >>in >>> > something >>> > > of a >>> > > > panic mode, so I'm not certain as to its >>effectiveness. >>> > > Needless to >>> > > > say, I welcome any feedback on this, and I may be >>> completely >>> > > off-base. >>> > > > >>> > > > I'm calling this a "countermeasure" as opposed to a >>> > > "mitigation", as >>> > > > it's something that requires modification of code >>as >>> > opposed to a >>> > > > drop-in patch. >>> > > > >>> > > > == Summary == >>> > > > >>> > > > Provide a kernel and userland API by which memory >>> allocation >>> > > can be done >>> > > > with extended attributes. In userland, this could >>be >>> > > accomplished by >>> > > > extending MMAP flags, and I could imagine a >>> > > malloc-with-attributes flag. >>> > > > In kernel space, this must already exist, as >>drivers >>> > need to >>> > > allocate >>> > > > memory with various MTRR-type attributes set. >>> > > > >>> > > > The immediate aim here is to store sensitive >>information >>> > that must >>> > > > remain memory-resident in non-cacheable memory >>locations >>> > (or, >>> > > if more >>> > > > effective attribute combinations exist, using those >>> > instead). >>> > > See the >>> > > > rationale for the argument why this should work. >>> > > > >>> > > > Assuming the rationale holds, then the attack >>surface >>> should >>> > > be greatly >>> > > > reduced. Attackers would need to grab sensitive >>data >>> > out of stack >>> > > > frames or similar locations if/when it gets copied >>there >>> for >>> > > faster use. >>> > > > Moreover, if this is done right, it could dovetail >>> > nicely into a >>> > > > framework for storing and processing sensitive >>assets in >>> > more >>> > > secure >>> > > > hardware[0] (like smart cards, the FPGAs I posted >>> > earlier, or >>> > > other >>> > > > options). >>> > > > >>> > > > The obvious downside is that you take a performance >>hit >>> > > storing things >>> > > > in non-cacheable locations, especially if you plan >>on >>> > doing heavy >>> > > > computation in that memory (say, >>encryption/decryption). >>> > > However, this >>> > > > is almost certainly going to be less than the >>projected >>> > 30-50% >>> > > > performance hit from other mitigations. Also, this >>> > technique >>> > > should >>> > > > work against spectre as well as meltdown (assuming >>the >>> > > rationale holds). >>> > > > >>> > > > The second downside is that you have to modify code >>for >>> this >>> > > to work, >>> > > > and you have to be careful not to keep copies of >>> sensitive >>> > > information >>> > > > around too long (this gets tricky in userland, >>where you >>> > might get >>> > > > interrupted and switched out). >>> > > > >>> > > > >>> > > > [0]: Full disclosure, enabling open hardware >>> implementations >>> > > of this >>> > > > kind of thing is something of an agenda of mine. >>> > > > >>> > > > == Rationale == >>> > > > >>> > > > (Again, I'm tired, rushed, and somewhat panicked so >>my >>> logic >>> > > could be >>> > > > faulty at any point, so please point it out if it >>is) >>> > > > >>> > > > The rationale for why this should work relies on >>> > assumptions about >>> > > > out-of-order pipelines that cannot be guaranteed to >>> > hold, but are >>> > > > extremely likely to be true. >>> > > > >>> > > > As background, these attacks depend on out-of-order >>> > execution >>> > > performing >>> > > > operations that end up affecting cache and >>> branch-prediction >>> > > state, >>> > > > ultimately storing information about sensitive data >>in >>> these >>> > > > side-channels before the fault conditions are >>detected >>> and >>> > > acted upon. >>> > > > I'll borrow terminology from the paper, using >>"transient >>> > > instructions" >>> > > > to refer to speculatively executed instructions >>that will >>> > > eventually be >>> > > > cancelled by a fault. >>> > > > >>> > > > These attacks depend entirely on transient >>instructions >>> > being >>> > > able to >>> > > > get sensitive information into the processor core >>and >>> then >>> > > perform some >>> > > > kind of instruction on them before the fault >>condition >>> > cancels >>> > > them. >>> > > > Therefore, anything that prevents them from doing >>this >>> > > *should* counter >>> > > > the attack. If the actual sensitive data never >>makes it >>> to >>> > > the core >>> > > > before the fault is detected, the dependent memory >>> > > accesses/branches >>> > > > never get executed and the data never makes it to >>the >>> > > side-channels. >>> > > > >>> > > > Another assumption here is that CPU architects are >>going >>> to >>> > > want to >>> > > > squash faulted instructions ASAP and stop issuing >>along >>> > those >>> > > > speculative branches, so as to reclaim execution >>units. >>> So >>> > > I'm assuming >>> > > > once a fault comes back from address translation, >>then >>> > transient >>> > > > execution stops dead. >>> > > > >>> > > > Now, break down the cases for whether the address >>> containing >>> > > sensitive >>> > > > data is in cache and TLB or not. (I'm assuming >>here that >>> > > caches are >>> > > > virtually-indexed, which enables cache lookups to >>bypass >>> > address >>> > > > translation.) >>> > > > >>> > > > * In cache, in TLB: You end up basically racing >>between >>> the >>> > > cache and >>> > > > TLB, which will very likely end up detecting the >>fault >>> > before >>> > > the data >>> > > > arrives, but at the very worst, you get one or two >>> cycles of >>> > > transient >>> > > > instruction execution before the fault. >>> > > > >>> > > > * In cache, not in TLB: Virtually-indexed tagged >>means >>> > you get >>> > > a cache >>> > > > lookup racing a page-table walk. The cache lookup >>beats >>> the >>> > > page table >>> > > > walk by potentially hundreds (maybe thousands) of >>cycles, >>> > > giving you a >>> > > > bunch of transient instructions before a fault gets >>> > > triggered. This is >>> > > > the main attack case. >>> > > > >>> > > > * Not in cache, in TLB: Memory access requires >>address >>> > > translation, >>> > > > which comes back almost immediately as a fault. >>> > > > >>> > > > * Not in cache, not in TLB: You have to do a page >>table >>> walk >>> > > before you >>> > > > can fetch the location, as you have to go out to >>physical >>> > > memory (and >>> > > > therefore need a physical address). The page table >>walk >>> > will >>> > > come back >>> > > > with a fault, stopping the attack. >>> > > > >>> > > > So, unless I'm missing something here, both >>non-cached >>> cases >>> > > defeat the >>> > > > meltdown attack, as you *cannot* get the data >>unless you >>> do >>> > > address >>> > > > translation first (and therefore detect faults). >>> > > > >>> > > > As for why this defeats the spectre attack, the >>logic is >>> > > similar: you've >>> > > > jumped into someone else's executable code, hoping >>to >>> > scoop up >>> > > enough >>> > > > information into your branch predictor before the >>fault >>> > kicks >>> > > you out. >>> > > > However, to capture anything about sensitive >>information >>> > in your >>> > > > side-channels, the transient instructions need to >>> > actually get >>> > > it into >>> > > > the core before a fault gets detected. The same >>case >>> > analysis >>> > > as above >>> > > > applies, so you never actually get the sensitive >>info >>> > into the >>> > > core >>> > > > before a fault comes back and you get squashed. >>> > > > >>> > > > >>> > > > [1]: A physically-indexed cache would be largely >>immune >>> to >>> > > this attack, >>> > > > as you'd have to do address translation before >>doing a >>> cache >>> > > lookup. >>> > > > >>> > > > >>> > > > I have some ideas that can build on this, but I'd >>like >>> > to get some >>> > > > feedback first. >>> > > > _______________________________________________ >>> > > > freebsd-security@freebsd.org >>> > >>> > > >> > > >>> > > >> > >>> > > >>> freebsd.org>>> >>> > > > mailing list >>> > > > https://lists.freebsd.org/mailman/listinfo/freebsd- >>> security >>> > >>> > > >>>> > > >>> > > > >>>> security >>> > >>> > > >>>> > >> >>> > > > To unsubscribe, send any mail to >>> > > > "freebsd-security-unsubscribe@freebsd.org >>> > >>> > > >> > > >>> > > > >> > >>> > > >> > >>" >>> > > > _______________________________________________ >>> > > > freebsd-arch@freebsd.org >>>> org> >>> > >> >>> > > >> > >>>> > >> >>> > > mailing list >>> > > > >>https://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> > >>> > > >> > > >>> > > > >>>> > >>> > > >> > >> >>> > > > To unsubscribe, send any mail to >>> > > > "freebsd-arch-unsubscribe@freebsd.org >>> > >>> > > >> > > >>> > > > >> > >>> > > >> > >>" >>> > > > >>> > > > >>> > > >>> > > >>> > >>> > >>> > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Sat Jan 6 05:28:10 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9056DEBC597; Sat, 6 Jan 2018 05:28:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 56F3274F06; Sat, 6 Jan 2018 05:28:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 6235F8BCD; Sat, 6 Jan 2018 05:28:09 +0000 (UTC) Subject: Re: A more general possible meltdown/spectre countermeasure To: Nathan Dautenhahn Cc: Warner Losh , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> From: Eric McCorkle Message-ID: Date: Sat, 6 Jan 2018 00:28:08 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 05:28:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb Content-Type: multipart/mixed; boundary="VvDKQxWj1LBLDsO8kW6mDydav7SWPi8CE"; protected-headers="v1" From: Eric McCorkle To: Nathan Dautenhahn Cc: Warner Losh , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Message-ID: Subject: Re: A more general possible meltdown/spectre countermeasure References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> In-Reply-To: --VvDKQxWj1LBLDsO8kW6mDydav7SWPi8CE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/05/2018 23:32, Nathan Dautenhahn wrote: > Another solution, which would handle the more complex attack above, (I > know I'm piggybacking, not sure if that's bad) could be to partition a > subset of the kernel address space for secrets, and then map those in > only when needed, and flush out when done. I did some work a while > back on page table isolation and protection from potentially malicious > OSs called the nested kernel. I haven't reviewed these new > side-channel attacks in great detail yet, but I'm currently working on > pushing fine grained intra-address space isolation that might be a > nice solution for easily managing and subsets of kernel data. >=20 > The paper and associated code etc. is all linked on nestedkernel.org. > I think these attacks really motivate the nested kernel approach, > although we didn't consider secret protection from side-channels. This sounds more or less like what I had in mind: carve out some special region of kernel space for sensitive information. Ideally, this could be swapped out with an API for storing sensitive data in a secure device (TPM, smart card, etc). However, discussions of this approach over on the RISC-V lists suggest that Intel apparently does some rather crazy things that end up thwarting my proposed countermeasure. (Apparently, they don't acknowledge faults until the faulting instruction *commits*, which means any number of transients could have followed) I'll probably still put a PoC together, but I fear it may not work on Intel. --VvDKQxWj1LBLDsO8kW6mDydav7SWPi8CE-- --V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iIsEARYIADMWIQTp6hWnRH4nHb9/QN/kI/o6qzq6mAUCWlBeaBUcZXJpY0BtZXRy aWNzcGFjZS5uZXQACgkQ5CP6Oqs6upjzSwEA70zkEBdc+WWD+OWW3GqXtw8rTZPs 3wEP+wuiThvhsoQBAKVcbCgztidemCIOCnlMO8QEyeZnG7v9YBjSnoeXeowN =czOH -----END PGP SIGNATURE----- --V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb-- From owner-freebsd-arch@freebsd.org Sat Jan 6 16:12:11 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6188EBFEEF; Sat, 6 Jan 2018 16:12:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id C075D74AE8; Sat, 6 Jan 2018 16:12:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 202868C54; Sat, 6 Jan 2018 16:12:11 +0000 (UTC) Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure To: Wojciech Puchar Cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> From: Eric McCorkle Message-ID: <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> Date: Sat, 6 Jan 2018 11:12:10 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 16:12:12 -0000 On 01/06/2018 11:07, Wojciech Puchar wrote: > sorry for stupid question but for my understanding these attacks works > as below: > > 1) perform access to byte not allowed virtual address and use next > instruction to store relative to private space so cache is filled > depending on value that one shouldn't be able to access. > > 2) as kernel get trap on access violation it will generate SIGSEGV or > SIGBUS which is directed by application using signal(2) so it can be > ignored. > > 3) other part of code perform some timing magic and detects this way > where cache is filled - so byte  value can be guessed properly. > > > My question is - why simply any access attempts to kernel space cannot > generate SIGKILL? Of course it would harm program development, but as > today developers doesn't usually use timesharing machine but have > private computers, simple sysctl variable would suffice. I'd thought of this myself. The problem is that the cache effects could still be observed by another process. While is doesn't defeat the attack, tt does still complicate attacks, so I think it's worth considering. From owner-freebsd-arch@freebsd.org Sat Jan 6 16:31:44 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 880BAEC0B78 for ; Sat, 6 Jan 2018 16:31:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5296975731 for ; Sat, 6 Jan 2018 16:31:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id w188so8807603iod.10 for ; Sat, 06 Jan 2018 08:31:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=h6OI70j7BH1CsMhyDXPLWMy6nSQUdJa1qNrd5c24qZU=; b=p26tdeuP4XDdEjuSXCUSaY+ZFRObPgLfslUFrIWHAU8u2infsVe/NcJIIRVymGl0Wj TV8iuhHNAZsqfOPJu4xKEYo8crMHxgSerOcnyW58JCyPWucGlB6bj/TB9gZmQ5yxIRKn gA/yJSW27om3lSRsHbApzq1FxcCabugMK2I9XALcjOJe0kCZN+Zls2FEv0+cXDAtPa50 zWNb1HQWURQ24W+UOJxmBgIHdWf9duqe+5da7P2zz+8IcRwc/n5i5O5cyE8HOk2kXWlw 9Mkvft/ml5RFWzxxuYBck2emzQXiI+WhjvEtJl3yCkobOQOlByWGaQu1jwER7JwWWnkL 5MWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=h6OI70j7BH1CsMhyDXPLWMy6nSQUdJa1qNrd5c24qZU=; b=lnt6NRpHtHKtWnU2cqVJLQ4V8vTJ7eVbRFtqeFQwW+DGcEZijHQRJNYFgiGkgBDSXN x44Lg9qO2R/d5yOy0QmL7HHR4Cg8ntRBoFNLviMTZgDpiNdR7z4G7iAH/NAZI+VJjJSj H/uZCXK4QCrcOGekBihOjSTdrLxZpxMIbpYLrIrn127zpEUlY4EczRD23HzGFHriix18 +HzjVGEVjIn9AV4ifzqYqSsDYY8RIDiNzSEoFmHY4KAQGx9iWXD3FgVLBD5BNfwWbDUg F/fkAJLBo8nB3XHvidJiAMNGQLfZEQxrDFGhDXVmMvcUEsDu9aKM07gMqTD+xBnTlh8g DgOA== X-Gm-Message-State: AKwxytcmBMdYET4xl6hkG3tRw2BXT7G75nagl24eDgM9Uzs8G6ajzeph DxU1W1FZpFeduO+1xd1D/jn7GKy5U4zxAkyZKOIXTw== X-Google-Smtp-Source: ACJfBosH70NxeKd9hGga//yXlTQA1lxCtwfiWMsBVfVjJSZZr2qxLI6XxpuTew9HIDFzHb6HYoE9OL7Ck6gMBlPHYs0= X-Received: by 10.107.78.12 with SMTP id c12mr6278684iob.63.1515256303292; Sat, 06 Jan 2018 08:31:43 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Sat, 6 Jan 2018 08:31:42 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> From: Warner Losh Date: Sat, 6 Jan 2018 09:31:42 -0700 X-Google-Sender-Auth: dqnExtGmM5mYdYak8_Ly-fGxTuQ Message-ID: Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure To: Eric McCorkle Cc: Wojciech Puchar , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 16:31:44 -0000 On Sat, Jan 6, 2018 at 9:12 AM, Eric McCorkle wrote: > On 01/06/2018 11:07, Wojciech Puchar wrote: > > sorry for stupid question but for my understanding these attacks works > > as below: > > > > 1) perform access to byte not allowed virtual address and use next > > instruction to store relative to private space so cache is filled > > depending on value that one shouldn't be able to access. > > > > 2) as kernel get trap on access violation it will generate SIGSEGV or > > SIGBUS which is directed by application using signal(2) so it can be > > ignored. > > > > 3) other part of code perform some timing magic and detects this way > > where cache is filled - so byte value can be guessed properly. > > > > > > My question is - why simply any access attempts to kernel space cannot > > generate SIGKILL? Of course it would harm program development, but as > > today developers doesn't usually use timesharing machine but have > > private computers, simple sysctl variable would suffice. > > I'd thought of this myself. The problem is that the cache effects could > still be observed by another process. > > While is doesn't defeat the attack, tt does still complicate attacks, so > I think it's worth considering. The problem is that the attempts to access kernel space are speculative. There's no way to get the 'speculative trap' that would have been generated had the code actually executed. There literally is no signal to the kernel this just happened. Warner From owner-freebsd-arch@freebsd.org Sat Jan 6 16:34:10 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4702FEC0DE2; Sat, 6 Jan 2018 16:34:10 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF3D175B22; Sat, 6 Jan 2018 16:34:09 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w06G7LqA041376 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 6 Jan 2018 17:07:21 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w06G7GwH041373; Sat, 6 Jan 2018 17:07:16 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 6 Jan 2018 17:07:16 +0100 (CET) From: Wojciech Puchar To: Eric McCorkle cc: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure In-Reply-To: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> Message-ID: References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 16:34:10 -0000 sorry for stupid question but for my understanding these attacks works as below: 1) perform access to byte not allowed virtual address and use next instruction to store relative to private space so cache is filled depending on value that one shouldn't be able to access. 2) as kernel get trap on access violation it will generate SIGSEGV or SIGBUS which is directed by application using signal(2) so it can be ignored. 3) other part of code perform some timing magic and detects this way where cache is filled - so byte value can be guessed properly. My question is - why simply any access attempts to kernel space cannot generate SIGKILL? Of course it would harm program development, but as today developers doesn't usually use timesharing machine but have private computers, simple sysctl variable would suffice. On Fri, 5 Jan 2018, Eric McCorkle wrote: > Re-posting to -hackers and -arch. I'm going to start working on > something like this over the weekend. > > -------- Forwarded Message -------- > Subject: A more general possible meltdown/spectre countermeasure > Date: Thu, 4 Jan 2018 23:05:40 -0500 > From: Eric McCorkle > To: freebsd-security@freebsd.org > > I've thought more about how to deal with meltdown/spectre, and I have an > idea I'd like to put forward. However, I'm still in something of a > panic mode, so I'm not certain as to its effectiveness. Needless to > say, I welcome any feedback on this, and I may be completely off-base. > > I'm calling this a "countermeasure" as opposed to a "mitigation", as > it's something that requires modification of code as opposed to a > drop-in patch. > > == Summary == > > Provide a kernel and userland API by which memory allocation can be done > with extended attributes. In userland, this could be accomplished by > extending MMAP flags, and I could imagine a malloc-with-attributes flag. > In kernel space, this must already exist, as drivers need to allocate > memory with various MTRR-type attributes set. > > The immediate aim here is to store sensitive information that must > remain memory-resident in non-cacheable memory locations (or, if more > effective attribute combinations exist, using those instead). See the > rationale for the argument why this should work. > > Assuming the rationale holds, then the attack surface should be greatly > reduced. Attackers would need to grab sensitive data out of stack > frames or similar locations if/when it gets copied there for faster use. > Moreover, if this is done right, it could dovetail nicely into a > framework for storing and processing sensitive assets in more secure > hardware[0] (like smart cards, the FPGAs I posted earlier, or other > options). > > The obvious downside is that you take a performance hit storing things > in non-cacheable locations, especially if you plan on doing heavy > computation in that memory (say, encryption/decryption). However, this > is almost certainly going to be less than the projected 30-50% > performance hit from other mitigations. Also, this technique should > work against spectre as well as meltdown (assuming the rationale holds). > > The second downside is that you have to modify code for this to work, > and you have to be careful not to keep copies of sensitive information > around too long (this gets tricky in userland, where you might get > interrupted and switched out). > > > [0]: Full disclosure, enabling open hardware implementations of this > kind of thing is something of an agenda of mine. > > == Rationale == > > (Again, I'm tired, rushed, and somewhat panicked so my logic could be > faulty at any point, so please point it out if it is) > > The rationale for why this should work relies on assumptions about > out-of-order pipelines that cannot be guaranteed to hold, but are > extremely likely to be true. > > As background, these attacks depend on out-of-order execution performing > operations that end up affecting cache and branch-prediction state, > ultimately storing information about sensitive data in these > side-channels before the fault conditions are detected and acted upon. > I'll borrow terminology from the paper, using "transient instructions" > to refer to speculatively executed instructions that will eventually be > cancelled by a fault. > > These attacks depend entirely on transient instructions being able to > get sensitive information into the processor core and then perform some > kind of instruction on them before the fault condition cancels them. > Therefore, anything that prevents them from doing this *should* counter > the attack. If the actual sensitive data never makes it to the core > before the fault is detected, the dependent memory accesses/branches > never get executed and the data never makes it to the side-channels. > > Another assumption here is that CPU architects are going to want to > squash faulted instructions ASAP and stop issuing along those > speculative branches, so as to reclaim execution units. So I'm assuming > once a fault comes back from address translation, then transient > execution stops dead. > > Now, break down the cases for whether the address containing sensitive > data is in cache and TLB or not. (I'm assuming here that caches are > virtually-indexed, which enables cache lookups to bypass address > translation.) > > * In cache, in TLB: You end up basically racing between the cache and > TLB, which will very likely end up detecting the fault before the data > arrives, but at the very worst, you get one or two cycles of transient > instruction execution before the fault. > > * In cache, not in TLB: Virtually-indexed tagged means you get a cache > lookup racing a page-table walk. The cache lookup beats the page table > walk by potentially hundreds (maybe thousands) of cycles, giving you a > bunch of transient instructions before a fault gets triggered. This is > the main attack case. > > * Not in cache, in TLB: Memory access requires address translation, > which comes back almost immediately as a fault. > > * Not in cache, not in TLB: You have to do a page table walk before you > can fetch the location, as you have to go out to physical memory (and > therefore need a physical address). The page table walk will come back > with a fault, stopping the attack. > > So, unless I'm missing something here, both non-cached cases defeat the > meltdown attack, as you *cannot* get the data unless you do address > translation first (and therefore detect faults). > > As for why this defeats the spectre attack, the logic is similar: you've > jumped into someone else's executable code, hoping to scoop up enough > information into your branch predictor before the fault kicks you out. > However, to capture anything about sensitive information in your > side-channels, the transient instructions need to actually get it into > the core before a fault gets detected. The same case analysis as above > applies, so you never actually get the sensitive info into the core > before a fault comes back and you get squashed. > > > [1]: A physically-indexed cache would be largely immune to this attack, > as you'd have to do address translation before doing a cache lookup. > > > I have some ideas that can build on this, but I'd like to get some > feedback first. > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-arch@freebsd.org Sat Jan 6 16:53:47 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75449EC1B43; Sat, 6 Jan 2018 16:53:47 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 055BE7681A; Sat, 6 Jan 2018 16:53:46 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w06Grg1T046942 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 6 Jan 2018 17:53:42 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w06GrbFd046939; Sat, 6 Jan 2018 17:53:37 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 6 Jan 2018 17:53:37 +0100 (CET) From: Wojciech Puchar To: Warner Losh cc: Eric McCorkle , Wojciech Puchar , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure In-Reply-To: Message-ID: References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 16:53:47 -0000 > While is doesn't defeat the attack, tt does still complicate attacks, so > I think it's worth considering. > > > The problem is that the attempts to access kernel space are speculative. There's no way to get the 'speculative trap' that would > have been generated had the code actually executed. There literally is no signal to the kernel this just happened. > > Warner  > > f..k. so there are no real workarounds. Anyway - if CPU companies would be honest they would replace at least all server CPUs that are on warranty From owner-freebsd-arch@freebsd.org Sat Jan 6 17:04:56 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3B38EC2596 for ; Sat, 6 Jan 2018 17:04:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85C7077060 for ; Sat, 6 Jan 2018 17:04:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id k18so8869145ioc.11 for ; Sat, 06 Jan 2018 09:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qxK6lHUIqiRkSC4De4cwFKYEOyQwjG9L2o6RG5K6ra4=; b=Bm3/brLnlFsGlX3cWd668tKRBgeXfyGd0Nxi8LZH0M2pJtmNueKSRgjX0WEpVmV12l DkDzwd7PmsxI2kCGotD8LYfsVylBbhNl3/DbCZy74U4VRCRRB3AVjKKadS7YK0FRhXDD S+In0OX1jtoFN1KbzafnqdIIbLm/5Jr6i/ysYALezZC2rGZmN4U+OTm09NrpfaQ0L9lS Lq8iJNPBVgUqmCkxagPxSW/Z125Z/1HlamI5vko3QUBSF9X4BWhjFYtcA6zcFXczA2AZ G04IOLy4tYIfvN6D59oaeBHQX29BVUIGaunAuIqhD/TIVAoEurOegvFAM6AMbN4McDfJ oayw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qxK6lHUIqiRkSC4De4cwFKYEOyQwjG9L2o6RG5K6ra4=; b=StM0G8BNwE8KRnzGe50N7WeYoB3h2j1GV9vewNaaCNdl41g7hlE5nykzczNrTO79x9 LO3hKY7dQMtCF0VDTdvZGEPiRGekrphfSBRwYHrHA2wc7LFzcIQ+GyVeoRgD61+o9LMN c6oPDbQL2mGzB/Et8TaW11v6pVnhfihPtmvdFHWRWygUlWyfzkb0yna+LLpH5TRofrHv U/YTtVGPifwnny+cn0D0fpHBrfoBMiQvu9quVvittKUjqu0H0fsDKerfsBXa4HlG8Izb WSf6bLgLscVplxah8YlMcqnqjt45bz5XTZ75oXJKAithowG1TbfPHnBo9htGZYn0xx94 fkMg== X-Gm-Message-State: AKwxytcxBgQfkGpwEVAifU8O1+qDLCVUVD4mIlNpAKwFiyrPid65XbtX kcoPCdg1XxvIgCK3Urrq/zQdBxeRkHlWjukmsAwILw== X-Google-Smtp-Source: ACJfBots7zwFP9w7ezasUUVZfZNLHrO8er3Sm5ib1lGQtE8vgsfs7WEl5LYD6cPFRhv3re/dmXN3DzXarhPu0UD8K0o= X-Received: by 10.107.78.12 with SMTP id c12mr6337340iob.63.1515258295739; Sat, 06 Jan 2018 09:04:55 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Sat, 6 Jan 2018 09:04:54 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> From: Warner Losh Date: Sat, 6 Jan 2018 10:04:54 -0700 X-Google-Sender-Auth: 3xtImcXG0eoMSSyWTPVcuOIfNSU Message-ID: Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure To: Wojciech Puchar Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 17:04:56 -0000 On Sat, Jan 6, 2018 at 9:53 AM, Wojciech Puchar wrote: > While is doesn't defeat the attack, tt does still complicate >> attacks, so >> I think it's worth considering. >> >> >> The problem is that the attempts to access kernel space are speculative. >> There's no way to get the 'speculative trap' that would >> have been generated had the code actually executed. There literally is no >> signal to the kernel this just happened. >> >> Warner >> >> >> f..k. so there are no real workarounds. Anyway - if CPU companies would > be honest they would replace at least all server CPUs that are on warranty The only workaround that's completely effective is to unmap all of kernel memory when running in userland. It's a bit tricky because there's small parts that have to stay mapped for various architectural reasons. This means KASLR on these CPUs likely can never be effective since meltdown will let you find what the trap address is and from that find the kernel (though there's some rumblings that the indirection Linux is doing will suffice). Warner From owner-freebsd-arch@freebsd.org Sat Jan 6 19:00:24 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68626EC69B2; Sat, 6 Jan 2018 19:00:24 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE1027AFAC; Sat, 6 Jan 2018 19:00:23 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x22a.google.com with SMTP id o15so7067306wrf.12; Sat, 06 Jan 2018 11:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=y/9jrmvhifUSJWS2amKTdaYeaaTWEWa/Ro0O/My4ppI=; b=ffajEtLxsUavF7T0nFW7kbSZnOd4+iWbhJSqkhMeCxB4l/Ie7s3IN60bO57WcT3KJ3 1ULme51H4GJPw5mwKc7V0LPbMDroJVoLlEsujv0gUQXifw31u3q/uC1OiBZ/b8IAhUrs C+9Bf4gyWkKZkYb3UeAluJpiN7n0i1+UdpFgF4oIzz48qwjcHKBp2APR7Hdedg0kxpdh 4VhVBl7ddYn7+tIKYPbLZmPCG/ZXjeGXroyCVGB/Gf34dw4ncaJwFJB/mrAf/Nf9Z3ls vU4Q93d2wxLgk+ujHyQd4NZmHQ7KRzm7iLYw3YP/9X+AaHFC94ju0tuXF9DmAO0RNEc6 cl1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=y/9jrmvhifUSJWS2amKTdaYeaaTWEWa/Ro0O/My4ppI=; b=I9PnPBi9bqFfRCQdUpzRHsAFrEmg3c3F8C6ukmL/2rl0Oh6prbMTemQpPWJg0IV1ML WDFIPMN5Tz1cKKgwy3dpc4XfgV41Rw/9e5yJcu55Ut2ZWkhOnD8qFSWTUSKiOpO3FBoq qdDRlN71HBVDzwuCEf96EDy34f5HUEGS6+51os0yZ8SYgh/2M2MG5XoSl0cSdNKpUiPj xbzJgz+HrBgFKfbKkAK7LZFvyz8IIigVFuTyHI4/5NCsiJESgpuGX5HTLJreb74VMRkU RD8n3fk8x6hIMkr0neW8KziF1zxkyucSHnu4ozKEAwBICnNxFUIE9UXT6USI1pXMI3Pc Jw2Q== X-Gm-Message-State: AKGB3mLxobfs+Tw5kfVdPPuRXIXwsDHx27m9hiKiCZXdouFg4sprDxdR X2mOPCfdK+wn1OY4/DpxlPE= X-Google-Smtp-Source: ACJfBosL9Zvtk0A2DjkMio8tfgJdKONQg9C7rAMY/VbWmqrkhJa/rpeNUKucpB9nJdSyfC1uxwnuNQ== X-Received: by 10.223.164.207 with SMTP id h15mr5897330wrb.59.1515265222539; Sat, 06 Jan 2018 11:00:22 -0800 (PST) Received: from ernst.home (p5B023419.dip0.t-ipconnect.de. [91.2.52.25]) by smtp.gmail.com with ESMTPSA id p107sm4457934wrc.61.2018.01.06.11.00.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 06 Jan 2018 11:00:21 -0800 (PST) Date: Sat, 6 Jan 2018 20:00:20 +0100 From: Gary Jennejohn To: Warner Losh Cc: Wojciech Puchar , Eric McCorkle , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: A more general possible meltdown/spectre countermeasure Message-ID: <20180106200020.051c4149@ernst.home> In-Reply-To: References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 19:00:24 -0000 On Sat, 6 Jan 2018 10:04:54 -0700 Warner Losh wrote: > On Sat, Jan 6, 2018 at 9:53 AM, Wojciech Puchar wrote: > > > While is doesn't defeat the attack, tt does still complicate > >> attacks, so > >> I think it's worth considering. > >> > >> > >> The problem is that the attempts to access kernel space are speculative. > >> There's no way to get the 'speculative trap' that would > >> have been generated had the code actually executed. There literally is no > >> signal to the kernel this just happened. > >> > >> Warner > >> > >> > >> f..k. so there are no real workarounds. Anyway - if CPU companies would > > be honest they would replace at least all server CPUs that are on warranty > > > The only workaround that's completely effective is to unmap all of kernel > memory when running in userland. It's a bit tricky because there's small > parts that have to stay mapped for various architectural reasons. This > means KASLR on these CPUs likely can never be effective since meltdown will > let you find what the trap address is and from that find the kernel (though > there's some rumblings that the indirection Linux is doing will suffice). > This point is addressed in one of the papers. KAISER only maps small parts of the address space, which are apparently required for special use, in both the kernel and user space. Otherwise, the kernel and user space do not share any part of the memory map. The conclusion in the paper is that, yes, a small part of memory is still common to both the kernel and user space, but if KASLR is used, then it will be very difficult to identify these ranges. -- Gary Jennejohn From owner-freebsd-arch@freebsd.org Sat Jan 6 19:55:17 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 873CDDB8C72; Sat, 6 Jan 2018 19:55:17 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A0587CD63; Sat, 6 Jan 2018 19:55:17 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w06JtBre047913 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 6 Jan 2018 11:55:11 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w06JtBG9047912; Sat, 6 Jan 2018 11:55:11 -0800 (PST) (envelope-from jmg) Date: Sat, 6 Jan 2018 11:55:11 -0800 From: John-Mark Gurney To: Freddie Cash Cc: Freebsd Security , FreeBSD Hackers , "freebsd-arch@freebsd.org" Subject: Re: Intel hardware bug Message-ID: <20180106195510.GH75576@funkthat.com> Mail-Followup-To: Freddie Cash , Freebsd Security , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <20180105191145.404BC335@spqr.komquats.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 06 Jan 2018 11:55:11 -0800 (PST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 19:55:17 -0000 Freddie Cash wrote this message on Fri, Jan 05, 2018 at 11:53 -0800: > Spectre (aka CVE-2017-5715 and CVE-2017-5753) is the issue that affects all > CPUs (Intel, AMD, ARM, IBM, Oracle, etc) and allows userland processes to > read memory assigned to other userland processes (but does NOT give access > to kernel memory). No, Spectre does not allow one userland process to read another userland process's memory.. It allows an attacker to read any memory within the same process.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Sat Jan 6 20:42:04 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2A27DEE59D; Sat, 6 Jan 2018 20:42:04 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 51D0D7E98C; Sat, 6 Jan 2018 20:42:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w06KfwvF072158 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 6 Jan 2018 21:41:58 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w06KfqJX072155; Sat, 6 Jan 2018 21:41:52 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 6 Jan 2018 21:41:52 +0100 (CET) From: Wojciech Puchar To: Warner Losh cc: Wojciech Puchar , Eric McCorkle , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure In-Reply-To: Message-ID: References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 20:42:04 -0000 > The only workaround that's completely effective is to unmap all of kernel memory when running in userland. It's a bit tricky because this means on every syscall on interrupt: - memcopy part of top level PTE on enter, bzero on exit - TLB flush both on enter and exit. IMHO it would make much more than 30% overhead in many cases. am i wrong? > there's small parts that have to stay mapped for various architectural reasons. This means KASLR on these CPUs likely can never be > effective since meltdown will let you find what the trap address is and from that find the kernel (though there's some rumblings > that the indirection Linux is doing will suffice). > > Warner > > From owner-freebsd-arch@freebsd.org Sat Jan 6 21:37:21 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5CF4DF3837; Sat, 6 Jan 2018 21:37:21 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48F7A81857; Sat, 6 Jan 2018 21:37:21 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id y71so8475234lfd.12; Sat, 06 Jan 2018 13:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VeaCCrhahGTR5WjwlkG09R8dkN7k/hKE7TBnG6w2zuY=; b=SL72Fx5QJc0H5QWPX8SqdhZIv4VYWvvsv2eoOg5HIXeee4+rf7v6CR7X4qwezQf+kF 3iBiMitaya0BvyatHH4ntyal/bGMwxb8xzy/kMSAjXLB5Gbaow2tu9wxOlGA/tXuXKgX sdEGVFwG+MxBDZfZ6Rbm29AJXFTpJ7pbk3uyu5YWIyGJwLqo2eN8e7tjNB4hnvE8cXLz iQEtS1VrHlk9uG2IdmMhGbX++gPBP8uFN4BSN4dLsyqfhAsARWjdUA1BK5Hny+YX7bhs Ug9CMyFBJFqmCjPacByKwVnaSSPoFtonGZqqG+0O91Ql72TJ93RHcoil7E48hDIrjHg7 MPDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VeaCCrhahGTR5WjwlkG09R8dkN7k/hKE7TBnG6w2zuY=; b=uRtu6XrljA1Q3lqzzfROasjQYY3oWrmdx1N/ETCMXp4BUGeWDqrN/I9JEWIBQ/SIX1 VQkjF1rMr48prJHyPmVzO9JYU8ut4Y5XziA31iy4/zSqvi+10pDCwRq1lK8BolhbOjtF JAt7fL4+hImy2KaanIP2b167tuPewdtMcKwMr+0dVYVAS0eUddcFsR5BImTRwBmIqTwX OQaozql11kkSEcx/CpY3zEQMqIFg9k7uAcVfIdc9rc5qhtt7oXhJDzuzM0fWfo20h6gl mwF51x9SVqKk0Xed7GpDBy2SmHDjsjCFo+TbQtp+ROd2D1sK1NtOJ2+NTgwvGCXiTl7W PRgw== X-Gm-Message-State: AKwxytdXWHFzrODCtfRxE8LEaCUTiswtcN1uaqsj0pADxWB9BiJSDtJO WlPpFOy/TuPZJhts56iPUEMvYa5OF7uDFOV6//Ny5A== X-Google-Smtp-Source: ACJfBotMFotIM1tbfdLMCAnsnlHdMM/WhEcPYKtsMIOHy83w/zxoB7a4xL3lsLZRDtHhtyohi/n0nRxgDRDTqui4OLQ= X-Received: by 10.25.86.17 with SMTP id k17mr3860615lfb.67.1515274638724; Sat, 06 Jan 2018 13:37:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.207 with HTTP; Sat, 6 Jan 2018 13:37:17 -0800 (PST) Received: by 10.25.163.207 with HTTP; Sat, 6 Jan 2018 13:37:17 -0800 (PST) In-Reply-To: <20180106195510.GH75576@funkthat.com> References: <20180105191145.404BC335@spqr.komquats.com> <20180106195510.GH75576@funkthat.com> From: Freddie Cash Date: Sat, 6 Jan 2018 13:37:17 -0800 Message-ID: Subject: Re: Intel hardware bug To: Freebsd Security , FreeBSD Hackers , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 21:37:21 -0000 On Jan 6, 2018 11:55 AM, "John-Mark Gurney" wrote: Freddie Cash wrote this message on Fri, Jan 05, 2018 at 11:53 -0800: > Spectre (aka CVE-2017-5715 and CVE-2017-5753) is the issue that affects all > CPUs (Intel, AMD, ARM, IBM, Oracle, etc) and allows userland processes to > read memory assigned to other userland processes (but does NOT give access > to kernel memory). No, Spectre does not allow one userland process to read another userland process's memory.. It allows an attacker to read any memory within the same process. That's variant 1 of Spectre. Variant 2 crosses process boundaries. It's the one that has VM hosting systems worried as a process running in VM1 can read memory assigned to VM2. Cheers, Freddie