Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe

:w00t: congrats!

also lol @ google releasing Yet Another Build System

Adbot
ADBOT LOVES YOU

Captain Foo
May 11, 2004

we vibin'
we slidin'
we breathin'
we dyin'

YABS YABS YABS YABS

FlapYoJacks
Feb 12, 2009
Next up on the chopping block: Make Buildroot not suck with SELinux.

Buildroot actually has decent SELinux support already! Currently, if a package has a selinux/ directory inside of it, the build system builds the policies in the selinux/ directory with refpolicy. However, there are three issues:

1) No packages currently have selinux/ directories.
2) Several packages need policies to work properly in enforcing mode.
3) Policies are always applied even when using a custom git version of refpolicy, which explicitly states, "if you use this, you are on your own."

I submitted a patch to fix #3, and when applied, I will submit a good 10~ patches to fix 1 and 2. The end goal is that anyone, even without knowledge of SELinux, will be able to build a minimal system with enforcing turned on and have no denials in audit.log.

sb hermit
Dec 13, 2016





FlapYoJacks posted:

Next up on the chopping block: Make Buildroot not suck with SELinux.

Buildroot actually has decent SELinux support already! Currently, if a package has a selinux/ directory inside of it, the build system builds the policies in the selinux/ directory with refpolicy. However, there are three issues:

1) No packages currently have selinux/ directories.
2) Several packages need policies to work properly in enforcing mode.
3) Policies are always applied even when using a custom git version of refpolicy, which explicitly states, "if you use this, you are on your own."

I submitted a patch to fix #3, and when applied, I will submit a good 10~ patches to fix 1 and 2. The end goal is that anyone, even without knowledge of SELinux, will be able to build a minimal system with enforcing turned on and have no denials in audit.log.

selinux on embedded linux always feels like that one task that no one wants to do because you have to cover all use cases so that denials won’t get triggered

although I guess in this case, you can just run scenario tests for specific software and hope that covers it.

Or, more likely, people create selinux profiles based on the software they’re shipping because then any unused features may simply not work which significantly reduces the attack surface.

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe
Writing an SELinux policy for every package in Buildroot sounds like my definition of hell

Poopernickel fucked around with this message at 22:55 on Oct 9, 2023

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe
SELinux is kind of a trash fire overall though tbh

I just ship products with nonroot services and a bunch of systemd sandboxing. Nobody's hacked one of my designs yet :smug:

hobbesmaster
Jan 28, 2008

sb hermit posted:

Or, more likely, people create selinux profiles based on the software they’re shipping because then any unused features may simply not work which significantly reduces the attack surface.

since this is the embedded thread, isn’t this what should be happening? it almost feels like the entire concept of saying “add SELinux policies to buildroot/yocto” is missing the point and the request makes it sound like you don’t want SELinux in the first place

FlapYoJacks
Feb 12, 2009
There is a minimal amount of effort being put into this. Not every package will have an selinux policy. So far there is:

Busybox
OpenSSH
Systemd
Audit
SysVinit

and a few others. Most of the policies are one or two lines. It’s enough to get a minimal system going in enforcing mode, that everyone would have to do. Nothing more, nothing less.

sb hermit
Dec 13, 2016





hobbesmaster posted:

since this is the embedded thread, isn’t this what should be happening? it almost feels like the entire concept of saying “add SELinux policies to buildroot/yocto” is missing the point and the request makes it sound like you don’t want SELinux in the first place

I think SELinux is cool and good and a default or example policy would go a long way towards getting it adopted more widely.


FlapYoJacks posted:

There is a minimal amount of effort being put into this. Not every package will have an selinux policy. So far there is:

Busybox
OpenSSH
Systemd
Audit
SysVinit

and a few others. Most of the policies are one or two lines. It’s enough to get a minimal system going in enforcing mode, that everyone would have to do. Nothing more, nothing less.

yeah, this makes sense to me, although I figure busybox could easily be a bugbear if you really want to lock it down depending on what command is called (which starts to chip away at the spirit of busybox, in my opinion). Nevertheless, selinux on embedded is the lord’s work

FlapYoJacks
Feb 12, 2009

sb hermit posted:

I think SELinux is cool and good and a default or example policy would go a long way towards getting it adopted more widely.

yeah, this makes sense to me, although I figure busybox could easily be a bugbear if you really want to lock it down depending on what command is called (which starts to chip away at the spirit of busybox, in my opinion). Nevertheless, selinux on embedded is the lord’s work

Thanks! Buildroot also has an option to use a policy from git which disables any of the default buildroot policies. If you really want to get into the dirty nity-grity and make your own, you are free to do so!

FlapYoJacks
Feb 12, 2009
SELinux patches submitted. :getin:

outhole surfer
Mar 18, 2003

buildroot is simply the tits for kernel development

god i love being able to just build an efi binary with my target kernel and tests all bundled up

FlapYoJacks
Feb 12, 2009
Tons more flutter work going on. I also figured out how to get sway working in Buildroot. I need to submit patches because in it's current form it's completely useless.

