From: Benjamin Berg <benjamin@sipsolutions.net>
To: Benjamin Beichler <Benjamin.Beichler@uni-rostock.de>,
Johannes Berg <johannes@sipsolutions.net>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: linux-um@lists.infradead.org
Subject: Re: [PATCH RFC 10/11] um: Delay timer_read only in possible busy loops in TT-mode
Date: Fri, 10 Nov 2023 17:39:39 +0100 [thread overview]
Message-ID: <0246e8d9dbccf86a2e83560cc62c0d4b752c7c25.camel@sipsolutions.net> (raw)
In-Reply-To: <867df5dc-8e78-48de-aa1a-da7c8fedb5e6@uni-rostock.de>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Fri, 2023-11-10 at 16:54 +0100, Benjamin Beichler wrote:
> At the moment, we haven't patched the random device that fetches random
> bytes from the host (do you already have a patch for this?),
> so complete repeatability isn't guaranteed at the moment. However, that
> could be a logical next step.
Right, we have the attached kernel patches internally. This simply
disables some of the random sources and replaces os_getrandom with
returning static random from the UML_RANDOM environment variable.
I doubt that it makes sense to upstream these patches, but may we can
include them as patch files in USFSTL or so.
The second piece is using a mount namespace to ensure that the linux
command line is identical between runs and that the location of all
files that are accessed directly from the host through hostfs never
changes.
The last piece was setting GLIBC_TUNABLES=-AVX512CD in the environment
just in case the CPU feature set is slightly different. That would
cause ld.so to search for a different set of optimized library versions
(affecting syscalls and with that randomness).
Benjamin
[-- Attachment #2: 0001-um-Use-fixed-random-seed-if-UML_RANDOM-is-set.patch --]
[-- Type: text/x-patch, Size: 1758 bytes --]
From 0b51202872111f1a5f7a59435ff741ef0272d30f Mon Sep 17 00:00:00 2001
From: Benjamin Berg <benjamin.berg@intel.com>
Date: Thu, 16 Mar 2023 13:19:37 +0200
Subject: [PATCH 1/3] um: Use fixed random seed if UML_RANDOM is set
This helps with reproducable test runs.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
---
arch/um/os-Linux/util.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/um/os-Linux/util.c b/arch/um/os-Linux/util.c
index fc0f2a9dee5a..1e7b19272dfa 100644
--- a/arch/um/os-Linux/util.c
+++ b/arch/um/os-Linux/util.c
@@ -99,6 +99,42 @@ static inline void __attribute__ ((noreturn)) uml_abort(void)
ssize_t os_getrandom(void *buf, size_t len, unsigned int flags)
{
+ static char random_pattern[128];
+ static ssize_t random_pattern_len = -1;
+
+ /* This happens when called by setup_arch */
+ if (random_pattern_len == -1) {
+ const char *env;
+
+ env = getenv("UML_RANDOM");
+ if (env) {
+ random_pattern_len =
+ strlen(env) > sizeof(random_pattern) ?
+ sizeof(random_pattern) : strlen(env);
+ memcpy(random_pattern, env, random_pattern_len);
+ } else {
+ random_pattern_len = 0;
+ }
+ }
+
+ if (random_pattern_len > 0) {
+ size_t tail = len;
+ /*
+ * If the returned length is too short, then the kernel might
+ * loop trying to generate random from the passing of time.
+ * Which seems to possibly infinite loop in time-travel mode.
+ * So just repeat the given pattern.
+ */
+ while (tail > random_pattern_len) {
+ memcpy(buf, random_pattern, random_pattern_len);
+ tail -= random_pattern_len;
+ buf += random_pattern_len;
+ }
+ memcpy(buf, random_pattern, tail);
+
+ return len;
+ }
+
return getrandom(buf, len, flags);
}
--
2.41.0
[-- Attachment #3: 0002-random-disable-interrupt-random-source.patch --]
[-- Type: text/x-patch, Size: 1057 bytes --]
From b8aa74aed9fa008b908682bfa085461635e876e0 Mon Sep 17 00:00:00 2001
From: Benjamin Berg <benjamin.berg@intel.com>
Date: Thu, 16 Mar 2023 13:21:19 +0200
Subject: [PATCH 2/3] random: disable interrupt random source
Interrupts in our UML environment are signals, which can be delivered at
somewhat random times depending on host scheduling. Disable these as a
source to make the random reproducible between runs.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
---
drivers/char/random.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 253f2ddb8913..db2c5a296c05 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1093,6 +1093,9 @@ void add_interrupt_randomness(int irq)
struct pt_regs *regs = get_irq_regs();
unsigned int new_count;
+ /* UML seems to not always get the signals entirely at the same time */
+ return;
+
fast_mix(fast_pool->pool, entropy,
(regs ? instruction_pointer(regs) : _RET_IP_) ^ swab(irq));
new_count = ++fast_pool->count;
--
2.41.0
[-- Attachment #4: 0003-random-do-not-include-utsname-in-early-random.patch --]
[-- Type: text/x-patch, Size: 1021 bytes --]
From c62e671073cfe990fd2200c81defae98b1e9258b Mon Sep 17 00:00:00 2001
From: Benjamin Berg <benjamin.berg@intel.com>
Date: Wed, 22 Mar 2023 17:56:37 +0100
Subject: [PATCH 3/3] random: do not include utsname in early random
The uts name includes information about the compile time and such and
changes. Exclude it, so that different kernel compilations will see
the same random numbers.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index db2c5a296c05..dd4aa42a4404 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -865,7 +865,7 @@ void __init random_init_early(const char *command_line)
++i;
}
- _mix_pool_bytes(init_utsname(), sizeof(*(init_utsname())));
+ /* _mix_pool_bytes(init_utsname(), sizeof(*(init_utsname()))); */
_mix_pool_bytes(command_line, strlen(command_line));
/* Reseed if already seeded by earlier phases. */
--
2.41.0
[-- Attachment #5: Type: text/plain, Size: 152 bytes --]
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2023-11-10 16:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 16:41 [PATCH RFC 00/11] Several Time Travel Mode Enhancements Benjamin Beichler
2023-11-03 16:41 ` [PATCH RFC 01/11] um: Make UBD requests synchronous in TT ext/infcpu mode Benjamin Beichler
2023-11-06 20:24 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 02/11] um: add a simple time_travel_handler implementation Benjamin Beichler
2023-11-03 16:41 ` [PATCH RFC 03/11] um: Use a simple time travel handler for line interrupts Benjamin Beichler
2023-11-06 20:26 ` Johannes Berg
2023-11-10 16:53 ` Benjamin Beichler
2023-11-10 17:16 ` Johannes Berg
2023-11-13 11:46 ` Benjamin Beichler
2023-11-13 21:22 ` Johannes Berg
2023-11-13 21:57 ` Johannes Berg
2023-11-20 13:42 ` Benjamin Beichler
2023-11-24 14:53 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 04/11] um: Handle UM_TIMETRAVEL_RUN only in idle loop, signal success in ACK Benjamin Beichler
2023-11-06 20:53 ` Johannes Berg
2023-11-10 18:41 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 05/11] um: Add final request time to TT wait message Benjamin Beichler
2023-11-06 20:29 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 06/11] um: always send UM_TIMETRAVEL_REQUEST from ISRs Benjamin Beichler
2023-11-06 20:32 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 07/11] um: add TIMETRAVEL_REQUEST handler to request latest event Benjamin Beichler
2023-11-06 20:33 ` Johannes Berg
2023-11-10 16:23 ` Benjamin Beichler
2023-11-10 17:19 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 08/11] um: Protect accesses to the timetravel event list Benjamin Beichler
2023-11-06 20:37 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 09/11] um: Delay timer_read in time travel mode only after consecutive reads Benjamin Beichler
2023-11-06 20:40 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 10/11] um: Delay timer_read only in possible busy loops in TT-mode Benjamin Beichler
2023-11-06 20:51 ` Johannes Berg
2023-11-10 15:54 ` Benjamin Beichler
2023-11-10 16:39 ` Benjamin Berg [this message]
2023-11-10 17:29 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 11/11] um: Remove all TSC flags when using Time Travel Mode Benjamin Beichler
2023-11-03 18:45 ` Anton Ivanov
2023-11-06 20:52 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0246e8d9dbccf86a2e83560cc62c0d4b752c7c25.camel@sipsolutions.net \
--to=benjamin@sipsolutions.net \
--cc=Benjamin.Beichler@uni-rostock.de \
--cc=anton.ivanov@cambridgegreys.com \
--cc=johannes@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox