From nobody Tue Sep 10 22:12:28 2024 X-Original-To: freebsd-hackers@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 4X3Hxt0Zhpz5TfHl; Tue, 10 Sep 2024 22:12:34 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 4X3Hxs4cWVz4sWw; Tue, 10 Sep 2024 22:12:33 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2f025b94e07so50790821fa.0; Tue, 10 Sep 2024 15:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726006351; x=1726611151; 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=VQklzI5f+UhE/4HXXB6RHKU+J3Qo/ASreqA6+yuuQMA=; b=Gt0Mxk0EpZN59+KWga6Y85o6QJxPxRtDzMbNCHMxOpiO95o/UbDHjCCMYrjGqeIu7I 6EVZDtyxrXexv/aKlQBVKWCfvz+YmoJMuTk20Iuz80tjI7KS3diMT+yDBZghH4SlK6+0 7vNouIrF8WU3PrIOuDzHKfZyudU2vMPdiEyRFBPVtm8NJPkCuww9BZKwlnm3zsL6eTiQ lJHMWVFumb9aqhaHr5oxWd/UKf79Tk4pu+kDoLVi5p2SRacCxoGBztvLqGmCwqVUpQ0f 41p8A6rARrO8fy/7iFLPQ2EX57k+xDRpUh8msj8o9zwdCSa5JvamrHhJDzCM8yAeevZE aG4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726006351; x=1726611151; 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=VQklzI5f+UhE/4HXXB6RHKU+J3Qo/ASreqA6+yuuQMA=; b=FrWGWSlI4V3C/Y5L7RHRSZ88lRJqCqQ44c8jPsOjgh/JlTg8/cjjy2vTpr2xwqWqLW 1xqlqDpWV8357RJycWFzS5yTsQEwXDi2pVcXZv3LHcoUeEz4lX/VmTsvaqZFysW9gSTV s5ID/WErJj0fR6yBT6+ZsCoNBG1Rl6/osSwKfp06Ov0alR/GWqNXEKGSeHE+FkipS3pn NMVpl68rsT1wuu+GeEbHVukVud5Ri6Fie5o5U3/97UaoqieywVsiK44zx4jeh4eAVsH1 rNUplXNXShVR7mYYN4qwixMgkpRuBPx2FwxKmLaxHdMsURLY4dH1MIiD3/zjiSj/azNP vkEA== X-Forwarded-Encrypted: i=1; AJvYcCUXyhl85uihZ4xjmNCvxgw17NL/6on20C7C+DJyGBs/HvOzIvL5HVYPlh3vj35o3OzEEpxXp4Omsr9pQeeCSSwe@freebsd.org, AJvYcCX+g+SUU4VBC6hqQRhaoGw/K6YNNGZyKCWdY1y2RTiuZJsKefVZ9xAuO2gIoh7r1lk6tT17vBviGrqpC+c=@freebsd.org, AJvYcCXfLs0EFHjn8KXuPPelq99ALzOXy1TOAcVLhxFuESmpvVFWMxBuEj1iqCkteUYCV+liXHKVGslHkagEidc=@freebsd.org X-Gm-Message-State: AOJu0YzSy9AGJhXKHBVk7pjrgB96buI3IoxqhmPrxrzqoyTyXXWMTQvZ o/O1jYKXV2n9QZHMqWoObZ31hPPniboiPuYefbUctmApXTQPewTDnWqsHZjW X-Google-Smtp-Source: AGHT+IHV0riUgCN7WGyLkuUPPbvyKnE92FLj4+LbmsITqsigNsHw13jPjtefeDp//sUQyk2pW6hqNA== X-Received: by 2002:a05:651c:1a0b:b0:2f7:6653:8044 with SMTP id 38308e7fff4ca-2f76653812dmr52539331fa.20.1726006350849; Tue, 10 Sep 2024 15:12:30 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f75c07cf5esm13208111fa.86.2024.09.10.15.12.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 15:12:30 -0700 (PDT) Date: Wed, 11 Sep 2024 01:12:28 +0300 From: Vadim Goncharov To: David Chisnall Cc: Poul-Henning Kamp , tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240911011228.161f94db@nuclight.lan> In-Reply-To: <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> 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> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4X3Hxs4cWVz4sWw On Tue, 10 Sep 2024 15:58:25 +0100 David Chisnall wrote: > 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 >=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). >=20 > Mitigations around these things are an active research area, but so > far everything that=E2=80=99s been proposed has a performance hit and sev= eral > 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 >=20 > This has absolutely no impact on cache side channels. The JIT makes > some attacks harder but prime-and-probe attacks are still possible. 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? > 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. 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? > 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 ? --=20 WBR, @nuclight