Ciaphas
Nov 20, 2005

> BEWARE, COWARD :ovr:


our yocto image includes mariadb. is it possible to do first-time setup stuff like mariadb-install-db, setting a default password for root@localhost, etc. during image creation, instead of having to do it at first-boot on the target device?

Captain Foo
May 11, 2004

we vibin'
we slidin'
we breathin'
we dyin'

buildroot but in the australian sense

hobbesmaster
Jan 28, 2008

Ciaphas posted:

our yocto image includes mariadb. is it possible to do first-time setup stuff like mariadb-install-db, setting a default password for root@localhost, etc. during image creation, instead of having to do it at first-boot on the target device?

can you not just grab the files from a target after setup? if there is something device specific then you’ll need to do something on first boot.

outhole surfer
Mar 18, 2003

yocto, passing around binaries while yelling "look how reproducible i am!" since whenever the gently caress

outhole surfer
Mar 18, 2003

just split this binary file up into 5 chunks, and bam file is 100% reproducible. you just cat together the 5 chunks!

Ciaphas
Nov 20, 2005

> BEWARE, COWARD :ovr:


hobbesmaster posted:

can you not just grab the files from a target after setup? if there is something device specific then you’ll need to do something on first boot.
i could; but it's not device-dependent, so i was hoping to just make it part of the initial image instead of having to do an intermediate then final image like that

FlapYoJacks
Feb 12, 2009

Ciaphas posted:

I could; but it's not device-dependent, so I was hoping to just make it part of the initial image instead of having to do an intermediate and then the final image like that

In these situations, either on Buildroot or Yocto, it's preferable to set up the DB on a device, dump the contents, and stuff it in an overlay. Then, have a startup script check to see if the DB is initialized, and if not, initialize the DB by using the dumped contents from earlier. It's a pain in the rear end to set up, but it's the best way I have found. That, or you can make a ${insert_language_of_choice} program that does that for you, but then you may have passwords laying around in plain text on your system (unless compiled, but then you have the passwords in source code, which is also meh.)

Ciaphas
Nov 20, 2005

> BEWARE, COWARD :ovr:


FlapYoJacks posted:

In these situations, either on Buildroot or Yocto, it's preferable to set up the DB on a device, dump the contents, and stuff it in an overlay. Then, have a startup script check to see if the DB is initialized, and if not, initialize the DB by using the dumped contents from earlier. It's a pain in the rear end to set up, but it's the best way I have found. That, or you can make a ${insert_language_of_choice} program that does that for you, but then you may have passwords laying around in plain text on your system (unless compiled, but then you have the passwords in source code, which is also meh.)
i'm actually doing sort-of that already, except instead of extracting a previous dump the first-boot script runs the setup commands & queries then & there, including ALTER USER etc (so i have the default pw in plaintext, which is the real issue i've been trying to solve). i'd hoped bitbake could do it, like in a do_install:append() or a pkg_postinst:mariadb() in a mariadb_%.bbappend or something, and save the trouble of having to do first-time config on the device at all

(e) lol i suppose i could solve the pw part by putting the hash in the script instead of PASSWORD('blah'), now I think about it

Ciaphas fucked around with this message at 22:12 on Nov 27, 2023

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe

Ciaphas posted:

our yocto image includes mariadb. is it possible to do first-time setup stuff like mariadb-install-db, setting a default password for root@localhost, etc. during image creation, instead of having to do it at first-boot on the target device?

I'd recommend making a package called something like mariadb-bonerlord-settings or something. The package can have a DEPENDS on mariadb-native, and then you can run your setup in the do_compile() stage and package the outputs. Then you can add your new package to the image you're trying to build. Probably you want the package to inherit allarch so that it's marked as architecture-independent.

If you really want to do it in your image recipe, you can add a function to ROOTFS_POSTPROCESS_COMMAND and add this line to your image recipe:

do_image[depends] += "mariadb-native:do_populate_sysroot"

then you can use mariadb there instead of in a standalone settings package.

Poopernickel fucked around with this message at 03:45 on Nov 28, 2023

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe
actually, I think Yocto runs pkg_postinst scripts in QEMU as part of the normal image build-flow. So maybe you can just add an extra post-install script in a bbappend or something.

Poopernickel fucked around with this message at 03:45 on Nov 28, 2023

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe
Yocto: there are 23435901 ways to do it

hobbesmaster
Jan 28, 2008

Poopernickel posted:

actually, I think Yocto runs pkg_postinst scripts in QEMU as part of the normal image build-flow. So maybe you can just add an extra post-install script in a bbappend or something.

does it always do that? i wasn’t going to recommend that without knowing the target lol

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe

hobbesmaster posted:

does it always do that? i wasn’t going to recommend that without knowing the target lol

I think that's the standard flow these days, yeah. Yocto didn't always do that, but it's been true for the past couple of years. I wtfed about it the first time I noticed that qemu-native was being built along the path to core-image-minimal, and I went on a deep-dive to figure out why.

