From nobody Tue Sep 10 23:47:35 2024 X-Original-To: freebsd-arch@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 4X3L3g4wZ9z5TtpP; Tue, 10 Sep 2024 23:47:43 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3L3f3QfJz476k; Tue, 10 Sep 2024 23:47:42 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=JQpQoezA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2f6580c2bbfso2953571fa.1; Tue, 10 Sep 2024 16:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726012060; x=1726616860; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=pLn0PIT2lwV+Djl805vfqvUiLnwCki2KPcUPimdE1mU=; b=JQpQoezARMrUdMigjLsU/NfW1PkDPD6Aa9gI/PQhObE02NfRyrPdaSQ6vRkXU6R1zh T4Hc2rNqRXGal/sCKKcfjsi+5bEtq/CH5VxpE1dxlIrbVNRCVlTy+sKUQlNGCYDIyHKt DSAbTF2ygoqINrpt0Q7nQjtKIrwbT74stMHfRuMq5bzd8LQc/uyL9TCyxIkXC9b7kBUq odIfyHokp6V8hKB8PA4pVxI8OyBrSO2oDPMx9qdvji/4kMGrYyJgsoesh22JqwDg8pvG VhkJoS0xSKqGEoHzKpQz6ThNEtoX0LniyRwVEOBDVsFNNzD3lnfmSWKjd4k6Mu3YWX8i 2VyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726012060; x=1726616860; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pLn0PIT2lwV+Djl805vfqvUiLnwCki2KPcUPimdE1mU=; b=QPN1tM80O+C4c0E87P9QyQURC4x8kaRGbxu9upCwovByDg6whRVKwoE9CiLvJRzfaq /UNIAbT/2JpQPlmH5hMrvkgbSPoK2H2+49f/Zyx+BK6TAponmTMK2oxsLQgO0Uf1cPTp wHqvoPFieJb3E9EvDsumbsS4Yt0lFlnfK2ltE64jjluE85jZkBmb6popiHyST5ZJjpT0 EzP1K+O/EcQCtdodk74OfVm5jSXvge/jg+fZznB8YxVgPpOJsiWgrSqJDVJkvanCnvoK nGNXwCen6XZzrr9QKyfIs6DKwNIobXfAjqiizk0MWMrgExAPfz021udRvJ363j81jBbg mNrw== X-Forwarded-Encrypted: i=1; AJvYcCUIhjJ1GZRlt1kOYsVRvTaHCzQjlfvbcTtK8BKhqFe3kZkHEiJhKqxtcZCLTJS+aBRfmTIIWkqzTNbgXPw=@freebsd.org, AJvYcCVGNoZBKdqC15RKc8pIdSRYdRHvNZEwXWp/DYG/M7jHLEJ9WAfooxVtC96a7itePRGsqdXi4RZRslml18s=@freebsd.org, AJvYcCWi2SotehQSxWaJ+u/mW/Uy3+8KQqFrcZwNTgqAXdIMErrwUVs/6G1MPBqbA9KD+ggZoDpepqnrCjMQN2jviU1B@freebsd.org X-Gm-Message-State: AOJu0Yxn37B/OcQfcfcOqHSvFDY8bWdY/BnkM1Um1u5lrUdTof1O4iK8 1m7P/Z4gp1qvWrCip2T/qb0aU8xtwa5eBPbpxDP7EwywWd0lrORHEGjD4OjM X-Google-Smtp-Source: AGHT+IFS3vPrdngBZPNcSrE198Tqj5S5aP4CHm4pOYWmA1awgaVQ++udPn+7VFedXQGZ7dqVjpIOBQ== X-Received: by 2002:a05:6512:1387:b0:536:552e:5d36 with SMTP id 2adb3069b0e04-5366b91f158mr1474569e87.12.1726012059924; Tue, 10 Sep 2024 16:47:39 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5365f90d482sm1362675e87.262.2024.09.10.16.47.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 16:47:39 -0700 (PDT) Date: Wed, 11 Sep 2024 02:47:35 +0300 From: Vadim Goncharov To: Rob Wing Cc: David Chisnall , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" Subject: That's how (why) BSD is dying (Was: BPF64) Message-ID: <20240911024735.37522532@nuclight.lan> In-Reply-To: References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> <20240911011228.161f94db@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-hackers@freebsd.org,freebsd-net@freebsd.org]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22c:from] X-Rspamd-Queue-Id: 4X3L3f3QfJz476k On Tue, 10 Sep 2024 15:05:21 -0800 Rob Wing wrote: > Doesn't NetBSD have Lua in the kernel...anyone have any experience > with it? Lua is not suitable for the discussed problem domains, don't listen to those who did not read material and did not understand short descriptions. > re BPF64: >=20 > looks like hand waving, proposing two unwritten languages that > extends an ISA that is still being drafted by IETF...hmm What's the point to waste resources on writing thing that is known to be not accepted to base system from the very beginning? FreeBSD already had precedent when a *ready* code framework was rejected be some FreeBSD users' enemy, leaving FreeBSD users to suck with absolutely *no* alternative (yep, sensors) - as ridiculous as if it was to say "current BSD firewalls are inferior to Linux so we'll better sit without that bad code (and firewall) AT ALL". Yes, the situation in networking for us was for many years - and still is - exactly so. This is exactly the way how to loose market competition and die - just don't try to innovate and do something better than competitor; then you find yourself porting compatibility layers after decades of rot, like Netlink or Linuxulator ABI, in a try to at least hobble with a cane instead of lying in a coma. > you can make anything look good on paper but the devil is in the > details...which there are plenty of So do you have to say something constructive on the real subject? Or even bikesheds are in short supply now? > On Tuesday, September 10, 2024, Vadim Goncharov > wrote: >=20 > > On Tue, 10 Sep 2024 15:58:25 +0100 > > David Chisnall wrote: > > =20 > > > On 10 Sep 2024, at 14:44, Vadim Goncharov > > > wrote: =20 > > > > > > > > I am not an experience assembler user and don't understand how > > > > Spectre works - that's why I've written RFC letter even before > > > > spec finished - but isn't that (Spectre) an x86-specific thing? > > > > BPF64 has more registers and primarily target RISC > > > > architectures if we're speaking of JIT. =20 > > > > > > No, speculative execution vulnerabilities are present in any CPUs > > > that do speculative execution that does not have explicit > > > mitigations against them (i.e. all that have shipped now). Cache > > > side channels are present in any system with caches and do not > > > have explicit mitigations (i.e. all that have shipped so far). > > > > > > Mitigations around these things are an active research area, but > > > so far everything that=E2=80=99s been proposed has a performance hit = and > > > several of them were broken before anyone even implemented them > > > outside a simulator. > > > =20 > > > > And BPF64 is meant as backwards-compatible extension of existing > > > > BPF, that is, it has bytecode interpreter (for(;;) switch/case) > > > > as primary form and JIT only then - thus e.g. JIT can be > > > > disabled for non-root users in case of doubt. eBPF can't do > > > > this - it always exists in native machine code form at > > > > execution, bytecode is only for verifier stage. =20 > > > > > > This has absolutely no impact on cache side channels. The JIT > > > makes some attacks harder but prime-and-probe attacks are still > > > possible. =20 > > > > Wait, do you want to say that problem is not in JIT, that is, that > > current BPF (e.g. tcpdump) present in the kernel - are also > > vulnerable? Also, let's classify vulnerabilities. Is speculative > > execution vulnerability the same as cache side channels? In any > > case, what impact is? E.g. attacker could leak secrets, but *where* > > would them leak? BPF typically returns one 32-bit number as a > > verdict (often as just boolean), is it really attack vector? That > > is, may be solution is just "don't give read access to BPF-writable > > memory segments to untrusteds". > > > > Next, if problem is with timing, then isn't that enough to just > > restrict BPF code on having access to timers with resolution high > > enough? > > =20 > > > BPF can be loaded only by root, who can also load kernel modules > > > and map /dev/[k]mem, and FreeBSD does not protect the root <-> > > > kernel boundary. =20 > > > > Wrong. It is possible for decades to do `chmod a+r /dev/bpf*` and > > run tcpdump as non-root, which will load BPF code into kernel. Is > > *that* also a vulnerability, and if so, why it was never reported? > > =20 > > > Please read some of the (many) attacks on eBPF to better > > > understand the security landscape here. It=E2=80=99s a *very* hard > > > problem to solve. =20 > > > > Finally, the most big (in effort) question: suppose we limited to > > trusted root user etc. so it's of no concern. Are there now any > > objections/suggestions/comments on (rest of) BPF64 ? > > > > -- > > WBR, @nuclight > > > > =20 --=20 WBR, @nuclight