From owner-freebsd-security@freebsd.org Fri Apr 17 13:52:11 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0A152BA2F9 for ; Fri, 17 Apr 2020 13:52:11 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493cwC0q9cz3wtw for ; Fri, 17 Apr 2020 13:52:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f182.google.com with SMTP id f2so2164374ilq.7 for ; Fri, 17 Apr 2020 06:52:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C/QC2Lhy+axENLuSQT4b3p32sK/ffPOBECwfPHf1g8U=; b=XB+KW4CVZQOwpoK306Wz8wFaa5SKFtCDOgLoOqzYcf78Zk4wxiwGDc2qxs7ngO7hrs ED7m38MCQKy5F+yZy+cTZZkp/hrzOIVr33LoT6ga/WzkFBULoUQuaVmGeb7++seXXvWA ASVky6/2bLzds3GjVv8ZU7sdfUahqzIBvYDQayMzREfAjUSIT+F37N6eslG3TsWkY1bG U0SBRmQ8xT6lWtkz3eOVtjFIrneKfvhFR6Mz+bPG4o53aVA+V6jQxzbtyHg8TnFJQB7L EP3mMPtg5Io1UO+IPQL/25qU7KZE678g0c83465rBMqMieHrUBmHceu4k2nLM55+rdtE 9/lQ== X-Gm-Message-State: AGi0PuaBXvY9+bIo9qjnQfYMYfT3RMQ4hEMgLR5K3X0jWgiIGknWio8T v78kxXzB/2RQmc8cKjXIEZ0KeSz2Qk1JGi11y1k= X-Google-Smtp-Source: APiQypJtkYhngwnz/TZ/3+sE5d5/j64SAPO247UD5pe4Jw8ObBDLd8E8GxkIm4kMoe7AY2RRblTsHAKnlXtcqQ48kbk= X-Received: by 2002:a05:6e02:141:: with SMTP id j1mr3204237ilr.100.1587131529823; Fri, 17 Apr 2020 06:52:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Fri, 17 Apr 2020 09:51:56 -0400 Message-ID: Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Marcin Wojtas Cc: freebsd-security@freebsd.org, Rafal Jaworowski Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 493cwC0q9cz3wtw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.37 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[182.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.37)[ip: (-5.99), ipnet: 209.85.128.0/17(-0.40), asn: 15169(-0.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 13:52:11 -0000 On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > Hi, > > Together with our customers, Semihalf is interested in improving the status > of security mitigations enablement in FreeBSD. Happy to hear that there's interest in this work! > 1. Are there any hard blockers, like missing features or bugs, that prevent > enabling ASLR by default in the kernel and building the base system with > -DWITH_PIE? I believe there are no showstopper issues but there are a some prerequisites. One is that there are some applications that may misbehave with randomization enabled. They would need to be identified, and tagged (with the elfctl tool now in the base system). > 2. In case the enablement becomes eventually approved, will it be better to > do it for all archs or focus only on the selected ones? There's a general and increasing preference of avoiding different defaults per architecture. One issue though is that some options may have much larger performance impacts on certain architectures - e.g. position independent executables (PIE) on i386. > 3. IMO it may be worth to benchmark/stress the system for the stability > verification and perf comparison purpose. Do you think it may be reasonable > to create a kind of reference matrix (archs vs tests)? Those could be done > to evaluate the current state of the OS, but also for validating each > proposed feature. I also think engaging the FreeBSD CI might be a huge help > in such an effort. BTW, any particular tests / benchmarks come to your mind > as useful in this case? Yes, benchmarking and testing are very important tasks on a path to enabling these by default. I agree with the CI comment; we should start with CI build + kyua runs with options turned on, in advance of changing the default. I would be interested in seeing macro-level benchmarking with mitigations on/off - for example, I assume Firefox must have a performance test suite that they use for tracking their own performance changes during development, and we could use benchmarks like that to see the impact of mitigations. Coming up with a full set of appropriate benchmarks will be a useful endeavour.