Menu
▾
▴
genode-main — [INACTIVE] Genode OS framework mailing list - use https://lists.genode.org/listinfo/users
This list is closed, nobody may subscribe to it.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(18) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(12) |
May
(7) |
Jun
(7) |
Jul
(22) |
Aug
(16) |
Sep
(3) |
Oct
(8) |
Nov
(1) |
Dec
|
| 2010 |
Jan
(44) |
Feb
(22) |
Mar
(30) |
Apr
(25) |
May
(24) |
Jun
(21) |
Jul
(12) |
Aug
(12) |
Sep
(27) |
Oct
(2) |
Nov
(2) |
Dec
|
| 2011 |
Jan
(7) |
Feb
(2) |
Mar
(91) |
Apr
(11) |
May
(46) |
Jun
(55) |
Jul
(19) |
Aug
(12) |
Sep
(21) |
Oct
(9) |
Nov
(5) |
Dec
(43) |
| 2012 |
Jan
(41) |
Feb
(44) |
Mar
(47) |
Apr
(6) |
May
(51) |
Jun
(13) |
Jul
(88) |
Aug
(29) |
Sep
(31) |
Oct
(52) |
Nov
(42) |
Dec
(42) |
| 2013 |
Jan
(184) |
Feb
(25) |
Mar
(66) |
Apr
(85) |
May
(63) |
Jun
(41) |
Jul
(66) |
Aug
(44) |
Sep
(12) |
Oct
(53) |
Nov
(56) |
Dec
(77) |
| 2014 |
Jan
(92) |
Feb
(29) |
Mar
(75) |
Apr
(82) |
May
(60) |
Jun
(78) |
Jul
(52) |
Aug
(63) |
Sep
(103) |
Oct
(88) |
Nov
(120) |
Dec
(109) |
| 2015 |
Jan
(163) |
Feb
(69) |
Mar
(94) |
Apr
(109) |
May
(144) |
Jun
(75) |
Jul
(111) |
Aug
(31) |
Sep
(162) |
Oct
(115) |
Nov
(90) |
Dec
(88) |
| 2016 |
Jan
(114) |
Feb
(72) |
Mar
(80) |
Apr
(32) |
May
(49) |
Jun
(104) |
Jul
(94) |
Aug
(54) |
Sep
(94) |
Oct
(36) |
Nov
(20) |
Dec
(86) |
| 2017 |
Jan
(71) |
Feb
(33) |
Mar
(89) |
Apr
(89) |
May
(62) |
Jun
(103) |
Jul
(56) |
Aug
(62) |
Sep
(39) |
Oct
(59) |
Nov
(50) |
Dec
(49) |
| 2018 |
Jan
(105) |
Feb
(86) |
Mar
(105) |
Apr
(48) |
May
(11) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Stefan K. <ste...@ge...> - 2022-11-17 10:31:45
|
Hello, thanks to the initiative of the people from the Unikraft project, the traditional "microkernel and component-based os" devroom will take place at FOSDEM 2023. This time it is a non-virtual event on-site in Brussels. If you're interested in giving a talk, or to read more details, please have a look into the call for participation below. Regards Stefan Kalkowski ----- Forwarded message from Razvan Deaconescu <ra...@gm...> ----- Date: Thu, 10 Nov 2022 05:30:43 +0200 From: Razvan Deaconescu <ra...@gm...> To: FOSDEM Devroom Managers <dev...@li...>, FOSDEM <fo...@li...> Cc: Simon Kuenzer <sku...@un...> Subject: [FOSDEM] [devroom-managers] Call for Participation: Microkernel and Component-based OS Devroom 2023 FOSDEM 2023 In Person – Microkernel and Component-based OS DevRoom Call for Participation! The twenty-third edition will take place Saturday 4th and Sunday 5th February 2023 in Brussels, Belgium. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-based, unikernel-based, component-based operating systems and similar topics. Key dates / New updates - Conference dates 4-5 February, 2023 In person - Microkernel and Component-based OS DevRoom date: Sunday, February 5, 2023 - Submission deadline: Friday, December 2, 2022 - Announcement of selected talks: Thursday, December 15, 2022 - You must be available in person to present your talk - Talk submissions should be 30 mins and this should include Q&A time. DEVROOM TOPICS Possible topics of the devroom include, but are not limited to: - introduction of a specific OS or framework - design of subsystems and the general architecture of an OS - languages, tools and toolchains used - enabling support for hardware (architectures, device drivers) and programming languages - development processes, debugging - maintenance, testing and release engineering - safety, security and robustness - trends and challenges - research and open questions - community and governance - use cases, experiences and status updates - best practices and lessons learned - demos ABOUT THE DEVROOM Since the first Microkernel OS Devroom at FOSDEM 2012, this devroom has been a part of each following FOSDEM (with slight variations of the name). The focus gradually widened to include component-based, unikernel-based and other operating systems. By now, it has become a somewhat institutionalized tradition for the open source operating systems community and it is one of the few places where microkernel / unikernel enthusiasts and people with different views on how operating systems should work meet regularly. To this date, over a dozen projects have participated in one way or another. Many of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. HOW TO SUBMIT A TALK - Head to the FOSDEM 2023 Pentabarf website: https://penta.fosdem.org/submission/FOSDEM23 - If you already have a Pentabarf account, please don’t create a new one. - If you forgot your password, reset it. - Otherwise, follow the instructions to create an account. - Once logged in, select “Create Event” and click on “Show All” in the top right corner to display the full form. - Your submission must include the following information: - First and last name / Nickname (optional)/ Image - Email address - Mobile phone number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) - Title and subtitle of your talk (please be descriptive, as titles will be listed with ~500 from other projects) - Track: Select "Microkernel and Component-based OS DevRoom" as the track - Event type: Lecture (talk) - Persons: Add yourself as the speaker with your bio - Description: Abstract (required)/ Full Description (optional) - Links to related websites / blogs etc. - Beyond giving us the above, let us know if there’s anything else you’d like to share as part of your submission – Twitter handle, GitHub activity history – whatever works for you. We especially welcome videos of you speaking elsewhere, or even just a list of talks you have done previously. First time speakers are, of course, welcome! - For issues with Pentabarf, please contact myself or Simon. If you need to get in touch with the organisers or program committee of the Microkernel and Component-based OS DevRoom, contact me or Simon: * Razvan: ra...@un... * Simon: sku...@un... Razvan Deaconescu, Simon Kuenzer - Microkernel and Component-Based OS DevRoom Co-Organizers FOSDEM website: https://fosdem.org/2023/ FOSDEM code of conduct: https://fosdem.org/2023/practical/conduct/ Razvan, Simon _______________________________________________ FOSDEM mailing list FO...@li... https://lists.fosdem.org/listinfo/fosdem ----- End forwarded message ----- -- Stefan Kalkowski Genode labs https://github.com/skalk | https://genode.org |
|
From: Christian H. <chr...@ge...> - 2018-05-14 12:50:32
|
Hello, as announced by Stefan this list is closed as of today. Please subscribe to our new mailing list with the details below. The mailing list archive https://lists.genode.org/pipermail/users/ also contains the complete history from this list. Regards -- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth On Fri, May 04, 2018 at 01:57:19PM +0200, Stefan Kalkowski wrote: > Dear Genode list subscribers, > > for quite some time, we thought about moving our mailing list away > from Sourceforge. The inability to turn of advertisement, > the automated mass-unsubscription Sourceforge proceeded last year, and > most importantly: mails were not processed for days frequently. > > Therefore, we have installed our own mailing list infrastructure at > lists.genode.org. Unfortunately, it is impossible for us to gain the > currently subscribed users of this list. That is why, we cannot simply > portage your e-mail addresses from one list to the other. > > We like to encourage you to subscribe to the new list at your earliest > convenience, here: > > https://lists.genode.org/listinfo/users > > From now on, postings shall be done to the new list's address that is: > > us...@li... > > The mail archive is now located at: > > https://lists.genode.org/pipermail/users/ > > The current "genode-main" mailing list will get turned off at Monday, > May 14, 2018. > > We apologize for the inconvenience! > > Best regards > Stefan > > -- > Stefan Kalkowski > Genode labs > > https://github.com.skalk | https://genode.org |
|
From: Johannes K. <kli...@co...> - 2018-05-13 11:57:19
|
Hi Martin, thanks for your feedback. I didn't expect such a widespread interest and unfortunately I won't be able to set up a stream in the short term. But I will take it into consideration next time ;) Regards, Johannes Am 10.05.2018 um 20:31 schrieb Martin Iturbide: > Hi > > I'm very far away but I wish you good luck with it. If I were there I > would live stream it :) > > Regards. > > El mié., 9 de may. de 2018 04:27, Johannes Kliemann > <kli...@co... <mailto:kli...@co...>> escribió: > > Hi Genode folks, > > since the Information in my last email was a bit scarce here is a short > follow up to my defence. > > My thesis is based on the Microkernelizing Linux challenge of Genodes > challenges [1]. > > > Thanks to Genode's generic interfaces for I/O access as provided > by core, all Genode device drivers including drivers ported from > Linux and gPXE can be executed as user-level components on all > supported microkernels. However, so far, we have not enabled the use > of these device drivers on Linux as base platform. The goal of this > project is the systematic replacement of in-kernel Linux device > drivers by Genode processes running in user space, effectively > reducing the Linux kernel to a runtime for Genode's core process. > But moving drivers to Genode processes is just the beginning. By > employing further Genode functionality such as its native GUI, lwIP, > and Noux, many protocol stacks can effectively be removed from the > Linux kernel. > > > > The goal of this project is to evaluate how small the Linux kernel > can get when used as a microkernel. > > I will present the the implemented concepts for native Genode drivers on > Linux and a demo running on base-linux with a stripped down Linux kernel > using the native fb_boot_drv and ps2_drv. > > Location: Andreas-Pfitzmann-Bau, Nöthnitzer Str. 46 > 01187 Dresden, Germany; Room 3105 > > Time: Monday, May 14, 2018 at 11:00 a.m > > Regards, > Johannes Kliemann > > [1]: https://genode.org/about/challenges > > Am 25.04.2018 um 10:18 schrieb Johannes Kliemann: > > > >> Hello Genode folks, > >> > >> I want to invite you to the defence of my student thesis > >> "Microkernelization of Linux" (and enabling native Genode driver > support > >> on base-linux). > >> It will take place in the Andreas-Pfitzmann-Bau room 3105 at 11:00. > > At the 14th May 2018. > > > >> Regards, > >> Johannes Kliemann > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > genode-main mailing list > > gen...@li... > <mailto:gen...@li...> > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > genode-main mailing list > gen...@li... > <mailto:gen...@li...> > https://lists.sourceforge.net/lists/listinfo/genode-main > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > genode-main mailing list > gen...@li... > https://lists.sourceforge.net/lists/listinfo/genode-main > |
|
From: Duss P. <pi...@tr...> - 2018-05-11 13:12:49
|
Spam detection software, running on the system "obelix.duss.local",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
root@localhost for details.
Content preview: Hello Is there a way to send an ACPI power off event to a
running guest to shut it down? I searched the issues and wasn't able to find
anything about it.
Content analysis details: (8.7 points, 5.5 required)
pts rule name description
---- ---------------------- --------------------------------------------------
2.9 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split
IP)
0.2 CK_HELO_GENERIC Relay used name indicative of a Dynamic Pool or
Generic rPTR
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[83.77.14.147 listed in dnsbl.sorbs.net]
3.6 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[83.77.14.147 listed in zen.spamhaus.org]
1.6 RCVD_IN_BRBL_LASTEXT RBL: No description available.
[83.77.14.147 listed in bb.barracudacentral.org]
0.4 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
|
|
From: Martin I. <mar...@gm...> - 2018-05-10 18:32:06
|
Hi I'm very far away but I wish you good luck with it. If I were there I would live stream it :) Regards. El mié., 9 de may. de 2018 04:27, Johannes Kliemann <kli...@co...> escribió: > Hi Genode folks, > > since the Information in my last email was a bit scarce here is a short > follow up to my defence. > > My thesis is based on the Microkernelizing Linux challenge of Genodes > challenges [1]. > > > Thanks to Genode's generic interfaces for I/O access as provided by > core, all Genode device drivers including drivers ported from Linux and > gPXE can be executed as user-level components on all supported > microkernels. However, so far, we have not enabled the use of these device > drivers on Linux as base platform. The goal of this project is the > systematic replacement of in-kernel Linux device drivers by Genode > processes running in user space, effectively reducing the Linux kernel to a > runtime for Genode's core process. But moving drivers to Genode processes > is just the beginning. By employing further Genode functionality such as > its native GUI, lwIP, and Noux, many protocol stacks can effectively be > removed from the Linux kernel. > > > > The goal of this project is to evaluate how small the Linux kernel can > get when used as a microkernel. > > I will present the the implemented concepts for native Genode drivers on > Linux and a demo running on base-linux with a stripped down Linux kernel > using the native fb_boot_drv and ps2_drv. > > Location: Andreas-Pfitzmann-Bau, Nöthnitzer Str. 46 > 01187 Dresden, Germany; Room 3105 > > Time: Monday, May 14, 2018 at 11:00 a.m > > Regards, > Johannes Kliemann > > [1]: https://genode.org/about/challenges > > Am 25.04.2018 um 10:18 schrieb Johannes Kliemann: > > > >> Hello Genode folks, > >> > >> I want to invite you to the defence of my student thesis > >> "Microkernelization of Linux" (and enabling native Genode driver support > >> on base-linux). > >> It will take place in the Andreas-Pfitzmann-Bau room 3105 at 11:00. > > At the 14th May 2018. > > > >> Regards, > >> Johannes Kliemann > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > genode-main mailing list > > gen...@li... > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > genode-main mailing list > gen...@li... > https://lists.sourceforge.net/lists/listinfo/genode-main > |
|
From: Johannes K. <kli...@co...> - 2018-05-09 09:26:59
|
Hi Genode folks, since the Information in my last email was a bit scarce here is a short follow up to my defence. My thesis is based on the Microkernelizing Linux challenge of Genodes challenges [1]. > Thanks to Genode's generic interfaces for I/O access as provided by core, all Genode device drivers including drivers ported from Linux and gPXE can be executed as user-level components on all supported microkernels. However, so far, we have not enabled the use of these device drivers on Linux as base platform. The goal of this project is the systematic replacement of in-kernel Linux device drivers by Genode processes running in user space, effectively reducing the Linux kernel to a runtime for Genode's core process. But moving drivers to Genode processes is just the beginning. By employing further Genode functionality such as its native GUI, lwIP, and Noux, many protocol stacks can effectively be removed from the Linux kernel. > > The goal of this project is to evaluate how small the Linux kernel can get when used as a microkernel. I will present the the implemented concepts for native Genode drivers on Linux and a demo running on base-linux with a stripped down Linux kernel using the native fb_boot_drv and ps2_drv. Location: Andreas-Pfitzmann-Bau, Nöthnitzer Str. 46 01187 Dresden, Germany; Room 3105 Time: Monday, May 14, 2018 at 11:00 a.m Regards, Johannes Kliemann [1]: https://genode.org/about/challenges Am 25.04.2018 um 10:18 schrieb Johannes Kliemann: > >> Hello Genode folks, >> >> I want to invite you to the defence of my student thesis >> "Microkernelization of Linux" (and enabling native Genode driver support >> on base-linux). >> It will take place in the Andreas-Pfitzmann-Bau room 3105 at 11:00. > At the 14th May 2018. > >> Regards, >> Johannes Kliemann > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > genode-main mailing list > gen...@li... > https://lists.sourceforge.net/lists/listinfo/genode-main > |
|
From: John J. K. <de...@al...> - 2018-05-06 20:17:29
|
On 05/04/2018 04:47 AM, Alexander Boettcher wrote: > Hi John, > > On 03.05.2018 17:47, John J. Karcher wrote: >> On 05/02/2018 07:42 AM, Alexander Boettcher wrote: >>> Ben & John, >>> >>> may you please try my branch [0] with the run/ahci_bench and run/lwip >>> scenarios and tell me whether this change anything for your setups ? >>> >>> Thanks, >>> >>> Alex. >>> >>> [0] https://github.com/alex-ab/genode/commits/acpica_ext >> Thanks Alex for all that work! >> >> Unfortunately, I am not advanced enough in Git or the new Genode build >> tools to know how to do this. Could you provide the commands needed to >> download/merge and build? (I have created a clean Sculpt EA tree, as >> described in the tutorial.) > never mind, I got it now tested myself and actually could fix it > differently for Genode as VM in Virtualbox [0]. The drivers > (sata/network) of Genode will run in Virtualbox in the upcoming Sculpt TC. > > Cheers, > > Alex. > > [0] https://github.com/genodelabs/genode/issues/2801 > Great news - can't wait to try it! |
|
From: Stefan K. <ste...@ge...> - 2018-05-04 11:57:32
|
Dear Genode list subscribers, for quite some time, we thought about moving our mailing list away from Sourceforge. The inability to turn of advertisement, the automated mass-unsubscription Sourceforge proceeded last year, and most importantly: mails were not processed for days frequently. Therefore, we have installed our own mailing list infrastructure at lists.genode.org. Unfortunately, it is impossible for us to gain the currently subscribed users of this list. That is why, we cannot simply portage your e-mail addresses from one list to the other. We like to encourage you to subscribe to the new list at your earliest convenience, here: https://lists.genode.org/listinfo/users >From now on, postings shall be done to the new list's address that is: us...@li... The mail archive is now located at: https://lists.genode.org/pipermail/users/ The current "genode-main" mailing list will get turned off at Monday, May 14, 2018. We apologize for the inconvenience! Best regards Stefan -- Stefan Kalkowski Genode labs https://github.com.skalk | https://genode.org |
|
From: Boris M. <bor...@nl...> - 2018-05-04 11:49:16
|
Hi all,
I experienced an issue while closing the laptop lid on some hp840
machines. I know you have not tested these laptops, but the behaviour is
really curious, so maybe you know better what might be going on.
* I am running the sculpt scenario from staging. Everything works
fine, until I close and open the lid of the laptop.
* When I reopen it, the current focused window still does its job.
However, when I switch the focus, for example by triggering the
leitzentrale on and off by pressing F12, nothing happens.
* I tried setting the report_rom to verbose. It shows the
global_keys_handler -> leitzentrale report is not updated by
pressing F12. However, in my leitzentrale window which is still
active I can type things, execute programs and view the log.
* This happened when the leitzentrale was on before I put the lid down
and up.
* When I put the leitzentrale off and focus my runtime (which is just
the fs runtime with a noux shell) before closing and opening the
lid, it also cannot change the focus and only the client that was
focused before closing the lid (the noux shell) receives input. F12
again does nothing.
* In fact I tried it with more complicated runtimes and all the time
only the component which had focus (in this case the leitzentrale)
still works, the other components cannot get focus or input events.
* Report_rom does not give me a focus-, hover-, or any other report
when I press a global key, hover over or click on any component,
including the focused component. For example, when I have
leitzentrale active, the log does not show any report updates when I
click or move the mouse. Starting and stopping a runtime works fine,
and the runtime gives a nice focus report (if I had focused that
runtime before). But pressing F12 does not disable the
leitzentrale_enabled flag (or gives any useful output).
* It happens both with the intel_fb_drv and the vesa driver. It does
not happen on a lenovo x250.
Somehow it seems that nitpicker fails to detect any input events
(whether from a USB device or the embedded ps2 pad+keyboard), though it
forwards those events that belong to the focused client correctly. What
could cause this?
What happens in the Genode components in the GUI stack when the lid is
opened or closed? When I run linux on that laptop I can close and open
it just fine.
--
Met vriendelijke groet / kind regards,
Boris Mulder
Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands
+31 35 631 3253 (office)
|
|
From: Alexander B. <ale...@ge...> - 2018-05-04 08:47:32
|
Hi John, On 03.05.2018 17:47, John J. Karcher wrote: > On 05/02/2018 07:42 AM, Alexander Boettcher wrote: >> >> Ben & John, >> >> may you please try my branch [0] with the run/ahci_bench and run/lwip >> scenarios and tell me whether this change anything for your setups ? >> >> Thanks, >> >> Alex. >> >> [0] https://github.com/alex-ab/genode/commits/acpica_ext > > Thanks Alex for all that work! > > Unfortunately, I am not advanced enough in Git or the new Genode build > tools to know how to do this. Could you provide the commands needed to > download/merge and build? (I have created a clean Sculpt EA tree, as > described in the tutorial.) never mind, I got it now tested myself and actually could fix it differently for Genode as VM in Virtualbox [0]. The drivers (sata/network) of Genode will run in Virtualbox in the upcoming Sculpt TC. Cheers, Alex. [0] https://github.com/genodelabs/genode/issues/2801 -- Alexander Boettcher Genode Labs http://www.genode-labs.com - http://www.genode.org Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth |
|
From: John J. K. <de...@al...> - 2018-05-03 15:47:32
|
On 05/02/2018 07:42 AM, Alexander Boettcher wrote: > > Ben & John, > > may you please try my branch [0] with the run/ahci_bench and run/lwip > scenarios and tell me whether this change anything for your setups ? > > Thanks, > > Alex. > > [0] https://github.com/alex-ab/genode/commits/acpica_ext Thanks Alex for all that work! Unfortunately, I am not advanced enough in Git or the new Genode build tools to know how to do this. Could you provide the commands needed to download/merge and build? (I have created a clean Sculpt EA tree, as described in the tutorial.) Thanks again! |
|
From: Alexander B. <ale...@ge...> - 2018-05-02 11:43:10
|
Hello, On 15.04.2018 00:13, John J. Karcher wrote: > On 04/12/2018 05:02 AM, Christian Helmuth wrote: >> Ben, >> >> On Thu, Apr 12, 2018 at 02:14:04AM -0600, Nobody III wrote: >>> What exactly are you referring to, and how do I do it? >> >> Unfortunately, you need to dig through the code, but if you dare it >> may be really rewarding. I'm neither the author of the Genode >> acpica-library port nor an expert in ACPICA at a whole, but find and >> grep yielded me some hints where to look at. >> >> So, navigate to repos/libports/src/lib/acpica and try to find some >> appropriate backend functions to instrument. This may not suffice, so >> you should also navigate to contrib/acpica-<hash>/src/lib/acpica and >> instrument source/components/executer/exregion.c >> (AcpiExSystemMemorySpaceHandler). To be honest, from this point it's >> up to you to invest more effort to get your platform running. >> >> Good luck > > Nobody, I am also interesting in looking at this code, with the goal of > getting networking to work in a VirtualBox client. (My main machine is > AMD-based, so I am interested in that also, but I like to do most of my > experimenting in a VM.) > > Unfortunately, I don't have much free time at the moment, but I can try > to assist your efforts as much as I can. I haven't worked on > driver-level code in years, but I don't mind shaking off the rust for a > good cause. ;^) > > If you post your discoveries / observations on this ML (or elsewhere, as > appropriate), I will do the same. Ben & John, may you please try my branch [0] with the run/ahci_bench and run/lwip scenarios and tell me whether this change anything for your setups ? Thanks, Alex. [0] https://github.com/alex-ab/genode/commits/acpica_ext -- Alexander Boettcher Genode Labs http://www.genode-labs.com - http://www.genode.org Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth |
|
From: Alexander B. <ale...@ge...> - 2018-04-25 18:47:00
|
Hello, On 24.04.2018 15:18, Boris Mulder wrote: > > Some observations: > > * The charge/discharge events do not work on the x250. > * On the hp840 connecting and deconnecting share the same data value. > * On both laptops, disconnecting and reconnecting the AC outlet only > triggers the ec report once, and doing it again does not produce a > report. Reconnecting AC a second time also seems to cause the charge > events to stop being reported on the hp840. > * The lid report only works on the hp840. > * The power button works on the hp840 and only works on the x250 if > you press it for a longer time (but not so long as to turn off the > device). > * Ideally, for some device, such as one of the above, we would like > all of these reports to be updated correctly. > > > I have some questions about this: > > * You mentioned in your issue about sculpt EA that the reports not > getting updated are a known issue. Do you have any plans of fixing > this in the future? We have not scheduled any work to address this. It may of course happen, either due to contract work or much spare time and willingness by whomever. > * Do you think solutions to this issue are going to be device > specific? Which parts are generally the same for different laptops? I don't know for sure, but I think yes. I suspect there will be vendor specific driver necessary if you have an embedded controller providing some of your requested features. Every notebook vendor seems like to have an own specific one, for which you will have to have some driver. To get and idea, look into the Thinkpad specific driver in the Linux kernel. > * Is the difference in handling of the events on these machines caused > by the acpica C code not supporting these machines, or by the Genode > code not supporting them? or both? We did not invested much time in getting it fully running on any Thinkpad at all - so we have no answer. Neither we can tell something about HP notebooks. The best experience we had with a FUJI notebook model for a customer. > * A workaround could be installing a timer and generating the initial > reports periodically. Do you think this would be worth implementing > or would fixing the problem be easier? Ideally, understanding the root cause and fixing it is the sane way. But if there is no time nor money for it, such quirk may help you of course. > * For device specific parts: suppose it works on your test setup, how > should we proceed to make it work on other hardware? I would try to re-read the ACPI specification and compare it against the implementation in the kernel. (How to react/interact on ACPI events called GPEs). Check that the events you expect are actually happening and visible to the kernel. If it does not look good, compare it to good traces, e.g. in the Linux kernel. (create traces, compare traces) Check the interplay between kernel and acpica library respectively our self-written acpica application. Are all events visible in the kernel also recognized by the acpica application ? Another step is to get hands on vendor specific documentation or implementation. Some vendors follow more closely the "ACPI-Defined Devices" (see ACPI spec) way, which our self-written acpica application effectively tries to support. Other vendor like to implement more functionality into their own embedded controller (EC) instead, as you have seen already. For such EC you will have to have an EC driver. We are happy about any contributions and volunteers it that direction. Cheers, -- Alexander Boettcher Genode Labs http://www.genode-labs.com - http://www.genode.org Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth |
|
From: Johannes K. <kli...@co...> - 2018-04-25 08:18:19
|
> Hello Genode folks, > > I want to invite you to the defence of my student thesis > "Microkernelization of Linux" (and enabling native Genode driver support > on base-linux). > It will take place in the Andreas-Pfitzmann-Bau room 3105 at 11:00. At the 14th May 2018. > Regards, > Johannes Kliemann |
|
From: Johannes K. <kli...@co...> - 2018-04-25 08:15:01
|
Hello Genode folks, I want to invite you to the defence of my student thesis "Microkernelization of Linux" (and enabling native Genode driver support on base-linux). It will take place in the Andreas-Pfitzmann-Bau room 3105 at 11:00. Regards, Johannes Kliemann |
|
From: Boris M. <bor...@nl...> - 2018-04-24 13:19:36
|
Hi all,
I tried diving into the acpica utility to check if I can make the state
reports work on some of our machines. Currently I am testing it on the
lenovo x250 and the hp 840 laptops.
However, I am not sure how and if to proceed here.
The current behaviour is as following:
When the machine starts up, it produces the reports of acpi_ac and
acpi_battery correctly. When I disconnect the power outlet, these
reports do not get updated. instead, I do get acpi_ec report updates on
some of the different events, such as connecting and disconnecting the
laptop to AC. These events have different values on the different laptops.
The ec report acpica produces on the hp840:
[init -> acpi_report_rom] report 'acpica -> acpi_ec'
[init -> acpi_report_rom] <acpi_ec>
[init -> acpi_report_rom] <ec>
[init -> acpi_report_rom] <data value="8"
count="36">triggered</data> <-- this is added on a charge up event
(it seems to trigger periodically when the battery is not full and AC is
connected
[init -> acpi_report_rom] <data value="9"
count="53"/> <-- this is added on a
charge down event (it seems to trigger periodically when the battery is
not full)
[init -> acpi_report_rom] <data value="6"
count="2"/> <-- AC connect/disconnect
event (this triggers once when disconnecting and once when connecting)
[init -> acpi_report_rom] </ec>
[init -> acpi_report_rom] </acpi_ec>
on the x250:
[init -> acpi_report_rom] report 'acpica -> acpi_ec'
[init -> acpi_report_rom] <acpi_ec>
[init -> acpi_report_rom] <ec>
[init -> acpi_report_rom] <data value="38"
count="1">triggered</data> <-- AC disconnect event (this triggers
once when disconnecting)
[init -> acpi_report_rom] <data value="77"
count="1"/> <-- AC connect event (this
triggers once when connecting)
[init -> acpi_report_rom] <data value="39"
count="1"/> <-- AC connect event (this
also triggers once when connecting)
[init -> acpi_report_rom] </ec>
[init -> acpi_report_rom] </acpi_ec>
Some observations:
* The charge/discharge events do not work on the x250.
* On the hp840 connecting and deconnecting share the same data value.
* On both laptops, disconnecting and reconnecting the AC outlet only
triggers the ec report once, and doing it again does not produce a
report. Reconnecting AC a second time also seems to cause the charge
events to stop being reported on the hp840.
* The lid report only works on the hp840.
* The power button works on the hp840 and only works on the x250 if
you press it for a longer time (but not so long as to turn off the
device).
* Ideally, for some device, such as one of the above, we would like
all of these reports to be updated correctly.
I have some questions about this:
* You mentioned in your issue about sculpt EA that the reports not
getting updated are a known issue. Do you have any plans of fixing
this in the future?
* Do you think solutions to this issue are going to be device
specific? Which parts are generally the same for different laptops?
* Is the difference in handling of the events on these machines caused
by the acpica C code not supporting these machines, or by the Genode
code not supporting them? or both?
* A workaround could be installing a timer and generating the initial
reports periodically. Do you think this would be worth implementing
or would fixing the problem be easier?
* For device specific parts: suppose it works on your test setup, how
should we proceed to make it work on other hardware?
--
Met vriendelijke groet / kind regards,
Boris Mulder
Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands
+31 35 631 3253 (office)
|
|
From: Stefan K. <ste...@ge...> - 2018-04-23 10:05:06
|
Hello Mauricio, On Thu, Apr 19, 2018 at 01:09:36PM -0700, Mauricio Gutierrez wrote: > Hello Stefan, > > Thank you for your answer. > > Ok, first I do not see how you can enforce the cache usage with > > respect to the normal world. As long as the cache is enabled, how do > > you confine memory access of the normal world when it's not asking > > for permission (via your smc call)? > > To me it looks like you want to close some covert channels by cache > > data usage/displacement? In that case, maybe it is more reasonable to > > circumvent usage of the cache by the secure world at all? > > > > It is not a side channel attack. The Cortex-A8 provides cache locking > mechanisms for the benefit of > real-time embedded systems. I am trying to prevent malicious users from > exploiting these to lock malicious > code in the normal world cache (to avoid memory introspection from the > Secure World) using TrustZone. > Which is why I am working with your OS framework. I see. > > There is a designated kernel/core page-table that can be used to add > > kernel mappings. Obviously, you are using some quite old Genode > > version, so I'm not sure how to do that in your case. Nowadays, I > > would add a designated static mapping to the core/kernel mappings in > > the "bootstrap" code for the corresponding board, e.g.: > > > > As far as I know, I have a fairly recent version of Genode (17.08). But > yes, now I am trying to > map NONSECURE_RAM memory to the Secure World so that it can access both > secure world and > normal world memory such that in SW there are VA translations that map to > PA's of NW. > Would adding another region in > repos/os/src/server/tz_vmm/spec/imx53/main.cc > <https://github.com/genodelabs/genode/blob/1e8689bafefe156429998c4f2f92ae982675c34c/repos/os/src/server/tz_vmm/spec/imx53/main.cc> > create > these > mappings in SW ie: > _m4if.set_region1(Trustzone::NON*SECURE_RAM_BASE*, > Trustzone::NONSECURE_RAM_SIZE); No, this region setting is about the TrustZone-affine Multi Master Multi Memory Interface, which controls access to physical memory dependent on the NS-bit. It has nothing to do with the MMU and cache, but sits "behind" them. > > Because attempting to have overlapping memory such as edditing > repos/base-hw/src/bootstrap/spec/imx53_qsb/platform_trustzone.cc > <https://github.com/genodelabs/genode/blob/ee4ee6a8ac91592065cbf7a96872a95acb926b17/repos/base-hw/src/bootstrap/spec/imx53_qsb/platform_trustzone.cc> > early_ram_regions(Memory_region{Trustzone::*SECURE_RAM_BASE*,Trustzone::SECURE_RAM_SIZE > + Trustzone::NONSECURE_RAM_SIZE}) > to have early ram region that encompass both secure and nonsecure is not > allowed > as far as I understand. I did not wanted you to add something to the (early_)ram_regions. Indeed, if you would do so the memory would be used by the secure world concurrently. I advised you to add it as a region to the core_mmio regions. In that case, a mapping is established, but no other code implicitly uses that memory. Anyway, I've overseen that core_mmio regions are mapped as uncached memory anyway. So that is no good opportunity in your case. Given your case, you might simply add a mapping within the bootstrap process to a designated virtual memory address of core. You can add an appropriated virtual address here: repos/base-hw/src/lib/hw/memory_map.h The mapping can be add in the Platform constructor of bootstrap. Have a look at existent code like: core_pd->map_insert(...). In doing so, you should use the page_flags "PAGE_FLAGS_KERN_DATA". > > However, once I do have these new virtual address translations, I am not > sure how to get the VA from a given PA. > VA -> PA I just use the ARM PAR register for translation, but the other way > still eludes me. > I know that linux provides virt_to_pys() and phys_to_virt() functions to > convert between the two. > In the Genode tz_vmm scenario, is there a phys_to_virt() (or equivalent > function) I can use to get > the virtual address that corresponds to a physical address? Or is there any > way I could implement it? We do not have a phys_to_virt translation function in our page-table implementation. Although, it would be possible to add that complexity, I do not see that you really need it. Given the physical memory address the normal world OS likes to lock into the cache, you can simply build the offset within the physical normal world memory and add that offset to the virtual start address of the mapping within the secure world kernel. I hope that clarifies your question, best regards Stefan > > Thank you, > > Mauricio > > > On Wed, Apr 11, 2018 at 2:42 AM, Stefan Kalkowski < > ste...@ge...> wrote: > > > Hi Mauricio, > > > > thank you for sharing your intention. > > > > On Tue, Apr 10, 2018 at 10:51:15PM -0700, Mauricio Gutierrez wrote: > > > Hello Stefan, > > > > > > Thank you for your reply. > > > > > > If you really need to execute code in monitor mode (I wonder why), I > > > > think it will be best to create an explicit interface on the > > > > kernel/core level that can be called from the VMM component, maybe an > > > > extensions of the VM session interface. > > > > > > > > I think it somehow depends on what you are trying to do. If your > > > > routine has to be called every time a secure monitor call was > > > > executed, it is better to handle that directly within the > > > > Vm::exception function. If you have a very special device that needs > > > > to be accessed from secure, privileged/monitor mode you should extend > > the > > > > interface of kernel/core. > > > > > > > > > > Indeed this is what I ended up doing. I have added some exception > > handling > > > in the default case > > > of the Vm::exception function for my smc call (#4) before it switches > > over > > > to user-level privilege. > > > > > > Your are welcome. Maybe, you can give us some insights why do you need > > > > to enter monitor mode at all? > > > > > > > > > > I am trying to make it so that the secure world can lock some normal > > world > > > physical memory into the cache. > > > For security reasons, I do not want to allow the normal word to do it so > > I > > > make an smc into secure world > > > passing the virtual address to load into cache. The secure world then > > uses > > > the VA to PA registers to get the > > > physical address and load the memory into the cache. Of course, the only > > > way this would work would be for > > > the cache entry to be tagged with an NS bit = 1. In order to do this, I > > > need to enter monitor mode so that I can > > > change the NS bit to 1 while remaining is secure world. This way I > > perform > > > the cache loading and locking on > > > behalf of the normal world while being able to check for consistency. The > > > issue I am facing now is that I get a > > > cpu exception 3 (Breakpoint) when I try to write to the given normal > > world > > > memory from secure world, > > > and I am not sure why. > > > > Ok, first I do not see how you can enforce the cache usage with > > respect to the normal world. As long as the cache is enabled, how do > > you confine memory access of the normal world when it's not asking > > for permission (via your smc call)? > > To me it looks like you want to close some covert channels by cache > > data usage/displacement? In that case, maybe it is more reasonable to > > circumvent usage of the cache by the secure world at all? > > > > Anyway, concerning your technical issue, I am not sure whether you > > count the cpu exception from 0 or 1, but however it does not > > correspond to a SMC or prefetch-abort exception. It is much more > > probable that you receive a data-abort when writing to access that > > memory. The first obvious reason is that you are using the wrong > > virtual address to access the normal world physical memory you like to > > access. Our kernel/core is not mapped one-by-one physical-to-virtual. > > Moreover, the normal world memory is not mapped at all into Genode's > > kernel. > > > > > > > > Right now I am trying to access the physical address by temporarily > > > disabling the mmu so PA = VA. > > > > This should not work in recent versions of our kernel, because as I > > wrote before the kernel binary is linked to a different virtual > > address region than its physical memory representation. That means, > > the kernel will fault immediately when disabling the MMU. > > > > > However, another method would be to create/edit a page table entry in the > > > secure world such that it > > > maps to the specified physical address, essentially creating world shared > > > memory. However, I am not > > > sure how I would do this in Genode. For example, in the Normal World > > linux > > > I could edit the paging global > > > directory, but in the Genode OS how could I make a PTE map to a given > > > physical address? > > > > There is a designated kernel/core page-table that can be used to add > > kernel mappings. Obviously, you are using some quite old Genode > > version, so I'm not sure how to do that in your case. Nowadays, I > > would add a designated static mapping to the core/kernel mappings in > > the "bootstrap" code for the corresponding board, e.g.: > > > > https://github.com/genodelabs/genode/blob/master/repos/base- > > hw/src/bootstrap/spec/imx53_qsb/platform_trustzone.cc#L38 > > > > as an example for the i.MX53 Quickstart board when used with > > TrustZone. The "core_mmio" regions here are static mappings always > > present in the kernel. When the normal world memory is to big, it > > might not fit into the virtual "core_mmio" region. Have a look at this > > file to check the kernel virtual memory regions: > > > > https://github.com/genodelabs/genode/blob/master/repos/base- > > hw/src/lib/hw/spec/32bit/memory_map.cc > > > > However, being in your position I would re-think the approach as a > > whole, before digging further down the rabbit hole ;-). > > > > Best regards > > Stefan > > > > > > > > Thank you, > > > > > > Mauricio > > > > > > > > > On Mon, Apr 9, 2018 at 2:36 AM, Stefan Kalkowski < > > > ste...@ge...> wrote: > > > > > > > Hi Mauricio, > > > > > > > > On Wed, Mar 28, 2018 at 07:48:43PM -0700, Mauricio Gutierrez wrote: > > > > > Hello, > > > > > > > > > > I have been doing some work with the Genode Trustzone VMM scenario > > on my > > > > > i.MX53 development board and I am having a bit of trouble > > understanding > > > > how > > > > > the SMC calls work between the normal and secure world. Online you > > talk > > > > > about how you implemented 6 calls in the modified normal world linux > > > > kernel > > > > > but in the main for the tz_vmm I only found 4 different cases in the > > > > > _handle_smc() function. In any case, I wanted to add my own call and > > was > > > > > able to add it and check that the required arguments are passed > > correctly > > > > > and everything so that part I think I understand. > > > > > > > > > > However, I need to do some of the handling in Monitor Mode and my > > > > > understanding was that an SMC would throw your into monitor mode but > > it > > > > > seems the handler operates in user mode? Since it is not privileged > > then > > > > I > > > > > am not able to call a "cps #22" to switch to monitor mode. In an > > earlier > > > > > thread I know you refer to the > > > > > > > > > > section "World switch between non-secure world and secure > > > > > > world" in http://genode.org/documentation/articles/trustzone. > > > > > > > > > > But I am still uncertain as to how I could get my case in > > _handle_smc() > > > > to > > > > > enter monitor mode so that I can play around with the NS bit without > > > > > leaving secure world. > > > > > > > > You are right, our virtual-machine monitor is an unprivileged > > > > user-level component. Because driving the normal world is not > > > > crucial to other components inside the secure world, there is no need > > > > to make them dependent on complex emulation/para-virtualization code > > inside > > > > the kernel. That is why the kernel contains a slim > > > > exception-vector-only functionality that is used to copy over the > > > > normal world state to the VMM user-level component. This > > > > exception-vector code is entered, e.g., when doing a "smc" call and > > > > can be found here: > > > > > > > > repos/base-hw/src/core/spec/arm_v7/trustzone/exception_vector.s > > > > > > > > That assembly code is the only code executed in monitor mode. In the > > > > end it switches to secure world's supervisor mode and enters the > > > > normal kernel routine. However, it hits subsequently some C++ VMM > > > > kernel object routine here: > > > > > > > > repos/base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc > > > > > > > > Namely, the Vm::exception function, which informs the kernel scheduler > > > > to exclude the normal world for now, and signals the VMM user-level > > > > component that the normal world's state changed. > > > > > > > > > I have been studying what happens when I call an smc, say "smc #4" > > from > > > > > normal world. But I have not been able to exactly pin point, where > > is the > > > > > entry point for such an exception in the Genode secure world call? > > What > > > > > exactly happens once I make that call to secure world and where I > > can I > > > > > find/follow the code? Is this covered somewhere in your book? > > > > > > > > > > I know about the mode_transitions.s file as well as the > > > > exception_vector.s > > > > > and vm.cc files in repos/base-hw/src/core/spec/arm_v7/trustzone, it > > > > seems > > > > > this is the entry point? But where does it go after we call the > > > > > nonsecure_to_secure transition? > > > > > > > > > > Most importantly, I need to understand where is the code operating in > > > > > monitor mode? Where does it end and where does it start? How can I > > tell? > > > > If > > > > > I needed to write at least some part of my smc handler in monitor > > mode > > > > > before it switches out, what is the best approach to doing that? > > > > > > > > > > > > > If you really need to execute code in monitor mode (I wonder why), I > > > > think it will be best to create an explicit interface on the > > > > kernel/core level that can be called from the VMM component, maybe an > > > > extensions of the VM session interface. > > > > > > > > I think it somehow depends on what you are trying to do. If your > > > > routine has to be called every time a secure monitor call was > > > > executed, it is better to handle that directly within the > > > > Vm::exception function. If you have a very special device that needs > > > > to be accessed from secure, privileged/monitor mode you should extend > > the > > > > interface of kernel/core. > > > > > > > > > I apologize for all the questions and would appreciate any help and > > > > > guidance you can provide. > > > > > > > > Your are welcome. Maybe, you can give us some insights why do you need > > > > to enter monitor mode at all? > > > > > > > > Best regards > > > > Stefan > > > > > > > > > > > > > > Thank you, > > > > > > > > > > Mauricio > > > > > > > > > ------------------------------------------------------------ > > > > ------------------ > > > > > Check out the vibrant tech community on one of the world's most > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > > _______________________________________________ > > > > > genode-main mailing list > > > > > gen...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > > > > > > > > > > -- > > > > Stefan Kalkowski > > > > Genode labs > > > > > > > > https://github.com.skalk | https://genode.org > > > > > > > > ------------------------------------------------------------ > > > > ------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > > > > genode-main mailing list > > > > gen...@li... > > > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > > > > > > > ------------------------------------------------------------ > > ------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > _______________________________________________ > > > genode-main mailing list > > > gen...@li... > > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > > > > -- > > Stefan Kalkowski > > Genode labs > > > > https://github.com.skalk | https://genode.org > > > > ------------------------------------------------------------ > > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > genode-main mailing list > > gen...@li... > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > genode-main mailing list > gen...@li... > https://lists.sourceforge.net/lists/listinfo/genode-main -- Stefan Kalkowski Genode labs https://github.com.skalk | https://genode.org |
|
From: Nobody I. <hun...@gm...> - 2018-04-22 08:47:13
|
I'm not sure whether that will work for a library that needs a blocking function call to load an image by calling a child process. It seems like I'd need another thread, unless Genode has coroutine-like behavior with RPC calls. On Sun, Apr 22, 2018, 1:03 AM Emery Hemingway <eh...@po...> wrote: > Hi Ben, > > The 'Genode' way would be not to block for RPC, but to only run the > component during RPC or signal handling. If you need a component to > execute between RPC calls then signal handlers would be the way to go. > A private signal handler can perform the operations you need and block > for RPC by returning from the signal handling function. If the > execution should resume after RPC, send a signal to the local signal > handler before finishing the RPC method. > > Cheers, > Emery > > On Sat, 21 Apr 2018 22:13:33 -0600 > Nobody III <hun...@gm...> wrote: > > > How do I get a component to wait for an RPC method to be called? Can > > I use a semaphore, or will that block RPC calls? Do I need a thread > > dedicated to handling RPC? If so, should I create a new > > Rpc_entrypoint and tell it to manage the Rpc_object? > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > genode-main mailing list > gen...@li... > https://lists.sourceforge.net/lists/listinfo/genode-main > |
|
From: Emery H. <eh...@po...> - 2018-04-22 07:03:06
|
Hi Ben, The 'Genode' way would be not to block for RPC, but to only run the component during RPC or signal handling. If you need a component to execute between RPC calls then signal handlers would be the way to go. A private signal handler can perform the operations you need and block for RPC by returning from the signal handling function. If the execution should resume after RPC, send a signal to the local signal handler before finishing the RPC method. Cheers, Emery On Sat, 21 Apr 2018 22:13:33 -0600 Nobody III <hun...@gm...> wrote: > How do I get a component to wait for an RPC method to be called? Can > I use a semaphore, or will that block RPC calls? Do I need a thread > dedicated to handling RPC? If so, should I create a new > Rpc_entrypoint and tell it to manage the Rpc_object? |
|
From: Nobody I. <hun...@gm...> - 2018-04-22 04:14:01
|
How do I get a component to wait for an RPC method to be called? Can I use a semaphore, or will that block RPC calls? Do I need a thread dedicated to handling RPC? If so, should I create a new Rpc_entrypoint and tell it to manage the Rpc_object? |
|
From: Nobody I. <hun...@gm...> - 2018-04-20 20:36:53
|
Currently, Genode's Slave API is designed to create child components and request services from them. However, it does not allow the parent component to provide services to the child. Making Genode::Slave::Policy::resolve_session_request() virtual would fix this. |
|
From: Josef S. <jos...@ge...> - 2018-04-20 13:25:27
|
Hello Pirmin, * Duss Pirmin <pi...@tr...> [2018-04-20 08:55:41 +0200]: > I have a notebook with two relatively small SSDs. To use the sculpt scenario > on it, I would like to use the two as one in a RAID 0 configuration. Is > there already a possibility to do this, or should I implement a block device > merger component that can be configured to join up multiple block sessions > in to one? So far there is no block stripe (RAID-0) component. I have, however, implemented a minimal block mirror (RAID-1) component [1], which could be extended to also support stripping (being able to just provide a nested RAID configuration, i.e., stripped mirror, and the component would figure out the rest would be nice but I will not have the time in the foreseeable future to implement it). [1] https://github.com/cnuke/genode/commit/31f1fc13e16 That being said, building a simple block stripe component from scratch is not hard and starting with multiple components and figuring out how to combine them afterwards (keeping them seperate or integrate them in one component) might be better than extending one prematurely. Regards, -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ |
|
From: Duss P. <pi...@tr...> - 2018-04-20 07:12:47
|
Hello all I have a notebook with two relatively small SSDs. To use the sculpt scenario on it, I would like to use the two as one in a RAID 0 configuration. Is there already a possibility to do this, or should I implement a block device merger component that can be configured to join up multiple block sessions in to one? Best regards Pirmin |
|
From: Mauricio G. <mag...@as...> - 2018-04-19 20:35:35
|
Hello Stefan, Thank you for your answer. Ok, first I do not see how you can enforce the cache usage with > respect to the normal world. As long as the cache is enabled, how do > you confine memory access of the normal world when it's not asking > for permission (via your smc call)? > To me it looks like you want to close some covert channels by cache > data usage/displacement? In that case, maybe it is more reasonable to > circumvent usage of the cache by the secure world at all? > It is not a side channel attack. The Cortex-A8 provides cache locking mechanisms for the benefit of real-time embedded systems. I am trying to prevent malicious users from exploiting these to lock malicious code in the normal world cache (to avoid memory introspection from the Secure World) using TrustZone. Which is why I am working with your OS framework. There is a designated kernel/core page-table that can be used to add > kernel mappings. Obviously, you are using some quite old Genode > version, so I'm not sure how to do that in your case. Nowadays, I > would add a designated static mapping to the core/kernel mappings in > the "bootstrap" code for the corresponding board, e.g.: > As far as I know, I have a fairly recent version of Genode (17.08). But yes, now I am trying to map NONSECURE_RAM memory to the Secure World so that it can access both secure world and normal world memory such that in SW there are VA translations that map to PA's of NW. Would adding another region in repos/os/src/server/tz_vmm/spec/imx53/main.cc <https://github.com/genodelabs/genode/blob/1e8689bafefe156429998c4f2f92ae982675c34c/repos/os/src/server/tz_vmm/spec/imx53/main.cc> create these mappings in SW ie: _m4if.set_region1(Trustzone::NON*SECURE_RAM_BASE*, Trustzone::NONSECURE_RAM_SIZE); Because attempting to have overlapping memory such as edditing repos/base-hw/src/bootstrap/spec/imx53_qsb/platform_trustzone.cc <https://github.com/genodelabs/genode/blob/ee4ee6a8ac91592065cbf7a96872a95acb926b17/repos/base-hw/src/bootstrap/spec/imx53_qsb/platform_trustzone.cc> early_ram_regions(Memory_region{Trustzone::*SECURE_RAM_BASE*,Trustzone::SECURE_RAM_SIZE + Trustzone::NONSECURE_RAM_SIZE}) to have early ram region that encompass both secure and nonsecure is not allowed as far as I understand. However, once I do have these new virtual address translations, I am not sure how to get the VA from a given PA. VA -> PA I just use the ARM PAR register for translation, but the other way still eludes me. I know that linux provides virt_to_pys() and phys_to_virt() functions to convert between the two. In the Genode tz_vmm scenario, is there a phys_to_virt() (or equivalent function) I can use to get the virtual address that corresponds to a physical address? Or is there any way I could implement it? Thank you, Mauricio On Wed, Apr 11, 2018 at 2:42 AM, Stefan Kalkowski < ste...@ge...> wrote: > Hi Mauricio, > > thank you for sharing your intention. > > On Tue, Apr 10, 2018 at 10:51:15PM -0700, Mauricio Gutierrez wrote: > > Hello Stefan, > > > > Thank you for your reply. > > > > If you really need to execute code in monitor mode (I wonder why), I > > > think it will be best to create an explicit interface on the > > > kernel/core level that can be called from the VMM component, maybe an > > > extensions of the VM session interface. > > > > > > I think it somehow depends on what you are trying to do. If your > > > routine has to be called every time a secure monitor call was > > > executed, it is better to handle that directly within the > > > Vm::exception function. If you have a very special device that needs > > > to be accessed from secure, privileged/monitor mode you should extend > the > > > interface of kernel/core. > > > > > > > Indeed this is what I ended up doing. I have added some exception > handling > > in the default case > > of the Vm::exception function for my smc call (#4) before it switches > over > > to user-level privilege. > > > > Your are welcome. Maybe, you can give us some insights why do you need > > > to enter monitor mode at all? > > > > > > > I am trying to make it so that the secure world can lock some normal > world > > physical memory into the cache. > > For security reasons, I do not want to allow the normal word to do it so > I > > make an smc into secure world > > passing the virtual address to load into cache. The secure world then > uses > > the VA to PA registers to get the > > physical address and load the memory into the cache. Of course, the only > > way this would work would be for > > the cache entry to be tagged with an NS bit = 1. In order to do this, I > > need to enter monitor mode so that I can > > change the NS bit to 1 while remaining is secure world. This way I > perform > > the cache loading and locking on > > behalf of the normal world while being able to check for consistency. The > > issue I am facing now is that I get a > > cpu exception 3 (Breakpoint) when I try to write to the given normal > world > > memory from secure world, > > and I am not sure why. > > Ok, first I do not see how you can enforce the cache usage with > respect to the normal world. As long as the cache is enabled, how do > you confine memory access of the normal world when it's not asking > for permission (via your smc call)? > To me it looks like you want to close some covert channels by cache > data usage/displacement? In that case, maybe it is more reasonable to > circumvent usage of the cache by the secure world at all? > > Anyway, concerning your technical issue, I am not sure whether you > count the cpu exception from 0 or 1, but however it does not > correspond to a SMC or prefetch-abort exception. It is much more > probable that you receive a data-abort when writing to access that > memory. The first obvious reason is that you are using the wrong > virtual address to access the normal world physical memory you like to > access. Our kernel/core is not mapped one-by-one physical-to-virtual. > Moreover, the normal world memory is not mapped at all into Genode's > kernel. > > > > > Right now I am trying to access the physical address by temporarily > > disabling the mmu so PA = VA. > > This should not work in recent versions of our kernel, because as I > wrote before the kernel binary is linked to a different virtual > address region than its physical memory representation. That means, > the kernel will fault immediately when disabling the MMU. > > > However, another method would be to create/edit a page table entry in the > > secure world such that it > > maps to the specified physical address, essentially creating world shared > > memory. However, I am not > > sure how I would do this in Genode. For example, in the Normal World > linux > > I could edit the paging global > > directory, but in the Genode OS how could I make a PTE map to a given > > physical address? > > There is a designated kernel/core page-table that can be used to add > kernel mappings. Obviously, you are using some quite old Genode > version, so I'm not sure how to do that in your case. Nowadays, I > would add a designated static mapping to the core/kernel mappings in > the "bootstrap" code for the corresponding board, e.g.: > > https://github.com/genodelabs/genode/blob/master/repos/base- > hw/src/bootstrap/spec/imx53_qsb/platform_trustzone.cc#L38 > > as an example for the i.MX53 Quickstart board when used with > TrustZone. The "core_mmio" regions here are static mappings always > present in the kernel. When the normal world memory is to big, it > might not fit into the virtual "core_mmio" region. Have a look at this > file to check the kernel virtual memory regions: > > https://github.com/genodelabs/genode/blob/master/repos/base- > hw/src/lib/hw/spec/32bit/memory_map.cc > > However, being in your position I would re-think the approach as a > whole, before digging further down the rabbit hole ;-). > > Best regards > Stefan > > > > > Thank you, > > > > Mauricio > > > > > > On Mon, Apr 9, 2018 at 2:36 AM, Stefan Kalkowski < > > ste...@ge...> wrote: > > > > > Hi Mauricio, > > > > > > On Wed, Mar 28, 2018 at 07:48:43PM -0700, Mauricio Gutierrez wrote: > > > > Hello, > > > > > > > > I have been doing some work with the Genode Trustzone VMM scenario > on my > > > > i.MX53 development board and I am having a bit of trouble > understanding > > > how > > > > the SMC calls work between the normal and secure world. Online you > talk > > > > about how you implemented 6 calls in the modified normal world linux > > > kernel > > > > but in the main for the tz_vmm I only found 4 different cases in the > > > > _handle_smc() function. In any case, I wanted to add my own call and > was > > > > able to add it and check that the required arguments are passed > correctly > > > > and everything so that part I think I understand. > > > > > > > > However, I need to do some of the handling in Monitor Mode and my > > > > understanding was that an SMC would throw your into monitor mode but > it > > > > seems the handler operates in user mode? Since it is not privileged > then > > > I > > > > am not able to call a "cps #22" to switch to monitor mode. In an > earlier > > > > thread I know you refer to the > > > > > > > > section "World switch between non-secure world and secure > > > > > world" in http://genode.org/documentation/articles/trustzone. > > > > > > > > But I am still uncertain as to how I could get my case in > _handle_smc() > > > to > > > > enter monitor mode so that I can play around with the NS bit without > > > > leaving secure world. > > > > > > You are right, our virtual-machine monitor is an unprivileged > > > user-level component. Because driving the normal world is not > > > crucial to other components inside the secure world, there is no need > > > to make them dependent on complex emulation/para-virtualization code > inside > > > the kernel. That is why the kernel contains a slim > > > exception-vector-only functionality that is used to copy over the > > > normal world state to the VMM user-level component. This > > > exception-vector code is entered, e.g., when doing a "smc" call and > > > can be found here: > > > > > > repos/base-hw/src/core/spec/arm_v7/trustzone/exception_vector.s > > > > > > That assembly code is the only code executed in monitor mode. In the > > > end it switches to secure world's supervisor mode and enters the > > > normal kernel routine. However, it hits subsequently some C++ VMM > > > kernel object routine here: > > > > > > repos/base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc > > > > > > Namely, the Vm::exception function, which informs the kernel scheduler > > > to exclude the normal world for now, and signals the VMM user-level > > > component that the normal world's state changed. > > > > > > > I have been studying what happens when I call an smc, say "smc #4" > from > > > > normal world. But I have not been able to exactly pin point, where > is the > > > > entry point for such an exception in the Genode secure world call? > What > > > > exactly happens once I make that call to secure world and where I > can I > > > > find/follow the code? Is this covered somewhere in your book? > > > > > > > > I know about the mode_transitions.s file as well as the > > > exception_vector.s > > > > and vm.cc files in repos/base-hw/src/core/spec/arm_v7/trustzone, it > > > seems > > > > this is the entry point? But where does it go after we call the > > > > nonsecure_to_secure transition? > > > > > > > > Most importantly, I need to understand where is the code operating in > > > > monitor mode? Where does it end and where does it start? How can I > tell? > > > If > > > > I needed to write at least some part of my smc handler in monitor > mode > > > > before it switches out, what is the best approach to doing that? > > > > > > > > > > If you really need to execute code in monitor mode (I wonder why), I > > > think it will be best to create an explicit interface on the > > > kernel/core level that can be called from the VMM component, maybe an > > > extensions of the VM session interface. > > > > > > I think it somehow depends on what you are trying to do. If your > > > routine has to be called every time a secure monitor call was > > > executed, it is better to handle that directly within the > > > Vm::exception function. If you have a very special device that needs > > > to be accessed from secure, privileged/monitor mode you should extend > the > > > interface of kernel/core. > > > > > > > I apologize for all the questions and would appreciate any help and > > > > guidance you can provide. > > > > > > Your are welcome. Maybe, you can give us some insights why do you need > > > to enter monitor mode at all? > > > > > > Best regards > > > Stefan > > > > > > > > > > > Thank you, > > > > > > > > Mauricio > > > > > > > ------------------------------------------------------------ > > > ------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > _______________________________________________ > > > > genode-main mailing list > > > > gen...@li... > > > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > > > > > > > -- > > > Stefan Kalkowski > > > Genode labs > > > > > > https://github.com.skalk | https://genode.org > > > > > > ------------------------------------------------------------ > > > ------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > genode-main mailing list > > > gen...@li... > > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > genode-main mailing list > > gen...@li... > > https://lists.sourceforge.net/lists/listinfo/genode-main > > > -- > Stefan Kalkowski > Genode labs > > https://github.com.skalk | https://genode.org > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > genode-main mailing list > gen...@li... > https://lists.sourceforge.net/lists/listinfo/genode-main > |
|
From: Norman F. <nor...@ge...> - 2018-04-16 09:29:23
|
Hello Johnathan, On 10.04.2018 23:20, Johnathan Gohde wrote: > I've been trying to figure out how to give an initial window placement > for Qt5 applications on startup. I've tried to mimic the example set in > ported applications, like found in qt_launchpad/main.cpp:89, using a > window.move(0,0) call in my application, but this doesn't place the > window in the corner. > > Can anybody help me out or point me in the right direction? I presume that your scenario is based on one of the examples of the libports repository. These examples use the window manager, which employs dedicated components for the managing the window layout (layouter) and producing the window decorations (decorator). The initial positioning of windows is the job of the layouter. The layouter used by the examples can be configured to place new windows at a specified position. You can find the configuration options documented in the corresponding README [1]. [1] repos/gems/src/app/floating_window_layouter/README Regards Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth |
40 messages has been excluded from this view by a project administrator.
