From nobody Wed Jul 13 17:39:55 2022 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B08D81D00533 for ; Wed, 13 Jul 2022 17:39:58 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LjlHx4JW3z3lCb for ; Wed, 13 Jul 2022 17:39:57 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-pj1-x102b.google.com with SMTP id o31-20020a17090a0a2200b001ef7bd037bbso4853218pjo.0 for ; Wed, 13 Jul 2022 10:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Oyar7NB8/9QxTwSPjrap9IJqPwmXeCx9wEwjAJoy8b4=; b=JuX6M6qMTdR0DjMyLzpFTYKJgGtfd/NCH21SaKxBZmkpa945YuYilwNZC+nalve85W EW1xyLaia79GSWJyYOXRyI/Tk1koGkJ+QlqVvkAMW/nFIeVZwGysKfUGv/Zc1su7wiqT fom3ERqQKHrMlDOT2kBqLojkdQUyS65M9nGDC6lh44XOcir4clKQEO1cix+QobxrL83L 0JvfT0uaU0E42H5CHiQk1YnUlIYGJxNXT9Ss15SGVYC5uifjMoftXxnSSP3snedJASGd tCyHLmn1NkzWFSuqoCgmNlSt9yvrH/ycgSodlmdQqqyP5j7uQ+d+naiAhaolEmybIacO Jr/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Oyar7NB8/9QxTwSPjrap9IJqPwmXeCx9wEwjAJoy8b4=; b=Ha2JspdiFiVxLDKokkQ8HzWvIDJ8H4ErGiZqxVJxWVRwjxoKfNGtv26ngOb+K+STpP N7JqSMKLvCijfk1qAIanf7e8XsQinrCDHspT8fSe6DVSHV49Og3aHw8lTrHWaW/KXbFr 2dEYgpcUD69oKGkBJXDX/6adGBY3x4GRWhsRMHMrwzXHoaJQct4ZA9Aq9ybvP7DSkge4 0hm3qCzDxWe++ZXrtdmGMScOqKiRjlTcGqaEcBzqhiudiiS2kSY8NQJFKHoJjQfV9zHW o33zce2lZN+dj+yOPLFPcBE1krDrpktjB3UI2d5XasniByXzLE37OXxUEuWs+WBCbwRo 9s3w== X-Gm-Message-State: AJIora+oS0YSfqlMTsMgQnumUFsssbuFW/Fi3X6Y+swKxYIX/XAKH4Fi rLmO/XD22q1skZgL99AR0QaRphERBk6o4QnXHiSd0eT/KowtQimD5rI= X-Google-Smtp-Source: AGRyM1v6Z84//b1gbn9l8Y5CYKKRYAyM1f1xhghZHQVX8Ut4VncC+UPsJrkjtLy3cixD6Yx/KuqVMI43Su856eWQWSw= X-Received: by 2002:a17:90b:3ece:b0:1f0:6b2e:6fbf with SMTP id rm14-20020a17090b3ece00b001f06b2e6fbfmr8851476pjb.203.1657733996005; Wed, 13 Jul 2022 10:39:56 -0700 (PDT) List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 Received: by 2002:a17:903:1cc:b0:16c:4f00:65b3 with HTTP; Wed, 13 Jul 2022 10:39:55 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Wed, 13 Jul 2022 13:39:55 -0400 Message-ID: Subject: Re: Retbleed, another speculative execution attack To: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LjlHx4JW3z3lCb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=JuX6M6qM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::102b as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; NEURAL_HAM_LONG(-0.98)[-0.980]; NEURAL_HAM_SHORT(-0.92)[-0.923]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102b:from]; MLMMJ_DEST(0.00)[freebsd-security]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N >> FreeBSD should keep a wiki table of all these >> HW attacks with at least three columns... >> - The exploit >> - Were mitigations published [by hw vendors or sw communities] >> - Were those or other [mitigations] applied [to freebsd] On 7/13/22, John Gray wrote: > Like this one? > https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities Cool, yes, more or less. Though that one may be missing some number of hardware (HW) vulnerabilities. They are a distinct space imposed on OS's by upstream HW makers (as opposed to self-imposed SW kernel, user, app, compiler, etc bugs), ambitious wiki'ers could track them all the way back to F00F, etc. Though only those HW bugs with actual or suspected potential for an exploitable security vector would need listed, not simple lockups, reboots, incorrect return status or data, as in the typical HW errata sheets. Maybe some organizing updates... Background and other generic upstream literature could by now be replaced with a few overall wikipedia links. Try one bug per row by its canonical links and name (usually CVE) to show BSD saw and signed off in what ways on each (whichever among ticket, review, commit, mail thread). Only the per bug list of 'fixes/mitigs available' and 'fixes/mitigs applied' matters to users. 'Vulnerable' or 'not vulnerable' is meta curation that really only matters to legacy hardware shoppers and critiquers of HW makers, and is already available in the offsite literature. The HEAD signoff is more important to track for long term reference than maintaining list of EOL major.minor's when that info already flows from and within links to the head work anyway. In the interest of importance on first glance "seen and signed off, didn't totally miss a CVE somewhere" aspect. From there, whatever level of work-from flow matrix and detail can then follow. Someone failed to post their reply to the list... " FreeBSD doesn't have a fix for that one, but it also doesn't have fixes for Spectre V1, Spectre-BHB, or MMIO Stale Data. FreeBSD is still a sitting duck for these CPU vulns, so adding yet another one on top doesn't really matter. " And please quit top-posting... replies belong below what you are replying to so people can linearly follow entire context like a book top to bottom, and don't have to labor to fix the disorderly mess you created when they reply to it.