SamuraiWTF / samuraiwtf

The main SamuraiWTF collaborative distro repo.

Home Page:https://owasp.org/www-project-samuraiwtf/#SamuraiWTF_Project

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

New image for MBP M1 processors

Bl0ckbuster opened this issue · comments

We should look into building an image for the Macbook Pro M1 ARM processors - they're becoming more prevalent, and we've had a few students ask about them over the last few weeks.

commented

I did a little research into this. Looks like a challenge is that VBox only works on X86/64. To support M1 ARM macs, we'd need to target vmware Fusion and/or Parallels. Each comes with licensing costs, vmware Fusion itself comes at a cost, and its Vagrant provisioner is approximately the same cost again. Parallels maintains a Vagrant provisioner, so it's just the license cost of Parallels itself. At one point in the past, before we maintained a packer base box, I had Jenkins set up to generate a Parallels box and to convert a VBox (x86) build to Vmware (x86), but that was based on the Bento images, not our current custom one. Not sure what @elreydetoda has in place today that might be adapted to this.

Vagrant provisioner is approximately the same cost again.

HashiCorp's VMware vagrant plugin doesn't cost money amymore: https://developer.hashicorp.com/vagrant/docs/providers/vmware

Looks like a challenge is that VBox only works on X86/64.

Looks like they have a developer preview for vbox on M1/M2 chips: https://osxdaily.com/2022/10/22/you-can-now-run-virtualbox-on-apple-silicon-m1-m2/

Not sure what @elreydetoda has in place today that might be adapted to this.

Currently we don't really have any of this in place, I can have multiple build targets if we want but I've been doing Secure Ideas infra work and no one has mentioned this as a priority yet. (Especially since they're using AWS workspaces for most classes and @JGillam has talked about possibly migrating to an Amzn Linux or CentOS base instead (#172))

Also, I haven't done any research into the M1/M2 chips specifically, but from my understanding of hypervisor technology on that platform in general. I believe I'd need to install + build the distro out as an arm architecture in the VM, instead of it being installed as x86_64.

It probably would ensure better compatibility if it was built on a Mac device, but everything except Parallels (in theory) should be able to support from architecture emulation from an x86 box. Parallels I can use the old Mac mini (I got from you) to build the x86 option of parallels but I don't know about arm version for that.

If this is a priority that we want to support I'd love to do similar to what I did for our remote access machines (have a new VM build for every merge to main/master depending on the changes), but just need to know if that's wanted before working on it. If we wanted it fully automated, I'd probably also either need to be able to add GitHub self-hosted runners (or work with an admin to do that). That way the self-hosted runners pickup all the builds that need to be run per release. (This does potential introduce a chance for a security issue) Alternatively, like I mentioned in the Secure Ideas slack, we could leverage the nested virtualization for most builds and then self-hosted runners for the OSX stuff (don't know if they offer OSX images for those larger instances).


There's also a major rewrite for the bento project that just happened (within the past couple of months) that they migrated to use HCL2. While this technically doesn't prevent us from doing a build for now, since it's a pinned submodule, it will prevent us from getting future updates. I'm currently rethinking how I'm using the bento project with my personal Kali project (planning on that being my test area for other project) to hopefully sort out the kinks and then I can work on integrating that here.

Looks like Bento has a box they built for Ubuntu at least: chef/bento#1344 (comment)

(specifically for parallels)