In D27666#744939, @emaste wrote:As a result, although the tests on 32-bit architectures with ASLR enabled were
mostly on par with what was observed on 64-bit ones, the defaults for the
former are not changed. Also, for the sake of safety keep the feature disabled for 32-bit
executables on 64-bit machines, too.I might write are not changed at this time to suggest this is not necessarily a final decision (in fact, it's not really a decision at all, 32-bit is probably not relevant enough to spend much effort on).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Nov 15 2021
Nov 15 2021
As a result, although the tests on 32-bit architectures with ASLR enabled were
mostly on par with what was observed on 64-bit ones, the defaults for the
former are not changed. Also, for the sake of safety keep the feature disabled for 32-bit
executables on 64-bit machines, too.
In D27666#744905, @kib wrote:Yes, leave it. I think it is verbose but explicit so that more people can notice that if pointed to.
Yes, leave it. I think it is verbose but explicit so that more people can notice that if pointed to.
In D27666#744903, @kib wrote:I suggest also dropping the
In case any change in the OS behavior is observed, that can be possibly caused by this patch, it is recommended to use freebsd-bugs@freebsd.org mailing list for reporting and discussing the encountered issue. Also,wording.
I suggest also dropping the
In case any change in the OS behavior is observed, that can be possibly caused by this patch, it is recommended to use freebsd-bugs@freebsd.org mailing list for reporting and discussing the encountered issue. Also,
wording.
Nov 12 2021
Nov 12 2021
I think it is better to provide short and concise list of potential issues with ASLR, like this:
- changed ABI due to modified layout of address space
- address space fragmentation
- non-reproducable address space layout between runs
- harder debugging
- some debuggers automatically disable ASLR for spawned targets, making target' environment different between debug and non-debug runs
Nov 4 2021
Nov 4 2021
assume it's a draft until proper tests are in progress
alfredo retitled D32838: powerpc64: add default boot option to enable autoboot from draftpowerpc64: add default boot option to enable autoboot to [draft] powerpc64: add default boot option to enable autoboot.
Limit setting of __elfN(pie_aslr_enabled) for only 64-bit PIE binaries.
LGTM. Would be good to add arm group for review and smoke test this change
Nov 3 2021
Nov 3 2021
Nov 2 2021
Nov 2 2021
Nov 1 2021
Nov 1 2021
correct comments wording
Oct 29 2021
Oct 29 2021
address reviewer comments
addresses commiter's suggestions
Hi! Any comments/remarks to the updated version?
Oct 25 2021
Oct 25 2021
Oct 23 2021
Oct 23 2021
Oct 22 2021
Oct 22 2021
Oct 18 2021
Oct 18 2021
In D27666#734447, @lattera-gmail.com wrote:In D27666#734443, @mw wrote:Hi,
I'm refreshing the discussion. The current status is following:
- Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.
It seems like a problem with the underlying AS{L}R implementation. HardenedBSD has not needed to make any changes to any application since it completed its PaX-inspired ASLR implementation in 2015. If applications experience issues with FreeBSD's AS{L}R implementation, it'd be safe to assume a problem with the AS{L}R implementation, not the application.
In D27666#734443, @mw wrote:Hi,
I'm refreshing the discussion. The current status is following:
- Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.
I'm refreshing the discussion. The current status is following:
- PIE enabled by default in 64-builds.
- Ports' exp-run issues are fixed (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214864)
- Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.
Oct 14 2021
Oct 14 2021
Oct 13 2021
Oct 13 2021
luporl retitled D29000: Export RGB offsets with FBIO_GETRGBOFFS from ofwfb: export RGB offsets with FBIO_GETRGBOFFS to Export RGB offsets with FBIO_GETRGBOFFS.
Oct 6 2021
Oct 6 2021
Initialize RGB offsets along with palette.
Sep 28 2021
Sep 28 2021
Address reviewer's comments
Sep 24 2021
Sep 24 2021
Sep 15 2021
Sep 15 2021
I tested this patch with D31232 few weeks ago on the Blackbird and it looks good to me once it's approved.
Sep 8 2021
Sep 8 2021
Sep 6 2021
Sep 6 2021
- Address reviewer's comments
Sep 4 2021
Sep 4 2021
Sep 3 2021
Sep 3 2021
In D31804#717525, @dim wrote:Let's do this for now to get the PowerPC builds working again. But also be aware that the bisected upstream commit is only exposing an underlying issue: most likely the root cause is in the PowerPC backend.
Sep 2 2021
Sep 2 2021
Let's do this for now to get the PowerPC builds working again. But also be aware that the bisected upstream commit is only exposing an underlying issue: most likely the root cause is in the PowerPC backend.
In D31698#715220, @fbsd-phab_maskray.me wrote:This is not suitable for the upstream. The root cause behind dso_local needs to be found and fixed.
alfredo retitled D31804: llvm: fix/workaround liblzma incorrect compress/uncompress from llvm: fix/workaround liblzma incorrect encode/decode to llvm: fix/workaround liblzma incorrect compress/uncompress.
Sep 1 2021
Sep 1 2021
Glad to see you solve the last piece of this puzzle!
Aug 27 2021
Aug 27 2021
fbsd-phab_maskray.me added a comment to D31698: powerpc64*: fix for broken binaries generated by llvm12.
This is not suitable for the upstream. The root cause behind dso_local needs to be found and fixed.
Aug 26 2021
Aug 26 2021
I wouldn't say "reverts LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a", but something like "amends LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a", as we're adding code here. But otherwise, LGTM!
alfredo retitled D31698: powerpc64*: fix for broken binaries generated by llvm12 from powerpc64*: fixfor broken binaries generated by llvm12 to powerpc64*: fix for broken binaries generated by llvm12.
Abandoned in favor of D31698
Aug 23 2021
Aug 23 2021
alfredo updated subscribers of D31646: powerpc64*: workaround for broken binaries generated with llvm12.
In D31646#713731, @emaste wrote:Move logic to BROKEN_OPTIONS as suggested by @jhibbits
This will work for src itself, but I think it won't work with ports that use /usr/share/mk?
Move logic to BROKEN_OPTIONS as suggested by @jhibbits
alfredo added a comment to D31646: powerpc64*: workaround for broken binaries generated with llvm12.
In D31646#713717, @emaste wrote:is there a PR to reference here?
alfredo updated the diff for D31646: powerpc64*: workaround for broken binaries generated with llvm12.
Move logic to BROKEN_OPTIONS as suggested by @jhibbits
is there a PR to reference here?
alfredo edited reviewers for D31646: powerpc64*: workaround for broken binaries generated with llvm12, added: luporl; removed: leandro.lupori_gmail.com.
alfredo requested review of D31646: powerpc64*: workaround for broken binaries generated with llvm12.
Aug 2 2021
Aug 2 2021
Jul 30 2021
Jul 30 2021
Great job luporl!
Jul 29 2021
Jul 29 2021
markmi_dsl-only.net abandoned D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..
I no longer have access to any operational old-PowerMacs. (And never had access to any other example types of PowerPC/Power hardware.) As such, I'll no longer be involved in powerpc64 or 32-bit powerpc activities.
Jul 23 2021
Jul 23 2021
This approach of auto detecting the correct frame buffer physical address based on Vendor ID looks good.
It would help to make FreeBSD graphics work out of the box for Blackbird and Talos II machines, instead of forcing the user to figure out the physical address of its VGA adapter and pass it to the kernel manually, or else the system just hangs.
Ideally, Petitboot should fix it on their side, but I don't know if it will happen anytime soon, since Linux isn't affected, because it just talks directly to ASPEED video device, instead of relying on the framebuffer info exposed in the device tree.
D31232 fixes OFWFB with radix. After it lands it should be safe to make radix default.
Jul 20 2021
Jul 20 2021
Jun 25 2021
Jun 25 2021
After discussion with @imp , we decided to try the "reroot" approach instead. It appears to be generic solution for other modules as well, and can be used on other platforms.
A new review entry will be created when it's ready for review.
Jun 17 2021
Jun 17 2021
Looks fine to me.
Jun 16 2021
Jun 16 2021
In D30793#692367, @imp wrote:That is, I'd rather see ZFS64
include GENERIC64 options ZFSetc
That is, I'd rather see ZFS64
include GENERIC64 options ZFS
etc
I'd really rather we didn't do this... I don't think it's a good idea....
Jun 11 2021
Jun 11 2021
May 10 2021
May 10 2021
May 7 2021
May 7 2021
May 4 2021
May 4 2021
May 1 2021
May 1 2021
It ended up being not entirely necessary due to the linker behavior of forcing required sections into whatever segment is a natural fit for them, unless we explicitly break it with /DISCARD/.
Is this still needed? We've had ifuncs for a year now, with no problems.
Apr 23 2021
Apr 23 2021
Seems to work fine on my G4.
Apr 20 2021
Apr 20 2021
Rebase against latest code.
Updating comments
bdragon retitled D29851: [PowerPC] Fix outdated FP regs on fork(2) and friends from [PowerPC] Fix outdated FP regs on fork() and friends to [PowerPC] Fix outdated FP regs on fork(2) and friends.