op, I'd recommend the "make a package that uses mariadb-native to create your files" approach more than anything else I suggested. It's the cleanest imo

Poopernickel fucked around with this message at 06:43 on Nov 28, 2023

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe

Ciaphas posted:

our yocto image includes mariadb. is it possible to do first-time setup stuff like mariadb-install-db, setting a default password for root@localhost, etc. during image creation, instead of having to do it at first-boot on the target device?

what did you wind up doing to solve this?

FlapYoJacks
Feb 12, 2009

Poopernickel posted:

what did you wind up doing to solve this?

Funny enough, back when I was an overworked, burnt out single man operation for an abusive company, I setup a postgresql server by running the disk image in qemu using a post image script. The script ran on first boot and self-deleted. Other than being a silly solution it worked fine. gently caress that company was otherwise.

Ciaphas
Nov 20, 2005

> BEWARE, COWARD :ovr:


Poopernickel posted:

what did you wind up doing to solve this?
I got shifted to other tasks and haven't had a chance to look again yet. i did try a pkg_postinst:mariadb() script but it didn't let me start the db up for reasons i don't remember

maybe it should have been pkg_postinst:mariadb-native(), i never quite remember which is which

Ciaphas
Nov 20, 2005

> BEWARE, COWARD :ovr:


yocto is a gently caress

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe
so I'm working on an embedded Linux product, and we need to build out a bunch of testbenches that we can use for running automated tests.

This is a hardware product, so each bench needs to have:
- External power supply (UART or ethernet control)
- Relay to connect some programming jumpers
- Debug serial UART cable
- Ethernet connection for SSH

I'll be supporting 20-30 testbenches, so I expect there will be some differences in stuff like "bench #17 has a USB-controlled power supply, and bench #3 has a ethernet-controlled power supply. Debug UART is on /dev/ttyUSB0 for bench #2, but /dev/ttyUSB2 for bench #4." etc.

How can I standardize these and provide a common interface to use in our test-suites? Is there anything out there that acts like "Hardware Abstraction Layer, but for testbench gear"?

sb hermit
Dec 13, 2016





ansible

sb hermit
Dec 13, 2016





bit of a shitpost answer though

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe

sb hermit posted:

bit of a shitpost answer though

Maybe not the right kind of thing. Ansible is an answer to "how do I manage a bunch of computers", but not really an answer to "how can I provide an abstraction around testbench hardware"

Like, I assume that step-1 of most of our test suites will be "download a build, flash it onto the target hardware, then reboot". Say I have some external gear that handles power-cycling the device-under-test. So maybe I want my test-suite to make calls like "start DUT power, set to +12V". But if "start DUT power" is implemented differently on different computers, then I need an abstraction layer of some kind.

I'm thinking something must already exist in this space - I can't believe that I have a unique problem here or anything.

Poopernickel fucked around with this message at 06:46 on Jan 2, 2024

sb hermit
Dec 13, 2016





Poopernickel posted:

Maybe not the right kind of thing. Ansible is an answer to "how do I manage a bunch of computers", but not really an answer to "how can I provide an abstraction around testbench hardware"

Like, I assume that step-1 of most of our test suites will be "download a build, flash it onto the target hardware, then reboot". Say I have some external gear that handles power-cycling the device-under-test. So maybe I want my test-suite to make calls like "start DUT power, set to +12V". But if "start DUT power" is implemented differently on different computers, then I need an abstraction layer of some kind.

I'm thinking something must already exist in this space - I can't believe that I have a unique problem here or anything.

Yeah, that’s what I figured. It’s just that I think you can start building the skeleton of the test framework with ansible, and use tags or other mechanisms to dynamically determine how to tailor the playbook for each specific bench type. (to be honest, I am not an ansible expert.) This doesn’t address how those differences can be better managed, I admit. On the other hand, if this is a configuration management problem, there may not be many other solutions that fit your vision and you may want to adjust accordingly.

So yeah. “ansible” is a shitpost answer.

You might want to try this question in the linux thread, see if you get better answers.

sb hermit
Dec 13, 2016





Pretty sure that other companies just use a hodgepodge of unreadable shell scripts with inscrutable timeout values and mainly written by one person who left six years ago and future changes were made by junior engineers in the interim.

Adbot
ADBOT LOVES YOU

Phobeste
Apr 9, 2006

never, like, count out Touchdown Tom, man

sb hermit posted:

Pretty sure that other companies just use a hodgepodge of unreadable shell scripts with inscrutable timeout values and mainly written by one person who left six years ago and future changes were made by junior engineers in the interim.

yeah op i think this is your competition. especially if you're not gonna have the juice to be able to have a specific design implemented like a product.

if you do have the juice for this, the right answer is definitely something like an SBC and a semicustom device tree that can force specific userspace bindings for things and then just write the software, a server/client or frontend/daemon architecture of some kind so you can manually control stuff if the ui doesn't present what you need. that's probably the right answer if you don't have the juice too you'll just have to abandon yourself to lots of config files keyed by machine type or some poo poo

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply