Re: [9fans] risc-v port progress at IWP9

Re: [9fans] risc-v port progress at IWP9

[Romano]

[-- Attachment #1: Type: text/plain, Size: 4919 bytes --]

Like this? 
https://fqa.9front.org/fqa4.html#4.4

Igor made a post about his setup: https://9lab.org/plan9/thinkpad-t420s/

On Thu, Jun 5, 2025, at 2:11 PM, Frank D. Engel, Jr. wrote:
> The biggest issue I have with 9front or other Plan9 distribution on a laptop is the lack of local authentication upon startup; the OS just trusts that you are whoever you say you are when you boot the system.  If the laptop were stolen or something there is nothing to keep someone from getting in and accessing all of the data.
> 
> It is one thing to do that with a server that is locked in a secure closet (as was the expected situation for a Plan9 file server back when it was invented), but for an all-in-one portable system that is more of a problem.
> 
> Has anyone come up with a solution for drive encryption and forced password authentication upon boot yet, to make it more practical to use 9 directly on a laptop without creating as much of a concern?
> 
> 
> 
> On 6/5/25 07:35, Daniel Maslowski via 9fans wrote:
>> Yea the "another machine" part is the tough bit.
>> I travel a lot, and I usually have one laptop with me.
>> Ideally, I want to avoid having two machines, or even systems.
>> If I can use plan9port to compile the code, that would be ideal.
>> 
>> My currently planned portable setup would be
>> - Plan 9 in a VM, headless in the background 🧐
>> - mount 9p from my host machine ✨
>> - use the editor on my host machine 👩‍💻
>> - run a command to recompile 🚀
>> - (re)run the resulting binary in QEMU 🥳
>> 
>> I expected that to be simpler, and I do know that it's possible.
>> Just takes time to figure out, so I walk tiny steps every now and then and get back to other stuff most of the time. 🙃
>> 
>> On Wed, 4 Jun 2025, 23:27 Shawn Rutledge, <lists@ecloud.org> wrote:
>>> On Wed, Jun 04, 2025 at 06:05:26PM +0200, Daniel Maslowski via 9fans wrote:
>>> > I am still trying to get a working 9front setup so I can work on the port.
>>> 
>>> It's not hard: just dd the iso to a usb stick, boot with it, and see how
>>> much luck you have with getting the right video mode and a working network
>>> interface (reading the fqa about that), on whatever spare PC you want to
>>> try, before attempting to install. Don't like it? try another machine. ;-)
>>> And https://luksamuk.codes/posts/plan9-setup-rpi.html is a decent
>>> walkthrough of the next steps to get drawterm working etc., regardless
>>> whether you are using a raspberry pi or not.  A Pi 4 is actually a nice
>>> enough substitute for a PC, except for having to trust an SD card with the
>>> filesystem.
>>> 
>>> > We used Shawn's setup; I am not there yet.
>>> > 
>>> > The workflow was as follows:
>>> > On a Linux machine, QEMU is set up, and another machine running 9front with
>>> > Acme et al serves 9p.
>>> > Editing and recompiling in 9front and then (re)running in QEMU works fine
>>> > that way, but debugging was tedious.
>>> > On the Linux machine, we stepped through instructions via gdb, and had to
>>> > reverse lookup the corresponding function.
>>> > With acid on 9front, we could see the counterpart and come to conclusions.
>>> > Not ideal, but a start.
>>> 
>>> Yep that's how it was.  I recorded some of the gdb work in a typescript
>>> and took a few notes, so as not to forget everything.
>>> 
>>> My wife took me to visit her family for a couple of weeks, I only brought
>>> along one laptop (the Acer with 9front that I took to IWP9, but now
>>> dual-booting Arch as well) and I doubt I will have time for much hacking
>>> until after I get back on the 16th. I also don't know what I'm doing, but
>>> figured it might do me some good to learn the risc-v architecture a bit.
>>> 
>>> > So I have done a few related things now to help along:
>>> > 
>>> > - https://github.com/platform-system-interface/p9aout2elf a tool to convert
>>> > Plan 9 a.out to ELF (*with* symbols!); so far amd64 only, I'm working on
>>> > RISC-V 64
>>> > - https://github.com/radareorg/radare2/pull/24261 WIP support for Plan 9
>>> > RISC-V kernels in radare2
>>> > 
>>> > Those tools significantly help with debugging, so one gets to see the
>>> > symbols in gdb and radare2.
>>> 
>>> Cool.
>>> 
>>> It was educational working with you guys that day. Thanks.
>>> 
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription> Permalink <https://9fans.topicbox.com/groups/9fans/T2fa5d9bbce09411d-M0b1793a4afa4ff40629119e1>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T2fa5d9bbce09411d-Md2ea0cd86aec8bdf102e898d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 8212 bytes --]

Re: [9fans] risc-v port progress at IWP9

[Maht Lawless via 9fans]

Hi,

I am working on 2FA to access your account on login, but it's a couple
of weeks away.

But you could just enable a bios password if you worry about someone
just booting it up.

Currently I rely on them seeing a grey screen and thinking the laptop is broken



On Thu, Jun 5, 2025 at 10:41 PM Frank D. Engel, Jr. <fde101@fjrhome.net> wrote:
>
> The biggest issue I have with 9front or other Plan9 distribution on a laptop is the lack of local authentication upon startup; the OS just trusts that you are whoever you say you are when you boot the system.  If the laptop were stolen or something there is nothing to keep someone from getting in and accessing all of the data.
>
> It is one thing to do that with a server that is locked in a secure closet (as was the expected situation for a Plan9 file server back when it was invented), but for an all-in-one portable system that is more of a problem.
>
> Has anyone come up with a solution for drive encryption and forced password authentication upon boot yet, to make it more practical to use 9 directly on a laptop without creating as much of a concern?
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T2fa5d9bbce09411d-M02070a23f0f9fb02ce3bf622
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] risc-v port progress at IWP9

[Ron Minnich]

Daniel and Shawn made good progress on the risc-v port, and their
experience reminded me of a standard test I used to use while doing
ports.

long story short, for blue gene and other ports (early amd64) we added
this test in main

ulong x = 0x12345678;

main()
{
    if (x != 0x12345678) panic("unaligned data"):

...


how can this test fail? x is in the data segment, but the immediate in
the test is in the text segment. This test is a quick and easy way to
check if your data segment is correctly loaded in memory.

In some ports, the data is aligned by code in l.s that moves it.

There are some really nasty, confusing errors that will arise in a
seemingly working kernel if data is not aligned.

I always add this test when I'm doing a port. It catches a problem
that is otherwise very confusing, and presents as strings  not set up
right, variables wrong, etc.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T2fa5d9bbce09411d-Mbe56005ac5604a0fe2a1b41c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] risc-v port progress at IWP9

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

that reminds me that the first kernel-level program i ran on new ports was
wump (hunt the wumpus),
partly to debug similar effects, but also because it's fun if not just silly

On Thu, 29 May 2025 at 22:05, Ron Minnich <rminnich@p9f.org> wrote:

> Daniel and Shawn made good progress on the risc-v port, and their
> experience reminded me of a standard test I used to use while doing
> ports.
> 
> long story short, for blue gene and other ports (early amd64) we added
> this test in main
> 
> ulong x = 0x12345678;
> 
> main()
> {
>     if (x != 0x12345678) panic("unaligned data"):
> 
> ...
> 
> how can this test fail? x is in the data segment, but the immediate in
> the test is in the text segment. This test is a quick and easy way to
> check if your data segment is correctly loaded in memory.
> 
> In some ports, the data is aligned by code in l.s that moves it.
> 
> There are some really nasty, confusing errors that will arise in a
> seemingly working kernel if data is not aligned.
> 
> I always add this test when I'm doing a port. It catches a problem
> that is otherwise very confusing, and presents as strings  not set up
> right, variables wrong, etc.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T2fa5d9bbce09411d-M0d096182de1b987e8ea4146d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2784 bytes --]

Re: [9fans] risc-v port progress at IWP9

[Charles Forsyth]

[-- Attachment #1.1: Type: text/plain, Size: 1756 bytes --]

copy attached
uncluttered by extensions
apparently ken thompson did the C version for unix (i just added the types),
which makes it an appropriate test for a new compiler and then kernel port.


On Thu, 29 May 2025 at 22:35, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> that reminds me that the first kernel-level program i ran on new ports was
> wump (hunt the wumpus),
> partly to debug similar effects, but also because it's fun if not just
> silly
>
> On Thu, 29 May 2025 at 22:05, Ron Minnich <rminnich@p9f.org> wrote:
>
>> Daniel and Shawn made good progress on the risc-v port, and their
>> experience reminded me of a standard test I used to use while doing
>> ports.
>> 
>> long story short, for blue gene and other ports (early amd64) we added
>> this test in main
>> 
>> ulong x = 0x12345678;
>> 
>> main()
>> {
>>     if (x != 0x12345678) panic("unaligned data"):
>> 
>> ...
>> 
>> how can this test fail? x is in the data segment, but the immediate in
>> the test is in the text segment. This test is a quick and easy way to
>> check if your data segment is correctly loaded in memory.
>> 
>> In some ports, the data is aligned by code in l.s that moves it.
>> 
>> There are some really nasty, confusing errors that will arise in a
>> seemingly working kernel if data is not aligned.
>> 
>> I always add this test when I'm doing a port. It catches a problem
>> that is otherwise very confusing, and presents as strings  not set up
>> right, variables wrong, etc.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T2fa5d9bbce09411d-M20971a617edcf1e37d4cf92f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #1.2: Type: text/html, Size: 3410 bytes --]

[-- Attachment #2: wump.c.gz --]
[-- Type: application/gzip, Size: 2562 bytes --]