It's not that bad to do, some minor refactoring at worst (the installer already knows how to set up FAT partitions). What does need to happen is that we need decide where they get mounted, what files should go onto them, how updates work, etc. It's a policy issue rather than a technical one, and one we can easily fix after 11.

Thanks for the clarification. I'm a little worried about the VM case (it seems silly to have a 300 MB base system + a 200 MB EFI partition that is empty save for a single 75KB executable) but have no serious objection to this change.

Doesn't this still copy an 800K FAT partition onto the 200MB EFI partition? Doing that works, but it doesn't really seem to meet the goals here. It also wastes a ton of space on VMs. When we went with the 800K partition, the concept was that you could have multiple EFI partitions for such circumstances, which is allowed by the standard, or hand-manage it if you want to do multi-boot.

I would approve a patch that added this screen, but in such a way that it was accessed only from the menu at the end (like the "docsinstall" step) rather than something that comes up by default. It would also need a banner that the defaults on the screen are not the defaults for the system and so opening the menu and then pressing "OK" without modifying anything will change the configuration of the installed system.

Thanks! Please go ahead and commit.

Looks good to me.

In D6826#143867, @bdrewery wrote:

In D6826#143860, @robak wrote:

@bdrewery It's hard to answer to such question. In my opinion, they are not - they will only be applied if following conditions are met:

• user uses bsdinstall to perform fresh installation (so users of freebsd-update or customized isntallation methods, like scripts for jails unpacking base.txz and other, wont be affected)
• user goes through the installation steps of bsdinstall, automatically goes via hardening menu and accepts the proposed defauls - at this point user can freely mark/unmark every single option proposed to disable its application to the installation

If those are not met, then in every other case, those options wont be applied. The only way is via bsdinstall and acceptance of proposed defaults (just as with services menu and sshd for example) so, again, I think they're not forced on users - they're strongly proposed ;)

My question is only about using bsdinstall. I don't feel I'm getting the right answer yet. If I use bsdinstall and just click install and never go into the services/hardeneing sections will these be enabled by default? I see that the options are coded as default on, but does it require going into the hardening section to actually activate the defaults on them?

You say 'conditions not met' and 'not forced on users' but also say they have to 'accept the proposed defaults', of ON right?

In D6826#143840, @robak wrote:

@nwhitehorn I kindly disagree on making all options off by default, on several grounds:

• the idea is to promote existing technologies for securing the default FreeBSD installation, so once disabled by default, they wont have any real impact on security of 'default' installation since they'll become merely useful shortcuts for enabling some of the options. The idea is that once these settle down in 'defaut' installations thanks to that bsdinstall menu and proposed set of options, they will get turned on by default for 'real' and removed from bsdinstall (as they'll be obsolete by then).

This is a nice piece of code. However, we should make the defaults for everything be off: if you press enter all the way through the installer, you should get the same results as if you had run make installworld installkernel distribution DESTDIR=/whatever. Put another way, bsdinstall is one of several legitimate ways to install the operating system and the default settings for FreeBSD should not depend on your choice of installation mechanism.

I like that idea a lot. Unless you feel like you have time to do that soon, the interface shouldn't be the thing to block the commit.

I disagree strongly that convenience is more important than the security issue, which allows a way to install root kits. Fixing it only involves having boot1.efi check the partition type (and gptboot, if it does not already), which is not such a huge issue. That should definitely happen before this patch goes in.

I have no objections to this from the installer end. Thanks! I'll leave it to others to comment on the wireless aspects (and ultimately approve).

Aside from the issue with swap and root ordering, this looks mostly reasonable at first pass.

This will break a large number of systems. On large disks, the whole disk may not be accessible to the boot loader and it may not be able to find /. Moreover, some versions of loader(8) and earlier bootstrap code rely on the first UFS partition in nested MBR+label disks being /.

I will defer to Kostik on this one.

Looks good. In those drivers, though, why not use pmap_mapdev_attr()? Why do you need to change it later?

That makes sense, thanks. Where are you planning to use this that you want to unmap it? The function is intended for use only in early boot (UART consoles in particular) where you don't ever want to unmap the result. The patch itself looks good to me.

Why do you need this? I don't understand the description since OF_decode_addr() calls bus_space_map() internally.

Thanks! It would be good to get rid of it on PowerPC too. I think it is unnecessary, but I don't have the one board that has a fixup() routine and so can't test it, unfortunately.

This is getting there now! I have some inline replies to your comments.

Thanks! A couple comments inline. Mostly looks good to me at this point.

This is a great feature! Thanks for the work. There are three inline comments. Two are nits, but the third (about fstab) is a more complicated issue.

If it's just the config range that you need, it's a 5-line diff to this existing code to store that in the softc. Do you need more than that? I'd very much prefer to keep this code centralized than exploded into a dozen utility functions that are used in identical ways on four platforms.

Could you elaborate on what is different for ARM? I see only a one-line change that would be required.

Why not just move the existing PowerPC code and use it on other architectures by subclassing, as is done already there? Aside from the use of bs_le_tag at line 431, which could be fixed with one line of #ifdef, the existing code is 100% machine-independent.

The use case when installing multiuser is not that uncommon and is something that needs to continue working. One of two things needs to happen here before being committed:
(a) it needs to use only those ZFS filesystems previously mounted
(b) the zfsboot script should use the ZFS support in partedit, which already works with umount

This looks good in general (though see inline comment about copyrights). The bus tag assignment (NOT_PCI stuff) seems a little odd to me, but I can't really think of anything better and that API is not baked in by the change.

This is not a simplebus-specific thing. What should happen is something like OF_decode_addr() in /sys/powerpc/ofw/ofw_machdep.c (or exactly that function). In simplebus, the resource decoding using newbus allocation cascading to achieve this. Early boot (for UARTs) has different requirements and needs addresses cascaded all the way to CPU space. OF_decode_addr() is mostly not MD and I think would work as-is on ARM. You can see how it is used in uart_cpu_powerpc.c.

This definitely fixes a bug (though see comment about OF_searchencprop() above). Could you make a call for testing on the powerpc and sparc64 lists before committing? I worry this might break those systems if code there is relying on the bug. It at least will work on one Apple PowerPC system, so that's promising.

I think the main function is good and should be in dev/ofw. What are the other ones for?

That wasn't really my question: I was wondering where, in the tree, you plan to use it. Parsing these lists is not very complicated in general, and where it is (see inline comment), I think this code won't actually work. It seems like not much actual code will be saved.

What code do you intend to use this in? The utility function is reasonable, so far as it goes, but it seems like a relatively specialized use case and I'm not sure that much code is saved in the consumers by centralizing this.

It might be better to call this "prepboot" or "chrpboot" or "paprboot", which are various names for the firmware that do this style of booting. Other PPC machines (notably, but not only, Apple hardware) have a completely different system. Otherwise, looks good to me.

On PPC, instead of a utility function, we have a common newbus base class that does this (powerpc/ofw/ofw_pci*). These remove 99% of the boilerplate from PCI bus drivers as well. I'd prefer that approach on ARM to new functions.